[Decision] DESIGN.md §04 makes clm_requester every employee's default, but a set that grants clm_requester.access cannot bind to everyone

Ruled: 6395821523 · letter A · 2026-10-25T09:14Z (第二问；第一问 Ruled: 5604446794 · letter A · 2026-09-09)
Ruled: 6398381229 · 第 3 步 letter A（声明 11 个能力令牌 + isDefault + 删七个额外绑定）· 2026-10-25T13:41:33Z

Unblocked: the 17.7.0 → 18.1.0 upgrade landed as PR #110 (7b736a0).

维护者速读

事情：DESIGN.md §04 说 clm_requester 是「所有员工默认」的权限集，同时又说导航分区的门控能力 clm_requester.access 由这个权限集的 systemPermissions 授予。平台的规则是：带任何 systemPermissions 的权限集属于高权限集，不能挂到 everyone 锚点（ADR-0090 D5/D9）。运行时在启动时拒绝绑定并打警告，os lint 直接报错（security-anchor-high-privilege）。所以「默认给所有员工」在这个平台版本上没有自动机制，卡 04 只能把它做成「分发」：七个岗位各自额外绑定 clm_requester（法务、财务、档案、管理员、两级领导都同时是发起人），没有岗位的普通员工由管理员在 Setup 里逐人授予。

为什么现在问你：改法有两个方向，一个改 §04 措辞，一个向平台提需求；两者都不是开发 agent 能定的。今天不定不阻塞 M1（验收测试用管理员逐人授予跑通了），但卡 07 要按 clm_requester.access 门控「我的合同」分区，到那时普通员工看不看得到这个分区，取决于这个决定。

选项：

A（推荐）：接受分发模型，§04 加一句「clm_requester 由管理员授予未持岗位的员工；持岗位者随岗位绑定」。零改代码；同时向 objectstack 报一个平台缺口：应用自己声明的 capability（scope: 'org'）不该被算作高权限位。平台修好后，把 clm_requester 标成 isDefault 就能自动给所有人，这边只需删一行绑定。
B：把 clm_requester.access 从 systemPermissions 拿掉，clm_requester 标成 isDefault: true 自动绑到 everyone；「我的合同」分区改为只要登录就可见（§04 与 §05 都要改一句）。
C：新增第八个岗位 clm_employee，绑定 clm_requester，管理员给每个员工发岗位。§04「岗位七个」要改。

代价：A 多一步管理员操作（每个新员工），文档改一句，等平台修好可以收回；B 少一个门控能力，导航分区退化成「登录即见」，但和 §04 的 access 令牌体系不一致；C 多一个岗位，仍然要逐人发，只是从「发权限集」变成「发岗位」。

你要做的：回一个字母，A、B 或 C。

Context

DESIGN.md §04, verbatim:

Permission set 五个：clm_requester（所有员工默认）· clm_legal · clm_finance · clm_records · clm_admin。
导航分区的门控能力由权限集 systemPermissions 授予：clm_requester.access · …

The platform's only mechanism for "the set every authenticated member holds" is isDefault: true on the set, which auto-binds it to the built-in everyone position at boot (ADR-0090 D5). That binding is gated by describeHighPrivilegeBits (@objectstack/spec/security), whose first rule is: any non-empty systemPermissions makes the set high-privilege. Measured on 17.3.0:

plugin-security bindBaselineToEveryone: refusing to bind fallback set to everyone — high-privilege bits { offending: "system permissions" } — a boot warning, and no binding.
@objectstack/lint security-anchor-high-privilege (severity error): isDefault:true suggests binding this set to the 'everyone' audience anchor, but it carries system permissions — the runtime will refuse the binding (ADR-0090 D5/D9).

So §04's two sentences cannot both be satisfied automatically on this platform version. Card 04 (#4) implemented the distributed reading without editing §04:

src/security/bind-position-sets.ts binds every one of the seven positions to clm_requester as well as to its own set (12 rows; measured on a running app);
the two requester test accounts in the acceptance run received the set through sys_user_permission_set rows written by the seeded admin — the Setup path.

Governing text: DESIGN.md §04 (the two sentences above); AGENTS.md → Delivery process → a code PR never touches DESIGN.md §01–§04 without a needs-user-decision first; → Platform gaps → report, never patch.

Options

