fix(service-cluster): stop the metadata bridge reporting “bridged” over an in-process cluster bus

[claude]

Fixes#14021

MetadataClusterBridgePlugin lane 1 attached and then logged
bridged metadata.changed → cluster.pubsub with no driver check. Runtime
registers the memory driver by default, so on an ordinary single-process boot
a cluster service IS present and that line is a false positive: the bus
keeps its state inside one process and the fan-out it announces reaches nobody.

---

Step zero — re-measurement on the post-1403d943a tree

⛔ Nothing below is copied from the card. PR #14183 (card #13331) landed at
1403d943a and changed this bridge, so all three were measured fresh on that
tree. One half of the card was already absorbed by #14183; the other stands.

1. The test file now EXISTS — what did #14183 already cover?

packages/services/service-cluster/src/metadata-cluster-bridge-plugin.test.ts
was created by #14183 (9 tests). Against the card's three wanted cases:

card's case	status before this PR	where
attach with (pubsub, nodeId)	✅ already covered by #14183	a manager metadata service and a real protocol both attach
attachClusterPubSub-missing warn	✅ already covered by #14183, asserted verbatim	warns for lane 1 AND attaches lane 2 in the same boot
in-process (lane 1)	❌ NOT covered — deliberately left open	see below

⇒ Card half 2 shrinks to one case, not three.#14183 did not merely omit
lane 1's in-process behaviour, it declined it in writing and said why — the
test file's own header:

⚠️ Lane 1's in-process-driver behaviour (it attaches and logs "bridged" on the
memory driver that fans out to nobody) is #14021's card, NOT pinned here —
these cases drive lane 1 only through its warn/absence paths so that card
stays free to fix it.

2. Does half 1 still hold? — YES, unchanged

attachMetadataServiceLane still attaches and logs info unconditionally.
#14183 did not incidentally fix it. It went further and recorded the defect
while adding lane 2 beside it:

Guarded on isInProcessClusterDriver from birth (the shape
AuthzClusterBridgePlugin uses): the in-process memory driver fans out to
nobody, so "attached" there would be the misreading #14021 records for lane
1's info line — a new lane does not inherit a known defect.

⇒ #14183 built the correct shape 40 lines below the defect, in the same file,
and named this card as the owner of the older one.

3. Is the sibling's guard shape still in place? — YES

authz-cluster-bridge-plugin.ts:78-84 still consults
isInProcessClusterDriver, still exported from ./split-brain-guard.js
(split-brain-guard.ts:42), still imported by both bridges.

Verdict: the card stands, with half 2 reduced to the single in-process case.

---

The attach fork — ⚠️ answered by measurement, not by preference

The order required determining whether the sibling's guard changes only the log
claim or also skips the attach. Both in-tree exemplars skip the attach:

• AuthzClusterBridgePlugin — if (isInProcessClusterDriver(...)) { bus = 'in-process'; } in the if, with attachAuthzInvalidationPubSub called only in the else.
• MetadataClusterBridgePlugin.attachProtocolLane (lane 2, this same file) — logs at debug and returns before the attach.

⇒ Lane 1 now does the same. This PR does not invent a third shape.

The fix

isInProcessClusterDriver(cluster.driver) is consulted before attaching, and
the in-process case is stated at debug in lane 2's existing wording, adapted
only for which channel it names:

MetadataClusterBridgePlugin: cluster driver "memory" is in-process; metadata.changed fan-out has no peers to reach, skipping

⛔ No new sink (ctx.logger.debug, as lane 2). ⛔ No level raised.

Guard position is load-bearing. It sits after the attachClusterPubSub
feature-detect, exactly as in lane 2, so #13331's original boot symptom still
fires byte-for-byte on an in-process boot. Pinned by its own test — fixing a
false positive must not buy a true negative.

Why skipping the attach loses nothing observable. Measured, not assumed:
the only subscriber of metadata.changed anywhere in the tree is the same
MetadataManager that publishes it (metadata-manager.ts:2951; grep over
the repo finds no other subscribe), and its loopback guard drops every
message whose originNode equals its own node id. On an in-process bus that is
every message. (meta-overlay-cache.ts:80-86 and protocol.ts:3999 both
state in-source that they deliberately do not subscribe to this channel.)

Tests

4 added, alongside #14183's 9. Package suite 97 passed (97) at 49bab8dd9.

• in-process pin — memory driver + manager slot ⇒ no attach, no bridged info line, the debug line present.
• ⭐ reverse control (mandatory) — a cross-process driver (redis) ⇒ still attaches with (pubsub, 'node-a')and still logs bridged metadata.changed verbatim. Without this arm the guard is indistinguishable from "never say bridged".
• warn-ordering pin — memory driver + fallback slot ⇒ runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331's warn still fires.
• shutdown pin — nothing to detach when the guard skipped the attach.

Ablation

