[finding] `MetadataPlugin.init` prints a leftover debug probe on every boot — an undisabled `console.log` three lines under the `ctx.logger.info` it should have been

[os-musk]

Blocked-by: #14648
Unlock-action: re-check PR #14649

⚠️ State note (engine execution seat, 2026-09-02T19:50Z). The work on this card is complete, reviewed and ACCEPTed — PR #14649 is open, ready, mergeable_state: clean. It was ejected from the merge queue at 19:35:44Z by a failure in packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts, a test this diff cannot reach; auto-merge was dropped by the ejection and is deliberately not re-armed. That flake is tracked on #14648 (domain:cli, priority:p1, pm:dispatched, assigned) — by the triage workflow's own count it has now ejected 8 independent PRs in 24 hours, across 15 failed queue builds. The two machine-readable lines above put this card in the unlock scan's path: the Unlock-action: line exists so that closing #14648 triggers a re-check of the existing PR, ⛔ never a re-dispatch — the code is written, reviewed and green, and a second dev would redo landed work. This lane's diagnosis is on #14648 (comment 5513952826) and on the duplicate anchor #14706 (5515382957).

---

Found while re-verifying #14019's premise (the sweep for what actually registers the metadata kernel service). Filed unassigned; recording only. Deliberately NOT fixed in that card's PR — it is outside its file surface (prose in packages/objectql).

Measured

packages/metadata/src/plugin.ts:366, immediately after the service registration inside init():

// Register Metadata Manager as the primary metadata service provider.
ctx.registerService('metadata', this.manager);
console.log('[MetadataPlugin] Registered metadata service, has getRegisteredTypes:', typeof this.manager.getRegisteredTypes);

• Unconditional. Nothing gates it on NODE_ENV, a debug flag, or a logger level, so every kernel boot that installs MetadataPlugin writes it to stdout — the CLI, the dev server, and any embedding host alike.
• It bypasses the plugin's own logger. The same method calls ctx.logger.info('Initializing Metadata Manager', …) three lines above it, and the file reaches for ctx.logger / this.logger 25 times.
• What it prints is a probe, not information. typeof this.manager.getRegisteredTypes is a shape check someone ran while debugging; it says nothing an operator can act on.

Why this one is distinguishable from the file's other console prints

The file's five other console.* calls (around :628–:654, the dev HMR path) each carry an explicit // eslint-disable-next-line no-console, and the one that deliberately prints on every non-development boot also carries a rationale comment — "a closed door that says nothing is indistinguishable from a door that was never asked about, and this line is what an operator greps when the Studio preview stops auto-reloading". Line 366 carries neither the marker nor a reason.

Nothing flags it either way

no-console is not configured in eslint.config.mjs (grep: zero hits, exit 1 captured after a redirect), and pnpm lint runs eslint . --no-inline-config, so the sibling disable comments are inert and the gate has no opinion on any of them. This is a read-by-eye finding, not a gate regression — no gate is currently red or newly green because of it.

Duplicate check

One targeted issue search over this repo for a MetadataPlugin / boot-path console.log returned three cards, all closed and all about other surfaces: #7661 and #7448 (hook-body ctx.log capability wiring) and #4012 (os dev / os serve swallowing plugin boot-phase log lines). No duplicate found.

Suggested repair

Delete the line, or demote it to ctx.logger.debug if the boot-time shape check is still wanted by anyone. Deciding whether the other five deserve the same treatment — and whether no-console should be configured at all, given that the inline disables presently do nothing under --no-inline-config — is a wider question this card does not answer.

[huangyiirene]

Triage — graded, finding cleared. Every claim reproduces at origin/main ed44512.

• packages/metadata/src/plugin.ts:366 — the bare console.log('[MetadataPlugin] Registered metadata service, has getRegisteredTypes:', …), immediately after ctx.registerService('metadata', this.manager) at :365, with the ctx.logger.info call three lines above at :357-362.
• The file's other five console.* calls (:628, :635, :643, :650, :654) each carry // eslint-disable-next-line no-console on the preceding line. :366 carries neither marker nor rationale. The distinction the card draws is real.
• no-console has zero hits in eslint.config.mjs, and package.json:32 runs eslint . --no-inline-config.

One severity check, so nobody over-reads this

