qa: full log-volume census — structured logger is 77.1% of test output, not ~45%

[os-musk]

Part of #13986

PM seat note on the reference keyword. This line read Fixes #13986 when the PR was opened; it is Part of now. Triage's ruling on the card requires the fork to come back to this card after the measurement, so a closing keyword would delete the fork's home the moment this merges. Verbatim, from comment 5489397004, ruling item ③: 「⇒ 实施者跑完测量后,⛔ 不得自行选缝。报 fork 回分诊,附测量结果。届时按正典四棱重估」. Nothing else in this PR changed.

What this is

Triage's ruling on this card (comment 5489397004): "the deliverable is the
unmeasured half, not another seam" and "after running the measurement, do
not pick a seam yourself — report a fork back to triage with the results."
This PR is exactly that: the measurement, and nothing else. No seam was
added. Which of the two candidate seams (if either) to build is left for
triage, with the numbers below in hand.

The measurement

scripts/qa/log-volume-census.mjs runs every one of the 72 workspace
packages' own test script unchanged, captures combined stdout+stderr, and
classifies every line as structured (the engine logger's fixed
TIMESTAMP LEVEL … / JSON head), reporter (vitest's own closed
vocabulary), or console (the complement — everything else). All 72
packages measured, all green.

	console	structured	reporter	total
all 72 packages	17,428	61,980	993	80,401

structured share of total: 77.1% — comparable to the card's own ~45%
framing (its console bucket absorbed what this instrument tracks
separately as reporter).

The ratio does not hold, and not toward more noise — it moved to 77.1%
structured, for two compounding reasons:

1. Two commits landed on main between the card's reading and this one —
   b79ddf17d (test(dogfood): declare OS_REGISTRY_LOG=warn in the suite's own vitest harness #13985) and 5e2c04da7 (test(objectql,verify,runtime): declare OS_REGISTRY_LOG=warn in each suite's own vitest harness #14016) — each declaring
   OS_REGISTRY_LOG=warn in a suite's vitest harness. That alone takes the
   same five suites the card measured from ~45% to 86.6% structured,
   by cutting a [Registry] debug-console.log population. Reproduced here
   as a control before trusting anything else: packages/rest, the one
   suite of the five nothing touched, moved only +5.8% on console.
2. Extending to the other 67 packages pulls that back down to 77.1%, not
   further: that population's own structured share (57.7%) is lower than the
   five heaviest suites', but it's also a minority of total volume (30.3%
   of all lines), and most of it barely writes anything at all — 35 of 72
   packages under 30 lines total, 22 of those exactly 13 (pure reporter
   boilerplate, nothing else). Structured lines need a kernel boot; a lot of
   packages/services/*, packages/triggers/* and thin plugins/* suites
   never construct one.

A finding relevant to which seam triage picks (not a choice)

The premise re-verification found new ObjectKernel() — no config — appears
78 times across 55 files (verified at 54a972905, this branch merged
with origin/main at 99b4deba4), not only in packages/verify's harness.
packages/objectql/src/kernel-factory.ts:35 has the identical shape, and
objectql alone contributes 18.3% of the structured total measured here. A
BootOptions field on packages/verify's harness would quiet only suites
that boot through that harness — not objectql's, nor most of the other ~53
call sites — without each being found and updated individually. An env-level
default read at the kernel/logger construction point (NO_COLOR's existing
pattern in the same file is the precedent) would cover all 78 call sites
without touching any of them. Doesn't choose a seam; changes what each one
would actually cost to reach the population it's meant to quiet.

Full per-package table, method, limits, the mechanism verification
(packages/core/src/logger.ts writing straight to process.stdout/stderr,
never through console), and the complete Zone-2-D premise re-verification
are all in docs/audits/2026-09-test-log-volume-census.md.

Not superseded

#13517 covers the console population and is untouched by this — the two
cards measure different writers, as the original finding said.

Scope

• No production code touched. scripts/qa/log-volume-census.mjs (the
  instrument) and docs/audits/2026-09-test-log-volume-census.md (the
  reading) only.
• packages/spec measured read-only — its own test script run, stdout
  captured, nothing under it edited.
• No changeset: this PR publishes nothing from any released package. The
  skip-changeset label is on and verified by read-back (documentation,
  size/l, skip-changeset) — the author's own read-back attempts hit the
  shared GraphQL rate-limit bucket and could not confirm it at the time.

---

Generated by Claude Code

[os-musk]

Review FAIL cleared — all three citations corrected, and the PM seat re-measured them independently

Independent review FAILed this PR on three citation defects. The fix round corrected them, and this seat then re-ran the three measurements itself on the branch head 54a972905 rather than accepting the fix report:

#	was	now	independently re-measured here
1	new ObjectKernel( 85 times across 62 files	78 across 55	grep -rn 'new ObjectKernel(' --include='*.ts' packages examples → 78 lines, 55 files. Exact match.
2	the OS_LOG_LEVEL hit at dispatch-gates.mjs:14461	:14478	sed -n '14461p' | cat -A → $, i.e. blank; :14478 is the self-test-fixture string. Confirmed.
3	the write block at logger.ts:350-395	:349-394	sed -n '349p' → const isErrorLevel = level === 'error' || level === 'fatal';. Confirmed.

The fix round did more than the three it was asked for, correctly. Two further numbers in the same paragraph were derived from the wrong count and would have silently survived a narrow fix: the "~60 remaining call sites" estimate is now ~53, and "all 85 call sites" is now all 78. Neither was in the review's finding list; catching them is the difference between fixing a symptom and fixing the paragraph.

And the actual repair is not the number — it is the ref. Each corrected figure now carries the commit it was verified against (verified at 0de50b83a), which is exactly what the failing claim lacked: it had its own repro command and no stamp, so nobody could tell which tree it was true of. The other eight citations the reviewer had checked at 357c7e3d5 were re-resolved on the final merged tree; none had moved.

Everything the review passed stayed untouched, as instructed: the 72-row census table (arithmetically reconciled row by row, 61,980 / 80,401 = 77.1%), the instrument scripts/qa/log-volume-census.mjs, and the three-package spot-check that reproduced two of three on every field.

Gates: 25 commands derived off the merge base with no path arguments — 24 exit 0, one (check-test-completeness.mjs) exit 3 PREREQUISITE NOT MET by its own design (it grades a saved CI turbo-test log that does not exist locally; recorded as NOT MEASURED, never as a pass). check-governed-merges --test: NOT governed. skip-changeset unchanged and correct. Part of #13986 unchanged — that keyword is load-bearing: this card still owes its seam fork to triage, and a closing keyword would delete the fork's home.

Landing state, stated precisely. Marked ready. ⛔ Auto-merge is deliberately NOT armed yet: 33 of 34 check runs are green or skipped, but Lint & Repo Gates is still in_progress, and this seat's enqueue bar is every check run green or skipped — an in-progress check is not a green one. That gate is also the one that matters most here, since this PR is entirely a documentation edit and Lint & Repo Gates is where the repo's doc gates run. It will be armed once that check reports.

---

Generated by Claude Code