Files
fusion/scripts
gsxdsm 5f6f39e115 fix(census): the scan root and the READ root could disagree, so an injected file list ENOENTs (#3230)
Picks up the bug **@#3228's author diagnosed and deliberately left
documented** rather than guessing at it mid-revision. Their diagnosis
was correct; the bug is mine, from extracting `triageFindings` in #3207
without considering an injected file list.

## The defect

`REPO_ROOT` came from the **script's** location; the file list comes
from `git ls-files` in the **CWD**. Identical in production and nowhere
else. Override the list — which a synthetic-tree fixture must do — and
every path is *listed* against the fixture but *read* against the repo:
`ENOENT` on every read.

## There were THREE read roots, not one

That is why a partial fix still ENOENTs, and I hit it myself: I fixed
`REPO_ROOT`, re-ran, and still got `ENOENT: open 'pkg/src/a.ts'`. The
scanners read the path **as given**:

| consumer | read root before |
|---|---|
| `triageFindings` | `join(REPO_ROOT, …)` |
| sync-resolver probe | `join(REPO_ROOT, …)` |
| `censusFiles` (AST) | path as given → CWD |
| `censusFilesText` | path as given → CWD |

All four now go through a single `readCensusFile`, so a listed path and
a read path cannot diverge again. **No lib change needed** — both
scanners already accept an injectable reader, which is the seam that
made this a small fix.

## What it unblocks

The two ratchet cases #3228 records as *permanently* vacuous at zero
backlog. On a three-file synthetic tree the full cycle is constructible
again:

```
inflated baseline  -> exit 0   TIGHTENED
deflated baseline  -> exit 1   ROSE
```

Neither is constructible against a real tree with nothing left to count
— which is exactly why that coverage was lost when the backlog hit zero,
and why `-1` (my #3218) and skip-at-zero (#3226) were both workarounds
for a missing seam rather than fixes.

## Measured

| | result |
|---|---|
| production scan | **unchanged** — 1961 files, 0 guards, `BACKLOG ZERO`
|
| `--strict` / `--json` / `--compare` | 0 / 0 / **0** (AST and text
classifiers still agree) |
| synthetic fixture | 3 files, **1 backlog / 1 deliberate** — the
numbers #3228 predicted |
| census suite | 53 passed |
| eslint / `check-fnxc-future-dates` / `pnpm test:gate` | clean / 0 / 0
(744 tests) |

`--compare` is the one I would look at first as a reviewer: it runs both
classifiers over the same list and fails if they disagree, so it catches
a reader change that silently alters what either one sees.

## Scope

Seams only — `FUSION_CENSUS_FILE_ROOT` and `FUSION_CENSUS_FILE_LIST`,
both required together (a root with no list still scans the real tree; a
list with no root still reads from it). Production sets neither.

I have **not** rewritten the two vacuous cases. That is #3228's work,
they already have two of six green, and duplicating it is how this fleet
loses PRs to collisions. This just removes the blocker.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Improved repository analysis reliability when run against configured
file sets or alternate repository locations.
* Prevented analysis from unintentionally reading unrelated files
outside the selected repository context.
  * Existing production behavior remains unchanged.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-07-31 12:49:54 -07:00
..