fix(retention): resolve the canonical workspace by git-dir ownership, not porcelain order - #142
Conversation
… not porcelain order The Friday gate resolved the canonical retention workspace from the first `git worktree list` entry, which is only conventionally the main worktree. A detached main worktree leaves the first entry as a stale, empty twin that merely holds `refs/heads/main` — the gate then inspects the twin's empty state roots and passes while real client records live in the main worktree. Resolve the canonical workspace by git-dir ownership instead: the main worktree is the entry whose `git rev-parse --git-dir` equals the repository common dir, never a linked worktree under `.git/worktrees/<name>`, and never whichever worktree happens to hold the `main` branch. Add a regression assertion to the closed-twin test that pins the canonical workspace to the git-dir owner even when the twin heads the porcelain list. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
Warning Review limit reached
Next review available in: 5 minutes Limit details: You’ve used the included review currently available. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (1)
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login. Comment |
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
1 participant
Problem
The Friday retention automation still passes on a stale, empty workspace after
the closed twin. The gate resolves the canonical retention workspace from the
first
git worktree listentry, which is only conventionally the mainworktree. When the main worktree is detached (or routinely on a feature branch,
as on this machine), the first entry can be a stale, empty twin that merely
holds
refs/heads/main— the gate then inspects the twin's empty state rootsand passes while real client records live in the main worktree.
Root cause (live state)
/home/nish/workspaces/products/tinystudio-inowns.git,currently on
chore/pin-required-verifiers(reflog shows daily checkouts)./home/nish/workspaces/products/tinystudio-in-autonomous-serviceholdsrefs/heads/mainat 24e516a (2026-08-06), 0 clients, 0 day0 prospects, noservice-decisions / runs roots — stale and empty.
canonicalMainWorktreereturns the worktree holding
main= the twin.Fix
Rewrite
canonicalMainWorktree()to resolve the canonical workspace bygit-dir ownership: the main worktree is the entry whose
git rev-parse --git-direquals the repository's common git dir. A linkedworktree always resolves under
.git/worktrees/<name>, so a twin can never besubstituted. No list-order assumption, no branch-holder assumption.
Evidence
Fixed gate against the live repo now reports the main worktree with 3 real
clients and fails closed on the stale canonical workspace (exit 1), where the
old code hollow-passed on the twin's empty state.
node scripts/test-retention-automation.mjspasses, including the newclosed-twin regression assertion.
Full report:
.lane/reports/fix-retention-gate-stale-twin-20260814.md