📖About

Clara escalated twice (the SST Scanner repeat-failure family on 2026-08-10, and the never-ran at-010/stw-010 family on 2026-08-02) and both escalations exist ONLY as rows in her own accountability ledger -- nothing delivered them to the operator, who found them by chance while reading her ledger. The estate already has an official escalation channel: an Agentbook message to Orion (visible to sender, recipient and Orion; carries a read flag). The Mind's escalate action simply never uses it.

Scope (no new store -- one home for the ask, per the no-duplicates law): 1. The Mind loop's escalate action, in addition to the agent's own ledger entry, sends an Agentbook message from the escalating agent to Orion carrying the escalation text. 2. Orion's board gains an ESCALATIONS block: unread Agentbook messages addressed to Orion, sender named, oldest first. Reading/acknowledging marks the message read via the store's own lane. 3. Session start (the Logbook session opener every session runs at Step 0, induction or not) returns the pending unread-escalation count so a no-induction session still sees escalations before any work starts. 4. Backfill: Clara's two existing open escalations are delivered as Agentbook messages to Orion citing their original dates. 5. A regression test in the persistent runner: an escalate action produces an unread Agentbook message to Orion; the board lists it; marking read clears it from the pending count. 6. The induction doc's Part 2 board description and Step 0 mention the escalation surface.

⚖️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)
• [delivery-check] 6 pending must-have criteria stamped met at bypass_end on live re-performance evidence (CAROL-INI-3020): test test_ini3816.py: PASS (3 passed in 0.48s) (orion)
• [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

• The Mind loop's escalate action sends an Agentbook message from the escalating agent to Orion (agt_023) carrying the escalation text, in addition to the agent's own accountability-ledger entry (must_have)
• Orion's board prints an ESCALATIONS block listing unread Agentbook messages addressed to Orion with sender name and date, oldest first, and prints nothing extra when there are none (must_have)
• The Logbook session opener returns the count of unread Agentbook messages addressed to Orion, so every session sees pending escalations at Step 0 even without induction (must_have)
• Clara's two existing escalations (SST Scanner repeat-failure family; never-ran at-010/stw-010 family) are delivered as unread Agentbook messages to Orion citing their original dates (must_have)
• A regression test in regression/tests.json proves: escalate action creates an unread message to Orion, the board lists it, and marking it read removes it from the pending count (must_have)
• The induction doc Part 2 and Step 0 describe the escalation surface (must_have)