ORA-2026-0063: STRAT owns queue health autonomously

ORA-2026-0063: STRAT owns queue health autonomously

Rule

Every ORA-lane STRAT session MUST proactively clear its decision backlog without waiting for Chad to escalate. Queue health is STRAT's job, not the operator's.

Boot-time protocol

On session start, after identity negotiation and feed-bracket open:

Step 1 — Queue health scan

fleet-active-queue | grep 'owner=ORA-lane\|owner=chad' | wc -l
fleet-active-queue | grep 'owner=ORA-lane' | grep 'BLOCKED\|AWAITING_CLAIM'

Step 2 — Triage

For every BLOCKED-on-ORA-lane or BLOCKED-on-chad item:

1. Read the original feed post (not just the reroute post) 2. Classify: is this a STRAT decision (source contract, schema, write target, deprecation, policy)? Or is it genuinely blocked on an external dependency? 3. STRAT decisions: render immediately. Spawn parallel Opus subagents for batches of 5+ (per ORA-2026-0055 two-stage decomposition). 4. BLOCKED-on-chad items: verify whether the operator action was already completed (per ORA-2026-0060) before re-escalating. Programmatic verification first; only escalate if verification fails. 5. External blockers: leave BLOCKED but document what's needed.

Step 3 — Report

After rendering, report to Chad ONLY the items that genuinely require his action. Format:

N items BLOCKED on you:
1. ITEM-ID — one sentence, what you need to do

No analysis. No context paragraphs. Just the list.

Continuous monitoring

During the session, re-scan the queue every 30 minutes (or after completing a batch of work). New items routed to ORA-lane should be rendered within the same session, not deferred.

Anti-patterns

• Waiting for Chad to ask "what's blocked?" — that question should

never need to be asked. If Chad asks it, STRAT already failed.

• Reporting queue state without acting — "there are 60 items

BLOCKED on ORA-lane" is an observation, not leadership. Render the decisions.

• Relabeling without rendering — moving items from owner=chad to

owner=ORA-lane without exercising decision authority (ORA-2026-0058).

• Re-escalating resolved operator actions — asking Chad to do

something he already did (ORA-2026-0060).

Decision rendering protocol

For each BLOCKED item needing a STRAT decision:

1. Read the original feed post to understand what's being asked 2. Check relevant DB schema / codebase if it's a source-contract or write-target question 3. Render a verdict with rationale 4. Transition to AWAITING_CLAIM owner=any-idle-CAMBER-codex (or DONE if the decision itself is the deliverable) 5. Post to feed with PRIOR-DIAGNOSTIC citing the original post

For batches: spawn parallel Opus subagents (per ORA-2026-0055), each handling ~12 items. Subagents read feed context, check schemas, render decisions, and post to feed.

Metrics

A healthy ORA-lane STRAT session:

• Decision-render throughput: >0 per hour when BLOCKED items exist
• BLOCKED-on-ORA-lane count: trending toward zero
• BLOCKED-on-chad count: only items that genuinely require physical

device, credentials, or business-direction input

• Time from BLOCKED to rendered: <30 min for items within STRAT

authority

A session that ends with renderable BLOCKED items unaddressed is in failure mode.

Graduation

Born M3 (canonical, binding) per Chad's directive making this the default for all future ORA sessions. Reaches M4 when a boot-time validator rejects an ORA session that skips the queue health scan.