📖About

Found in the 2026-07-15 Pipeline-app truth audit. When the concurrent-execution cap is exceeded, the enforcer flips a LIVE executing initiative back to dispatched (2631 at 21:11 Jul-14, 2628 at 02:44 Jul-15), silently abandoning the in-flight run; the dispatcher later re-runs the same row as attempt N+1. This violates the admin-locked re-run authority matrix (cookbook 34 - no dispatcher lane for initiative re-runs), the failed-step cascade (cookbook 377 - a dead attempt must FAIL, not vanish), the verified-fix refile lane (cookbook 455 - new attempts are -NN refiles) and the queue feeding model (cookbook 429 - backfill promotes planned items only). Also observed: the sprint backfiller posted two identical backfill decisions in the same minute (race). FIX: (a) the cap must be enforced at START time - refuse to begin excess work; an EXECUTING initiative is never pulled back into the queue; (b) status-router guard forbidding executing->dispatched (mirror of the blocked->dispatched rule) so no caller can do this again; (c) make the backfiller idempotent per tick. Bypass, pipeline-fixing scope.

⚖️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)
• Current state at filing (Elrond validity check): The Pipeline Orchestrator and Mirror are running; the described bug where executing initiatives are silently re-queued when the concurrency cap is exceeded still exists per the audit findings, with no evidence of a fix yet deployed. (elrond)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [status-router] reviewing -> closed | event=operator_signoff | Auto-accepted (CAROL-INI-1859): Orion-initiated, >2 days in reviewing with no objection. (el-srac-01)

✅Success criteria

• No initiative silently loses a live run anymore: once a run starts executing it ends only in a real outcome (review, failure, or block) - the story readers see no more superseded attempts caused by re-queuing. (must_have)
• When too many things run at once, the extra work simply WAITS its turn in the queue - nothing mid-flight is yanked back, and the Pipeline app shows attempts that each tell a complete story. (must_have)
• Any future attempt to pull an executing initiative back into the queue is refused and visibly recorded, so the reader of the initiative wall sees who tried and why it was denied. (must_have)