docs(loop): R17 -- a tick owns its worktree and takes a claim - #3358
Merged
Conversation
…3357) Two sessions ran concurrently on 2026-09-06 sharing one checkout and one `target/`, and neither had a way to find out. Every symptom was attributed to the tool being measured: a commit that "did not form" while `git push` reported success (it pushed an unchanged HEAD), a built binary that lost a subcommand it had a minute earlier, census readings that flip-flopped between runs, and a HEAD sitting on a branch this session never created. That is the broken-ruler error with a second session as the ruler. R17 writes down what `tri loop claim` (#3332) made possible: own the tree, take the claim first, and do not diagnose a shared tree through the tree. It also records the trap found while following it. A private `CARGO_TARGET_DIR` -- the thing that makes the tree private -- hides the binary from `.githooks/pre-commit:52` and `.githooks/commit-msg:14`, which probe `$ROOT/target/{debug,release}/tri`. They report "not built", refuse with exit 2, and the commit silently does not form while the next push reports success. The fix is a symlink where the hooks look, and checking that `git rev-parse HEAD` moved rather than trusting what `git commit` printed. Resealed: the rule file changed, so `LOOP-RULES.sha256` moved with it in this commit. R6 -- the seal certifies identity, not correctness. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Sep 6, 2026
Closed
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #3357
Two sessions ran concurrently on 2026-09-06 sharing one checkout and one
target/, and neither had a way to find out.What it produced
Every symptom was attributed to the tool being measured:
git pushsaid successHEADtarget/HEADonw119a-fold, a branch never created hereThat is the broken-ruler error with a second session as the ruler.
The rule
R17 writes down what
tri loop claim(#3332) made possible: own the tree, takethe claim first, and do not diagnose a shared tree through the tree. The claim is
a git ref, so the atomicity is the remote's compare-and-swap rather than a file
two machines both believe they hold.
The trap found while following it
A private
CARGO_TARGET_DIR— the very thing that makes the tree private — hidesthe binary from
.githooks/pre-commit:52and.githooks/commit-msg:14, whichprobe
$ROOT/target/{debug,release}/tri. They report "not built", refuse withexit 2, and the commit silently does not form while the next push reports
success. I hit this in this pass, and the branch briefly pointed at master's HEAD
because of it.
R17 records the symlink and, more importantly, checking that
git rev-parse HEADmoved instead of trusting what
git commitprinted.Seal
LOOP-RULES.sha256moved with the rule file in the same commit — R6, the sealcertifies identity, not correctness.