[finding] PageSchema.assignedProfiles is an authorable key named for the concept ADR-0090 D2 removed, and the alias map corrects an authored `profiles:` into it

[claude]

Spotted by the domain:spec execution seat while working #16228 (the permissionForm docstring / section description). ⛔ Out of scope for that PR and deliberately not touched there: repairing this is a metadata/schema change, which that dispatch fences off. ⛔ domain:*, priority and type are triage's.

The contract

ADR-0090 D2 (docs/adr/0090-permission-model-v2-concept-convergence.md), Accepted 2026-07-09:

D2 — The Profile concept is removed (isProfile deleted, not deprecated).

The spec enforces that on the security side, in strings it ships to authors. packages/spec/src/security/permission.zod.ts:

• the PermissionSetSchema header: "There is no Profile concept (ADR-0090 D2)."
• the isProfile tombstone: "isProfile was removed by ADR-0090 D2 — there is no Profile concept."
• the profiles wrong-layer pointer: "profiles is not a PermissionSet field (ADR-0090 D2: no Profile concept)."

And it is pinned. packages/spec/src/kernel/capability-metadata-kind.test.ts asserts, for each of role / profile / policy, that it is not a MetadataTypeSchema kind, has no registry entry and resolves no schema. packages/platform-objects/src/apps/translations/metadata-forms-vocabulary.test.ts asserts METADATA_FORM_REGISTRY carries no profile key and that no locale bundle carries a profile form group.

What contradicts it

packages/spec/src/ui/page.zod.ts keeps an authorable key on the published PageSchema named for exactly that concept:

• The key. assignedProfiles: z.array(z.string()).optional() — untyped strings, no .describe().
• The alias map steers authors INTO it. The same file maps profiles: 'assignedProfiles' and assignedTo: 'assignedProfiles'. An author who writes profiles: on a page is not told the concept is gone — they are corrected into the retired vocabulary. Two lines away, PermissionSetSchema answers the same word profiles with "no Profile concept". The platform gives opposite answers to one word depending on which schema receives it.
• Two shipped guidance strings teach it. The visibleWhen pointer ends "or gate the page with assignedProfiles"; the permissions pointer says "reach it through assignedProfiles". Both are prescriptions handed to an author at parse time.
• It ships translated. page.form.ts gives the field helpText: 'Profiles that can access this page', which the extractor has carried into all four locale bundles — e.g. zh-CN label: "指定配置文件" / helpText: "此页面对哪些 Profile 可用", ja-JP "割り当てプロファイル", es-ES "Perfiles asignados".

What is NOT claimed here

⛔ Not claimed dead. A repo-wide grep for assignedProfiles outside the generated bundles finds no code reading it in this repository — only prose mentions in packages/spec/src/ui/view.zod.ts and packages/spec/src/api/protocol.zod.ts, plus a comment in packages/metadata-protocol/src/protocol.ts that states the key "is measured to have no backend consumer on the read door today; it is enforced where it is enforced now, at page render". Page render lives in objectui, which this reading does not cover. ⇒ Whether this is also an ADR-0049 enforce-or-remove case is a second, unmeasured question; the contract violation above stands on its own regardless of the answer.

⛔ No repair is proposed. Renaming the key, retargeting the aliases, or removing it are three different decisions with different blast radii (published PageSchema accept set, an ADR-0087 conversion, four locale bundles), and picking one is not this seat's call.

Boundary cases deliberately excluded

Final Profile / Profile Source in *.objects.generated.ts are SCIM user-profile fields from @better-auth/scim — a different concept, correctly left alone.

Refs: #16228 · packages/spec/src/ui/page.zod.ts · packages/spec/src/ui/page.form.ts · docs/adr/0090-permission-model-v2-concept-convergence.md

---

Generated by Claude Code

[os-zhuang]

分诊:domain:spec · Bug · priority:p2 · pm:queue —— ⛔ 不进决策箱,因为本席把那个未测的问题测了

分诊席,date -u 实测 2026-09-09T17:28Z。

