Should the authz posture statement live outside service-cluster? Runtime now registers AuthzClusterBridgePlugin under cluster: false, so that flag no longer means "this package contributes nothing"

Filed by the domain:engine seat (session session_01LZbWd2jNV1FErXTPSS4Dry) while accepting PR #12652 for #11968. ⛔ Filed as a card rather than raised as a blocker: the PR is green, contract-reviewed and implements a ruled design, and a prose note in a PR body is nobody's inbox.

⚠️ The PR was accepted and is landing. This card exists so the shape question reaches the maintainer without holding a ruled change. If the answer is "move it", that is a follow-up PR, not a revert.

The one-line question

Runtime now registers AuthzClusterBridgePlugin unconditionally — including when cluster: false. That changed an existing pin from "kernel.use is not called at all" to "exactly one plugin, the authz posture bridge".

So cluster: false no longer means "this package contributes nothing." Is that the shape you want, or should the boot-time posture statement live outside the service-cluster package?

Why it was built that way (⛔ this is not a defect report)

Both the dev and the contract reviewer cleared it, and the reasoning is sound: a missing bus is the loudest case the posture check has. Skipping registration under cluster: false would put the statement's absence exactly where the missing bus is — i.e. the platform would go quiet precisely in the configuration most worth announcing. The plugin is inert on the shipped default.

The dev classified it openQuestions: [], "a shape change rather than a bug", and stated it rather than deciding it. That was the right call and this card is the consequence.

四棱卡面块(决策待裁)

背景一句话:授权缓存的开机「姿态声明」现在由 service-cluster 包的 AuthzClusterBridgePlugin 承载,而 Runtime 对它无条件注册 —— 包括 cluster: false 时。代价是 cluster: false 这个开关原本的含义(「这个包什么都不装」)被改写了;收益是「没有总线」这一最该出声的配置不会静默。

选项 A —— 维持现状:姿态声明继续住在 service-cluster,Runtime 无条件注册。
选项 B —— 搬家:把姿态声明移到 core(或 kernel 自身),service-cluster 恢复「cluster: false 即零注册」的旧语义。

实际业务需求:目前没有实测拉力指向任一侧 —— 没有用户报过 cluster: false 下多一个 inert 插件造成的问题,也没人报过姿态声明缺失。这一轴是空的,我据实说明而不是编一个。真正会踩到的是读启动日志或断言插件数量的人:仓内已有一条 pin 因此改写,说明「cluster: false ⇒ 零插件」这个假设是有人真的在依赖的形状。
项目长远合理性:B 更干净 —— 「集群功能开关」和「平台是否声明自己的授权缓存姿态」本来就是两件事,把后者绑在前者的包里,是让一个部署开关顺带决定一个可观测性行为。A 的代价会随时间累积:下一个「必须无条件发生」的东西也会想住进这个包,cluster: false 的含义继续稀释。
防 AI 写代码犯错:这一轴最尖锐,且指向 B。cluster: false 现在是一个名字与行为不符的开关 —— 一个读代码的人(或生成代码的模型)看到 cluster: false,合理推断「service-cluster 不参与」,而事实是它注册了一个插件。这正是本仓反复付账的 declared≠actual 形状。A 若保留,那条「cluster: false 仍会注册 authz 姿态桥」的注释必须是强制且显眼的,否则它会被下一个重构悄悄删掉。
创业阶段不扩散需求:A 明显更省 —— 已经实现、已过契约复审、已绿。B 是一次纯搬迁 PR:跨 core / service-cluster 移动一个插件与其 pin,零新增能力,收益是语义整洁而不是功能。创业阶段不该为「更漂亮」付一次跨包重构,除非上面那条 AI 易错轴被判定为真实成本。

推荐:A(维持现状)+ 一条强制注释,把「cluster: false 仍注册 authz 姿态桥」写在 Runtime 注册处与 cluster 配置项的文档上,并让那条改写过的 pin 显式断言这件事(而不是断言一个数字)。理由:四轴里只有「防 AI 犯错」一轴真正推 B,而那一轴的伤害可以用一条读得到的声明消掉,不必付跨包搬迁的价钱;「实际业务需求」一轴是空的,不足以支撑重构。

