fix(metadata): drop the leftover boot-time debug probe from MetadataPlugin.init

[os-musk]

Fixes#14527

MetadataPlugin.init() carried a bare console.log immediately after
ctx.registerService('metadata', this.manager), printing
typeof this.manager.getRegisteredTypes. Nothing gated it on NODE_ENV, a debug flag
or a logger level, so every kernel boot that installs MetadataPlugin wrote it to
stdout — the CLI, the dev server and any embedding host alike.

What changed

One line deleted from packages/metadata/src/plugin.ts, plus a changeset. The whole
contribution is 2 files changed, 30 insertions(+), 1 deletion(-), and the single
source hunk is:

 // 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);

Deleted rather than demoted to ctx.logger.debug

The triage allowed either. Deletion was chosen on two measurements:

• Nothing reads it. A repo-wide search for the printed string (has getRegisteredTypes,
  and separately Registered metadata service) returns exactly one hit: the emitting line
  itself. No test, script, doc or workflow consumes it.
• What it reported is statically known.getRegisteredTypes is a method the class
  declares, so the typeof it printed cannot vary in a way an operator could act on.
  Demoting would preserve a probe whose answer is fixed at compile time.

The ctx.logger.info('Initializing Metadata Manager', ...) call three lines above already
announces the same lifecycle step through the plugin's own logger, carrying the fields that
are actually actionable (root, watch, artifactSource).

Severity is bounded, per the triage: on the two paths where a stray stdout line would break
a parser — --json payloads and the os serve protocol channel — packages/cli already
reserves stdout by redirecting to stderr, so nothing downstream depended on this line being
present or absent.

Deliberately not touched

• The file's five other console.* calls (:627–:653 on this tree, the dev HMR path).
  Each carries // eslint-disable-next-line no-console, and the one that prints on every
  non-development boot carries a written rationale for doing so. That distinction is what
  makes this a one-line change and not a six-line one. The file's console.* count went
  6 -> 5 and its eslint-disable count stayed at 5.
• eslint.config.mjs and the no-console question. No inline disable was added, none
  was removed, and the rule was not configured. That question, and the inert-suppression
  population behind it, is the separate card 134 eslint-disable comments across 45 source files are structurally inert — pnpm lint runs --no-inline-config #14529.

Why no gate moves in either direction here

Re-measured on this tree, with eslint's own resolved config rather than a text search:

$ eslint --print-config packages/metadata/src/plugin.ts
resolved rules for this file: 6
no-console entry: null
any rule name containing "console": []
$ grep -n '"lint"' package.json
32: "lint": "node --stack-size=4000 node_modules/eslint/bin/eslint.js . --no-inline-config"

no-console is not configured, and the repo's only lint invocation passes
--no-inline-config, so the sibling disable comments are inert. Repo-wide pnpm lint is
green (exit 0, no output, 118s) while the file still contains five console.* calls — which
is the positive control that the rule really is off. This change therefore turns no gate
green and no gate red.

Measurements

Everything below was run at head 9d4221244, after merging origin/main.

The shipped artefact moved. No assertion exists to ablate, so no ablation is owed; the
proof is the built output instead. grep -rn 'has getRegisteredTypes' dist/ in
packages/metadata:

	before	after
probe string in dist/	8 hits (index.js, index.cjs, node.js, node.cjs + 4 sourcemaps)	0
control: sibling HMR print	8 files	8 files
control: the logger.info above it	8 files	8 files

Both controls still hold, so the zero is a real absence rather than a broken grep or an
unbuilt dist/. The probe is likewise absent from the 677-test run log, in which the
sibling console.log still appears 17 times.

Tests.pnpm --filter @objectstack/metadata exec vitest run --maxWorkers=2 —
Test Files 43 passed (43), Tests 677 passed (677).

Type check.@objectstack/metadata has no typecheck script on this tree (PR #14627,
which adds it, has not landed), so the substitute was
pnpm --filter @objectstack/metadata exec tsc --noEmit -p tsconfig.json. It reports 89
errors — all 89 in *.test.ts files, zero in plugin.ts and zero in any non-test file. A
reverse check confirms they are pre-existing rather than mine: restoring the pre-change
plugin.ts from the merge base and re-running gives the same 89, also with zero in
plugin.ts. The restore was verified by blob hash (8e4d1e3c... on disk equals the HEAD
blob) with an empty git diff HEAD. --listFiles confirms plugin.ts is in the program
that was checked.

Gates. The family union was re-derived from the actual change set on this tree
(node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, 2 paths vs merge
base ca48cf377) and gives 30 families — identical before and after the merge. 27 are
green. Three answer exit 3, which each script's own verdict text defines as NOT MEASURED
rather than a failure, and none for a reason this change can influence:

• check-test-completeness.mjs — needs a saved turbo run test log as an argument; the
  derived family names it with none, which the script documents as the unreachable branch
  ("record this gate as NOT MEASURED; it is not a red").
• scripts/pm/check-half-states.mjs — needs repo-scoped REST egress, which this container
  refuses (a direct REST probe answers 403). It sweeps the PM board, not this diff. Its
  --self-test wrapper, pnpm check:pm-half-states, is green at 2062 cases.
• check:dual-build-cjs-loads — PREREQUISITE NOT MET: it reads built output and 57
  packages have no dist/ in this worktree. Its --self-test is green at 93 cases, and the
  property it asserts was checked directly for the package this PR touches: all four
  published require entries of @objectstack/metadata (index.cjs, node.cjs,
  errors.cjs, migrations/index.cjs) load, with MetadataPlugin exported as a function.

Always-runs: pnpm lint green (full repo, not narrowed), pnpm check:nul-bytes green
(7991 files), pnpm check:error-status-conformance green.

Changeset.@objectstack/metadata: patch. The file is in the published entry closure,
measured three ways: src/index.ts:14 re-exports MetadataPlugin from ./plugin.js; the
manifest ships "files": ["dist"] with exports["."] resolving to ./dist/index.js and
publishConfig.access: public; and pnpm check:published-files counts this package among
the 69 publishable members with a files whitelist and an exports map. Most directly, the
probe string was physically present in the shipped bundles before this change. One fewer
line on boot is observable, so skip-changeset would have been wrong.

This PR touches no package.json, so Validate Package Dependencies should not run on it.
That job is red on main for four lockfile advisories tracked in #14639, and no lockfile
change is carried here.

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata, touching 1 documentable anchor(s).

