Permission-set resolution binds by POSITION NAME while sys_position_permission_set sits near-empty — confirm name-based resolution is the intended mechanism, not an accident the empty junction hides

[baozhoutao]

Filed at destination by the repo:cloud execution seat (objectstack#6026, session session_01EzWYDkwr6WEwDGhMH1Jzuq, R22) from the cloud#1628 verification run's handed-up observations. Filed unassigned and ungraded — domain:*/type are central triage's to mint (expected territory: the RBAC resolver, domain:services family).

The observation (measured on cloud's walled rig at cloud pin 1a540e82, composed HotCRM artifact)

• sys_position_permission_set holds exactly one row per organization: everyone → member_default. No HotCRM position binds any HotCRM permission set through the junction table.
• Yet the sales_manager permission set resolves onto a principal who holds the sales_manager position: after a user→position assignment through Setup, /api/v1/security/explain shows both positions: [... "sales_manager" ...] and permissionSets: ["sales_manager", ...] — with no junction row connecting them.

⇒ Resolution appears to bind a position to a same-named permission set by name, and the junction table is nearly inert on this shape.

The question

Is name-based binding the declared mechanism (in which case: where is it declared, and what is sys_position_permission_set for — an override? an addition? dead?), or is it a fallback that the near-empty junction table is silently exercising as the primary path? Either way the current state invites a wrong read: an operator or an app author inspecting the junction table sees "no bindings" while bindings are in force, and an app that names a position differently from its permission set may get no binding at all with nothing saying so. Declared-vs-enforced discipline wants one authoritative answer.

Re-check

On any walled rig with the composed HotCRM artifact: assign a user to sales_manager through Setup, then compare /api/v1/security/explain for that principal against SELECT * FROM sys_position_permission_set. cloud's scripts/dev-local/verify-position-surface.mjs (cloud PR #1760) automates the surrounding steps.

[claude]

分诊定级 · 首次定级 · security · p1 · domain:services · needs-user-decision

⚠️ 本卡自 11:15 起零标签。立卡人(repo:cloud 执行席位)明写「domain:*/type 由中央分诊铸造,预期落 domain:services 家族」—— 本席确认该预期正确:RBAC 解析面在 lanes/services.md 的身份侧。

为什么是决策卡而不是队列卡

卡问的是一个意图问题,不是一个缺陷:

位置(position)与同名权限集(permission set)之间的绑定按名字发生,而 sys_position_permission_set junction 表每组织只有一行(everyone → member_default),没有任何 HotCRM position 通过它绑定过。

两种可能的世界,分诊无权替维护者选:

1. 按名解析是有意设计 ⇒ junction 表是遗留/未启用面,应当被记录清楚(否则下一个人会以为它是权威);
2. 按名解析是意外 ⇒ 那么它是一条静默授权路径:建一个与既有 position 同名的 permission set,即可让持有该 position 的所有主体获得它 —— ⛔ 没有任何 junction 行、没有任何显式授予动作。

⇒ 世界 2 是权限提升向量,所以定 p1 + security;而 1 与 2 的区别是意图,撞人工地板(lanes/services.md 红线:安全/权限边界,恒升级不代裁)。

证据级别(够格入决策箱)

在 cloud 的隔离台架上实测(cloud pin 1a540e82,composed HotCRM artifact):/api/v1/security/explain 同时显示 positions: [… "sales_manager" …] 与 permissionSets: ["sales_manager", …],而两者之间没有 junction 行。⇒ 现象已测,缺的只是意图。

给裁决者的最小提问

同名绑定是设计,还是 junction 表未接线的副作用?
若是设计:junction 表的角色要写进文档,并给出「同名即授予」的显式说明;
若是意外:需要一次授权面普查(哪些组织已因同名而实际获得了未显式授予的权限集)。

⚠️ 后者的普查必须在裁决后进行,⛔ 分诊不预跑 —— 它需要读生产授权数据,超出本席范围。

本轮实测(R+58 新口径)

本卡引用的 cloud 面本轮可达:GET /repos/objectstack-ai/cloud 200,open_issues 65。⚠️ 但 git ls-remote 仍 128 ⇒ 代码面读不到,本席未能核对 cloud 侧源码,以上仅据卡面与本仓车道表判定。

---

Generated by Claude Code

[hotlong]

⚖️ RULED — 维护者,2026-08-31,总监席第 5 场决裁批 #1,verbatim 「同意」(采本席推荐 B)

裁定:治理侧胜出 —— sys_position_permission_set junction 成为职位→权限集的唯一绑定通道,按名折叠通道退役。 依据平台元判据(一个操作两个实现且行为不一致 ⇒ 带治理的一侧默认胜出,另一侧改绑并删除——留着未治理侧等于给权限闸留旁路)。

实体认定(本席实读 origin/main):junction 通道真实在用(resolve-authz-context.ts §6a 按 position id 读取);按名通道 = plugin-security/src/security-plugin.ts:4638 的 requested = [...positions, ...explicitPermissionSets],把职位名直接折进权限集名单——无声明、无审计行、无治理;上游停用清扫的注释自证知情(「名字留着就会在下一层解析出同一授予」)。

执行要点(顺序即依赖):

1. 普查先行:census 全部依赖同名解析的绑定(仓内种子/内置集/示例与 composed app 工件;已知 everyone→member_default 有 junction 行、HotCRM sales_manager 靠同名),带正对照;
2. 物化:把普查出的合法依赖生成 junction 行(seed / app install 时),⛔ 不物化不删折叠;
3. 删折叠 + 发布/lint 门对「permission set 名与 position 名撞车且无 junction 行」响亮告警;
4. 隐式授予审计报告:普查已因同名而实际生效、且无 junction 行的授予,逐组织列出供维护者复核;
5. 方向必须响亮:任何行为差异只能表现为拒绝/告警,⛔ 永不静默改变解析结果;bypassTenantAudit 式的静音不适用于此。

条款②预判:安全行为变更、控制即本裁决(人工地板已走),内容肢不触发;路径肢按实际 diff。

状态转换(同笔):摘 needs-user-decision → pm:queue。席位边界:裁不派,派发归 domain:services 车道。

---

Generated by Claude Code

[os-steve]

Claim: PM loop round 8 — slice 1 of the ruling: 普查 + 隐式授予审计报告(执行要点 1 与 4)
Session: session_016ZC5rNQj3WEet5HAmmAkMs
Branch: claude/issue-13419-name-fold-census
Worktree: objectstack-issue-13419
Domain: domain:services
File surface: a census/audit script under scripts/ + its self-test, and read-only measurement across packages/** seeds/built-ins/examples. ⛔ No behaviour change in this slice (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: claude-opus-5 — judgement tier. This slice is measurement and reporting; the heavy judgement (materialise, delete the fold) is later slices and will be priced then.
Clause-②: no, for this slice — a census script changes no contract and no public surface. ⚠️ The ruling's own prediction ("安全行为变更、控制即本裁决…路径肢按实际 diff") applies to the later slices; re-declare at that point, ⛔ not here.
Serial constraints cleared: ⛔ packages/plugins/plugin-security/src/security-plugin.ts is HELD by PR #13514 (#11974, open draft parked on contract review) — that file is where 执行要点 3 ("删折叠", line 4638) must eventually land, and it is not available now. ⛔ Also held: service-messaging/** + plugin-webhooks/** + service-automation/builtin/http-nodes.ts (PR #13565, red, patch round in flight). ✅ Free and just landed: plugin-security/rls-compiler.ts (PR #13570 MERGED as 09b0d7b), service-storage/** (PR #13572 MERGED as d475838).

Why this dispatch is slice 1 only — the ruling forces the order

The ruling's 执行要点 are labelled 「顺序即依赖」, and two independent facts make anything beyond the census undispatchable right now:

1. ⛔ The ruling itself forbids it: 「⛔ 不物化不删折叠」 — the fold may not be deleted before the legitimate dependencies it carries have been materialised as junction rows, and they cannot be materialised before the census names them.
2. ⛔ The file is fenced: 执行要点 3 lands at security-plugin.ts:4638, held by PR feat(plugin-security): walled bootstrap stops minting the platform-admin grant row; platformAdmin audit service; legacy-grant deprecation pointer (L4) #13514.

⇒ Dispatching 普查 (要点 1) + 隐式授予审计报告 (要点 4). Both are measurement and reporting; neither changes resolution behaviour, which 要点 5 requires stay unchanged until the loud version ships.

裁决 — 不可重裁 (维护者,2026-08-31,总监席第 5 场决裁批 #1,verbatim「同意」)

治理侧胜出 —— sys_position_permission_set junction 成为职位→权限集的唯一绑定通道,按名折叠通道退役。 依据平台元判据:一个操作两个实现且行为不一致 ⇒ 带治理的一侧默认胜出,另一侧改绑并删除 —— 留着未治理侧等于给权限闸留旁路。

裁决者实读 origin/main 的实体认定(⛔ 不重新论证,但必须重新定位 —— 见下):

• junction 通道真实在用:resolve-authz-context.ts §6a 按 position id 读取;
• 按名通道 = plugin-security/src/security-plugin.ts:4638 的 requested = [...positions, ...explicitPermissionSets] —— 把职位名直接折进权限集名单,无声明、无审计行、无治理;
• 上游停用清扫的注释自证知情(「名字留着就会在下一层解析出同一授予」)。

⚠️ 行号会腐烂,而且本仓今夜已合并多笔。 按符号重新定位 requested = [...positions, ...explicitPermissionSets],⛔ 不按行号。

本刀的交付物

要点 1 — 普查(带正对照):枚举全部依赖同名解析的绑定。范围由裁决点名:仓内 seeds / 内置权限集 / examples 与 composed app 工件。已知两个锚点可作为正负对照:

• everyone → member_default —— 有 junction 行(正对照:普查必须把它认成 junction 绑定,⛔ 不能误报成同名依赖);
• HotCRM sales_manager —— 靠同名(正对照:普查必须把它认出来)。

⚠️ 一个零命中若没有反向对照就不是读数。普查脚本必须自带 self-test,像 scripts/measure-durability-swallow-family.mjs 那样:先证明它能在已知样本上命中,再报数。

要点 4 — 隐式授予审计报告:逐组织列出「已因同名而实际生效、且无 junction 行」的授予,供维护者复核。⚠️ 这是裁决明确要给维护者的产物,⛔ 不是附带品。

PM 机制假设 —— 请实测,我宁可被证伪

1. 同名折叠只有 :4638 一处。 裁决点名了一处;若解析链上还有第二处按名折叠(或另一个包里有同形),报上来 —— 那会改变「删折叠」的范围,而这一刀正是为了在动手前把范围测准。
2. 仓内可完成普查。 已知依赖同名的例子(HotCRM sales_manager)来自 composed app artifact,可能不在本仓。若仓内枚举无法覆盖裁决要求的范围,说清楚哪一半测不到、需要谁去测,⛔ 不要用仓内样本冒充全量,也 ⛔ 不要凭空构造一个 fixture 当作生产读数。
3. 「隐式授予」可从仓内数据判定。 要点 4 说「逐组织」——组织是部署侧概念。若这份报告本质上需要跑在真实部署上,那么这一刀能交付的是报告的生成器 + 在测试装置上的验证,而运行归运维。如实报告这个分界,⛔ 不要把空库的零行写成「无隐式授予」。⚠️ 这正是本车道另一张 p1([Decision] Override-recall of a returned approval: an ADR-0044 side effect to retire, or a capability to keep? The gate, the prose and the viewer flag disagree three ways #12775)此刻卡住的同一形状 —— 空库的零和真零在查询上分不出。

⛔ 本刀的硬边界

• ⛔ **不改任何解析行为。**要点 5:任何行为差异只能表现为拒绝/告警,永不静默改变解析结果 —— 而本刀连告警都不加,只测量。
• ⛔ **不删折叠、不物化 junction 行。**那是要点 2/3,依赖本刀的产出,且其落点文件当前被 PR feat(plugin-security): walled bootstrap stops minting the platform-admin grant row; platformAdmin audit service; legacy-grant deprecation pointer (L4) #13514 持有。
• ⛔ **不碰 security-plugin.ts。**读它,不改它。

Gates

从你自己的 worktree 在 origin/main 上、按实际 diff 重新推导:node scripts/pm/dispatch-gates.mjs <changed paths>。⚠️ main 今夜已前进数笔(09b0d7b、d475838 等),⛔ 不用记忆中的门禁族清单。

Report

终报先作为本卡评论落地,再作返回消息。只收机器可核字段;⛔ 不复述 PR 叙事。普查数字必须带正对照,并把「测得到 / 测不到」的分界写清楚 —— 下一刀的 PM 拿它当账本。

---

Generated by Claude Code

[os-steve]

Claim (dev): slice 1 — 普查 + 隐式授予审计报告 (执行要点 1 + 4)
Session: session_016ZC5rNQj3WEet5HAmmAkMs
Branch: claude/issue-13419-name-fold-census (pushed empty at base eb64351)
Worktree: objectstack-issue-13419
Domain: domain:services · dispatched by the domain:services PM seat, round 8

File surface: a census/audit script under scripts/ plus its self-test; read-only measurement across packages/** (seeds, built-in permission sets, examples). ⛔ No resolution behaviour change in this slice — not even a warning (执行要点 5 requires behaviour stay unchanged until the loud version ships).

Fences respected: ⛔ packages/plugins/plugin-security/src/security-plugin.ts (held by PR #13514) is read-only for me — 执行要点 3 lands there and is not part of this slice. ⛔ service-messaging/**, plugin-webhooks/**, service-automation/src/builtin/http-nodes.ts (PR #13565) untouched.

⛔ Not touching assignees or labels (PM-owned).

---

Generated by Claude Code