Replace a sidecar still running superseded code

[Castrozan]

What was wrong

reconcile_one_sidecar_process asked pgrep for the sidecar's match pattern and, finding anything alive, returned without spawning. The pattern deliberately carries no store path, so a bridge launched from an older generation of bridge.py matches it exactly as well as the current one does.

A rebuild could therefore never put new bridge code on a running agent. Live evidence on chise: monster's bridge (pid 4193780, /nix/store/fx1wv2ds…-bridge.py) has run for two days across system generations 1618 to 1621. The media fix shipped in v0.12.5 would never have reached it.

What changed

spawn_sidecar_process records the command it launched beside the sidecar log (<log>.spawned-command). reconcile_one_sidecar_process compares that record to the desired command; on a mismatch it terminates every live process, waits for each to exit, then spawns the replacement.

The command string covers everything that can change: the bridge script's store path, the python environment, the one-shot turn command, the workspace and state directories.

A sidecar with no record at all counts as superseded, so the first reconcile after this change refreshes every bridge once and later reconciles leave it alone. No respawn loop.

Terminating and waiting before spawning keeps the replacement from holding the bot token at the same moment as the process it supersedes.

Verification

• nix build .#checks.aarch64-darwin.unit-tests green
• formatting and discord-transport-eval green
• 8 new tests in test_clawde_service_sidecar_process_supersession.py, including the exactly-once replacement for a sidecar predating the record and both bounds of the termination wait

[Castrozan]

What was wrong

reconcile_one_sidecar_process asked pgrep for the sidecar's match pattern and, finding anything alive, returned without spawning. The pattern deliberately carries no store path, so a bridge launched from an older generation of bridge.py matches it exactly as well as the current one does.

A rebuild could therefore never put new bridge code on a running agent. Live evidence on chise: monster's bridge (pid 4193780, /nix/store/fx1wv2ds…-bridge.py) has run for two days across system generations 1618 to 1621. The media fix shipped in v0.12.5 would never have reached it.

What changed

spawn_sidecar_process records the command it launched beside the sidecar log (<log>.spawned-command). reconcile_one_sidecar_process compares that record to the desired command; on a mismatch it terminates every live process, waits for each to exit, then spawns the replacement.

The command string covers everything that can change: the bridge script's store path, the python environment, the one-shot turn command, the workspace and state directories.

A sidecar with no record at all counts as superseded, so the first reconcile after this change refreshes every bridge once and later reconciles leave it alone. No respawn loop.

Terminating and waiting before spawning keeps the replacement from holding the bot token at the same moment as the process it supersedes.

Verification

• nix build .#checks.aarch64-darwin.unit-tests green
• formatting and discord-transport-eval green
• 8 new tests in test_clawde_service_sidecar_process_supersession.py, including the exactly-once replacement for a sidecar predating the record and both bounds of the termination wait

[Castrozan]

What was wrong

reconcile_one_sidecar_process asked pgrep for the sidecar's match pattern and, finding anything alive, returned without spawning. The pattern deliberately carries no store path, so a bridge launched from an older generation of bridge.py matches it exactly as well as the current one does.

A rebuild could therefore never put new bridge code on a running agent. Live evidence on chise: monster's bridge (pid 4193780, /nix/store/fx1wv2ds…-bridge.py) has run for two days across system generations 1618 to 1621. The media fix shipped in v0.12.5 would never have reached it.

What changed

spawn_sidecar_process records the command it launched beside the sidecar log (<log>.spawned-command). reconcile_one_sidecar_process compares that record to the desired command; on a mismatch it terminates every live process, waits for each to exit, then spawns the replacement.

The command string covers everything that can change: the bridge script's store path, the python environment, the one-shot turn command, the workspace and state directories.

A sidecar with no record at all counts as superseded, so the first reconcile after this change refreshes every bridge once and later reconciles leave it alone. No respawn loop.

Terminating and waiting before spawning keeps the replacement from holding the bot token at the same moment as the process it supersedes.

Verification

• nix build .#checks.aarch64-darwin.unit-tests green
• formatting and discord-transport-eval green
• 8 new tests in test_clawde_service_sidecar_process_supersession.py, including the exactly-once replacement for a sidecar predating the record and both bounds of the termination wait

[Castrozan]

What was wrong

reconcile_one_sidecar_process asked pgrep for the sidecar's match pattern and, finding anything alive, returned without spawning. The pattern deliberately carries no store path, so a bridge launched from an older generation of bridge.py matches it exactly as well as the current one does.

A rebuild could therefore never put new bridge code on a running agent. Live evidence on chise: monster's bridge (pid 4193780, /nix/store/fx1wv2ds…-bridge.py) has run for two days across system generations 1618 to 1621. The media fix shipped in v0.12.5 would never have reached it.

What changed

spawn_sidecar_process records the command it launched beside the sidecar log (<log>.spawned-command). reconcile_one_sidecar_process compares that record to the desired command; on a mismatch it terminates every live process, waits for each to exit, then spawns the replacement.

