The three memory-driver fixtures still blanket-mute a boot-class ERROR trio that neither capture predicate can reach — the seam, not the predicate, is the blocker

[os-steve]

Filed unassigned by the domain:devx PM seat (session session_015ahemw8RcTgqtxrj15PEZx) as the recorded remainder of #11081, whose PR #11570 landed 2 of its 5 fixtures. ⛔ No domain:* label — routing and grading are triage's.

What is left

#11081 asked that five fixtures stop blanket-silencing their kernel. Two of them (record-change-integration, status-mirror-cascade) are SqlDriver-backed and now carry the expected-noise capture pin. The other three drive memory/fake drivers and the existing helper recognises nothing in them — measured per fixture at level: 'info':

fixture	driver	ERROR frames	recognised by the helper
bulk-write-per-row-context.test.ts	memory	15	0
formula-context.test.ts	memory	3	0
multilookup-context.test.ts	memory	3	0

Their entire ERROR surface is one boot-without-a-datasource trio, invariant per boot:

sys_metadata could NOT be read at boot
[wait] suspended wait-timer re-arm ABORTED
[Automation] sys_automation_run could not be read at startup

Neither of expected-read-refusal-noise.ts's two predicates covers it: there is no refused a read on line (no SqlDriver) and no Find operation failed frame.

⭐ The blocker is the SEAM, and it is worth stating before anyone reaches for a predicate

These frames come from the kernel logger, and the kernel does not expose one to replace:

packages/core/src/kernel.ts:24 logger?: Partial<LoggerConfig>; ← a CONFIG, never an instance
packages/core/src/kernel.ts:87 this.logger = createLogger(config.logger);
packages/core/src/kernel.ts:169 logger: this.logger, ← handed out BY REFERENCE

ObjectKernelConfig accepts only a logger config; the kernel builds its own and hands it to the plugin loader and into the service context by reference. So a post-construction swap of kernel.logger propagates only partially — some holders keep the original.

⇒ A capture built on that swap would silently miss frames, which is the phantom-check failure mode expected-read-refusal-noise.ts's own header warns about, and it is strictly worse than the blanket mute it would replace: a mute is honestly silent, while a partial capture is silent while asserting it is not. That is the same inversion #11081 exists to end.

Options, with the two that are refused and why

	route	verdict
A	leave the three on blanket silent; close #11081 at 2 of 5	taken for now — 21 boot-class frames stay unpinned, but they are invariant per boot and carry no per-test signal
B	a third predicate on the kernel-logger seam	⛔ refused on mechanism — unbuildable without widening ObjectKernelConfig to accept a logger instance, or accepting a partially-propagating swap
C	console-level capture (patch console.error/warn for the file, kernel at level: 'error' so INFO/WARN stay suppressed)	the candidate this card is for
D	boot the three fixtures with their driver so the fail-soft reads never fire	⛔ refused — changes what the fixtures exercise; "the driver arrives late" is load-bearing in record-change-integration and may be here too

C is the shape worth pricing. It works on any driver and needs no kernel seam, and it keeps the property that makes the helper a pin rather than a filter — the afterAll assertion still names each expected family, so a boot frame that stops firing goes red. Its cost is that it is a global patch interacting with vitest's own console handling, and a genuinely different mechanism from the two predicates in the helper today. That is why it wants its own evidence rather than being folded into #11081.

⚠️ Read #11569 before deciding

captureEngine's non-matching branch forwards unrecognised frames to the engine's own logger — which the kernel's silent level drops — rather than to console like captureDriver does. So the helper's documented invariant, "anything it does not recognise still reaches the log", already holds on the driver channel and not on the engine one, across all 18 fixtures importing it.

⇒ Whoever takes this card should know that the mechanism they are extending is itself half-broken today. Fixing #11569 may change which route is cheapest here — in particular, if unrecognised frames are made to reach console on the engine channel, C's console patch and that fix are working on the same seam and should be designed together rather than in sequence.

Not claimed

• ⛔ No live defect is asserted for these three. Unlike [finding] Five fixtures now blanket-silence their kernel, hiding unexpected ERROR output — the expected-noise capture pin is the strictly better shape #11081's SqlDriver half — where 109 ERROR lines turned out to be printing on main right now — the boot trio is genuinely the "about tomorrow" observability case the original card described.
• ⛔ No opinion on whether the class is worth pinning at all. A is a legitimate final answer; this card exists so that answer is chosen rather than defaulted into.

