📖About

Currently Albus is only woken by Merlin's step reviewer when an execution fails. If the dispatcher is broken (breaker tripped, not running), no execs are created, no reviewer fires, and Albus never gets called. Fix: add _invoke_albus_for_initiative that wakes Albus with initiative-level context (not exec-level). Call it from _block_stuck_initiatives before blocking. This lets Albus diagnose and fix dispatcher issues (e.g., resume breaker, restart dispatch timer) independently.

⚖️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 999900584 (orion)
• Scope inherited verbatim from parent INI 999900584 per CAROL-INI-361. (elrond.initiative_author)
• Validator-refinement (CAROL-INI-509): Refined Cookbook entry from #400 to #397: Cookbook index shows last entry is #396; #400 does not exist, next available is #397. (elrond.initiative_author)
• Validator-refinement (CAROL-INI-509): Refined criterion: Cookbook entry number changed from #400 to #397 because Cookbook index highest entry is #396 (per state), and #397 is the next free slot; parent had incorrectly assumed #400 was available. (elrond.initiative_author)
• Validator-refinement (CAROL-INI-509): Added note: Must include a mandatory topic tag per cookbook #396 rule when creating entry #397. (elrond.initiative_author)
• Validator round 2 still flagged 2 items — operator review needed (CAROL-INI-509). (elrond.initiative_validator)
• [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 999900502): [procedural, confidence high] The Albus executor did not wake to process step 0 of the initiative after dispatch (albus_no_show), leaving it idle with no execution history until the Elrond safety net blocked it after 10 minutes of inactivity. This is a procedural failure consistent with a systemic pattern where Albus fails to respond to dispatch events, as confirmed by the empty execution history and the dead-Albus protocol decision. (orion)
• [status-router] blocked -> closed | event=operator_put | PUT /api/initiatives (operator)
• [rsi-group-cure] Cured by the group diagnosis on INI 999900502 (shared cause stuck_10min_no_activity); retriggered as INI 999900843. Root cause: [procedural, confidence high] The Albus executor did not wake to process step 0 of the initiative after dispatch (albus_no_show), leaving it idle with no execution history until the Elrond safety net blocked it after 10 minutes of inactivity. This is a procedural failure consistent with a systemic pattern where Albus fails to respond to dispatch events, as confirmed by the empty execution history (elrond.rsi_loop)

✅Success criteria

• _wake_albus_for_initiative in elrond_watcher wakes Albus independently of dispatcher (must_have)
• _block_stuck_initiatives calls Albus before blocking stuck initiatives (must_have)
• Cookbook entry #397 documenting independent Albus invocation (must_have)