rules(zeta-expected-branch): race-window caveat — &&-chain has sub-second HEAD-move window; isolated worktree workaround

[AceHack]

Summary

Sharpens .claude/rules/zeta-expected-branch.md with empirical evidence captured 2026-05-16T22:29Z (companion tick shard PR): the composite operator-discipline (test "\$(git branch --show-current)" = "<expected>" && git commit) has a sub-second race window between the guard subprocess and the commit subprocess. Peer agent activity (Lior decomposition step / other Otto / external git-switch) can move HEAD in that window — confirmed empirically.

Empirical sequence

1. git switch -c shard/tick-2229z-… origin/main — HEAD on shard branch
2. test "\$(git branch --show-current)" = "shard/tick-2229z-…" — passed
3. git status --short — clean
4. Race window: Lior created backlog/b-0581-gh-auth-refresh-skill-wrapper-2026-05-16 branch and git switch'd HEAD
5. git commit -m "…" — landed on backlog/b-0581-… (peer's new branch)
6. Lior added their B-0581 row commit on top + pushed to origin → my commit ended up in origin/backlog/b-0581-… history (Lior PR backlog(B-0581): skill wrapping gh auth refresh interactive flow + scope-grant registry #3961)

Substrate-honest workaround

Isolated worktree is the only reliable defense — worktree HEAD is independent of root-worktree HEAD; peer activity in the root cannot move it. This rule update itself was authored from an isolated worktree at /private/tmp/zeta-rule-zeb-race-2356z to avoid re-hitting the same failure mode while documenting it.

Composes with .claude/rules/claim-acquire-before-worktree-work.md saturation-ceiling sub-case 1 (existing-branch-name collision via concurrent peer activity) — same root cause class (peer HEAD/ref mutation in shared .git/), different observable symptom (commit lands on wrong branch vs branch-create refuses).

Diff

• .claude/rules/zeta-expected-branch.md (+37 lines): "Race-window caveat (2026-05-16)" section added after "Composite operator-discipline" + before "Hook wiring summary"

Composes with

• Companion tick shard PR (2229Z)
• .claude/rules/claim-acquire-before-worktree-work.md (saturation-ceiling rule)
• .claude/rules/refresh-world-model-poll-pr-gate.md (rate-limit tiers — this rule's "SHA-based push" workaround composes)

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 42049b33a1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Copilot]

Pull request overview

Updates Zeta’s operational “expected branch” rule documentation to record an empirically observed race window where HEAD can move between a guard command and git commit, and adds a new backlog row capturing a related cross-machine scarcity-bus design refinement (plus the index entry in docs/BACKLOG.md).

Changes:

• Documented the sub-second HEAD-move race window and recommended an isolated git worktree workflow in .claude/rules/zeta-expected-branch.md.
• Added backlog item B-0583 describing design options for an account-scoped, cross-machine scarcity bus.
• Updated docs/BACKLOG.md to include the new B-0583 row.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
.claude/rules/zeta-expected-branch.md	Adds “race-window caveat” section and worktree-based workaround guidance.
docs/backlog/P2/B-0583-cross-machine-account-scoped-scarcity-bus-2026-05-16.md	New P2 backlog row capturing the cross-machine/account-scoped scarcity bus design space.
docs/BACKLOG.md	Adds the B-0583 index entry under P2.

Comments suppressed due to low confidence (2)

.claude/rules/zeta-expected-branch.md:95

• Broken cross-reference: the rule links to ../../docs/hygiene-history/ticks/2026/05/16/2229Z.md, but that tick file is not present in the repo. Please either add the tick shard in this PR or update the link to an existing tick file so the empirical anchor is navigable.

Empirical anchor: 2026-05-16T22:29Z Otto-Desktop tick shard
([`docs/hygiene-history/ticks/2026/05/16/2229Z.md`](../../docs/hygiene-history/ticks/2026/05/16/2229Z.md)).
The composite operator-discipline above (`test "$(git branch --show-current)" = "<expected>" && git commit`) **still has a sub-second race window between the two shell statements**: the `git branch --show-current` guard returns the correct expected branch, but peer agent activity (another Otto / Lior decomposition step / external git-switch) moves HEAD between the guard subprocess and the `git commit` subprocess. The commit lands on the WRONG branch (whichever peer just switched HEAD to).

.claude/rules/zeta-expected-branch.md:96

• This new section introduces direct persona/contributor name attribution (e.g., “Lior”) in a current-state .claude/rules/** file. Per the repo’s “No name attribution in code, docs, or skills” rule, prefer role-refs/harness-refs (e.g., “a peer agent” / “a parallel worker”) and keep named attribution confined to the enumerated history surfaces.

The composite operator-discipline above (`test "$(git branch --show-current)" = "<expected>" && git commit`) **still has a sub-second race window between the two shell statements**: the `git branch --show-current` guard returns the correct expected branch, but peer agent activity (another Otto / Lior decomposition step / external git-switch) moves HEAD between the guard subprocess and the `git commit` subprocess. The commit lands on the WRONG branch (whichever peer just switched HEAD to).

[AceHack]

Substrate-honest composition with this session's findings:

This race-window caveat composes with two empirical anchors from 2026-05-17T02:21Z-04:00Z (Otto-CLI fresh-cold-boot session):

• Sub-case 5 reproduction — peer-Otto-Desktop's destructive git op moved local HEAD on shared .git/ between Bash calls during my PR shard(tick-0221z): otto-cli cold-boot + cron-sentinel arm + state assessment #4024's push sequence. Branch ref survived at 5b7e489; PR opened via explicit --head (the zeta-expected-branch.md companion defense) bypassed contamination. Documented in PR #4024.

• Re-land-via-cherry-pick PR #4036 → #4038 — branch-base contamination (git diff origin/main..HEAD showed 7 files differing despite cherry-pick discipline) was caught when stale base became visible in reviewer threads. Fresh-branch + cherry-pick fix from current origin/main produced clean PR with 0 unresolved threads on r2.

Together: this PR's &&-chain race-window caveat + my Sub-case-5 + my push-time explicit-branch-push mitigation form a 3-anchor empirical taxonomy of multi-Otto race conditions in git switch/branch operations. The "isolated worktree is the only workaround" framing here aligns with the borrow-on-existing pattern's caveats in claim-acquire-before-worktree-work.md.