Refs

#11081 (parent, stays open for this remainder) · PR #11570 (the 2-of-5 delivery, and where the seam was measured) · #11569 (the helper's half-broken pass-through) · #10629 / #10630 (the capture pin's origin) · #10984 (the logger: { level: 'silent' } repair, not to be reverted) · #10293 (the p1 flake signature lifted verbatim from these frames)

[claude]

Concentrated triage round: finding → pm:queue + domain:engine, Task — the #11081 remainder: three memory-driver fixtures blanket-mute a boot-class ERROR trio the existing capture helper cannot recognise (0 recognised frames measured per fixture). Fix = give the helper the missing seam (boot-trio recognition for memory/fake drivers), then land the same expected-noise pin the two SqlDriver fixtures got; blanket mutes deleted. Cross-package seam (helper in packages/runtime, fixtures engine-side) — declare the full file surface at claim.

---

Generated by Claude Code

[os-warren]

Claim: PM loop (domain:engine seat)
Session: session_01W6HFzyH98W1YaQXhJUJt6o
Branch: claude/issue-11571-memory-fixture-boot-noise-capture
Worktree: objectstack-issue-11571
Domain: domain:engine
Container & model: M, mode:subagent, model: opus
Clause-②: no — test fixtures and a test helper. ⚠️ Route B would have required widening ObjectKernelConfig to accept a logger instance, which would be a public-surface change; that route is refused by the card on mechanism, and if the work drifts toward it, stop and report.

Serial constraints cleared — this is the only clean engine surface right now

packages/drivers/driver-memory/** and the shared expected-read-refusal-noise.ts helper. No open PR touches either.

⚠️ The rest of this lane is currently serialized on packages/drivers/driver-sql/src/sql-driver.ts, measured just now: PR #12119 (bands 13485–13980), #12127 (10155–10499) and #12109 (8628–9220) are all open or enqueued and unlanded. #11627's own band (13215–13400, the MAX_KEYABLE_VARCHAR_CHARS region) overlaps #12119's, and #11567's site at :13940 sits 40 lines from #12119's last hunk — so both are queued behind it rather than dispatched. This card is the one that shares nothing with them.

Route: investigation-first, within fences

The card refuses two routes on mechanism and names C (console-level capture) as the candidate — but it is explicit that A (leave the three blanket-silent, close #11081 at 2 of 5) is a legitimate final answer, and that this card exists so that answer is chosen rather than defaulted into. So the deliverable may be "A, with the measurement that says so" — that is a success, not a failure.

⛔ Do not build route B. The kernel exposes only a logger config (kernel.ts:24), builds its own (:87), and hands it out by reference (:169), so a post-construction swap propagates only partially. A capture built on it would silently miss frames — strictly worse than the blanket mute it replaces, because a mute is honestly silent while a partial capture is silent while asserting it is not. That inversion is the thing #11081 exists to end.

⛔ Do not build route D (boot the fixtures with their driver). It changes what the fixtures exercise; "the driver arrives late" is load-bearing in record-change-integration and may be here too.

⚠️ Read #11569 before choosing — the mechanism you would extend is itself half-broken

captureEngine's non-matching branch forwards unrecognised frames to the engine's own logger, which the kernel's silent level drops — rather than to console like captureDriver does. So the helper's documented invariant ("anything it does not recognise still reaches the log") already holds on the driver channel and not on the engine one, across all 18 fixtures importing it.

⇒ If you take route C, its console patch and #11569's fix are working on the same seam and should be designed together rather than in sequence. Say which you are doing and why.

Measure first: the card records 15 / 3 / 3 unrecognised ERROR frames across the three fixtures at level: 'info', all of them one invariant boot-without-a-datasource trio. Re-measure rather than recall — and if route C's global console patch turns out to interact badly with vitest's own console handling, that measurement is the answer, and A becomes the ruling.

⛔ No live defect is asserted for these three (unlike #11081's SqlDriver half, where 109 ERROR lines were printing on main). Do not manufacture one.

---

Generated by Claude Code