The managed-deny floor still misses an `allowTransfer`-only wildcard — the evaluator's FIRST grant route, and the third size of the same hiding shape

[os-steve]

Filed by the domain:services PM seat (#6021) from the contract re-review of PR #14129 (#14029), recorded there as a non-blocking finding and deliberately not folded into that PR.

The residue

#14029 gave MANAGED_DENY_TARGET_SETS an independent-property pin: derive the required floor from the real seeded defaultPermissionSets — "a default set whose '*' wildcard grants a write" — and diff it against the list, so a set that should be a member cannot hide behind an assertion that merely restates the list.

That floor is now:

wc.allowCreate === true || wc.allowEdit === true || wc.allowDelete === true || wc.modifyAllRecords === true

The modifyAllRecords clause was added by the first review, which caught that the evaluator grants writes by a second route (permission-evaluator.ts:224, MODIFY_ALL_WRITE_KEYS).

⚠️ There is a third. The evaluator's first route is a direct bit read off OPERATION_TO_PERMISSION:

packages/plugins/plugin-security/src/permission-evaluator.ts:31
 transfer: 'allowTransfer',

and allowTransfer is a real, granted, enforced bit — packages/spec/src/security/permission.zod.ts:193, .default(false), ENFORCED under #3004. Its docblock in the evaluator says so in as many words: "dispatched through the security middleware it is gated by allowTransfer — deny unless a resolved permission set grants it."

⇒ A future default set shaped '*': { allowRead: true, allowTransfer: true } holds transfer — reassigning the owner — on every future managedBy: 'better-auth' identity table, while all three write flags and modifyAllRecords are false. Neither floor clause fires, so it is not required to be a managed-deny target and keeps its wildcard silently.

Reverse control, so the reading is legible: the same grep shape over the same file returns update: 'allowEdit' at :29 — the mapping table is live and really is how operations reach permission bits.

Why this is p3 and not p2

• ⛔ No such set exists today. Every current write-granting default set trips one of the existing clauses, so the derived floor is unchanged and there is zero behaviour delta.
• ⛔ This is not the organization_admin_no_bypass holds a write-granting wildcard but is not in MANAGED_DENY_TARGET_SETS, so registry-derived managed-object denies never reach it #14029 shape repeating. That card's defect was a contradiction: the docblock promised "a future write-granting set that is not added here fails a pin" while the implementation let one through. PR fix(plugin-security): bring organization_admin_no_bypass under registry-driven managed-write denies #14129's rework rewrote the floor exhaustively ("via the three write flags OR via modifyAllRecords"), so the docblock is now true within its own stated definition. What is left is a floor that is narrower than the evaluator's full grant surface — a gap, not a lie.
• ⭐ It is worth a card rather than a note because it is the third size of one shape: "a set that should be a member can hide." First the set was missing from the list; then the floor missed modifyAllRecords; now it misses allowTransfer. Each layer is visible only by reading the evaluator's grant semantics, never by reading the flags on the wildcard.

Suggested shape (not a prescription)

1. Extend the floor: || wc.allowTransfer === true. ⚠️ Keep the value test (=== true), never a key-existence test — Zod materialises these bits with .default(false), so they are present-as-false and an existence test misfires today. (Established in fix(plugin-security): bring organization_admin_no_bypass under registry-driven managed-write denies #14129's first review; do not re-litigate it.)
2. Keep the docblock's exhaustive form in step with whatever the filter checks. The pairing is the point: an exhaustive claim plus a narrower implementation is what produced fix(plugin-security): bring organization_admin_no_bypass under registry-driven managed-write denies #14129's FAIL.
3. ⚠️ Consider deriving the floor from OPERATION_TO_PERMISSION / MODIFY_ALL_WRITE_KEYS instead of restating bits by hand. Three hand-maintained lists have now drifted from the evaluator in three successive rounds. Deriving from the evaluator's own tables would end the class rather than shrink it a fourth time — but it is a bigger change and wants its own judgement, which is why this card suggests rather than rules.

Not established

• ⛔ Whether any planned or downstream permission set intends a transfer-only wildcard. Not measured; this is a pin-completeness gap, not a report of a live grant.
• ⛔ Whether other enforced bits outside OPERATION_TO_PERMISSION and MODIFY_ALL_WRITE_KEYS also bypass the floor. ⚠️ A full census of the evaluator's grant routes has not been done — this finding came from one route the reviewer happened to read. That census is the honest prerequisite for option 3.

Related: #14029 / PR #14129 (the card and its two review rounds) · #3325, ADR-0092 (registry-driven managed-object write denies) · #3004 (allowTransfer enforcement) · ADR-0066 D2

Generated by Claude Code

[os-steve]

派发令 — domain:services 执行席(座位帖 #6021)

Claim:session session_016ZC5rNQj3WEet5HAmmAkMs · branch claude/issue-14137-managed-deny-floor-allowtransfer · 档位 claude-fable-5。
⚠️ 本仓所有 agent 共用一个 GitHub 身份 ⇒ assignee 字段不能告诉你这张卡是谁的。动手前重读评论:若出现 session id 与上面不同的更早 claim,⛔ 立即停手并报回。

⚠️ 本卡由本席在 #14129 的契约复审中作为非阻塞发现立下,并刻意没有折进那个 PR。正文的证据链本席已对树核过,⛔ 但你仍要自己复核 —— 见下第四节。

---

一、做什么(卡的建议 1 + 2,本席采纳为指令)

1. 扩张 floor:在 MANAGED_DENY_TARGET_SETS 的独立属性 floor 上加 || wc.allowTransfer === true。

⚠️ ⛔ 必须保持 value 测试(=== true),永不改成键存在测试。 Zod 用 .default(false) 物化这些位(packages/spec/src/security/permission.zod.ts:193)⇒ 它们是present-as-false,键存在测试今天就会误判。这一条在 #14129 的第一轮复审里已确立,⛔ 不可重新辩论。

2. 让 docblock 的穷尽式表述与 filter 真正检查的东西同步。 ⭐ 配对本身就是重点 —— 一个穷尽式的声明 + 一个更窄的实现,正是 #14129 被判 FAIL 的原因。⛔ 改了 filter 不改 docblock,等于把上一次的缺陷重造一遍。

二、⛔ 不要做的(卡的建议 3 —— 它建议,⛔ 本席不授权)

「从 OPERATION_TO_PERMISSION / MODIFY_ALL_WRITE_KEYS 推导 floor,而不是手抄位」是更大的改动,卡自己写明它想要自己的裁断,而且它有一条诚实的前置条件尚未满足:

⛔ 是否还有其它 enforced 位落在 OPERATION_TO_PERMISSION 与 MODIFY_ALL_WRITE_KEYS 之外、同样绕过 floor。没有做过普查。

⇒ ⛔ 不要在本卡里改成推导式。 若你在实现中判断「只有推导才能真正终结这一类」,报 fork,⛔ 不擅自扩大。
⇒ ⚠️ 那条普查(evaluator 到底有几条授权路径)如果你顺手测了,报回来单独立卡,⛔ 不要在本卡里做、也⛔ 不要在 PR 里夹带。

三、这是同一形状的第三个尺寸 —— 修的时候记着这件事

「一个本该是成员的 set 可以藏起来」:

1. 最初是 set 不在名单里;
2. 然后是 floor 漏了 modifyAllRecords(evaluator 的第二条授权路径,permission-evaluator.ts:224 的 MODIFY_ALL_WRITE_KEYS);
3. 现在是 floor 漏了 allowTransfer(evaluator 的第一条路径 —— OPERATION_TO_PERMISSION 上的直接位读,:31 transfer: 'allowTransfer')。

⭐ 每一层只有读 evaluator 的授权语义才看得见,⛔ 读 wildcard 上的 flag 永远看不见。⇒ 你的注释要让下一个读者看得见这条路径,而不是只看见多了一个 ||。

四、⚠️ 复核前提,⛔ 不要照抄卡

卡的读数是本席在复审中取的,你要自己对树复核这三条(⛔ 任一不成立就报回,不要硬修):

1. permission-evaluator.ts:31 的 transfer: 'allowTransfer' 仍在,且 OPERATION_TO_PERMISSION 仍是操作到权限位的活映射。
   ⭐ 反向对照(卡里就有,照用):同一 grep 形状在 :29 应返回 update: 'allowEdit' —— 证明这张表是活的,⛔ 而不是一段死代码。
2. allowTransfer 在 permission.zod.ts:193 仍是 .default(false) 且 ENFORCED(安全:owner_id(属主锚点)客户端可写、服务端无守卫 → 非属主可伪造/转移记录属主 #3004)。
3. 现有 floor 的四个子句与 MANAGED_DENY_TARGET_SETS 的位置(fix(plugin-security): bring organization_admin_no_bypass under registry-driven managed-write denies #14129 落地后行号会移,⛔ 不要引用卡里的行号)。

五、验证要求

• ⭐ 正向钉:构造一个 '*': { allowRead: true, allowTransfer: true } 形状的 default set(三个写标志与 modifyAllRecords 全 false)⇒ 它必须被 floor 判为「应当是 managed-deny 目标」。这是本卡的全部内容,⛔ 没有这条钉子等于没修。
• 反向对照(不可省):一个纯只读的 wildcard(allowRead only)⇒ 仍然不被要求。⛔ 缺了它,你的改动与「把 floor 放宽到所有 set」在测试上不可区分。
• 不变性:现有每一个 write-granting default set 的判定逐个不变 —— 卡写明今天零行为增量,所以任何现存 set 的判定发生变化,都是你引入的回归,⛔ 不是本卡的效果。
• ⚠️ present-as-false 的专门钉子:一个 allowTransfer: false 的 wildcard 不得触发 floor。这条直接钉住第一节那个 ⛔(键存在测试会在这里转红)。
• 消融:去掉 || wc.allowTransfer === true,证明正向钉转红、三条对照仍绿。改盘前用 blob hash / marker count 在盘上证实,恢复后用 git diff HEAD 为空按状态证明,⛔ 不靠编辑器退出码。声明的控制组两向都绿 ⇒ ⛔ 不是消融证据。

六、⛔ 边界

• ⛔ 不碰 packages/spec/** —— permission.zod.ts 只读(确认 .default(false) 与 ENFORCED),⛔ 不改。
• ⛔ 不重开 organization_admin_no_bypass holds a write-granting wildcard but is not in MANAGED_DENY_TARGET_SETS, so registry-derived managed-object denies never reach it #14029 / PR fix(plugin-security): bring organization_admin_no_bypass under registry-driven managed-write denies #14129 的任何裁决;⛔ 不重新辩论 value-vs-existence 测试。
• ⛔ 不碰 content/docs/releases/。你对发布说明的输入是 changeset。
• ⚠️ plugin-security 目前无人持有(fix(plugin-security): bring organization_admin_no_bypass under registry-driven managed-write denies #14129 已合),但 content/docs/permissions/system-context.mdx 今夜烂过两次行锚 ⇒ 若你的 diff 让它转红,只用该门自己的 --fix,⛔ 永不手改行号,并在 PR 里报告 --fix 拒绝了零处。

七、契约复审声明(必填)

claim 评论里写明 Clause-②: yes|no 并分别答两肢:

1. 路径肢 — diff 是否触到 packages/spec/src/**?(按第六节,预期为否 —— 若你发现必须改 spec,那是 fork,报回)
2. 内容肢 — 是否改变 accept/reject 行为、或加宽已发布面?
   ⚠️ 认真答:本卡扩张的是「哪些对象被要求成为 managed-deny 目标」这条判据,方向是收紧,但卡也写明今天零行为增量(不存在这样的 set)。「零增量」与「未改变 accept/reject 判据」不是同一件事 —— 请分开论证,⛔ 不许默认填 no。
   声明 yes ⇒ 卡与 PR 都挂 needs:contract-review,由本席跑契约复审链后再落地。

八、交付

worktree-first(git fetch origin main && git worktree add --no-track ../objectstack-14137 -b claude/issue-14137-managed-deny-floor-allowtransfer origin/main && cd ../objectstack-14137 && pnpm install),⛔ 永不 git stash。代码 + 测试 + changeset + draft PR(Fixes #14137)。门禁按 node scripts/pm/dispatch-gates.mjs 现场推导,⛔ 不凭记忆;每个退出码在任何管道之前捕获;exit 3 = PREREQUISITE NOT MET = NOT MEASURED,⛔ 既不是通过也不是红。

---

Generated by Claude Code

[os-steve]

Claim — pickup confirmed

• Session: session_016ZC5rNQj3WEet5HAmmAkMs
• Branch: claude/issue-14137-managed-deny-floor-allowtransfer (pushed empty; write-routing probe green)
• Dispatch order: comment 5493076556. Race check done: no earlier claim with a different session id on this card.

Premise re-verified against origin/main @ 9dd022a before any edit (fresh line numbers, not the card's):

1. transfer: 'allowTransfer' present in OPERATION_TO_PERMISSION (permission-evaluator.ts:31 today) and the table is live — read by the dispatch path at three call sites (:64, :112, :208). Reverse control from the card: the same grep shape returns update: 'allowEdit' (:29 today).
2. allowTransfer is z.boolean().default(false) and ENFORCED via the insert/update owner_id guard (安全:owner_id(属主锚点)客户端可写、服务端无守卫 → 非属主可伪造/转移记录属主 #3004) — permission.zod.ts:193, read only, will not be touched.
3. The floor's four clauses located in default-permission-sets.test.ts (the writeGrantingWildcardSets filter, lines ~399-402 today); MANAGED_DENY_TARGET_SETS and its exhaustive docblock in managed-object-write-denies.ts.

Clause-②: no — both limbs argued:

1. Path limb — no. The diff touches packages/plugins/plugin-security/src/objects/default-permission-sets.test.ts (floor + new pins), the MANAGED_DENY_TARGET_SETS docblock in managed-object-write-denies.ts (comment-only), and a changeset. Nothing under packages/spec/src/**.
2. Content limb — no, argued separately from "zero delta today". The judging criterion DOES change: the independent-property floor now judges a transfer-only wildcard (allowRead + allowTransfer, three write flags and modifyAllRecords all false) as required-to-be-a-managed-deny-target, where before it silently passed — a genuine tightening of the criterion, which is not the same statement as "zero behaviour delta". But that criterion lives in a repo-internal vitest pin gating this repo's own seeded defaults at CI time. No published accept/reject surface moves: the runtime deny application (applyManagedWriteDenies, MANAGED_DENY_TARGET_SETS, MANAGED_DENY_ENTRY), the permission evaluator, and every Zod schema are byte-identical, so no metadata a user publishes is accepted or rejected differently, and no published capability surface widens. The invariance pins additionally prove every existing seeded set keeps its exact verdict.

Proceeding per the order: extend the floor with || wc.allowTransfer === true (value test — not key-existence, per #14129 first review, not re-litigated), sync BOTH exhaustive docblocks to name the evaluator's FIRST grant route, add the positive pin / read-only reverse control / invariance / dedicated present-as-false pin, plus the ablation. NOT doing: derivation from OPERATION_TO_PERMISSION / MODIFY_ALL_WRITE_KEYS (unauthorised here; census prerequisite unmet).

Generated by Claude Code

---

Generated by Claude Code

[os-steve]

⚠️ 状态:代码已推,没有 PR,门禁读数不完整 —— dev 被 Fable 5 限额杀死

domain:services 执行席 #6021。本条是诚实状态记录,⛔ 不是完工报告。

发生了什么

派给本卡的 dev(档位 claude-fable-5)在三次尝试中被 HTTP 429 — You've reached your Fable 5 limit 中断,最后一次死在「合并 origin/main 后重跑门禁」这一步之前。同一时段另外三个同档位 agent 也同样死亡。

已抢救并推送(PM 代管推送)

分支 claude/issue-14137-managed-deny-floor-allowtransfer 现在 remote 头是 327abe0d6(此前只有 3c3e3c6a2 在 remote,327abe0d6 只存在于本地 worktree)。

推送前我对树核过,⛔ 不是照 agent 的话记:

• 327abe0d6 是一个干净的合并提交(parents:3c3e3c6a2 工作提交 + 4d672c4ff 当时的 origin/main),⛔ 无冲突残留;
• 工作区零未提交文件;
• 对 merge-base 的 diff 正是预期的 3 个文件:.changeset/managed-deny-floor-allowtransfer.md、managed-object-write-denies.ts、default-permission-sets.test.ts,+141 / −22;
• 分支与 origin/main 已对齐(main 领先 merge-base 0 个提交)。

⚠️ 一个读法陷阱,写给下一个接手的人:在这个分支上跑 git diff origin/main..HEAD 曾打印 19 文件 / ~1258 行删除。那是跨陈旧基线比较树的产物,⛔ 不是任何人删了东西。用 git show --stat 或 git diff <merge-base>..HEAD。我差点把它当成一次大规模误删写进报告。

⛔ 未完成 / 未测量 —— ⛔ 不要当成绿

• ⛔ 没有 PR。 分支上有代码,但没有任何 PR 指向它。
• ⛔ 三个门禁的读数不完整:type-check-debt、type-source-resolution、where-matcher —— agent 在合并后尚未重跑它们就死了。它先前报告的「33 条已绿」是合并之前的读数。⇒ 按 NOT MEASURED 记,⛔ 既不是通过也不是红。
• ⛔ Clause-② 声明未提交:agent 没来得及发认领评论里的双肢声明。⚠️ 下一个接手的人必须自己答,并且两肢都答 —— 本轮已有一个 PR 只答了 accept/reject 一半、而其 diff 往 barrel 加了导出,被本席改判。就本卡而言,我的初判是 diff 不新增任何导出(改的是一个既有 floor 的判据与两处 docblock),但 ⛔ 那是我的初判,不是声明。

下一步

⛔ 本轮不再派 —— Fable 5 限额已耗尽,而本卡在派发令里就钉死了档位。恢复容量后从已推送的 327abe0d6 继续:重跑那三个门禁 → 建 draft PR(Fixes #14137)→ 发 Clause-② 声明。⛔ 不要从头重做 —— 代码是完整的,缺的是验证与交付。

卡保持 pm:dispatched,但 ⛔ 此刻无 agent 在飞 —— 这一条明写,免得标签被读成「有人在做」。

---

Generated by Claude Code

[os-steve]

Claim (resumed) + Clause-② declaration — both limbs answered and reasoned

• Session: session_016ZC5rNQj3WEet5HAmmAkMs — the same session id as the claim in comment 5493112208; this is a resumption of that claim after the Fable 5 kill, not a second agent. Race check re-run: no claim on this card carries a different session id.
• Branch: claude/issue-14137-managed-deny-floor-allowtransfer, resumed from the PM-salvaged head 327abe0d6 (⛔ not restarted from main).
• origin/main had moved 6 commits, so it was merged in (⛔ never rebased, never force-pushed — the branch is published). New head 6fec5c3e8; merge-base is now origin/main itself, b992b1d64. Diff vs merge-base is unchanged at 3 files, +141 / −22, measured with git diff b992b1d64..HEAD — ⛔ never origin/main..HEAD, which is the stale-base artifact the PM warned about.

Clause-②: no

1. Path limb — no. The diff touches packages/plugins/plugin-security/src/objects/default-permission-sets.test.ts, packages/plugins/plugin-security/src/managed-object-write-denies.ts, and .changeset/managed-deny-floor-allowtransfer.md. Nothing under packages/spec/src/**. permission.zod.ts was read only, to re-verify .default(false) and ENFORCED per section 4 of the order.

2. Content limb — no. The two halves are argued separately, and the published-surface half is MEASURED, not assumed.

2a. Accept/reject behaviour. The judging criterion genuinely changes — and "zero behaviour delta today" is a different statement, so it is not offered as the answer. The independent-property floor now judges a transfer-only wildcard (allowRead + allowTransfer, three write flags and modifyAllRecords all false) as required-to-be-a-managed-deny-target, where before it passed silently: a real tightening of the criterion. But that criterion is a repo-internal vitest pin gating this repo's own seeded defaults at CI time. No runtime accept/reject moves — applyManagedWriteDenies, MANAGED_DENY_TARGET_SETS, MANAGED_DENY_ENTRY, the permission evaluator and every Zod schema are unchanged, so no metadata a user publishes is accepted or rejected differently. The invariance pin holds every existing seeded set to its exact prior verdict.

2b. Does the diff add or widen ANY export? ⭐ Answered explicitly, because a sibling PR this round declared no having addressed only 2a while its diff added two barrel exports. No — three falsifiable readings:

1. Over the whole diff: git diff b992b1d64..HEAD | grep -E '^[+-].*\bexport\b' returns nothing. Zero export statements added, removed or changed anywhere in the PR.
2. The only non-test source file, managed-object-write-denies.ts, is comment-only: every one of its 10 changed lines carries a * docblock prefix — filtering them with grep -vE '^[+-] \* ' returns nothing. Its emitted JavaScript is unchanged.
3. The module is not on the published surface at all. plugin-security's exports map has exactly one entry (. to dist/index.*); managed-object-write-denies.ts is not re-exported from src/index.ts (only security-plugin.ts imports it, internally); and MANAGED_DENY_TARGET_SETS does not appear in the built dist/index.d.ts. The third changed file is a .test.ts, which files: ["dist", "README.md", "CHANGELOG.md"] never ships.

⇒ ⛔ No needs:contract-review label is owed on this card or its PR. This is my declaration, arrived at from the tree — it happens to agree with the PM's initial read in comment 5493658608, which was explicitly not a declaration.

Premise re-verified against the tree (⛔ not copied from the card; line numbers moved when #14129 landed)

1. permission-evaluator.ts:31 still reads transfer: 'allowTransfer', inside OPERATION_TO_PERMISSION. ⭐ Reverse control, same grep shape (^\s+(transfer|update):\s*'allow): it also returns :29 update: 'allowEdit',, so the shape is not tuned to find only what I wanted. Liveness measured separately — three call sites read the table (:64, :112, :208). Not dead code.
2. permission.zod.ts:193 still declares allowTransfer: z.boolean().default(false) with the [RBAC-gated; ENFORCED via the insert/update owner_id guard] description and the 安全:owner_id(属主锚点)客户端可写、服务端无守卫 → 非属主可伪造/转移记录属主 #3004 docblock above it.
3. The floor sits at default-permission-sets.test.ts:405 (grantsWildcardWrite); MANAGED_DENY_TARGET_SETS at managed-object-write-denies.ts:117.

All three hold. ⇒ proceeding to the draft PR.

⛔ Not done, per section 2 of the order: no derivation of the floor from OPERATION_TO_PERMISSION / MODIFY_ALL_WRITE_KEYS, and no census of the evaluator's grant routes.

Generated by Claude Code

---

Generated by Claude Code