[Deep-Sixed]

Summary

Fixes the review items that decide who may authorize and what happens to filesystem state when ownership moves. PR #9 (the receive transaction boundary) and the scope enforcement in PR #10 are left to those PRs.

Review finding	Status here
Agents can approve their own operation (P1)	Fixed
Expired reclaim / takeover breaks with an existing local worktree (P1)	Fixed
Agent/repo names can escape the worktree directory (P1/P2)	Fixed
Verify governance-critical triggers, not just tables/migrations	Partly: the new and existing governance triggers are now part of the contract

Approval authority

Before this change, gate.vote() checked only that the voter was a registered agent, and the requester set --threshold (default 1). A worker could therefore request and approve its own push.

• Roles. Each agent has one role: worker (the default), reviewer, or operator.
• Repository policy. Each repository owns approval_threshold, its approving roles, and requester_may_vote. The defaults are 1, operator, and no. approve request --threshold is removed; the threshold is recorded on the instance for display only.
• Voting. Only agents whose role the policy names may vote, yes or no. The requester may not vote unless the policy allows it. The agent a takeover would benefit may never vote on it.
• Consumption. An agent that voted yes on an operation can never carry it out, whether by pushing or by taking over. The gate refuses this, and so does a database trigger.
• Re-checked at use time. Consumption recomputes eligible votes from current roles and policy. Raising the threshold or demoting an approver therefore invalidates approvals that no longer meet the policy.
• Administration. Registering a non-worker, changing a role, and changing policy all require an operator. The exception is bootstrap: while no operator exists, anyone can designate the first one. The last operator cannot be demoted. All of these changes are audited.
• Database enforcement. Migration 004_approval_authority.sql adds triggers for vote eligibility (on insert and update), approvals naming a registered repository, and consumer ≠ approver. verify_contract now fails if any governance trigger is missing.
• CLI. New commands agent add --role, agent role <name> <role>, and repo policy <name> [--threshold] [--role]… [--[no-]requester-may-vote]. agent list now shows roles.

Upgrade behavior (fails closed). Existing agents become workers and existing repositories get the default policy. Old approvals, self-approvals included, stop authorizing anything until an eligible operator votes on a new request. The README tells operators to run quorumgit agent role <name> operator after init.

Worktree continuation

A claim that replaces an earlier claim on the same task and branch no longer tries to create a second checkout, which Git would refuse. This covers lease expiry, an approved takeover, and release without --remove-worktree. Instead, trees.continue_or_create_worktree checks the retained checkout's repository, root, and branch (the same check doctor uses, now factored out), moves it to the new claim with any uncommitted work, and records worktree.continued.

• A retained checkout from a different task is never adopted. The claim is refused with a clear message instead of Git's raw "already checked out" error.
• A drifted checkout (wrong branch, detached HEAD, or a different repository) is also refused. The claim rolls back entirely.
• If the recorded directory no longer exists, a fresh worktree is created, as before, and doctor reports the stale record.

Worktree paths

Managed paths are now worktrees/repo-<id>/claim-<id>-<random>. Agent and repository names no longer appear in paths, so a name like ../../x cannot move a checkout outside the managed directory. The random suffix stops a leftover directory from blocking a later claim that reuses the rowid of a rolled-back one.

CLI connection lifecycle

Every CLI command now runs inside store.session(). It keeps the connection context manager's commit/rollback behavior and then closes the connection deterministically. (The Windows 0xC0000005 crashes seen earlier on this PR were a libSQL 0.1.11 double-close bug; PR #14's move to sqlite3 removed it. Details are in the PR comments.)

Interaction with other PRs

• Reserve exact Git mutations until receive completion #9: the migration is numbered 004 to avoid Reserve exact Git mutations until receive completion #9's 003_git_mutations.sql. Reserve exact Git mutations until receive completion #9's receive._policy_for_update should pass consumer=pusher["name"] to gate.approved_instance. Otherwise an approver who pushes passes pre-receive, and post-receive then refuses to consume after Git has already moved the ref. Reserve exact Git mutations until receive completion #9's tests request and vote as the same agent, so they need this PR's tests/conftest.py::approve fixture. Its new hook post-receive command should use store.session.
• Bind push authorization to Git's ref transaction; scope enforcement and full schema contract #10 (open, another session) also fixes self-approval and worktree reclaim. The plan is to merge this PR first and carry Bind push authorization to Git's ref transaction; scope enforcement and full schema contract #10's scope fixes onto it.

