📖About

OPERATOR EMERGENCY (Ninad 2026-07-03), explicitly NOT the CAROL-INI-2128 feature work: the gate built by 2128 is live and pausing EVERY dispatch right now — including 2128s own planner attempt (999900511, dispatched+paused by its own gate: a deadlock the pipeline cannot self-heal). The queued cap of 3 holds; the flood is the paused pool the gate feeds (11 rows, growing every dispatcher tick). Orion applies the minimal operator correction so the pipeline can move again: (a) evidence lookup accepts the LIVE attempts vocabulary (succeeded/success/completed, or partial with non-empty result summary; failed/in_progress are not evidence) instead of the near-nonexistent completed status; (b) MISSING attempts row becomes advisory (decision logged, no halt) — the STALE halt stays; (c) cancel the phantom-paused rows so the reconciler re-feeds within the cap. The gate REDESIGN stays with Elronds CAROL-INI-2128-01 lane, untouched — a linking decision records this split, mirroring the CAROL-INI-2291 watchdog emergency-stop pattern.

⚖️Decisions

• Elrond's bypass methodology checklist (a reminder, not a gate -- you've got this): 0. File it requested_mode='bypass' (planner-vs-bypass is a deliberate choice). bypass_start REFUSES a non-bypass initiative (CAROL-INI-1846), and the dispatcher only skips the bypass lane when the mode says bypass -- a 'planner' mistag lets Merlin's pipeline grab the placeholder step and block your finished work. 1. Filed as planned status -- let the bypass claim/activate it; never file active. 2. Open the bypass (bypass_start) with your droid id + the remediation answer (remediates_initiative_id=NNN, or remediates_nothing=True). 3. Work the blocks for your work-type: template -> design -> code -> test -> review. Do the real work; record decisions on the initiative as you make them. 4. Reality is recorded for you at close -- code (files changed), each decision, and the twin-review verdict become real activities tied to this initiative and show in the Activity Tracker like a planner run (CAROL-INI-1840). No dummy rows. 5. Keep the initiative status moving; it parks in 'reviewing' and is tagged uat-pending for you at close (CAROL-INI-1836), so the stuck-watchdog leaves it alone until UAT. 6. Close runs the gates (design/architecture compliance + caller-audit). If a gate flags something pre-existing or unrelated to your change, waive it with a clear written rationale -- audit, don't skip. 7. Bypass skips the planner's auto-orchestration, NOT the standards. Same template checklist, same review, same observability as a planner run. (elrond)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• Gate evidence lookup fixed to the live attempts vocabulary (succeeded/success/completed/partial with non-empty summary); missing evidence is now ADVISORY (logged, no halt); the stale halt is unchanged. Live-verified: gate passes on 999900568 (previously halted). 11 phantom gate-fail paused rows cancelled; reconciler re-feeds within the queued cap of 3. Linking decision recorded on CAROL-INI-2128-01 (redesign stays in that lane). Backup .pre-2317. NOTE for redesign: the recurring radagast needs_attention rows for INIs 7/8 are a separate escalation-noise issue, untouched. (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [status-router] reviewing -> blocked | event=operator_put | PUT /api/initiatives (operator)
• Orion remediated: Albus RSI group diagnosis (via INI 999900484): [procedural, confidence high] The initiative was manually blocked by operator 'or-bx-01' (PUT /api/initiatives) because the previous attempt's success criteria were never genuinely verified — the reviewer log shows that 'stale_artifacts' pre-verify failures preceded a forced transition to 'executing' followed by an immediate operator block, indicating that the operator recognized the procedural gap (missing evidence of actual droid replacement, shim delegation, and cookbook updates) and blocked to prevent a repeat of the same failure pat (orion)
• Orion remediated: Albus RSI group diagnosis (via INI 999900490): [procedural, confidence high] The initiative is blocked because the operator manually put it to blocked after a reviewer reopened it for rework, indicating that the execution artifacts did not satisfy the success criteria. The prior diagnosis for a similar initiative (1000107) highlighted that criteria were meta-checks rather than substantive, and although the current criteria appear improved, the pipeline still lacks proper evidence capture automation, causing the operator to intervene when progress stalls. (orion)
• [status-router] blocked -> closed | event=operator_put | PUT /api/initiatives (operator)
• [rsi-group-cure] Cured by the group diagnosis on INI 999900490 (shared cause operator_put); retriggered as INI 999900927. Root cause: [procedural, confidence high] The initiative is blocked because the operator manually put it to blocked after a reviewer reopened it for rework, indicating that the execution artifacts did not satisfy the success criteria. The prior diagnosis for a similar initiative (1000107) highlighted that criteria were meta-checks rather than substantive, and although the current criteria appear improved, the (elrond.rsi_loop)

✅Success criteria

• Gate evidence lookup accepts succeeded/success/completed or partial-with-summary; missing rows advisory only; stale halt unchanged; verified by a live gate run (must_have)
• Phantom-paused rows cancelled; dispatch flows again within the queued cap of 3; no new missing-artifacts pauses (must_have)
• Linking decision recorded on CAROL-INI-2128-01 attributing the root-cause redesign to that lane (must_have)