zara-coding: create detached worktrees already coordination-locked #454

Open
nsaspy wants to merge 0 commits from rage/1-zara-coding-worktree-add-locked into main
Owner

Advances #1 with a one-approval worktree creation primitive for coding-task coordination.

RAGE transaction

  • RED-first 5a0c818: define exact add→revalidate→lock behavior and failure semantics.
  • implementation 2378a23 + 2077f8b; tool-surface contract 3a7fa1e.

Contract

  • adds approval-gated coding.git.worktree.add-detached-locked
  • creates only a detached worktree at a caller-supplied full commit ID inside configured roots
  • immediately re-reads registered worktree evidence and requires the exact expected HEAD before locking
  • uses bounded/control-free lock reasons and fixed argv with shell=false
  • does not create/move branches, force Git operations, or claim success if the post-create lock precondition fails

Adversarial boundary

This reduces the gap between worktree creation and coordination locking to one authorized tool call, but Git lock reasons remain observable coordination metadata rather than identity/authentication. Canonical Zara approval is still the authority. Strong principal/worker ownership remains part of task-state composition blocked on Zara Core #400.

Exact-head CI must pass compatibility contract, registry/plugin nix flake check, and package builds before merge.

Advances #1 with a one-approval worktree creation primitive for coding-task coordination. ## RAGE transaction - RED-first `5a0c818`: define exact add→revalidate→lock behavior and failure semantics. - implementation `2378a23` + `2077f8b`; tool-surface contract `3a7fa1e`. ## Contract - adds approval-gated `coding.git.worktree.add-detached-locked` - creates only a detached worktree at a caller-supplied full commit ID inside configured roots - immediately re-reads registered worktree evidence and requires the exact expected HEAD before locking - uses bounded/control-free lock reasons and fixed argv with `shell=false` - does not create/move branches, force Git operations, or claim success if the post-create lock precondition fails ## Adversarial boundary This reduces the gap between worktree creation and coordination locking to one authorized tool call, but Git lock reasons remain observable coordination metadata rather than identity/authentication. Canonical Zara approval is still the authority. Strong principal/worker ownership remains part of task-state composition blocked on Zara Core #400. Exact-head CI must pass compatibility contract, registry/plugin `nix flake check`, and package builds before merge.
Some checks failed
CI / test (pull_request) Failing after 16s
This branch is already included in the target branch. There is nothing to merge.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin rage/1-zara-coding-worktree-add-locked:rage/1-zara-coding-worktree-add-locked
git switch rage/1-zara-coding-worktree-add-locked

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main
git merge --no-ff rage/1-zara-coding-worktree-add-locked
git switch rage/1-zara-coding-worktree-add-locked
git rebase main
git switch main
git merge --ff-only rage/1-zara-coding-worktree-add-locked
git switch rage/1-zara-coding-worktree-add-locked
git rebase main
git switch main
git merge --no-ff rage/1-zara-coding-worktree-add-locked
git switch main
git merge --squash rage/1-zara-coding-worktree-add-locked
git switch main
git merge --ff-only rage/1-zara-coding-worktree-add-locked
git switch main
git merge rage/1-zara-coding-worktree-add-locked
git push origin main
Sign in to join this conversation.
No description provided.