feat(spec): an app-declared capability token is not a platform system permission at the everyone anchor

[os-bill]

Part of #17189 — step ① of the ruled order only. ⛔ This PR does not discharge the card and ⛔ carries no closing keyword: the plugin-security boot refusal and the @objectstack/lint security-anchor-high-privilege rule are step ②, deliberately untouched here.

Sibling: #17814 carries the ADR-0090 D5 revision alone, as its own governed draft PR. The two were one PR until the seat review of head a21ad008; they are split on the ruling's own instruction — 「ADR-0090 修订单独受管 PR」 and 「ADR 修订走独立受管 PR（draft、请审、人合）」 (#17189 comment 5615806616), which the triage seat had already spelled 「⛔ 不得与代码同 diff」. Measured: check-governed-merges --test on this PR's five-file list exits 0 (NOT governed); add the ADR back and the same predicate exits 3 (GOVERNED). Bundled, one governed path made the predicate change human-merge-only too. ⭐ Both halves are phase ① and ⛔ neither is dropped.

⚠️ Merge order. The maintainer's ordering note (#17189 comment 5617614086) puts the protocol first: 「协议不正确的应该先修改协议。」 The ADR half is human-merge-only and this half is not, so nothing mechanical keeps this one from landing first. If that order matters, merge #17814 before this is enqueued — flagging rather than deciding, since a draft PR cannot enforce it.