Validation

• python -m pytest -q: 122 passed on the current head (merged with main through PRs Ignore removed worktrees in handoff and checkpoint #13, Use standard-library SQLite 3 for the store instead of libSQL #14 and Fix pre-existing ruff lint findings #15)
• The 26 new approval and worktree tests fail against the original main source
• pyright: 0 errors, 0 warnings
• ruff check src tests: clean

New tests are in tests/test_approval_authority.py, tests/test_worktree_continuation.py, and tests/test_store.py (session commit/rollback/close).

🤖 Generated with Claude Code

https://claude.ai/code/session_01SrukvuPz7kpbore3kkKpQ3

[Deep-Sixed]

CI note on 1ad1f7e: windows-latest / Python 3.11 failed in test_governed_takeover_continues_incumbent_worktree. The failure is the test's first quorumgit claim subprocess exiting with 3221225477 (0xC0000005, access violation) and empty stdout and stderr. That means the native libSQL extension crashed. It isn't a Python exception or a governance refusal.

Why I don't think this is a logic failure in this PR:

• Ubuntu 3.11, Ubuntu 3.14 and macOS 3.11 pass all 117 tests.
• On the same Windows runner, the previous test in the same file, test_reclaim_after_expiry_continues_retained_worktree, made an identical first claim call after identical setup (register repo, add agents, create task, commit), and it passed.
• The crashing call is a plain first claim. It doesn't reach the takeover or continuation code this PR adds.

I can't reproduce Windows from this environment and haven't found a root cause, so I'm not calling it a flake. I'll re-run the failed job once when the rest of the run finishes; GitHub refused the re-run while macOS 3.14 is still in progress. If the crash comes back, I'll treat it as real and make the CLI's libSQL connection lifecycle explicit (close each connection deterministically, not by garbage collection), then re-test.

---

Generated by Claude Code

[Deep-Sixed]

Follow-up on the Windows crash: the one re-run of windows-latest / Python 3.11 failed again with the same 0xC0000005 and empty output, this time in approve vote (test_cli_votes_by_approval_instance_id, which has passed on Windows on main) and agent role. The claim test that crashed the first time passed. That makes it a real, intermittent crash in the CLI child process, not a flake, and more likely the more CLI subprocesses the suite starts. It doesn't reproduce on Linux (15 back-to-back runs of the CLI-heavy test files all passed).

Pushed 52438c6 as the fix I proposed. libSQL's connection context manager commits or rolls back but never closes, so every CLI command left its native connection to be torn down implicitly. store.session() keeps the same transaction semantics and then closes the connection explicitly. All 25 CLI commands use it. I also added a regression test for the session's commit and rollback behavior. The next Windows run will show whether this is the root cause.

---

Generated by Claude Code

[Deep-Sixed]

Root cause of the Windows 0xC0000005 crashes, for the record: it was a bug in libSQL 0.1.11, not in this PR's code.

• With faulthandler on, the crash was in Connection.close().
• Under Valgrind on Linux, every libSQL connection teardown reads freed memory. Dropping the inner LibsqlConnection calls sqlite3Close and frees the handle, then the outer Connection's drop calls sqlite3Close again on it ("Invalid read … inside a block of size 848 free'd by sqlite3Close"). main's code at the time did the same. Linux tolerates the stray read; Windows sometimes faults on it. This PR runs more CLI subprocesses in its tests, which is why the crash started showing up. 0.1.11 is the newest libSQL release, so there was no upgrade to take.

PR #14 has since replaced libSQL with the standard-library sqlite3 module, which removes the bug. b09c847 merges that main into this branch and reverts my libSQL-specific workaround (c5ba900, keeping connections alive and exiting via os._exit) and the faulthandler diagnostic. store.session() stays, rebuilt on sqlite3: the CLI still closes each command's connection deterministically. Trigger-abort tests now expect sqlite3.IntegrityError. Locally: 120 passed, pyright and ruff clean.

---

Generated by Claude Code