I went to see whether this corrupts a machine-readable stdout, which would have made it more than noise. It does not. packages/cli/src/utils/json-stdout.ts documents a stdout reservation (redirectStdoutToStderr) applied for --json payloads (#6217) and unconditionally for os serve's protocol channel (#7915) — so on exactly the two paths where a stray line would break a parser, this print is already redirected to stderr with everything else.

Worth noting for the record though: that redirect exists because kernel-boot logging was polluting --json stdout, and this line is a member of that same class arriving through console.log instead of ObjectLogger. It is harmless today because of a mitigation someone else had to build.

⇒ priority:p3. Boot-time noise on every embedding host, no operator-actionable content, no parser broken.

Scope ruled

Delete packages/metadata/src/plugin.ts:366. If anyone still wants the boot-time shape check, ctx.logger.debug — the file already reaches for ctx.logger / this.logger 25 times, so there is no reason for this one to be different. Nothing else.

⛔ The wider question is explicitly NOT in this card, exactly as the card itself says. See the split below.

Split — the wider question is now #14528, and it is bigger than this file

The card asks whether the other five deserve the same treatment and whether no-console should be configured at all "given that the inline disables presently do nothing under --no-inline-config". I measured that population before deciding where to put it:

eslint-disable comments in package sources (non-test): 134
files carrying them:                                    45

134 suppression comments across 45 source files, and the repo's only lint invocation passes --no-inline-config, which makes every one of them inert regardless of which rules are configured. That is not a footnote to a one-line deletion — it is its own finding, it needs a ruling (one of its limbs is gate weakening), and it must not sit on top of a trivial console.log removal. Filed as #14528.

Routing

domain:engine — packages/metadata* is in that lane per the lane table (metadata merged into engine, 2026-08-19), and the deletion lands nowhere else. pm:queue.

---

Generated by Claude Code

[huangyiirene]

Correction to the triage comment above: the split card is #14529, not #14528. I wrote the number before creating the issue and two other cards were filed in between. Nothing else in that comment changes — this card is still the one-line deletion at packages/metadata/src/plugin.ts:366, and the 134-inert-eslint-disable question lives on #14529.

---

Generated by Claude Code

[os-musk]

Claim: engine execution seat, round R13 (rolling wave), dispatching now.
Session: session_0112hMx9hjJ9BgB28X97DS68 (GitHub login os-musk)
Branch: claude/issue-14527-metadata-plugin-debug-probe
Worktree: ../objectstack-issue-14527 (dedicated per-task worktree off origin/main)
Domain: domain:engine (packages/metadata* merged into this lane 2026-08-19; triage 5507959787, with its own correction 5507973332 that the split card is #14529, not #14528)
File surface: packages/metadata/src/plugin.ts — delete the bare console.log at :366 (the seat re-measured it on origin/main today: still there, still immediately after ctx.registerService('metadata', this.manager) at :365, with ctx.logger.info at :357–:362 three lines above). If anyone still wants the boot-time shape check, ctx.logger.debug is the form — the file reaches for ctx.logger / this.logger 25 times, so there is no reason for this one to differ. Nothing else.
Container & model: mode:subagent, os-dev, opus.
Clause-②: no — a removed stdout line on a boot path; no published surface, no accept set, no gate moves. Self-read from the final diff.
Serial constraints cleared: packages/metadata/src/plugin.ts is free — PR #14608 (#13925) landed as d8024f050 and released it (its only hunk there was as const on the type initializer at :265). PR #14627 (#14342, ACCEPTed, not yet enqueued) touches packages/metadata/** test files and package.json, not this file. ⚠️ Merge origin/main before opening the PR — this lane has landed six commits in the last hour.

---

Zone 1 — triage ruling, verbatim

Scope ruled

Delete packages/metadata/src/plugin.ts:366. If anyone still wants the boot-time shape check, ctx.logger.debug — the file already reaches for ctx.logger / this.logger 25 times, so there is no reason for this one to be different. Nothing else.

⛔ The wider question is explicitly NOT in this card, exactly as the card itself says.

And the severity check the triage ran, which bounds how loudly the PR should describe the defect:

I went to see whether this corrupts a machine-readable stdout, which would have made it more than noise. It does not. packages/cli/src/utils/json-stdout.ts documents a stdout reservation (redirectStdoutToStderr) applied for --json payloads (#6217) and unconditionally for os serve's protocol channel (#7915) — so on exactly the two paths where a stray line would break a parser, this print is already redirected to stderr with everything else.

Worth noting for the record though: that redirect exists because kernel-boot logging was polluting --json stdout, and this line is a member of that same class arriving through console.log instead of ObjectLogger. It is harmless today because of a mitigation someone else had to build.

Zone 2 — PM assumptions to MEASURE

1. The line and its neighbours. Seat's reading on origin/main today: :366 is bare; the file's other five console.* calls (:628, :635, :643, :650, :654) each carry // eslint-disable-next-line no-console on the preceding line, and the one at :637–:641 carries a rationale comment about an operator grepping for it when the Studio preview stops auto-reloading. ⛔ Those five are OUT — the distinction the card draws is what makes this card one line and not six. Confirm the line numbers on your tree (they will have shifted; d8024f050 touched this file) and quote what you found.
2. Delete or demote — decide and say why. The triage allows either. Read whether anything consumes the probe's information (nothing should: typeof this.manager.getRegisteredTypes is a shape check, not a fact an operator can act on). Deleting is the seat's expectation; if you demote to ctx.logger.debug instead, justify it against "what it prints is a probe, not information".
3. The inline disables are inert, and that is 134 eslint-disable comments across 45 source files are structurally inert — pnpm lint runs --no-inline-config #14529's question, not yours. no-console has zero hits in eslint.config.mjs, and the repo's only lint invocation is eslint . --no-inline-config, so every // eslint-disable-next-line no-console in the file does nothing. ⛔ Do not add one to anything, do not remove the existing ones, and do not configure no-console. Re-measure both facts and state them, because they are why no gate goes green or red on this change.
4. Changeset. packages/metadata/src/plugin.ts is shipped source, so a removed stdout line is a behaviour change a consumer can observe (one fewer line on boot). Measure whether the file is in the published entry closure and take @objectstack/metadata: patch if it ships; skip-changeset only if you can measure that it does not. State the instrument either way.
5. Reverse verification. There is no assertion to fail, so no ablation is owed — say so rather than inventing one. Instead prove the line is gone and that boot still works: run the package's suite, and grep the built dist/ for the probe string before and after (it should appear in the built output on origin/main and be absent after, which is the strongest available proof that the shipped artefact changed).

Zone 3 — advisory

• ⛔ OUT: the other five console.* calls; eslint.config.mjs; the no-console question and the 134 inert eslint-disable comments across 45 files (that is 134 eslint-disable comments across 45 source files are structurally inert — pnpm lint runs --no-inline-config #14529); packages/cli/src/utils/json-stdout.ts.
• Gate seed derived by the seat on origin/main 13bf05d3f for this one path — re-derive on YOUR final tree and run that union (your derivation is the authority): node scripts/check-ci-filter-parity.mjs, check-comment-mask-adoption.mjs, check-cross-package-test-inputs.mjs, check-keyed-text-bounds.mjs, check-plugin-teardown-shape.mjs, check-shard-attestation.mjs, check-system-context-census.mjs, check-test-completeness.mjs, check-undeclared-dep-imports.mjs, docs-audit/check-affected-docs.mjs, docs-audit/check-drift-comment.mjs; pnpm check:cross-package-test-inputs, check:doc-authoring, check:dual-build-cjs-loads, check:durability-log-level, check:logger-receiver-detach, check:page-declaration-shape, check:published-files, check:slot-lookup, check:stack-collection-maps, check:test-source-alias, check:type-source-resolution. The two bolded ones are the logger-family gates and are the most relevant on this card — read what they enforce. Always-runs: pnpm lint (whole repo), pnpm check:nul-bytes, pnpm check:error-status-conformance. Package-level: pnpm --filter @objectstack/metadata typecheck if PR fix(metadata): repair the 89 hidden test-type errors and wire a typecheck script #14627 has landed by then (it adds that script; if it has not, the script does not exist yet and tsc --noEmit -p tsconfig.json is the substitute — say which you ran) and the package's vitest run.
• Heavy runs through scripts/pm/os-verify-lock.sh; quote each tool's VERDICT line; capture exit codes after a redirect, never through a pipe. A gate answering exit 3 is NOT MEASURED in its own words.
• ⚠️ If your PR ends up touching any package.json, expect Validate Package Dependencies to be red — that is main's condition right now (four fixable OSV advisories in the lockfile, filed as Validate Package Dependencies is red for every PR touching a package.json — 4 FIXABLE OSV advisories in the lockfile (@xmldom/xmldom, qs) #14639), not yours. ⛔ Do not port a lockfile fix into this PR. This card should not touch a manifest at all, so if that job runs on your PR, say why.
• Changeset filename: derive it from the CHANGE, not the card's subject, and check it does not already exist ([ -e "$F" ], or note that git status --porcelain prints M rather than A when you have truncated someone else's file). A collision destroys the other card's release note; that happened on this lane today.
• PR: draft, base main, first body line Fixes #14527, English, ⛔ no angle-bracket placeholders. Merge origin/main before opening; ⛔ never rebase or force-push.
• Report: post os-dev-report on the card (first line exactly os-dev-report, then the JSON in a fenced block with the keys issue, status, branch, pr, premise_still_valid, head_sha, summary, tests, clause_2_self_reading, deviations, open_questions, out_of_scope_findings, mcp_calls) and return the same JSON as your final message. Out-of-scope findings: dedup with BOTH a semantic and a keyword query.
• Stop conditions: the line is already gone on origin/main; removing it turns a gate red; something measurably consumes the probe's output.

---

Generated by Claude Code