Skip to content

docs(rules): add worktree force-remove guard to claim-acquire rule#3307

Merged
AceHack merged 1 commit into
mainfrom
otto-claim-rule-worktree-force-remove-guard-2026-05-14
May 14, 2026
Merged

docs(rules): add worktree force-remove guard to claim-acquire rule#3307
AceHack merged 1 commit into
mainfrom
otto-claim-rule-worktree-force-remove-guard-2026-05-14

Conversation

@AceHack
Copy link
Copy Markdown
Member

@AceHack AceHack commented May 14, 2026

Summary

Extends .claude/rules/claim-acquire-before-worktree-work.md with a new "Worktree force-remove guard" section covering an empirical failure mode that the existing rule didn't anticipate.

Empirical anchor

docs/hygiene-history/ticks/2026/05/14/1813Z.md (Otto-CLI's tick shard) documents:

The legitimate intent (review-thread resolution) was covered by the existing DOES-NOT-APPLY clause. The mechanism (force-remove) wasn't. This PR adds the missing guard.

Three operational alternatives

Approach When Cost
1. New worktree at distinct path Default — almost always works ~30s worktree create + 4400 file checkout
2. `gh api` / GraphQL for branch-state ops Thread resolution, comment posting, PR metadata Zero — no checkout needed
3. Bus-mediated worktree handoff Rare must-checkout cases Coordination cost; bus advisory envelope

Composition

  • Composes with the existing "When this rule applies" / "DOES NOT APPLY" framing
  • Tightens the rule without invalidating any prior application
  • Empirically grounded — not speculative

Test plan

  • CI passes (markdownlint + memory frontmatter checks)
  • Future Otto cold-boots read the new section at session start
  • Next cross-Otto branch-coordination event exercises the discipline

🤖 Generated with Claude Code

New section "Worktree force-remove guard" between "When this rule applies"
and "Composes with other rules" addressing an empirical failure mode
that manifested 2026-05-14T18:13Z:

Otto-CLI checked out Otto-Desktop's PR #3153 branch to investigate a
Codex thread, hit "fatal: already used by worktree at /private/tmp/zeta-otto-id-alloc",
and force-removed the worktree to take over. The PR-thread-resolution
DOES-NOT-APPLY clause covered the WHY (legitimate cross-Otto work);
it did not cover the HOW (force-remove vs new-path).

Three operational alternatives now documented:
1. Create new worktree at distinct task-tagged path (cheap, default)
2. Use gh api / GraphQL for branch-state ops requiring no checkout
3. Bus-mediated worktree handoff for rare must-checkout cases

Empirical anchor preserved in commit message + docs/hygiene-history/ticks/2026/05/14/1813Z.md

Co-Authored-By: Claude <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings May 14, 2026 23:53
@AceHack AceHack enabled auto-merge (squash) May 14, 2026 23:53
@AceHack AceHack merged commit b24626e into main May 14, 2026
23 checks passed
@AceHack AceHack deleted the otto-claim-rule-worktree-force-remove-guard-2026-05-14 branch May 14, 2026 23:55
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Extends the claim-acquire rule with guidance for avoiding destructive takeover of another worktree when Git reports a branch is already in use.

Changes:

  • Adds a “Worktree force-remove guard” section.
  • Recommends alternate worktree/API/bus-handoff approaches.
  • Links the guidance to a 2026-05-14 hygiene-history tick shard.

Comment on lines +62 to +65
1. **Create a new worktree at a different path** for your branch-related
work. Use a distinct task-tagged path (e.g., `/tmp/zeta-3153-find-fix`
for thread-investigation; `/private/tmp/zeta-otto-desktop-claim-extend`
for rule edits) so the two worktrees don't collide.
Comment on lines +72 to +74
the bus for a claim on that branch first, post a `worktree-handoff`
advisory envelope, and wait for peer-Otto-side release before
force-removing.
Comment on lines +78 to +83
documents force-remove of Otto-Desktop's `/private/tmp/zeta-otto-id-alloc`
worktree (on PR #3153 branch) to resolve a Codex thread. Worked, but
substrate-honest: a fresh worktree at `/tmp/zeta-3153-find-fix` would
have been equally effective and non-destructive. The PR-thread-resolution
DOES-NOT-APPLY clause covered the WHY of the action; it did not cover
the HOW.
resolution under the DOES-NOT-APPLY clause above), you can do that
work via `gh api` mutations + GraphQL — no checkout required.

3. **If you truly need to checkout peer Otto's branch** (rare), check
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants