Plan 0002 Phase 4 β the "later, optional" tier (umbrella #107; plan docs/planning/plans/0002-first-party-source.md Β§5, Β§11). Phases 1β3 (#110, #115, #118) route the measurement engines through the first-party inventory and make exclusions honest + fixable. Phase 4 refines the exclusion model itself: today it is binary and global (a file is in the inventory or not, for every check); Β§5 shows the right behaviour is category Γ check.
1. Make exclusion category-aware (the meat) β Β§5
The consuming engine must know why a file was set aside, not just that it was:
| Category |
exclude from |
keep in |
| Generated |
complexity, duplication, stats, identity |
β |
| Vendored (copied 3rd-party, bundles) |
maintainability, identity |
security / supply-chain |
| Test corpora / fixtures |
almost everything |
its presence is a signal |
| migrations / snapshots |
duplication, complexity |
churn, bug-density, coverage, stats |
Headline consequence: security opts vendored code back in. You ship vendored code, so its CVEs/secrets are yours β the secret-scan / SAST / supply-chain checks should still see it even though identity/complexity ignore it.
2. migrations/ and snapshots/ are first-party β stop dropping them entirely
_inventory_excluded removes them from the inventory wholesale (lib/source-inventory.sh), which is wrong β migrations (Rails/Django/Flyway) are hand-written and high-bug-density. Demote from a global exclude to a per-check one: out of duplication/complexity (noisy), kept for churn/coverage/stats. Likewise gate vendor//third_party/ directory excludes on corroboration so a first-party package literally named vendor/snapshots isn't eaten (Β§5, Β§15.M1).
3. Optional sugar β a standalone --plan config emitter (Β§2)
Emit a .checkup.yml skeleton from what was detected. Explicitly never a mode the scan depends on β convenience for the operator edit-and-re-run loop only.
Why deferred
Phases 1β3 deliver the load-bearing value (engines measure first-party code; the banner makes exclusions honest). Phase 4 is a more invasive change to the exclusion model with a narrower payoff β chiefly: vendored CVEs resurfaced in security, and migrations' churn/bug-density restored. Pick it up when that specific accuracy matters.
Refs #107.
Plan 0002 Phase 4 β the "later, optional" tier (umbrella #107; plan
docs/planning/plans/0002-first-party-source.md Β§5, Β§11). Phases 1β3 (#110, #115, #118) route the measurement engines through the first-party inventory and make exclusions honest + fixable. Phase 4 refines the exclusion model itself: today it is binary and global (a file is in the inventory or not, for every check); Β§5 shows the right behaviour is category Γ check.1. Make exclusion category-aware (the meat) β Β§5
The consuming engine must know why a file was set aside, not just that it was:
Headline consequence: security opts vendored code back in. You ship vendored code, so its CVEs/secrets are yours β the secret-scan / SAST / supply-chain checks should still see it even though identity/complexity ignore it.
2.
migrations/andsnapshots/are first-party β stop dropping them entirely_inventory_excludedremoves them from the inventory wholesale (lib/source-inventory.sh), which is wrong β migrations (Rails/Django/Flyway) are hand-written and high-bug-density. Demote from a global exclude to a per-check one: out of duplication/complexity (noisy), kept for churn/coverage/stats. Likewise gatevendor//third_party/directory excludes on corroboration so a first-party package literally namedvendor/snapshotsisn't eaten (Β§5, Β§15.M1).3. Optional sugar β a standalone
--planconfig emitter (Β§2)Emit a
.checkup.ymlskeleton from what was detected. Explicitly never a mode the scan depends on β convenience for the operator edit-and-re-run loop only.Why deferred
Phases 1β3 deliver the load-bearing value (engines measure first-party code; the banner makes exclusions honest). Phase 4 is a more invasive change to the exclusion model with a narrower payoff β chiefly: vendored CVEs resurfaced in security, and migrations' churn/bug-density restored. Pick it up when that specific accuracy matters.
Refs #107.