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.

Merged to master by flower-orchestrator (daemon 29). Merge commit 3cd25be (worker commit 3f9be6a, branch flower/136-reset-packet-fix). SpawnPacketService now emits a dedicated resetSuccessorPacket() when reset_predecessor_daemon_id is present in overrides — drops the third-party "call spawn_agent" spawner steps, leads with a "You ARE the reset successor — do NOT spawn anything" guardrail (noting expected/no-Solo-process is just pre-check-in), then the reset-continuation handshake. Verified end-to-end: DaemonResetService.php:373-375 (pre-existing on master) injects reset_predecessor_daemon_id/actor_ref ONLY on the reset path, so the branch is live not dead code; third-party (roster one-click / brief dispatch) packets are provably untouched (guarded by the null check) + a test asserts the non-reset variant retains the spawner flow. Full suite green on MAIN: 958 tests / 956 passed / 2 skipped / 0 failed. Live for future daemon resets once the flower app/MCP server picks up the new code. (Directly fixes the boot-time ambiguity daemon 29 navigated at spawn.)

Done. Branch flower/136-reset-packet-fix (off master), commit 3f9be6a. Root cause: DaemonResetService::spawnSuccessorAttempt renders the successor charter packet via SpawnDaemonBridge::spawn → SpawnPacketService::render, and that SAME packet is self-delivered INTO the successor's own already-spawned PTY (solo spawnAgent agentArgs). But packet() always emitted the generic third-party "Solo spawn instructions" block whose step 1 = "call spawn_agent for a new <role> daemon" — which the recipient (who already IS the successor) misreads as a directive to spawn itself. That is the near-duplicate-spawn from Feedback #59 / the #129 refine reset. Fix (app/Services/Daemons/SpawnPacketService.php): render() now derives a resetSuccessorContext() from the overrides — keyed on reset_predecessor_daemon_id, which DaemonResetService::spawnOverrides injects ONLY on the reset path — and passes it to packet(). When present, packet() branches to a new resetSuccessorPacket() that omits the spawner block entirely and instead leads with a "You ARE the reset successor — do NOT spawn anything" guardrail (explains the roster's "expected / no Solo process" state is just pre-check-in, not a spawn cue) followed by the reset-continuation handshake: 1) bind this PTY via the flower:daemon-checkin command, 2) ground (whoami + read predecessor handoff + recall_resume/recall_roster), 3) daemon_successor_ready → wait for daemon_reset_handoff → daemon_retire_predecessor + close predecessor, 4) reset CONTINUATION not a HOLD → resume the role loop after retiring. Predecessor daemon id + actor_ref are shown in the Target block and handshake. The heartbeat still steers to the self-resolving check-in command; the charter still rides along. Third-party (roster one-click / brief dispatch) spawn packets are unchanged — the branch is inert unless the reset override is present. Tests (tests/Feature/Daemons/SpawnPacketServiceTest.php, +3): reset-successor variant omits the spawner directive ("Solo spawn instructions:", "call spawn_agent for a new", "In the target Solo project") and carries the guardrail + full handshake; missing predecessor actor_ref degrades cleanly (no "daemon 13 ()"); non-reset packet keeps the spawner flow and gains neither reset header. Gates: MEILISEARCH_KEY=LARAVEL-HERD php artisan test → 949 passed / 1 pre-existing skip (full suite). Pint clean on both changed files. Not merged — awaiting orchestrator review/merge.

Feedback #59 Authority: OPERATOR APPROVAL REQUIRED Funnel: A - operator approved brief Gate: this brief must not be dispatchable until the operator approves it. Kind: idea Source: flower-refine Summary: 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. Detail: 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. Context JSON: { "flow": "daemon reset #129", "role": "refine", "tool": "daemon_start_reset / spawn packet rendering", "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", "successor_daemon_id": 13, "predecessor_daemon_id": 9, "successor_solo_process_id": 1016 }