A — keep the tokens, state the distribution, report the platform gap. §04 gains one sentence; objectstack gets an issue proposing that an app-declared capability with scope: 'org' (ADR-0066 D1) not count as a high-privilege bit for the everyone anchor — manage_users and clm_requester.access are not the same kind of thing. When that lands, isDefault: true on clm_requester restores the automatic default and the seven extra bindings can go.

B — drop clm_requester.access, make the set isDefault. The "我的合同" navigation group (§05) is then gated by authentication alone. Consistent with the platform today; inconsistent with the five-token *.access scheme §04 and §05 build the navigation on.

C — an eighth position, clm_employee. Keeps every token; changes "Position 扁平，七个" and turns the per-employee admin step into a position assignment rather than a set grant.

四棱分析

实际业务需求 — A 或 C。业务上「所有员工都能发起合同」是产品定位（§01），门控能力是卡 07 导航分区的基础；B 把「我的合同」分区退化成登录即见，短期无害，但一旦客户要按员工类型（例如外包、实习）收窄「谁能发起」，B 没有开关。A 保留开关。

项目长远合理性 — A。矛盾在平台的高权限判定粗于 ADR-0066 的能力模型（应用能力令牌与平台系统权限被一视同仁），根因应回到平台修；应用侧 A 的代码在平台修好后可整体收回，B 与 C 都是把平台的粗糙固化进设计文本。

防 AI 写错 — A。三个方案里只有 A 不改 systemPermissions 的语义；B 让「一个权限集既是默认又不带令牌」成为惯例，下一个 AI 作者会在别的分区照抄，门控能力体系逐渐空心化；C 引入一个只为绑定而存在的岗位，与 ADR-0090「岗位是分发点」勉强相容，但七变八的理由是平台限制而非业务，容易被下一个读者当成业务岗位再挂规则。

创业阶段不扩散 — 三者都不扩散能力面。A 增加一步管理员操作与一条上游 issue；B 删一个令牌；C 加一个岗位。A 的成本最低且可逆。

结论：四棱同向 A。推荐 A。

Impact if deferred

M1 is not blocked: card 04's acceptance run staffed the requester accounts through Setup-equivalent grants and every refusal was observed. Card 07 (views/app) gates the "我的合同" group on clm_requester.access; an employee without the grant will not see it. Deciding before card 07 is dispatched avoids a second pass over the navigation.

第二问（PM 追加）：六个动作门控挂在哪些权限集上

§04 列出了六个动作门控，但没说哪个权限集持有哪个。卡 04 只能推导，推导结果在 PR #12 里。这一条落在「安全与权限边界」上，按规矩归你，不归我。

维护者速读：下面这张表里只有最后一行需要你多看一眼——「审批合同」这个门控挂在了发起人这个权限集上，看起来像「人人都能审批」。实际不是：审批阶梯的第一级就是直接主管，而主管在系统里就是个普通员工，只持有发起人权限集。不给他这个令牌，第一级永远没人能点。持有令牌不等于能审批任何合同，能审批哪一份由审批流程指派。

动作门控	推导出的持有者	依据
维护审批矩阵	管理员	§04 矩阵里只有管理员对审批规则有写权限
维护条款库	法务、管理员	§04 矩阵：条款对法务是 RCU
登记执行、归档	档案与记录、管理员	§04 矩阵：签署记录与归档字段归档案岗
终止合同	法务、管理员	终止是法律动作，§04 矩阵里业务承办对生效合同无写权限
审批合同	发起人、法务、财务、管理员	§06 F5 第一级是直接主管，主管只持有发起人权限集

选项：

A（推荐）：接受这张表。每一行都由 §04 矩阵或 F5 的阶梯结构推出来，最后一行是唯一能让第一级审批工作的挂法。
B：你改动其中若干行，改法是 src/profiles/ 里的一行编辑，不影响其他任何东西。

你要做的：和本卡第一问一起回，比如「A A」。

Both questions on this card are one-line reversible edits and neither blocks M1 — PR #12 is merged and the acceptance run staffed its personas through the Setup path. Card 07 is the first consumer of question 1 (it gates the 我的合同 navigation group on clm_requester.access); question 2's only consumer is card 06's approval ladder.

Generated by Claude Code

Positions, permission sets, sharing rules, FLS and the bootstrap bind…

第一问裁定：A —— 接受分发模型，缺口报到平台

维护者裁决，2026-09-09，常设决裁批第 1 批，逐字：

第 1 批平台的问题去平台修，业务的问题按照你的意见。

