[quality] e2e --require-source-files is satisfied by a zero-executable-line measurement, so three src modules pass the gate unmeasured

Read tests/tools/e2e-coverage-report.mjs around the source filtering, missingSourceFiles, and summary construction, then inspect the related tests/e2e-coverage-report*.test.mjs cases. Decide which reported semantics to implement: the issue presents three options with different effects, and Option A makes the current job fail for three modules. Done means the chosen behavior is visible in the report and covered by tests while the stated harness coverage floors still pass.

Finding

The "End-to-end coverage" job's --require-source-files flag exists to give a
second guarantee beyond the percentages. tests/tools/e2e-coverage-report.mjs
states it directly at lines 929-936:

The summary below is a ratio over the files the run observed. A src module
the bundle dropped (or that attribution lost) contributes neither numerator
nor denominator, so the percentage cannot see it (#992). The file-set
comparison is the second, different guarantee: every module on disk under
src/ must have been measured.

That second guarantee does not currently hold. A source file measured with
zero executable lines satisfies --require-source-files while being absent
from the per-file table and from the summary denominators — so the one check
meant to catch "attribution lost this module" is itself blind to exactly that
case.

The two checks read different collections:

• line 926 — .filter((row) => row.executableLines > 0) drops zero-line rows
  from report.sources;
• line 940 — report.summary = report.sources.reduce( sums the filtered
  array, so zero-line files are outside the denominators;
• line 937 — report.missingSourceFiles = enumerateSourceFiles(root).filter((file) => file.startsWith('src/') && !sources.has(file))
  tests the unfiltered sources map, so a zero-line entry counts as
  "measured".

Evidence

Against main @ 1e37cdcd, artifact e2e-coverage from the "Validate
repository" run 38418930699
(status passed, report header E2E coverage: ok (run 38418930699-1; status passed)):

22 + 3 = 25, so exactly three enumerated src/ modules are in sources with
executableLines === 0:

• src/components/shared/MirrorSyncStatus.js
• src/components/shared/initials.js
• src/components/shared/useFilterToolbar.js

They appear in neither the table nor the 2177/2177 lines / 656/674 regions
totals, and the job still reports ok.

Reproduce without a browser run:

gh api repos/cncf/endusers/actions/artifacts/11825781781/zip > e2e-coverage.zip
# unzip, then:
node -e "const r=require('./report.json'); console.log(r.sources.length, r.missingSourceFiles)"
node -e "import('./tests/tools/coverage-report.mjs').then(m=>console.log(m.enumerateSourceFiles().filter(f=>f.startsWith('src/')).length))"

What this is not

This is not a claim that those three modules lack browser coverage. Two of
them are demonstrably driven in the browser — the preamble of
tests/e2e/radar-reports-variant.spec.js cites
src/components/shared/MirrorSyncStatus.js:20 and :22 as arms the variant
build takes. Their unit coverage is complete as well: npm run test:unit:coverage
at 1e37cdcd reports all three at 100.00 line and 100.00 region.

The claim is narrower and about the gate, not the modules: the gate cannot
tell the difference between "measured and fully covered" and "attribution
produced nothing at all". Any of the three could lose every browser record, or
be dropped from the bundle, and the job would stay green.

Recommendation

The direction here is a maintainer's call, because each option trades
differently and one of them turns the job red on main today:

• Decide which semantics --require-source-files should have (see options below)
• Implement it in tests/tools/e2e-coverage-report.mjs
• Cover the new branches in tests/e2e-coverage-report*.test.mjs so the
  --check-harness 100 / --check-harness-regions 99 floors still pass

Option A — require a non-empty measurement. Make the file-set check assert
what its comment claims, by testing the filtered rows rather than the raw map:

  const measured = new Set(report.sources.map((row) => row.file));
  report.missingSourceFiles = enumerateSourceFiles(root)
    .filter((file) => file.startsWith('src/') && !measured.has(file))
    .sort();

This is the honest reading of the existing comment, but it fails the
e2e-coverage job immediately on the three files above, so it needs to land
together with whatever fixes or exempts them.

Option B — report them without failing. Keep the gate as-is and add a
third, named list (for example zeroLineSourceFiles) to report.json and the
text report, so the count is visible in the step summary and can be ratcheted
later. Non-breaking, and makes the blind spot reviewable instead of invisible.

Option C — treat it as attribution. If these three are bundler-inlined into
their importers (all three are small: 974, 369 and 1728 bytes), the records may
be folding onto the importing module, which is the same root cause as #992. In
that case the fix belongs there and this issue becomes the gate-side regression
test for it.

Option B is the smallest safe step and does not foreclose A or C.

Priority

• Impact: medium — no coverage is known to be missing today, but the check that
  would detect it going missing does not work
• Effort: low (Option B) to medium (Option A, which needs the three files
  resolved first)

🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5n31 | SHA: f734dbf

— hive: agent=quality backend=copilot model=claude-opus-5 copilot=1.0.88