feat(audit): exempt upstream-authored files from governance metadata (0.1.0-alpha.15) - #45
Conversation
A vendored fork carries the upstream project's own AGENTS.md. Asking it for a `Last validated:` line asks us to write our first authored line into someone else's document, which then conflicts on every merge — and until we do, the repo sits permanently red for files carrying zero lines of ours. Both signals are local, as proposed: `git ls-tree <upstream-ref>` for what upstream ships and `git log <upstream-ref>..HEAD --name-only` for what we have touched since diverging. `upstream` only has to be CONFIGURED, not reachable, so the audit stays offline and deterministic. Two git calls per repo, not two per file. Where no upstream remote exists the check never fires. openclaw: CRITICAL -> NEEDS WORK, Validation Date Coverage 0/23 -> pass with all 23 excluded. arbor, anvil and lc-classic-starter are unchanged. postiz-app does NOT become exempt, and the brief's two framings disagree about it. By content it is byte-identical to upstream — but to upstream's CLAUDE.md, under a different filename. By history its AGENTS.md is a local file with one local commit and no counterpart at that path upstream. The stated test (`git log upstream/main..HEAD -- AGENTS.md` empty) is false for it. Exempting it would need content-matching across renames, which is a different check and a network-free one worth measuring separately. Also removes a fallback I added last round. When every governance file was exempt the check fell back to the unexempted set to avoid reading an empty denominator as 0% — which re-failed exactly the repos this exemption exists for, since upstream authorship was not yet one of the exemptions. Emptiness now splits: no governance files at all still scores 0, because that is a missing surface Governance Surface already fails on, while a surface we decided not to ask passes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 31 minutes 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 for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (12)
Comment |
1 participant
Takes §5. The stale-specifier discriminator is measured and not built — it fails, see below.
§5: upstream exemption
Your local-refs framing was right and it changed my read completely.
upstreamonly has to be configured, not reachable —git ls-tree <ref>andgit log <ref>..HEAD --name-onlyread refs already on disk. Two git calls per repo, not two per file. Where no upstream remote exists the check never fires.openclaw: CRITICAL → NEEDS WORK, Validation Date Coverage 0/23 → pass, all 23 excluded. arbor, anvil, lc-classic-starter unchanged.
postiz-app does not become exempt, and your two framings disagree about it. By content it is byte-identical to upstream — but to upstream's
CLAUDE.md, under a different filename. By history itsAGENTS.mdis a local file with one local commit and no counterpart at that path upstream, so the stated testgit log upstream/main..HEAD -- AGENTS.mdis not empty. Exempting it needs content-matching across renames — a different check, still network-free, worth measuring separately.Also removes a fallback I added in alpha.13: when every governance file was exempt it fell back to the unexempted set, which re-failed exactly the repos this exemption exists for. Emptiness now splits — no governance files at all still scores 0 (a missing surface, which Governance Surface already fails), a surface we decided not to ask passes.
Stale-specifier discriminator: measured, do not build
Ran it across 33 repos. Your predicted error was right, and worse than predicted:
@360training/cloudflare-proxy@medusajs/ui→ flagged against@t360/ui. Medusa's real published package.@lambdacurry/forms×2 in lc-classic-starter → flagged against@lc-classic-starter/forms. Real published package, v0.22.7 on npm.And it never sees
@360training/uiat all — that specifier lives in.devagent/workspace/tasks/and a package README, neither of which is a scanned rule surface. The check misses the one case it was designed for and fires only on collisions.Root cause:
ui,forms,utils,sharedare the most common package basenames there are. Any monorepo with@scope/uicollides with every external@vendor/ui. Basename equality can't distinguish a rename from a coincidence.Verify
lint · format:check · release:pin --check · typecheck · 517 pass / 0 fail · verify:self-audit-proof.
🤖 Generated with Claude Code