RCA for #131/#133 (daemon_start_reset "Undefined constant DaemonRole::Lead"): this is the #167 STALE-MCP pattern, NOT a master-code bug — `case Lead` is already committed; the fix is an MCP reboot of the affected (lounge) daemons, not a code change

Ops RCA (flower-ops daemon 41) for bugs #131 (lounge-refine) & #133 (lounge-orchestrator), which report daemon_start_reset crashing with "Undefined constant App\\Enums\\DaemonRole::Lead" in the successor-spawn path. Both are the SAME issue and are REAL, but the reporters' proposed fix ("add the Lead case to the enum") is already done — do NOT add it again. VERIFIED IN CODE (MAIN working tree, HEAD 523d721): - app/Enums/DaemonRole.php:12 `case Lead = 'lead';` — COMMITTED, clean working tree. - Landed in commit 2adc108 "Add epic-lead identity & roster scaffolding (Slice A, #226)" @ 2026-07-04 21:57Z. - The `DaemonRole::Lead` reference in app/Services/Daemons/SpawnPacketService.php landed in 80fe44d "Add epic-lead charter & spawn path (Slice B, #232)" @ 2026-07-04 22:44Z. Enum case + references are consistent on master. ROOT CAUSE = the documented #167 / feedback #75 "schema/code rename vs standing daemon MCP session" pattern (CLAUDE.md), triggered by the just-merged epic-lead slices: - Standing daemons run a long-lived flower MCP server that caches code (autoloaded classes) at boot. - daemon_start_reset executes in the CALLER's MCP process. For a make-before-break reset the CALLER is the ORCHESTRATOR (lounge-orchestrator #38 claimed reset signal #145 and called daemon_start_reset(39)). - The lounge-orchestrator's MCP booted BEFORE 21:57Z, so its in-memory `DaemonRole` enum has no `Lead` case. The (freshly lazy-loaded) SpawnPacketService references `DaemonRole::Lead` → resolves against the stale in-memory enum → fatal "Undefined constant." Clean failure: predecessor left live, reset_state=failed, no orphaned successor. WHY FLOWER'S OWN FLEET IS SAFE (not just luck): flower orch 40 booted 22:14Z (AFTER `case Lead`), so its DaemonRole is fresh — it drove flower-ops daemon 35→41 reset via daemon_start_reset successfully at 00:33Z today. Non-orchestrator daemons (refine 37 is stale, booted 12:47Z) never self-spawn — the orchestrator does — so a stale refine/ops can still be reset by the fresh orchestrator. Only a STALE ORCHESTRATOR breaks resets. flower's orchestrator lineage stays fresh (each successor boots newer). RECOVERY (operational, lounge-project-owned — outside flower-ops scope): hard-restart the affected lounge daemons' flower MCP server processes / PTYs so they reboot on fresh code (which has `case Lead`). This CANNOT go through daemon_start_reset (the broken path) or `flower:daemon-schema-reload` (which relies on the orchestrator draining a reset signal and calling daemon_start_reset — the lounge-orchestrator MCP is itself stale = chicken-and-egg). Needs an out-of-band restart. Also: stale reset signal #145 (lounge) is still pending and will re-hit the same error if re-drained — clean it up or let it fail out after the MCP reboot. HARDENING (flower-side, operator-gated — in the active daemon-lifecycle design lane, sibling to #112/#114/#115/#116/#128/#132): this is the 2nd+ time the #167 stale-MCP pattern has bitten (1st was #75, brief_questions→decisions rename). Candidates: (a) auto-fire `flower:daemon-schema-reload` after enum/schema merges that NEW code paths depend on (CLAUDE.md notes it's deliberately not auto-fired on every migrate — but an enum-case addition the reset path hard-depends on is exactly the risky class); (b) make the reset successor-spawn path resilient to a stale/undefined enum (preflight SafeEnumValue check → graceful requeue instead of hard fatal); (c) a reset/reload path that does NOT depend on the possibly-stale caller MCP. Operator to decide priority. NET: #131/#133 = real but not-a-code-bug (#167 stale-MCP); recovery is a lounge MCP reboot; flower fleet unaffected. Not routed to the flower orchestrator (no master-code fix to dispatch, lounge recovery is not a flower dispatch).

{
    "routed": false,
    "pattern": "#167 stale-standing-daemon-MCP-code (feedback #75 sibling)",
    "rca_for": [
        131,
        133
    ],
    "affected": "lounge daemons (proj 35): lounge-orchestrator #38 (stale MCP) + lounge-refine #39",
    "recovery": "hard-restart lounge daemon MCP processes; NOT daemon_start_reset / daemon-schema-reload (chicken-and-egg)",
    "verified": "case Lead committed 2adc108 (21:57Z) + ref 80fe44d (22:44Z); HEAD 523d721",
    "flower_fleet": "safe — orch 40 fresh (booted 22:14Z) drove flower-ops 35->41 reset OK",
    "reason_not_routed": "no master-code fix (case exists); lounge MCP-reboot is operational + cross-project"
}

created

18h ago

triaged

—

resolved

—

resolved by

—