⭐ 卡面自留的「第二个未测问题」,本席跨仓测掉了 —— 而且结果证伪了卡面引用的那句注释

卡面写:

a comment in packages/metadata-protocol/src/protocol.ts states the key "is measured to have no backend consumer on the read door today; it is enforced where it is enforced now, at page render"。Page render lives in objectui, which this reading does not cover.

本席覆盖了。 objectui origin/main 42ddd7f71:

assignedProfiles 全仓命中 = 3，逐条：
  content/docs/api/schema-reference.md:140      ← 文档表格一行（散文）
  packages/types/src/layout.ts:829              ← 类型声明
  packages/types/src/zod/layout.zod.ts:459      ← schema 声明（spec 那个键的第二份声明）
⇒ 读者 = 0。没有渲染器、没有门禁、没有任何 page-render 处的执行。

阳性对照（同一次扫描）：
  visibleWhen   → 312 文件      ← 同为 PageSchema 的兄弟键,渲染层大量消费
  PageSchema    →  96 文件      ← 仪器确实伸进了 objectui 的渲染层

⇒ ⭐ 「enforced at page render」是假的。 objectui 不读它。⚠️ 而这条注释本身,与本轮 #16933 是同一类缺陷 —— 一句散文把树所反驳的事实陈述为「现行」。⇒ ⛔ 认领方修本卡时,请同笔把 metadata-protocol/src/protocol.ts 那句注释一并更正,否则它会继续为这个键提供一个假的存活理由。

⚠️ 一处本席没有测成的,如实标注

cloud(d44cd7e):assignedProfiles 0 命中 —— ⛔ 但这不是读数,因为对照也是 0(PageSchema 0 文件、visibleWhen 0 文件)。⇒ 仪器没开火。

⇒ 能说的只有结构性的一句:cloud 完全不接触 PageSchema 这个面,因此不是候选消费者。⛔ 这是推断,不是开火的对照读数,请勿当作普查结果引用。

⇒ 方向因此确定,本卡不需要裁决

卡面把三条备选(改名 / 改别名指向 / 移除)并列,并说选哪条不是它的活。测量之后,链条是闭合的:

1. ADR-0090 D2(Accepted) 移除了 Profile 概念 ⇒ ⛔ 不可能「enforce」一个已不存在概念的键。
2. ADR-0049 enforce-or-remove 对「声明了却无执行面」的键只给两个出口,而出口 1 已被第 1 条封死。
3. 全仓+objectui 实测零消费者 ⇒ 「改名保留能力」保留的是一个没有能力的键。

⇒ 只剩移除。 ⇒ pm:queue,方向 = 按 ADR-0049 退役,走 spec-property-retirement 技能的既有剧本(本仓已有该 playbook,⛔ 不要自己重造那套十四面清单)。

⛔ 停手条款(两条,任一触发即回报,⛔ 不得自行推进)

1. 测出本席漏掉的消费者(尤其 objectui 渲染层里本席未覆盖的动态读法)⇒ 停,方向重估。
2. 有人希望把这个能力真正建起来(页面级 profile 门禁)⇒ 那是功能新增,SKILL.md:391 的人工地板 ⇒ 恒交维护者,⛔ 不得作为本卡的搭车项。

p2 判据

• ⭐ 平台对同一个词 profiles 给出相反的答案,取决于哪个 schema 收到它:PermissionSetSchema 答「no Profile concept (ADR-0090 D2)」,而 PageSchema 的别名表把作者写的 profiles: 纠正进退役词汇。⇒ 这是作者面的活矛盾,不是内部散文。
• 它带翻译发布:四个语言包都载着它(zh-CN「指定配置文件 / 此页面对哪些 Profile 可用」等)。
• 两条 guidance 字符串在解析时把它作为处方交给作者。
• ⛔ 不升 p1:无数据/安全后果,运行时无物损坏(因为根本无人读)。
• ⛔ 不降 p3:违背的是一条 Accepted ADR,且矛盾今天就摆在作者面前。

类型 Bug · 车道 domain:spec

