📖About

1) Move 4 blocked initiatives (0055, 0022, 0020, 0016) to planned + enqueue for dispatch. 2) Enable carol-dispatch.timer (5min is already correct). 3) Add priority boost for previously-blocked initiatives in enqueue(). 4) Update RSI module step 3 to move blocked→planned + enqueue instead of direct route_status to executing. 5) Update cookbook.

⚖️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)
• Follow-on to parent INI 999900601 (orion)
• Scope inherited verbatim from parent INI 999900601 per CAROL-INI-361. (elrond.initiative_author)
• [status-router] planned -> dispatched | event=dispatch | RSI: auto-promoted bypasses depth limit (CAROL-INI-2198) (spb-01)
• [status-router] dispatched -> blocked | event=stuck_10min_no_activity | Elrond safety net: initiative has had no activity for 10+ minutes. Blocking under the parallel safety mechanism. (el-watchdog)
• Elrond safety net blocked initiative: no activity for 10+ minutes. Parallel mechanism (twin of handshake). (el-watchdog)
• Elrond blocked initiative under the CAROL-INI-2162 dead-Albus protocol. Albus was supposed to wake for step 0 (cause=albus_no_show) but did not respond. Cause: albus_no_show. Reason: Elrond safety net: initiative stranded 10+ min. Albus wake failed or produced no useful result. (el-s1)
• Orion remediated: Albus RSI group diagnosis (via INI 999900575): [procedural, confidence high] The initiative blocked because the Albus executor never received a proper activation signal (bypass_start was never called) after dispatch. The execution history is empty and the dispatch queue status is 'cancelled', consistent with the pattern in prior diagnoses where the operator failed to invoke bypass_start on bypass-mode initiatives, leaving the initiative stranded until Elrond's 10-minute inactivity safety net triggered. (orion)
• [status-router] blocked -> closed | event=operator_put | PUT /api/initiatives (operator)
• [rsi-group-cure] Cured by the group diagnosis on INI 999900575 (shared cause stuck_10min_no_activity); retriggered as INI 999900876. Root cause: [procedural, confidence high] The initiative blocked because the Albus executor never received a proper activation signal (bypass_start was never called) after dispatch. The execution history is empty and the dispatch queue status is 'cancelled', consistent with the pattern in prior diagnoses where the operator failed to invoke bypass_start on bypass-mode initiatives, leaving the initiative strand (elrond.rsi_loop)

✅Success criteria

• 4 blocked initiatives moved to planned and enqueued (must_have)
• carol-dispatch.timer is enabled and active (must_have)
• Previously-blocked initiatives get priority boost in dispatch queue (must_have)
• RSI step 3 moves blocked to planned + enqueues instead of direct route_status to executing (must_have)