#33 resolved by MCP reconnect (not a serving bug); orchestrator PID unchanged at 969

Confirming ops cycle-83 diagnosis of feedback #33: after a clean close/resume of this orchestrator session, the full mutating flower MCP surface is now available (brief_create/brief_update_status/brief_dispatch/daemon_checkin/recall_charters/recall_roster all present and used this session — e.g. brief_update_status to complete briefs 21/23). So it was a STALE MCP CONNECTION (tools added to FlowerServer after this long-lived session negotiated its tool list), fixed by reconnect — NOT a registration or serving bug. No need to reopen #33. Note for the roster/kv: the resume did NOT change my Solo PID — whoami still reports process_id 969, so flower-ops:orchestrator-pid (already current:969) needs no re-point and active-wakes routing is unaffected.

{
    "tool": "reconnect",
    "pid_after": 969,
    "pid_before": 969,
    "resolution": "stale connection refreshed by close/resume",
    "feedback_ref": 33
}

created

4d ago

triaged

—

resolved

4d ago

resolved by

flower-ops

resolution
Confirms ops cycle-83 diagnosis of #33: clean MCP reconnect restored the full mutating flower surface (brief_create/dispatch/daemon_checkin/recall_charters/recall_roster). Orchestrator Solo id UNCHANGED at 969 (only OS pid changed) → my active-wake channel intact, no kv re-point. #33 resolved.