5 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/api/index.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/automation/flows.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/protocol/kernel/metadata-service.mdx(via MetadataPlugin (symbol, a top-level class))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx(via MetadataPlugin (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 12 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 — the merge of head 9d422124467501b60af0f1885d7a78b5c77d5bb9 into base 20b883918aa787e65299e72b85c2b3396aa2006f, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 && git checkout 8bd18a6f4e2db0764aa87b42e38e373abcd5f266
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 20b883918aa787e65299e72b85c2b3396aa2006f 9d422124467501b60af0f1885d7a78b5c77d5bb9 && git checkout -B drift-repro 20b883918aa787e65299e72b85c2b3396aa2006f && git merge --no-ff 9d422124467501b60af0f1885d7a78b5c77d5bb9
node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 20b883918aa787e65299e72b85c2b3396aa2006f → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Landing provenance (engine execution seat, session session_0112hMx9hjJ9BgB28X97DS68): flipped ready at 17:50Z and armed auto-merge (squash) at 17:51:32Z on head 9d4221244. The echo read method: MERGE; the queue build ref is the arming reading, not the echo.

• Review: ACCEPT on the card. Clause-② no, self-read from the final diff — one deleted console.log, nothing published changes shape.
• Governed-surface test on the two changed paths: 0 of 2 governed — ordinary queue landing.
• Enqueue bar: all 33 check runs on 9d4221244 completed success or skipped, read with perPage: 50.

The red on this head was diagnosed, not waited out.Test Core (1/6) failed at 17:15:22Z on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts:317 (AssertionError: expected 'SIGKILL' to be null). Established as not this PR's before the one permitted re-run was spent:

• the diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0;
• removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure, not toward it;
• Test Core (1/6) was green on test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629, test(objectql): declare the recorded-by fixture's lookup with the canonical reference key #14633 and fix(lint): teach describe() the live-elsewhere verdict instead of throwing #14632 within the preceding hour, all of which include @objectstack/cli;
• the assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports that the harness's own 40s cap won a race, in a shard reporting Duration 843.94s against tests 2151.97s.

The re-run on the identical head, with no push and no rebase, passed at 17:45:27Z. Red then green on a byte-identical tree is the controlled A/B, and it is now recorded on the queue-flake anchor #14648 (comment 5513952826) together with the shape of a real fix. That anchor is domain:cli; this lane contributed the measurement and ⛔ did not claim it, relabel it, or weaken the test.

⚠️ Known exposure, stated rather than discovered later: the queue build runs the full suite, so this PR meets that same packages/cli test again on its queue build. #14629 was ejected on it at 17:45Z. If this PR is ejected the same way, the disposition is the same — ⛔ no second re-run, ⛔ no re-queue while #14648 is open and unfixed, and the failure goes on the record rather than into another full-queue round.

Owed by the seat at MERGED: verify by content on origin/main that the probe line is gone from packages/metadata/src/plugin.ts and that the five sibling console.* calls remain, strip pm:dispatched from #14527, landing record on the card, inventory reconciliation.

---

Generated by Claude Code

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 33671786568 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (1/6) — 失败步骤: Run this shard's tests

  @objectstack/cli:test: FAIL integration test/run-dev-unbuilt-workspace.e2e.test.ts > the mirror direction: a reader that is never coming back > gives up and exits instead of waiting forever
  ↳ 失败原因: @objectstack/cli:test: AssertionError: expected 'SIGKILL' to be null
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• test/run-dev-unbuilt-workspace.e2e.test.ts — 24h 内已弹出 8 个互相独立的 PR（fix(objectql,runtime,rest): store a serializable manifest projection in the package registry #14499、fix(devx): guard the last two run-on-import gate scripts — KNOWN_IMPORT_UNSAFE 2 to 0 #14593、lint(flows): warn on an uncontained loop body and on a try_catch with no catch, and document loop { try_catch } #14617、test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629、fix(cli): let the dev artifact door own stack-declared security metadata on a host config #14631、fix(metadata): drop the leftover boot-time debug probe from MetadataPlugin.init #14649、fix(objectql,metadata): derive a view container's object through the shared helper, so the row's own name is LAST at every SOURCE registrar (#14399) #14665、fix(cli): remove the ghost field types from generate.ts's three vocabularies #14675）。汇总 issue：Queue-flake anchor: test/run-dev-unbuilt-workspace.e2e.test.ts #14706（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 15 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)

[os-musk]

Ejected from the merge queue at 19:35:44Z — not this PR's failure, and deliberately NOT re-queued

Engine execution seat (session session_0112hMx9hjJ9BgB28X97DS68), reading queue build 33671786568.

What failed:Test Core (1/6) on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts — AssertionError: expected 'SIGKILL' to be null. The same signature that ejected #14629 at 17:45Z.

Verified by content that nothing landed:git grep -c "has getRegisteredTypes" origin/main -- packages/metadata/src/plugin.ts still returns 1, against a control of 14 console occurrences in the same file. The probe line this PR deletes is still on main, so this was an ejection and not a quiet landing.

Why it is not this PR's. The diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0. Removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure.

Why it is not a regression at all. The assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports only that the harness's own 40-second cap beat the child's exit. The decisive evidence is on this very PR: the same test, same assertion, failed on the PR side at 17:15:22Z and passed on a re-run of the identical head — no push, no rebase — at 17:45:27Z. A test red and green on a byte-identical tree is not measuring the tree.

⭐ The class has escalated since that first stand-down. The triage workflow's own count is now 8 independent PRs in 24 hours (#14499, #14593, #14617, #14629, #14631, #14649, #14665, #14675) across 15 failed queue builds, and it states that figure as a lower bound. Anchor: #14648 (domain:cli, priority:p1, pm:dispatched, assigned) — the card with an owner — plus the auto-filed duplicate #14706 which carries the current count. This lane's full diagnosis and the shape of a real fix are on both (5513952826 and 5515382957): the only option that closes the class is to assert the child's own exit reason instead of the absence of a signal, taking the wall clock out of the oracle.

Why this PR is not being re-queued. The triage workflow's checklist, item 2: once an aggregation issue exists, re-queuing before the fix only burns another full-queue round for every PR behind it — and with 15 failed builds in 24h that cost is now measurably superlinear. ⛔ No re-queue while the anchor is open and unfixed. ⛔ The test is not being skipped, quarantined, relaxed or re-baselined by this lane, and no second re-run has been spent — weakening a gate stays a human act and none of it is ours to do.

State: PR stays open, ready, mergeable_state: clean; auto-merge not re-armed. Card #14527 moved to pm:blocked with body lines Blocked-by: #14648 and Unlock-action: re-check PR #14649 — that second line is what stops the unlock scan re-dispatching finished, reviewed, green work when the anchor closes.

---

Generated by Claude Code

[os-musk]

Fixes#14527

MetadataPlugin.init() carried a bare console.log immediately after
ctx.registerService('metadata', this.manager), printing
typeof this.manager.getRegisteredTypes. Nothing gated it on NODE_ENV, a debug flag
or a logger level, so every kernel boot that installs MetadataPlugin wrote it to
stdout — the CLI, the dev server and any embedding host alike.

What changed

One line deleted from packages/metadata/src/plugin.ts, plus a changeset. The whole
contribution is 2 files changed, 30 insertions(+), 1 deletion(-), and the single
source hunk is:

 // 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);

Deleted rather than demoted to ctx.logger.debug

The triage allowed either. Deletion was chosen on two measurements:

• Nothing reads it. A repo-wide search for the printed string (has getRegisteredTypes,
  and separately Registered metadata service) returns exactly one hit: the emitting line
  itself. No test, script, doc or workflow consumes it.
• What it reported is statically known.getRegisteredTypes is a method the class
  declares, so the typeof it printed cannot vary in a way an operator could act on.
  Demoting would preserve a probe whose answer is fixed at compile time.

The ctx.logger.info('Initializing Metadata Manager', ...) call three lines above already
announces the same lifecycle step through the plugin's own logger, carrying the fields that
are actually actionable (root, watch, artifactSource).

Severity is bounded, per the triage: on the two paths where a stray stdout line would break
a parser — --json payloads and the os serve protocol channel — packages/cli already
reserves stdout by redirecting to stderr, so nothing downstream depended on this line being
present or absent.

Deliberately not touched

• The file's five other console.* calls (:627–:653 on this tree, the dev HMR path).
  Each carries // eslint-disable-next-line no-console, and the one that prints on every
  non-development boot carries a written rationale for doing so. That distinction is what
  makes this a one-line change and not a six-line one. The file's console.* count went
  6 -> 5 and its eslint-disable count stayed at 5.
• eslint.config.mjs and the no-console question. No inline disable was added, none
  was removed, and the rule was not configured. That question, and the inert-suppression
  population behind it, is the separate card 134 eslint-disable comments across 45 source files are structurally inert — pnpm lint runs --no-inline-config #14529.

Why no gate moves in either direction here

Re-measured on this tree, with eslint's own resolved config rather than a text search:

$ eslint --print-config packages/metadata/src/plugin.ts
resolved rules for this file: 6
no-console entry: null
any rule name containing "console": []
$ grep -n '"lint"' package.json
32: "lint": "node --stack-size=4000 node_modules/eslint/bin/eslint.js . --no-inline-config"

no-console is not configured, and the repo's only lint invocation passes
--no-inline-config, so the sibling disable comments are inert. Repo-wide pnpm lint is
green (exit 0, no output, 118s) while the file still contains five console.* calls — which
is the positive control that the rule really is off. This change therefore turns no gate
green and no gate red.

Measurements

Everything below was run at head 9d4221244, after merging origin/main.

The shipped artefact moved. No assertion exists to ablate, so no ablation is owed; the
proof is the built output instead. grep -rn 'has getRegisteredTypes' dist/ in
packages/metadata:

	before	after
probe string in dist/	8 hits (index.js, index.cjs, node.js, node.cjs + 4 sourcemaps)	0
control: sibling HMR print	8 files	8 files
control: the logger.info above it	8 files	8 files

Both controls still hold, so the zero is a real absence rather than a broken grep or an
unbuilt dist/. The probe is likewise absent from the 677-test run log, in which the
sibling console.log still appears 17 times.

Tests.pnpm --filter @objectstack/metadata exec vitest run --maxWorkers=2 —
Test Files 43 passed (43), Tests 677 passed (677).

Type check.@objectstack/metadata has no typecheck script on this tree (PR #14627,
which adds it, has not landed), so the substitute was
pnpm --filter @objectstack/metadata exec tsc --noEmit -p tsconfig.json. It reports 89
errors — all 89 in *.test.ts files, zero in plugin.ts and zero in any non-test file. A
reverse check confirms they are pre-existing rather than mine: restoring the pre-change
plugin.ts from the merge base and re-running gives the same 89, also with zero in
plugin.ts. The restore was verified by blob hash (8e4d1e3c... on disk equals the HEAD
blob) with an empty git diff HEAD. --listFiles confirms plugin.ts is in the program
that was checked.

Gates. The family union was re-derived from the actual change set on this tree
(node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, 2 paths vs merge
base ca48cf377) and gives 30 families — identical before and after the merge. 27 are
green. Three answer exit 3, which each script's own verdict text defines as NOT MEASURED
rather than a failure, and none for a reason this change can influence:

• check-test-completeness.mjs — needs a saved turbo run test log as an argument; the
  derived family names it with none, which the script documents as the unreachable branch
  ("record this gate as NOT MEASURED; it is not a red").
• scripts/pm/check-half-states.mjs — needs repo-scoped REST egress, which this container
  refuses (a direct REST probe answers 403). It sweeps the PM board, not this diff. Its
  --self-test wrapper, pnpm check:pm-half-states, is green at 2062 cases.
• check:dual-build-cjs-loads — PREREQUISITE NOT MET: it reads built output and 57
  packages have no dist/ in this worktree. Its --self-test is green at 93 cases, and the
  property it asserts was checked directly for the package this PR touches: all four
  published require entries of @objectstack/metadata (index.cjs, node.cjs,
  errors.cjs, migrations/index.cjs) load, with MetadataPlugin exported as a function.

Always-runs: pnpm lint green (full repo, not narrowed), pnpm check:nul-bytes green
(7991 files), pnpm check:error-status-conformance green.

Changeset.@objectstack/metadata: patch. The file is in the published entry closure,
measured three ways: src/index.ts:14 re-exports MetadataPlugin from ./plugin.js; the
manifest ships "files": ["dist"] with exports["."] resolving to ./dist/index.js and
publishConfig.access: public; and pnpm check:published-files counts this package among
the 69 publishable members with a files whitelist and an exports map. Most directly, the
probe string was physically present in the shipped bundles before this change. One fewer
line on boot is observable, so skip-changeset would have been wrong.

This PR touches no package.json, so Validate Package Dependencies should not run on it.
That job is red on main for four lockfile advisories tracked in #14639, and no lockfile
change is carried here.

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata, touching 1 documentable anchor(s).

5 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/api/index.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/automation/flows.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/protocol/kernel/metadata-service.mdx(via MetadataPlugin (symbol, a top-level class))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx(via MetadataPlugin (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 12 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 — the merge of head 9d422124467501b60af0f1885d7a78b5c77d5bb9 into base 20b883918aa787e65299e72b85c2b3396aa2006f, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 && git checkout 8bd18a6f4e2db0764aa87b42e38e373abcd5f266
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 20b883918aa787e65299e72b85c2b3396aa2006f 9d422124467501b60af0f1885d7a78b5c77d5bb9 && git checkout -B drift-repro 20b883918aa787e65299e72b85c2b3396aa2006f && git merge --no-ff 9d422124467501b60af0f1885d7a78b5c77d5bb9
node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 20b883918aa787e65299e72b85c2b3396aa2006f → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Landing provenance (engine execution seat, session session_0112hMx9hjJ9BgB28X97DS68): flipped ready at 17:50Z and armed auto-merge (squash) at 17:51:32Z on head 9d4221244. The echo read method: MERGE; the queue build ref is the arming reading, not the echo.

• Review: ACCEPT on the card. Clause-② no, self-read from the final diff — one deleted console.log, nothing published changes shape.
• Governed-surface test on the two changed paths: 0 of 2 governed — ordinary queue landing.
• Enqueue bar: all 33 check runs on 9d4221244 completed success or skipped, read with perPage: 50.

The red on this head was diagnosed, not waited out.Test Core (1/6) failed at 17:15:22Z on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts:317 (AssertionError: expected 'SIGKILL' to be null). Established as not this PR's before the one permitted re-run was spent:

• the diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0;
• removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure, not toward it;
• Test Core (1/6) was green on test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629, test(objectql): declare the recorded-by fixture's lookup with the canonical reference key #14633 and fix(lint): teach describe() the live-elsewhere verdict instead of throwing #14632 within the preceding hour, all of which include @objectstack/cli;
• the assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports that the harness's own 40s cap won a race, in a shard reporting Duration 843.94s against tests 2151.97s.

The re-run on the identical head, with no push and no rebase, passed at 17:45:27Z. Red then green on a byte-identical tree is the controlled A/B, and it is now recorded on the queue-flake anchor #14648 (comment 5513952826) together with the shape of a real fix. That anchor is domain:cli; this lane contributed the measurement and ⛔ did not claim it, relabel it, or weaken the test.

⚠️ Known exposure, stated rather than discovered later: the queue build runs the full suite, so this PR meets that same packages/cli test again on its queue build. #14629 was ejected on it at 17:45Z. If this PR is ejected the same way, the disposition is the same — ⛔ no second re-run, ⛔ no re-queue while #14648 is open and unfixed, and the failure goes on the record rather than into another full-queue round.

Owed by the seat at MERGED: verify by content on origin/main that the probe line is gone from packages/metadata/src/plugin.ts and that the five sibling console.* calls remain, strip pm:dispatched from #14527, landing record on the card, inventory reconciliation.

---

Generated by Claude Code

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 33671786568 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (1/6) — 失败步骤: Run this shard's tests

  @objectstack/cli:test: FAIL integration test/run-dev-unbuilt-workspace.e2e.test.ts > the mirror direction: a reader that is never coming back > gives up and exits instead of waiting forever
  ↳ 失败原因: @objectstack/cli:test: AssertionError: expected 'SIGKILL' to be null
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• test/run-dev-unbuilt-workspace.e2e.test.ts — 24h 内已弹出 8 个互相独立的 PR（fix(objectql,runtime,rest): store a serializable manifest projection in the package registry #14499、fix(devx): guard the last two run-on-import gate scripts — KNOWN_IMPORT_UNSAFE 2 to 0 #14593、lint(flows): warn on an uncontained loop body and on a try_catch with no catch, and document loop { try_catch } #14617、test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629、fix(cli): let the dev artifact door own stack-declared security metadata on a host config #14631、fix(metadata): drop the leftover boot-time debug probe from MetadataPlugin.init #14649、fix(objectql,metadata): derive a view container's object through the shared helper, so the row's own name is LAST at every SOURCE registrar (#14399) #14665、fix(cli): remove the ghost field types from generate.ts's three vocabularies #14675）。汇总 issue：Queue-flake anchor: test/run-dev-unbuilt-workspace.e2e.test.ts #14706（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 15 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)

[os-musk]

Ejected from the merge queue at 19:35:44Z — not this PR's failure, and deliberately NOT re-queued

Engine execution seat (session session_0112hMx9hjJ9BgB28X97DS68), reading queue build 33671786568.

What failed:Test Core (1/6) on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts — AssertionError: expected 'SIGKILL' to be null. The same signature that ejected #14629 at 17:45Z.

Verified by content that nothing landed:git grep -c "has getRegisteredTypes" origin/main -- packages/metadata/src/plugin.ts still returns 1, against a control of 14 console occurrences in the same file. The probe line this PR deletes is still on main, so this was an ejection and not a quiet landing.

Why it is not this PR's. The diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0. Removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure.

Why it is not a regression at all. The assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports only that the harness's own 40-second cap beat the child's exit. The decisive evidence is on this very PR: the same test, same assertion, failed on the PR side at 17:15:22Z and passed on a re-run of the identical head — no push, no rebase — at 17:45:27Z. A test red and green on a byte-identical tree is not measuring the tree.

⭐ The class has escalated since that first stand-down. The triage workflow's own count is now 8 independent PRs in 24 hours (#14499, #14593, #14617, #14629, #14631, #14649, #14665, #14675) across 15 failed queue builds, and it states that figure as a lower bound. Anchor: #14648 (domain:cli, priority:p1, pm:dispatched, assigned) — the card with an owner — plus the auto-filed duplicate #14706 which carries the current count. This lane's full diagnosis and the shape of a real fix are on both (5513952826 and 5515382957): the only option that closes the class is to assert the child's own exit reason instead of the absence of a signal, taking the wall clock out of the oracle.

Why this PR is not being re-queued. The triage workflow's checklist, item 2: once an aggregation issue exists, re-queuing before the fix only burns another full-queue round for every PR behind it — and with 15 failed builds in 24h that cost is now measurably superlinear. ⛔ No re-queue while the anchor is open and unfixed. ⛔ The test is not being skipped, quarantined, relaxed or re-baselined by this lane, and no second re-run has been spent — weakening a gate stays a human act and none of it is ours to do.

State: PR stays open, ready, mergeable_state: clean; auto-merge not re-armed. Card #14527 moved to pm:blocked with body lines Blocked-by: #14648 and Unlock-action: re-check PR #14649 — that second line is what stops the unlock scan re-dispatching finished, reviewed, green work when the anchor closes.

---

Generated by Claude Code

[os-musk]

Fixes#14527

MetadataPlugin.init() carried a bare console.log immediately after
ctx.registerService('metadata', this.manager), printing
typeof this.manager.getRegisteredTypes. Nothing gated it on NODE_ENV, a debug flag
or a logger level, so every kernel boot that installs MetadataPlugin wrote it to
stdout — the CLI, the dev server and any embedding host alike.

What changed

One line deleted from packages/metadata/src/plugin.ts, plus a changeset. The whole
contribution is 2 files changed, 30 insertions(+), 1 deletion(-), and the single
source hunk is:

 // 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);

Deleted rather than demoted to ctx.logger.debug

The triage allowed either. Deletion was chosen on two measurements:

• Nothing reads it. A repo-wide search for the printed string (has getRegisteredTypes,
  and separately Registered metadata service) returns exactly one hit: the emitting line
  itself. No test, script, doc or workflow consumes it.
• What it reported is statically known.getRegisteredTypes is a method the class
  declares, so the typeof it printed cannot vary in a way an operator could act on.
  Demoting would preserve a probe whose answer is fixed at compile time.

The ctx.logger.info('Initializing Metadata Manager', ...) call three lines above already
announces the same lifecycle step through the plugin's own logger, carrying the fields that
are actually actionable (root, watch, artifactSource).

Severity is bounded, per the triage: on the two paths where a stray stdout line would break
a parser — --json payloads and the os serve protocol channel — packages/cli already
reserves stdout by redirecting to stderr, so nothing downstream depended on this line being
present or absent.

Deliberately not touched

• The file's five other console.* calls (:627–:653 on this tree, the dev HMR path).
  Each carries // eslint-disable-next-line no-console, and the one that prints on every
  non-development boot carries a written rationale for doing so. That distinction is what
  makes this a one-line change and not a six-line one. The file's console.* count went
  6 -> 5 and its eslint-disable count stayed at 5.
• eslint.config.mjs and the no-console question. No inline disable was added, none
  was removed, and the rule was not configured. That question, and the inert-suppression
  population behind it, is the separate card 134 eslint-disable comments across 45 source files are structurally inert — pnpm lint runs --no-inline-config #14529.

Why no gate moves in either direction here

Re-measured on this tree, with eslint's own resolved config rather than a text search:

$ eslint --print-config packages/metadata/src/plugin.ts
resolved rules for this file: 6
no-console entry: null
any rule name containing "console": []
$ grep -n '"lint"' package.json
32: "lint": "node --stack-size=4000 node_modules/eslint/bin/eslint.js . --no-inline-config"

no-console is not configured, and the repo's only lint invocation passes
--no-inline-config, so the sibling disable comments are inert. Repo-wide pnpm lint is
green (exit 0, no output, 118s) while the file still contains five console.* calls — which
is the positive control that the rule really is off. This change therefore turns no gate
green and no gate red.

Measurements

Everything below was run at head 9d4221244, after merging origin/main.

The shipped artefact moved. No assertion exists to ablate, so no ablation is owed; the
proof is the built output instead. grep -rn 'has getRegisteredTypes' dist/ in
packages/metadata:

	before	after
probe string in dist/	8 hits (index.js, index.cjs, node.js, node.cjs + 4 sourcemaps)	0
control: sibling HMR print	8 files	8 files
control: the logger.info above it	8 files	8 files

Both controls still hold, so the zero is a real absence rather than a broken grep or an
unbuilt dist/. The probe is likewise absent from the 677-test run log, in which the
sibling console.log still appears 17 times.

Tests.pnpm --filter @objectstack/metadata exec vitest run --maxWorkers=2 —
Test Files 43 passed (43), Tests 677 passed (677).

Type check.@objectstack/metadata has no typecheck script on this tree (PR #14627,
which adds it, has not landed), so the substitute was
pnpm --filter @objectstack/metadata exec tsc --noEmit -p tsconfig.json. It reports 89
errors — all 89 in *.test.ts files, zero in plugin.ts and zero in any non-test file. A
reverse check confirms they are pre-existing rather than mine: restoring the pre-change
plugin.ts from the merge base and re-running gives the same 89, also with zero in
plugin.ts. The restore was verified by blob hash (8e4d1e3c... on disk equals the HEAD
blob) with an empty git diff HEAD. --listFiles confirms plugin.ts is in the program
that was checked.

Gates. The family union was re-derived from the actual change set on this tree
(node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, 2 paths vs merge
base ca48cf377) and gives 30 families — identical before and after the merge. 27 are
green. Three answer exit 3, which each script's own verdict text defines as NOT MEASURED
rather than a failure, and none for a reason this change can influence:

• check-test-completeness.mjs — needs a saved turbo run test log as an argument; the
  derived family names it with none, which the script documents as the unreachable branch
  ("record this gate as NOT MEASURED; it is not a red").
• scripts/pm/check-half-states.mjs — needs repo-scoped REST egress, which this container
  refuses (a direct REST probe answers 403). It sweeps the PM board, not this diff. Its
  --self-test wrapper, pnpm check:pm-half-states, is green at 2062 cases.
• check:dual-build-cjs-loads — PREREQUISITE NOT MET: it reads built output and 57
  packages have no dist/ in this worktree. Its --self-test is green at 93 cases, and the
  property it asserts was checked directly for the package this PR touches: all four
  published require entries of @objectstack/metadata (index.cjs, node.cjs,
  errors.cjs, migrations/index.cjs) load, with MetadataPlugin exported as a function.

Always-runs: pnpm lint green (full repo, not narrowed), pnpm check:nul-bytes green
(7991 files), pnpm check:error-status-conformance green.

Changeset.@objectstack/metadata: patch. The file is in the published entry closure,
measured three ways: src/index.ts:14 re-exports MetadataPlugin from ./plugin.js; the
manifest ships "files": ["dist"] with exports["."] resolving to ./dist/index.js and
publishConfig.access: public; and pnpm check:published-files counts this package among
the 69 publishable members with a files whitelist and an exports map. Most directly, the
probe string was physically present in the shipped bundles before this change. One fewer
line on boot is observable, so skip-changeset would have been wrong.

This PR touches no package.json, so Validate Package Dependencies should not run on it.
That job is red on main for four lockfile advisories tracked in #14639, and no lockfile
change is carried here.

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata, touching 1 documentable anchor(s).

5 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/api/index.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/automation/flows.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/protocol/kernel/metadata-service.mdx(via MetadataPlugin (symbol, a top-level class))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx(via MetadataPlugin (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 12 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 — the merge of head 9d422124467501b60af0f1885d7a78b5c77d5bb9 into base 20b883918aa787e65299e72b85c2b3396aa2006f, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 && git checkout 8bd18a6f4e2db0764aa87b42e38e373abcd5f266
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 20b883918aa787e65299e72b85c2b3396aa2006f 9d422124467501b60af0f1885d7a78b5c77d5bb9 && git checkout -B drift-repro 20b883918aa787e65299e72b85c2b3396aa2006f && git merge --no-ff 9d422124467501b60af0f1885d7a78b5c77d5bb9
node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 20b883918aa787e65299e72b85c2b3396aa2006f → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Landing provenance (engine execution seat, session session_0112hMx9hjJ9BgB28X97DS68): flipped ready at 17:50Z and armed auto-merge (squash) at 17:51:32Z on head 9d4221244. The echo read method: MERGE; the queue build ref is the arming reading, not the echo.

• Review: ACCEPT on the card. Clause-② no, self-read from the final diff — one deleted console.log, nothing published changes shape.
• Governed-surface test on the two changed paths: 0 of 2 governed — ordinary queue landing.
• Enqueue bar: all 33 check runs on 9d4221244 completed success or skipped, read with perPage: 50.

The red on this head was diagnosed, not waited out.Test Core (1/6) failed at 17:15:22Z on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts:317 (AssertionError: expected 'SIGKILL' to be null). Established as not this PR's before the one permitted re-run was spent:

• the diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0;
• removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure, not toward it;
• Test Core (1/6) was green on test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629, test(objectql): declare the recorded-by fixture's lookup with the canonical reference key #14633 and fix(lint): teach describe() the live-elsewhere verdict instead of throwing #14632 within the preceding hour, all of which include @objectstack/cli;
• the assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports that the harness's own 40s cap won a race, in a shard reporting Duration 843.94s against tests 2151.97s.

The re-run on the identical head, with no push and no rebase, passed at 17:45:27Z. Red then green on a byte-identical tree is the controlled A/B, and it is now recorded on the queue-flake anchor #14648 (comment 5513952826) together with the shape of a real fix. That anchor is domain:cli; this lane contributed the measurement and ⛔ did not claim it, relabel it, or weaken the test.

⚠️ Known exposure, stated rather than discovered later: the queue build runs the full suite, so this PR meets that same packages/cli test again on its queue build. #14629 was ejected on it at 17:45Z. If this PR is ejected the same way, the disposition is the same — ⛔ no second re-run, ⛔ no re-queue while #14648 is open and unfixed, and the failure goes on the record rather than into another full-queue round.

Owed by the seat at MERGED: verify by content on origin/main that the probe line is gone from packages/metadata/src/plugin.ts and that the five sibling console.* calls remain, strip pm:dispatched from #14527, landing record on the card, inventory reconciliation.

---

Generated by Claude Code

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 33671786568 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (1/6) — 失败步骤: Run this shard's tests

  @objectstack/cli:test: FAIL integration test/run-dev-unbuilt-workspace.e2e.test.ts > the mirror direction: a reader that is never coming back > gives up and exits instead of waiting forever
  ↳ 失败原因: @objectstack/cli:test: AssertionError: expected 'SIGKILL' to be null
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• test/run-dev-unbuilt-workspace.e2e.test.ts — 24h 内已弹出 8 个互相独立的 PR（fix(objectql,runtime,rest): store a serializable manifest projection in the package registry #14499、fix(devx): guard the last two run-on-import gate scripts — KNOWN_IMPORT_UNSAFE 2 to 0 #14593、lint(flows): warn on an uncontained loop body and on a try_catch with no catch, and document loop { try_catch } #14617、test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629、fix(cli): let the dev artifact door own stack-declared security metadata on a host config #14631、fix(metadata): drop the leftover boot-time debug probe from MetadataPlugin.init #14649、fix(objectql,metadata): derive a view container's object through the shared helper, so the row's own name is LAST at every SOURCE registrar (#14399) #14665、fix(cli): remove the ghost field types from generate.ts's three vocabularies #14675）。汇总 issue：Queue-flake anchor: test/run-dev-unbuilt-workspace.e2e.test.ts #14706（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 15 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)

[os-musk]

Ejected from the merge queue at 19:35:44Z — not this PR's failure, and deliberately NOT re-queued

Engine execution seat (session session_0112hMx9hjJ9BgB28X97DS68), reading queue build 33671786568.

What failed:Test Core (1/6) on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts — AssertionError: expected 'SIGKILL' to be null. The same signature that ejected #14629 at 17:45Z.

Verified by content that nothing landed:git grep -c "has getRegisteredTypes" origin/main -- packages/metadata/src/plugin.ts still returns 1, against a control of 14 console occurrences in the same file. The probe line this PR deletes is still on main, so this was an ejection and not a quiet landing.

Why it is not this PR's. The diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0. Removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure.

Why it is not a regression at all. The assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports only that the harness's own 40-second cap beat the child's exit. The decisive evidence is on this very PR: the same test, same assertion, failed on the PR side at 17:15:22Z and passed on a re-run of the identical head — no push, no rebase — at 17:45:27Z. A test red and green on a byte-identical tree is not measuring the tree.

⭐ The class has escalated since that first stand-down. The triage workflow's own count is now 8 independent PRs in 24 hours (#14499, #14593, #14617, #14629, #14631, #14649, #14665, #14675) across 15 failed queue builds, and it states that figure as a lower bound. Anchor: #14648 (domain:cli, priority:p1, pm:dispatched, assigned) — the card with an owner — plus the auto-filed duplicate #14706 which carries the current count. This lane's full diagnosis and the shape of a real fix are on both (5513952826 and 5515382957): the only option that closes the class is to assert the child's own exit reason instead of the absence of a signal, taking the wall clock out of the oracle.

Why this PR is not being re-queued. The triage workflow's checklist, item 2: once an aggregation issue exists, re-queuing before the fix only burns another full-queue round for every PR behind it — and with 15 failed builds in 24h that cost is now measurably superlinear. ⛔ No re-queue while the anchor is open and unfixed. ⛔ The test is not being skipped, quarantined, relaxed or re-baselined by this lane, and no second re-run has been spent — weakening a gate stays a human act and none of it is ours to do.

State: PR stays open, ready, mergeable_state: clean; auto-merge not re-armed. Card #14527 moved to pm:blocked with body lines Blocked-by: #14648 and Unlock-action: re-check PR #14649 — that second line is what stops the unlock scan re-dispatching finished, reviewed, green work when the anchor closes.

---

Generated by Claude Code

[os-musk]

Fixes#14527

MetadataPlugin.init() carried a bare console.log immediately after
ctx.registerService('metadata', this.manager), printing
typeof this.manager.getRegisteredTypes. Nothing gated it on NODE_ENV, a debug flag
or a logger level, so every kernel boot that installs MetadataPlugin wrote it to
stdout — the CLI, the dev server and any embedding host alike.

What changed

One line deleted from packages/metadata/src/plugin.ts, plus a changeset. The whole
contribution is 2 files changed, 30 insertions(+), 1 deletion(-), and the single
source hunk is:

 // 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);

Deleted rather than demoted to ctx.logger.debug

The triage allowed either. Deletion was chosen on two measurements:

• Nothing reads it. A repo-wide search for the printed string (has getRegisteredTypes,
  and separately Registered metadata service) returns exactly one hit: the emitting line
  itself. No test, script, doc or workflow consumes it.
• What it reported is statically known.getRegisteredTypes is a method the class
  declares, so the typeof it printed cannot vary in a way an operator could act on.
  Demoting would preserve a probe whose answer is fixed at compile time.

The ctx.logger.info('Initializing Metadata Manager', ...) call three lines above already
announces the same lifecycle step through the plugin's own logger, carrying the fields that
are actually actionable (root, watch, artifactSource).

Severity is bounded, per the triage: on the two paths where a stray stdout line would break
a parser — --json payloads and the os serve protocol channel — packages/cli already
reserves stdout by redirecting to stderr, so nothing downstream depended on this line being
present or absent.

Deliberately not touched

• The file's five other console.* calls (:627–:653 on this tree, the dev HMR path).
  Each carries // eslint-disable-next-line no-console, and the one that prints on every
  non-development boot carries a written rationale for doing so. That distinction is what
  makes this a one-line change and not a six-line one. The file's console.* count went
  6 -> 5 and its eslint-disable count stayed at 5.
• eslint.config.mjs and the no-console question. No inline disable was added, none
  was removed, and the rule was not configured. That question, and the inert-suppression
  population behind it, is the separate card 134 eslint-disable comments across 45 source files are structurally inert — pnpm lint runs --no-inline-config #14529.

Why no gate moves in either direction here

Re-measured on this tree, with eslint's own resolved config rather than a text search:

$ eslint --print-config packages/metadata/src/plugin.ts
resolved rules for this file: 6
no-console entry: null
any rule name containing "console": []
$ grep -n '"lint"' package.json
32: "lint": "node --stack-size=4000 node_modules/eslint/bin/eslint.js . --no-inline-config"

no-console is not configured, and the repo's only lint invocation passes
--no-inline-config, so the sibling disable comments are inert. Repo-wide pnpm lint is
green (exit 0, no output, 118s) while the file still contains five console.* calls — which
is the positive control that the rule really is off. This change therefore turns no gate
green and no gate red.

Measurements

Everything below was run at head 9d4221244, after merging origin/main.

The shipped artefact moved. No assertion exists to ablate, so no ablation is owed; the
proof is the built output instead. grep -rn 'has getRegisteredTypes' dist/ in
packages/metadata:

	before	after
probe string in dist/	8 hits (index.js, index.cjs, node.js, node.cjs + 4 sourcemaps)	0
control: sibling HMR print	8 files	8 files
control: the logger.info above it	8 files	8 files

Both controls still hold, so the zero is a real absence rather than a broken grep or an
unbuilt dist/. The probe is likewise absent from the 677-test run log, in which the
sibling console.log still appears 17 times.

Tests.pnpm --filter @objectstack/metadata exec vitest run --maxWorkers=2 —
Test Files 43 passed (43), Tests 677 passed (677).

Type check.@objectstack/metadata has no typecheck script on this tree (PR #14627,
which adds it, has not landed), so the substitute was
pnpm --filter @objectstack/metadata exec tsc --noEmit -p tsconfig.json. It reports 89
errors — all 89 in *.test.ts files, zero in plugin.ts and zero in any non-test file. A
reverse check confirms they are pre-existing rather than mine: restoring the pre-change
plugin.ts from the merge base and re-running gives the same 89, also with zero in
plugin.ts. The restore was verified by blob hash (8e4d1e3c... on disk equals the HEAD
blob) with an empty git diff HEAD. --listFiles confirms plugin.ts is in the program
that was checked.

Gates. The family union was re-derived from the actual change set on this tree
(node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, 2 paths vs merge
base ca48cf377) and gives 30 families — identical before and after the merge. 27 are
green. Three answer exit 3, which each script's own verdict text defines as NOT MEASURED
rather than a failure, and none for a reason this change can influence:

• check-test-completeness.mjs — needs a saved turbo run test log as an argument; the
  derived family names it with none, which the script documents as the unreachable branch
  ("record this gate as NOT MEASURED; it is not a red").
• scripts/pm/check-half-states.mjs — needs repo-scoped REST egress, which this container
  refuses (a direct REST probe answers 403). It sweeps the PM board, not this diff. Its
  --self-test wrapper, pnpm check:pm-half-states, is green at 2062 cases.
• check:dual-build-cjs-loads — PREREQUISITE NOT MET: it reads built output and 57
  packages have no dist/ in this worktree. Its --self-test is green at 93 cases, and the
  property it asserts was checked directly for the package this PR touches: all four
  published require entries of @objectstack/metadata (index.cjs, node.cjs,
  errors.cjs, migrations/index.cjs) load, with MetadataPlugin exported as a function.

Always-runs: pnpm lint green (full repo, not narrowed), pnpm check:nul-bytes green
(7991 files), pnpm check:error-status-conformance green.

Changeset.@objectstack/metadata: patch. The file is in the published entry closure,
measured three ways: src/index.ts:14 re-exports MetadataPlugin from ./plugin.js; the
manifest ships "files": ["dist"] with exports["."] resolving to ./dist/index.js and
publishConfig.access: public; and pnpm check:published-files counts this package among
the 69 publishable members with a files whitelist and an exports map. Most directly, the
probe string was physically present in the shipped bundles before this change. One fewer
line on boot is observable, so skip-changeset would have been wrong.

This PR touches no package.json, so Validate Package Dependencies should not run on it.
That job is red on main for four lockfile advisories tracked in #14639, and no lockfile
change is carried here.

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata, touching 1 documentable anchor(s).

5 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/api/index.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/automation/flows.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/protocol/kernel/metadata-service.mdx(via MetadataPlugin (symbol, a top-level class))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx(via MetadataPlugin (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 12 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 — the merge of head 9d422124467501b60af0f1885d7a78b5c77d5bb9 into base 20b883918aa787e65299e72b85c2b3396aa2006f, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 && git checkout 8bd18a6f4e2db0764aa87b42e38e373abcd5f266
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 20b883918aa787e65299e72b85c2b3396aa2006f 9d422124467501b60af0f1885d7a78b5c77d5bb9 && git checkout -B drift-repro 20b883918aa787e65299e72b85c2b3396aa2006f && git merge --no-ff 9d422124467501b60af0f1885d7a78b5c77d5bb9
node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 20b883918aa787e65299e72b85c2b3396aa2006f → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Landing provenance (engine execution seat, session session_0112hMx9hjJ9BgB28X97DS68): flipped ready at 17:50Z and armed auto-merge (squash) at 17:51:32Z on head 9d4221244. The echo read method: MERGE; the queue build ref is the arming reading, not the echo.

• Review: ACCEPT on the card. Clause-② no, self-read from the final diff — one deleted console.log, nothing published changes shape.
• Governed-surface test on the two changed paths: 0 of 2 governed — ordinary queue landing.
• Enqueue bar: all 33 check runs on 9d4221244 completed success or skipped, read with perPage: 50.

The red on this head was diagnosed, not waited out.Test Core (1/6) failed at 17:15:22Z on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts:317 (AssertionError: expected 'SIGKILL' to be null). Established as not this PR's before the one permitted re-run was spent:

• the diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0;
• removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure, not toward it;
• Test Core (1/6) was green on test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629, test(objectql): declare the recorded-by fixture's lookup with the canonical reference key #14633 and fix(lint): teach describe() the live-elsewhere verdict instead of throwing #14632 within the preceding hour, all of which include @objectstack/cli;
• the assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports that the harness's own 40s cap won a race, in a shard reporting Duration 843.94s against tests 2151.97s.

The re-run on the identical head, with no push and no rebase, passed at 17:45:27Z. Red then green on a byte-identical tree is the controlled A/B, and it is now recorded on the queue-flake anchor #14648 (comment 5513952826) together with the shape of a real fix. That anchor is domain:cli; this lane contributed the measurement and ⛔ did not claim it, relabel it, or weaken the test.

⚠️ Known exposure, stated rather than discovered later: the queue build runs the full suite, so this PR meets that same packages/cli test again on its queue build. #14629 was ejected on it at 17:45Z. If this PR is ejected the same way, the disposition is the same — ⛔ no second re-run, ⛔ no re-queue while #14648 is open and unfixed, and the failure goes on the record rather than into another full-queue round.

Owed by the seat at MERGED: verify by content on origin/main that the probe line is gone from packages/metadata/src/plugin.ts and that the five sibling console.* calls remain, strip pm:dispatched from #14527, landing record on the card, inventory reconciliation.

---

Generated by Claude Code

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 33671786568 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (1/6) — 失败步骤: Run this shard's tests

  @objectstack/cli:test: FAIL integration test/run-dev-unbuilt-workspace.e2e.test.ts > the mirror direction: a reader that is never coming back > gives up and exits instead of waiting forever
  ↳ 失败原因: @objectstack/cli:test: AssertionError: expected 'SIGKILL' to be null
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• test/run-dev-unbuilt-workspace.e2e.test.ts — 24h 内已弹出 8 个互相独立的 PR（fix(objectql,runtime,rest): store a serializable manifest projection in the package registry #14499、fix(devx): guard the last two run-on-import gate scripts — KNOWN_IMPORT_UNSAFE 2 to 0 #14593、lint(flows): warn on an uncontained loop body and on a try_catch with no catch, and document loop { try_catch } #14617、test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629、fix(cli): let the dev artifact door own stack-declared security metadata on a host config #14631、fix(metadata): drop the leftover boot-time debug probe from MetadataPlugin.init #14649、fix(objectql,metadata): derive a view container's object through the shared helper, so the row's own name is LAST at every SOURCE registrar (#14399) #14665、fix(cli): remove the ghost field types from generate.ts's three vocabularies #14675）。汇总 issue：Queue-flake anchor: test/run-dev-unbuilt-workspace.e2e.test.ts #14706（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 15 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)

[os-musk]

Ejected from the merge queue at 19:35:44Z — not this PR's failure, and deliberately NOT re-queued

Engine execution seat (session session_0112hMx9hjJ9BgB28X97DS68), reading queue build 33671786568.

What failed:Test Core (1/6) on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts — AssertionError: expected 'SIGKILL' to be null. The same signature that ejected #14629 at 17:45Z.

Verified by content that nothing landed:git grep -c "has getRegisteredTypes" origin/main -- packages/metadata/src/plugin.ts still returns 1, against a control of 14 console occurrences in the same file. The probe line this PR deletes is still on main, so this was an ejection and not a quiet landing.

Why it is not this PR's. The diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0. Removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure.

Why it is not a regression at all. The assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports only that the harness's own 40-second cap beat the child's exit. The decisive evidence is on this very PR: the same test, same assertion, failed on the PR side at 17:15:22Z and passed on a re-run of the identical head — no push, no rebase — at 17:45:27Z. A test red and green on a byte-identical tree is not measuring the tree.

⭐ The class has escalated since that first stand-down. The triage workflow's own count is now 8 independent PRs in 24 hours (#14499, #14593, #14617, #14629, #14631, #14649, #14665, #14675) across 15 failed queue builds, and it states that figure as a lower bound. Anchor: #14648 (domain:cli, priority:p1, pm:dispatched, assigned) — the card with an owner — plus the auto-filed duplicate #14706 which carries the current count. This lane's full diagnosis and the shape of a real fix are on both (5513952826 and 5515382957): the only option that closes the class is to assert the child's own exit reason instead of the absence of a signal, taking the wall clock out of the oracle.

Why this PR is not being re-queued. The triage workflow's checklist, item 2: once an aggregation issue exists, re-queuing before the fix only burns another full-queue round for every PR behind it — and with 15 failed builds in 24h that cost is now measurably superlinear. ⛔ No re-queue while the anchor is open and unfixed. ⛔ The test is not being skipped, quarantined, relaxed or re-baselined by this lane, and no second re-run has been spent — weakening a gate stays a human act and none of it is ours to do.

State: PR stays open, ready, mergeable_state: clean; auto-merge not re-armed. Card #14527 moved to pm:blocked with body lines Blocked-by: #14648 and Unlock-action: re-check PR #14649 — that second line is what stops the unlock scan re-dispatching finished, reviewed, green work when the anchor closes.

---

Generated by Claude Code

[os-musk]

Fixes#14527

MetadataPlugin.init() carried a bare console.log immediately after
ctx.registerService('metadata', this.manager), printing
typeof this.manager.getRegisteredTypes. Nothing gated it on NODE_ENV, a debug flag
or a logger level, so every kernel boot that installs MetadataPlugin wrote it to
stdout — the CLI, the dev server and any embedding host alike.

What changed

One line deleted from packages/metadata/src/plugin.ts, plus a changeset. The whole
contribution is 2 files changed, 30 insertions(+), 1 deletion(-), and the single
source hunk is:

 // 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);

Deleted rather than demoted to ctx.logger.debug

The triage allowed either. Deletion was chosen on two measurements:

• Nothing reads it. A repo-wide search for the printed string (has getRegisteredTypes,
  and separately Registered metadata service) returns exactly one hit: the emitting line
  itself. No test, script, doc or workflow consumes it.
• What it reported is statically known.getRegisteredTypes is a method the class
  declares, so the typeof it printed cannot vary in a way an operator could act on.
  Demoting would preserve a probe whose answer is fixed at compile time.

The ctx.logger.info('Initializing Metadata Manager', ...) call three lines above already
announces the same lifecycle step through the plugin's own logger, carrying the fields that
are actually actionable (root, watch, artifactSource).

Severity is bounded, per the triage: on the two paths where a stray stdout line would break
a parser — --json payloads and the os serve protocol channel — packages/cli already
reserves stdout by redirecting to stderr, so nothing downstream depended on this line being
present or absent.

Deliberately not touched

• The file's five other console.* calls (:627–:653 on this tree, the dev HMR path).
  Each carries // eslint-disable-next-line no-console, and the one that prints on every
  non-development boot carries a written rationale for doing so. That distinction is what
  makes this a one-line change and not a six-line one. The file's console.* count went
  6 -> 5 and its eslint-disable count stayed at 5.
• eslint.config.mjs and the no-console question. No inline disable was added, none
  was removed, and the rule was not configured. That question, and the inert-suppression
  population behind it, is the separate card 134 eslint-disable comments across 45 source files are structurally inert — pnpm lint runs --no-inline-config #14529.

Why no gate moves in either direction here

Re-measured on this tree, with eslint's own resolved config rather than a text search:

$ eslint --print-config packages/metadata/src/plugin.ts
resolved rules for this file: 6
no-console entry: null
any rule name containing "console": []
$ grep -n '"lint"' package.json
32: "lint": "node --stack-size=4000 node_modules/eslint/bin/eslint.js . --no-inline-config"

no-console is not configured, and the repo's only lint invocation passes
--no-inline-config, so the sibling disable comments are inert. Repo-wide pnpm lint is
green (exit 0, no output, 118s) while the file still contains five console.* calls — which
is the positive control that the rule really is off. This change therefore turns no gate
green and no gate red.

Measurements

Everything below was run at head 9d4221244, after merging origin/main.

The shipped artefact moved. No assertion exists to ablate, so no ablation is owed; the
proof is the built output instead. grep -rn 'has getRegisteredTypes' dist/ in
packages/metadata:

	before	after
probe string in dist/	8 hits (index.js, index.cjs, node.js, node.cjs + 4 sourcemaps)	0
control: sibling HMR print	8 files	8 files
control: the logger.info above it	8 files	8 files

Both controls still hold, so the zero is a real absence rather than a broken grep or an
unbuilt dist/. The probe is likewise absent from the 677-test run log, in which the
sibling console.log still appears 17 times.

Tests.pnpm --filter @objectstack/metadata exec vitest run --maxWorkers=2 —
Test Files 43 passed (43), Tests 677 passed (677).

Type check.@objectstack/metadata has no typecheck script on this tree (PR #14627,
which adds it, has not landed), so the substitute was
pnpm --filter @objectstack/metadata exec tsc --noEmit -p tsconfig.json. It reports 89
errors — all 89 in *.test.ts files, zero in plugin.ts and zero in any non-test file. A
reverse check confirms they are pre-existing rather than mine: restoring the pre-change
plugin.ts from the merge base and re-running gives the same 89, also with zero in
plugin.ts. The restore was verified by blob hash (8e4d1e3c... on disk equals the HEAD
blob) with an empty git diff HEAD. --listFiles confirms plugin.ts is in the program
that was checked.

Gates. The family union was re-derived from the actual change set on this tree
(node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, 2 paths vs merge
base ca48cf377) and gives 30 families — identical before and after the merge. 27 are
green. Three answer exit 3, which each script's own verdict text defines as NOT MEASURED
rather than a failure, and none for a reason this change can influence:

• check-test-completeness.mjs — needs a saved turbo run test log as an argument; the
  derived family names it with none, which the script documents as the unreachable branch
  ("record this gate as NOT MEASURED; it is not a red").
• scripts/pm/check-half-states.mjs — needs repo-scoped REST egress, which this container
  refuses (a direct REST probe answers 403). It sweeps the PM board, not this diff. Its
  --self-test wrapper, pnpm check:pm-half-states, is green at 2062 cases.
• check:dual-build-cjs-loads — PREREQUISITE NOT MET: it reads built output and 57
  packages have no dist/ in this worktree. Its --self-test is green at 93 cases, and the
  property it asserts was checked directly for the package this PR touches: all four
  published require entries of @objectstack/metadata (index.cjs, node.cjs,
  errors.cjs, migrations/index.cjs) load, with MetadataPlugin exported as a function.

Always-runs: pnpm lint green (full repo, not narrowed), pnpm check:nul-bytes green
(7991 files), pnpm check:error-status-conformance green.

Changeset.@objectstack/metadata: patch. The file is in the published entry closure,
measured three ways: src/index.ts:14 re-exports MetadataPlugin from ./plugin.js; the
manifest ships "files": ["dist"] with exports["."] resolving to ./dist/index.js and
publishConfig.access: public; and pnpm check:published-files counts this package among
the 69 publishable members with a files whitelist and an exports map. Most directly, the
probe string was physically present in the shipped bundles before this change. One fewer
line on boot is observable, so skip-changeset would have been wrong.

This PR touches no package.json, so Validate Package Dependencies should not run on it.
That job is red on main for four lockfile advisories tracked in #14639, and no lockfile
change is carried here.

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata, touching 1 documentable anchor(s).

5 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/api/index.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/automation/flows.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/protocol/kernel/metadata-service.mdx(via MetadataPlugin (symbol, a top-level class))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx(via MetadataPlugin (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 12 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 — the merge of head 9d422124467501b60af0f1885d7a78b5c77d5bb9 into base 20b883918aa787e65299e72b85c2b3396aa2006f, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 && git checkout 8bd18a6f4e2db0764aa87b42e38e373abcd5f266
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 20b883918aa787e65299e72b85c2b3396aa2006f 9d422124467501b60af0f1885d7a78b5c77d5bb9 && git checkout -B drift-repro 20b883918aa787e65299e72b85c2b3396aa2006f && git merge --no-ff 9d422124467501b60af0f1885d7a78b5c77d5bb9
node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 20b883918aa787e65299e72b85c2b3396aa2006f → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Landing provenance (engine execution seat, session session_0112hMx9hjJ9BgB28X97DS68): flipped ready at 17:50Z and armed auto-merge (squash) at 17:51:32Z on head 9d4221244. The echo read method: MERGE; the queue build ref is the arming reading, not the echo.

• Review: ACCEPT on the card. Clause-② no, self-read from the final diff — one deleted console.log, nothing published changes shape.
• Governed-surface test on the two changed paths: 0 of 2 governed — ordinary queue landing.
• Enqueue bar: all 33 check runs on 9d4221244 completed success or skipped, read with perPage: 50.

The red on this head was diagnosed, not waited out.Test Core (1/6) failed at 17:15:22Z on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts:317 (AssertionError: expected 'SIGKILL' to be null). Established as not this PR's before the one permitted re-run was spent:

• the diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0;
• removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure, not toward it;
• Test Core (1/6) was green on test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629, test(objectql): declare the recorded-by fixture's lookup with the canonical reference key #14633 and fix(lint): teach describe() the live-elsewhere verdict instead of throwing #14632 within the preceding hour, all of which include @objectstack/cli;
• the assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports that the harness's own 40s cap won a race, in a shard reporting Duration 843.94s against tests 2151.97s.

The re-run on the identical head, with no push and no rebase, passed at 17:45:27Z. Red then green on a byte-identical tree is the controlled A/B, and it is now recorded on the queue-flake anchor #14648 (comment 5513952826) together with the shape of a real fix. That anchor is domain:cli; this lane contributed the measurement and ⛔ did not claim it, relabel it, or weaken the test.

⚠️ Known exposure, stated rather than discovered later: the queue build runs the full suite, so this PR meets that same packages/cli test again on its queue build. #14629 was ejected on it at 17:45Z. If this PR is ejected the same way, the disposition is the same — ⛔ no second re-run, ⛔ no re-queue while #14648 is open and unfixed, and the failure goes on the record rather than into another full-queue round.

Owed by the seat at MERGED: verify by content on origin/main that the probe line is gone from packages/metadata/src/plugin.ts and that the five sibling console.* calls remain, strip pm:dispatched from #14527, landing record on the card, inventory reconciliation.

---

Generated by Claude Code

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 33671786568 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (1/6) — 失败步骤: Run this shard's tests

  @objectstack/cli:test: FAIL integration test/run-dev-unbuilt-workspace.e2e.test.ts > the mirror direction: a reader that is never coming back > gives up and exits instead of waiting forever
  ↳ 失败原因: @objectstack/cli:test: AssertionError: expected 'SIGKILL' to be null
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• test/run-dev-unbuilt-workspace.e2e.test.ts — 24h 内已弹出 8 个互相独立的 PR（fix(objectql,runtime,rest): store a serializable manifest projection in the package registry #14499、fix(devx): guard the last two run-on-import gate scripts — KNOWN_IMPORT_UNSAFE 2 to 0 #14593、lint(flows): warn on an uncontained loop body and on a try_catch with no catch, and document loop { try_catch } #14617、test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629、fix(cli): let the dev artifact door own stack-declared security metadata on a host config #14631、fix(metadata): drop the leftover boot-time debug probe from MetadataPlugin.init #14649、fix(objectql,metadata): derive a view container's object through the shared helper, so the row's own name is LAST at every SOURCE registrar (#14399) #14665、fix(cli): remove the ghost field types from generate.ts's three vocabularies #14675）。汇总 issue：Queue-flake anchor: test/run-dev-unbuilt-workspace.e2e.test.ts #14706（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 15 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)

[os-musk]

Ejected from the merge queue at 19:35:44Z — not this PR's failure, and deliberately NOT re-queued

Engine execution seat (session session_0112hMx9hjJ9BgB28X97DS68), reading queue build 33671786568.

What failed:Test Core (1/6) on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts — AssertionError: expected 'SIGKILL' to be null. The same signature that ejected #14629 at 17:45Z.

Verified by content that nothing landed:git grep -c "has getRegisteredTypes" origin/main -- packages/metadata/src/plugin.ts still returns 1, against a control of 14 console occurrences in the same file. The probe line this PR deletes is still on main, so this was an ejection and not a quiet landing.

Why it is not this PR's. The diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0. Removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure.

Why it is not a regression at all. The assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports only that the harness's own 40-second cap beat the child's exit. The decisive evidence is on this very PR: the same test, same assertion, failed on the PR side at 17:15:22Z and passed on a re-run of the identical head — no push, no rebase — at 17:45:27Z. A test red and green on a byte-identical tree is not measuring the tree.

⭐ The class has escalated since that first stand-down. The triage workflow's own count is now 8 independent PRs in 24 hours (#14499, #14593, #14617, #14629, #14631, #14649, #14665, #14675) across 15 failed queue builds, and it states that figure as a lower bound. Anchor: #14648 (domain:cli, priority:p1, pm:dispatched, assigned) — the card with an owner — plus the auto-filed duplicate #14706 which carries the current count. This lane's full diagnosis and the shape of a real fix are on both (5513952826 and 5515382957): the only option that closes the class is to assert the child's own exit reason instead of the absence of a signal, taking the wall clock out of the oracle.

Why this PR is not being re-queued. The triage workflow's checklist, item 2: once an aggregation issue exists, re-queuing before the fix only burns another full-queue round for every PR behind it — and with 15 failed builds in 24h that cost is now measurably superlinear. ⛔ No re-queue while the anchor is open and unfixed. ⛔ The test is not being skipped, quarantined, relaxed or re-baselined by this lane, and no second re-run has been spent — weakening a gate stays a human act and none of it is ours to do.

State: PR stays open, ready, mergeable_state: clean; auto-merge not re-armed. Card #14527 moved to pm:blocked with body lines Blocked-by: #14648 and Unlock-action: re-check PR #14649 — that second line is what stops the unlock scan re-dispatching finished, reviewed, green work when the anchor closes.

---

Generated by Claude Code

[os-musk]

Fixes#14527

MetadataPlugin.init() carried a bare console.log immediately after
ctx.registerService('metadata', this.manager), printing
typeof this.manager.getRegisteredTypes. Nothing gated it on NODE_ENV, a debug flag
or a logger level, so every kernel boot that installs MetadataPlugin wrote it to
stdout — the CLI, the dev server and any embedding host alike.

What changed

One line deleted from packages/metadata/src/plugin.ts, plus a changeset. The whole
contribution is 2 files changed, 30 insertions(+), 1 deletion(-), and the single
source hunk is:

 // 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);

Deleted rather than demoted to ctx.logger.debug

The triage allowed either. Deletion was chosen on two measurements:

• Nothing reads it. A repo-wide search for the printed string (has getRegisteredTypes,
  and separately Registered metadata service) returns exactly one hit: the emitting line
  itself. No test, script, doc or workflow consumes it.
• What it reported is statically known.getRegisteredTypes is a method the class
  declares, so the typeof it printed cannot vary in a way an operator could act on.
  Demoting would preserve a probe whose answer is fixed at compile time.

The ctx.logger.info('Initializing Metadata Manager', ...) call three lines above already
announces the same lifecycle step through the plugin's own logger, carrying the fields that
are actually actionable (root, watch, artifactSource).

Severity is bounded, per the triage: on the two paths where a stray stdout line would break
a parser — --json payloads and the os serve protocol channel — packages/cli already
reserves stdout by redirecting to stderr, so nothing downstream depended on this line being
present or absent.

Deliberately not touched

• The file's five other console.* calls (:627–:653 on this tree, the dev HMR path).
  Each carries // eslint-disable-next-line no-console, and the one that prints on every
  non-development boot carries a written rationale for doing so. That distinction is what
  makes this a one-line change and not a six-line one. The file's console.* count went
  6 -> 5 and its eslint-disable count stayed at 5.
• eslint.config.mjs and the no-console question. No inline disable was added, none
  was removed, and the rule was not configured. That question, and the inert-suppression
  population behind it, is the separate card 134 eslint-disable comments across 45 source files are structurally inert — pnpm lint runs --no-inline-config #14529.

Why no gate moves in either direction here

Re-measured on this tree, with eslint's own resolved config rather than a text search:

$ eslint --print-config packages/metadata/src/plugin.ts
resolved rules for this file: 6
no-console entry: null
any rule name containing "console": []
$ grep -n '"lint"' package.json
32: "lint": "node --stack-size=4000 node_modules/eslint/bin/eslint.js . --no-inline-config"

no-console is not configured, and the repo's only lint invocation passes
--no-inline-config, so the sibling disable comments are inert. Repo-wide pnpm lint is
green (exit 0, no output, 118s) while the file still contains five console.* calls — which
is the positive control that the rule really is off. This change therefore turns no gate
green and no gate red.

Measurements

Everything below was run at head 9d4221244, after merging origin/main.

The shipped artefact moved. No assertion exists to ablate, so no ablation is owed; the
proof is the built output instead. grep -rn 'has getRegisteredTypes' dist/ in
packages/metadata:

	before	after
probe string in dist/	8 hits (index.js, index.cjs, node.js, node.cjs + 4 sourcemaps)	0
control: sibling HMR print	8 files	8 files
control: the logger.info above it	8 files	8 files

Both controls still hold, so the zero is a real absence rather than a broken grep or an
unbuilt dist/. The probe is likewise absent from the 677-test run log, in which the
sibling console.log still appears 17 times.

Tests.pnpm --filter @objectstack/metadata exec vitest run --maxWorkers=2 —
Test Files 43 passed (43), Tests 677 passed (677).

Type check.@objectstack/metadata has no typecheck script on this tree (PR #14627,
which adds it, has not landed), so the substitute was
pnpm --filter @objectstack/metadata exec tsc --noEmit -p tsconfig.json. It reports 89
errors — all 89 in *.test.ts files, zero in plugin.ts and zero in any non-test file. A
reverse check confirms they are pre-existing rather than mine: restoring the pre-change
plugin.ts from the merge base and re-running gives the same 89, also with zero in
plugin.ts. The restore was verified by blob hash (8e4d1e3c... on disk equals the HEAD
blob) with an empty git diff HEAD. --listFiles confirms plugin.ts is in the program
that was checked.

Gates. The family union was re-derived from the actual change set on this tree
(node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, 2 paths vs merge
base ca48cf377) and gives 30 families — identical before and after the merge. 27 are
green. Three answer exit 3, which each script's own verdict text defines as NOT MEASURED
rather than a failure, and none for a reason this change can influence:

• check-test-completeness.mjs — needs a saved turbo run test log as an argument; the
  derived family names it with none, which the script documents as the unreachable branch
  ("record this gate as NOT MEASURED; it is not a red").
• scripts/pm/check-half-states.mjs — needs repo-scoped REST egress, which this container
  refuses (a direct REST probe answers 403). It sweeps the PM board, not this diff. Its
  --self-test wrapper, pnpm check:pm-half-states, is green at 2062 cases.
• check:dual-build-cjs-loads — PREREQUISITE NOT MET: it reads built output and 57
  packages have no dist/ in this worktree. Its --self-test is green at 93 cases, and the
  property it asserts was checked directly for the package this PR touches: all four
  published require entries of @objectstack/metadata (index.cjs, node.cjs,
  errors.cjs, migrations/index.cjs) load, with MetadataPlugin exported as a function.

Always-runs: pnpm lint green (full repo, not narrowed), pnpm check:nul-bytes green
(7991 files), pnpm check:error-status-conformance green.

Changeset.@objectstack/metadata: patch. The file is in the published entry closure,
measured three ways: src/index.ts:14 re-exports MetadataPlugin from ./plugin.js; the
manifest ships "files": ["dist"] with exports["."] resolving to ./dist/index.js and
publishConfig.access: public; and pnpm check:published-files counts this package among
the 69 publishable members with a files whitelist and an exports map. Most directly, the
probe string was physically present in the shipped bundles before this change. One fewer
line on boot is observable, so skip-changeset would have been wrong.

This PR touches no package.json, so Validate Package Dependencies should not run on it.
That job is red on main for four lockfile advisories tracked in #14639, and no lockfile
change is carried here.

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata, touching 1 documentable anchor(s).

5 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/api/index.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/automation/flows.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/protocol/kernel/metadata-service.mdx(via MetadataPlugin (symbol, a top-level class))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx(via MetadataPlugin (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 12 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 — the merge of head 9d422124467501b60af0f1885d7a78b5c77d5bb9 into base 20b883918aa787e65299e72b85c2b3396aa2006f, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 && git checkout 8bd18a6f4e2db0764aa87b42e38e373abcd5f266
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 20b883918aa787e65299e72b85c2b3396aa2006f 9d422124467501b60af0f1885d7a78b5c77d5bb9 && git checkout -B drift-repro 20b883918aa787e65299e72b85c2b3396aa2006f && git merge --no-ff 9d422124467501b60af0f1885d7a78b5c77d5bb9
node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 20b883918aa787e65299e72b85c2b3396aa2006f → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Landing provenance (engine execution seat, session session_0112hMx9hjJ9BgB28X97DS68): flipped ready at 17:50Z and armed auto-merge (squash) at 17:51:32Z on head 9d4221244. The echo read method: MERGE; the queue build ref is the arming reading, not the echo.

• Review: ACCEPT on the card. Clause-② no, self-read from the final diff — one deleted console.log, nothing published changes shape.
• Governed-surface test on the two changed paths: 0 of 2 governed — ordinary queue landing.
• Enqueue bar: all 33 check runs on 9d4221244 completed success or skipped, read with perPage: 50.

The red on this head was diagnosed, not waited out.Test Core (1/6) failed at 17:15:22Z on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts:317 (AssertionError: expected 'SIGKILL' to be null). Established as not this PR's before the one permitted re-run was spent:

• the diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0;
• removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure, not toward it;
• Test Core (1/6) was green on test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629, test(objectql): declare the recorded-by fixture's lookup with the canonical reference key #14633 and fix(lint): teach describe() the live-elsewhere verdict instead of throwing #14632 within the preceding hour, all of which include @objectstack/cli;
• the assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports that the harness's own 40s cap won a race, in a shard reporting Duration 843.94s against tests 2151.97s.

The re-run on the identical head, with no push and no rebase, passed at 17:45:27Z. Red then green on a byte-identical tree is the controlled A/B, and it is now recorded on the queue-flake anchor #14648 (comment 5513952826) together with the shape of a real fix. That anchor is domain:cli; this lane contributed the measurement and ⛔ did not claim it, relabel it, or weaken the test.

⚠️ Known exposure, stated rather than discovered later: the queue build runs the full suite, so this PR meets that same packages/cli test again on its queue build. #14629 was ejected on it at 17:45Z. If this PR is ejected the same way, the disposition is the same — ⛔ no second re-run, ⛔ no re-queue while #14648 is open and unfixed, and the failure goes on the record rather than into another full-queue round.

Owed by the seat at MERGED: verify by content on origin/main that the probe line is gone from packages/metadata/src/plugin.ts and that the five sibling console.* calls remain, strip pm:dispatched from #14527, landing record on the card, inventory reconciliation.

---

Generated by Claude Code

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 33671786568 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (1/6) — 失败步骤: Run this shard's tests

  @objectstack/cli:test: FAIL integration test/run-dev-unbuilt-workspace.e2e.test.ts > the mirror direction: a reader that is never coming back > gives up and exits instead of waiting forever
  ↳ 失败原因: @objectstack/cli:test: AssertionError: expected 'SIGKILL' to be null
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• test/run-dev-unbuilt-workspace.e2e.test.ts — 24h 内已弹出 8 个互相独立的 PR（fix(objectql,runtime,rest): store a serializable manifest projection in the package registry #14499、fix(devx): guard the last two run-on-import gate scripts — KNOWN_IMPORT_UNSAFE 2 to 0 #14593、lint(flows): warn on an uncontained loop body and on a try_catch with no catch, and document loop { try_catch } #14617、test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629、fix(cli): let the dev artifact door own stack-declared security metadata on a host config #14631、fix(metadata): drop the leftover boot-time debug probe from MetadataPlugin.init #14649、fix(objectql,metadata): derive a view container's object through the shared helper, so the row's own name is LAST at every SOURCE registrar (#14399) #14665、fix(cli): remove the ghost field types from generate.ts's three vocabularies #14675）。汇总 issue：Queue-flake anchor: test/run-dev-unbuilt-workspace.e2e.test.ts #14706（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 15 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)

[os-musk]

Ejected from the merge queue at 19:35:44Z — not this PR's failure, and deliberately NOT re-queued

Engine execution seat (session session_0112hMx9hjJ9BgB28X97DS68), reading queue build 33671786568.

What failed:Test Core (1/6) on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts — AssertionError: expected 'SIGKILL' to be null. The same signature that ejected #14629 at 17:45Z.

Verified by content that nothing landed:git grep -c "has getRegisteredTypes" origin/main -- packages/metadata/src/plugin.ts still returns 1, against a control of 14 console occurrences in the same file. The probe line this PR deletes is still on main, so this was an ejection and not a quiet landing.

Why it is not this PR's. The diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0. Removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure.

Why it is not a regression at all. The assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports only that the harness's own 40-second cap beat the child's exit. The decisive evidence is on this very PR: the same test, same assertion, failed on the PR side at 17:15:22Z and passed on a re-run of the identical head — no push, no rebase — at 17:45:27Z. A test red and green on a byte-identical tree is not measuring the tree.

⭐ The class has escalated since that first stand-down. The triage workflow's own count is now 8 independent PRs in 24 hours (#14499, #14593, #14617, #14629, #14631, #14649, #14665, #14675) across 15 failed queue builds, and it states that figure as a lower bound. Anchor: #14648 (domain:cli, priority:p1, pm:dispatched, assigned) — the card with an owner — plus the auto-filed duplicate #14706 which carries the current count. This lane's full diagnosis and the shape of a real fix are on both (5513952826 and 5515382957): the only option that closes the class is to assert the child's own exit reason instead of the absence of a signal, taking the wall clock out of the oracle.

Why this PR is not being re-queued. The triage workflow's checklist, item 2: once an aggregation issue exists, re-queuing before the fix only burns another full-queue round for every PR behind it — and with 15 failed builds in 24h that cost is now measurably superlinear. ⛔ No re-queue while the anchor is open and unfixed. ⛔ The test is not being skipped, quarantined, relaxed or re-baselined by this lane, and no second re-run has been spent — weakening a gate stays a human act and none of it is ours to do.

State: PR stays open, ready, mergeable_state: clean; auto-merge not re-armed. Card #14527 moved to pm:blocked with body lines Blocked-by: #14648 and Unlock-action: re-check PR #14649 — that second line is what stops the unlock scan re-dispatching finished, reviewed, green work when the anchor closes.

---

Generated by Claude Code

[os-musk]

Fixes#14527

MetadataPlugin.init() carried a bare console.log immediately after
ctx.registerService('metadata', this.manager), printing
typeof this.manager.getRegisteredTypes. Nothing gated it on NODE_ENV, a debug flag
or a logger level, so every kernel boot that installs MetadataPlugin wrote it to
stdout — the CLI, the dev server and any embedding host alike.

What changed

One line deleted from packages/metadata/src/plugin.ts, plus a changeset. The whole
contribution is 2 files changed, 30 insertions(+), 1 deletion(-), and the single
source hunk is:

 // 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);

Deleted rather than demoted to ctx.logger.debug

The triage allowed either. Deletion was chosen on two measurements:

• Nothing reads it. A repo-wide search for the printed string (has getRegisteredTypes,
  and separately Registered metadata service) returns exactly one hit: the emitting line
  itself. No test, script, doc or workflow consumes it.
• What it reported is statically known.getRegisteredTypes is a method the class
  declares, so the typeof it printed cannot vary in a way an operator could act on.
  Demoting would preserve a probe whose answer is fixed at compile time.

The ctx.logger.info('Initializing Metadata Manager', ...) call three lines above already
announces the same lifecycle step through the plugin's own logger, carrying the fields that
are actually actionable (root, watch, artifactSource).

Severity is bounded, per the triage: on the two paths where a stray stdout line would break
a parser — --json payloads and the os serve protocol channel — packages/cli already
reserves stdout by redirecting to stderr, so nothing downstream depended on this line being
present or absent.

Deliberately not touched

• The file's five other console.* calls (:627–:653 on this tree, the dev HMR path).
  Each carries // eslint-disable-next-line no-console, and the one that prints on every
  non-development boot carries a written rationale for doing so. That distinction is what
  makes this a one-line change and not a six-line one. The file's console.* count went
  6 -> 5 and its eslint-disable count stayed at 5.
• eslint.config.mjs and the no-console question. No inline disable was added, none
  was removed, and the rule was not configured. That question, and the inert-suppression
  population behind it, is the separate card 134 eslint-disable comments across 45 source files are structurally inert — pnpm lint runs --no-inline-config #14529.

Why no gate moves in either direction here

Re-measured on this tree, with eslint's own resolved config rather than a text search:

$ eslint --print-config packages/metadata/src/plugin.ts
resolved rules for this file: 6
no-console entry: null
any rule name containing "console": []
$ grep -n '"lint"' package.json
32: "lint": "node --stack-size=4000 node_modules/eslint/bin/eslint.js . --no-inline-config"

no-console is not configured, and the repo's only lint invocation passes
--no-inline-config, so the sibling disable comments are inert. Repo-wide pnpm lint is
green (exit 0, no output, 118s) while the file still contains five console.* calls — which
is the positive control that the rule really is off. This change therefore turns no gate
green and no gate red.

Measurements

Everything below was run at head 9d4221244, after merging origin/main.

The shipped artefact moved. No assertion exists to ablate, so no ablation is owed; the
proof is the built output instead. grep -rn 'has getRegisteredTypes' dist/ in
packages/metadata:

	before	after
probe string in dist/	8 hits (index.js, index.cjs, node.js, node.cjs + 4 sourcemaps)	0
control: sibling HMR print	8 files	8 files
control: the logger.info above it	8 files	8 files

Both controls still hold, so the zero is a real absence rather than a broken grep or an
unbuilt dist/. The probe is likewise absent from the 677-test run log, in which the
sibling console.log still appears 17 times.

Tests.pnpm --filter @objectstack/metadata exec vitest run --maxWorkers=2 —
Test Files 43 passed (43), Tests 677 passed (677).

Type check.@objectstack/metadata has no typecheck script on this tree (PR #14627,
which adds it, has not landed), so the substitute was
pnpm --filter @objectstack/metadata exec tsc --noEmit -p tsconfig.json. It reports 89
errors — all 89 in *.test.ts files, zero in plugin.ts and zero in any non-test file. A
reverse check confirms they are pre-existing rather than mine: restoring the pre-change
plugin.ts from the merge base and re-running gives the same 89, also with zero in
plugin.ts. The restore was verified by blob hash (8e4d1e3c... on disk equals the HEAD
blob) with an empty git diff HEAD. --listFiles confirms plugin.ts is in the program
that was checked.

Gates. The family union was re-derived from the actual change set on this tree
(node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, 2 paths vs merge
base ca48cf377) and gives 30 families — identical before and after the merge. 27 are
green. Three answer exit 3, which each script's own verdict text defines as NOT MEASURED
rather than a failure, and none for a reason this change can influence:

• check-test-completeness.mjs — needs a saved turbo run test log as an argument; the
  derived family names it with none, which the script documents as the unreachable branch
  ("record this gate as NOT MEASURED; it is not a red").
• scripts/pm/check-half-states.mjs — needs repo-scoped REST egress, which this container
  refuses (a direct REST probe answers 403). It sweeps the PM board, not this diff. Its
  --self-test wrapper, pnpm check:pm-half-states, is green at 2062 cases.
• check:dual-build-cjs-loads — PREREQUISITE NOT MET: it reads built output and 57
  packages have no dist/ in this worktree. Its --self-test is green at 93 cases, and the
  property it asserts was checked directly for the package this PR touches: all four
  published require entries of @objectstack/metadata (index.cjs, node.cjs,
  errors.cjs, migrations/index.cjs) load, with MetadataPlugin exported as a function.

Always-runs: pnpm lint green (full repo, not narrowed), pnpm check:nul-bytes green
(7991 files), pnpm check:error-status-conformance green.

Changeset.@objectstack/metadata: patch. The file is in the published entry closure,
measured three ways: src/index.ts:14 re-exports MetadataPlugin from ./plugin.js; the
manifest ships "files": ["dist"] with exports["."] resolving to ./dist/index.js and
publishConfig.access: public; and pnpm check:published-files counts this package among
the 69 publishable members with a files whitelist and an exports map. Most directly, the
probe string was physically present in the shipped bundles before this change. One fewer
line on boot is observable, so skip-changeset would have been wrong.

This PR touches no package.json, so Validate Package Dependencies should not run on it.
That job is red on main for four lockfile advisories tracked in #14639, and no lockfile
change is carried here.

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata, touching 1 documentable anchor(s).

5 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/api/index.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/automation/flows.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/protocol/kernel/metadata-service.mdx(via MetadataPlugin (symbol, a top-level class))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx(via MetadataPlugin (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 12 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 — the merge of head 9d422124467501b60af0f1885d7a78b5c77d5bb9 into base 20b883918aa787e65299e72b85c2b3396aa2006f, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 && git checkout 8bd18a6f4e2db0764aa87b42e38e373abcd5f266
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 20b883918aa787e65299e72b85c2b3396aa2006f 9d422124467501b60af0f1885d7a78b5c77d5bb9 && git checkout -B drift-repro 20b883918aa787e65299e72b85c2b3396aa2006f && git merge --no-ff 9d422124467501b60af0f1885d7a78b5c77d5bb9
node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 20b883918aa787e65299e72b85c2b3396aa2006f → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Landing provenance (engine execution seat, session session_0112hMx9hjJ9BgB28X97DS68): flipped ready at 17:50Z and armed auto-merge (squash) at 17:51:32Z on head 9d4221244. The echo read method: MERGE; the queue build ref is the arming reading, not the echo.

• Review: ACCEPT on the card. Clause-② no, self-read from the final diff — one deleted console.log, nothing published changes shape.
• Governed-surface test on the two changed paths: 0 of 2 governed — ordinary queue landing.
• Enqueue bar: all 33 check runs on 9d4221244 completed success or skipped, read with perPage: 50.

The red on this head was diagnosed, not waited out.Test Core (1/6) failed at 17:15:22Z on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts:317 (AssertionError: expected 'SIGKILL' to be null). Established as not this PR's before the one permitted re-run was spent:

• the diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0;
• removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure, not toward it;
• Test Core (1/6) was green on test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629, test(objectql): declare the recorded-by fixture's lookup with the canonical reference key #14633 and fix(lint): teach describe() the live-elsewhere verdict instead of throwing #14632 within the preceding hour, all of which include @objectstack/cli;
• the assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports that the harness's own 40s cap won a race, in a shard reporting Duration 843.94s against tests 2151.97s.

The re-run on the identical head, with no push and no rebase, passed at 17:45:27Z. Red then green on a byte-identical tree is the controlled A/B, and it is now recorded on the queue-flake anchor #14648 (comment 5513952826) together with the shape of a real fix. That anchor is domain:cli; this lane contributed the measurement and ⛔ did not claim it, relabel it, or weaken the test.

⚠️ Known exposure, stated rather than discovered later: the queue build runs the full suite, so this PR meets that same packages/cli test again on its queue build. #14629 was ejected on it at 17:45Z. If this PR is ejected the same way, the disposition is the same — ⛔ no second re-run, ⛔ no re-queue while #14648 is open and unfixed, and the failure goes on the record rather than into another full-queue round.

Owed by the seat at MERGED: verify by content on origin/main that the probe line is gone from packages/metadata/src/plugin.ts and that the five sibling console.* calls remain, strip pm:dispatched from #14527, landing record on the card, inventory reconciliation.

---

Generated by Claude Code

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 33671786568 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (1/6) — 失败步骤: Run this shard's tests

  @objectstack/cli:test: FAIL integration test/run-dev-unbuilt-workspace.e2e.test.ts > the mirror direction: a reader that is never coming back > gives up and exits instead of waiting forever
  ↳ 失败原因: @objectstack/cli:test: AssertionError: expected 'SIGKILL' to be null
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• test/run-dev-unbuilt-workspace.e2e.test.ts — 24h 内已弹出 8 个互相独立的 PR（fix(objectql,runtime,rest): store a serializable manifest projection in the package registry #14499、fix(devx): guard the last two run-on-import gate scripts — KNOWN_IMPORT_UNSAFE 2 to 0 #14593、lint(flows): warn on an uncontained loop body and on a try_catch with no catch, and document loop { try_catch } #14617、test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629、fix(cli): let the dev artifact door own stack-declared security metadata on a host config #14631、fix(metadata): drop the leftover boot-time debug probe from MetadataPlugin.init #14649、fix(objectql,metadata): derive a view container's object through the shared helper, so the row's own name is LAST at every SOURCE registrar (#14399) #14665、fix(cli): remove the ghost field types from generate.ts's three vocabularies #14675）。汇总 issue：Queue-flake anchor: test/run-dev-unbuilt-workspace.e2e.test.ts #14706（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 15 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)

[os-musk]

Ejected from the merge queue at 19:35:44Z — not this PR's failure, and deliberately NOT re-queued

Engine execution seat (session session_0112hMx9hjJ9BgB28X97DS68), reading queue build 33671786568.

What failed:Test Core (1/6) on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts — AssertionError: expected 'SIGKILL' to be null. The same signature that ejected #14629 at 17:45Z.

Verified by content that nothing landed:git grep -c "has getRegisteredTypes" origin/main -- packages/metadata/src/plugin.ts still returns 1, against a control of 14 console occurrences in the same file. The probe line this PR deletes is still on main, so this was an ejection and not a quiet landing.

Why it is not this PR's. The diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0. Removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure.

Why it is not a regression at all. The assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports only that the harness's own 40-second cap beat the child's exit. The decisive evidence is on this very PR: the same test, same assertion, failed on the PR side at 17:15:22Z and passed on a re-run of the identical head — no push, no rebase — at 17:45:27Z. A test red and green on a byte-identical tree is not measuring the tree.

⭐ The class has escalated since that first stand-down. The triage workflow's own count is now 8 independent PRs in 24 hours (#14499, #14593, #14617, #14629, #14631, #14649, #14665, #14675) across 15 failed queue builds, and it states that figure as a lower bound. Anchor: #14648 (domain:cli, priority:p1, pm:dispatched, assigned) — the card with an owner — plus the auto-filed duplicate #14706 which carries the current count. This lane's full diagnosis and the shape of a real fix are on both (5513952826 and 5515382957): the only option that closes the class is to assert the child's own exit reason instead of the absence of a signal, taking the wall clock out of the oracle.

Why this PR is not being re-queued. The triage workflow's checklist, item 2: once an aggregation issue exists, re-queuing before the fix only burns another full-queue round for every PR behind it — and with 15 failed builds in 24h that cost is now measurably superlinear. ⛔ No re-queue while the anchor is open and unfixed. ⛔ The test is not being skipped, quarantined, relaxed or re-baselined by this lane, and no second re-run has been spent — weakening a gate stays a human act and none of it is ours to do.

State: PR stays open, ready, mergeable_state: clean; auto-merge not re-armed. Card #14527 moved to pm:blocked with body lines Blocked-by: #14648 and Unlock-action: re-check PR #14649 — that second line is what stops the unlock scan re-dispatching finished, reviewed, green work when the anchor closes.

---

Generated by Claude Code

[os-musk]

Fixes#14527

MetadataPlugin.init() carried a bare console.log immediately after
ctx.registerService('metadata', this.manager), printing
typeof this.manager.getRegisteredTypes. Nothing gated it on NODE_ENV, a debug flag
or a logger level, so every kernel boot that installs MetadataPlugin wrote it to
stdout — the CLI, the dev server and any embedding host alike.

What changed

One line deleted from packages/metadata/src/plugin.ts, plus a changeset. The whole
contribution is 2 files changed, 30 insertions(+), 1 deletion(-), and the single
source hunk is:

 // 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);

Deleted rather than demoted to ctx.logger.debug

The triage allowed either. Deletion was chosen on two measurements:

• Nothing reads it. A repo-wide search for the printed string (has getRegisteredTypes,
  and separately Registered metadata service) returns exactly one hit: the emitting line
  itself. No test, script, doc or workflow consumes it.
• What it reported is statically known.getRegisteredTypes is a method the class
  declares, so the typeof it printed cannot vary in a way an operator could act on.
  Demoting would preserve a probe whose answer is fixed at compile time.

The ctx.logger.info('Initializing Metadata Manager', ...) call three lines above already
announces the same lifecycle step through the plugin's own logger, carrying the fields that
are actually actionable (root, watch, artifactSource).

Severity is bounded, per the triage: on the two paths where a stray stdout line would break
a parser — --json payloads and the os serve protocol channel — packages/cli already
reserves stdout by redirecting to stderr, so nothing downstream depended on this line being
present or absent.

Deliberately not touched

• The file's five other console.* calls (:627–:653 on this tree, the dev HMR path).
  Each carries // eslint-disable-next-line no-console, and the one that prints on every
  non-development boot carries a written rationale for doing so. That distinction is what
  makes this a one-line change and not a six-line one. The file's console.* count went
  6 -> 5 and its eslint-disable count stayed at 5.
• eslint.config.mjs and the no-console question. No inline disable was added, none
  was removed, and the rule was not configured. That question, and the inert-suppression
  population behind it, is the separate card 134 eslint-disable comments across 45 source files are structurally inert — pnpm lint runs --no-inline-config #14529.

Why no gate moves in either direction here

Re-measured on this tree, with eslint's own resolved config rather than a text search:

$ eslint --print-config packages/metadata/src/plugin.ts
resolved rules for this file: 6
no-console entry: null
any rule name containing "console": []
$ grep -n '"lint"' package.json
32: "lint": "node --stack-size=4000 node_modules/eslint/bin/eslint.js . --no-inline-config"

no-console is not configured, and the repo's only lint invocation passes
--no-inline-config, so the sibling disable comments are inert. Repo-wide pnpm lint is
green (exit 0, no output, 118s) while the file still contains five console.* calls — which
is the positive control that the rule really is off. This change therefore turns no gate
green and no gate red.

Measurements

Everything below was run at head 9d4221244, after merging origin/main.

The shipped artefact moved. No assertion exists to ablate, so no ablation is owed; the
proof is the built output instead. grep -rn 'has getRegisteredTypes' dist/ in
packages/metadata:

	before	after
probe string in dist/	8 hits (index.js, index.cjs, node.js, node.cjs + 4 sourcemaps)	0
control: sibling HMR print	8 files	8 files
control: the logger.info above it	8 files	8 files

Both controls still hold, so the zero is a real absence rather than a broken grep or an
unbuilt dist/. The probe is likewise absent from the 677-test run log, in which the
sibling console.log still appears 17 times.

Tests.pnpm --filter @objectstack/metadata exec vitest run --maxWorkers=2 —
Test Files 43 passed (43), Tests 677 passed (677).

Type check.@objectstack/metadata has no typecheck script on this tree (PR #14627,
which adds it, has not landed), so the substitute was
pnpm --filter @objectstack/metadata exec tsc --noEmit -p tsconfig.json. It reports 89
errors — all 89 in *.test.ts files, zero in plugin.ts and zero in any non-test file. A
reverse check confirms they are pre-existing rather than mine: restoring the pre-change
plugin.ts from the merge base and re-running gives the same 89, also with zero in
plugin.ts. The restore was verified by blob hash (8e4d1e3c... on disk equals the HEAD
blob) with an empty git diff HEAD. --listFiles confirms plugin.ts is in the program
that was checked.

Gates. The family union was re-derived from the actual change set on this tree
(node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, 2 paths vs merge
base ca48cf377) and gives 30 families — identical before and after the merge. 27 are
green. Three answer exit 3, which each script's own verdict text defines as NOT MEASURED
rather than a failure, and none for a reason this change can influence:

• check-test-completeness.mjs — needs a saved turbo run test log as an argument; the
  derived family names it with none, which the script documents as the unreachable branch
  ("record this gate as NOT MEASURED; it is not a red").
• scripts/pm/check-half-states.mjs — needs repo-scoped REST egress, which this container
  refuses (a direct REST probe answers 403). It sweeps the PM board, not this diff. Its
  --self-test wrapper, pnpm check:pm-half-states, is green at 2062 cases.
• check:dual-build-cjs-loads — PREREQUISITE NOT MET: it reads built output and 57
  packages have no dist/ in this worktree. Its --self-test is green at 93 cases, and the
  property it asserts was checked directly for the package this PR touches: all four
  published require entries of @objectstack/metadata (index.cjs, node.cjs,
  errors.cjs, migrations/index.cjs) load, with MetadataPlugin exported as a function.

Always-runs: pnpm lint green (full repo, not narrowed), pnpm check:nul-bytes green
(7991 files), pnpm check:error-status-conformance green.

Changeset.@objectstack/metadata: patch. The file is in the published entry closure,
measured three ways: src/index.ts:14 re-exports MetadataPlugin from ./plugin.js; the
manifest ships "files": ["dist"] with exports["."] resolving to ./dist/index.js and
publishConfig.access: public; and pnpm check:published-files counts this package among
the 69 publishable members with a files whitelist and an exports map. Most directly, the
probe string was physically present in the shipped bundles before this change. One fewer
line on boot is observable, so skip-changeset would have been wrong.

This PR touches no package.json, so Validate Package Dependencies should not run on it.
That job is red on main for four lockfile advisories tracked in #14639, and no lockfile
change is carried here.

🤖 Generated with Claude Code

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/metadata, touching 1 documentable anchor(s).

5 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/api/index.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/automation/flows.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataPlugin (symbol, a top-level class))
• content/docs/protocol/kernel/metadata-service.mdx(via MetadataPlugin (symbol, a top-level class))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/implementation-status.mdx(via MetadataPlugin (symbol, a top-level class))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 12 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 — the merge of head 9d422124467501b60af0f1885d7a78b5c77d5bb9 into base 20b883918aa787e65299e72b85c2b3396aa2006f, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8bd18a6f4e2db0764aa87b42e38e373abcd5f266 && git checkout 8bd18a6f4e2db0764aa87b42e38e373abcd5f266
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 20b883918aa787e65299e72b85c2b3396aa2006f 9d422124467501b60af0f1885d7a78b5c77d5bb9 && git checkout -B drift-repro 20b883918aa787e65299e72b85c2b3396aa2006f && git merge --no-ff 9d422124467501b60af0f1885d7a78b5c77d5bb9
node scripts/docs-audit/affected-docs.mjs --json 20b883918aa787e65299e72b85c2b3396aa2006f

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 20b883918aa787e65299e72b85c2b3396aa2006f → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-musk]

Landing provenance (engine execution seat, session session_0112hMx9hjJ9BgB28X97DS68): flipped ready at 17:50Z and armed auto-merge (squash) at 17:51:32Z on head 9d4221244. The echo read method: MERGE; the queue build ref is the arming reading, not the echo.

• Review: ACCEPT on the card. Clause-② no, self-read from the final diff — one deleted console.log, nothing published changes shape.
• Governed-surface test on the two changed paths: 0 of 2 governed — ordinary queue landing.
• Enqueue bar: all 33 check runs on 9d4221244 completed success or skipped, read with perPage: 50.

The red on this head was diagnosed, not waited out.Test Core (1/6) failed at 17:15:22Z on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts:317 (AssertionError: expected 'SIGKILL' to be null). Established as not this PR's before the one permitted re-run was spent:

• the diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0;
• removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure, not toward it;
• Test Core (1/6) was green on test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629, test(objectql): declare the recorded-by fixture's lookup with the canonical reference key #14633 and fix(lint): teach describe() the live-elsewhere verdict instead of throwing #14632 within the preceding hour, all of which include @objectstack/cli;
• the assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports that the harness's own 40s cap won a race, in a shard reporting Duration 843.94s against tests 2151.97s.

The re-run on the identical head, with no push and no rebase, passed at 17:45:27Z. Red then green on a byte-identical tree is the controlled A/B, and it is now recorded on the queue-flake anchor #14648 (comment 5513952826) together with the shape of a real fix. That anchor is domain:cli; this lane contributed the measurement and ⛔ did not claim it, relabel it, or weaken the test.

⚠️ Known exposure, stated rather than discovered later: the queue build runs the full suite, so this PR meets that same packages/cli test again on its queue build. #14629 was ejected on it at 17:45Z. If this PR is ejected the same way, the disposition is the same — ⛔ no second re-run, ⛔ no re-queue while #14648 is open and unfixed, and the failure goes on the record rather than into another full-queue round.

Owed by the seat at MERGED: verify by content on origin/main that the probe line is gone from packages/metadata/src/plugin.ts and that the five sibling console.* calls remain, strip pm:dispatched from #14527, landing record on the card, inventory reconciliation.

---

Generated by Claude Code

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 33671786568 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (1/6) — 失败步骤: Run this shard's tests

  @objectstack/cli:test: FAIL integration test/run-dev-unbuilt-workspace.e2e.test.ts > the mirror direction: a reader that is never coming back > gives up and exits instead of waiting forever
  ↳ 失败原因: @objectstack/cli:test: AssertionError: expected 'SIGKILL' to be null
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• test/run-dev-unbuilt-workspace.e2e.test.ts — 24h 内已弹出 8 个互相独立的 PR（fix(objectql,runtime,rest): store a serializable manifest projection in the package registry #14499、fix(devx): guard the last two run-on-import gate scripts — KNOWN_IMPORT_UNSAFE 2 to 0 #14593、lint(flows): warn on an uncontained loop body and on a try_catch with no catch, and document loop { try_catch } #14617、test(driver-sql): give the seven unconditionally-live hooks an explicit 60_000 budget #14629、fix(cli): let the dev artifact door own stack-declared security metadata on a host config #14631、fix(metadata): drop the leftover boot-time debug probe from MetadataPlugin.init #14649、fix(objectql,metadata): derive a view container's object through the shared helper, so the row's own name is LAST at every SOURCE registrar (#14399) #14665、fix(cli): remove the ghost field types from generate.ts's three vocabularies #14675）。汇总 issue：Queue-flake anchor: test/run-dev-unbuilt-workspace.e2e.test.ts #14706（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 15 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)

[os-musk]

Ejected from the merge queue at 19:35:44Z — not this PR's failure, and deliberately NOT re-queued

Engine execution seat (session session_0112hMx9hjJ9BgB28X97DS68), reading queue build 33671786568.

What failed:Test Core (1/6) on packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts — AssertionError: expected 'SIGKILL' to be null. The same signature that ejected #14629 at 17:45Z.

Verified by content that nothing landed:git grep -c "has getRegisteredTypes" origin/main -- packages/metadata/src/plugin.ts still returns 1, against a control of 14 console occurrences in the same file. The probe line this PR deletes is still on main, so this was an ejection and not a quiet landing.

Why it is not this PR's. The diff is two files in packages/metadata and cannot reach packages/cli — git grep -c "has getRegisteredTypes" origin/main -- packages/cli = 0. Removing stdout output makes an unread-pipe scenario strictly less likely to block, so the change points away from the failure.

Why it is not a regression at all. The assertion is a wall-clock claim, not a behavioural one: UNREAD_HARD_CAP_MS = 40_000 at :153 and setTimeout(() => child.kill('SIGKILL'), …) at :186 mean signal === 'SIGKILL' reports only that the harness's own 40-second cap beat the child's exit. The decisive evidence is on this very PR: the same test, same assertion, failed on the PR side at 17:15:22Z and passed on a re-run of the identical head — no push, no rebase — at 17:45:27Z. A test red and green on a byte-identical tree is not measuring the tree.

⭐ The class has escalated since that first stand-down. The triage workflow's own count is now 8 independent PRs in 24 hours (#14499, #14593, #14617, #14629, #14631, #14649, #14665, #14675) across 15 failed queue builds, and it states that figure as a lower bound. Anchor: #14648 (domain:cli, priority:p1, pm:dispatched, assigned) — the card with an owner — plus the auto-filed duplicate #14706 which carries the current count. This lane's full diagnosis and the shape of a real fix are on both (5513952826 and 5515382957): the only option that closes the class is to assert the child's own exit reason instead of the absence of a signal, taking the wall clock out of the oracle.

Why this PR is not being re-queued. The triage workflow's checklist, item 2: once an aggregation issue exists, re-queuing before the fix only burns another full-queue round for every PR behind it — and with 15 failed builds in 24h that cost is now measurably superlinear. ⛔ No re-queue while the anchor is open and unfixed. ⛔ The test is not being skipped, quarantined, relaxed or re-baselined by this lane, and no second re-run has been spent — weakening a gate stays a human act and none of it is ours to do.

State: PR stays open, ready, mergeable_state: clean; auto-merge not re-armed. Card #14527 moved to pm:blocked with body lines Blocked-by: #14648 and Unlock-action: re-check PR #14649 — that second line is what stops the unlock scan re-dispatching finished, reviewed, green work when the anchor closes.

---

Generated by Claude Code