第一问的阻塞源是平台缺陷（平台的高权限判定把应用自己声明的能力令牌与平台系统权限一视同仁，粗于 ADR-0066 的能力模型）⇒ 走「去平台修」，而选项 A 恰好就是这个形状：应用侧保持现状、把缺口报到平台、平台修好后删一行绑定即可恢复自动默认。

⛔ 因此 B 与 C 明确不采纳：两者都是把平台今天的粗糙固化进设计文本，且不可逆。

Governing text（录裁前重跑）：DESIGN.md §04「Permission set 五个：clm_requester（所有员工默认）…导航分区的门控能力由权限集 systemPermissions 授予：clm_requester.access…」；AGENTS.md → Platform gaps → report, never patch。

鲜度门：正文最后编辑 2026-09-07T14:00:44Z；其后一条评论（2026-09-07T14:05:46Z，前任 PM 追加的第二问）—— 见下，它改变了本卡的状态转换。

⚠️ 第二问未裁，本卡因此不离开决策箱

本卡带两问。前任 PM 在 2026-09-07T14:05:46Z 追加了第二问（六个动作门控分别挂在哪些权限集上），并写明「和本卡第一问一起回」。

我在第 1 批只呈报了第一问。 这是我的呈报缺漏，不是你的遗漏 —— 你说「业务的问题按照我的意见」，而第二问我从未给过意见，你无从背书一个不存在的推荐。

而且第二问不能由我代裁：它自己写明落在「安全与权限边界」上，而安全/权限边界是代裁的人工地板，任何自裁通道都够不到它。第二问的实质是「审批合同」这个门控挂在了发起人权限集上 —— 表面像「人人都能审批」，实际是因为审批阶梯第一级是直接主管、而主管在系统里只是普通员工。这个取舍必须你亲自看一眼。

⇒ 状态转换：本卡维持 needs-user-decision。 第一问的落地作为搭车项（Refs #11，⛔ 非 Fixes）随设计文档 PR 走；第二问随下一批呈给你，届时我补齐它的四棱与推荐。

裁后执行（仅第一问）

§04 编辑（受管面，随折叠的设计文档 PR，链首 [Decision] DESIGN.md §03 requires a termination reason but declares no field for it #6）：加一句 —— clm_requester 由管理员授予未持岗位的员工；持岗位者随岗位绑定。
代码零改动：卡 04（Positions, permission sets, sharing rules, FLS, onEnable bindings (card 04, M1) #4 / PR Positions, permission sets, sharing rules, FLS, onEnable bindings (card 04, M1) #12）实现的就是这个分发模型，七个岗位各自额外绑定 clm_requester，已在 main 上。
平台缺口卡已立：见下方本席的立卡回链。按跨仓规矩 file-at-destination，普通卡、无 assignee、待分诊。
平台修好后的收回动作（预写在此，免得将来重新论证）：把 clm_requester 标 isDefault: true，删掉 src/security/bind-position-sets.ts 里那七行额外绑定。

与 #28 的耦合，现已解开

#28 明写「先回 #11 第一问，这一张的答案就基本定了」。第一问裁 A ⇒ dev admin 永远看不到「我的合同」分区 ⇒ #28 的选项 C 自动出局，剩下 A（维持现状，操作员手工建号）与 B（让 pnpm demo 自己建三个演示账号）二选一。#28 在第 2 批，届时按这个已定的前提呈报。

Generated by Claude Code

Evidence for this card's second question · 2026-10-09T16:01Z — measured by the #82 dev (PR #85, Acceptance notes), identical on 17.4.0 and 17.7.0.

A clm_admin holder cannot edit a contract past submitted: PATCH /api/v1/data/clm_contract/ID → 403, and editing its child review is refused with "master not editable … row-level security". Cause, as measured: every position also binds clm_requester (the workaround for the everyone anchor this card is about), and that set's using-only contract_requester_edit_window is the only update policy that applies — so the requester's edit window caps the administrator too. README says clm_admin "holds full reach over every CLM object".

Not filed as its own card: its cause is the binding this card's open question decides. Whichever permission sets hold clm_requester once Q2 is ruled, this is the case that ruling must not leave behind.

Generated by Claude Code

Ruling: batch #2 item 1 · letter A · maintainer 「同意」 2026-10-25T09:14:04Z

第二问裁定：A —— 接受六个动作门控的持有者表

