Repository navigation
Description
Summary
isRepoCensus — the structural gate for the fleet-feed coverage census behind the #1220 coverage panel (merged in PR #3309) — accepts census rows that cannot describe a real repo: negative counts, gate counts larger than the repo's open-issue total, a repo of "/" or "a/", and duplicate rows for the same repo. Those rows flow straight into the report, are persisted into the weekly coverage snapshot (including the frozen weekly baseline), and render on /projects — so one bad feed read can show negative/impossible backlog numbers and poison the week-over-week baseline for a full week. Duplicate rows are resolved by silent last-wins overwrite in computeCoverage, with none of the drop-and-count diagnostics the aggregator's other feed gates (#2429 quota sanitization) surface.
Evidence (verified this run, main 1a68d6af; coverage.ts sha256 2c166cdf…b301, feed.ts sha256 d7416455…36a4, both matched on the laptop clone)
The gate, pm-stack/aggregator/src/coverage.ts:88-98, checks only typeof repo === "string" && repo.includes("/") and Number.isInteger on the three counts. Laptop probe (~/git/fleet/probe-2026-11-01-laneB-census/probe.ts, bun, importing the real coverage.ts/feed.ts; full output in run.log):
isRepoCensus({repo:"developing-today/code", openIssues:-5, gateNow:0, gateNext:0})→trueisRepoCensus({…, openIssues:3, gateNow:10, gateNext:7})→true(gate counts are label-filtered subsets of the same open-issue search inscripts/collect-fleet-feed.ts:684-696, so each must be ≤openIssues)isRepoCensus({…, openIssues:10, gateNow:-2, gateNext:0})→trueisRepoCensus({repo:"/", …})and{repo:"a/", …}→truecomputeCoverageon two rows fordeveloping-today/code(openIssues:100thenopenIssues:7, gateNow:9, gateNext:9) → one row with the last values, no diagnostic;coverageFromFeed(src/feed.ts:275-282) keeps all 4 rows of a mixed feed (negative + impossible + duplicates)- A negative census row yields a report row with
openIssues:-5and a week-over-week delta of-55against a baseline of 50 (diffCoverage)
Downstream, src/server.ts:81 (coverageSnapshot) persists whatever computeCoverage returns via CoverageSnapshotStore, and nextCoverageSnapshot freezes the week's first report into weekly, which becomes next week's baseline — so impossible values are not a transient render glitch; they are stored and compared against for a week. coverageSectionHtml (src/render.ts:4910-4925) renders the numbers verbatim.
Why it matters
The coverage panel's whole contract (per the coverage.ts header and PR #3309's Codex rounds) is that unavailable or malformed source data renders as unavailable, never as invented numbers. Every sibling feed gate enforces its section's invariants (e.g. isQuotaWindow/sanitizeQuotaView drop-and-count, isProjectPoolItem shape-strictness). The census gate enforces only types, so the one section whose values are snapshotted to disk and frozen as a weekly baseline is the one that can store impossible values. A collector bug, a hand-edited feed, or a future collector change that double-emits a repo silently rewrites the panel and the baseline instead of dropping the row.
Acceptance criteria
isRepoCensusrefuses: negative counts;gateNow > openIssuesorgateNext > openIssues; arepothat is not anowner/namepair (both sides non-empty, exactly the shape the collector emits for the four fleet repos).- Duplicate census rows for one repo are handled explicitly — refused/dropped at the gate (with the surviving row's provenance clear), or counted/surfaced like
sanitizeQuotaView's drop counts — never silent last-wins. - Regression tests in
test/coverage.test.tspin each refusal and the duplicate behavior; existing coverage tests (absent census → null fields, pool-unavailable → null pool fields, weekly rotation) keep passing. - No change to the collector's emitted shape, the snapshot file format, or the panel layout.
Distinct from: #1220 (the feature, closed), #1218 (Project export auditability), #3332/#3309 (AA keep-last-good / the coverage panel PR itself). Dedup checked this run against open + closed issues for isRepoCensus / RepoCensus / coverage-census terms — no existing issue covers this gate.
Activity
dezren39 commentedon Nov 1, 2026
🤖 Agent note · filed
isRepoCensusaccepts impossible coverage-census rows (negative counts, gate counts above the open total,//a/repos, silent duplicate last-wins), and the values persist into the weekly coverage snapshot baseline (probe-verified on the laptop against the realcoverage.ts/feed.ts, sha-matched). Triage packet enqueued to repo-health-code-pilot.isRepoCensusinvariant checks + duplicate handling and tests.probe-2026-11-01-laneB-census(~/git/fleet/ on the laptop)dezren39 commentedon Nov 1, 2026
agent-note:v1 — state: picked-up (triage task 5083, OpenChamber scheduled lane)
24 remaining items
dezren39 commentedon Nov 1, 2026
🤖 Agent note · parked
ses_e5e66840ab9ffemBPdIMjlSmGW; queue task 5954dezren39 commentedon Nov 2, 2026
🤖 Agent note · picked up (resume — ownership re-check)
queue/5954-3364-coverage-census-validation— this task's own namespace), and every comment on issue aggregator(coverage): isRepoCensus accepts impossible census rows — negative counts, gate counts above the open total, '/' repos and silent duplicate overwrite — and they persist into the weekly snapshot baseline #3364 is a fleet agent note; there is no explicit Drew handoff or held/do-not-merge label anywhere. dezren39 is the shared fleet account, so PR fix(aggregator): reject invalid coverage census rows #4066 is this task's canonical PR, not a Drew-owned artifact. Proceeding on the merits: checks, Codex gate, recorded tests (bun 58 pass), then merge + complete if clean.dezren39 commentedon Nov 2, 2026
🤖 Agent note · done (fixed, merged)
eeae30534(2026-11-02T00:16:11Z).isRepoCensusnow requires an exact owner/name repo and non-negative integer counts with gateNow/gateNext ≤ openIssues; duplicate census rows make the optional census explicitly unavailable instead of silent last-wins. Files:pm-stack/aggregator/src/coverage.ts,src/feed.ts,test/coverage.test.ts.queue/5954-3364-coverage-census-validation) and no Drew handoff exists on this issue — it was this task's canonical PR.6b473c03cwith no findings; implementing lane's recorded tests:bun test test/coverage.test.ts test/feed.test.ts— 58 pass, 0 fail, 187 assertions (typecheck unavailable in that environment: bun type definitions absent — noted, not a regression signal).