Audit addendum: the branch-durability blind spot, and a zsh trap that reads as a git bug - #1696
Conversation
Two findings from finishing the wiring audit. **Nine branches held commits that existed nowhere but this laptop** — up to 95 on one — and the lifecycle tool reported none of them. It was not wrong to: it checks the protected prefixes (backup/, preserve/, recovered/, stage/) BEFORE it checks for unique upstream-less work, so those branches return KEEP_PROTECTED and never reach the durability verdict. Both verdicts are correct in isolation. The ordering means the branches named for preservation are exactly the ones whose non-durability is invisible. That also reconciles an earlier claim rather than contradicting it. The 2026-08-30 closeout recorded `NO_UPSTREAM_UNIQUE_WORK remaining: NONE` after pushing ten branches, and that was true as stated — protected branches were never in that verdict's population. All nine were scanned and pushed. gitleaks: no leaks found across 127 commits on the four largest, run BEFORE any push; the only secret-shaped literal was .env.example's placeholder `your-service-role-key`. Branches whose work exists in one place: 9 -> 0. Left as a design question, not repaired: whether KEEP_PROTECTED should also report unique-work status. A protected branch cannot be deleted by the tool, so the durability fact is advisory rather than load-bearing — that is a decision about what the report should say, not a defect to fix. **A zsh trap that reads as a git bug.** Pushing those branches failed seven times with `src refspec ... does not match any` against refs that resolved fine. In zsh, "refs/heads/$b:refs/heads/$b" parses $b:r as the `:r` history modifier and eats it, producing `refs/heads/recovered/stash-0efs/heads/recovered/stash-0`. The same command typed literally works, which is what makes it convincing — it only appears when the branch name is a variable. Recorded in shipping.md §3 alongside the other traps of its kind (`timeout` on macOS, `ls` aliased to eza). Verified: docs:schema-drift 0, docs:path-drift 0, knowledge:check 0, markdown ratchet at baseline, and the durability re-measure returns 0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NbDxyygyXRUEERuGocpZZH
|
ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing |
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…#1696 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NbDxyygyXRUEERuGocpZZH
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Documentation only. Closes out the repo wiring audit (#1694).
Nine branches held commits that existed nowhere but this laptop
Up to 95 on one. The lifecycle tool reported none of them — and was not
wrong to. It checks the protected prefixes (
backup/,preserve/,recovered/,stage/) before it checks for unique upstream-less work, sothose branches return
KEEP_PROTECTEDand never reach the durability verdict.Both verdicts are correct in isolation. The ordering means the branches named
for preservation are exactly the ones whose non-durability is invisible.
That also reconciles an earlier claim rather than contradicting it. The
2026-08-30 closeout recorded
NO_UPSTREAM_UNIQUE_WORK remaining: NONEafterpushing ten branches — true as stated, because protected branches were never in
that verdict's population.
All nine were scanned and pushed. gitleaks: no leaks found, 127 commits
scanned, run before any push; the only secret-shaped literal was
.env.example's placeholderyour-service-role-key.Left as a design question, not repaired: whether
KEEP_PROTECTEDshould alsoreport unique-work status. A protected branch cannot be deleted by the tool, so
the durability fact is advisory rather than load-bearing — that is a decision
about what the report should say, not a defect to fix.
A zsh trap that reads as a git bug
Pushing them failed seven times with
src refspec ... does not match anyagainst refs that resolved fine. In zsh,
"refs/heads/$b:refs/heads/$b"parses$b:ras the:rhistory modifier andeats it:
The same command typed literally works, which is what makes it convincing — it
appears only when the branch name is a variable.
git push origin "$b"avoidsit. Recorded in
shipping.md§3 alongside the other traps of its kind(
timeouton macOS,lsaliased toeza).Verified
docs:schema-drift 0 · docs:path-drift 0 · knowledge:check 0 · markdown ratchet at
baseline · durability re-measure returns 0
🤖 Generated with Claude Code
https://claude.ai/code/session_01NbDxyygyXRUEERuGocpZZH