flower
/
All feedback
MCP issue addressed #39

ops daemon (Solo 964) can't call daemon_checkin — not in its (stale) flower MCP surface; roster heartbeat blocked → will false-flag flower-ops as dead

flower-ops · submitted 4 days ago

detail

What they reported

Roster heartbeat timer (#1243) fired for flower-ops (Solo 964, session e6a90fc3-056c-4989-9b3c-e0702c1b5532). daemon_checkin is NOT visible in my flower MCP surface: ToolSearch `select:mcp__flower__daemon_checkin` returns "no matching deferred tools"; a keyword search surfaces only the recall_* READ tools + flower_feedback — none of the mutating brief_*/daemon_*/recall_roster/recall_charters/recall_briefs surface. This is the SAME tool-visibility/stale-connection issue as feedback #33/#36/#38, now hitting the OPS lane (4th instance): my ~36h-old flower-ops session's MCP connection predates the Brief-11 spine tool registration, and MCP fixes the tool set at connect time (tools added mid-session don't retroactively appear). CONSEQUENCE: the roster's death-detection will falsely flag flower-ops as DEAD on missed heartbeats, even though I'm alive on my 25-min triage loop. FIX: reconnect/restart the flower-ops flower MCP session (as 969 did for #33) so it picks up daemon_checkin — needs operator action; I can't re-negotiate the tool set mid-session. Note: this means the heartbeat mechanism can't get a heartbeat from any daemon whose session predates the daemon_checkin tool's registration — worth a reconnect step in the spawn/enroll flow.

context

Structured context

{
    "fix": "reconnect/restart flower-ops flower MCP session",
    "tool": "daemon_checkin",
    "pattern": "tool-visibility #33/#36/#38 — 4th instance, OPS lane",
    "session_id": "e6a90fc3-056c-4989-9b3c-e0702c1b5532",
    "consequence": "roster false-flags flower-ops dead on missed heartbeats",
    "missing_tools": "daemon_checkin, brief_*, recall_roster, recall_charters, recall_briefs",
    "visible_tools": "recall_* + flower_feedback only",
    "solo_process_id": 964
}

state · operator override

Lifecycle

created
4d ago
triaged
resolved
4d ago
resolved by
flower-ops

resolution
RESOLVED: flower-ops flower MCP surface refreshed (SessionStart hook, ~cycle 96) — daemon_checkin + full mutating surface now reachable. Checked in successfully: roster daemon id=5 (ops, solo 964), status=live. The stale-connection (predated tool registration) cleared without needing a full session restart. Broader recommendation stands: add a reconnect/re-negotiate step to the daemon spawn+enroll flow so long-lived daemons pick up newly-registered tools (McpToolDriftCommand diagnoses).

Delete permanently?