📖About

RSI diagnosis (CAROL-INI-2223b/2246, cookbook 456): Albus root-causes WHY CAROL-INI-2627-00 (row 999901240, 'CAROL-INI-2627-00: Auto-detected failed process: App Watchdog (app-watchdog-01)') blocked using the THREE-LAYER TROUBLESHOOTING FRAMEWORK below. Diagnose in order — do NOT jump to code patches before checking the plan and execution.

=== TROUBLESHOOTING FRAMEWORK (cookbook 456) ===

LAYER 0 — PREMISE (CAROL-INI-2732): Is this block even real?

• Check the PLAN STEPS: are they ALL done? Check the last status transitions:

did the block come FROM reviewing, with no step-level failure evidence?

• If yes to both: the work is ALREADY COMPLETE and this is a FALSE BLOCK.

Verdict = failure_type [false-block]; root cause = what flipped the finished item to blocked; recommendation = restore to reviewing, NO retrigger, NO rework. Do NOT proceed to Layers 1-3 and do NOT invent pipeline causes for completed work.

• VERDICT: Premise holds (work genuinely incomplete/failed) -> Layer 1.

LAYER 1 — GOAL & STRATEGY: Was the initiative ever going to succeed?

• What was the initiative supposed to achieve? What user-visible outcome?
• Would ELROND'S PLAN (the steps) have delivered that outcome if every step succeeded?
• If the plan was unsound: what was missing? If sound: why didn't it execute?
• VERDICT: Good plan -> Layer 2. Bad plan -> recommend fixing the plan BEFORE retrigger.

LAYER 2 — STEP EXECUTION: Did every step have the right people, tools, and instructions?

• Step definitions: Were they clear and actionable? Did each step specify WHAT to build?
• Team: Were the right agents/droids assigned? Did any step skip a required phase without OVERRIDE?
• Skills: Was each step paired with the correct skill? Was the skill available and wired?
• Tasks: Did each task succeed? If not, was it a code error, tool error, or pipeline config error?
• VERDICT: Execution is sound -> Layer 3. Execution broken -> recommend SPECIFIC fixes.

LAYER 3 — SAFETY NET: Was Albus set up to succeed when called?

• Is Albus alive and reachable? Can he receive and process diagnosis requests?
• Did his prompt carry FULL context: initiative goal, step plan, execution logs, failure reason?
• Can his recommendation be applied without operator intervention? Is it pipeline-scoped?
• VERDICT: If Layers 1+2 are sound but the block persists, the safety net is the root cause.

META-RULE: Answer this question in every diagnosis — "What should the NEXT attempt do DIFFERENTLY to succeed?" Ground your answer in a specific Layer finding. Generic advice like 'improve the pipeline' or 'wake the executor' is NOT a diagnosis — it must point to a specific code path, config line, or procedural gap.

This is a PIPELINE-FIXING initiative: any fix it implements to the pipeline MUST adhere to the cookbook (checked automatically per fix during the Albus bypass, verdicts recorded as decisions).

=== DECISION REQUIRED BEFORE RETRIGGER (cookbook 457) ===

After diagnosis, record a BYPASS DECISION. Answer this EXACT question: "Will an Albus bypass focused on pipeline wiring enable this initiative to succeed on retrigger?"

Format your decision as: Albus RSI bypass troubleshooting decision: YES — [what wiring fix makes retrigger succeed] OR Albus RSI bypass troubleshooting decision: NO — [what blocks this from pipeline-scope]

=== BYPASS HARNESS (cookbook 457) — if decision is YES ===

Your bypass is a SURGICAL, PIPELINE-ONLY fix. You may ONLY:

• Fix pipeline WIRING: broken URLs, missing channel IDs, faulty gates,

race conditions, skill-to-phase mapping errors, dispatch queue issues.

• Take SUPPORTIVE actions: register missing droids, update skills,

seed missing cookbook entries, clear stuck queue rows.

• Write code ONLY in shared/, agents/, or apps/initiatives/ — never in services/ or apps//.

You may NEVER:

• Do the initiative's actual work (that is Merlin's team: Sage, Archon, Forge, Argus, Radagast).
• Write feature code, design UI, build components, run product tests, or generate content.
• Circumvent the planner to ship product changes through a bypass.

If the fix requires product work, decision MUST be NO and the initiative escalates. If decision is YES, your bypass must touch ONLY pipeline infrastructure files.

⚖️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): CAROL-INI-2627-00 remains blocked due to an auto-detected failed process: App Watchdog (app-watchdog-01). The RSI pipeline has not yet recorded a diagnosis or fix for this specific block, and a previous attempt (CAROL-INI-2777-00) was closed without resolving it. The live system shows the App Watchdog is still running, so the block is likely a false or transient failure requiring diagnosis. (elrond)
• Gap H REFUSED (INI-634): target INI 999901240 is status='blocked', expected 'parked' (invariant 2). Operator triage required. (elrond.handover_watchdog)
• Gap H REFUSED (INI-634): target INI 999901240 is status='blocked', expected 'parked' (invariant 2). Operator triage required. (elrond.handover_watchdog)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• Remediates INI-999901240: Orion bypass opened to remediate this blocked/closed parent. — CAROL-INI-696 linkage: this bypass is the operator-driven remediation of a previously-blocked-or-closed initiative. target_initiative_id set on this row; canonical Orion remediated: row will land on the parent at bypass_end. (shared.bypass.bypass_start)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [status-router] reviewing -> closed | event=diagnosis_complete | RSI diagnosis complete by Albus on INI 999901240. Root cause: [procedural, confidence high] The step-review orchestration in planner-mode initiatives fails to reliably wake the Albus architect for step review because the wake mechanism lacks a health check and r (el-rsi-loop-01)

✅Success criteria

• The same pipeline defect stops blocking work: after this initiative, CAROL-INI-2627-00 and other initiatives hitting this cause flow through the planner instead of blocking again (must_have)
• An operator reading CAROL-INI-2627-00 sees a recorded explanation of why it blocked and exactly what pipeline change fixes it, rather than an unexplained block (must_have)
• The pipeline stays correct after the fix: a viewer of the initiative sees a recorded check that the shipped pipeline change follows Carol's cookbook (must_have)