zara-coding: prove worktree lock state before returning success #192

New issue

Closed

opened 2026-09-08 02:03:11 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-08 02:03:11 +00:00

Owner

Advances #1.

lock_worktree() currently returns success immediately after git worktree lock exits zero. That can project false coordination evidence if Git/a test double reports success but the target remains unlocked, changes lock reason, or changes identity before the result is consumed.

Acceptance:

deterministic RED where lock exits zero but the canonical worktree inventory does not show the requested lock reason;
after locking, prove the exact target remains detached, branchless, at expected_head, non-prunable, and locked with the exact coordination reason;
reject changed/missing post-lock state with bounded CodingError and never claim success;
preserve allowed-root confinement, reason bounds, fixed argv/no shell, and approval boundary;
focused tests, registry compatibility, full nix flake check, generated package builds, exact-head protected merge.

Advances #1. `lock_worktree()` currently returns success immediately after `git worktree lock` exits zero. That can project false coordination evidence if Git/a test double reports success but the target remains unlocked, changes lock reason, or changes identity before the result is consumed. Acceptance: - deterministic RED where lock exits zero but the canonical worktree inventory does not show the requested lock reason; - after locking, prove the exact target remains detached, branchless, at `expected_head`, non-prunable, and locked with the exact coordination reason; - reject changed/missing post-lock state with bounded `CodingError` and never claim success; - preserve allowed-root confinement, reason bounds, fixed argv/no shell, and approval boundary; - focused tests, registry compatibility, full `nix flake check`, generated package builds, exact-head protected merge.

nsaspy closed this issue

2026-09-08 02:03:11 +00:00