Repository navigation
Two loop ticks shared one worktree, and every symptom was blamed on the tool being measured #3357
Description
Two sessions ran concurrently on 2026-09-06 sharing one checkout and one target/. Neither could find out.
Symptoms, each misattributed first:
HEADsat on a branch this session never created (w119a-fold); the other session had made five branch switches in the same directory in five minutes.- A commit "did not form" while
git pushreported success — it pushed an unchangedHEAD. - The built binary lost a subcommand it had a minute earlier (one shared
target/). - Census readings flip-flopped between runs, read as a flaky gate.
Every one was blamed on the tool being measured. That is the broken-ruler error with a second session as the ruler.
tri loop claim (#3332) gives a tick a way to find out. This issue is for writing the discipline down where the next tick reads it, as a LOOP-RULES rule, including the trap that a private CARGO_TARGET_DIR hides the binary from .githooks/pre-commit, which probes $ROOT/target/{debug,release}/tri and refuses with exit 2 so the commit silently does not form.
Activity
docs(loop): R17 -- a tick owns its worktree and takes a claim (Refs #…
gHashTag commentedon Sep 6, 2026
Closed by #3358, merged as
bb60ddc.Verified on
origin/master, not on the merge message:docs/loop/LOOP-RULES.mdcarries exactly one## R17heading.LOOP-RULES.sha256isb6d5a074…and the file digests tob6d5a074….python3 scripts/tri_loop/loop_rules.pyexits 0: "the rule text is byte-identical to the sealed text" — identity only, per R6.R17 records the claim discipline (
tri loop claim, #3332), the private-worktree rule, and the trap that a privateCARGO_TARGET_DIRhides the binary from.githooks/pre-commit:52, which refuses with exit 2 so the commit silently does not form while the next push reports success.