⚠️ 本分析看不见什么:① 我没有测量仓内还有多少地方假设「cluster: false ⇒ 零插件」—— 已知一条 pin 因此改写,是否还有第二条、第三条,决定了 A 的注释是否够用;② 分发/部署层若近期要把 cluster 变成面向客户的公开配置项,那 A 的语义债就会变成对外契约债,那时 B 会明显更值 —— 这是路线图问题,只有你能答。

低摩擦裁决格式:回一个字母即可;「A,但 X」我按 A 落地并把 X 记进卡里。

⚠️ Dedup channel DECLARED — this card may be a duplicate

⛔ I could not verify this is not already filed. search_issues returned total_count: 0 for this topic, but the positive control I ran immediately afterwards failed with API rate limit already exceeded — so the zero is not a reading, it is a possibly-degraded channel. This lane has a recorded instance of exactly that failure (search_issues answering 0 on a known-hit control while REST answered 403).

⇒ Treat the zero as unverified. If a duplicate surfaces, close this one as the later card.

Provenance

PR feat(engine,core,cluster): the authorization-cache invalidation substrate — engine-seam write epoch, authz.invalidated channel, boot-time posture statement (#11968) #12652 — the implementation (accepted by this seat, comment 5436232239).
authz caching substrate: engine-seam write epoch (generalise plugin-security's writeEpoch) + authz.invalidated channel + boot-time posture statement #11968 — the substrate card.
Design: cross-request caching for the authenticated request path (tranche 2 of #10757) — write-invalidation-first, short-TTL fallback, configurable staleness window #11633 — the maintainer-accepted design (2026-08-25, 「接受你的建议，继续」, §10.3) whose logic requires the unconditional registration.
Contract review PASS: comment 5434287219 on authz caching substrate: engine-seam write epoch (generalise plugin-security's writeEpoch) + authz.invalidated channel + boot-time posture statement #11968, run at contract-review tier.

Adjudicated — option A. Director seat, batch #1, 2026-08-27 (session session_01MnijPVVDakqK2J335JoJtq, tier machine-read claude-fable-5). Maintainer's one-line ruling on the batch, verbatim: 「12683 本轮不处理，其他同意」 — this card was item 5 with recommendation A, so A is ruled.

Ruling: the posture statement stays in service-cluster with unconditional registration — no cross-package move. The work is the mandatory declaration at three sites, so the declared≠actual hazard the four-facet analysis flagged is pinned down in text and test:

the Runtime registration site — a load-bearing comment stating cluster: false still registers the authz posture bridge, and why (a missing bus is the loudest case the posture check has);
the cluster config option's documentation — same statement, author-facing;
the rewritten pin — make it assert this fact explicitly ("exactly one plugin, the authz posture bridge, including under cluster: false") rather than a bare count, so a refactor that silently drops the registration reds the pin by name.

Option B (move to core/kernel) is recorded as the fallback if the roadmap ever makes cluster a customer-facing public config option — that re-opens this card's question, per its stated confidence gap. Released to pm:queue in the same stroke; domain:engine lane dispatches (small task, no behaviour change).

Generated by Claude Code

Claim: PM seat for the domain:engine lane, session session_01LZbWd2jNV1FErXTPSS4Dry. Dispatching to an os-dev seat on branch claude/issue-12679-cluster-false-posture-declaration.

Clause-②: no — answered deliberately, not skipped. Option A adds two declarations and makes an existing pin more specific; no call that was refused becomes accepted, no public surface widens, no behaviour changes. Standard tier.

Sites located on origin/main so the seat starts from anchors rather than a search:

packages/runtime/src/runtime.ts:86 — this.kernel.use(new AuthzClusterBridgePlugin()); (the unconditional registration).
the cluster config option's author-facing documentation — the seat locates this; it is the one site the ruling names that I did not pin down.
packages/runtime/src/runtime.test.ts:53 — expect(kernel.use).toHaveBeenCalledTimes(1);. That bare count is the pin the ruling says to rewrite into an assertion naming the bridge, so a refactor that silently drops the registration reds it by name instead of by arithmetic.

One measurement before the declarations, and it is this card's own declared gap. The card's confidence gap ① says, in its own words, that it did not measure how many other places in the repo assume cluster: false ⇒ zero plugins — one pin is known to have been rewritten for it, and whether there is a second or third "决定了 A 的注释是否够用". That matters because option A was ruled on the argument that the declared≠actual harm can be erased by one readable declaration. If that assumption is only true at one site, A is cheap as ruled; if several places encode the old meaning, three declarations do not reach them and the seat should report that rather than declare at three sites and call it done. Run the census with a positive control, report the number, then proceed.

⚠️ Dedup channel was DECLARED degraded when this card was filed — search_issues answered total_count: 0, but the positive control immediately after failed with an API rate limit, so that zero was never a reading. If a duplicate surfaces, this is the later card and closes.

Option B (move the posture statement to core/kernel) is the recorded fallback only if the roadmap makes cluster a customer-facing public config option. ⛔ Not in scope here.

Generated by Claude Code

Census before implementing — the card's declared confidence gap ①, measured. os-dev seat, branch claude/issue-12679-cluster-false-posture-declaration, base 96dc446c9c19063edfae26ae30ff75143ef0c5b7.

Answer: 2 live sites encode "cluster: false means service-cluster registers nothing", and both are prose. Zero code sites and zero other test sites. The ruling's three declarations reach both, so option A's premise — that the declared-not-equal-actual harm is erasable by a readable declaration — holds as ruled.

Method (all searches git grep over tracked files at the base commit, so node_modules is out of corpus by construction):

Positive controls, run first — a zero is not a reading until the search is proven to reach the corpus:

cluster !== false matched packages/runtime/src/runtime.ts:67 and :78.
AuthzClusterBridgePlugin matched 5 files; the plugin id authz-cluster-bridge matched 5 files.

Four shapes searched, not just the token:

Plugin-count / kernel.use call-count assertions, whole repo. Exactly 2 exist anywhere: packages/runtime/src/runtime.test.ts:30 and :53 — both already rewritten by the substrate PR, both correct today. No second or third pin exists. (getPlugins / plugins.length also swept: 6 hits, none an assertion about Runtime's registrations.)
Every cluster: false occurrence — 16 hits. Seven are call sites in tests and in packages/cli/src/utils/schema-migrate.ts that use the flag only to avoid standing up a cluster service; none asserts a count or a registration total.
Prose encoding the old meaning — the 2 live sites:
- packages/runtime/src/runtime.ts:29 — the cluster option's docblock: "false: skip auto-registration entirely."
- content/docs/kernel/cluster.mdx:567 — "(pass cluster: false to skip registration entirely)".
  Both say entirely, which is now false: the authz posture bridge is still registered.
Code branching on the flag — exactly 1 branch in the repo, runtime.ts:67, which is the correct one.

Two prose sites nearby are accurate as written and need no change, recorded so the next reader does not re-open them: content/docs/concepts/metadata-lifecycle.mdx:176 names exactly the two plugins cluster: false skips rather than claiming zero, and the substrate changeset already states the registration is unconditional.

Scope note. Both live sites fall inside site 2 as the ruling defines it — "the cluster config option's documentation, same statement, author-facing" — in its two homes: the TypeScript docblock an integrator reads in their editor, and the docs page an operator reads on the site. The dispatch anticipated exactly this ("the runtime config type's docblock, and/or the deployment/configuration page under content/docs"). So this is the ruled three-site declaration, not a widening; nothing extra is being absorbed into the card.

One correction to the dispatch's anchor, which changes the site-3 work without changing its intent. runtime.test.ts:55 already asserts expect(names).toEqual(['com.objectstack.service.authz-cluster-bridge']), so the pin is not a bare count. The defect is ordering: the count assertion at :53 runs first and aborts the test, so the failure an engineer actually sees when the registration is dropped is a count mismatch, and the naming assertion never executes. The rewrite therefore makes the first failing assertion name the bridge. Ablation will show the failure text.

Generated by Claude Code

docs(runtime): declare that cluster:false still registers the authz p…

predict: removing the unconditional AuthzClusterBridgePlugin registra…

chore(changeset): patch @objectstack/runtime for the cluster:false po…

os-dev-report

{
  "issue": 12679,
  "status": "done",
  "branch": "claude/issue-12679-cluster-false-posture-declaration",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/12812",
  "premise_still_valid": true,
  "summary": "Option A implemented as ruled: the authz posture statement stays in service-cluster with unconditional registration, and the deliverable is the mandatory declaration at three sites. (1) packages/runtime/src/runtime.ts registration site: a load-bearing comment stating what cluster:false does NOT mean, why the line sits outside the `cluster !== false` branch (a missing bus is the loudest case the posture check has), that relocating to core was weighed and ruled against, and which author-facing copies and which pin go stale if the line moves. (2) Site 2 in its two homes: the RuntimeConfig.cluster docblock (which ships into the package .d.ts, so it reaches an integrator in their editor) and content/docs/kernel/cluster.mdx section 8 as a warning callout; both previously said 'skip registration entirely', true before the substrate landed and false since. (3) The pin now asserts the bridge BY NAME before any count. ONE CORRECTION TO THE DISPATCH ANCHOR, which changed the work without changing its intent: runtime.test.ts:55 already asserted toEqual(['com.objectstack.service.authz-cluster-bridge']), so the pin was not a bare count. The defect was ORDERING - toHaveBeenCalledTimes(1) at :53 ran first and aborted the test, so the failure an engineer actually saw was 'expected 1, received 0' and the naming assertion never executed. The rewrite makes the FIRST failing assertion name the bridge and carries the contract in its message; the exact-set and count assertions are kept, moved after it. Plugin ids are now named constants and the sibling default-registration test got the same identity-before-cardinality ordering. No behaviour change: two comments, one docs paragraph, one reordered assertion. Option B (move to core/kernel) not touched.",
  "census": "ANSWER: 2 live sites encode 'cluster:false means service-cluster registers nothing', both PROSE; zero code sites and zero other test sites. Method: git grep over tracked files at base 96dc446c9 (node_modules out of corpus by construction). POSITIVE CONTROLS RUN FIRST, before any zero was read: 'cluster !== false' matched runtime.ts:67 and :78; 'AuthzClusterBridgePlugin' matched 5 files; the plugin id 'authz-cluster-bridge' matched 5 files - the searches demonstrably reach the corpus. Four shapes searched, not just the token. (a) Plugin-count / kernel.use call-count assertions in the WHOLE repo: exactly 2 exist anywhere, runtime.test.ts:30 and :53, both already rewritten by the substrate PR and correct today; no second or third pin exists. getPlugins/plugins.length also swept - 6 hits, none an assertion about Runtime's registrations. (b) Every 'cluster: false' occurrence: 16 hits; 7 are call sites in tests and in packages/cli/src/utils/schema-migrate.ts that use the flag only to avoid standing up a cluster service, none asserting a count. (c) Prose encoding the old meaning: the 2 live sites - packages/runtime/src/runtime.ts:29 and content/docs/kernel/cluster.mdx:567, both saying 'skip registration ENTIRELY'. (d) Code branching on the flag: exactly 1, runtime.ts:67, the correct one. Checked and deliberately NOT changed because accurate as written: content/docs/concepts/metadata-lifecycle.mdx:176 names exactly the two plugins cluster:false skips rather than claiming zero, and the substrate changeset already states the registration is unconditional. VERDICT: the ruling's three declarations REACH EVERY SITE. Both live sites fall inside site 2 as the ruling defines it (the cluster option's author-facing documentation) in its two homes - the TS docblock and the docs page - which the dispatch explicitly anticipated, so nothing extra was absorbed into scope. Option A was ruled on the argument that the declared-not-equal-actual harm is erasable by one readable declaration; that assumption HOLDS - the old meaning lives in prose, in exactly the two places the ruling already named, and nowhere in code. Posted to the card as comment 5445482868 BEFORE implementing, as the dispatch required.",
  "site_2_location": "It exists, in two homes, and both were declared. (a) The runtime config type's docblock: RuntimeConfig.cluster in packages/runtime/src/runtime.ts - this is the one that ships, since tsup emits it into the package .d.ts, so it reaches an integrator in their editor at the moment they write the flag. (b) The docs-site page: content/docs/kernel/cluster.mdx section 8 'Configuration surface', which is where cluster:false is documented for an operator; a warning callout was added beside the configuration surface and the phrase 'skip registration entirely' became 'skip that auto-registration'. There is NO separate deployment/configuration page for the option - packages/runtime/README.md does not mention cluster at all, and the RuntimeConfig in content/docs/references/kernel/plugin-security-advanced.mdx is a DIFFERENT type (spec/kernel sandbox resource limits), not this one.",
  "tests": "All readings below are quoted from the tool's own printed verdict line, never from a bare $? after a pipe; heavy runs went through scripts/pm/os-verify-lock.sh. UNION RUN AT FINAL COMMIT e2abbc548 (git status clean at that sha). (1) pnpm --filter @objectstack/runtime test -> 'Test Files 197 passed (197) / Tests 2890 passed (2890)'. (2) The rewritten pin re-run at e2abbc548 -> 'Test Files 1 passed (1) / Tests 6 passed (6)'. (3) pnpm --filter @objectstack/runtime typecheck -> exit 0, but reported as NOT MEASURED for the test edits: this package's tsconfig.json excludes **/*.test.ts, verified with tsc --listFiles (0 hits for src/runtime.test.ts). Measured separately against the ledger's own program shape (the package tsconfig with the exclusion lifted): 217 total test-layer errors, exactly matching the ledger entry TEST_DEBT '@objectstack/runtime': 217, and the 3 errors in the edited file are pre-existing import-level ones (unused beforeEach, unused PluginContext, missing .js extension) that this diff does not touch - so the edits added zero. (4) pnpm check:type-check-debt on a fully built closure (turbo build: 'Tasks: 70 successful, 70 total') -> its own verdict line: 'check-type-check-coverage --re-measure: OK - 31 ledger entr(ies) re-measured in 214.3s, 1570 raw tsc error(s) total, none above its recorded number. surplus: none'. A measurement, not the refusal an unbuilt worktree would have produced. (5) pnpm lint - the WHOLE repo, eslint . --no-inline-config - exit 0 in 55s under the lock. No narrowing claimed and none needed. (6) 30 further gate families, derived from the REAL diff with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack (which read the change set itself from the merge base, three-dot) rather than from the dispatch's list: doc-anchors, doc-authoring, docs-single-h1, doc-frontmatter, docs-section-name, doc-route-spelling, role-word, docs-redirects, docs-audit-scope, section-landing-index, cross-package-test-inputs, test-source-alias, type-source-resolution, published-files, page-declaration-shape, slot-lookup, comment-mask-adoption, plugin-teardown-shape, objectql-double-limit, ci-filter-parity, engine-double-contract, where-matcher, query-options-erasure, nul-bytes, type-check-coverage, empty-changeset, changeset-no-major, adr-0087-registration, changeset-gate-self-tests, objectui-changeset - all exit 0 at e2abbc548.",
  "ablation": "PREDICTION COMMITTED FIRST as empty commit caad4296c, before the mutation, so it could not be edited to match the result. Mutation: delete 'this.kernel.use(new AuthzClusterBridgePlugin());' from packages/runtime/src/runtime.ts. REBUILD: none needed for the mutated module and this is proven rather than asserted - runtime.test.ts imports './runtime' RELATIVELY, so the mutated file is read from source and no dist can stale the leg; its own imports were built beforehand (@objectstack/core is aliased to source in packages/runtime/vitest.config.ts, @objectstack/service-cluster resolves through exports to dist, and the dependency closure was built with pnpm --filter '@objectstack/runtime^...' build, verdict command-exit 0). MUTATION CONFIRMED ON DISK IN BOTH DIRECTIONS BEFORE ANYTHING RAN, anchored on the exact text: removed-text-count 0 (was 1 pre-mutation), injected-marker-count 1 (was 0 pre-mutation), and git hash-object eb0a15ff18c081ab... differing from the HEAD blob 32fc5d29634e39a7... The python edit also asserted exactly 1 anchor occurrence and would have exited nonzero on 0, so a no-op edit could not have passed as a run. RESULT, exactly as predicted: 'Tests 2 failed | 4 passed (6)', SUITE_EXIT=1, and BOTH failures name the bridge. The cluster:false pin's failure message: \"AssertionError: `cluster: false` must STILL register the authz posture bridge (com.objectstack.service.authz-cluster-bridge). It is registered unconditionally in Runtime, outside the `cluster !== false` branch, because a grants cache with no invalidation bus at all is the loudest case the posture check has (#12679 option A). If you removed that registration, restore it; the flag skips the CLUSTER plugins only.: expected [] to include 'com.objectstack.service.authz-cluster...'\" at src/runtime.test.ts:91. The sibling default-registration test failed at 'expected [ ...(2) ] to include com.objectstack.service.authz-cluster...' (src/runtime.test.ts:55) rather than at 3 -> 2. NOT ONE count-mismatch message appears anywhere in the output - which is the thing the ruling asked to be proven, and is distinguishable from the old assertion's failure. RESTORE PROVEN, not assumed: trap RESTORE_FN EXIT INT TERM with ABSOLUTE paths seeded from git rev-parse --show-toplevel, restoring with 'git checkout HEAD -- ABS_PATH' (naming HEAD, never a bare checkout, so a polluted index cannot hand back the mutation). After: git hash-object equals the HEAD blob 32fc5d29634e39a7... exactly (non-empty, checked - an empty hash would be a failure, not a 'nothing to compare'), 0 residual markers, the registration line back at count 1, 'git diff HEAD' EMPTY and 'git status --porcelain' empty.",
  "changeset": "WRITTEN: .changeset/cluster-false-authz-posture-declaration.md, '@objectstack/runtime': patch. Argued rather than defaulted, and the skip-changeset case is real: this ships no behaviour change at all - two comments, one docs paragraph, one reordered assertion. The counter-argument wins because the deliverable IS a statement to readers, and the statement is published two ways. First, the RuntimeConfig.cluster docblock is emitted into the package's .d.ts by the tsup DTS build, so it is part of what @objectstack/runtime ships to an integrator, not just repo-internal prose. Second, the docs correction retires a sentence ('skip registration entirely') that has been WRONG since the substrate landed - an operator who read it holds a false belief today. A correction whose entire value is telling people something they currently believe wrongly, shipped with no release note, reaches only readers of the source. So the changeset is the delivery mechanism for the fix, not paperwork about it. Patch rather than minor: no API surface moves. No skip-changeset label applied, and none needed.",
  "mcp_calls": "4 - issue_read(get), issue_read(get_comments), add_issue_comment(census), add_issue_comment(this report). Everything else went through the repo-scoped REST channel, which was probed and works from this seat (HTTP 200 on /repos/...); note the /search/issues endpoint is BLOCKED here ('sessions are bound to their configured repositories'), so dedup used targeted repo-scoped label listings plus local grep, never a wide paginated scan.",
  "open_questions": [],
  "out_of_scope_findings": [
    "NOT FILED, deliberately, after dedup: packages/runtime/tsconfig.json excludes **/*.test.ts with no sibling tsconfig.test.json, so 'pnpm --filter @objectstack/runtime typecheck' renders a green verdict that says nothing about 197 test files. This LOOKS like the AGENTS.md violation and is not a new one - the package carries TEST_DEBT '@objectstack/runtime': 217 in scripts/check-type-check-coverage.mjs, i.e. it is the standing ledgered condition already filed as #12511 ('A type error in a ledgered package's tests is invisible to its own typecheck...', 19 packages in that state). Dedup channel: repo-scoped REST listings of label:finding (13 open, no typecheck/tsconfig hit), label:pm:queue (93 open, one hit - #12511) and label:needs-user-decision (12 open, one hit - #12799, about ledger surplus, different), each a single page with no Link header, plus reading #12511's body to confirm coverage. Positive control: the listings returned real card titles, so the zeros are readings. Filing a duplicate would have been the wrong move."
  ]
}

Generated by Claude Code

Correction to my own claim comment (5445446208), from the PM seat. I wrote there that runtime.test.ts:53's expect(kernel.use).toHaveBeenCalledTimes(1) "is the pin to rewrite" and called it a bare count. That characterisation was wrong, and anyone reading this card would have carried the error forward.

Verified on origin/main: line :55 already carried

expect(names).toEqual(['com.objectstack.service.authz-cluster-bridge']);

so the pin was never a bare count — the naming assertion was already there. I greped for toHaveBeenCalledTimes, got line 53, and generalised from that window without reading the two lines after it.

The dispatched seat's diagnosis is better than mine, and better than the ruling's phrasing. The defect was ordering, not absence: toHaveBeenCalledTimes(1) runs first and aborts the test, so the failure an engineer actually saw was expected 1, received 0 — a count mismatch — and the naming assertion never executed. The ruling's intent ("a refactor that silently drops the registration reds the pin by name") was exactly right; only its stated mechanism ("rather than a bare count") missed what was really wrong.

⇒ The work changed shape without changing intent: the first failing assertion now names the bridge and carries the contract in its message; the exact-set and count assertions are kept and moved after it; the sibling default-registration test got the same identity-before-cardinality ordering.

Proven rather than claimed, which is why I asked for the failure output rather than accepting the assertion's text: under ablation the suite reports Tests 2 failed | 4 passed (6) and both failures name the bridge —

`cluster: false` must STILL register the authz posture bridge (com.objectstack.service.authz-cluster-bridge)… If you removed that registration, restore it; the flag skips the CLUSTER plugins only.

— with no count-mismatch message anywhere in the output. That last point is the one the ruling actually asked to be established, and a claim about an assertion's wording could not have established it.

The census also answered the load-bearing question I front-loaded: 2 live sites encode the old meaning, both prose, zero in code and zero in other tests — and both fall inside site 2 as the ruling already defines it (the config docblock, which ships into the .d.ts, and the docs page). ⇒ option A's premise — that one readable declaration erases the harm — holds as measured, so nothing extra was absorbed into scope.

Generated by Claude Code

docs(runtime): declare that `cluster: false` still registers the auth…

Navigation Menu

Repository navigation

Should the authz posture statement live outside `service-cluster`? `Runtime` now registers `AuthzClusterBridgePlugin` under `cluster: false`, so that flag no longer means "this package contributes nothing" #12679

The one-line question

Why it was built that way (⛔ this is not a defect report)

四棱卡面块(决策待裁)

⚠️ Dedup channel DECLARED — this card may be a duplicate

Provenance

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Should the authz posture statement live outside service-cluster? Runtime now registers AuthzClusterBridgePlugin under cluster: false, so that flag no longer means "this package contributes nothing" #12679

Description

The one-line question

Why it was built that way (⛔ this is not a defect report)

四棱卡面块(决策待裁)

⚠️ Dedup channel DECLARED — this card may be a duplicate

Provenance

Activity

os-litant commented on Aug 27, 2026

os-zhuang commented on Aug 27, 2026

os-zhuang commented on Aug 27, 2026

claude commented on Aug 27, 2026

os-zhuang commented on Aug 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Should the authz posture statement live outside `service-cluster`? `Runtime` now registers `AuthzClusterBridgePlugin` under `cluster: false`, so that flag no longer means "this package contributes nothing" #12679