Reset-successor spawn packet reuses the third-party "call spawn_agent" instructions when self-delivered into the successor's own PTY — nearly caused a duplicate-agent spawn.

During the #129 make-before-break refine reset (predecessor daemon 9 → successor daemon 13 / Solo proc 1016), the reset-successor spawn packet rendered by daemon_start_reset was delivered INTO the successor's own already-spawned PTY. The packet's top "Solo spawn instructions" block (step 1: "In the target Solo project for flower, call spawn_agent for a new refine daemon") reads as a directive to the RECIPIENT to spawn a new agent — but the recipient already IS the successor. whoami showed proc 1016 = daemon 13; the roster showed daemon 13 as "expected / no Solo process" ONLY because it had not checked in yet, which compounds the misread. Near-miss observed twice independently: (1) on first read I concluded my job was to spawn the successor PTY ("create the successor's Solo PTY"); (2) predecessor daemon 9 sent an URGENT CORRECTION ("do NOT call spawn_agent; THIS process already IS the successor"). A grounding whoami is what caught it before any spurious spawn — but the packet should not depend on that. Suggested fix: when daemon_start_reset renders a packet for a reset SUCCESSOR (self-delivered), do NOT reuse the generic third-party-spawner instructions. Lead with an explicit reset-continuation header, e.g.: "You ARE the reset successor (Solo proc <id> = daemon <id>); it shows 'expected' only because you have not checked in yet. Do NOT call spawn_agent. First action: run the check-in command to bind this PTY to daemon <id>, then the reset handshake: read predecessor handoff → daemon_successor_ready → wait for daemon_reset_handoff → daemon_retire_predecessor + close predecessor. This is a reset continuation — resume the refine loop after retiring, not a HOLD." Even a single guardrail first line ("you ARE the successor; check in, do not spawn") would eliminate the hazard.

{
    "flow": "daemon reset #129",
    "role": "refine",
    "tool": "daemon_start_reset / spawn packet rendering",
    "routed": {
        "target": "brief",
        "brief_id": 136,
        "authority": "operator_approval",
        "routed_at": "2026-07-03T13:16:50+00:00",
        "routed_by": "operator:mike",
        "project_id": 16,
        "approved_at": "2026-07-04T03:21:27+00:00",
        "approved_by": "operator:mike",
        "approval_status": "approved",
        "default_project_id": 16,
        "needs_operator_approval": false
    },
    "observed": "packet's third-party spawn_agent instructions misread as a directive to spawn a NEW agent; near-duplicate-spawn averted by whoami + operator/predecessor correction",
    "promotion_ledger": [
        {
            "at": "2026-07-03T13:16:50+00:00",
            "action": "brief_created",
            "target": "brief",
            "brief_id": 136,
            "actor_ref": "operator:mike",
            "cycle_key": "2026070313"
        },
        {
            "at": "2026-07-04T03:21:27+00:00",
            "action": "approved",
            "target": "brief",
            "brief_id": 136,
            "actor_ref": "operator:mike"
        },
        {
            "at": "2026-07-04T08:20:34+00:00",
            "action": "source_brief_completed",
            "target": "brief",
            "brief_id": 136,
            "actor_ref": "flower-136-reset-packet-worker"
        }
    ],
    "successor_daemon_id": 13,
    "predecessor_daemon_id": 9,
    "successor_solo_process_id": 1016
}

• complete #136 Feedback #59: Reset-successor spawn packet reuses the third-party "call spawn_agent" instructions when self-delivered into the successor's own PTY — nearly caused a duplicate-agent spawn.

created

2d ago

triaged

2d ago

resolved

1d ago

resolved by

flower-136-reset-packet-worker

resolution
Brief #136: Feedback #59: Reset-successor spawn packet reuses the third-party "call spawn_agent" instructions when self-delivered into the successor's own PTY — nearly caused a duplicate-agent spawn.