The command string covers everything that can change: the bridge script's store path, the python environment, the one-shot turn command, the workspace and state directories.

A sidecar with no record at all counts as superseded, so the first reconcile after this change refreshes every bridge once and later reconciles leave it alone. No respawn loop.

Terminating and waiting before spawning keeps the replacement from holding the bot token at the same moment as the process it supersedes.

Verification

• nix build .#checks.aarch64-darwin.unit-tests green
• formatting and discord-transport-eval green
• 8 new tests in test_clawde_service_sidecar_process_supersession.py, including the exactly-once replacement for a sidecar predating the record and both bounds of the termination wait

[Castrozan]

What was wrong

reconcile_one_sidecar_process asked pgrep for the sidecar's match pattern and, finding anything alive, returned without spawning. The pattern deliberately carries no store path, so a bridge launched from an older generation of bridge.py matches it exactly as well as the current one does.

A rebuild could therefore never put new bridge code on a running agent. Live evidence on chise: monster's bridge (pid 4193780, /nix/store/fx1wv2ds…-bridge.py) has run for two days across system generations 1618 to 1621. The media fix shipped in v0.12.5 would never have reached it.

What changed

spawn_sidecar_process records the command it launched beside the sidecar log (<log>.spawned-command). reconcile_one_sidecar_process compares that record to the desired command; on a mismatch it terminates every live process, waits for each to exit, then spawns the replacement.

The command string covers everything that can change: the bridge script's store path, the python environment, the one-shot turn command, the workspace and state directories.

A sidecar with no record at all counts as superseded, so the first reconcile after this change refreshes every bridge once and later reconciles leave it alone. No respawn loop.

Terminating and waiting before spawning keeps the replacement from holding the bot token at the same moment as the process it supersedes.

Verification

• nix build .#checks.aarch64-darwin.unit-tests green
• formatting and discord-transport-eval green
• 8 new tests in test_clawde_service_sidecar_process_supersession.py, including the exactly-once replacement for a sidecar predating the record and both bounds of the termination wait

[Castrozan]

What was wrong

reconcile_one_sidecar_process asked pgrep for the sidecar's match pattern and, finding anything alive, returned without spawning. The pattern deliberately carries no store path, so a bridge launched from an older generation of bridge.py matches it exactly as well as the current one does.

A rebuild could therefore never put new bridge code on a running agent. Live evidence on chise: monster's bridge (pid 4193780, /nix/store/fx1wv2ds…-bridge.py) has run for two days across system generations 1618 to 1621. The media fix shipped in v0.12.5 would never have reached it.

What changed

spawn_sidecar_process records the command it launched beside the sidecar log (<log>.spawned-command). reconcile_one_sidecar_process compares that record to the desired command; on a mismatch it terminates every live process, waits for each to exit, then spawns the replacement.

The command string covers everything that can change: the bridge script's store path, the python environment, the one-shot turn command, the workspace and state directories.

A sidecar with no record at all counts as superseded, so the first reconcile after this change refreshes every bridge once and later reconciles leave it alone. No respawn loop.

Terminating and waiting before spawning keeps the replacement from holding the bot token at the same moment as the process it supersedes.

Verification

• nix build .#checks.aarch64-darwin.unit-tests green
• formatting and discord-transport-eval green
• 8 new tests in test_clawde_service_sidecar_process_supersession.py, including the exactly-once replacement for a sidecar predating the record and both bounds of the termination wait

[Castrozan]

What was wrong

reconcile_one_sidecar_process asked pgrep for the sidecar's match pattern and, finding anything alive, returned without spawning. The pattern deliberately carries no store path, so a bridge launched from an older generation of bridge.py matches it exactly as well as the current one does.

A rebuild could therefore never put new bridge code on a running agent. Live evidence on chise: monster's bridge (pid 4193780, /nix/store/fx1wv2ds…-bridge.py) has run for two days across system generations 1618 to 1621. The media fix shipped in v0.12.5 would never have reached it.

What changed

spawn_sidecar_process records the command it launched beside the sidecar log (<log>.spawned-command). reconcile_one_sidecar_process compares that record to the desired command; on a mismatch it terminates every live process, waits for each to exit, then spawns the replacement.

The command string covers everything that can change: the bridge script's store path, the python environment, the one-shot turn command, the workspace and state directories.

A sidecar with no record at all counts as superseded, so the first reconcile after this change refreshes every bridge once and later reconciles leave it alone. No respawn loop.

Terminating and waiting before spawning keeps the replacement from holding the bot token at the same moment as the process it supersedes.

Verification

• nix build .#checks.aarch64-darwin.unit-tests green
• formatting and discord-transport-eval green
• 8 new tests in test_clawde_service_sidecar_process_supersession.py, including the exactly-once replacement for a sidecar predating the record and both bounds of the termination wait