fix(tooling): string-payload ratchet scans nothing under a dot-directory (and invites zeroing its own baseline) - #11082
proggeramlug wants to merge 1 commit into
Conversation
…directory
`collect_inventory` filtered on `path.parts` — the ABSOLUTE path — so any
checkout living under a dot-prefixed directory skipped every file. Agent
worktrees live at `.claude/worktrees/agent-<id>/`, so for a growing share of
the people who run this gate it scanned 0 files and found 0 sites.
That is not a quiet failure. Finding nothing makes every baseline row read
"baseline 349, found 0", i.e. "all of these were converted", and the failure
text then says:
Run: python3 scripts/string_payload_access_inventory.py --write-baseline
Doing what the error says would commit an all-zero baseline. The ratchet would
be satisfied forever and could never catch a regression again, and the diff
would look like a legitimate "record the progress" commit in review.
Three changes:
- filter on the path RELATIVE to the repo root (`rel.parts`), which is the
thing the filter was always meant to test;
- refuse to report a verdict after scanning zero files, with an explicit "do
NOT run --write-baseline" — a scanner that looked at nothing must not be able
to produce a clean bill of health (CLAUDE.md's fourth way a gate cannot fail);
- self-test the dot-directory case. The existing fixture plants a synthetic
crate in a tempdir and asserts files_scanned == 1, which is the right shape
but cannot catch this, because `/var/folders/...` has no dot component. The
new fixture plants the same tree under `.agentdir/` and asserts both the file
count and the findings.
Measured before/after in a dot-named directory: before, "found 0" for every row
plus the --write-baseline instruction; after, 4056 files scanned, 393 inline
offsets and 14 reader helpers, exit 0.
CI was never affected — runners check out to /home/runner/work/perry/perry.
Diagnosis by the turnloop lane, which hit it in an agent worktree.
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughThe scanner now applies its path filter relative to the repository root. A self-test covers scanning under a dot-prefixed directory. The command exits with an error when it scans zero files. ChangesScanner behavior
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix · Severity of issue fixed: Low Merge Risk: ⚪ Minimal · up to The scanner fix is mergeable after normal checks; no outstanding risk is established. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 1 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
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 |
|
Landed on Cherry-picked from this PR's head Nothing needed from you. Thanks. |
1 participant
scripts/string_payload_access_inventory.pyscans zero files from any checkout under a dot-prefixed directory — which is where every agent worktree lives (.claude/worktrees/agent-<id>/)..claudematchespart.startswith("."), so every source file is skipped. Diagnosed by the turnloop lane, which hit it in an agent worktree; I reproduced it and confirmed the pieces in isolation all work —INLINE_OFFSET_REmatches,scan_textfinds,crate_dirs()returns 67 crates — and the file filter throws all of it away.Why this is worse than a broken scan
Finding nothing makes every baseline row read
baseline 349, found 0— "all of these were converted" — and the failure text then says:An agent or reviewer doing exactly what the error instructs would commit an all-zero baseline. The ratchet would be permanently satisfied, could never catch a regression again, and the diff would look like a legitimate "record the progress" commit.
Changes
--write-baseline". A scanner that looked at nothing must not be able to issue a clean bill of health — CLAUDE.md's fourth way a gate cannot fail.files_scanned == 1, which is the right shape but cannot catch this, because/var/folders/…has no dot component. The new fixture plants the same tree under.agentdir/and asserts both the file count and the findings.Measured, same dot-named directory, before and after
--self-testpasses, and the new fixture was confirmed to fail against the old filter before being wired in.CI was never affected: runners check out to
/home/runner/work/perry/perry, which has no dot component, so the gate has been genuinely live there throughout. This is purely about local and agent runs — which is where most of its invocations now happen.Summary by CodeRabbit