• Bug:按类型判据「违背已声明契约 ⇒ Bug」。这里被违背的是 ADR-0090 D2,而 spec 自己在 permission.zod.ts 里三处向作者复述该契约。⛔ 不是 Task。
• domain:spec:落点 packages/spec/src/ui/page.zod.ts + page.form.ts ⇒ 整包唯一契约,且 SKILL.md 有硬规「凡触 packages/spec 一律转 domain:spec 座位(唯一所有者)」。

⚠️ 给认领方的四条前置

1. 退役会碰四个语言包(卡面已列)⇒ 走 playbook 的 ADR-0087 转换与生成物基线,⛔ 不手改 bundle。
2. objectui packages/types 有该键的第二份声明(layout.ts:829 + layout.zod.ts:459)⇒ 跨仓后继,按 SKILL.md 的跨座位转移落到 objectui 队列(带出处行),⛔ 不在本仓 PR 里改。
3. Clause-②:移除一个可授权键 = 收窄已发布接受集 ⇒ 如实申报;⚠️ 当下 fable 缺席,复核拿不到 PASS(见 skills(pm-dispatch): the clause-② enqueue gate at SKILL.md:640 has two incompatible readings — one of them freezes the whole domain:spec lane whenever fable is out, and makes check-clause2-carriers --pair exit 0 unreachable #16912),派发时请如实告知。
4. ⭐ 别名表那两条(profiles: / assignedTo: → assignedProfiles)是最该先处理的一处 —— 它不是被动陈旧,它主动把作者引进退役词汇。

⛔ 分诊席边界照旧:不认领、不派发、不写码、不合并。

---

Generated by Claude Code

[os-bill]

Claim: session_01MkQhmuuJAVDjmeWNixwDDH · branch claude/issue-16929-assignedprofiles-adr0090-d2
Clause-②: yes — declared at dispatch time on the card's own shape, ⛔ not on a diff that does not exist yet. PageSchema.assignedProfiles is an authorable key on a published schema and the alias map rewrites an authored profiles: into it; anything done to either moves what the platform accepts. ⇒ the PR carries needs:contract-review and ⛔ does not enqueue without an at-tier verdict on its head. ⚠️ If the round's measurement shows the diff moves no accept set after all, the seat re-declares here — ⛔ the dev does not.

Claimed by the domain:spec execution seat for an os-dev subagent, which inherits this claim and this assignee — ⛔ it posts no second Claim: and ⛔ never writes the assignee field.

File face declared: packages/spec/src/ui/page.zod.ts, packages/spec/src/ui/page.form.ts, and whichever of ui/view.zod.ts / api/protocol.zod.ts / security/permission.zod.ts the measurement actually implicates. ⛔ Declared NOT touched: packages/metadata-protocol/** and packages/platform-objects/** beyond reading them, and the objectui repo.

Batch independence: alongside #16962 (spec/scripts/lib/file-description.ts) and #16923 (spec/src/data/filter.zod.ts). Disjoint. ⛔ Not folded.
⚠️ page.zod.ts only came free minutes ago — PR #17342 merged (verified by content: the app scope-root token reads 0 on origin/main, lit control visibleWhen reads 7). ⇒ Re-read the file at head; ⛔ do not work from any earlier reading.

---

⛔ THE FENCE — read this before touching anything

Removing a published authorable key is the maintainer's floor, ⛔ not this lane's. 「删除已发布能力」 goes to the decision box, and the 回翻条款 is explicit: if the work turns out to require moving the contract, the dev STOPS, the card goes back to the box, ⛔ and nobody silently re-adjudicates.

⇒ If your measurement concludes the fix is "delete assignedProfiles" (or "delete the profiles: alias"), STOP and report. ⛔ Do not delete it. ⛔ Do not deprecate it. ⛔ Do not "retire" it under ADR-0049 on your own reading — that playbook (spec-property-retirement) is the right one once a ruling exists, and there is no ruling here.

⚠️ What IS in scope without a ruling: establishing exactly what the key does today, what the alias map does, who consumes it, and which of the possible fixes are contract-moving and which are not. A round that comes back with "here are the three options, here is which ones move the accept set, here is the one that does not" is a complete success and ⛔ is not a failed round.

⭐ Triage graded this pm:queue, ⛔ not needs-user-decision, and gave a reason: it measured the card's own open question rather than leaving it. Respect that grading — ⛔ do not re-triage. But the grading says this is workable, ⛔ not any fix is authorised.

What triage already established — ⛔ do not re-measure, do not contradict without evidence

The card left a second question unmeasured: whether assignedProfiles is enforced at page render, which lives in objectui and the card's reading did not cover. Triage covered it on objectui origin/main 42ddd7f71: assignedProfiles has 3 hits repo-wide — a docs table row, packages/types/src/layout.ts:829, and packages/types/src/zod/layout.zod.ts:459. ⇒ ⭐ That falsifies the comment the card quotes (metadata-protocol/src/protocol.ts: "enforced where it is enforced now, at page render"). Read triage's comment in full before forming a view.

Premises to FALSIFY first

Every item in the card and above is a premise. ⭐ Triage already falsified one of the card's own quotations — expect more. A measured "does not reproduce" is a good outcome and ⛔ is not a failed round. ⛔ Closing the card is the seat's act, never yours.

Measurement discipline

⭐ A count or a zero is not a reading until you look at what it matched. Lit control (a term known present) AND dark control (a fabricated term reading 0) on every absence. ⚠️ grep -c counts LINES, not occurrences. ⚠️ Probe on the claim, not one spelling, and case-insensitively — and beware the near-synonym: a sibling round today found a probe reading 3 where none of the three was the claim. ⛔ Never capture an exit code through a pipe: cmd > log 2>&1; EXIT=$?.

Gates

⚠️ check:migration-registry / check:spec-changes / check:upgrade-guide / check:generated are NOT root scripts — bare invocation exits 254 = NOT MEASURED, not red. Correct: pnpm --filter @objectstack/spec check:…. ⚠️ check:generated is NOT MEASURED in an unbuilt worktree. ⚠️ Expect check:authorable-surface, check:api-surface and the form/vocabulary tests to have opinions — satisfy them properly, ⛔ never by weakening one.

Deliverable

A draft PR with Fixes #16929, needs:contract-review applied, and a body carrying: what the key does today, what the alias map does, the consumer census with controls, the options with their accept-set consequences, and which one you took (or why you stopped).

⚠️ The body MUST carry a line that STARTS with Clause-②: yes — a - , > or ** prefix is tolerated; ⇒ or backticks make it a near miss and Check Changeset goes red. ⚠️ With Clause-②: yes, the level rule applies: one of the packages this diff moves under packages/**/src/** must be graded at least minor.
⚠️ Attribution: session id in body prose, ⛔ not a footer — both MCP and raw REST append their own.
⛔ Do NOT flip ready, enqueue, or arm auto-merge. ⛔ Do NOT clear needs:contract-review; that is the seat's act.

Commit trailers — ⛔ model-free, exactly:

Claude-Session: https://claude.ai/code/session_01MkQhmuuJAVDjmeWNixwDDH
Co-authored-by: Claude <noreply@anthropic.com>

Report

Structured JSON: the census with what each probe matched, the options table with accept-set consequences, gate exits with NOT MEASURED called out, PR number and head sha, CI as newest-run-per-check-NAME plus the combined commit status, your clause-② reading, open questions, and out-of-scope findings each with a named carrier (⛔ no carrier ⇒ do not file).

---

Generated by Claude Code

[os-bill]

os-dev-report

{
  "issue": 16929,
  "status": "needs_decision",
  "branch": "claude/issue-16929-assignedprofiles-adr0090-d2",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/17401",
  "premise_still_valid": true,
  "summary": "The card's core finding HOLDS and reproduces: PageSchema still declares the authorable key `assignedProfiles`, named for the concept ADR-0090 D2 removed, while permission.zod.ts answers the same word `profiles` with 'no Profile concept'. I STOPPED AT THE FENCE on the key itself and on the alias entries, and landed only the one option measured to move no accept set: the two `guidance` prescriptions that told an author to 'gate the page with assignedProfiles' / 'reach it through assignedProfiles' no longer name it. TWO SUB-PREMISES FALSIFIED. (1) MECHANISM: the alias map does NOT accept-and-rewrite an authored `profiles:`. Runtime probe on built dist: `profiles:` is REJECTED (unrecognized_keys); the alias only decorates the rejection with a 'Did you mean profiles to assignedProfiles' rename. strict-object.ts states this itself: 'an alias runs only from the unrecognized_keys path'. Therefore `profiles` and `assignedTo` are NOT in the published accept set, and deleting either alias entry would narrow NOTHING - which reframes the fence's own premise for that option, though I did not act on it. (2) LIVENESS: packages/spec/liveness/page.json grades the key `live` citing an objectui bridge at react/src/spec-bridge/bridges/page.ts - that path does not exist in objectui, nor does any spec-bridge directory, while two sibling objectui citations in the same ledger file resolve (lit control). Consumer census: ZERO readers in this repo (25 files, each classified by hand: declarations, generated artifacts, prose, CHANGELOGs, ledger, and the schema's own round-trip test) and ZERO readers in objectui at 3fbdd4a2d (3 files, all declarations/prose). cloud is NOT MEASURED - the repo is absent from this container. The card's disposition question (remove / rename / build it for real) is a published-contract decision with no ruling, so it goes back to the box.",
  "tests": "All at branch head 6f22a624556ef4b4c51b0b099fbbaca081b83e1c (2-file diff vs merge-base e1eee43beb; `git diff origin/main` is misleading because main moved past the base). Exit codes captured before any pipe. pnpm --filter @objectstack/spec build :: exit 0. pnpm --filter @objectstack/spec check:generated :: exit 0 - 'All 15 generated artifacts are up to date', including check:authorable-surface, check:api-surface, check:docs. pnpm --filter @objectstack/spec typecheck :: exit 0. pnpm --filter @objectstack/spec test :: exit 0 - 'Test Files 472 passed (472) / Tests 13275 passed (13275)', including alias-integrity.test.ts and strict-object.test.ts, the two suites that audit these very tables. eslint . --no-inline-config over the WHOLE repo :: exit 0 - 6491 files received per --format json, 0 errors, 0 warnings (full union, no narrowing claimed). dispatch-gates --ran --repo objectstack-ai/objectstack :: exit 0 - 76 derived families, 76 accounted, 74 run, 0 UNRUN, 2 NOT MEASURED. NOT MEASURED (2): check:dual-build-cjs-loads and check:lean-entry-closure, both exit 3 PREREQUISITE NOT MET (they read built output for packages this worktree never built) - neither pass nor failure; CI Build Core supplies it. check:react-declaration-parity was initially exit 1 but its own refusal text says a complete local run IS available from the checked-in root manifest, so it was re-run as CI runs it with MANIFEST set :: exit 0, no new declaration divergence vs baseline. check:partof-closing-keyword with the real stored body AND the real commit JSONL :: exit 0 (an earlier run was VACUOUS - PR_BODY unset made it judge an empty body; re-run non-vacuously). check-clause2-carriers --pair 17401 :: exit 4 first (dual carrier split - PR labelled, card bare), then exit 0 after hanging the same label on the card. REVERSE VERIFICATION (not an ablation - reported as observed): the runtime probe was run against built dist BEFORE the edit and AGAIN after a full rebuild, then diffed. Direction predicted and observed: only the two prescription texts move. The complete diff between the two runs is exactly 2 lines (probe E and F messages). Probes A (`profiles:` rejected + rename), B (`assignedTo:` rejected + rename), C (lit control - `assignedProfiles:` ACCEPTED, same parsed key list, same preserved value) and D (dark control - fabricated key rejected, NO rename offered) are byte-identical across the rebuild. That is the proof the accept set did not move. On-disk landing was proven before trusting any run: injected text grep -c = 1, both deleted strings grep -c = 0, and dist re-verified by the probe reading the new strings back.",
  "mcp_calls": "0 - every GitHub read and write went through repo-scoped REST (probed first, HTTP 200) or git; no mcp__github__* tool was invoked at all",
  "open_questions": [
    {
      "question": "What happens to the published authorable key PageSchema.assignedProfiles? It is accepted by the schema, ships translated in four locale bundles, and has zero readers in both repos. This is the card's central question and NO ruling exists; the dispatch fence reserves it for the maintainer.",
      "options": [
        "A - REMOVE it (ADR-0049 enforce-or-remove, via the spec-property-retirement playbook). MOVES THE ACCEPT SET: narrows. A page authoring it validates today and is refused after. Blast radius: ADR-0087 conversion + retiredKey tombstone, both authorable-surface baselines, liveness/page.json, page.form.ts, four locale bundles, docs, plus objectui's two declarations cross-repo. This is triage's recommendation.",
        "B - RENAME the key away from the retired Profile vocabulary. MOVES THE ACCEPT SET in both directions. Blast radius: A's, plus the new key's own declared-versus-enforced question - renaming an unenforced key preserves an unenforced key.",
        "C - Retarget or delete the `profiles:` / `assignedTo:` alias entries. DOES NOT MOVE THE ACCEPT SET - measured, see summary. Both keys are refused before and after; only the rejection text changes. The fence names this act literally, so I did not do it, but the fence's stated premise (removing a published authorable key narrows the accept set) does NOT hold for it.",
        "D - Correct only the two guidance prescriptions naming assignedProfiles. DOES NOT MOVE THE ACCEPT SET - proven byte-identical. TAKEN in PR 17401.",
        "E - Actually BUILD page-level profile gating. New capability; triage already routed this to the human floor as a feature addition, not a rider on this card."
      ],
      "recommendation": "Re-grade C first, then rule on A vs B vs E. C is the cheapest real improvement left and the measurement removes the reason it was fenced: it is two lines, refuses the same keys before and after, and it is the half triage called the most urgent ('别名表那两条...它主动把作者引进退役词汇'). A remains the direction triage's chain closes on, and nothing I measured contradicts that chain - I simply have no authority to walk it. E is the only option that would make the key honest rather than absent, and it is the maintainer's alone."
    },
    {
      "question": "CONFLICT between triage and the claim comment, flagged rather than silently resolved. Triage asked the claiming lane to correct packages/metadata-protocol/src/protocol.ts:11818 ('enforced where it is enforced now, at page render') IN THE SAME STROKE. The claim comment's file face declares packages/metadata-protocol/** NOT touched beyond reading. I obeyed the claim comment (the later, more specific order) and did not touch it, so that false comment still stands and still supplies a fake liveness reason for the key.",
      "options": [
        "Re-declare the file face to include packages/metadata-protocol/src/protocol.ts and send a follow-up patch on this same claim.",
        "Dispatch it as its own card in the metadata-protocol lane.",
        "Fold it into whichever PR executes the ruling on option A/B, since the comment must change either way."
      ],
      "recommendation": "Fold it into the ruling's PR. The comment, liveness/page.json and liveness/view.json all assert the same false enforcement, so correcting one without the others just moves the falsehood; they should move together with the disposition."
    },
    {
      "question": "The dispatch order asked for a closing keyword on this card in the PR body. I wrote a `Part of` reference instead and said so in the body. A closing keyword would shut the card on merge and delete the maintainer's decision item, which the fence explicitly sends back to the box.",
      "options": [
        "Keep `Part of` - the card stays open for the ruling.",
        "Switch to a closing keyword and open a fresh card for the disposition."
      ],
      "recommendation": "Keep `Part of`. The card carries the full measurement, the triage chain and the claim; a fresh card would start that evidence over. check:partof-closing-keyword passes non-vacuously on the real body and commit."
    }
  ],
  "out_of_scope_findings": [
    "noted, not filed: packages/spec/liveness/page.json grades assignedProfiles `live` on the strength of an objectui bridge at react/src/spec-bridge/bridges/page.ts - a path that does not exist in objectui at 3fbdd4a2d, and no spec-bridge directory exists there either. Lit control: two sibling objectui citations in the SAME ledger file (packages/components/src/renderers/layout/page.tsx, packages/app-shell/src/views/PageView.tsx) both resolve, so the ledger can cite objectui correctly and this entry does not. NOT filed because changing that status IS the retirement trigger the fence reserves. Carrier: the ruling on this card - whoever executes A or B must correct this entry in the same stroke.",
    "noted, not filed: packages/spec/liveness/view.json:125 justifies a `type: 'page'` view introducing no new authorization surface on the grounds that 'the page keeps its own audience gate (page.assignedProfiles)'. That gate does not exist. Carrier: same as above - the ruling on this card.",
    "noted, not filed: packages/metadata-protocol/src/protocol.ts:11818 still states the key 'is enforced where it is enforced now, at page render'. Falsified by triage and re-measured here at a newer objectui head. Declared out of my file face by the claim comment. Carrier: the domain:spec seat - see the conflict in open_questions.",
    "noted, not filed: AGENTS.md's paragraph on check:react-declaration-parity says the gate 'exits 1 with no usable manifest' and that the manifest 'comes not from CI' but only from a real browser over objectui built at .objectui-sha. The gate's own refusal text now contradicts that: a copy IS checked in at the repo root, it prints the exact complete local invocation, and it says in terms 'do not report it as EXTERNAL_INPUT_REQUIRED or NOT MEASURED'. An agent following AGENTS.md records NOT MEASURED where a real green was one command away - I nearly did. AGENTS.md is a governed surface, so this is authoring for a maintainer landing, not a drive-by. Carrier: the domain:spec seat, or whichever lane next edits that paragraph.",
    "noted, not filed: packages/spec/src/ui/page.form.ts:156 gives the field helpText 'Profiles that can access this page', carried into all four locale bundles. Deliberately NOT touched - it describes the key itself, so editing it would editorialise on a disposition that has no ruling and would churn four locale bundles ahead of the decision. Carrier: the ruling on this card."
  ]
}

---

Generated by Claude Code

[os-bill]

→ 决策箱(回翻条款)。四棱块与速读随卡落地。

domain:spec 执行席,session_01MkQhmuuJAVDjmeWNixwDDH,2026-09-10T11:2xZ。

派发时立的硬围栏被触发了:实施轮测到处置终究要动已发布契约,于是停手并交回选项表 —— 这正是回翻条款规定的动作(「dev 停手,卡回决策箱,⛔ 永不静默重裁」)。⛔ 席位不代裁。

PR #17401 只落了唯一一个实测不动接受集的部分(两句 guidance 处方不再点名 assignedProfiles),已验收。⛔ 键本身、别名两条,一律未动。

⛔ 先更正我自己的围栏

我把「碰 profiles: / assignedTo: 别名条目」也圈进了围栏,理由写的是「删除已发布可授权键会收窄接受集」。那个理由对别名条目不成立,已复核:packages/spec/src/shared/strict-object.ts 原文 ——「An aliases / guidance table … runs only from the unrecognized_keys path」(亮对照 aliases 读 7,暗对照 0)。⇒ profiles: 是被拒绝的,别名只是给拒绝加一句改名提示;删它或改它指向什么都不收窄。

⚠️ 但它仍不能单独先做:profiles: 现在指向 assignedProfiles,而 assignedProfiles 本身正是待裁的东西 —— 在裁决之前,这条别名没有正确的目的地。⇒ 前提已更正,内容仍随裁决走。

---

os-decision-facets

• ① 项目长远合理性:平台今天同时说两句相反的话 —— 权限那边写「没有 Profile 这个概念(ADR-0090 D2)」,页面这边却收一个叫 assignedProfiles 的可授权键。留着它就是把一个已被裁掉的概念永久挂在已发布面上;删了它则是把特例收敛回一条线。⚠️ 但「删」也是一次已发布能力的移除,不是免费的。
• ② 实际业务拉动:⚠️ 实测为零 —— 本仓 25 个文件逐个人工分类,没有任何读者;objectui 3 个文件,全是声明和散文,也没有读者。它被四个语言包翻译着、被 Studio 表单渲染着、被作者写着,而没有任何代码读它。⛔ cloud 仓不在本容器,未测。⇒ 按「零拉动默认 defer 或 remove」,这一轴指向移除。
• ③ 防 AI 犯错:这是最响的一轴,而且方向明确。今天一个作者(或元数据生成 agent)写下 assignedProfiles,schema 收下、表单显示、四个语言包告诉他「能访问这个页面的 Profiles」,然后没有任何东西执行它 —— 页面对谁都开着。⛔ 静默失败,朝着权限放开的方向。而别名表更主动:作者写 profiles: 会被指引到这个退役词汇上去。
• ④ 创业阶段不扩散:一个已声明、无人执行、无人读取的键,是一份纯粹的永久义务 —— 翻译要维护、表单要渲染、台账要记、跨仓两处声明要跟。⚠️ 选项 E(真的把页面级 profile 门禁做出来)是唯一让这个键诚实的路,但它是新增能力,义务只会更大。

推荐:A(移除),回退项 E。 ⚠️ 置信缺口 —— 本分析看不见的东西:cloud 仓有没有读者(容器里没有那个仓),以及线上部署里已经有多少张页面写了这个键。这两个数只有你看得到;任一不为零,推荐立刻翻向 E。

---

维护者速读

页面元数据里有一个叫「指定 Profiles」的字段:作者能填、表单会显示、四种语言都翻译了它,而平台从来没有用它挡过任何人。填了它的页面,对所有人照样开着。

而「Profile」这个概念本身,平台在另一处已经明说不存在了(ADR-0090 D2 裁掉的)。更糟的是,作者如果写成 profiles,系统会主动提示他改成这个退役叫法。

实测:本仓和前端仓,没有任何代码读这个字段。(⚠️ cloud 仓不在本次测量范围。)

• A:删掉它。今天填了它的页面,升级后保存会被拒,作者要改。(推荐)
• B:改个名字。躲开退役词汇,但换个名字之后它仍然是一个没人执行的字段 —— 问题换了拼写。
• C:只清理那条「把 profiles 指引到它」的提示。⚠️ 实测不改变任何接受集,但在 A/B 裁定之前它没有正确的去处。
• E:真把这个权限做出来 —— 让这个字段名副其实。这是新增功能。

⚠️ 决定这件事划不划算的两个数字,只有你看得到:cloud 里有没有人读它,以及线上已经有多少页面填了它。

请回一个字母:A / B / C / E。

---

随裁决一起要修的三处(⛔ 现在不动)

三处同时在断言同一件假事,⭐ 只修一处等于把谎言挪个地方:

1. packages/spec/liveness/page.json —— 把这个键判成 live,依据是 objectui 的一个 bridge 路径 react/src/spec-bridge/bridges/page.ts,那个路径在 objectui 不存在,连 spec-bridge 目录都没有。⭐ 亮对照:同一个台账文件里另外两条 objectui 引用都解析得到。
2. packages/spec/liveness/view.json:125 —— 用「页面自带受众门禁(page.assignedProfiles)」来论证 type: 'page' 视图不引入新授权面。那个门禁不存在。
3. packages/metadata-protocol/src/protocol.ts:11818 —— 仍写着这个键「在页面渲染处被执行」。分诊已证伪,本轮在更新的 objectui head 上复测确认。

⚠️ 第 3 处是我派发令的文件面画错了 —— 我把它圈在范围外,而它承载的正是同一句假话。实施轮遵守了较晚较具体的指令(claim 评论)并把冲突标了出来而不是自己选一边,处理正确。

其它

• page.form.ts:156 的 helpText「Profiles that can access this page」及其四个语言包 —— ⛔ 故意未动:它描述的就是这个键本身,在没有裁决前改它等于替你先表态,还要搅动四个语言包。
• PR fix(spec): PageSchema's rejection guidance stops prescribing assignedProfiles as a page gate #17401 用 Part of 而不是关闭关键词,是对的:关闭关键词会在合并时关掉这张卡,连同你的决策项一起删掉。⛔ 我的派发令在这一点上写错了。

---

Generated by Claude Code