ORA-2026-0060: Fleet re-escalates resolved operator actions without verifying

ORA-2026-0060: Fleet re-escalates resolved operator actions without verifying

Observation

On 2026-04-25, Chad provided screenshots proving two operator actions the fleet had repeatedly escalated were already completed:

1. DWD scope grant (FLT-0301): Google Admin Console showed gmail.readonly, gmail.metadata, AND gmail.compose scopes on orbit-mcp-runtime@orbitmcp.iam.gserviceaccount.com. Chad: "the DWD has been done for days. i have checked it every time the fleet has complained."

2. iPhone developer trust (CMB-0184/CMB-1356): iPhone Settings showed CamberRedline as "Verified" under Apple Development: chbarlow@gmail.com (9683PJ9JTG).

In both cases, the fleet treated "BLOCKED on Chad" as a permanent state until Chad explicitly reported completion. No seat verified whether the blocker had been resolved before re-escalating.

Pattern

1. Seat encounters a blocker requiring operator action 2. Seat posts BLOCKED owner=chad with the action request 3. Chad performs the action (no fleet-visible receipt) 4. Next seat encounters the same downstream failure 5. Seat sees prior BLOCKED-on-chad post, assumes action not done 6. Seat re-escalates to Chad with the same ask 7. Repeat until Chad provides explicit proof (screenshot)

The failure is in step 5: the assumption that "BLOCKED on Chad with no DONE post = Chad hasn't done it." The fleet has no mechanism to detect operator action completion other than Chad posting to the feed.

Root cause

Two gaps:

Gap 1: No operator-action verification protocol

When a seat encounters a downstream failure after a BLOCKED-on-chad item exists, the correct response is: verify whether the operator action was completed before re-escalating. For DWD, that means checking the SA token mint against the target scope. For developer trust, that means attempting the build. The fleet skips verification and goes straight to re-escalation.

Gap 2: Misdiagnosis masked by escalation

For FLT-0301/FLT-0429, the actual failure was a code-path bug in the hcb-gmail-admin edge function — it was not using the same auth path proven in FLT-0300. But because the symptom ("compose scope unavailable") resembled a DWD configuration issue, every seat routed it to Chad instead of investigating the code. The escalation-to-Chad path became the default because it was easier than debugging the connector.

Remediation (proposed)

1. Verify-before-re-escalate rule: before posting any item as BLOCKED owner=chad for an action Chad was previously asked to do, the posting seat MUST verify the action state programmatically. For auth: attempt the operation. For device config: check the downstream symptom. If verification is impossible, state why.

2. Operator-action-complete feed convention: when Chad performs a requested action, a DONE post should be filed (by Chad or by the first seat that observes the action was done). This closes the feedback loop.

3. Misdiagnosis guard: when an error message resembles a known blocker type (auth scope, credential, device config), check whether the blocker was already resolved before assuming it is the root cause. "Looks like X" is not "is X."