From phase 3b (documented at ceremony.rs issue_and_deliver / :719). Two concurrent zeroclaw control register-client runs are a read-modify-write on clients.json with no lock: the later save wins, dropping the earlier registration while its delivered credential file survives on disk authenticating nothing. The server-side host.lock added in the transport work does NOT close this — the ceremony is a separate process. Fix: take an exclusive registry lock in run_register_client (and run_genesis's client step), which needs a stale-lock policy decision. Low real-world likelihood (interactive, single-operator) but a correctness gap. Part of #35, relates to #29.
From phase 3b (documented at ceremony.rs issue_and_deliver / :719). Two concurrent
zeroclaw control register-clientruns are a read-modify-write on clients.json with no lock: the later save wins, dropping the earlier registration while its delivered credential file survives on disk authenticating nothing. The server-side host.lock added in the transport work does NOT close this — the ceremony is a separate process. Fix: take an exclusive registry lock in run_register_client (and run_genesis's client step), which needs a stale-lock policy decision. Low real-world likelihood (interactive, single-operator) but a correctness gap. Part of #35, relates to #29.