Review round 2 (codex):
- R1: register_job reads .mam/reset-in-progress under the registry lock and
refuses while a reset of the workspace owning <ws>/.mam/jobs is live, so the
public registry.py register CLI and the API no longer bypass the gate. The
reset's precheck takes that lock once after publishing its marker, so a
registration is either seen by it or refused. The reset's own create passes
MAM_RESET_OWNER_PID; the remote runner refuses the dispatch.
- R2: before each purge the reset re-runs stop's revalidate check
(verify_session_uuid) for a post-discovered id against the row's folder and
skips the target (id not verified) when it does not verify.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A shared take also showed `pane_lock acquire --fd 7` for an instant, so the
test passed with the old shared admission; it now matches the exclusive
argv and checks the reset is still waiting a second later.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review round 1 of PR #82:
- A running claude/grok row without a recorded id is refused by the
precheck (stop would fill it with a folder-wide guess the purge then
deletes); record-id never records a pre-assigned guess, and a target is
skipped (id_unverified) when the row's id after the normal stop is not
the one recorded before it.
- reset takes the update admission lock exclusively while it publishes
.mam/loop-guard-active and .mam/reset-in-progress; delegate submit
refuses on a live reset marker (mam_reset_admit). Before each target's
stop its open jobs are re-read (skipped as open_job, never cancelled),
and a row whose agent/server no longer matches the spec is skipped.
- read_spec validates every stored field (herdr_server required, never
defaulted) and rejects duplicate names.
- Signal tests wait 60 s for the kill-session gate (this Mac needs ~18 s).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
GodopuandClaude Opus 5.5