📖About

RSI diagnosis (CAROL-INI-2223b/2246, cookbook 456): Albus root-causes WHY CAROL-INI-2723-01 (row 999901567, 'CAROL-INI-2723-01: Auto-detected stuck process: Step Planner (SP-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

• Filing escalated by the security gate (CAROL-INI-1973) — {"authorization": {"ok": true, "reason": "holds file_initiative permission via ['owner', 'support']"}, "role_alignment": {"ok": true, "reason": "Albus's role includes preflight risk detection and execution-environment troubleshooting. Diagnosing a stuck pipeline step via RSI is squarely within this remit."}, "policy_compliance": {"ok": false, "reason": "Violates policy 'No agent switching - every process runs as its own OS identity': initiatives must be owned by an agent who will do the work through droids, but the title 'Albus root-causes ...' impli"}} (el-sg-01)
• [status-router] planned -> redirected | event=security_gate | Security gate failed: policy violation: Violates policy 'No agent switching - every process runs as its own OS identity': initiatives must be owned by an agent who will do the work through droids, but the title 'Albus root-causes ...' impli (el-sg-01)
• [status-router] redirected -> executing | event=bypass_executing | bypass transition (or-bx-01)
• Remediates INI-999901567: 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 -> closed | event=operator_put | PUT /api/initiatives (operator)
• [status-router] executing -> closed | event=operator_put | PUT /api/initiatives (operator)
• Handover-watchdog: reviewer-pending nudge for phase 1 (auto-invoked Elrond reviewer). (elrond)
• Handover-watchdog: reviewer-pending nudge for phase 1 (auto-invoked Elrond reviewer). (elrond)
• [status-router] closed -> discarded | event=diagnosis_complete | diagnosis attempt retired (diagnosis complete) — findings live as decisions on the target (CAROL-INI-2887) (al-rsi-diag-01)
• [status-router] discarded -> closed | event=diagnosis_complete | RSI diagnosis complete by Albus on INI 999901567. Root cause: [procedural, confidence high] The IR-S1 reviewer's _kickstart_phase_2 function in /home/caroladmin/dev/agents/agt_011/droids/ir_s1.py unconditionally creates a rework plan step and transitions the ini (el-rsi-loop-01)