维护者在第 2 批决策箱对本卡第二问回了「同意」（= 推荐项 A）。裁决文档：https://claude.ai/artifact/X4sZxhLrEYshLjkgYp4svr 。第一问早已于 2026-09-09 裁 A（评论 5604446794）；至此本卡两问皆裁。

所裁的表（2026-09-07T14:05Z 追加的第二问，main e4997a8 的 src/profiles/*.profile.ts 与之一致）：

动作门控	持有者
`manage_approval_rules`	管理员
`manage_clauses`	法务、管理员
`execute_contract`、`archive_contract`	档案岗、管理员
`terminate_contract`	法务、管理员
`approve_contract`	发起人、法务、财务、管理员（F5 第一级是直接主管，主管只持发起人权限集；持令牌只是能点按钮，能审批哪一份由审批流程指派）

鲜度门：正文 2026-09-07T14:00Z；评论三条，最后一条 2026-10-09T16:02Z（#82 dev 的 clm_admin 证据），已纳入下面第 2 点。录裁前重读，无新评论。

裁后执行（给 lane 席位）

§04（受管面）：加一张「门控 × 持有者」表，内容即上表。随设计文档 PR（链首 [Decision] DESIGN.md §03 requires a termination reason but declares no field for it #6）走，Refs #11。零改代码。
随裁必查的缺陷，不是裁决题：评论 6084539514 实测 clm_admin 改不了 submitted 之后的合同（PATCH → 403「master not editable … row-level security」），原因是每个岗位都额外绑了 clm_requester，该集的 contract_requester_edit_window（using: status in [draft, submitted]）成了唯一生效的 update 策略，把管理员也压住了；README 承诺管理员「对每个 CLM 对象全量可达」。lane 要先定性：若是平台语义（一个权限集的 using 策略压住另一个集的全量授权）→ 立 objectstack 卡、等平台，不绕路；若是 clm_admin 自己缺一条全量规则 → 直接修。两种都不改上表。
第一问的收回动作可以排期了：第一问的平台缺口 objectstack#17189 与 #18535 均已 completed。18.1 升级 PR 合并后，dev 实测 clm_requester 标 isDefault: true 是否被 boot / os lint 接受；若接受，执行评论 5604446794 预写的收回（标 isDefault，删 src/security/bind-position-sets.ts 的七行额外绑定）。⚠️ 收回不消除第 2 点：everyone 自动绑定后管理员仍持 clm_requester。

⛔ 本席不动标签（director 席位只录裁决）；lane 席位派发时转标签并带 Ruling-ref:。

Generated by Claude Code

Out of the decision box — Ruling-ref: comment 6395821523 (batch #2 · maintainer 「同意」).

State: needs-user-decision → pm:blocked, Blocked-by: the 18.1 upgrade PR. 18.x moves position → permission-set binding onto the position definitions (src/sharing/positions.ts), which is the surface both follow-ups touch.
After it lands, one card: diagnose the clm_admin update cap (comment 6084539514) — platform semantics ⇒ objectstack card and wait; a missing clm_admin rule ⇒ fix it — and measure isDefault: true on clm_requester (objectstack #17189 / #18535 are closed) before the retraction pre-written in comment 5604446794.
The §04 gate × holder table is governed text and goes with the design-document PR (Refs #11).

Generated by Claude Code

Unblocked: PR #110 (the 18.1 upgrade) merged as 7b736a0. State pm:blocked → pm:queue; dispatch follows its ruling.

Generated by Claude Code

Ruling: batch #6 item 1 · letter A · maintainer 「同意」 2026-10-25T13:41:33Z

第 3 步裁定：A —— 声明全部 11 个能力令牌，`clm_requester` 标 `isDefault: true`，删掉七个岗位的额外绑定

维护者在第 6 批决策箱回了「同意」（= 推荐项 A）。裁决文档：https://claude.ai/artifact/SZoEhiaJ1uSE776GAvBYqh 。这是第一问裁决（5604446794）预写的收回动作，按 18.1 平台的要求补上一块声明。

依据（objectstack main，2026-10-25 复测）：平台修复 objectstack-ai/objectstack#18535 把解锁定义为「应用在 capabilities: 里声明自己的 systemPermissions 令牌」——security-anchor-high-privilege（packages/lint/src/validate-security-posture.ts:611-624）与运行时同一条规则，逐令牌比对（describeHighPrivilegeBits，spec/security/high-privilege.ts:147-158），平台自己的令牌永不豁免。开发在 18.1.0 上三条腿实测（PR #117 正文）：只标 isDefault 全拒；加声明 11 个令牌全绿，无岗位成员自动持 clm_requester；再删七个额外绑定，八个人物有效权限集逐个不变。

对 AGENTS.md「能力扩展：紧」那条的判定：声明令牌不触发它。这 11 个令牌是五个权限集今天已经在授予的门控，声明只是把它们列在平台要求的位置；不加运行时依赖、插件、requires: 或外部服务。车道不必再问。

鲜度门：正文首行 Ruled: 6395821523；评论 9 条，最后一条 6398156132（2026-10-25T13:19Z，PR #117 落地）。录裁前重读，无变化。

裁后执行（给 lane 席位）

objectstack.config.ts：capabilities: 声明 11 个令牌（scope: 'org'），即 PR clm_admin edits contracts past submitted: the administrator carries its own permissive update policies #117 正文 Leg B 的那块。
src/profiles/requester.profile.ts：isDefault: true；头注释改写。
src/sharing/positions.ts：删七个 RequesterSet.name 条目；注释改写。
README：第 93–96 行（发起人不持岗位、Setup 逐人授予）与第 147 行（dev admin 看不到「我的合同」）改写为「每个成员默认持 clm_requester」；顺手修 PR clm_admin edits contracts past submitted: the administrator carries its own permissive update policies #117 验收注记里的两处漂移（已退役的 bind-position-sets.ts 文件名；sys_user_permission_set 的字段是 permission_set 名而非 id）。
受管面：第一问裁决让 §04 加的那句「clm_requester 由管理员授予未持岗位的员工；持岗位者随岗位绑定」收回，随席位的设计文档 PR（Refs #11），与第 1 条（门控 × 持有者表）同车。
第 2 步的 clm_admin 自有更新规则（PR clm_admin edits contracts past submitted: the administrator carries its own permissive update policies #117，bcf8eb9）保留：收回后管理员仍持 clm_requester。
不开平台卡：所需能力已在 18.1。

⛔ 本席不动标签；lane 席位派发时转标签并带 Ruling-ref:。

Generated by Claude Code

Claim: PM loop round 14 (second branch on this card, same session)
Session: session_017nzWFRUo2U7evMkPdVniAn
Account: zhuangjianguo (the seat's linked user as GET /user answers it; the card's assignee)
Branch: claude/issue-11-requester-default
Worktree: hotclm-issue-11
Domain: repo:hotclm (single-lane sister repo — no domain:*)
Seat: repo:hotclm#1
File surface: objectstack.config.ts (capabilities: block only) · src/profiles/requester.profile.ts · src/sharing/positions.ts · README.md (the requester-grant paragraphs, the dev-admin line, the retired bind-position-sets.ts name, the permission_set field name) — stop on breach; explain in the report
Container & model: S, mode:subagent, model: opus (TIER_DEFAULT; hand-derived for a sister repo), effort: medium
Clause-②: no
Metadata-protocol: none
Responsibility: this app's requester distribution (a manual Setup grant for every position-less employee) | none known | every employee without a CLM position
Thread-read: 6398381229
Ruling-ref: 6398381229 (batch #6 item 1 · letter A) — the retraction pre-written in 5604446794
Premise: measured by the previous branch on 18.1.0 (PR #117 body, legs A/B/C); re-run by the dev on origin/main
Serial constraints cleared: PR #117 (admin.profile.ts) merged bcf8eb9. In flight: #107 (objectstack.config.ts composition knob) — different block of the same file; whoever lands second rebases. #99 and #38 disjoint. Step 5 (§04) needs no text: the question-1 sentence never reached DESIGN.md (§04 already reads 「clm_requester（所有员工默认）」); the gate × holder table rides PR #120.

Generated by Claude Code

os-dev-report
{
"issue": 11,
"status": "done",
"branch": "claude/issue-11-requester-default",
"pr": "#122",
"session": "session_017nzWFRUo2U7evMkPdVniAn",
"premise_still_valid": true,
"summary": "Ruling 6398381229 step 3 (letter A), steps 1-4 of its lane list, delivered as draft PR #122 (Part of #11, no closing keyword). objectstack.config.ts gains a capabilities: block (only that block) declaring the eleven tokens the five sets grant, scope 'org', each with a label and a description. clm_requester carries isDefault: true and its header is rewritten. positions.ts drops the seven RequesterSet.name entries (the executive and GM positions now omit permissionSets) and its header is rewritten. README now says every member holds clm_requester by default: the requester paragraph, the named-accounts 'Give it' cell, the dev-admin paragraph and the permission_set_id drift are rewritten, plus two paragraphs in 'Assigning a position from a script' that this change made false ('a position grants clm_requester too'; 'an id-spelled position lands the account in the dev admin's navigation: [] state'). The retired bind-position-sets.ts name was already gone from README.md on 4460d31: PR #110 (7b736a0) replaced it, so the previous report's drift note no longer applied to README. Its two remaining mentions in src/apps/clm.app.ts are out of surface and listed in Acceptance notes. admin.profile.ts is untouched. Persona accounts were created on the throwaway local demo DB the README way, and no permission check refused it.",
"tests": "No test files (metadata app). 18.1.0, pnpm demo --port 3411, one throwaway DB, before = origin/main 4460d31, after = d96e62a. Personas: create-user x9 -> 200; sys_user_position x7 and sys_user_permission_set x1 (permission_set: 'clm_requester') -> 201; change-password x9 -> 200. security/explain principal (clm_contract read+create), before vs after: admin = clm_admin,clm_requester,member_default; counsel and head = clm_legal,clm_requester,member_default; finance = clm_finance,...; records = clm_records,...; executive, GM and the requester row = clm_requester,member_default. All UNCHANGED; only the attribution moves from 'direct grant' to 'additive baseline (ADR-0090 D5)'. Persona Blank (no position, no grant): member_default with read/create false -> clm_requester,member_default with read/create true. Dev admin: admin_full_access,member_default,organization_admin_no_bypass -> the same plus clm_requester. Blank member POST /api/v1/data/clm_contract: before 403 PERMISSION_DENIED, after 201, then its list total is 1. GET /api/v1/meta/app/clm groups and contract totals per persona are unchanged (admin/counsel/head 120 and +1 for the blank member's new row, finance 82, records 82, executive 23, GM 4, requester 0). Blank: 403 / navigation [] -> group_my_contracts + group_analytics. Dev admin: navigation [] -> group_my_contracts (launch, my_contracts, approvals inbox, my_obligations) + group_analytics. Browser: Chromium /opt/pw-browsers/chromium via /opt/node-tools playwright-core, signed in as admin@objectos.ai, /_console/apps/clm. Before: no My Contracts/Analytics items in the sidebar. After: sidebar My Contracts (Launch a Contract, Launched by Me, Waiting on Me, My Obligations) + Analytics (Executive Overview), no other group; clicking Launched by Me lands on clm_contract/view/my_contracts. Console identical on both runs (401 get-session before sign-in, one 404 resource). Boot: the diagnostics block and all WARN/ERROR lines are byte-identical main vs branch on the same DB re-run, with no high-privilege or anchor refusal. The refusal leg (isDefault without the block) was not re-run; PR #117 Leg A is cited.",
"gates": "Local, head d96e62a (rebased on origin/main 4460d31, no-op), exit codes captured to files before any pipe: pnpm install 0; pnpm validate 0 ('✓ Validation passed (959ms)', the 7 pre-existing warnings, none about capabilities/isDefault); pnpm lint 0 ('6 suggestion(s)', same count as main per PR #117); pnpm typecheck 0; pnpm lint:i18n-gate 0 ('COVERAGE : 0 missing keys across 2 locale(s)'). hotclm has no dispatch-gates derivation; CI is .github/workflows/ci.yml job Validate. PR check-runs on head d96e62a: Validate completed success (121188684364, push); Validate in_progress (121189074632, pull_request) at report time.",
"dogfood_battery": "n/a — no ! in the PR title and no (narrowing) arm",
"mcp_calls": "0",
"api_writes": "2 — (1) fleet-write relay pr_create (request fw-20261025T135742Z-29b1e5, run 40200001110 success): POST /repos/objectstack-ai/objectstack/dispatches -> relay POST /repos/objectstack-ai/hotclm/pulls (draft #122) + POST /repos//issues/122/assignees (zhuangjianguo); body read back 10157/10157 bytes identical. (2) this os-dev-report comment via post-stamped: POST /repos//issues/11/comments. Plus git push x1 of the branch (not REST).",
"open_questions": [],
"out_of_scope_findings": [
"carrier: the seat's #95 remainder · src/apps/clm.app.ts comments still name the retired bind-position-sets.ts twice (header 'Every position also holds clm_requester (bind-position-sets.ts)'; the executive_overview note in the Analytics group). Both are now doubly stale because the binding is the default set. Noted in PR #122 Acceptance notes, not filed.",
"carrier: 承接者:无 · three declared tokens (archive_contract, manage_clauses, manage_approval_rules) have no requiredPermissions consumer anywhere in src/ (git grep outside src/profiles: zero hits). Their capabilities: descriptions say 'DESIGN.md §04 action gate for …' and claim no button. Observation only, in PR #122 Acceptance notes."
]
}

Every member holds clm_requester by default; the app declares its ele…

Maintainer-action: merge PR #120 (governed DESIGN.md §04 gate × holder table — step 1 of this card's release; already edited there).

Landed — PR #122 · 2026-10-25T14:05Z

reading	value
PR #122	`MERGED`, squash `721f01c` on `main`, merged at its ACCEPT head `d96e62a`
authority	maintainer, project thread, verbatim: 「你可以自己审核的就自己合并」

Release: step 2 (PR #117) and step 3 (ruling 6398381229, letter A — PR #122: capabilities: block with the eleven app tokens, clm_requester isDefault: true, positions no longer name it) are delivered. Step 1 is governed text only, in PR #120. State: pm:dispatched → pm:awaiting-maintainer, assignee cleared; the seat closes this card when PR #120 merges (it carries Refs #11). The stale bind-position-sets.ts comments in src/apps/clm.app.ts go with the #95 remainder.

Generated by Claude Code

Sync the governed design text with the rulings landed on 2026-10-25

fix(console): an app that serves the caller no navigation opens on an…

Navigation Menu

Repository navigation

[Decision] `DESIGN.md` §04 makes `clm_requester` every employee's default, but a set that grants `clm_requester.access` cannot bind to `everyone` #11

维护者速读

Context

Options

四棱分析

Impact if deferred

第二问（PM 追加）：六个动作门控挂在哪些权限集上

第一问裁定：A —— 接受分发模型，缺口报到平台

⚠️ 第二问未裁，本卡因此不离开决策箱

裁后执行（仅第一问）

与 #28 的耦合，现已解开

第二问裁定：A —— 接受六个动作门控的持有者表

裁后执行（给 lane 席位）

7 remaining items

第 3 步裁定：A —— 声明全部 11 个能力令牌，`clm_requester` 标 `isDefault: true`，删掉七个岗位的额外绑定

裁后执行（给 lane 席位）

Landed — PR #122 · 2026-10-25T14:05Z

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Decision] DESIGN.md §04 makes clm_requester every employee's default, but a set that grants clm_requester.access cannot bind to everyone #11

Description

维护者速读

Context

Options

四棱分析

Impact if deferred

Activity

hotlong commented on Sep 7, 2026

第二问（PM 追加）：六个动作门控挂在哪些权限集上

zhuangjianguo commented on Sep 9, 2026

第一问裁定：A —— 接受分发模型，缺口报到平台

⚠️ 第二问未裁，本卡因此不离开决策箱

裁后执行（仅第一问）

与 #28 的耦合，现已解开

objectstack-fleet commented on Oct 9, 2026

zhuangjianguo commented on Oct 25, 2026

第二问裁定：A —— 接受六个动作门控的持有者表

裁后执行（给 lane 席位）

objectstack-fleet commented on Oct 25, 2026

objectstack-fleet commented on Oct 25, 2026

7 remaining items

zhuangjianguo commented on Oct 25, 2026

第 3 步裁定：A —— 声明全部 11 个能力令牌，clm_requester 标 isDefault: true，删掉七个岗位的额外绑定

裁后执行（给 lane 席位）

objectstack-fleet commented on Oct 25, 2026

objectstack-fleet commented on Oct 25, 2026

objectstack-fleet commented on Oct 25, 2026

Landed — PR #122 · 2026-10-25T14:05Z

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[Decision] `DESIGN.md` §04 makes `clm_requester` every employee's default, but a set that grants `clm_requester.access` cannot bind to `everyone` #11

第 3 步裁定：A —— 声明全部 11 个能力令牌，`clm_requester` 标 `isDefault: true`，删掉七个岗位的额外绑定