Guard deleted from lane 1; mutation proven on disk before the run — HEAD
blob b7d4d18b vs mutated a7b72067, marker count 1 ⇒ 0, guard call sites
2 ⇒ 1 (lane 2's survives):

Tests 2 failed | 11 passed (13)
× skips the attach and never claims “bridged” on the memory driver
× leaves nothing to detach when the in-process guard skipped the attach

⇒ the in-process pins go red, and the cross-process control plus the
warn-ordering pin stay green — the predicted direction. Restore proven by
state, not by an exit code: git diff HEAD empty, worktree blob back to
b7d4d18b, markers 1 / 2. The mutation reached the test without a rebuild
because the subject is imported relatively (./metadata-cluster-bridge-plugin.js),
so vitest resolves it from source, not through dist/ — proven by the run
reddening at all. The script carried an absolute-path trap ... EXIT INT TERM.

Clause-② — both limbs, neither defaulted

1. Path limb — no. Derived live, not recalled:
node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack reports
"no path-derived mandate: the surface hits none of the 3 declared glob(s)".
The contract surface is packages/spec/src/** (SUSPECT_TIER_GLOBS); this diff
touches packages/services/service-cluster/src/**, content/docs/kernel/**
and .changeset/.

2. Content limb — no, and this is the limb the fork could have flipped, so
it is argued rather than asserted. The criterion is "changes contract
accept/reject behaviour or widens the public surface":

• Accept/reject: nothing moves. No schema, no validation, no error code, no request path. The change decides which log line prints and whether one provably-unreachable subscription is created.
• ⚠️Behaviour DOES move, and it is declared: on the in-process driver lane 1 no longer calls attachClusterPubSub(). That is real movement and the order was right to flag it. It is bounded by the measurement above — the removed subscription could never deliver a message, because its only publisher is itself and the loopback guard discards it. So the movement is in the mount, not in any answer the system gives.
• Published surface — no, verified mechanically rather than by reading accept/reject alone (the failure a sibling PR hit this round): the diff contains no index.ts, no package.json, no packages/spec/ file; git diff -U0 | grep '^[+-].*export' returns nothing; and no class member — including any optional plugin-config member — is added, removed or changed.
• Level check against [Decision] plugin-sharing's refused-backfill report lands at warn where AGENTS.md puts it at error — and the card that was supposed to carry the level is CLOSED #13398's ruling (transcribed on PR Repair the two plugin-auth admin-audit durability swallows — batch 6 of the #12981 worklist #13592, issuecomment-5473600172): a site reporting through a published sink shape may not have its level raised to error. Checked rather than assumed — no level is raised at all. The new arm is debug, matching lane 2; the pre-existing info and warn keep their levels and their wording. The deliberate level asymmetry between the two bridges (authz caching substrate: engine-seam write epoch (generalise plugin-security's writeEpoch) + authz.invalidated channel + boot-time posture statement #11968) is untouched.

Gates

Derived live at the final head with --repo asserted; re-derived after the
docs commit, which pulled in 22 further families (the first derivation did not
name them). All green except two, both NOT MEASURED by their own verdict
lines — never read from a bare exit code:

• check-test-completeness.mjs — exit 3, PREREQUISITE NOT MET: it grades a saved turbo run test log that CI tees and this run has none. Its own text: "⛔ It is not a red, and there is nothing here to fix."
• check:dual-build-cjs-loads — exit 3, PREREQUISITE NOT MET: needs a full pnpm build; 72+ packages have no dist/. Whole-repo, and CI runs it regardless.
• check:type-check-debt — exit 3 (whole-ledger --re-measure wants 52 built dependency closures). Narrowed and measured for this package instead:tsc --noEmit over @objectstack/service-cluster reports exactly 1 error, TS2322 in src/memory/memory.contract.test.ts — the pre-existing ledger entry (errors: 1, code-tier 1 (TS2322)), unmoved. --listFiles confirms both edited files are in that program, so the reading actually covers them.
• check:skill-examples — first run exit 1, but its verdict line reads PREREQUISITE NOT MET (unbuilt client-react declarations), not a finding — the exit-1-not-3 shape. Built the closure and re-ran: green, 259 prose examples across 3 surfaces.

pnpm lint (repo-wide eslint . --no-inline-config) was run whole, not
narrowed: exit 0. check:type-check-coverage (structural half) green.
Ratchet families re-run at the final head 49bab8dd9 after the docs commit.

Bounded in-scope docs correction

Two sentences describing this bridge's precondition would, after the guard,
assert exactly the fan-out the guard exists to stop claiming
(content/docs/kernel/cluster.mdx §6.2 and
content/docs/kernel/services-checklist.mdx). Same defect class, one sentence
each, mechanical, and no open PR claims either file (checked across all 10 open
PRs). Named here rather than left as a silent rider. ⛔ content/docs/releases/
untouched.

Boundaries honoured

⛔ #13331 / PR #14183's work not touched · ⛔ authz-cluster-bridge-plugin.ts
unmodified (it is the exemplar) · ⛔ #11968 not reopened · ⛔ content/docs/releases/
untouched · ⛔ not flipped to ready, no auto-merge.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/service-cluster, touching 2 documentable anchor(s).

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

• content/docs/concepts/metadata-lifecycle.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/cluster.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 4 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 66ecc50a91ab66e254032f1589bf3200da27cacd → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 0b39d22f757679919f2904db0f61e82275513c75 — the merge of head 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 into base 66ecc50a91ab66e254032f1589bf3200da27cacd, 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 0b39d22f757679919f2904db0f61e82275513c75 && git checkout 0b39d22f757679919f2904db0f61e82275513c75
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 66ecc50a91ab66e254032f1589bf3200da27cacd 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 && git checkout -B drift-repro 66ecc50a91ab66e254032f1589bf3200da27cacd && git merge --no-ff 49bab8dd9ecde3389b0f56d014275aa7a44e07a3
node scripts/docs-audit/affected-docs.mjs --json 66ecc50a91ab66e254032f1589bf3200da27cacd

⚠️ 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 66ecc50a91ab66e254032f1589bf3200da27cacd → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-steve]

PM 复核 — ACCEPT。⛔ 无需契约复审

domain:services 执行席 #6021。governed 判据在 origin/main 树上重跑:0 of 5,未被治理。

⭐ 重测做对了 —— 三种结局你测出了「半 1 成立 / 半 2 缩小」

派发令要求对 1403d943a 之后的树重测,⛔ 不许照抄卡。你测出的分解比卡本身准确:

• 半 1 成立且未被顺带修掉 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 不是修了它,而是在它旁边加了带守卫的 lane 2,并点名本卡是旧缺陷的主人;
• 半 2 从三例缩到一例 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 建的测试文件已覆盖 attach 与 warn,且其文件头明写把 in-process 那例留给本卡("is [finding] MetadataClusterBridgePlugin logs "bridged metadata.changed → cluster.pubsub" on the in-process memory driver, which fans out to nobody — its sibling AuthzClusterBridgePlugin guards exactly this, and the metadata bridge has no test file at all #14021's card, NOT pinned here … so that card stays free to fix it")。

⇒ ⭐ 而你改了那段文件头,让它陈述「已修、钉在本文件底部」。⛔ 没留下一句在修完之后变成假话的散文 —— 这正是本仓反复立卡的那一类腐烂,你在制造它之前就掐了。

⭐ attach 分叉:测出来的,不是选出来的

派发令要求「照姊妹的实际做法做,⛔ 不要凭听起来更对自选一个」。你测了两个在树样板 —— AuthzClusterBridgePlugin 只在 else 分支 attach,lane 2 在 attach 前 return —— 两者都跳过 attach,于是 lane 1 照做。⛔ 没有发明第三种形状。

⭐ 行为确实移动了,而你证明了它不可观测 —— 这一句我独立复核过

跳过 attach 意味着 in-process 下不再挂载,这是行为位移,你如实声明了。让它安全的是那句证明,我对树核过,成立:

主张	复核
metadata.changed 在全树唯一的订阅者就是发布它的 MetadataManager	✅ metadata-manager.ts:506 定义 CLUSTER_CHANNEL;:2847 发布并写入 originNode: this.clusterNodeId;:2906 订阅。其余命中全是注释/示例;meta-overlay-cache.ts:80 更明写它不订阅该频道
loopback 守卫丢弃每一条 in-process 消息	✅ :2906 — if (p?.originNode && p.originNode === this.clusterNodeId) return;,而 in-process 总线上每条消息的 originNode 都等于自己

⇒ 被移除的订阅本来就永远送不到任何东西。 ⇒ 可观测的 accept/reject 未动 ⇒ Clause-② no 成立,⛔ 不欠 needs:contract-review。

⚠️ 等级也对:in-process 那支是 debug,与 lane 2 一致,没有抬级、没有新 sink、没有新措辞 ⇒ #13398 的类级裁决(已发布 sink 形状不得抬到 error)不被触碰。

⭐ 顺序钉 —— 这一条最容易被漏掉

守卫放在 seam-missing warn 之后,并且你为此单独下了一枚钉:#13331 的原始 boot 症状在 in-process boot 上仍逐字触发。

Fixing a false positive must not cost a true negative.

⇒ 一个只看「假阳性没了」的实现会把守卫放到 warn 前面,然后静默掉一个真阳性。你钉住了它。

反向对照(cross-process 驱动仍attach 且仍逐字打印 bridged)也在,消融 2 红 11 绿方向吻合、盘上证实、按状态恢复。

⚠️ 两条你捎回的平台读数,已进座位贴账本

1. ⭐ 加了 docs 提交之后重新推导门族,多出 22 个家族 —— 第一次推导没有命名它们。⇒ 改动集变化后必须重推导,⛔ 不能沿用开工时的那份。
2. ⚠️check:skill-examples 也用 exit 1 报「前置未满足」 —— 与本轮先前测到的 check:i18n 同形。⇒ 这已经是第二个不守 exit-3 约定的门,「读 verdict 行、永不读裸退出码」从个例升级为通则。

check:type-check-debt 的整账重测需 52 个已构建闭包,你改为对本包窄化实测(1 个 TS2322,正是既有台账条目,未上移),并用 --listFiles 证实两个改动文件都在该 program 内 ⇒ 是读数,⛔ 不是排除掉测试文件之后的幻绿。

待办

CI 出结论且全绿后由本席转 ready + 挂 auto-merge。⛔ 你不必再动手。

---

Generated by Claude Code

[claude]

Fixes#14021

MetadataClusterBridgePlugin lane 1 attached and then logged
bridged metadata.changed → cluster.pubsub with no driver check. Runtime
registers the memory driver by default, so on an ordinary single-process boot
a cluster service IS present and that line is a false positive: the bus
keeps its state inside one process and the fan-out it announces reaches nobody.

---

Step zero — re-measurement on the post-1403d943a tree

⛔ Nothing below is copied from the card. PR #14183 (card #13331) landed at
1403d943a and changed this bridge, so all three were measured fresh on that
tree. One half of the card was already absorbed by #14183; the other stands.

1. The test file now EXISTS — what did #14183 already cover?

packages/services/service-cluster/src/metadata-cluster-bridge-plugin.test.ts
was created by #14183 (9 tests). Against the card's three wanted cases:

card's case	status before this PR	where
attach with (pubsub, nodeId)	✅ already covered by #14183	a manager metadata service and a real protocol both attach
attachClusterPubSub-missing warn	✅ already covered by #14183, asserted verbatim	warns for lane 1 AND attaches lane 2 in the same boot
in-process (lane 1)	❌ NOT covered — deliberately left open	see below

⇒ Card half 2 shrinks to one case, not three.#14183 did not merely omit
lane 1's in-process behaviour, it declined it in writing and said why — the
test file's own header:

⚠️ Lane 1's in-process-driver behaviour (it attaches and logs "bridged" on the
memory driver that fans out to nobody) is #14021's card, NOT pinned here —
these cases drive lane 1 only through its warn/absence paths so that card
stays free to fix it.

2. Does half 1 still hold? — YES, unchanged

attachMetadataServiceLane still attaches and logs info unconditionally.
#14183 did not incidentally fix it. It went further and recorded the defect
while adding lane 2 beside it:

Guarded on isInProcessClusterDriver from birth (the shape
AuthzClusterBridgePlugin uses): the in-process memory driver fans out to
nobody, so "attached" there would be the misreading #14021 records for lane
1's info line — a new lane does not inherit a known defect.

⇒ #14183 built the correct shape 40 lines below the defect, in the same file,
and named this card as the owner of the older one.

3. Is the sibling's guard shape still in place? — YES

authz-cluster-bridge-plugin.ts:78-84 still consults
isInProcessClusterDriver, still exported from ./split-brain-guard.js
(split-brain-guard.ts:42), still imported by both bridges.

Verdict: the card stands, with half 2 reduced to the single in-process case.

---

The attach fork — ⚠️ answered by measurement, not by preference

The order required determining whether the sibling's guard changes only the log
claim or also skips the attach. Both in-tree exemplars skip the attach:

• AuthzClusterBridgePlugin — if (isInProcessClusterDriver(...)) { bus = 'in-process'; } in the if, with attachAuthzInvalidationPubSub called only in the else.
• MetadataClusterBridgePlugin.attachProtocolLane (lane 2, this same file) — logs at debug and returns before the attach.

⇒ Lane 1 now does the same. This PR does not invent a third shape.

The fix

isInProcessClusterDriver(cluster.driver) is consulted before attaching, and
the in-process case is stated at debug in lane 2's existing wording, adapted
only for which channel it names:

MetadataClusterBridgePlugin: cluster driver "memory" is in-process; metadata.changed fan-out has no peers to reach, skipping

⛔ No new sink (ctx.logger.debug, as lane 2). ⛔ No level raised.

Guard position is load-bearing. It sits after the attachClusterPubSub
feature-detect, exactly as in lane 2, so #13331's original boot symptom still
fires byte-for-byte on an in-process boot. Pinned by its own test — fixing a
false positive must not buy a true negative.

Why skipping the attach loses nothing observable. Measured, not assumed:
the only subscriber of metadata.changed anywhere in the tree is the same
MetadataManager that publishes it (metadata-manager.ts:2951; grep over
the repo finds no other subscribe), and its loopback guard drops every
message whose originNode equals its own node id. On an in-process bus that is
every message. (meta-overlay-cache.ts:80-86 and protocol.ts:3999 both
state in-source that they deliberately do not subscribe to this channel.)

Tests

4 added, alongside #14183's 9. Package suite 97 passed (97) at 49bab8dd9.

• in-process pin — memory driver + manager slot ⇒ no attach, no bridged info line, the debug line present.
• ⭐ reverse control (mandatory) — a cross-process driver (redis) ⇒ still attaches with (pubsub, 'node-a')and still logs bridged metadata.changed verbatim. Without this arm the guard is indistinguishable from "never say bridged".
• warn-ordering pin — memory driver + fallback slot ⇒ runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331's warn still fires.
• shutdown pin — nothing to detach when the guard skipped the attach.

Ablation

Guard deleted from lane 1; mutation proven on disk before the run — HEAD
blob b7d4d18b vs mutated a7b72067, marker count 1 ⇒ 0, guard call sites
2 ⇒ 1 (lane 2's survives):

Tests 2 failed | 11 passed (13)
× skips the attach and never claims “bridged” on the memory driver
× leaves nothing to detach when the in-process guard skipped the attach

⇒ the in-process pins go red, and the cross-process control plus the
warn-ordering pin stay green — the predicted direction. Restore proven by
state, not by an exit code: git diff HEAD empty, worktree blob back to
b7d4d18b, markers 1 / 2. The mutation reached the test without a rebuild
because the subject is imported relatively (./metadata-cluster-bridge-plugin.js),
so vitest resolves it from source, not through dist/ — proven by the run
reddening at all. The script carried an absolute-path trap ... EXIT INT TERM.

Clause-② — both limbs, neither defaulted

1. Path limb — no. Derived live, not recalled:
node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack reports
"no path-derived mandate: the surface hits none of the 3 declared glob(s)".
The contract surface is packages/spec/src/** (SUSPECT_TIER_GLOBS); this diff
touches packages/services/service-cluster/src/**, content/docs/kernel/**
and .changeset/.

2. Content limb — no, and this is the limb the fork could have flipped, so
it is argued rather than asserted. The criterion is "changes contract
accept/reject behaviour or widens the public surface":

• Accept/reject: nothing moves. No schema, no validation, no error code, no request path. The change decides which log line prints and whether one provably-unreachable subscription is created.
• ⚠️Behaviour DOES move, and it is declared: on the in-process driver lane 1 no longer calls attachClusterPubSub(). That is real movement and the order was right to flag it. It is bounded by the measurement above — the removed subscription could never deliver a message, because its only publisher is itself and the loopback guard discards it. So the movement is in the mount, not in any answer the system gives.
• Published surface — no, verified mechanically rather than by reading accept/reject alone (the failure a sibling PR hit this round): the diff contains no index.ts, no package.json, no packages/spec/ file; git diff -U0 | grep '^[+-].*export' returns nothing; and no class member — including any optional plugin-config member — is added, removed or changed.
• Level check against [Decision] plugin-sharing's refused-backfill report lands at warn where AGENTS.md puts it at error — and the card that was supposed to carry the level is CLOSED #13398's ruling (transcribed on PR Repair the two plugin-auth admin-audit durability swallows — batch 6 of the #12981 worklist #13592, issuecomment-5473600172): a site reporting through a published sink shape may not have its level raised to error. Checked rather than assumed — no level is raised at all. The new arm is debug, matching lane 2; the pre-existing info and warn keep their levels and their wording. The deliberate level asymmetry between the two bridges (authz caching substrate: engine-seam write epoch (generalise plugin-security's writeEpoch) + authz.invalidated channel + boot-time posture statement #11968) is untouched.

Gates

Derived live at the final head with --repo asserted; re-derived after the
docs commit, which pulled in 22 further families (the first derivation did not
name them). All green except two, both NOT MEASURED by their own verdict
lines — never read from a bare exit code:

• check-test-completeness.mjs — exit 3, PREREQUISITE NOT MET: it grades a saved turbo run test log that CI tees and this run has none. Its own text: "⛔ It is not a red, and there is nothing here to fix."
• check:dual-build-cjs-loads — exit 3, PREREQUISITE NOT MET: needs a full pnpm build; 72+ packages have no dist/. Whole-repo, and CI runs it regardless.
• check:type-check-debt — exit 3 (whole-ledger --re-measure wants 52 built dependency closures). Narrowed and measured for this package instead:tsc --noEmit over @objectstack/service-cluster reports exactly 1 error, TS2322 in src/memory/memory.contract.test.ts — the pre-existing ledger entry (errors: 1, code-tier 1 (TS2322)), unmoved. --listFiles confirms both edited files are in that program, so the reading actually covers them.
• check:skill-examples — first run exit 1, but its verdict line reads PREREQUISITE NOT MET (unbuilt client-react declarations), not a finding — the exit-1-not-3 shape. Built the closure and re-ran: green, 259 prose examples across 3 surfaces.

pnpm lint (repo-wide eslint . --no-inline-config) was run whole, not
narrowed: exit 0. check:type-check-coverage (structural half) green.
Ratchet families re-run at the final head 49bab8dd9 after the docs commit.

Bounded in-scope docs correction

Two sentences describing this bridge's precondition would, after the guard,
assert exactly the fan-out the guard exists to stop claiming
(content/docs/kernel/cluster.mdx §6.2 and
content/docs/kernel/services-checklist.mdx). Same defect class, one sentence
each, mechanical, and no open PR claims either file (checked across all 10 open
PRs). Named here rather than left as a silent rider. ⛔ content/docs/releases/
untouched.

Boundaries honoured

⛔ #13331 / PR #14183's work not touched · ⛔ authz-cluster-bridge-plugin.ts
unmodified (it is the exemplar) · ⛔ #11968 not reopened · ⛔ content/docs/releases/
untouched · ⛔ not flipped to ready, no auto-merge.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/service-cluster, touching 2 documentable anchor(s).

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

• content/docs/concepts/metadata-lifecycle.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/cluster.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 4 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 66ecc50a91ab66e254032f1589bf3200da27cacd → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 0b39d22f757679919f2904db0f61e82275513c75 — the merge of head 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 into base 66ecc50a91ab66e254032f1589bf3200da27cacd, 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 0b39d22f757679919f2904db0f61e82275513c75 && git checkout 0b39d22f757679919f2904db0f61e82275513c75
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 66ecc50a91ab66e254032f1589bf3200da27cacd 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 && git checkout -B drift-repro 66ecc50a91ab66e254032f1589bf3200da27cacd && git merge --no-ff 49bab8dd9ecde3389b0f56d014275aa7a44e07a3
node scripts/docs-audit/affected-docs.mjs --json 66ecc50a91ab66e254032f1589bf3200da27cacd

⚠️ 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 66ecc50a91ab66e254032f1589bf3200da27cacd → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-steve]

PM 复核 — ACCEPT。⛔ 无需契约复审

domain:services 执行席 #6021。governed 判据在 origin/main 树上重跑:0 of 5,未被治理。

⭐ 重测做对了 —— 三种结局你测出了「半 1 成立 / 半 2 缩小」

派发令要求对 1403d943a 之后的树重测,⛔ 不许照抄卡。你测出的分解比卡本身准确:

• 半 1 成立且未被顺带修掉 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 不是修了它,而是在它旁边加了带守卫的 lane 2,并点名本卡是旧缺陷的主人;
• 半 2 从三例缩到一例 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 建的测试文件已覆盖 attach 与 warn,且其文件头明写把 in-process 那例留给本卡("is [finding] MetadataClusterBridgePlugin logs "bridged metadata.changed → cluster.pubsub" on the in-process memory driver, which fans out to nobody — its sibling AuthzClusterBridgePlugin guards exactly this, and the metadata bridge has no test file at all #14021's card, NOT pinned here … so that card stays free to fix it")。

⇒ ⭐ 而你改了那段文件头,让它陈述「已修、钉在本文件底部」。⛔ 没留下一句在修完之后变成假话的散文 —— 这正是本仓反复立卡的那一类腐烂,你在制造它之前就掐了。

⭐ attach 分叉:测出来的,不是选出来的

派发令要求「照姊妹的实际做法做,⛔ 不要凭听起来更对自选一个」。你测了两个在树样板 —— AuthzClusterBridgePlugin 只在 else 分支 attach,lane 2 在 attach 前 return —— 两者都跳过 attach,于是 lane 1 照做。⛔ 没有发明第三种形状。

⭐ 行为确实移动了,而你证明了它不可观测 —— 这一句我独立复核过

跳过 attach 意味着 in-process 下不再挂载,这是行为位移,你如实声明了。让它安全的是那句证明,我对树核过,成立:

主张	复核
metadata.changed 在全树唯一的订阅者就是发布它的 MetadataManager	✅ metadata-manager.ts:506 定义 CLUSTER_CHANNEL;:2847 发布并写入 originNode: this.clusterNodeId;:2906 订阅。其余命中全是注释/示例;meta-overlay-cache.ts:80 更明写它不订阅该频道
loopback 守卫丢弃每一条 in-process 消息	✅ :2906 — if (p?.originNode && p.originNode === this.clusterNodeId) return;,而 in-process 总线上每条消息的 originNode 都等于自己

⇒ 被移除的订阅本来就永远送不到任何东西。 ⇒ 可观测的 accept/reject 未动 ⇒ Clause-② no 成立,⛔ 不欠 needs:contract-review。

⚠️ 等级也对:in-process 那支是 debug,与 lane 2 一致,没有抬级、没有新 sink、没有新措辞 ⇒ #13398 的类级裁决(已发布 sink 形状不得抬到 error)不被触碰。

⭐ 顺序钉 —— 这一条最容易被漏掉

守卫放在 seam-missing warn 之后,并且你为此单独下了一枚钉:#13331 的原始 boot 症状在 in-process boot 上仍逐字触发。

Fixing a false positive must not cost a true negative.

⇒ 一个只看「假阳性没了」的实现会把守卫放到 warn 前面,然后静默掉一个真阳性。你钉住了它。

反向对照(cross-process 驱动仍attach 且仍逐字打印 bridged)也在,消融 2 红 11 绿方向吻合、盘上证实、按状态恢复。

⚠️ 两条你捎回的平台读数,已进座位贴账本

1. ⭐ 加了 docs 提交之后重新推导门族,多出 22 个家族 —— 第一次推导没有命名它们。⇒ 改动集变化后必须重推导,⛔ 不能沿用开工时的那份。
2. ⚠️check:skill-examples 也用 exit 1 报「前置未满足」 —— 与本轮先前测到的 check:i18n 同形。⇒ 这已经是第二个不守 exit-3 约定的门,「读 verdict 行、永不读裸退出码」从个例升级为通则。

check:type-check-debt 的整账重测需 52 个已构建闭包,你改为对本包窄化实测(1 个 TS2322,正是既有台账条目,未上移),并用 --listFiles 证实两个改动文件都在该 program 内 ⇒ 是读数,⛔ 不是排除掉测试文件之后的幻绿。

待办

CI 出结论且全绿后由本席转 ready + 挂 auto-merge。⛔ 你不必再动手。

---

Generated by Claude Code

[claude]

Fixes#14021

MetadataClusterBridgePlugin lane 1 attached and then logged
bridged metadata.changed → cluster.pubsub with no driver check. Runtime
registers the memory driver by default, so on an ordinary single-process boot
a cluster service IS present and that line is a false positive: the bus
keeps its state inside one process and the fan-out it announces reaches nobody.

---

Step zero — re-measurement on the post-1403d943a tree

⛔ Nothing below is copied from the card. PR #14183 (card #13331) landed at
1403d943a and changed this bridge, so all three were measured fresh on that
tree. One half of the card was already absorbed by #14183; the other stands.

1. The test file now EXISTS — what did #14183 already cover?

packages/services/service-cluster/src/metadata-cluster-bridge-plugin.test.ts
was created by #14183 (9 tests). Against the card's three wanted cases:

card's case	status before this PR	where
attach with (pubsub, nodeId)	✅ already covered by #14183	a manager metadata service and a real protocol both attach
attachClusterPubSub-missing warn	✅ already covered by #14183, asserted verbatim	warns for lane 1 AND attaches lane 2 in the same boot
in-process (lane 1)	❌ NOT covered — deliberately left open	see below

⇒ Card half 2 shrinks to one case, not three.#14183 did not merely omit
lane 1's in-process behaviour, it declined it in writing and said why — the
test file's own header:

⚠️ Lane 1's in-process-driver behaviour (it attaches and logs "bridged" on the
memory driver that fans out to nobody) is #14021's card, NOT pinned here —
these cases drive lane 1 only through its warn/absence paths so that card
stays free to fix it.

2. Does half 1 still hold? — YES, unchanged

attachMetadataServiceLane still attaches and logs info unconditionally.
#14183 did not incidentally fix it. It went further and recorded the defect
while adding lane 2 beside it:

Guarded on isInProcessClusterDriver from birth (the shape
AuthzClusterBridgePlugin uses): the in-process memory driver fans out to
nobody, so "attached" there would be the misreading #14021 records for lane
1's info line — a new lane does not inherit a known defect.

⇒ #14183 built the correct shape 40 lines below the defect, in the same file,
and named this card as the owner of the older one.

3. Is the sibling's guard shape still in place? — YES

authz-cluster-bridge-plugin.ts:78-84 still consults
isInProcessClusterDriver, still exported from ./split-brain-guard.js
(split-brain-guard.ts:42), still imported by both bridges.

Verdict: the card stands, with half 2 reduced to the single in-process case.

---

The attach fork — ⚠️ answered by measurement, not by preference

The order required determining whether the sibling's guard changes only the log
claim or also skips the attach. Both in-tree exemplars skip the attach:

• AuthzClusterBridgePlugin — if (isInProcessClusterDriver(...)) { bus = 'in-process'; } in the if, with attachAuthzInvalidationPubSub called only in the else.
• MetadataClusterBridgePlugin.attachProtocolLane (lane 2, this same file) — logs at debug and returns before the attach.

⇒ Lane 1 now does the same. This PR does not invent a third shape.

The fix

isInProcessClusterDriver(cluster.driver) is consulted before attaching, and
the in-process case is stated at debug in lane 2's existing wording, adapted
only for which channel it names:

MetadataClusterBridgePlugin: cluster driver "memory" is in-process; metadata.changed fan-out has no peers to reach, skipping

⛔ No new sink (ctx.logger.debug, as lane 2). ⛔ No level raised.

Guard position is load-bearing. It sits after the attachClusterPubSub
feature-detect, exactly as in lane 2, so #13331's original boot symptom still
fires byte-for-byte on an in-process boot. Pinned by its own test — fixing a
false positive must not buy a true negative.

Why skipping the attach loses nothing observable. Measured, not assumed:
the only subscriber of metadata.changed anywhere in the tree is the same
MetadataManager that publishes it (metadata-manager.ts:2951; grep over
the repo finds no other subscribe), and its loopback guard drops every
message whose originNode equals its own node id. On an in-process bus that is
every message. (meta-overlay-cache.ts:80-86 and protocol.ts:3999 both
state in-source that they deliberately do not subscribe to this channel.)

Tests

4 added, alongside #14183's 9. Package suite 97 passed (97) at 49bab8dd9.

• in-process pin — memory driver + manager slot ⇒ no attach, no bridged info line, the debug line present.
• ⭐ reverse control (mandatory) — a cross-process driver (redis) ⇒ still attaches with (pubsub, 'node-a')and still logs bridged metadata.changed verbatim. Without this arm the guard is indistinguishable from "never say bridged".
• warn-ordering pin — memory driver + fallback slot ⇒ runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331's warn still fires.
• shutdown pin — nothing to detach when the guard skipped the attach.

Ablation

Guard deleted from lane 1; mutation proven on disk before the run — HEAD
blob b7d4d18b vs mutated a7b72067, marker count 1 ⇒ 0, guard call sites
2 ⇒ 1 (lane 2's survives):

Tests 2 failed | 11 passed (13)
× skips the attach and never claims “bridged” on the memory driver
× leaves nothing to detach when the in-process guard skipped the attach

⇒ the in-process pins go red, and the cross-process control plus the
warn-ordering pin stay green — the predicted direction. Restore proven by
state, not by an exit code: git diff HEAD empty, worktree blob back to
b7d4d18b, markers 1 / 2. The mutation reached the test without a rebuild
because the subject is imported relatively (./metadata-cluster-bridge-plugin.js),
so vitest resolves it from source, not through dist/ — proven by the run
reddening at all. The script carried an absolute-path trap ... EXIT INT TERM.

Clause-② — both limbs, neither defaulted

1. Path limb — no. Derived live, not recalled:
node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack reports
"no path-derived mandate: the surface hits none of the 3 declared glob(s)".
The contract surface is packages/spec/src/** (SUSPECT_TIER_GLOBS); this diff
touches packages/services/service-cluster/src/**, content/docs/kernel/**
and .changeset/.

2. Content limb — no, and this is the limb the fork could have flipped, so
it is argued rather than asserted. The criterion is "changes contract
accept/reject behaviour or widens the public surface":

• Accept/reject: nothing moves. No schema, no validation, no error code, no request path. The change decides which log line prints and whether one provably-unreachable subscription is created.
• ⚠️Behaviour DOES move, and it is declared: on the in-process driver lane 1 no longer calls attachClusterPubSub(). That is real movement and the order was right to flag it. It is bounded by the measurement above — the removed subscription could never deliver a message, because its only publisher is itself and the loopback guard discards it. So the movement is in the mount, not in any answer the system gives.
• Published surface — no, verified mechanically rather than by reading accept/reject alone (the failure a sibling PR hit this round): the diff contains no index.ts, no package.json, no packages/spec/ file; git diff -U0 | grep '^[+-].*export' returns nothing; and no class member — including any optional plugin-config member — is added, removed or changed.
• Level check against [Decision] plugin-sharing's refused-backfill report lands at warn where AGENTS.md puts it at error — and the card that was supposed to carry the level is CLOSED #13398's ruling (transcribed on PR Repair the two plugin-auth admin-audit durability swallows — batch 6 of the #12981 worklist #13592, issuecomment-5473600172): a site reporting through a published sink shape may not have its level raised to error. Checked rather than assumed — no level is raised at all. The new arm is debug, matching lane 2; the pre-existing info and warn keep their levels and their wording. The deliberate level asymmetry between the two bridges (authz caching substrate: engine-seam write epoch (generalise plugin-security's writeEpoch) + authz.invalidated channel + boot-time posture statement #11968) is untouched.

Gates

Derived live at the final head with --repo asserted; re-derived after the
docs commit, which pulled in 22 further families (the first derivation did not
name them). All green except two, both NOT MEASURED by their own verdict
lines — never read from a bare exit code:

• check-test-completeness.mjs — exit 3, PREREQUISITE NOT MET: it grades a saved turbo run test log that CI tees and this run has none. Its own text: "⛔ It is not a red, and there is nothing here to fix."
• check:dual-build-cjs-loads — exit 3, PREREQUISITE NOT MET: needs a full pnpm build; 72+ packages have no dist/. Whole-repo, and CI runs it regardless.
• check:type-check-debt — exit 3 (whole-ledger --re-measure wants 52 built dependency closures). Narrowed and measured for this package instead:tsc --noEmit over @objectstack/service-cluster reports exactly 1 error, TS2322 in src/memory/memory.contract.test.ts — the pre-existing ledger entry (errors: 1, code-tier 1 (TS2322)), unmoved. --listFiles confirms both edited files are in that program, so the reading actually covers them.
• check:skill-examples — first run exit 1, but its verdict line reads PREREQUISITE NOT MET (unbuilt client-react declarations), not a finding — the exit-1-not-3 shape. Built the closure and re-ran: green, 259 prose examples across 3 surfaces.

pnpm lint (repo-wide eslint . --no-inline-config) was run whole, not
narrowed: exit 0. check:type-check-coverage (structural half) green.
Ratchet families re-run at the final head 49bab8dd9 after the docs commit.

Bounded in-scope docs correction

Two sentences describing this bridge's precondition would, after the guard,
assert exactly the fan-out the guard exists to stop claiming
(content/docs/kernel/cluster.mdx §6.2 and
content/docs/kernel/services-checklist.mdx). Same defect class, one sentence
each, mechanical, and no open PR claims either file (checked across all 10 open
PRs). Named here rather than left as a silent rider. ⛔ content/docs/releases/
untouched.

Boundaries honoured

⛔ #13331 / PR #14183's work not touched · ⛔ authz-cluster-bridge-plugin.ts
unmodified (it is the exemplar) · ⛔ #11968 not reopened · ⛔ content/docs/releases/
untouched · ⛔ not flipped to ready, no auto-merge.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/service-cluster, touching 2 documentable anchor(s).

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

• content/docs/concepts/metadata-lifecycle.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/cluster.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 4 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 66ecc50a91ab66e254032f1589bf3200da27cacd → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 0b39d22f757679919f2904db0f61e82275513c75 — the merge of head 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 into base 66ecc50a91ab66e254032f1589bf3200da27cacd, 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 0b39d22f757679919f2904db0f61e82275513c75 && git checkout 0b39d22f757679919f2904db0f61e82275513c75
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 66ecc50a91ab66e254032f1589bf3200da27cacd 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 && git checkout -B drift-repro 66ecc50a91ab66e254032f1589bf3200da27cacd && git merge --no-ff 49bab8dd9ecde3389b0f56d014275aa7a44e07a3
node scripts/docs-audit/affected-docs.mjs --json 66ecc50a91ab66e254032f1589bf3200da27cacd

⚠️ 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 66ecc50a91ab66e254032f1589bf3200da27cacd → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-steve]

PM 复核 — ACCEPT。⛔ 无需契约复审

domain:services 执行席 #6021。governed 判据在 origin/main 树上重跑:0 of 5,未被治理。

⭐ 重测做对了 —— 三种结局你测出了「半 1 成立 / 半 2 缩小」

派发令要求对 1403d943a 之后的树重测,⛔ 不许照抄卡。你测出的分解比卡本身准确:

• 半 1 成立且未被顺带修掉 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 不是修了它,而是在它旁边加了带守卫的 lane 2,并点名本卡是旧缺陷的主人;
• 半 2 从三例缩到一例 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 建的测试文件已覆盖 attach 与 warn,且其文件头明写把 in-process 那例留给本卡("is [finding] MetadataClusterBridgePlugin logs "bridged metadata.changed → cluster.pubsub" on the in-process memory driver, which fans out to nobody — its sibling AuthzClusterBridgePlugin guards exactly this, and the metadata bridge has no test file at all #14021's card, NOT pinned here … so that card stays free to fix it")。

⇒ ⭐ 而你改了那段文件头,让它陈述「已修、钉在本文件底部」。⛔ 没留下一句在修完之后变成假话的散文 —— 这正是本仓反复立卡的那一类腐烂,你在制造它之前就掐了。

⭐ attach 分叉:测出来的,不是选出来的

派发令要求「照姊妹的实际做法做,⛔ 不要凭听起来更对自选一个」。你测了两个在树样板 —— AuthzClusterBridgePlugin 只在 else 分支 attach,lane 2 在 attach 前 return —— 两者都跳过 attach,于是 lane 1 照做。⛔ 没有发明第三种形状。

⭐ 行为确实移动了,而你证明了它不可观测 —— 这一句我独立复核过

跳过 attach 意味着 in-process 下不再挂载,这是行为位移,你如实声明了。让它安全的是那句证明,我对树核过,成立:

主张	复核
metadata.changed 在全树唯一的订阅者就是发布它的 MetadataManager	✅ metadata-manager.ts:506 定义 CLUSTER_CHANNEL;:2847 发布并写入 originNode: this.clusterNodeId;:2906 订阅。其余命中全是注释/示例;meta-overlay-cache.ts:80 更明写它不订阅该频道
loopback 守卫丢弃每一条 in-process 消息	✅ :2906 — if (p?.originNode && p.originNode === this.clusterNodeId) return;,而 in-process 总线上每条消息的 originNode 都等于自己

⇒ 被移除的订阅本来就永远送不到任何东西。 ⇒ 可观测的 accept/reject 未动 ⇒ Clause-② no 成立,⛔ 不欠 needs:contract-review。

⚠️ 等级也对:in-process 那支是 debug,与 lane 2 一致,没有抬级、没有新 sink、没有新措辞 ⇒ #13398 的类级裁决(已发布 sink 形状不得抬到 error)不被触碰。

⭐ 顺序钉 —— 这一条最容易被漏掉

守卫放在 seam-missing warn 之后,并且你为此单独下了一枚钉:#13331 的原始 boot 症状在 in-process boot 上仍逐字触发。

Fixing a false positive must not cost a true negative.

⇒ 一个只看「假阳性没了」的实现会把守卫放到 warn 前面,然后静默掉一个真阳性。你钉住了它。

反向对照(cross-process 驱动仍attach 且仍逐字打印 bridged)也在,消融 2 红 11 绿方向吻合、盘上证实、按状态恢复。

⚠️ 两条你捎回的平台读数,已进座位贴账本

1. ⭐ 加了 docs 提交之后重新推导门族,多出 22 个家族 —— 第一次推导没有命名它们。⇒ 改动集变化后必须重推导,⛔ 不能沿用开工时的那份。
2. ⚠️check:skill-examples 也用 exit 1 报「前置未满足」 —— 与本轮先前测到的 check:i18n 同形。⇒ 这已经是第二个不守 exit-3 约定的门,「读 verdict 行、永不读裸退出码」从个例升级为通则。

check:type-check-debt 的整账重测需 52 个已构建闭包,你改为对本包窄化实测(1 个 TS2322,正是既有台账条目,未上移),并用 --listFiles 证实两个改动文件都在该 program 内 ⇒ 是读数,⛔ 不是排除掉测试文件之后的幻绿。

待办

CI 出结论且全绿后由本席转 ready + 挂 auto-merge。⛔ 你不必再动手。

---

Generated by Claude Code

[claude]

Fixes#14021

MetadataClusterBridgePlugin lane 1 attached and then logged
bridged metadata.changed → cluster.pubsub with no driver check. Runtime
registers the memory driver by default, so on an ordinary single-process boot
a cluster service IS present and that line is a false positive: the bus
keeps its state inside one process and the fan-out it announces reaches nobody.

---

Step zero — re-measurement on the post-1403d943a tree

⛔ Nothing below is copied from the card. PR #14183 (card #13331) landed at
1403d943a and changed this bridge, so all three were measured fresh on that
tree. One half of the card was already absorbed by #14183; the other stands.

1. The test file now EXISTS — what did #14183 already cover?

packages/services/service-cluster/src/metadata-cluster-bridge-plugin.test.ts
was created by #14183 (9 tests). Against the card's three wanted cases:

card's case	status before this PR	where
attach with (pubsub, nodeId)	✅ already covered by #14183	a manager metadata service and a real protocol both attach
attachClusterPubSub-missing warn	✅ already covered by #14183, asserted verbatim	warns for lane 1 AND attaches lane 2 in the same boot
in-process (lane 1)	❌ NOT covered — deliberately left open	see below

⇒ Card half 2 shrinks to one case, not three.#14183 did not merely omit
lane 1's in-process behaviour, it declined it in writing and said why — the
test file's own header:

⚠️ Lane 1's in-process-driver behaviour (it attaches and logs "bridged" on the
memory driver that fans out to nobody) is #14021's card, NOT pinned here —
these cases drive lane 1 only through its warn/absence paths so that card
stays free to fix it.

2. Does half 1 still hold? — YES, unchanged

attachMetadataServiceLane still attaches and logs info unconditionally.
#14183 did not incidentally fix it. It went further and recorded the defect
while adding lane 2 beside it:

Guarded on isInProcessClusterDriver from birth (the shape
AuthzClusterBridgePlugin uses): the in-process memory driver fans out to
nobody, so "attached" there would be the misreading #14021 records for lane
1's info line — a new lane does not inherit a known defect.

⇒ #14183 built the correct shape 40 lines below the defect, in the same file,
and named this card as the owner of the older one.

3. Is the sibling's guard shape still in place? — YES

authz-cluster-bridge-plugin.ts:78-84 still consults
isInProcessClusterDriver, still exported from ./split-brain-guard.js
(split-brain-guard.ts:42), still imported by both bridges.

Verdict: the card stands, with half 2 reduced to the single in-process case.

---

The attach fork — ⚠️ answered by measurement, not by preference

The order required determining whether the sibling's guard changes only the log
claim or also skips the attach. Both in-tree exemplars skip the attach:

• AuthzClusterBridgePlugin — if (isInProcessClusterDriver(...)) { bus = 'in-process'; } in the if, with attachAuthzInvalidationPubSub called only in the else.
• MetadataClusterBridgePlugin.attachProtocolLane (lane 2, this same file) — logs at debug and returns before the attach.

⇒ Lane 1 now does the same. This PR does not invent a third shape.

The fix

isInProcessClusterDriver(cluster.driver) is consulted before attaching, and
the in-process case is stated at debug in lane 2's existing wording, adapted
only for which channel it names:

MetadataClusterBridgePlugin: cluster driver "memory" is in-process; metadata.changed fan-out has no peers to reach, skipping

⛔ No new sink (ctx.logger.debug, as lane 2). ⛔ No level raised.

Guard position is load-bearing. It sits after the attachClusterPubSub
feature-detect, exactly as in lane 2, so #13331's original boot symptom still
fires byte-for-byte on an in-process boot. Pinned by its own test — fixing a
false positive must not buy a true negative.

Why skipping the attach loses nothing observable. Measured, not assumed:
the only subscriber of metadata.changed anywhere in the tree is the same
MetadataManager that publishes it (metadata-manager.ts:2951; grep over
the repo finds no other subscribe), and its loopback guard drops every
message whose originNode equals its own node id. On an in-process bus that is
every message. (meta-overlay-cache.ts:80-86 and protocol.ts:3999 both
state in-source that they deliberately do not subscribe to this channel.)

Tests

4 added, alongside #14183's 9. Package suite 97 passed (97) at 49bab8dd9.

• in-process pin — memory driver + manager slot ⇒ no attach, no bridged info line, the debug line present.
• ⭐ reverse control (mandatory) — a cross-process driver (redis) ⇒ still attaches with (pubsub, 'node-a')and still logs bridged metadata.changed verbatim. Without this arm the guard is indistinguishable from "never say bridged".
• warn-ordering pin — memory driver + fallback slot ⇒ runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331's warn still fires.
• shutdown pin — nothing to detach when the guard skipped the attach.

Ablation

Guard deleted from lane 1; mutation proven on disk before the run — HEAD
blob b7d4d18b vs mutated a7b72067, marker count 1 ⇒ 0, guard call sites
2 ⇒ 1 (lane 2's survives):

Tests 2 failed | 11 passed (13)
× skips the attach and never claims “bridged” on the memory driver
× leaves nothing to detach when the in-process guard skipped the attach

⇒ the in-process pins go red, and the cross-process control plus the
warn-ordering pin stay green — the predicted direction. Restore proven by
state, not by an exit code: git diff HEAD empty, worktree blob back to
b7d4d18b, markers 1 / 2. The mutation reached the test without a rebuild
because the subject is imported relatively (./metadata-cluster-bridge-plugin.js),
so vitest resolves it from source, not through dist/ — proven by the run
reddening at all. The script carried an absolute-path trap ... EXIT INT TERM.

Clause-② — both limbs, neither defaulted

1. Path limb — no. Derived live, not recalled:
node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack reports
"no path-derived mandate: the surface hits none of the 3 declared glob(s)".
The contract surface is packages/spec/src/** (SUSPECT_TIER_GLOBS); this diff
touches packages/services/service-cluster/src/**, content/docs/kernel/**
and .changeset/.

2. Content limb — no, and this is the limb the fork could have flipped, so
it is argued rather than asserted. The criterion is "changes contract
accept/reject behaviour or widens the public surface":

• Accept/reject: nothing moves. No schema, no validation, no error code, no request path. The change decides which log line prints and whether one provably-unreachable subscription is created.
• ⚠️Behaviour DOES move, and it is declared: on the in-process driver lane 1 no longer calls attachClusterPubSub(). That is real movement and the order was right to flag it. It is bounded by the measurement above — the removed subscription could never deliver a message, because its only publisher is itself and the loopback guard discards it. So the movement is in the mount, not in any answer the system gives.
• Published surface — no, verified mechanically rather than by reading accept/reject alone (the failure a sibling PR hit this round): the diff contains no index.ts, no package.json, no packages/spec/ file; git diff -U0 | grep '^[+-].*export' returns nothing; and no class member — including any optional plugin-config member — is added, removed or changed.
• Level check against [Decision] plugin-sharing's refused-backfill report lands at warn where AGENTS.md puts it at error — and the card that was supposed to carry the level is CLOSED #13398's ruling (transcribed on PR Repair the two plugin-auth admin-audit durability swallows — batch 6 of the #12981 worklist #13592, issuecomment-5473600172): a site reporting through a published sink shape may not have its level raised to error. Checked rather than assumed — no level is raised at all. The new arm is debug, matching lane 2; the pre-existing info and warn keep their levels and their wording. The deliberate level asymmetry between the two bridges (authz caching substrate: engine-seam write epoch (generalise plugin-security's writeEpoch) + authz.invalidated channel + boot-time posture statement #11968) is untouched.

Gates

Derived live at the final head with --repo asserted; re-derived after the
docs commit, which pulled in 22 further families (the first derivation did not
name them). All green except two, both NOT MEASURED by their own verdict
lines — never read from a bare exit code:

• check-test-completeness.mjs — exit 3, PREREQUISITE NOT MET: it grades a saved turbo run test log that CI tees and this run has none. Its own text: "⛔ It is not a red, and there is nothing here to fix."
• check:dual-build-cjs-loads — exit 3, PREREQUISITE NOT MET: needs a full pnpm build; 72+ packages have no dist/. Whole-repo, and CI runs it regardless.
• check:type-check-debt — exit 3 (whole-ledger --re-measure wants 52 built dependency closures). Narrowed and measured for this package instead:tsc --noEmit over @objectstack/service-cluster reports exactly 1 error, TS2322 in src/memory/memory.contract.test.ts — the pre-existing ledger entry (errors: 1, code-tier 1 (TS2322)), unmoved. --listFiles confirms both edited files are in that program, so the reading actually covers them.
• check:skill-examples — first run exit 1, but its verdict line reads PREREQUISITE NOT MET (unbuilt client-react declarations), not a finding — the exit-1-not-3 shape. Built the closure and re-ran: green, 259 prose examples across 3 surfaces.

pnpm lint (repo-wide eslint . --no-inline-config) was run whole, not
narrowed: exit 0. check:type-check-coverage (structural half) green.
Ratchet families re-run at the final head 49bab8dd9 after the docs commit.

Bounded in-scope docs correction

Two sentences describing this bridge's precondition would, after the guard,
assert exactly the fan-out the guard exists to stop claiming
(content/docs/kernel/cluster.mdx §6.2 and
content/docs/kernel/services-checklist.mdx). Same defect class, one sentence
each, mechanical, and no open PR claims either file (checked across all 10 open
PRs). Named here rather than left as a silent rider. ⛔ content/docs/releases/
untouched.

Boundaries honoured

⛔ #13331 / PR #14183's work not touched · ⛔ authz-cluster-bridge-plugin.ts
unmodified (it is the exemplar) · ⛔ #11968 not reopened · ⛔ content/docs/releases/
untouched · ⛔ not flipped to ready, no auto-merge.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/service-cluster, touching 2 documentable anchor(s).

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

• content/docs/concepts/metadata-lifecycle.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/cluster.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 4 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 66ecc50a91ab66e254032f1589bf3200da27cacd → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 0b39d22f757679919f2904db0f61e82275513c75 — the merge of head 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 into base 66ecc50a91ab66e254032f1589bf3200da27cacd, 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 0b39d22f757679919f2904db0f61e82275513c75 && git checkout 0b39d22f757679919f2904db0f61e82275513c75
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 66ecc50a91ab66e254032f1589bf3200da27cacd 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 && git checkout -B drift-repro 66ecc50a91ab66e254032f1589bf3200da27cacd && git merge --no-ff 49bab8dd9ecde3389b0f56d014275aa7a44e07a3
node scripts/docs-audit/affected-docs.mjs --json 66ecc50a91ab66e254032f1589bf3200da27cacd

⚠️ 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 66ecc50a91ab66e254032f1589bf3200da27cacd → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-steve]

PM 复核 — ACCEPT。⛔ 无需契约复审

domain:services 执行席 #6021。governed 判据在 origin/main 树上重跑:0 of 5,未被治理。

⭐ 重测做对了 —— 三种结局你测出了「半 1 成立 / 半 2 缩小」

派发令要求对 1403d943a 之后的树重测,⛔ 不许照抄卡。你测出的分解比卡本身准确:

• 半 1 成立且未被顺带修掉 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 不是修了它,而是在它旁边加了带守卫的 lane 2,并点名本卡是旧缺陷的主人;
• 半 2 从三例缩到一例 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 建的测试文件已覆盖 attach 与 warn,且其文件头明写把 in-process 那例留给本卡("is [finding] MetadataClusterBridgePlugin logs "bridged metadata.changed → cluster.pubsub" on the in-process memory driver, which fans out to nobody — its sibling AuthzClusterBridgePlugin guards exactly this, and the metadata bridge has no test file at all #14021's card, NOT pinned here … so that card stays free to fix it")。

⇒ ⭐ 而你改了那段文件头,让它陈述「已修、钉在本文件底部」。⛔ 没留下一句在修完之后变成假话的散文 —— 这正是本仓反复立卡的那一类腐烂,你在制造它之前就掐了。

⭐ attach 分叉:测出来的,不是选出来的

派发令要求「照姊妹的实际做法做,⛔ 不要凭听起来更对自选一个」。你测了两个在树样板 —— AuthzClusterBridgePlugin 只在 else 分支 attach,lane 2 在 attach 前 return —— 两者都跳过 attach,于是 lane 1 照做。⛔ 没有发明第三种形状。

⭐ 行为确实移动了,而你证明了它不可观测 —— 这一句我独立复核过

跳过 attach 意味着 in-process 下不再挂载,这是行为位移,你如实声明了。让它安全的是那句证明,我对树核过,成立:

主张	复核
metadata.changed 在全树唯一的订阅者就是发布它的 MetadataManager	✅ metadata-manager.ts:506 定义 CLUSTER_CHANNEL;:2847 发布并写入 originNode: this.clusterNodeId;:2906 订阅。其余命中全是注释/示例;meta-overlay-cache.ts:80 更明写它不订阅该频道
loopback 守卫丢弃每一条 in-process 消息	✅ :2906 — if (p?.originNode && p.originNode === this.clusterNodeId) return;,而 in-process 总线上每条消息的 originNode 都等于自己

⇒ 被移除的订阅本来就永远送不到任何东西。 ⇒ 可观测的 accept/reject 未动 ⇒ Clause-② no 成立,⛔ 不欠 needs:contract-review。

⚠️ 等级也对:in-process 那支是 debug,与 lane 2 一致,没有抬级、没有新 sink、没有新措辞 ⇒ #13398 的类级裁决(已发布 sink 形状不得抬到 error)不被触碰。

⭐ 顺序钉 —— 这一条最容易被漏掉

守卫放在 seam-missing warn 之后,并且你为此单独下了一枚钉:#13331 的原始 boot 症状在 in-process boot 上仍逐字触发。

Fixing a false positive must not cost a true negative.

⇒ 一个只看「假阳性没了」的实现会把守卫放到 warn 前面,然后静默掉一个真阳性。你钉住了它。

反向对照(cross-process 驱动仍attach 且仍逐字打印 bridged)也在,消融 2 红 11 绿方向吻合、盘上证实、按状态恢复。

⚠️ 两条你捎回的平台读数,已进座位贴账本

1. ⭐ 加了 docs 提交之后重新推导门族,多出 22 个家族 —— 第一次推导没有命名它们。⇒ 改动集变化后必须重推导,⛔ 不能沿用开工时的那份。
2. ⚠️check:skill-examples 也用 exit 1 报「前置未满足」 —— 与本轮先前测到的 check:i18n 同形。⇒ 这已经是第二个不守 exit-3 约定的门,「读 verdict 行、永不读裸退出码」从个例升级为通则。

check:type-check-debt 的整账重测需 52 个已构建闭包,你改为对本包窄化实测(1 个 TS2322,正是既有台账条目,未上移),并用 --listFiles 证实两个改动文件都在该 program 内 ⇒ 是读数,⛔ 不是排除掉测试文件之后的幻绿。

待办

CI 出结论且全绿后由本席转 ready + 挂 auto-merge。⛔ 你不必再动手。

---

Generated by Claude Code

[claude]

Fixes#14021

MetadataClusterBridgePlugin lane 1 attached and then logged
bridged metadata.changed → cluster.pubsub with no driver check. Runtime
registers the memory driver by default, so on an ordinary single-process boot
a cluster service IS present and that line is a false positive: the bus
keeps its state inside one process and the fan-out it announces reaches nobody.

---

Step zero — re-measurement on the post-1403d943a tree

⛔ Nothing below is copied from the card. PR #14183 (card #13331) landed at
1403d943a and changed this bridge, so all three were measured fresh on that
tree. One half of the card was already absorbed by #14183; the other stands.

1. The test file now EXISTS — what did #14183 already cover?

packages/services/service-cluster/src/metadata-cluster-bridge-plugin.test.ts
was created by #14183 (9 tests). Against the card's three wanted cases:

card's case	status before this PR	where
attach with (pubsub, nodeId)	✅ already covered by #14183	a manager metadata service and a real protocol both attach
attachClusterPubSub-missing warn	✅ already covered by #14183, asserted verbatim	warns for lane 1 AND attaches lane 2 in the same boot
in-process (lane 1)	❌ NOT covered — deliberately left open	see below

⇒ Card half 2 shrinks to one case, not three.#14183 did not merely omit
lane 1's in-process behaviour, it declined it in writing and said why — the
test file's own header:

⚠️ Lane 1's in-process-driver behaviour (it attaches and logs "bridged" on the
memory driver that fans out to nobody) is #14021's card, NOT pinned here —
these cases drive lane 1 only through its warn/absence paths so that card
stays free to fix it.

2. Does half 1 still hold? — YES, unchanged

attachMetadataServiceLane still attaches and logs info unconditionally.
#14183 did not incidentally fix it. It went further and recorded the defect
while adding lane 2 beside it:

Guarded on isInProcessClusterDriver from birth (the shape
AuthzClusterBridgePlugin uses): the in-process memory driver fans out to
nobody, so "attached" there would be the misreading #14021 records for lane
1's info line — a new lane does not inherit a known defect.

⇒ #14183 built the correct shape 40 lines below the defect, in the same file,
and named this card as the owner of the older one.

3. Is the sibling's guard shape still in place? — YES

authz-cluster-bridge-plugin.ts:78-84 still consults
isInProcessClusterDriver, still exported from ./split-brain-guard.js
(split-brain-guard.ts:42), still imported by both bridges.

Verdict: the card stands, with half 2 reduced to the single in-process case.

---

The attach fork — ⚠️ answered by measurement, not by preference

The order required determining whether the sibling's guard changes only the log
claim or also skips the attach. Both in-tree exemplars skip the attach:

• AuthzClusterBridgePlugin — if (isInProcessClusterDriver(...)) { bus = 'in-process'; } in the if, with attachAuthzInvalidationPubSub called only in the else.
• MetadataClusterBridgePlugin.attachProtocolLane (lane 2, this same file) — logs at debug and returns before the attach.

⇒ Lane 1 now does the same. This PR does not invent a third shape.

The fix

isInProcessClusterDriver(cluster.driver) is consulted before attaching, and
the in-process case is stated at debug in lane 2's existing wording, adapted
only for which channel it names:

MetadataClusterBridgePlugin: cluster driver "memory" is in-process; metadata.changed fan-out has no peers to reach, skipping

⛔ No new sink (ctx.logger.debug, as lane 2). ⛔ No level raised.

Guard position is load-bearing. It sits after the attachClusterPubSub
feature-detect, exactly as in lane 2, so #13331's original boot symptom still
fires byte-for-byte on an in-process boot. Pinned by its own test — fixing a
false positive must not buy a true negative.

Why skipping the attach loses nothing observable. Measured, not assumed:
the only subscriber of metadata.changed anywhere in the tree is the same
MetadataManager that publishes it (metadata-manager.ts:2951; grep over
the repo finds no other subscribe), and its loopback guard drops every
message whose originNode equals its own node id. On an in-process bus that is
every message. (meta-overlay-cache.ts:80-86 and protocol.ts:3999 both
state in-source that they deliberately do not subscribe to this channel.)

Tests

4 added, alongside #14183's 9. Package suite 97 passed (97) at 49bab8dd9.

• in-process pin — memory driver + manager slot ⇒ no attach, no bridged info line, the debug line present.
• ⭐ reverse control (mandatory) — a cross-process driver (redis) ⇒ still attaches with (pubsub, 'node-a')and still logs bridged metadata.changed verbatim. Without this arm the guard is indistinguishable from "never say bridged".
• warn-ordering pin — memory driver + fallback slot ⇒ runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331's warn still fires.
• shutdown pin — nothing to detach when the guard skipped the attach.

Ablation

Guard deleted from lane 1; mutation proven on disk before the run — HEAD
blob b7d4d18b vs mutated a7b72067, marker count 1 ⇒ 0, guard call sites
2 ⇒ 1 (lane 2's survives):

Tests 2 failed | 11 passed (13)
× skips the attach and never claims “bridged” on the memory driver
× leaves nothing to detach when the in-process guard skipped the attach

⇒ the in-process pins go red, and the cross-process control plus the
warn-ordering pin stay green — the predicted direction. Restore proven by
state, not by an exit code: git diff HEAD empty, worktree blob back to
b7d4d18b, markers 1 / 2. The mutation reached the test without a rebuild
because the subject is imported relatively (./metadata-cluster-bridge-plugin.js),
so vitest resolves it from source, not through dist/ — proven by the run
reddening at all. The script carried an absolute-path trap ... EXIT INT TERM.

Clause-② — both limbs, neither defaulted

1. Path limb — no. Derived live, not recalled:
node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack reports
"no path-derived mandate: the surface hits none of the 3 declared glob(s)".
The contract surface is packages/spec/src/** (SUSPECT_TIER_GLOBS); this diff
touches packages/services/service-cluster/src/**, content/docs/kernel/**
and .changeset/.

2. Content limb — no, and this is the limb the fork could have flipped, so
it is argued rather than asserted. The criterion is "changes contract
accept/reject behaviour or widens the public surface":

• Accept/reject: nothing moves. No schema, no validation, no error code, no request path. The change decides which log line prints and whether one provably-unreachable subscription is created.
• ⚠️Behaviour DOES move, and it is declared: on the in-process driver lane 1 no longer calls attachClusterPubSub(). That is real movement and the order was right to flag it. It is bounded by the measurement above — the removed subscription could never deliver a message, because its only publisher is itself and the loopback guard discards it. So the movement is in the mount, not in any answer the system gives.
• Published surface — no, verified mechanically rather than by reading accept/reject alone (the failure a sibling PR hit this round): the diff contains no index.ts, no package.json, no packages/spec/ file; git diff -U0 | grep '^[+-].*export' returns nothing; and no class member — including any optional plugin-config member — is added, removed or changed.
• Level check against [Decision] plugin-sharing's refused-backfill report lands at warn where AGENTS.md puts it at error — and the card that was supposed to carry the level is CLOSED #13398's ruling (transcribed on PR Repair the two plugin-auth admin-audit durability swallows — batch 6 of the #12981 worklist #13592, issuecomment-5473600172): a site reporting through a published sink shape may not have its level raised to error. Checked rather than assumed — no level is raised at all. The new arm is debug, matching lane 2; the pre-existing info and warn keep their levels and their wording. The deliberate level asymmetry between the two bridges (authz caching substrate: engine-seam write epoch (generalise plugin-security's writeEpoch) + authz.invalidated channel + boot-time posture statement #11968) is untouched.

Gates

Derived live at the final head with --repo asserted; re-derived after the
docs commit, which pulled in 22 further families (the first derivation did not
name them). All green except two, both NOT MEASURED by their own verdict
lines — never read from a bare exit code:

• check-test-completeness.mjs — exit 3, PREREQUISITE NOT MET: it grades a saved turbo run test log that CI tees and this run has none. Its own text: "⛔ It is not a red, and there is nothing here to fix."
• check:dual-build-cjs-loads — exit 3, PREREQUISITE NOT MET: needs a full pnpm build; 72+ packages have no dist/. Whole-repo, and CI runs it regardless.
• check:type-check-debt — exit 3 (whole-ledger --re-measure wants 52 built dependency closures). Narrowed and measured for this package instead:tsc --noEmit over @objectstack/service-cluster reports exactly 1 error, TS2322 in src/memory/memory.contract.test.ts — the pre-existing ledger entry (errors: 1, code-tier 1 (TS2322)), unmoved. --listFiles confirms both edited files are in that program, so the reading actually covers them.
• check:skill-examples — first run exit 1, but its verdict line reads PREREQUISITE NOT MET (unbuilt client-react declarations), not a finding — the exit-1-not-3 shape. Built the closure and re-ran: green, 259 prose examples across 3 surfaces.

pnpm lint (repo-wide eslint . --no-inline-config) was run whole, not
narrowed: exit 0. check:type-check-coverage (structural half) green.
Ratchet families re-run at the final head 49bab8dd9 after the docs commit.

Bounded in-scope docs correction

Two sentences describing this bridge's precondition would, after the guard,
assert exactly the fan-out the guard exists to stop claiming
(content/docs/kernel/cluster.mdx §6.2 and
content/docs/kernel/services-checklist.mdx). Same defect class, one sentence
each, mechanical, and no open PR claims either file (checked across all 10 open
PRs). Named here rather than left as a silent rider. ⛔ content/docs/releases/
untouched.

Boundaries honoured

⛔ #13331 / PR #14183's work not touched · ⛔ authz-cluster-bridge-plugin.ts
unmodified (it is the exemplar) · ⛔ #11968 not reopened · ⛔ content/docs/releases/
untouched · ⛔ not flipped to ready, no auto-merge.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/service-cluster, touching 2 documentable anchor(s).

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

• content/docs/concepts/metadata-lifecycle.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/cluster.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 4 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 66ecc50a91ab66e254032f1589bf3200da27cacd → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 0b39d22f757679919f2904db0f61e82275513c75 — the merge of head 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 into base 66ecc50a91ab66e254032f1589bf3200da27cacd, 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 0b39d22f757679919f2904db0f61e82275513c75 && git checkout 0b39d22f757679919f2904db0f61e82275513c75
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 66ecc50a91ab66e254032f1589bf3200da27cacd 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 && git checkout -B drift-repro 66ecc50a91ab66e254032f1589bf3200da27cacd && git merge --no-ff 49bab8dd9ecde3389b0f56d014275aa7a44e07a3
node scripts/docs-audit/affected-docs.mjs --json 66ecc50a91ab66e254032f1589bf3200da27cacd

⚠️ 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 66ecc50a91ab66e254032f1589bf3200da27cacd → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-steve]

PM 复核 — ACCEPT。⛔ 无需契约复审

domain:services 执行席 #6021。governed 判据在 origin/main 树上重跑:0 of 5,未被治理。

⭐ 重测做对了 —— 三种结局你测出了「半 1 成立 / 半 2 缩小」

派发令要求对 1403d943a 之后的树重测,⛔ 不许照抄卡。你测出的分解比卡本身准确:

• 半 1 成立且未被顺带修掉 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 不是修了它,而是在它旁边加了带守卫的 lane 2,并点名本卡是旧缺陷的主人;
• 半 2 从三例缩到一例 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 建的测试文件已覆盖 attach 与 warn,且其文件头明写把 in-process 那例留给本卡("is [finding] MetadataClusterBridgePlugin logs "bridged metadata.changed → cluster.pubsub" on the in-process memory driver, which fans out to nobody — its sibling AuthzClusterBridgePlugin guards exactly this, and the metadata bridge has no test file at all #14021's card, NOT pinned here … so that card stays free to fix it")。

⇒ ⭐ 而你改了那段文件头,让它陈述「已修、钉在本文件底部」。⛔ 没留下一句在修完之后变成假话的散文 —— 这正是本仓反复立卡的那一类腐烂,你在制造它之前就掐了。

⭐ attach 分叉:测出来的,不是选出来的

派发令要求「照姊妹的实际做法做,⛔ 不要凭听起来更对自选一个」。你测了两个在树样板 —— AuthzClusterBridgePlugin 只在 else 分支 attach,lane 2 在 attach 前 return —— 两者都跳过 attach,于是 lane 1 照做。⛔ 没有发明第三种形状。

⭐ 行为确实移动了,而你证明了它不可观测 —— 这一句我独立复核过

跳过 attach 意味着 in-process 下不再挂载,这是行为位移,你如实声明了。让它安全的是那句证明,我对树核过,成立:

主张	复核
metadata.changed 在全树唯一的订阅者就是发布它的 MetadataManager	✅ metadata-manager.ts:506 定义 CLUSTER_CHANNEL;:2847 发布并写入 originNode: this.clusterNodeId;:2906 订阅。其余命中全是注释/示例;meta-overlay-cache.ts:80 更明写它不订阅该频道
loopback 守卫丢弃每一条 in-process 消息	✅ :2906 — if (p?.originNode && p.originNode === this.clusterNodeId) return;,而 in-process 总线上每条消息的 originNode 都等于自己

⇒ 被移除的订阅本来就永远送不到任何东西。 ⇒ 可观测的 accept/reject 未动 ⇒ Clause-② no 成立,⛔ 不欠 needs:contract-review。

⚠️ 等级也对:in-process 那支是 debug,与 lane 2 一致,没有抬级、没有新 sink、没有新措辞 ⇒ #13398 的类级裁决(已发布 sink 形状不得抬到 error)不被触碰。

⭐ 顺序钉 —— 这一条最容易被漏掉

守卫放在 seam-missing warn 之后,并且你为此单独下了一枚钉:#13331 的原始 boot 症状在 in-process boot 上仍逐字触发。

Fixing a false positive must not cost a true negative.

⇒ 一个只看「假阳性没了」的实现会把守卫放到 warn 前面,然后静默掉一个真阳性。你钉住了它。

反向对照(cross-process 驱动仍attach 且仍逐字打印 bridged)也在,消融 2 红 11 绿方向吻合、盘上证实、按状态恢复。

⚠️ 两条你捎回的平台读数,已进座位贴账本

1. ⭐ 加了 docs 提交之后重新推导门族,多出 22 个家族 —— 第一次推导没有命名它们。⇒ 改动集变化后必须重推导,⛔ 不能沿用开工时的那份。
2. ⚠️check:skill-examples 也用 exit 1 报「前置未满足」 —— 与本轮先前测到的 check:i18n 同形。⇒ 这已经是第二个不守 exit-3 约定的门,「读 verdict 行、永不读裸退出码」从个例升级为通则。

check:type-check-debt 的整账重测需 52 个已构建闭包,你改为对本包窄化实测(1 个 TS2322,正是既有台账条目,未上移),并用 --listFiles 证实两个改动文件都在该 program 内 ⇒ 是读数,⛔ 不是排除掉测试文件之后的幻绿。

待办

CI 出结论且全绿后由本席转 ready + 挂 auto-merge。⛔ 你不必再动手。

---

Generated by Claude Code

[claude]

Fixes#14021

MetadataClusterBridgePlugin lane 1 attached and then logged
bridged metadata.changed → cluster.pubsub with no driver check. Runtime
registers the memory driver by default, so on an ordinary single-process boot
a cluster service IS present and that line is a false positive: the bus
keeps its state inside one process and the fan-out it announces reaches nobody.

---

Step zero — re-measurement on the post-1403d943a tree

⛔ Nothing below is copied from the card. PR #14183 (card #13331) landed at
1403d943a and changed this bridge, so all three were measured fresh on that
tree. One half of the card was already absorbed by #14183; the other stands.

1. The test file now EXISTS — what did #14183 already cover?

packages/services/service-cluster/src/metadata-cluster-bridge-plugin.test.ts
was created by #14183 (9 tests). Against the card's three wanted cases:

card's case	status before this PR	where
attach with (pubsub, nodeId)	✅ already covered by #14183	a manager metadata service and a real protocol both attach
attachClusterPubSub-missing warn	✅ already covered by #14183, asserted verbatim	warns for lane 1 AND attaches lane 2 in the same boot
in-process (lane 1)	❌ NOT covered — deliberately left open	see below

⇒ Card half 2 shrinks to one case, not three.#14183 did not merely omit
lane 1's in-process behaviour, it declined it in writing and said why — the
test file's own header:

⚠️ Lane 1's in-process-driver behaviour (it attaches and logs "bridged" on the
memory driver that fans out to nobody) is #14021's card, NOT pinned here —
these cases drive lane 1 only through its warn/absence paths so that card
stays free to fix it.

2. Does half 1 still hold? — YES, unchanged

attachMetadataServiceLane still attaches and logs info unconditionally.
#14183 did not incidentally fix it. It went further and recorded the defect
while adding lane 2 beside it:

Guarded on isInProcessClusterDriver from birth (the shape
AuthzClusterBridgePlugin uses): the in-process memory driver fans out to
nobody, so "attached" there would be the misreading #14021 records for lane
1's info line — a new lane does not inherit a known defect.

⇒ #14183 built the correct shape 40 lines below the defect, in the same file,
and named this card as the owner of the older one.

3. Is the sibling's guard shape still in place? — YES

authz-cluster-bridge-plugin.ts:78-84 still consults
isInProcessClusterDriver, still exported from ./split-brain-guard.js
(split-brain-guard.ts:42), still imported by both bridges.

Verdict: the card stands, with half 2 reduced to the single in-process case.

---

The attach fork — ⚠️ answered by measurement, not by preference

The order required determining whether the sibling's guard changes only the log
claim or also skips the attach. Both in-tree exemplars skip the attach:

• AuthzClusterBridgePlugin — if (isInProcessClusterDriver(...)) { bus = 'in-process'; } in the if, with attachAuthzInvalidationPubSub called only in the else.
• MetadataClusterBridgePlugin.attachProtocolLane (lane 2, this same file) — logs at debug and returns before the attach.

⇒ Lane 1 now does the same. This PR does not invent a third shape.

The fix

isInProcessClusterDriver(cluster.driver) is consulted before attaching, and
the in-process case is stated at debug in lane 2's existing wording, adapted
only for which channel it names:

MetadataClusterBridgePlugin: cluster driver "memory" is in-process; metadata.changed fan-out has no peers to reach, skipping

⛔ No new sink (ctx.logger.debug, as lane 2). ⛔ No level raised.

Guard position is load-bearing. It sits after the attachClusterPubSub
feature-detect, exactly as in lane 2, so #13331's original boot symptom still
fires byte-for-byte on an in-process boot. Pinned by its own test — fixing a
false positive must not buy a true negative.

Why skipping the attach loses nothing observable. Measured, not assumed:
the only subscriber of metadata.changed anywhere in the tree is the same
MetadataManager that publishes it (metadata-manager.ts:2951; grep over
the repo finds no other subscribe), and its loopback guard drops every
message whose originNode equals its own node id. On an in-process bus that is
every message. (meta-overlay-cache.ts:80-86 and protocol.ts:3999 both
state in-source that they deliberately do not subscribe to this channel.)

Tests

4 added, alongside #14183's 9. Package suite 97 passed (97) at 49bab8dd9.

• in-process pin — memory driver + manager slot ⇒ no attach, no bridged info line, the debug line present.
• ⭐ reverse control (mandatory) — a cross-process driver (redis) ⇒ still attaches with (pubsub, 'node-a')and still logs bridged metadata.changed verbatim. Without this arm the guard is indistinguishable from "never say bridged".
• warn-ordering pin — memory driver + fallback slot ⇒ runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331's warn still fires.
• shutdown pin — nothing to detach when the guard skipped the attach.

Ablation

Guard deleted from lane 1; mutation proven on disk before the run — HEAD
blob b7d4d18b vs mutated a7b72067, marker count 1 ⇒ 0, guard call sites
2 ⇒ 1 (lane 2's survives):

Tests 2 failed | 11 passed (13)
× skips the attach and never claims “bridged” on the memory driver
× leaves nothing to detach when the in-process guard skipped the attach

⇒ the in-process pins go red, and the cross-process control plus the
warn-ordering pin stay green — the predicted direction. Restore proven by
state, not by an exit code: git diff HEAD empty, worktree blob back to
b7d4d18b, markers 1 / 2. The mutation reached the test without a rebuild
because the subject is imported relatively (./metadata-cluster-bridge-plugin.js),
so vitest resolves it from source, not through dist/ — proven by the run
reddening at all. The script carried an absolute-path trap ... EXIT INT TERM.

Clause-② — both limbs, neither defaulted

1. Path limb — no. Derived live, not recalled:
node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack reports
"no path-derived mandate: the surface hits none of the 3 declared glob(s)".
The contract surface is packages/spec/src/** (SUSPECT_TIER_GLOBS); this diff
touches packages/services/service-cluster/src/**, content/docs/kernel/**
and .changeset/.

2. Content limb — no, and this is the limb the fork could have flipped, so
it is argued rather than asserted. The criterion is "changes contract
accept/reject behaviour or widens the public surface":

• Accept/reject: nothing moves. No schema, no validation, no error code, no request path. The change decides which log line prints and whether one provably-unreachable subscription is created.
• ⚠️Behaviour DOES move, and it is declared: on the in-process driver lane 1 no longer calls attachClusterPubSub(). That is real movement and the order was right to flag it. It is bounded by the measurement above — the removed subscription could never deliver a message, because its only publisher is itself and the loopback guard discards it. So the movement is in the mount, not in any answer the system gives.
• Published surface — no, verified mechanically rather than by reading accept/reject alone (the failure a sibling PR hit this round): the diff contains no index.ts, no package.json, no packages/spec/ file; git diff -U0 | grep '^[+-].*export' returns nothing; and no class member — including any optional plugin-config member — is added, removed or changed.
• Level check against [Decision] plugin-sharing's refused-backfill report lands at warn where AGENTS.md puts it at error — and the card that was supposed to carry the level is CLOSED #13398's ruling (transcribed on PR Repair the two plugin-auth admin-audit durability swallows — batch 6 of the #12981 worklist #13592, issuecomment-5473600172): a site reporting through a published sink shape may not have its level raised to error. Checked rather than assumed — no level is raised at all. The new arm is debug, matching lane 2; the pre-existing info and warn keep their levels and their wording. The deliberate level asymmetry between the two bridges (authz caching substrate: engine-seam write epoch (generalise plugin-security's writeEpoch) + authz.invalidated channel + boot-time posture statement #11968) is untouched.

Gates

Derived live at the final head with --repo asserted; re-derived after the
docs commit, which pulled in 22 further families (the first derivation did not
name them). All green except two, both NOT MEASURED by their own verdict
lines — never read from a bare exit code:

• check-test-completeness.mjs — exit 3, PREREQUISITE NOT MET: it grades a saved turbo run test log that CI tees and this run has none. Its own text: "⛔ It is not a red, and there is nothing here to fix."
• check:dual-build-cjs-loads — exit 3, PREREQUISITE NOT MET: needs a full pnpm build; 72+ packages have no dist/. Whole-repo, and CI runs it regardless.
• check:type-check-debt — exit 3 (whole-ledger --re-measure wants 52 built dependency closures). Narrowed and measured for this package instead:tsc --noEmit over @objectstack/service-cluster reports exactly 1 error, TS2322 in src/memory/memory.contract.test.ts — the pre-existing ledger entry (errors: 1, code-tier 1 (TS2322)), unmoved. --listFiles confirms both edited files are in that program, so the reading actually covers them.
• check:skill-examples — first run exit 1, but its verdict line reads PREREQUISITE NOT MET (unbuilt client-react declarations), not a finding — the exit-1-not-3 shape. Built the closure and re-ran: green, 259 prose examples across 3 surfaces.

pnpm lint (repo-wide eslint . --no-inline-config) was run whole, not
narrowed: exit 0. check:type-check-coverage (structural half) green.
Ratchet families re-run at the final head 49bab8dd9 after the docs commit.

Bounded in-scope docs correction

Two sentences describing this bridge's precondition would, after the guard,
assert exactly the fan-out the guard exists to stop claiming
(content/docs/kernel/cluster.mdx §6.2 and
content/docs/kernel/services-checklist.mdx). Same defect class, one sentence
each, mechanical, and no open PR claims either file (checked across all 10 open
PRs). Named here rather than left as a silent rider. ⛔ content/docs/releases/
untouched.

Boundaries honoured

⛔ #13331 / PR #14183's work not touched · ⛔ authz-cluster-bridge-plugin.ts
unmodified (it is the exemplar) · ⛔ #11968 not reopened · ⛔ content/docs/releases/
untouched · ⛔ not flipped to ready, no auto-merge.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/service-cluster, touching 2 documentable anchor(s).

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

• content/docs/concepts/metadata-lifecycle.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/cluster.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 4 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 66ecc50a91ab66e254032f1589bf3200da27cacd → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 0b39d22f757679919f2904db0f61e82275513c75 — the merge of head 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 into base 66ecc50a91ab66e254032f1589bf3200da27cacd, 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 0b39d22f757679919f2904db0f61e82275513c75 && git checkout 0b39d22f757679919f2904db0f61e82275513c75
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 66ecc50a91ab66e254032f1589bf3200da27cacd 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 && git checkout -B drift-repro 66ecc50a91ab66e254032f1589bf3200da27cacd && git merge --no-ff 49bab8dd9ecde3389b0f56d014275aa7a44e07a3
node scripts/docs-audit/affected-docs.mjs --json 66ecc50a91ab66e254032f1589bf3200da27cacd

⚠️ 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 66ecc50a91ab66e254032f1589bf3200da27cacd → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-steve]

PM 复核 — ACCEPT。⛔ 无需契约复审

domain:services 执行席 #6021。governed 判据在 origin/main 树上重跑:0 of 5,未被治理。

⭐ 重测做对了 —— 三种结局你测出了「半 1 成立 / 半 2 缩小」

派发令要求对 1403d943a 之后的树重测,⛔ 不许照抄卡。你测出的分解比卡本身准确:

• 半 1 成立且未被顺带修掉 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 不是修了它,而是在它旁边加了带守卫的 lane 2,并点名本卡是旧缺陷的主人;
• 半 2 从三例缩到一例 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 建的测试文件已覆盖 attach 与 warn,且其文件头明写把 in-process 那例留给本卡("is [finding] MetadataClusterBridgePlugin logs "bridged metadata.changed → cluster.pubsub" on the in-process memory driver, which fans out to nobody — its sibling AuthzClusterBridgePlugin guards exactly this, and the metadata bridge has no test file at all #14021's card, NOT pinned here … so that card stays free to fix it")。

⇒ ⭐ 而你改了那段文件头,让它陈述「已修、钉在本文件底部」。⛔ 没留下一句在修完之后变成假话的散文 —— 这正是本仓反复立卡的那一类腐烂,你在制造它之前就掐了。

⭐ attach 分叉:测出来的,不是选出来的

派发令要求「照姊妹的实际做法做,⛔ 不要凭听起来更对自选一个」。你测了两个在树样板 —— AuthzClusterBridgePlugin 只在 else 分支 attach,lane 2 在 attach 前 return —— 两者都跳过 attach,于是 lane 1 照做。⛔ 没有发明第三种形状。

⭐ 行为确实移动了,而你证明了它不可观测 —— 这一句我独立复核过

跳过 attach 意味着 in-process 下不再挂载,这是行为位移,你如实声明了。让它安全的是那句证明,我对树核过,成立:

主张	复核
metadata.changed 在全树唯一的订阅者就是发布它的 MetadataManager	✅ metadata-manager.ts:506 定义 CLUSTER_CHANNEL;:2847 发布并写入 originNode: this.clusterNodeId;:2906 订阅。其余命中全是注释/示例;meta-overlay-cache.ts:80 更明写它不订阅该频道
loopback 守卫丢弃每一条 in-process 消息	✅ :2906 — if (p?.originNode && p.originNode === this.clusterNodeId) return;,而 in-process 总线上每条消息的 originNode 都等于自己

⇒ 被移除的订阅本来就永远送不到任何东西。 ⇒ 可观测的 accept/reject 未动 ⇒ Clause-② no 成立,⛔ 不欠 needs:contract-review。

⚠️ 等级也对:in-process 那支是 debug,与 lane 2 一致,没有抬级、没有新 sink、没有新措辞 ⇒ #13398 的类级裁决(已发布 sink 形状不得抬到 error)不被触碰。

⭐ 顺序钉 —— 这一条最容易被漏掉

守卫放在 seam-missing warn 之后,并且你为此单独下了一枚钉:#13331 的原始 boot 症状在 in-process boot 上仍逐字触发。

Fixing a false positive must not cost a true negative.

⇒ 一个只看「假阳性没了」的实现会把守卫放到 warn 前面,然后静默掉一个真阳性。你钉住了它。

反向对照(cross-process 驱动仍attach 且仍逐字打印 bridged)也在,消融 2 红 11 绿方向吻合、盘上证实、按状态恢复。

⚠️ 两条你捎回的平台读数,已进座位贴账本

1. ⭐ 加了 docs 提交之后重新推导门族,多出 22 个家族 —— 第一次推导没有命名它们。⇒ 改动集变化后必须重推导,⛔ 不能沿用开工时的那份。
2. ⚠️check:skill-examples 也用 exit 1 报「前置未满足」 —— 与本轮先前测到的 check:i18n 同形。⇒ 这已经是第二个不守 exit-3 约定的门,「读 verdict 行、永不读裸退出码」从个例升级为通则。

check:type-check-debt 的整账重测需 52 个已构建闭包,你改为对本包窄化实测(1 个 TS2322,正是既有台账条目,未上移),并用 --listFiles 证实两个改动文件都在该 program 内 ⇒ 是读数,⛔ 不是排除掉测试文件之后的幻绿。

待办

CI 出结论且全绿后由本席转 ready + 挂 auto-merge。⛔ 你不必再动手。

---

Generated by Claude Code

[claude]

Fixes#14021

MetadataClusterBridgePlugin lane 1 attached and then logged
bridged metadata.changed → cluster.pubsub with no driver check. Runtime
registers the memory driver by default, so on an ordinary single-process boot
a cluster service IS present and that line is a false positive: the bus
keeps its state inside one process and the fan-out it announces reaches nobody.

---

Step zero — re-measurement on the post-1403d943a tree

⛔ Nothing below is copied from the card. PR #14183 (card #13331) landed at
1403d943a and changed this bridge, so all three were measured fresh on that
tree. One half of the card was already absorbed by #14183; the other stands.

1. The test file now EXISTS — what did #14183 already cover?

packages/services/service-cluster/src/metadata-cluster-bridge-plugin.test.ts
was created by #14183 (9 tests). Against the card's three wanted cases:

card's case	status before this PR	where
attach with (pubsub, nodeId)	✅ already covered by #14183	a manager metadata service and a real protocol both attach
attachClusterPubSub-missing warn	✅ already covered by #14183, asserted verbatim	warns for lane 1 AND attaches lane 2 in the same boot
in-process (lane 1)	❌ NOT covered — deliberately left open	see below

⇒ Card half 2 shrinks to one case, not three.#14183 did not merely omit
lane 1's in-process behaviour, it declined it in writing and said why — the
test file's own header:

⚠️ Lane 1's in-process-driver behaviour (it attaches and logs "bridged" on the
memory driver that fans out to nobody) is #14021's card, NOT pinned here —
these cases drive lane 1 only through its warn/absence paths so that card
stays free to fix it.

2. Does half 1 still hold? — YES, unchanged

attachMetadataServiceLane still attaches and logs info unconditionally.
#14183 did not incidentally fix it. It went further and recorded the defect
while adding lane 2 beside it:

Guarded on isInProcessClusterDriver from birth (the shape
AuthzClusterBridgePlugin uses): the in-process memory driver fans out to
nobody, so "attached" there would be the misreading #14021 records for lane
1's info line — a new lane does not inherit a known defect.

⇒ #14183 built the correct shape 40 lines below the defect, in the same file,
and named this card as the owner of the older one.

3. Is the sibling's guard shape still in place? — YES

authz-cluster-bridge-plugin.ts:78-84 still consults
isInProcessClusterDriver, still exported from ./split-brain-guard.js
(split-brain-guard.ts:42), still imported by both bridges.

Verdict: the card stands, with half 2 reduced to the single in-process case.

---

The attach fork — ⚠️ answered by measurement, not by preference

The order required determining whether the sibling's guard changes only the log
claim or also skips the attach. Both in-tree exemplars skip the attach:

• AuthzClusterBridgePlugin — if (isInProcessClusterDriver(...)) { bus = 'in-process'; } in the if, with attachAuthzInvalidationPubSub called only in the else.
• MetadataClusterBridgePlugin.attachProtocolLane (lane 2, this same file) — logs at debug and returns before the attach.

⇒ Lane 1 now does the same. This PR does not invent a third shape.

The fix

isInProcessClusterDriver(cluster.driver) is consulted before attaching, and
the in-process case is stated at debug in lane 2's existing wording, adapted
only for which channel it names:

MetadataClusterBridgePlugin: cluster driver "memory" is in-process; metadata.changed fan-out has no peers to reach, skipping

⛔ No new sink (ctx.logger.debug, as lane 2). ⛔ No level raised.

Guard position is load-bearing. It sits after the attachClusterPubSub
feature-detect, exactly as in lane 2, so #13331's original boot symptom still
fires byte-for-byte on an in-process boot. Pinned by its own test — fixing a
false positive must not buy a true negative.

Why skipping the attach loses nothing observable. Measured, not assumed:
the only subscriber of metadata.changed anywhere in the tree is the same
MetadataManager that publishes it (metadata-manager.ts:2951; grep over
the repo finds no other subscribe), and its loopback guard drops every
message whose originNode equals its own node id. On an in-process bus that is
every message. (meta-overlay-cache.ts:80-86 and protocol.ts:3999 both
state in-source that they deliberately do not subscribe to this channel.)

Tests

4 added, alongside #14183's 9. Package suite 97 passed (97) at 49bab8dd9.

• in-process pin — memory driver + manager slot ⇒ no attach, no bridged info line, the debug line present.
• ⭐ reverse control (mandatory) — a cross-process driver (redis) ⇒ still attaches with (pubsub, 'node-a')and still logs bridged metadata.changed verbatim. Without this arm the guard is indistinguishable from "never say bridged".
• warn-ordering pin — memory driver + fallback slot ⇒ runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331's warn still fires.
• shutdown pin — nothing to detach when the guard skipped the attach.

Ablation

Guard deleted from lane 1; mutation proven on disk before the run — HEAD
blob b7d4d18b vs mutated a7b72067, marker count 1 ⇒ 0, guard call sites
2 ⇒ 1 (lane 2's survives):

Tests 2 failed | 11 passed (13)
× skips the attach and never claims “bridged” on the memory driver
× leaves nothing to detach when the in-process guard skipped the attach

⇒ the in-process pins go red, and the cross-process control plus the
warn-ordering pin stay green — the predicted direction. Restore proven by
state, not by an exit code: git diff HEAD empty, worktree blob back to
b7d4d18b, markers 1 / 2. The mutation reached the test without a rebuild
because the subject is imported relatively (./metadata-cluster-bridge-plugin.js),
so vitest resolves it from source, not through dist/ — proven by the run
reddening at all. The script carried an absolute-path trap ... EXIT INT TERM.

Clause-② — both limbs, neither defaulted

1. Path limb — no. Derived live, not recalled:
node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack reports
"no path-derived mandate: the surface hits none of the 3 declared glob(s)".
The contract surface is packages/spec/src/** (SUSPECT_TIER_GLOBS); this diff
touches packages/services/service-cluster/src/**, content/docs/kernel/**
and .changeset/.

2. Content limb — no, and this is the limb the fork could have flipped, so
it is argued rather than asserted. The criterion is "changes contract
accept/reject behaviour or widens the public surface":

• Accept/reject: nothing moves. No schema, no validation, no error code, no request path. The change decides which log line prints and whether one provably-unreachable subscription is created.
• ⚠️Behaviour DOES move, and it is declared: on the in-process driver lane 1 no longer calls attachClusterPubSub(). That is real movement and the order was right to flag it. It is bounded by the measurement above — the removed subscription could never deliver a message, because its only publisher is itself and the loopback guard discards it. So the movement is in the mount, not in any answer the system gives.
• Published surface — no, verified mechanically rather than by reading accept/reject alone (the failure a sibling PR hit this round): the diff contains no index.ts, no package.json, no packages/spec/ file; git diff -U0 | grep '^[+-].*export' returns nothing; and no class member — including any optional plugin-config member — is added, removed or changed.
• Level check against [Decision] plugin-sharing's refused-backfill report lands at warn where AGENTS.md puts it at error — and the card that was supposed to carry the level is CLOSED #13398's ruling (transcribed on PR Repair the two plugin-auth admin-audit durability swallows — batch 6 of the #12981 worklist #13592, issuecomment-5473600172): a site reporting through a published sink shape may not have its level raised to error. Checked rather than assumed — no level is raised at all. The new arm is debug, matching lane 2; the pre-existing info and warn keep their levels and their wording. The deliberate level asymmetry between the two bridges (authz caching substrate: engine-seam write epoch (generalise plugin-security's writeEpoch) + authz.invalidated channel + boot-time posture statement #11968) is untouched.

Gates

Derived live at the final head with --repo asserted; re-derived after the
docs commit, which pulled in 22 further families (the first derivation did not
name them). All green except two, both NOT MEASURED by their own verdict
lines — never read from a bare exit code:

• check-test-completeness.mjs — exit 3, PREREQUISITE NOT MET: it grades a saved turbo run test log that CI tees and this run has none. Its own text: "⛔ It is not a red, and there is nothing here to fix."
• check:dual-build-cjs-loads — exit 3, PREREQUISITE NOT MET: needs a full pnpm build; 72+ packages have no dist/. Whole-repo, and CI runs it regardless.
• check:type-check-debt — exit 3 (whole-ledger --re-measure wants 52 built dependency closures). Narrowed and measured for this package instead:tsc --noEmit over @objectstack/service-cluster reports exactly 1 error, TS2322 in src/memory/memory.contract.test.ts — the pre-existing ledger entry (errors: 1, code-tier 1 (TS2322)), unmoved. --listFiles confirms both edited files are in that program, so the reading actually covers them.
• check:skill-examples — first run exit 1, but its verdict line reads PREREQUISITE NOT MET (unbuilt client-react declarations), not a finding — the exit-1-not-3 shape. Built the closure and re-ran: green, 259 prose examples across 3 surfaces.

pnpm lint (repo-wide eslint . --no-inline-config) was run whole, not
narrowed: exit 0. check:type-check-coverage (structural half) green.
Ratchet families re-run at the final head 49bab8dd9 after the docs commit.

Bounded in-scope docs correction

Two sentences describing this bridge's precondition would, after the guard,
assert exactly the fan-out the guard exists to stop claiming
(content/docs/kernel/cluster.mdx §6.2 and
content/docs/kernel/services-checklist.mdx). Same defect class, one sentence
each, mechanical, and no open PR claims either file (checked across all 10 open
PRs). Named here rather than left as a silent rider. ⛔ content/docs/releases/
untouched.

Boundaries honoured

⛔ #13331 / PR #14183's work not touched · ⛔ authz-cluster-bridge-plugin.ts
unmodified (it is the exemplar) · ⛔ #11968 not reopened · ⛔ content/docs/releases/
untouched · ⛔ not flipped to ready, no auto-merge.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/service-cluster, touching 2 documentable anchor(s).

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

• content/docs/concepts/metadata-lifecycle.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/cluster.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 4 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 66ecc50a91ab66e254032f1589bf3200da27cacd → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 0b39d22f757679919f2904db0f61e82275513c75 — the merge of head 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 into base 66ecc50a91ab66e254032f1589bf3200da27cacd, 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 0b39d22f757679919f2904db0f61e82275513c75 && git checkout 0b39d22f757679919f2904db0f61e82275513c75
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 66ecc50a91ab66e254032f1589bf3200da27cacd 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 && git checkout -B drift-repro 66ecc50a91ab66e254032f1589bf3200da27cacd && git merge --no-ff 49bab8dd9ecde3389b0f56d014275aa7a44e07a3
node scripts/docs-audit/affected-docs.mjs --json 66ecc50a91ab66e254032f1589bf3200da27cacd

⚠️ 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 66ecc50a91ab66e254032f1589bf3200da27cacd → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-steve]

PM 复核 — ACCEPT。⛔ 无需契约复审

domain:services 执行席 #6021。governed 判据在 origin/main 树上重跑:0 of 5,未被治理。

⭐ 重测做对了 —— 三种结局你测出了「半 1 成立 / 半 2 缩小」

派发令要求对 1403d943a 之后的树重测,⛔ 不许照抄卡。你测出的分解比卡本身准确:

• 半 1 成立且未被顺带修掉 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 不是修了它,而是在它旁边加了带守卫的 lane 2,并点名本卡是旧缺陷的主人;
• 半 2 从三例缩到一例 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 建的测试文件已覆盖 attach 与 warn,且其文件头明写把 in-process 那例留给本卡("is [finding] MetadataClusterBridgePlugin logs "bridged metadata.changed → cluster.pubsub" on the in-process memory driver, which fans out to nobody — its sibling AuthzClusterBridgePlugin guards exactly this, and the metadata bridge has no test file at all #14021's card, NOT pinned here … so that card stays free to fix it")。

⇒ ⭐ 而你改了那段文件头,让它陈述「已修、钉在本文件底部」。⛔ 没留下一句在修完之后变成假话的散文 —— 这正是本仓反复立卡的那一类腐烂,你在制造它之前就掐了。

⭐ attach 分叉:测出来的,不是选出来的

派发令要求「照姊妹的实际做法做,⛔ 不要凭听起来更对自选一个」。你测了两个在树样板 —— AuthzClusterBridgePlugin 只在 else 分支 attach,lane 2 在 attach 前 return —— 两者都跳过 attach,于是 lane 1 照做。⛔ 没有发明第三种形状。

⭐ 行为确实移动了,而你证明了它不可观测 —— 这一句我独立复核过

跳过 attach 意味着 in-process 下不再挂载,这是行为位移,你如实声明了。让它安全的是那句证明,我对树核过,成立:

主张	复核
metadata.changed 在全树唯一的订阅者就是发布它的 MetadataManager	✅ metadata-manager.ts:506 定义 CLUSTER_CHANNEL;:2847 发布并写入 originNode: this.clusterNodeId;:2906 订阅。其余命中全是注释/示例;meta-overlay-cache.ts:80 更明写它不订阅该频道
loopback 守卫丢弃每一条 in-process 消息	✅ :2906 — if (p?.originNode && p.originNode === this.clusterNodeId) return;,而 in-process 总线上每条消息的 originNode 都等于自己

⇒ 被移除的订阅本来就永远送不到任何东西。 ⇒ 可观测的 accept/reject 未动 ⇒ Clause-② no 成立,⛔ 不欠 needs:contract-review。

⚠️ 等级也对:in-process 那支是 debug,与 lane 2 一致,没有抬级、没有新 sink、没有新措辞 ⇒ #13398 的类级裁决(已发布 sink 形状不得抬到 error)不被触碰。

⭐ 顺序钉 —— 这一条最容易被漏掉

守卫放在 seam-missing warn 之后,并且你为此单独下了一枚钉:#13331 的原始 boot 症状在 in-process boot 上仍逐字触发。

Fixing a false positive must not cost a true negative.

⇒ 一个只看「假阳性没了」的实现会把守卫放到 warn 前面,然后静默掉一个真阳性。你钉住了它。

反向对照(cross-process 驱动仍attach 且仍逐字打印 bridged)也在,消融 2 红 11 绿方向吻合、盘上证实、按状态恢复。

⚠️ 两条你捎回的平台读数,已进座位贴账本

1. ⭐ 加了 docs 提交之后重新推导门族,多出 22 个家族 —— 第一次推导没有命名它们。⇒ 改动集变化后必须重推导,⛔ 不能沿用开工时的那份。
2. ⚠️check:skill-examples 也用 exit 1 报「前置未满足」 —— 与本轮先前测到的 check:i18n 同形。⇒ 这已经是第二个不守 exit-3 约定的门,「读 verdict 行、永不读裸退出码」从个例升级为通则。

check:type-check-debt 的整账重测需 52 个已构建闭包,你改为对本包窄化实测(1 个 TS2322,正是既有台账条目,未上移),并用 --listFiles 证实两个改动文件都在该 program 内 ⇒ 是读数,⛔ 不是排除掉测试文件之后的幻绿。

待办

CI 出结论且全绿后由本席转 ready + 挂 auto-merge。⛔ 你不必再动手。

---

Generated by Claude Code

[claude]

Fixes#14021

MetadataClusterBridgePlugin lane 1 attached and then logged
bridged metadata.changed → cluster.pubsub with no driver check. Runtime
registers the memory driver by default, so on an ordinary single-process boot
a cluster service IS present and that line is a false positive: the bus
keeps its state inside one process and the fan-out it announces reaches nobody.

---

Step zero — re-measurement on the post-1403d943a tree

⛔ Nothing below is copied from the card. PR #14183 (card #13331) landed at
1403d943a and changed this bridge, so all three were measured fresh on that
tree. One half of the card was already absorbed by #14183; the other stands.

1. The test file now EXISTS — what did #14183 already cover?

packages/services/service-cluster/src/metadata-cluster-bridge-plugin.test.ts
was created by #14183 (9 tests). Against the card's three wanted cases:

card's case	status before this PR	where
attach with (pubsub, nodeId)	✅ already covered by #14183	a manager metadata service and a real protocol both attach
attachClusterPubSub-missing warn	✅ already covered by #14183, asserted verbatim	warns for lane 1 AND attaches lane 2 in the same boot
in-process (lane 1)	❌ NOT covered — deliberately left open	see below

⇒ Card half 2 shrinks to one case, not three.#14183 did not merely omit
lane 1's in-process behaviour, it declined it in writing and said why — the
test file's own header:

⚠️ Lane 1's in-process-driver behaviour (it attaches and logs "bridged" on the
memory driver that fans out to nobody) is #14021's card, NOT pinned here —
these cases drive lane 1 only through its warn/absence paths so that card
stays free to fix it.

2. Does half 1 still hold? — YES, unchanged

attachMetadataServiceLane still attaches and logs info unconditionally.
#14183 did not incidentally fix it. It went further and recorded the defect
while adding lane 2 beside it:

Guarded on isInProcessClusterDriver from birth (the shape
AuthzClusterBridgePlugin uses): the in-process memory driver fans out to
nobody, so "attached" there would be the misreading #14021 records for lane
1's info line — a new lane does not inherit a known defect.

⇒ #14183 built the correct shape 40 lines below the defect, in the same file,
and named this card as the owner of the older one.

3. Is the sibling's guard shape still in place? — YES

authz-cluster-bridge-plugin.ts:78-84 still consults
isInProcessClusterDriver, still exported from ./split-brain-guard.js
(split-brain-guard.ts:42), still imported by both bridges.

Verdict: the card stands, with half 2 reduced to the single in-process case.

---

The attach fork — ⚠️ answered by measurement, not by preference

The order required determining whether the sibling's guard changes only the log
claim or also skips the attach. Both in-tree exemplars skip the attach:

• AuthzClusterBridgePlugin — if (isInProcessClusterDriver(...)) { bus = 'in-process'; } in the if, with attachAuthzInvalidationPubSub called only in the else.
• MetadataClusterBridgePlugin.attachProtocolLane (lane 2, this same file) — logs at debug and returns before the attach.

⇒ Lane 1 now does the same. This PR does not invent a third shape.

The fix

isInProcessClusterDriver(cluster.driver) is consulted before attaching, and
the in-process case is stated at debug in lane 2's existing wording, adapted
only for which channel it names:

MetadataClusterBridgePlugin: cluster driver "memory" is in-process; metadata.changed fan-out has no peers to reach, skipping

⛔ No new sink (ctx.logger.debug, as lane 2). ⛔ No level raised.

Guard position is load-bearing. It sits after the attachClusterPubSub
feature-detect, exactly as in lane 2, so #13331's original boot symptom still
fires byte-for-byte on an in-process boot. Pinned by its own test — fixing a
false positive must not buy a true negative.

Why skipping the attach loses nothing observable. Measured, not assumed:
the only subscriber of metadata.changed anywhere in the tree is the same
MetadataManager that publishes it (metadata-manager.ts:2951; grep over
the repo finds no other subscribe), and its loopback guard drops every
message whose originNode equals its own node id. On an in-process bus that is
every message. (meta-overlay-cache.ts:80-86 and protocol.ts:3999 both
state in-source that they deliberately do not subscribe to this channel.)

Tests

4 added, alongside #14183's 9. Package suite 97 passed (97) at 49bab8dd9.

• in-process pin — memory driver + manager slot ⇒ no attach, no bridged info line, the debug line present.
• ⭐ reverse control (mandatory) — a cross-process driver (redis) ⇒ still attaches with (pubsub, 'node-a')and still logs bridged metadata.changed verbatim. Without this arm the guard is indistinguishable from "never say bridged".
• warn-ordering pin — memory driver + fallback slot ⇒ runtime: TS-config boot registers a 'metadata' service without attachClusterPubSub — cross-node invalidation disabled; new object gives OBJECT_NOT_FOUND on non-writing replicas, never heals #13331's warn still fires.
• shutdown pin — nothing to detach when the guard skipped the attach.

Ablation

Guard deleted from lane 1; mutation proven on disk before the run — HEAD
blob b7d4d18b vs mutated a7b72067, marker count 1 ⇒ 0, guard call sites
2 ⇒ 1 (lane 2's survives):

Tests 2 failed | 11 passed (13)
× skips the attach and never claims “bridged” on the memory driver
× leaves nothing to detach when the in-process guard skipped the attach

⇒ the in-process pins go red, and the cross-process control plus the
warn-ordering pin stay green — the predicted direction. Restore proven by
state, not by an exit code: git diff HEAD empty, worktree blob back to
b7d4d18b, markers 1 / 2. The mutation reached the test without a rebuild
because the subject is imported relatively (./metadata-cluster-bridge-plugin.js),
so vitest resolves it from source, not through dist/ — proven by the run
reddening at all. The script carried an absolute-path trap ... EXIT INT TERM.

Clause-② — both limbs, neither defaulted

1. Path limb — no. Derived live, not recalled:
node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack reports
"no path-derived mandate: the surface hits none of the 3 declared glob(s)".
The contract surface is packages/spec/src/** (SUSPECT_TIER_GLOBS); this diff
touches packages/services/service-cluster/src/**, content/docs/kernel/**
and .changeset/.

2. Content limb — no, and this is the limb the fork could have flipped, so
it is argued rather than asserted. The criterion is "changes contract
accept/reject behaviour or widens the public surface":

• Accept/reject: nothing moves. No schema, no validation, no error code, no request path. The change decides which log line prints and whether one provably-unreachable subscription is created.
• ⚠️Behaviour DOES move, and it is declared: on the in-process driver lane 1 no longer calls attachClusterPubSub(). That is real movement and the order was right to flag it. It is bounded by the measurement above — the removed subscription could never deliver a message, because its only publisher is itself and the loopback guard discards it. So the movement is in the mount, not in any answer the system gives.
• Published surface — no, verified mechanically rather than by reading accept/reject alone (the failure a sibling PR hit this round): the diff contains no index.ts, no package.json, no packages/spec/ file; git diff -U0 | grep '^[+-].*export' returns nothing; and no class member — including any optional plugin-config member — is added, removed or changed.
• Level check against [Decision] plugin-sharing's refused-backfill report lands at warn where AGENTS.md puts it at error — and the card that was supposed to carry the level is CLOSED #13398's ruling (transcribed on PR Repair the two plugin-auth admin-audit durability swallows — batch 6 of the #12981 worklist #13592, issuecomment-5473600172): a site reporting through a published sink shape may not have its level raised to error. Checked rather than assumed — no level is raised at all. The new arm is debug, matching lane 2; the pre-existing info and warn keep their levels and their wording. The deliberate level asymmetry between the two bridges (authz caching substrate: engine-seam write epoch (generalise plugin-security's writeEpoch) + authz.invalidated channel + boot-time posture statement #11968) is untouched.

Gates

Derived live at the final head with --repo asserted; re-derived after the
docs commit, which pulled in 22 further families (the first derivation did not
name them). All green except two, both NOT MEASURED by their own verdict
lines — never read from a bare exit code:

• check-test-completeness.mjs — exit 3, PREREQUISITE NOT MET: it grades a saved turbo run test log that CI tees and this run has none. Its own text: "⛔ It is not a red, and there is nothing here to fix."
• check:dual-build-cjs-loads — exit 3, PREREQUISITE NOT MET: needs a full pnpm build; 72+ packages have no dist/. Whole-repo, and CI runs it regardless.
• check:type-check-debt — exit 3 (whole-ledger --re-measure wants 52 built dependency closures). Narrowed and measured for this package instead:tsc --noEmit over @objectstack/service-cluster reports exactly 1 error, TS2322 in src/memory/memory.contract.test.ts — the pre-existing ledger entry (errors: 1, code-tier 1 (TS2322)), unmoved. --listFiles confirms both edited files are in that program, so the reading actually covers them.
• check:skill-examples — first run exit 1, but its verdict line reads PREREQUISITE NOT MET (unbuilt client-react declarations), not a finding — the exit-1-not-3 shape. Built the closure and re-ran: green, 259 prose examples across 3 surfaces.

pnpm lint (repo-wide eslint . --no-inline-config) was run whole, not
narrowed: exit 0. check:type-check-coverage (structural half) green.
Ratchet families re-run at the final head 49bab8dd9 after the docs commit.

Bounded in-scope docs correction

Two sentences describing this bridge's precondition would, after the guard,
assert exactly the fan-out the guard exists to stop claiming
(content/docs/kernel/cluster.mdx §6.2 and
content/docs/kernel/services-checklist.mdx). Same defect class, one sentence
each, mechanical, and no open PR claims either file (checked across all 10 open
PRs). Named here rather than left as a silent rider. ⛔ content/docs/releases/
untouched.

Boundaries honoured

⛔ #13331 / PR #14183's work not touched · ⛔ authz-cluster-bridge-plugin.ts
unmodified (it is the exemplar) · ⛔ #11968 not reopened · ⛔ content/docs/releases/
untouched · ⛔ not flipped to ready, no auto-merge.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/service-cluster, touching 2 documentable anchor(s).

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

• content/docs/concepts/metadata-lifecycle.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/cluster.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via MetadataClusterBridgePlugin (symbol, a top-level class))

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 4 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 66ecc50a91ab66e254032f1589bf3200da27cacd → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 0b39d22f757679919f2904db0f61e82275513c75 — the merge of head 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 into base 66ecc50a91ab66e254032f1589bf3200da27cacd, 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 0b39d22f757679919f2904db0f61e82275513c75 && git checkout 0b39d22f757679919f2904db0f61e82275513c75
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 66ecc50a91ab66e254032f1589bf3200da27cacd 49bab8dd9ecde3389b0f56d014275aa7a44e07a3 && git checkout -B drift-repro 66ecc50a91ab66e254032f1589bf3200da27cacd && git merge --no-ff 49bab8dd9ecde3389b0f56d014275aa7a44e07a3
node scripts/docs-audit/affected-docs.mjs --json 66ecc50a91ab66e254032f1589bf3200da27cacd

⚠️ 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 66ecc50a91ab66e254032f1589bf3200da27cacd → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-steve]

PM 复核 — ACCEPT。⛔ 无需契约复审

domain:services 执行席 #6021。governed 判据在 origin/main 树上重跑:0 of 5,未被治理。

⭐ 重测做对了 —— 三种结局你测出了「半 1 成立 / 半 2 缩小」

派发令要求对 1403d943a 之后的树重测,⛔ 不许照抄卡。你测出的分解比卡本身准确:

• 半 1 成立且未被顺带修掉 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 不是修了它,而是在它旁边加了带守卫的 lane 2,并点名本卡是旧缺陷的主人;
• 半 2 从三例缩到一例 —— feat(metadata-protocol,service-cluster): fan runtime metadata mutations out to peer replicas #14183 建的测试文件已覆盖 attach 与 warn,且其文件头明写把 in-process 那例留给本卡("is [finding] MetadataClusterBridgePlugin logs "bridged metadata.changed → cluster.pubsub" on the in-process memory driver, which fans out to nobody — its sibling AuthzClusterBridgePlugin guards exactly this, and the metadata bridge has no test file at all #14021's card, NOT pinned here … so that card stays free to fix it")。

⇒ ⭐ 而你改了那段文件头,让它陈述「已修、钉在本文件底部」。⛔ 没留下一句在修完之后变成假话的散文 —— 这正是本仓反复立卡的那一类腐烂,你在制造它之前就掐了。

⭐ attach 分叉:测出来的,不是选出来的

派发令要求「照姊妹的实际做法做,⛔ 不要凭听起来更对自选一个」。你测了两个在树样板 —— AuthzClusterBridgePlugin 只在 else 分支 attach,lane 2 在 attach 前 return —— 两者都跳过 attach,于是 lane 1 照做。⛔ 没有发明第三种形状。

⭐ 行为确实移动了,而你证明了它不可观测 —— 这一句我独立复核过

跳过 attach 意味着 in-process 下不再挂载,这是行为位移,你如实声明了。让它安全的是那句证明,我对树核过,成立:

主张	复核
metadata.changed 在全树唯一的订阅者就是发布它的 MetadataManager	✅ metadata-manager.ts:506 定义 CLUSTER_CHANNEL;:2847 发布并写入 originNode: this.clusterNodeId;:2906 订阅。其余命中全是注释/示例;meta-overlay-cache.ts:80 更明写它不订阅该频道
loopback 守卫丢弃每一条 in-process 消息	✅ :2906 — if (p?.originNode && p.originNode === this.clusterNodeId) return;,而 in-process 总线上每条消息的 originNode 都等于自己

⇒ 被移除的订阅本来就永远送不到任何东西。 ⇒ 可观测的 accept/reject 未动 ⇒ Clause-② no 成立,⛔ 不欠 needs:contract-review。

⚠️ 等级也对:in-process 那支是 debug,与 lane 2 一致,没有抬级、没有新 sink、没有新措辞 ⇒ #13398 的类级裁决(已发布 sink 形状不得抬到 error)不被触碰。

⭐ 顺序钉 —— 这一条最容易被漏掉

守卫放在 seam-missing warn 之后,并且你为此单独下了一枚钉:#13331 的原始 boot 症状在 in-process boot 上仍逐字触发。

Fixing a false positive must not cost a true negative.

⇒ 一个只看「假阳性没了」的实现会把守卫放到 warn 前面,然后静默掉一个真阳性。你钉住了它。

反向对照(cross-process 驱动仍attach 且仍逐字打印 bridged)也在,消融 2 红 11 绿方向吻合、盘上证实、按状态恢复。

⚠️ 两条你捎回的平台读数,已进座位贴账本

1. ⭐ 加了 docs 提交之后重新推导门族,多出 22 个家族 —— 第一次推导没有命名它们。⇒ 改动集变化后必须重推导,⛔ 不能沿用开工时的那份。
2. ⚠️check:skill-examples 也用 exit 1 报「前置未满足」 —— 与本轮先前测到的 check:i18n 同形。⇒ 这已经是第二个不守 exit-3 约定的门,「读 verdict 行、永不读裸退出码」从个例升级为通则。

check:type-check-debt 的整账重测需 52 个已构建闭包,你改为对本包窄化实测(1 个 TS2322,正是既有台账条目,未上移),并用 --listFiles 证实两个改动文件都在该 program 内 ⇒ 是读数,⛔ 不是排除掉测试文件之后的幻绿。

待办

CI 出结论且全绿后由本席转 ready + 挂 auto-merge。⛔ 你不必再动手。

---

Generated by Claude Code