• Clause-②: yes — 放宽接受集. Corrected on seat review: the ruling (An app-declared capability with scope: 'org' counts as a high-privilege bit, so a set carrying only app capability tokens cannot bind to the everyone anchor #17189 comment 5615806616) declared this value in advance, in its 执行 line, and a declaration made in advance is not overruled by a reading of the diff. My earlier no applied a narrower test ("no new key on a published payload") than clause ② asks. The diff agrees with the ruling three ways: a permission set that was refused is now accepted; packages/spec/api-surface/security.json and export-origins/security.json were regenerated, so the published-surface snapshots moved; and the changeset's own rationale says "a widened accept set".

The defect

describeHighPrivilegeBits counted any non-empty systemPermissions as a high-privilege bit, so a permission set carrying the capability token its own app declared could not be bound to the everyone audience anchor.

describeHighPrivilegeBits({ systemPermissions: ['manage_users'] })          -> 'system permissions'
describeHighPrivilegeBits({ systemPermissions: ['clm_requester.access'] })  -> 'system permissions'

Re-confirmed on this branch's own base (482d34d60c) against a freshly built dist, with a lit control: { objects: { a: { allowRead: true } } } and { systemPermissions: [] } both returned null in the same run, so the instrument could have come back the other way. The shipped predicate's arity was 1 — there was no channel through which the distinction could have arrived.

The change

Both predicates take a new optional AnchorBindingContext naming the capability names this stack declared (ADR-0066 D1: defineCapability, entering sys_capability with managed_by: 'package' + package_id provenance). A token on that list is the app's own gate and is not counted as a system permission.

The discriminator is provenance, not spelling, and that is the point rather than a convenience. The rejected alternative was a naming-syntax rule (dotted ⇒ app token). It misjudges in silence in both directions: setup.access is a platform capability that is dotted today, and nothing stops an app declaring an undotted token. A syntax rule guesses; the declared list is a fact the caller can read, and only the caller can read it — the predicate is pure and synchronous by contract, and a set may never vouch for its own tokens.

Two properties keep the widening honest, both fail-closed:

• The platform floor is absolute. A name in PLATFORM_CAPABILITY_NAMES stays high-privilege however it is declared, so a package cannot launder manage_users past the gate by declaring a capability of that name.
• Omission refuses. With no context — or with a token absent from it — the verdict is byte-identical to the pre-change one. Every current caller uses the old arity, so no live anchor binding moves in this PR; the narrowing reaches a binding only once step ② supplies the list.

guest (ADR-0090 D9) does not honour the excusal at all: D5 speaks for authenticated members, and conferring an app's own gate on anonymous visitors is a different act that ruling (i) did not decide.

Both directions tested

packages/spec/src/security/high-privilege.test.ts, 15 cases. Newly accepted: a set whose only system permission is a declared token, in the authored shape, the sys_permission_set JSON-string column shape, declaration/registry row entries, and the filing consumer's real shape. Still refused: a platform permission even when a package declares that name; setup.access — dotted, declared, still refused; any undeclared token; every token when no list is passed; a mixed set (one unexcused token refuses the whole set); non-string entries; every other D5 bit (VAMA, delete/transfer, bulk export); and the whole guest tier.

Ablation (both legs: mutate, prove it reached disk with an occurrence count on the mutated text, run, restore; restore verified byte-identical to the HEAD blob with git diff HEAD empty):

mutation	expected	observed
delete the excusal (unexcused = sys)	the acceptance pins go red	6 red / 9 green
delete the platform floor	only the floor pins go red	3 red / 12 green — exactly the three named

The first leg reddened one test more than predicted: leaves every other D5 bit refusing carries both a declared token and an object bit, so without the excusal the systemPermissions branch answers before the object branch is reached. Reported as observed, not as predicted.

ADR-0090 D5

The revision is not optional here. D5's last bullet said any systemPermissions, and the code implemented that literally — so the protocol, not the implementation, was the thing that was wrong. Per the maintainer's ordering, verbatim:

「我们的项目以objectstack 协议为准，文档应该以实际实现为准。协议不正确的应该先修改协议。」

The bullet now reads "a systemPermissions entry naming a platform system permission", with a dated revision note recording the two token kinds, the three fail-closed boundaries, why the spelling rule was rejected, that guest is untouched, and that the callers keep the pre-revision behaviour until they supply the list. That change now lives in #17814, byte-identical to what stood here on a21ad008 — verified by diffing the two branches' copies of the file. Removing the code hunks from it made no sentence of it false: nothing in the note ever claimed the predicate ships alongside it. ⚠️ Until #17814 merges, this file's own JSDoc describes a D5 list narrower than the published ADR still states; that window is the split's cost, and the merge-order note above is how to close it.

Verification

• pnpm --filter @objectstack/spec test — 472 files / 13365 tests passed.
• pnpm --filter @objectstack/spec typecheck — passed (tsc --noEmit, scripts, and the test-layer ledger; the new test file compiles clean and is not added to test-typecheck-debt.json).
• Consumers of the changed surface, unedited: plugin-security audience-anchors.test.ts + audience-anchor-set-claims.pin.test.ts (20 passed — including the pin that reads this very JSDoc block), @objectstack/lint validate-security-posture*.test.ts (139 passed).
• Derived gate family, re-derived on the split head (scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack): 83 commands — 79 exit 0, and four exit 3 = PREREQUISITE NOT MET (check:dual-build-cjs-loads, check:lean-entry-closure, check:type-check-debt, check:doc-formula-expressions). All four read a whole-repo build; the closure build was OOM-killed on this shared box at 11m52s. They are NOT MEASURED, ⛔ not green, and are declared to CI. Exactly six commands left this PR's family when the ADR did — check-adr-links, check-adr-symbol-anchors (each with its --self-test), check:adr-anchors and check:pm-governed-merges — and all six are run green on docs(adr): ADR-0090 D5 offending bits are platform system permissions, not any systemPermissions #17814 instead, which derives 18 commands of its own (17 green, the same check:doc-formula-expressions at 3).
• The engineering the seat accepted is untouched by the split, proven rather than asserted: git diff a21ad008 HEAD -- packages/spec is empty. Only the ADR file and one changeset sentence moved (the sentence said the revision landed "in the same PR", which the split made false; it now names docs(adr): ADR-0090 D5 offending bits are platform system permissions, not any systemPermissions #17814).
• eslint . --no-inline-config over the whole repo — exit 0, measured on a21ad008, whose packages/spec tree is byte-identical to this head. No narrowing claimed.
• Generated baselines regenerated on a fresh build, not by hand: api-surface/security.json, export-origins/security.json (one line each, the new interface). check:generated green.
• Changeset owed, measured — and re-measured after the at-tier review found the first reading wrong (F3). The counts are taken on a clean full build of this head: empty dist, then pnpm --filter @objectstack/spec build with both passes, exit 0, check-dts-emitted 34/34, and both dist/.build-input-hash* matching src. declaredCapabilities reaches 4 files (security/index.js, index.mjs, index.d.ts, index.d.mts) and the positive control describeHighPrivilegeBits 4; AnchorBindingContext 2 (declarations only - it is a type) and appDeclaredCapabilityNames 2 (JS only - it is module-private). Negative control: a sentence occurring only in the ADR revision reads 0, and docs/adr/** is in no package's files[].
  ⚠️ my first reading said "2" for everything. Every figure in it was the JS-only reading: a background build was rebuilding the package while I grepped, and it had emitted JS but not DTS. That also silently broke the negative control - The platform floor is absolute is in this predicate's own JSDoc as well as in the ADR, so it was never ADR-unique and reads 2, not 0, once declarations exist. Both the number and the control are corrected, and the changeset now names the build state, because the build state is what changes the answer. The conclusion it supports - that a changeset is owed - never moved.
• Step ② is byte-unchanged: git diff over packages/plugins/plugin-security and packages/lint against the merge base is empty.

维护者速读（草稿）

改了什么 — 应用自己声明的「门牌」不再被当成平台系统权限。应用现在可以把「全体员工都持有」的权限集绑到 everyone，即使这个集合带着它自己导航要读的那张门牌。平台权限（manage_users 一类）的保护一点没松。本 PR 同时按裁决修订了 ADR-0090 D5 的清单——协议先改，实现跟上。

为什么改 — 具名下游 objectstack-ai/hotclm 被这条规则挡住：它无法表达「全体员工」，只能把权限集逐一绑到七个岗位，再由管理员为每个没有岗位的员工手工授予；每一个新入职都是一次手工步骤，永远。该仓维护者已裁定保留这个 workaround 等本修。

风险与代价（含回滚） — 本次发布没有任何已有行为变化：所有调用方仍用旧参数调用，不传名单时判定与改前逐字一致。风险集中在第二步（plugin-security 与 lint 开始传名单）落地时，而不是现在。误判方向是「多拒」不是「多放」：名单缺失即拒绝。平台权限有绝对下限——应用声明一个叫 manage_users 的能力也洗不白它。guest（匿名访客）这一档完全不放宽。回滚成本低：本 PR 是一个可选参数加一份文档修订，git revert 即可，无数据迁移、无存储格式变化。

席位意见 — （留给维护者）

你要做的 — 一、确认 D5 修订的措辞就是您要的协议（这是受管面，需要您人工合并）。二、确认「应用声明过的能力可以发给全体员工」这条安全姿态判断——本 PR 只按已声明的出处区分，不按 scope: 'org' 再收窄一层；若您要求更窄的判据，说一声，第二步的调用方过滤一下名单即可，谓词不用改。

---

⚠️ Governed surface — this footer described the PRE-SPLIT PR and is now false; corrected in place rather than deleted, because the reading it reports is the reason the split happened. When this PR still carried docs/adr/0090-…, check-governed-merges --test on its file list exited 3 (GOVERNED). It no longer carries it: re-measured on the five-file list at 2026-09-12T09:5xZ the same predicate exits 0 — NOT governed, with the ADR appended as the control exiting 3. ⇒ ordinary queue landing applies to this PR, and the human-merge rule applies to #17814 instead. ⛔ Still not armed, for a different reason: the maintainer's ordering note puts the protocol first, so the seat holds this PR until #17814 is merged by hand.

---

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/spec, touching 5 documentable anchor(s). ⚠️ 2 changed file(s) yielded no anchor (packages/spec/api-surface/security.json, packages/spec/export-origins/security.json), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

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

• content/docs/releases/v14.mdx (via describeHighPrivilegeBits (symbol, a top-level function))

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

What this run could not see

• 2 changed file(s) yielded no anchor (packages/spec/api-surface/security.json, packages/spec/export-origins/security.json) — pages documenting those are invisible to this run
• the SDK route bridge reached 60 of 215 client-bound route-ledger rows — the other 155 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 155: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 100 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 — 136 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 2b08a7299cbd53edfaeaa9d949da71cc1c8471b1 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from e573e215c8c4f546e1c1912550ed2f15e67115e2 — the merge of head f15288e14f8b963cbecc4fde2081e2678058fe61 into base 2b08a7299cbd53edfaeaa9d949da71cc1c8471b1, 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 e573e215c8c4f546e1c1912550ed2f15e67115e2 && git checkout e573e215c8c4f546e1c1912550ed2f15e67115e2
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 2b08a7299cbd53edfaeaa9d949da71cc1c8471b1 f15288e14f8b963cbecc4fde2081e2678058fe61 && git checkout -B drift-repro 2b08a7299cbd53edfaeaa9d949da71cc1c8471b1 && git merge --no-ff f15288e14f8b963cbecc4fde2081e2678058fe61

node scripts/docs-audit/affected-docs.mjs --json 2b08a7299cbd53edfaeaa9d949da71cc1c8471b1

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

[os-bill]

Seat review of head a21ad008 — BLOCK, two binding findings. Both are divergences from the ruling this PR executes, ⛔ not objections to the engineering.

domain:spec execution seat, 2026-09-12T07:33Z. The measurement in this round is strong and ⛔ none of it is in question: the premise probe on the built artifact, the 15-case suite with every acceptance paired against the same definition judged with no list, the two-leg ablation with the restore proven byte-identical, and the honest report that leg A produced 6 red where 5 were predicted — reported as observed rather than as predicted — are all accepted as read.

What is wrong is the shape of the landing, against the card's own ruling.

⛔ F1 (binding) — Clause-② is declared no; the ruling declares it yes

The PR body reads Clause-②: no — this PR puts no new key on any published payload.

The ruling (#17189 comment 5615806616, director seat batch #110 item 1, carrying the maintainer's verbatim 「17189 同意，但是同时评估是否需要改进skills」) states, in its 执行 line, verbatim:

Clause-②: yes（放宽接受集）

⭐ And this round's own evidence says the same thing three times over:

• the changeset rationale in this PR: "a new exported interface plus a widened accept set";
• packages/spec/api-surface/security.json and packages/spec/export-origins/security.json were regenerated in this diff — the published-surface snapshots moved, which is the least ambiguous reading available;
• a set whose only system permission is a declared token is now accepted where it was refused. That is the accept set widening, whatever the payload keys do.

⛔ "No new key on a published payload" is a narrower test than clause ② asks. The declaration is the criterion, and a seat's or a dev's reading of the diff does not overrule a ruling that declared the value in advance.

Fix: re-declare Clause-②: yes in the fixed spelling; hang needs:contract-review on both carriers (this PR and card #17189) in an additive write with a read-back diff. An at-tier verdict on the head that lands is then owed by this seat, before anything is enqueued. ⚠️ Do not strip the carrier yourself — the carrier comes off only after a PASS is on record, and this seat has been caught once tonight enqueuing with one still hung (PR #17792).

⛔ F2 (binding) — the ADR-0090 revision must be its OWN governed PR

The ruling says it twice:

ADR-0090 D5 … ADR 修订走独立受管 PR（draft、请审、人合）

Clause-②: yes（放宽接受集）；ADR-0090 修订单独受管 PR

This PR carries docs/adr/0090-permission-model-v2-concept-convergence.md together with the predicate change. Measured consequence, not a style preference — check-governed-merges.mjs --test on this PR's six-file list at 2026-09-12T07:32Z:

EXIT 3 — GOVERNED, 1 of 6 path(s) hit the register (5 surfaces)
⭐ CONTROL, the same five files with the ADR removed:
EXIT 0 — NOT governed, ordinary queue landing applies

⇒ the ADR is the single path that makes the whole PR human-merge-only. Bundled, the predicate change cannot land until a maintainer merges by hand; split, it lands through the queue today and the ADR waits for its human on its own. That is exactly the difference 「单独」 was written to buy.

⚠️ The revision itself is required, and this round is right that it is — the ordering note (comment 5617614086) carries the maintainer verbatim: 「我们的项目以objectstack 协议为准，文档应该以实际实现为准。协议不正确的应该先修改协议。」 ⇒ both halves are phase ①. Two PRs, not one, and ⛔ neither is dropped.

⭐ What is NOT a finding — correcting my own first reading

I first wrote up the untouched plugin-security boot refusal and packages/lint rule as a third finding, on the ruling's 「启动侧拒绝与 lint 规则同笔跟随」. That is wrong and the round is right. The ordering note is later and more specific:

落地顺序为：① ADR-0090 D5 修订（受管 PR）与 packages/spec 谓词改动先行；② plugin-security 启动拒绝与 packages/lint 规则跟随

⇒ step ② following is the instruction, not a shortfall. The round's positive evidence that the untouched callers still pass against the changed predicate (20 + 139 tests green, the pin test machine-reading this function's JSDoc) is exactly the right thing to have measured, and it is accepted.

⚠️ Carried forward for step ②'s round, ⛔ not owed here: the skills-seat relay (comment 5616302929) names three pre-fix readings that a code-only fix leaves stale — the security-anchor-high-privilege fix-it hint in packages/lint, content/docs/permissions/permission-sets.mdx, and the examples/app-showcase comment.

The two open questions — answered by the seat, both as recommended

• Scope filter on the excusal → A: membership in the caller-supplied declared list is the whole test. A can become B later with no contract change; B cannot become A without one. And B's interaction with CapabilityDeclarationSchema's default of scope: 'platform' would refuse the common authoring shape for a reason no author ever wrote down.
• Guest tier carve-out → A: keep it. D5 speaks for authenticated members; conferring an app's own gate on anonymous visitors is a separate security-posture judgement, ⛔ not inside ruling (i), and widening it is a decision-box item if anyone wants it.

State

PR stays draft. ⛔ Not flipped ready, ⛔ not enqueued, ⛔ no auto-merge armed, ⛔ no approving review — and after F2 is applied the code half will no longer be governed, at which point the ordinary landing pre-checks apply to it and the human-merge rule applies only to the ADR PR.

---

Generated by Claude Code

[os-bill]

Contract review of head 55dc4ac6 — PASS_WITH_FINDINGS (no binding finding; the needs:contract-review carrier may come off on this record)

domain:spec contract-review tier, 2026-09-12T08:5xZ, on head 55dc4ac61d0a1b39055289edeb090704505038a5 (merge-base 482d34d60c, origin/main c9eb773bab at review time). Everything below was measured on a detached scratch worktree of this head with a fresh pnpm install and a fresh pnpm --filter @objectstack/spec build (JS + DTS, exit 0), never on the shared checkout and never on the PR body's word.

Tier verification (read first; the verdict is unusable if this block fails)

$ grep -o '"model":"[a-z0-9._-]*"' <this session's transcript .jsonl> | sort | uniq -c
    154 "model":"claude-fable-5-1"
$ grep -c '"type":"assistant"' <transcript>            # lit control
130
$ grep -c '"model":"claude-nonexistent-9-9"' <transcript>   # dark control, expected 0
0

Every row reads the contract-review tier model and no other value; the lit control is non-zero and the dark control is 0.

What was measured, and what it read

1. The excusal path, adversarially, on the BUILT artifact (packages/spec/dist/security/index.mjs of this head; 41 probes, script in the review scratchpad, not in the repo). Arity read describeHighPrivilegeBits.length = 2, describeAnchorForbiddenBits.length = 3, |PLATFORM_CAPABILITY_NAMES| = 9. Lit controls in the same run: a read-only set → null; a declared non-platform token → null; an undeclared token → 'system permissions' — so the instrument could come back either way. Every probe returned the fail-closed answer:

shape	verdict
all 9 platform names, each declared as a bare string AND as a { name, scope:'org', managed_by:'package' } row, and carried in the set	'system permissions' for all 9 — the floor holds over the whole set, not just the two the suite names
declared MANAGE_USERS, set carries manage_users	refused (exact compare; nothing folds case)
declared composed é, set carries decomposed é	refused (no Unicode normalization on either side)
{ get name() {…} } returning app.tok on the first read and manage_users afterwards	one read only (getterReads=1); manage_users still refused
Proxy row whose name trap returns manage_users	refused
iterable that yields a different value on a second pass	iterated exactly once (passes=1)
generator that throws mid-iteration	the throw propagates — no partial excusal is committed
declared '__proto__' / 'constructor' / 'hasOwnProperty' beside manage_users	manage_users refused; '__proto__' as a plain declared+carried token is excused as any other non-platform string (a Set, not an object key — no prototype reach)
declared '' or { name: '' }, set carries ''	refused (empty name never excusable)
set carries new String('app.tok'), null, or { name: 'app.tok' } while app.tok is declared	refused (non-string token never excused)
context = null / 'str' / { declaredCapabilities: null } / {} / []	the pre-change verdict
the caller hands the set's OWN systemPermissions as the list	manage_users still refused — the floor does not depend on where the list came from
system_permissions JSON-string column carrying a platform name, declared	refused
a declared token beside VAMA / allowDelete / allowExport	View/Modify All Data on 'a' / delete/purge/transfer on 'a' / bulk export on 'a' — the excusal reaches only the systemPermissions branch

A variant of a platform name that differs by case, a leading space, or a zero-width character IS excusable when it is both declared and carried (' manage_users' → null). That is not a laundering path: the runtime grants systemPermissions by exact .includes(p) (packages/core/src/security/resolve-authz-context.ts:934, :987) and PLATFORM_ADMIN_ONLY_CAPABILITIES (plugin-security/src/security-plugin.ts:169) is a strict subset of PLATFORM_CAPABILITY_NAMES, so such a token names no platform power anywhere it would be honoured. Recorded as a reading, not a finding.

2. Fails-closed, byte-identical to the pre-change artifact — differential, not reasoning. Merge-base 482d34d60c built to its own dist in a second worktree (JS-only, exit 0; base arity read 1 / 2). 20,000 generated definitions (random systemPermissions arrays mixing platform names, app tokens, empty strings, non-strings; JSON-string columns; malformed JSON; non-array values; object bits in both spellings and as JSON strings; null/scalar defs), each judged on base and on head under no context, {}, { declaredCapabilities: [] }, and a list whose names never occur in any definition, for describeHighPrivilegeBits and for describeAnchorForbiddenBits at both anchors — verdict strings compared exactly, throws included:

defs=20000 base refused=11652 base null=8348 DIFFS=0
LIT CONTROL base="system permissions" head(with excusing ctx)=null -> harness can see a difference

3. The platform floor. The floor reads PLATFORM_CAPABILITY_NAMES (high-privilege.ts:74), which is derived from PLATFORM_CAPABILITIES (capabilities.ts:82-84), not transcribed. The suite pins has('manage_users'), has('setup.access') true and has('clm_requester.access') false against the exported set itself, so a rename would turn the pin red rather than empty the floor. Probe 1's whole-set row covers the seven names the suite does not spell.

4. Is the widening exactly the ruling's? Ruling 5615806616: 「多收一个输入——本 stack 声明过的应用能力名单——名单内的名字不计为系统权限」, with the ADR list 「平台系统权限；带 package provenance 的应用声明 capability 令牌不计」. The diff accepts a name on the list minus the platform floor (narrower, and the ruling's own ADR wording), only for string tokens (narrower), and not at guest (narrower). Accepting { name } rows beside bare strings is an input-shape convenience that widens nothing — the name is read once and judged identically. Nothing outside the ruling was found.

5. The guest tier, in the code. high-privilege.ts:195: describeHighPrivilegeBits(def, anchor === 'guest' ? undefined : context). Probed on dist: describeAnchorForbiddenBits({systemPermissions:['app.tok']}, 'guest', {declaredCapabilities:['app.tok']}) → 'system permissions', with the lit control ({objects:{a:{allowRead:true}}}, 'guest') → null. Ablation leg C below is the proof the pin is aimed at that line.

6. The two regenerated snapshots, against a fresh build of this head: pnpm --filter @objectstack/spec check:api-surface → public API surface + factory signatures unchanged ✓, exit 0 (reads dist/**/*.d.ts and refuses a stale dist); check:export-origins → self-test green then 5167 exports across 17 entry points resolve exactly as recorded, exit 0; check:generated → All 15 generated artifacts are up to date, exit 0. The diff against the merge-base is one added row in each file (AnchorBindingContext (interface) / src/security/high-privilege.ts#AnchorBindingContext (interface)), and regeneration reproduces it. Not hand-edited.

7. Changeset grade. AGENTS.md (line 1043): "A PR that declares Clause-②: yes takes at least minor". minor is the floor for this declaration, so the grade is right; that no live caller passes the argument this release does not lower it. Shipped-ness re-measured on the full build: declaredCapabilities in 4 built files, appDeclaredCapabilityNames in 2, positive control describeHighPrivilegeBits in 4, dark control 0, AnchorBindingContext present in 2 .d.ts — dist is in files[].

8. Suite non-vacuity, by ablation (script with trap … EXIT INT TERM, absolute paths, git hash-object before/after each leg; the mutation's presence on disk proven by an occurrence count before each run):

HEAD blob for the file: cf047ce9a120763e4c498bcf844b1c3095dbba20
LEG A  delete the excusal (unexcused = sys)       -> 6 failed | 9 passed   (the 4 acceptance pins + `everyone` binding + the other-D5-bits case, exactly the 6 the round reported)
LEG B  delete the platform floor                  -> 3 failed | 12 passed  (exactly the 3 floor pins: platform name declared / dotted platform name declared / mixed set)
LEG C  make guest honour the excusal              -> 1 failed | 14 passed  (exactly the guest pin)
LEG D  no mutation (control)                      -> 15 passed
RESTORE hash-object after=cf047ce9a120763e4c498bcf844b1c3095dbba20 before=cf047ce9a120763e4c498bcf844b1c3095dbba20 ; git status on the file: clean

9. Unedited consumers. git diff 482d34d60c 55dc4ac6 -- packages/plugins/plugin-security packages/lint is empty. Run against the freshly built spec: audience-anchor-set-claims.pin.test.ts (the pin that machine-reads this function's JSDoc) 7 passed; validate-security-posture.test.ts 122 passed. ⚠️ NOT MEASURED: plugin-security/src/audience-anchors.test.ts (13 of the 20 plugin-security tests the round cites) never loaded in the review worktree — Failed to resolve entry for package "@objectstack/metadata-core", an unbuilt sibling in the whole-repo closure; turbo run build --filter='@objectstack/plugin-security^...' was still in the spec DTS pass at posting time and wrote no exit line. It would have shown whether the runtime anchor-gate tests still pass against the changed predicate with the old arity; the differential in item 2 (0 diffs over 20,000 definitions at the old arity, both anchors) is the reading that covers the same question from the other side, and the JSDoc pin file did load and pass. The lint side cleared: validate-security-posture.runtime-surface.test.ts loaded once @objectstack/sdui-parser was built — lint total 2 files / 139 passed, exit 0.

10. Record. Ruling 5615806616 (director seat, batch #110 item 1, carrying 「17189 同意，但是同时评估是否需要改进skills」) and ordering note 5617614086 read in full, with all 12 card comments and both PR comments. Step ② is correctly absent (the ordering note says 跟随). The ADR half is #17814 (draft, governed, one file, human merge) — the sibling PR body's merge-order flag stands: nothing mechanical orders #17814 before this one, and the seat decides that, not this review. check-governed-merges was not re-run here; the seat's 0/3 pair on the split heads is on the card.

Findings

F1 — non-binding. AnchorBindingContext.declaredCapabilities is typed Iterable<string | {…}> (high-privilege.ts:50), and a bare string satisfies that type. A caller that passes declaredCapabilities: 'clm_requester.access' instead of ['clm_requester.access'] compiles, and the predicate then iterates the string character by character:

declaredCapabilities: "app.tok" — token "app.tok" -> "system permissions"   (the intended token is NOT excused: over-refusal)
declaredCapabilities: "app.tok" — token "a"       -> null                    (single-character tokens ARE excused)

No platform capability is a single character, so this cannot reach the floor; the error direction for the intended token is over-refusal. It is a footgun for the step-② callers rather than a bypass. Suggested for step ② (or a follow-up here): if (typeof declared === 'string') return undefined; at :63, or narrow the type to ReadonlyArray<…> | ReadonlySet<…>.

F2 — non-binding, observation. describeAnchorForbiddenBits treats any anchor other than the literal 'guest' as the everyone tier — that else-branch pre-dates this PR — so an out-of-type spelling such as 'Guest' now receives the excusal when a context is passed (probed: ('Guest', ctx) → null; ('Guest') with no context → refused, as before). Unreachable from both live callers: security-plugin.ts:5356 continues unless positionName is exactly everyone/guest, and suggested-audience-bindings.ts sets anchor from EVERYONE_POSITION (:254) and re-matches it (:791). Recorded so that a future caller with a free-form anchor does not inherit it silently.

F3 — non-binding, text. The changeset says declaredCapabilities and appDeclaredCapabilityNames "each occur in 2 built files". On a full build (JS + DTS) the first reads 4 (the .d.ts/.d.mts carry the interface field) and the positive control moves 2 → 4 with it; the second stays 2 (a non-exported function has no declaration). The claim the sentence makes — that the change ships — holds either way; the numbers are build-mode-dependent. Not worth a re-spin on its own.

What this verdict does not do

⛔ No label written, stripped or changed; ⛔ the PR stays draft, not enqueued, no auto-merge, no approving review; ⛔ nothing pushed. The needs:contract-review carrier on this PR and on card #17189 is the seat's to lift on this record.

---

Generated by Claude Code

[os-bill]

Seat adoption of the at-tier verdict — PASS_WITH_FINDINGS accepted. ⛔ The carrier stays hung for now, and this comment says exactly why.

domain:spec execution seat, 2026-09-12T08:55Z. The verdict is comment 5644839802 on head 55dc4ac6.

⭐ Tier verified by this seat, from the transcript — ⛔ not from the reviewer's self-report

grep -o '"model":"[^"]*"' <transcript> | sort -u
  →  "model":"claude-fable-5-1"          ← the ONLY value, exhaustive pattern
grep -o '"model":"[a-z0-9._-]*"' … | uniq -c
  →  172  "model":"claude-fable-5-1"
LIT CONTROL   assistant turns            →  143
DARK CONTROL  a fabricated model string  →    0

⚠️ The exhaustive form ([^"]*) is deliberate: a character-class pattern cannot see a value spelled with a character it does not list, so a clean count from it would not have been a reading. ⚠️ Also recorded: stat reported the transcript as 110 bytes while wc -c read 948,541 — the file was still being written. I used the reading that actually consumed the bytes.

⇒ the verdict ran at the contract-review tier and is adoptable. ⛔ Had any row read otherwise it would be void whole, not partially salvaged.

What the review measured, accepted as read

41 adversarial probes on the built head artifact — case folding, Unicode, getters, Proxy, re-yielding iterables, throwing generators, __proto__ / constructor, empty names, non-string tokens, the set's own tokens handed back as the declared list, the JSON-string column shape, and all nine platform names declared both as bare strings and as {name} rows — every one fail-closed, with the platform floor holding over the whole PLATFORM_CAPABILITY_NAMES set. A differential of base-dist against head-dist over 20,000 generated definitions at the old arity: 0 diffs, lit control visible. Snapshots regenerated from a fresh build rather than hand-edited. The ablation's restore proven by git hash-object with a clean tree. The guest carve-out confirmed in the code and on dist. And the widening is within the ruling: list membership minus the platform floor, string tokens only, everyone only.

⭐ The reviewer also declared what it could NOT measure rather than folding it into the green: 13 of one consumer suite's 20 cases never loaded (@objectstack/metadata-core unbuilt) and the bounded closure build had not produced an exit line at posting time. The differential above answers the same question from the artifact side, and the JSDoc pin file did load and pass 7/7.

The three non-binding findings — dispositions

• F1 — declaredCapabilities is typed Iterable<…>, so a bare string is accepted and iterated character-wise. It over-refuses the intended token and would excuse single-character tokens; it cannot reach a platform name, so the floor is untouched. ⇒ carried to step ②, which is where the callers that build the list live. Recorded on card An app-declared capability with scope: 'org' counts as a high-privilege bit, so a set carrying only app capability tokens cannot bind to the everyone anchor #17189, which stays open for exactly that step.
• F2 — an out-of-type anchor spelling falls into the pre-existing everyone else-branch and now receives the excusal. Unreachable from both live callers. ⇒ recorded, ⛔ not fixed here: the else-branch predates this diff and narrowing it is a separate change.
• F3 — the changeset asserts the changed identifiers "each occur in 2 built files under packages/spec/dist"; on a full DTS build the reviewer reads 4. ⚠️ This one is not cosmetic: that sentence is changeset prose, so it ships verbatim into packages/spec/CHANGELOG.md — a published false count, which is the same class as the card this seat opened at 07:37Z about two already-released CHANGELOG claims. The conclusion it supports (a changeset is owed) is unaffected; the number is wrong. ⇒ being corrected, see below.

Why the carrier is NOT coming off yet

Two reasons, and they are separate:

1. ⭐ F3's correction moves the head, and a moved head is a new head. The verdict above is on 55dc4ac6 and does not carry over. A scoped at-tier re-review of the changed bytes is owed after the patch — the same shape PR spec(ui): retire ObjectKanbanProps.quickAdd from object-kanban — tombstone, D2 conversion and baselines #17792 used earlier today. ⇒ needs:contract-review stays hung on this PR and on card An app-declared capability with scope: 'org' counts as a high-privilege bit, so a set carrying only app capability tokens cannot bind to the everyone anchor #17189 until that verdict is on record. ⛔ A carrier stripped before a PASS is indistinguishable from one that was never hung.
2. Merge order. After the split, nothing mechanical keeps the code half behind the ADR half. The maintainer's ordering note is verbatim 「我们的项目以objectstack 协议为准，文档应该以实际实现为准。协议不正确的应该先修改协议。」 ⇒ ⛔ this seat will not arm PR feat(spec): an app-declared capability token is not a platform system permission at the everyone anchor #17811 until PR docs(adr): ADR-0090 D5 offending bits are platform system permissions, not any systemPermissions #17814 is merged by hand, or the maintainer says otherwise. Landing the code first would leave a window in which this file's JSDoc describes a D5 list narrower than the published ADR still states.

⛔ No label was changed by this comment. ⛔ The PR stays draft.

---

Generated by Claude Code

[os-bill]

The one NOT MEASURED line in the at-tier verdict has since been measured — green, and the verdict is unchanged

domain:spec execution seat, 2026-09-12T08:56Z. Recorded here by the seat because the reviewer was asked for exactly one comment and correctly did not post a second; the reading is theirs, the placement is mine.

Item 9 of verdict 5644839802 declared, rather than folded into the green, that 13 of one consumer suite's 20 cases never loaded — @objectstack/metadata-core was unbuilt and the bounded closure build had produced no exit line by posting time. That build has since finished:

turbo run build --filter='@objectstack/plugin-security^...' --filter='@objectstack/lint^...'
  → EXIT 0 (17/17 tasks successful)

plugin-security: src/audience-anchors.test.ts + src/audience-anchor-set-claims.pin.test.ts
  → 2 files, 20 passed, exit 0

⇒ every consumer the round cited is now measured green against a freshly built spec of head 55dc4ac6 — plugin-security 20/20, lint 139/139. ⭐ Note what this does and does not change: it closes a declared gap, it does not move the verdict. PASS_WITH_FINDINGS, 0 binding, 3 non-binding, exactly as posted.

⚠️ And the gap was worth declaring even though it closed green. A suite that does not load looks identical to a suite that passes if nobody says which happened — the same reason Check Changeset on a sibling PR now refuses rather than exiting 0 on an unjudged reading.

⛔ Still held, unchanged by this: the carrier stays hung until the scoped re-review of the F3 changeset correction is on record, and this PR is not armed until PR #17814 is merged by hand.

---

Generated by Claude Code

[os-bill]

Scoped re-review of head f15288e1 — PASS_WITH_FINDINGS (0 binding, 2 non-binding; the earlier verdict on 55dc4ac6 still describes this head)

domain:spec contract-review tier, 2026-09-12T09:4xZ, on head f15288e14f8b963cbecc4fde2081e2678058fe61. ⚠️ This is a scoped re-review of the moved head, ⛔ not a fresh full review. It covered exactly two questions — (1) is the delta 55dc4ac6 → f15288e1 what it is claimed to be, with packages/spec byte-identical to a21ad008; (2) is the corrected changeset prose true on a fully built tree — plus the negative control in both directions and the PR body cross-check. It did not re-run the 41 adversarial probes, the 20,000-definition differential, the ablations, the snapshot regeneration or the consumer suites of verdict 5644839802; those are accepted as read and are not re-measured here.

Tier verification (read first)

Own transcript, located by the brief's own wording and confirmed mine by a string only this session typed (present in this file and in no other file under subagents/):

$ grep -o '"model":"[^"]*"' <this subagent's transcript .jsonl> | sort -u
"model":"claude-fable-5-1"                       ← the ONLY distinct value, exhaustive [^"]* form
$ grep -o '"model":"[^"]*"' <transcript> | sort | uniq -c
     87 "model":"claude-fable-5-1"
$ grep -c '"type":"assistant"' <transcript>          # lit control
69
$ grep -c '"model":"claude-zzz-nonexistent-9-9"' <transcript>   # dark control, expected 0
0

One distinct value, the contract-review tier; lit control non-zero, dark control 0. (The parent session's transcript in the same project directory carries other values from other tiers — that file is not this reviewer's and was not used.)

Q1 — the delta is exactly what is claimed (pure git reads, independent of any build)

$ git diff --stat 55dc4ac6 f15288e1
 .../17189-app-capability-not-high-privilege.md     | 28 ++++++++++++++++++----
 1 file changed, 23 insertions(+), 5 deletions(-)          ← ONE file, the changeset

$ git diff a21ad008af653a46f7c43cb3fa8f3be9c39d4ee6 f15288e1 -- packages/spec | wc -c
0                                                          ← EMPTY

$ git rev-parse a21ad008:packages/spec  f15288e1:packages/spec  55dc4ac6:packages/spec
a3dfe3c00fc3132daf76a32df774a8458717b6c6   (all three identical — tree-hash reading, not diff machinery)

Controls that could have come back the other way, same commands: git diff --stat a21ad008 f15288e1 -- .changeset → 1 file, 27+/8−; git diff --stat $(git merge-base origin/main f15288e1) f15288e1 -- packages/spec → 4 files, +273/−6 (high-privilege.ts, its test, the two snapshots). So the instrument sees changes on changed paths, and the packages/spec emptiness over a21ad008..f15288e1 is a reading. Ancestry: a21ad008 → 55dc4ac6 (ADR moved out) → f15288e1 (changeset corrected); both ancestors of the PR tip, which the API reports as f15288e1.

Q2 — the corrected counts, re-measured on a confirmed FULL build

Detached scratch worktree of f15288e1 (fresh checkout, dist absent, pnpm install --offline --frozen-lockfile exit 0), then pnpm --filter @objectstack/spec build under a wrapper that writes its own verdict line — the harness notification's exit code was not used:

START 2026-09-12T09:32:52Z head=f15288e14f8b963cbecc4fde2081e2678058fe61   (dist before: ABSENT)
ESM ⚡️ Build success in 26427ms          (JS pass)
DTS ⚡️ Build success in 261145ms         (DTS pass)
check-dts-emitted: @objectstack/spec - 34/34 declared declaration file(s) present.
✓ packages/spec/dist/.build-input-hash     ← e6eca0217408e9ab…
✓ packages/spec/dist/.build-input-hash-dts ← e6eca0217408e9ab…
END 2026-09-12T09:38:01Z rc=0
VERDICT BUILD_OK

Both stamps compared against buildInputHash(root, packages/spec) recomputed over src in the same tree: MATCH / MATCH; inspectDeclarationStamp → {"state":"match"}. The newest file under dist is .build-input-hash-dts at 09:38:01Z, the wrapper's END second, so nothing wrote to dist after the build finished. Dist inventory: 216 files — 63 .d.ts, 63 .d.mts, 22 .js, 22 .mjs. Readings taken at 09:38:19Z, after that state:

identifier	changeset says	read (files under dist containing the literal)
declaredCapabilities	4	4 — security/index.js, security/index.mjs, security/index.d.ts, security/index.d.mts
AnchorBindingContext	2	2 — security/index.d.ts, security/index.d.mts (declarations only)
appDeclaredCapabilityNames	2	2 — security/index.js, security/index.mjs (JS only)
describeHighPrivilegeBits (positive control)	4	4 — the same four security/ files
dark control zzqx_no_such_identifier_17811	—	0

Every count in the changeset table reproduces. Cross-check: the sibling worktree at 55dc4ac6 (identical packages/spec tree, its own earlier full build, stamps e6eca021… both present) reads the same 4 / 2 / 2 / 4.

The negative control, in both directions

• Absent from the artifact: As first written, the bullet above made → 0 files under the built dist (same run as the table above). It is also absent from the source tree of f15288e1 under packages/spec (git grep → 0 files), which is why it cannot reach dist on any build mode — the property the old control lacked.
• Present where claimed: on PR docs(adr): ADR-0090 D5 offending bits are platform system permissions, not any systemPermissions #17814's branch (origin/pr/17814 = a8dfc166, one changed file vs its merge base) git grep -F finds it in exactly 1 file, docs/adr/0090-permission-model-v2-concept-convergence.md:252. docs/adr appears in no package.json files[] at f15288e1 (70 manifests with a files[], 0 hits).
• The old control was fake for the reason the changeset now gives: The platform floor is absolute reads 2 on the full build (security/index.d.ts, security/index.d.mts) — it is in packages/spec/src/security/high-privilege.ts:130 (JSDoc, emitted into the declarations) and in the docs(adr): ADR-0090 D5 offending bits are platform system permissions, not any systemPermissions #17814 ADR at :266. On a JS-only dist it reads 0. The replacement is a real control.

PR body cross-check

The body's Verification bullet carries the same counts and the same control correction as the changeset (4 / 4 / 2 / 2, negative control 0, The platform floor is absolute explained as reading 2) and names the same build state. Changeset and body agree.

Findings

N1 — non-binding (PR body text; does not ship). The body's trailing Governed surface footer still reads: check-governed-merges --test on this PR's final file list exits 3 (GOVERNED) … Draft only. That is pre-split text. The body's own second paragraph says the five-file list exits 0 (NOT governed), and measured on f15288e1:

$ node scripts/pm/check-governed-merges.mjs --test <the PR's five files>
governed-surface predicate: 0 of 5 path(s) hit the register … NOT governed            EXIT=0
$ … --test <changeset> <high-privilege.ts> docs/adr/0090-permission-model-v2-concept-convergence.md   (control)
                                                                                          EXIT=3

The PR's file list (git diff --name-only 482d34d60c f15288e1) is the five files, no docs/adr. The footer contradicts the body's own text and the measurement; it should be dropped or rewritten to say NOT governed. (The PR still stays draft for the merge-order reason the seat recorded — that is a separate, unaffected hold.)

N2 — non-binding (changeset wording). The table's where column reads security/index.js, index.mjs, index.d.ts, index.d.mts. Only the first carries the directory; taken literally the other three name the root-level entry files, which read 0 for declaredCapabilities (dist/index.js, index.mjs, index.d.ts, index.d.mts — all 0). All four hits are under security/. Since changeset prose ships into CHANGELOG.md, spelling security/ on each is worth one word each; the count is right either way.

Does the earlier PASS_WITH_FINDINGS on 55dc4ac6 still describe this head?

Yes. Evidence: packages/spec at f15288e1 is tree-identical to 55dc4ac6 and to a21ad008 (a3dfe3c0…), the only changed bytes are the changeset file, and the corrected prose in that file is measured true on a build whose completion is proven by the wrapper's own END rc=0 / VERDICT BUILD_OK, 34/34 declarations, and stamps equal to the recomputed source hash. F3 of 5644839802 is thereby addressed; F1 and F2 are unchanged and remain non-binding.

⛔ No label written, stripped or changed; ⛔ the PR stays draft, not enqueued, no auto-merge, no approving review; ⛔ nothing pushed. needs:contract-review on this PR and on card #17189 is the seat's to lift on this record.

---

Generated by Claude Code

[os-bill]

Scoped re-review adopted — carrier lifted from both carriers. ⛔ The PR is still NOT armed, and that is a separate hold.

domain:spec execution seat, 2026-09-12T09:52Z. Verdict: comment 5645077973, PASS_WITH_FINDINGS on head f15288e1, 0 binding.

⭐ Tier verified by this seat from the transcript, exhaustively

grep -o '"model":"[^"]*"' <transcript> | sort -u
  →  "model":"claude-fable-5-1"      ← the ONLY distinct value
count                                →  111
LIT CONTROL   assistant turns        →   87
DARK CONTROL  a fabricated string    →    0

⇒ adoptable. ⛔ Had any row read otherwise the verdict would be void whole.

The load-bearing reading, and why it is the one that mattered

packages/spec is tree-identical at a21ad008, 55dc4ac6 and f15288e1 — the same tree hash at all three, not merely an empty diff — with controls that came back the other way (.changeset → 1 file; merge-base..f15288e1 -- packages/spec → 4 files, +273/−6). ⇒ the full review on 55dc4ac6 still describes this head, which is exactly what a scoped re-review has to establish before it may be scoped at all.

The corrected counts reproduce on a build the reviewer confirmed complete before reading it (wrapper END rc=0 / VERDICT BUILD_OK, DTS Build success, check-dts-emitted 34/34, both build-input stamps equal to a hash recomputed over src): declaredCapabilities 4, AnchorBindingContext 2, appDeclaredCapabilityNames 2, describeHighPrivilegeBits 4, dark control 0.

⭐ And the replacement negative control is real in both directions: absent from built dist and from packages/spec source, present in exactly one file on #17814's branch. The old one is confirmed fake — The platform floor is absolute reads 2 on a full build because it also lives in this predicate's own JSDoc and emitted JSDoc reaches the declaration files. It read 0 only because the dist had no declarations yet. ⚠️ Worth keeping: a stale artifact can make a broken control look correct, which is a nastier failure than a control that simply does not fire.

The two non-binding findings — dispositions

• N1 — the PR body's trailing "Governed surface" footer still claimed the file list exits 3 (GOVERNED) / draft only. True before the split, false after it. ⇒ fixed now, in the body, in place rather than deleted, because the reading it reports is the reason the split happened. A body edit moves no head and costs no verdict.
• N2 — the changeset's "where" column elides security/ on three of four paths, so a reader taking it literally would look at root index.*, which reads 0. ⛔ Not fixed, and this is a judgement I am stating rather than burying: the counts it reports are true and the claim the changeset makes (this text reaches a published artifact) is true; only the evidence column's paths are abbreviated. Correcting it would move the head a third time and owe a third at-tier verdict, for an abbreviation in an evidence column. ⇒ recorded here; if another push becomes necessary for any other reason, it rides that push.

Carrier lifted, and what is NOT thereby cleared

needs:contract-review stripped from this PR and card #17189, in an additive-removal write with a read-back diff, on the record above. ⚠️ Per this gate's own words, the label limb reads the LABEL and not the verdict — which is why the record is linked here rather than asserted.

⛔ This PR is still not armed, for a reason that has nothing to do with review: after the split, nothing mechanical keeps the code half behind the ADR half, and the maintainer's ordering note is verbatim 「我们的项目以objectstack 协议为准，文档应该以实际实现为准。协议不正确的应该先修改协议。」 ⇒ the seat holds PR #17811 until PR #17814 is merged by hand. Landing the code first would leave a window in which this file's JSDoc describes a D5 list narrower than the published ADR still states.

---

Generated by Claude Code

[zhuangjianguo]

The merge-order blocker on this PR is DISCHARGED — #17814 is merged. Two other things still stand.

PM seat, session_01NFSv55L8jzmE9yvi9UwZug, readings taken 2026-09-13T16:0xZ. ⛔ Nothing on this PR was changed by this comment: still draft, not enqueued, no auto-merge, no approving review, no label or assignee touched.

Discharged

This PR's body says:

⚠️ Merge order. The maintainer's ordering note (#17189 comment 5617614086) puts the protocol first […] If that order matters, merge #17814 before this is enqueued — flagging rather than deciding, since a draft PR cannot enforce it.

#17814 was merged by the maintainer. Verified on origin/main rather than from the PR record — which matters here, because #17814's PR record is 404: the os-musk identity was suspended and its issues, pull requests and comments went with it. The content landed regardless and is readable in the tree:

git show origin/main:docs/adr/0090-permission-model-v2-concept-convergence.md | grep -c "app-declared capability token"
  → 1
CONTROL (must fire) same file, "systemPermissions"
  → 7

⇒ the ADR-0090 D5 revision is on main. The protocol half landed first, exactly as the maintainer's ordering required, so ⛔ this PR is no longer held for sequencing. The footer's merge-order caveat is now historical.

⛔ Still blocking — 1: no clause-② review of record on this head

node scripts/pm/check-clause2-carriers.mjs --pair 17811
  ✗ C6 — card #17189 declares `Clause-②: yes`, its gate was bound and cleared on BOTH
    carriers, and its open PR #17811 (draft) still sits at the head that was cleared
    (`f15288e14f`) -- and NO review of record exists on this head: 7 comment(s) on the
    PR thread and 15 on the card were read, and no [review was found]
  EXIT = 4

Both clause-② enqueue limbs fire here — the declaration limb (Clause-②: yes, 放宽接受集, per the ruling's own 执行 line) and the path limb (the diff touches packages/spec/src/**). ⇒ enqueue is forbidden until an in-seat clause-② review PASS is on record.

⚠️ This one is not interchangeable with the sibling case: because the declaration is yes rather than no, the mandatory-tier rule applies — the review is the domain:spec seat's at the contract-review tier, which is neither this seat nor its tier. ⛔ This seat will not perform it, and ⛔ will not waive it.

For the record, the governed question is settled the other way and needs no human merge:

node scripts/pm/check-governed-merges.mjs --pr 17811
  → 0 of 5 path(s) hit the register
  ✅ NOT governed — ordinary queue landing applies

⛔ Still blocking — 2: the base is four days stale

base is 2eab3beb (2026-09-12); this PR's head has not moved since 2026-09-12T09:42Z. main has taken a large number of merges since, including work in this PR's own neighbourhood — among them the ADR-0090 revision above and several packages/spec/src/** landings.

⇒ the CI reading on f15288e14f is a reading about a four-day-old tree and ⛔ should not be read as "this PR is green today". A main merge is owed before any green here means anything, and before the clause-② review is worth doing — reviewing the old head would review a diff that no longer describes what would land.

Suggested order for whoever picks this up

1. merge origin/main into the branch and push; let CI re-run against a current base;
2. then the domain:spec seat's clause-② review at the contract-review tier, recorded on this PR or on An app-declared capability with scope: 'org' counts as a high-privilege bit, so a set carrying only app capability tokens cannot bind to the everyone anchor #17189 naming the new head;
3. then ready → queue. ⛔ Not before 2.

Also still true and unchanged: this PR does not discharge #17189 — step ② (the plugin-security boot refusal and the @objectstack/lint security-anchor-high-privilege rule) remains untouched, and this PR carries no closing keyword.

---

Generated by Claude Code

[os-elon-musk]

Tier: served at CONTRACT_REVIEW_TIER (verified by the seat from this round's transcript)

Contract review (delta re-review of a moved head)

domain:spec contract-review tier, 2026-09-13T16:2xZ. Reviewed head of the adopted verdict (5644839802): 55dc4ac61d0a1b39055289edeb090704505038a5 (55dc4ac6). Current head: f15288e14f8b963cbecc4fde2081e2678058fe61 (f15288e14), which is what refs/heads/claude/issue-17189-app-capability-not-high-privilege points at on origin (git ls-remote, this session) and what the PR API reports as head.sha. ⛔ This is a delta review of 55dc4ac61..f15288e14 and of whether the existing PASS binds to the current head. The predecessor's judgments — the 41 adversarial probes, the 20,000-definition differential, the ablations, the snapshot regeneration, the consumer suites — are adopted and were not re-run. The record on main was read with git grep … origin/main after a fetch, never from the shared checkout; the head and its ancestors were fetched into refs owned by this session, and the build was made in a detached scratch worktree.

Tier verification, from this session's own transcript (located by a marker string only this session typed): grep -o '"model":"[^"]*"' … | sort | uniq -c → one distinct value across 84 rows, equal to CONTRACT_REVIEW_TIER in scripts/pm/dispatch-gates.mjs; lit control "type":"assistant" → 61; dark control, a fresh JSON-shaped model value never typed before this round → 0.

1. What the delta is — exactly one changeset file, nothing else

• REST compare/55dc4ac61...f15288e14: status: ahead, ahead_by: 1, behind_by: 0, total_commits: 1; the one commit is f15288e14 (docs(changeset): correct the dist measurement — 4 files, and name the build state, committed 2026-09-12T09:03:29Z). git merge-base --is-ancestor 55dc4ac61 f15288e14 → exit 0.
• git diff --stat 55dc4ac61 f15288e14 → 1 file changed, 23 insertions(+), 5 deletions(-); --name-only → .changeset/17189-app-capability-not-high-privilege.md, and no other path. The hunk begins at line 56 of the file: the frontmatter ('@objectstack/spec': minor) and every paragraph above the measurement paragraph are byte-unchanged.
• Tree-hash reading, not diff machinery: git rev-parse SHA:packages/spec at a21ad008 (pre-split), 55dc4ac61 and f15288e14 → a3dfe3c00fc3132daf76a32df774a8458717b6c6 at all three. git diff a21ad008 f15288e14 -- packages/spec | wc -c → 0. Lit control on the same instrument: git diff --name-only 482d34d60c f15288e14 (merge-base → head, the PR's own diff) → 5 files, the same five the API lists for this PR (.changeset/17189-…md, api-surface/security.json, export-origins/security.json, high-privilege.test.ts, high-privilege.ts).
• Governed-surface predicate on the delta file alone and on the 5-file list: node scripts/pm/check-governed-merges.mjs --test … → 0 of 1 / 0 of 5 path(s) hit the register, EXIT=0 both; lit control, the delta file plus docs/adr/0090-…md → 1 of 2, EXIT=3.

⇒ The delta touches changeset prose only. It moves no accept set, no source, no snapshot, no test.

2. Does the correction make the changeset TRUE? — re-measured on a clean full build, yes

Detached scratch worktree of f15288e14 (dist ABSENT before), pnpm install --offline --frozen-lockfile rc=0, then pnpm --filter @objectstack/spec build with OS_SKIP_DTS unset, under a wrapper that writes its own terminal line (the harness notification was not the reading):

START 2026-09-13T16:17:35Z  HEAD=f15288e14f8b963cbecc4fde2081e2678058fe61  dist before: ABSENT
ESM ⚡️ Build success in 23500ms        (JS pass)
DTS ⚡️ Build success in 120008ms       (DTS pass)
check-dts-emitted: @objectstack/spec - 34/34 declared declaration file(s) present.
build rc=0   END 2026-09-13T16:20:22Z rc=0   VERDICT BUILD_OK

Freshness, recomputed rather than trusted: buildInputHash(root, 'packages/spec') over src → e6eca0217408e9ab…; dist/.build-input-hash → MATCH, dist/.build-input-hash-dts → MATCH, inspectDeclarationStamp → {"state":"match"}. The newest file under dist is .build-input-hash-dts at the wrapper's END second, so nothing wrote to dist after the build. Inventory: 216 files — 63 .d.ts, 63 .d.mts, 22 .js, 22 .mjs. (⚠️ check-dev-prereqs over the whole workspace reads red in this worktree for the 67 other packages that were deliberately not built — "1 of 68" is spec, present; that red is not a spec-staleness reading and is recorded so it is not misread as one.)

Files under dist containing each literal (grep -rlF), against the changeset's table:

identifier	changeset says	read	where (all under dist/security/)
declaredCapabilities	4	4	index.js, index.mjs, index.d.ts, index.d.mts
AnchorBindingContext	2	2	index.d.ts, index.d.mts
appDeclaredCapabilityNames	2	2	index.js, index.mjs
describeHighPrivilegeBits (positive control)	4	4	the same four
fresh dark control qv7x_rev17811_delta_nonexistent_9f3a7c	—	0	—

Every count reproduces. The controls the changeset now names:

• Negative control As first written, the bullet above made → 0 built files. It is also absent from packages/spec source at f15288e14 (git grep → 0 hits, exit 1), which is the property that makes it a real control on any build mode; and it is present on origin/main in docs/adr/0090-permission-model-v2-concept-convergence.md → 1 (lit control on the same file, systemPermissions → 7). docs/adr appears in no files[]: 70 manifests at f15288e14 declare a files[], 0 name it; control, @objectstack/spec's files[] carries dist.
• The old control the changeset now explains away, The platform floor is absolute → 2 (security/index.d.ts, security/index.d.mts), and it is in packages/spec/src/security/high-privilege.ts:130 (JSDoc). The changeset's explanation — emitted JSDoc reaches the declarations, so the old control was never ADR-unique — is measured true.

⇒ The corrected paragraph is true on the tree it describes, under the build state it names. The claim it supports — the change ships, so a minor changeset is owed — was never in doubt and is unchanged.

Non-binding, text. The table's where column elides security/ on three of its four paths; taken literally, the root-level dist/index.js / index.mjs / index.d.ts / index.d.mts each read 0 for declaredCapabilities. All four hits are under dist/security/. The count column — the claim — is right; only the evidence column's spelling is abbreviated. Same finding the earlier scoped re-review (5645077973, N2) recorded; not worth moving the head on its own, and it rides the next push if there is one.

3. Does the existing PASS still bind to f15288e14? — yes, the delta is inert with respect to every derived judgment

Every judgment in 5644839802 derives from one of three inputs, and the delta touches only the third:

• packages/spec at the reviewed head — items 1–6, 8 and 9 (the excusal probes on the built artifact, the base-vs-head differential, the platform floor, the widening-vs-ruling reading, the guest tier, the two regenerated snapshots, the ablation legs A–D, the unedited consumers), and findings F1 and F2. The tree is hash-identical (a3dfe3c0…) at 55dc4ac61 and f15288e14, so none of these can have moved. F1 (a bare string satisfies Iterable) and F2 (the pre-existing everyone else-branch) remain non-binding and unchanged, carried to step ② as the seat recorded.
• The card and ruling record — item 10. Not touched by a commit.
• The changeset — item 7. Its grade input ('@objectstack/spec': minor, the Clause-②: yes floor) is outside the hunk and unchanged. Its shipped-ness numbers are what the delta corrects, and they now agree with the artifact: the predecessor's own re-measurement (4 / 2 / 4, AnchorBindingContext in 2 .d.ts) and this one read the same. F3 is thereby addressed by this delta — the one non-binding finding the predecessor filed against the prose is the one thing the prose changed.

So the PASS_WITH_FINDINGS on 55dc4ac6 carries to f15288e14 with 0 binding findings, 2 unchanged non-binding findings (F1, F2), F3 addressed, and the text note above.

Record note: an at-tier scoped re-review of this same head already exists (5645077973, 2026-09-12T09:40Z) and its readings match this one. It is not read as a review of record by check-clause2-carriers C6 because its heading begins ## Scoped re-review, not ## Contract review — reproduced from a clean worktree before this comment: node scripts/pm/check-clause2-carriers.mjs --pair 17811 → ✗ C6 … NO review of record exists on this head … 8 comment(s) on the PR thread and 15 on the card were read, EXIT=4. This comment is written in H51's measured shape (the heading, the head as a code span, the authorship pair) so that the gate can read it. Also observed on that run, not adjudicated here: an ℹ️ C2-CORRECTION note that the correction comment on card #17189 names 5644019664 rather than the governing claim 5644750913.

4. Security-card caution — what this record covers, and what it does not

⛔ The security question is ruled and is not re-opened here. What this comment establishes is only that the review record now covers the head the maintainer would merge: the card's Maintainer-action: names PR #17811 sequenced after PR #17814; #17814 is merged (PR API: merged: true, merged_at: 2026-09-13T15:12:42Z; origin/main after fetch carries the D5 revision, git grep -c "app-declared capability token" → 1 with the control above), so the sequencing prerequisite is cleared, and the PR's head on origin is f15288e14, the head this record names. ⚠️ Any further push — including the main merge the PM seat suggested in 5654401657 — is a new head, and this record does not carry to it; a head that moves owes a fresh delta read, however small.

⛔ Nothing changed by this review: no label written, stripped or changed; the PR stays draft, not enqueued, no auto-merge, no approving review; nothing pushed; the scratch worktree was removed.

Implemented-by: claude/issue-17189-app-capability-not-high-privilege
Reviewed-by: session_01EfsizFDgAcEjpwv4oM3WGT

Verdict: PASS — the delta 55dc4ac61..f15288e14 is changeset prose only, the corrected prose is measured true, and the existing PASS binds to the current head.

---

Generated by Claude Code

[os-elon-musk]

Clause-② provenance — record cited, ⛔ PR deliberately NOT enqueued

domain:spec seat, session_01EfsizFDgAcEjpwv4oM3WGT.

Record of review, as check-clause2-carriers C6 asks to be cited: comment 5654498495, a ## Contract review comment naming head f15288e14f8b963cbecc4fde2081e2678058fe61 and carrying a Reviewed-by: line. Verdict PASS — the earlier PASS on 55dc4ac61 binds to this head.

Machine read by this seat: node scripts/pm/check-clause2-carriers.mjs --pair 17811 → EXIT 0 (captured on the command, ⛔ never after a pipe).

Tier: served at CONTRACT_REVIEW_TIER, verified by this seat from the round's transcript (95/95 assistant records), against an os-dev control transcript from this same session reading the default tier (360/360) ⇒ the extractor discriminates. Model identifiers are deliberately absent from this comment per AGENTS.md:442.

⭐ What was actually blocking this PR

An at-tier scoped re-review of this head already existed (5645077973) — but its heading began ## Scoped re-review, which is not the machine-legible shape, so C6 read no review of record and --pair 17811 returned EXIT 4. Reproduced before the new record was posted, and EXIT 0 after.

⇒ the work was reviewed; the record was invisible to the gate. A review whose heading does not match is, mechanically, no review at all. Worth a word to whoever standardises these records.

The delta, verified rather than assumed

compare/55dc4ac61...f15288e14 reads ahead 1 / behind 0 — exactly one commit, touching only .changeset/17189-app-capability-not-high-privilege.md (+23/−5), frontmatter untouched. packages/spec tree hash is identical at a21ad008, 55dc4ac61 and f15288e14 (lit control: the merge-base→head diff shows the PR's 5 files). ⇒ no accept-set surface moved.

The correction itself was checked against a built artifact rather than taken on trust: clean detached worktree, offline install, build rc 0, check-dts-emitted 34/34, both stamps MATCH a recomputed buildInputHash, and the changeset's counts reproduced under dist/security/ — with a negative control at 0 and a fresh dark control at 0.

⛔ Why this PR is NOT being enqueued

Card #17189 is priority:p1 + security, and its recorded Maintainer-action: is hand-merge PR #17811, sequenced after PR #17814. PR #17814 merged at 2026-09-13T15:12:42Z, so that sequencing prerequisite is now cleared.

A permission-boundary change sits on the maintainer's manual floor. ⇒ this seat ⛔ does not enqueue, ⛔ does not arm auto-merge, and ⛔ does not merge. The review record exists so the merge can be made on a verified head.

⚠️ One action is still owed and this seat could not perform it: the PR is still draft, so it cannot be hand-merged as-is. Both undraft channels are down right now — POST …/ccr/ready_for_review returns 503 (two probes) and the GitHub MCP server is disconnected. A bare PATCH {"draft": false} was tried once and re-confirmed the documented trap: HTTP 200 with no effect, draft still true on read-back.

⚠️ Any further push makes a new head and this record does not carry to it.

---

Generated by Claude Code

[os-elon-musk]

Addendum — the platform outage cleared; both PRs are now in their final states.

domain:spec seat, session_01EfsizFDgAcEjpwv4oM3WGT. The previous note recorded both PRs stuck as drafts on a ccr/ready_for_review 503. That endpoint recovered (HTTP 200), and the remaining action has been taken. ⛔ Nothing in the verification above changed — only the draft bit.

PR	action taken	read-back
#17835 (#16929)	ready → auto-merge armed	draft=false, auto_merge set, auto_merge_enabled on the timeline
#17811 (#17189)	ready only	draft=false; ⛔ not enqueued, not armed, not merged

#17811 is deliberately left for the maintainer's hand. #17189 is priority:p1 + security — a permission-boundary change sits on the manual floor — and the card's recorded Maintainer-action: is hand-merge PR #17811, sequenced after PR #17814, which merged at 15:12:42Z. It is now ready to be merged on a head that carries a machine-legible at-tier review of record.

⚠️ #17835's added_to_merge_queue still reads 0 at the time of this note — armed, not yet enqueued. The positive reading for enqueue is that timeline event, ⛔ never the auto_merge field. Whoever picks this up should confirm it entered the queue and then verify the merge by content on origin/main, ⛔ not by the merged field.

⭐ One platform fact re-confirmed today, worth keeping: a bare PATCH /pulls/{n} with {"draft": false} returns HTTP 200 and silently does nothing — verified by read-back, reproducing the 2026-09-11 record. The working channels are POST …/ccr/ready_for_review (seat credential) and the GitHub MCP server; when both are down, there is no third way and the honest move is to record the block rather than trust a 200.

---

Generated by Claude Code