@@ -0,0 +1,12 @@
+---
+'@objectstack/platform-objects': patch
+'@objectstack/plugin-auth': patch
+---
+
+Fix `POST /api/v1/auth/admin/remove-user`, which could never succeed and left the identity un-authenticatable when it failed.
+
+Three compounding problems on the better-auth admin removal path:
+
+- **`sys_member.user_id` declared no `deleteBehavior`.** A `lookup` defaults to `set_null`, and the engine escalates a defaulted `set_null` on a REQUIRED foreign key to `restrict` — so the membership every user gets at sign-up (and, since the invitation-adoption change, keeps after accepting an invitation) vetoed every `sys_user` delete. The field now declares `deleteBehavior: 'cascade'`. The last-administrator invariant is unaffected: it is enforced by a `beforeDelete` hook on `sys_member`, and the engine's cascade recurses through the public `delete()`, so that hook still runs.
+- **The removal was not atomic.** better-auth deletes the sessions, then the accounts, then the user, in three calls with no transaction, so anything refusing the last one left the credential rows deleted and the user row behind — an identity still on the org roster that can no longer sign in. Subject-erasure requests now run inside one engine transaction and roll back as a unit. Datasources whose driver has no transaction support keep the previous behaviour and log the engine's existing warning.
+- **A referential refusal reached the client as an HTTP 500 with an empty body.** The auth adapter mapped engine validation errors and policy refusals to better-auth `APIError`s but not referential ones, so a `DELETE_RESTRICTED` escaped unmapped. It now surfaces as a structured 409 carrying the dependent object, the dependent count and the remedy.
@@ -40,7 +40,7 @@ metadata:
 | `repo:<owner/name>` | 扫哪个仓的 backlog(单 issue 的落地仓看它自己的 `repo:*` 标签) | `objectstack-ai/objectstack` |
 | `batch:<n>` | 同时在飞的 dev 上限 | `3` |
 | `rounds:<n>` | 跑 N 轮后停 | 队列清空为止 |
-| `mode:subagent` \| `mode:cloud` | 派发后端 | 按卡分流:M+ ⇒ `cloud`,S 级机械 ⇒ `subagent`(维护者 2026-08-10 裁定) |
+| `mode:subagent` \| `mode:cloud` | 派发后端 | 按卡分流:S+M ⇒ `subagent`,`cloud` 只留 L/XL 等保留面(维护者 2026-08-12 裁定) |
 | `#12 #34 …` | 显式 issue 清单,整体覆盖标签查询 | — |
 
 无角色参数时按执行姿态运行,车道由座位贴认定。角色参数的意义:座位 Routine 的prompt 收敛成一行
@@ -220,15 +220,16 @@ UI 创建并勾 GitHub 连接器、UI 钉模型(会话内 create_trigger 的Rout
 ## 座位贴协议(一座位一贴,单写手)
 
 多写手共编一个 body 机制上防不住互吞(维护者 2026-08-06 拍板):**贴 = 座位**(标签`pm:seat`),正
-文固定六段现值(**范围 | 当前 PM | 继承台账 | 热文件串行队 | 常设承诺
-| 说明**,没有一段随时间增长),**只由在任座位 PM 编辑**,正文为权威 —— 标题
-(`[PM seat] <座位名> — <状态>`)与 assignee 是它的派生视图,三者同笔更新。接管/移交 = 改正
-文 + 一条审计评论,**评论只作审计不承载状态**;接管压缩是标准步骤(按六段模板重述现值,编辑历史
-即存档)。**热文件串行队是正文具名段**(文件 → 有序卡片清单 → 每张卡认领的区域;区域写不清就只
-能整文件串行)。无心跳,活性惰性判定(只在接管冲突时评估,会话座位 >24h 无产出可回收);每轮巡检核
-对自己的贴;竞态(空缺争用)三招 —— 动手前重 fetch 正文、审计评论时间戳先到先得、写后回读。状态
-词表、接管/退场收尾清单等细则见 `references/seat-post-protocol.md`;epic 委托不入座位贴体系
-;`packages/spec`恒归 spec 座位。
+文固定六段现值(**范围 | 当前 PM | 继承台账 | 热文件串行队 | 常设承诺 | 说明**,没有一段随时间
+增长),**只由在任座位 PM 编辑**,正文为权威 —— 标题(`[PM seat] <座位名> — <状态>`)与
+assignee 是它的派生视图,三者同笔更新。接管/移交 = 改正文 + 一条审计评论,**评论只作审计不承载
+状态**;接管压缩是标准步骤(按六段模板重述现值,编辑历史即存档)。**读侧闭环(维护者 2026-08-12
+批准):接管与巡检只读贴正文 + 晚于正文最后编辑的评论** —— 更早的已被那次编辑吸收,是存档不是现
+状。**热文件串行队是正文具名段**(文件 → 有序卡片清单 → 每张卡认领的区域;区域写不清就只能整文
+件串行)。无心跳,活性惰性判定(只在接管冲突时评估,会话座位 >24h 无产出可回收);每轮巡检核对自
+己的贴;竞态(空缺争用)三招 —— 动手前重 fetch 正文、审计评论时间戳先到先得、写后回读。状态词表
+、接管/退场收尾清单等细则见 `references/seat-post-protocol.md`;epic 委托不入座位贴体系
+;`packages/spec` 恒归 spec 座位。
 
 ## Epic 子树车道
 
@@ -381,13 +382,13 @@ dev 侧推分支要早 —— 远程分支是在飞工作最硬的证据。**Sta
 还需要考虑的是派任务时使用什么模型,也应该项目经理决定,最低下限sonnet,最高可以 fable」;「比
 如 更新 项目经理技能 必须要使用 Fable 5」。政策:**派发模型是 PM 的逐卡显式决定** —— 下
 限 `sonnet`(机械卡:正确性由门禁农场机械判定,失败模式是漏跑门不是判断失误);默认判断
-档 `opus`(M/L、裁决实施、多面语义、任何带设计判断的卡;拿不准就升一档 —— 错派低档的返工贵过省
-下的额度);上限 `fable`(交付物本身是协议/流程/编排结构的最重卡,按卡取用不是新默认)。**⛔ 强制
-条款(无向下裁量权):凡改 `.claude/skills/pm-dispatch/**` 的卡,一
-律 `model: "claude-fable-5"` 派发。**档位**逐次派发显式传参,永不省略**(解析顺序:环境变
-量 → 派发参数 → 定义frontmatter → 主会话模型;pin 只管什么都不传的情形;被允许名单挡下时回退**
-继承的模型**,正是 pin 要防的静默继承),连同尺寸写进认领评论「Container & model」行;分诊
-suggestion 行是输入不是决定,不采纳给一句理由。
+档 `opus`(M/L、裁决实施、任何带设计判断的卡;拿不准就升一档 —— 错派低档的返工贵过省下的额度)
+;上限 `fable`(交付物本身是协议/流程/编排结构的最重卡,按卡取用不是新默认)。**⛔ 强制条款(无
+向下裁量权):凡改 `.claude/skills/pm-dispatch/**` 的卡,一律 `model: "claude-fable-5"` 派发。
+**档位**逐次派发显式传参,永不省略**(解析顺序:环境变量 → 派发参数 → 定义 frontmatter → 主会
+话模型;pin 只管什么都不传的情形;被允许名单挡下时回退**继承的模型**,正是 pin 要防的静默继承)
+,连同尺寸写进认领评论「Container & model」行;分诊 suggestion 行是输入不是决定,不采纳给一句
+理由。
 
 **派发词原则(构造细则与条款原文见 `references/dispatch-runbook.md`)。** ⛔ 默认不整段粘
 贴 issue 正文 —— 让 dev 自己读 GitHub 全文与全部评论,并**必须**要求 dev 自查正文完整性(截断
@@ -412,23 +413,22 @@ suggestion 行是输入不是决定,不采纳给一句理由。
 - **Premise-first 写明**:issue 正文是线索不是规格;`premise_still_valid: false` +无 PR 是合法
   且常常有价值的交付 —— 派发词预设 issue 为真,就把好运行变成表面抗命。
 
-**资源与后端。** 并行 agent 共享一个容器,内存峰值来自 build+test(os-dev 定义已强制验证锁
-/heap 上限/scoped filter/收尾清理);build 重的降 `batch:2` 或走`mode:cloud`;OOM 死的单独重派
-。**M 及以上默认云卡**(维护者 2026-08-10 裁定,原话:「确认,M 及以上默认云卡」):M+ ⇒
-`mode:cloud` 独享容器,⛔ 不混共享批次;只有 S 级**机械**卡留 `mode:subagent`;S 级但不机械(判
-断面在设计不在门禁)按 M 待遇 —— 尺寸不是档位的充分判据。判定连同档位写进认领评论。
-
-**云卡四课**(细则见 `references/dispatch-runbook.md`;一次性云卡用`create_session`,⛔ 不
-用 create_trigger+fire —— 维护者 2026-08-07 拍板,trigger 流只留给定时/重复型):① 授权面
-随 source 不随环境(带 `source_url` + `outcome_branch` +显式 `model` + 车道名开头
-的 `title`);② 派发词必带**自驱条款**(⛔ 不为提问/中期汇报结束回合;合法回合终点只有推送完
-成 + 终报,或硬阻塞详报);③ 交付通道 = dev 自开draft PR + 终报以 issue 评论交付;④ **云卡 draft
-PR 一存在立即`subscribe_pr_activity` —— 硬步骤**(未订阅的云卡 PR 是轮询负债)。CCR 云会话不注
-册跨会话消息 roster —— `SendMessage` 直投 not-reachable 是设计而非故障(维护者2026-08-11 裁定
-:事件驱动架构即长期方案),⛔ 不复测 roster 路径。**接手中断的dev**:先试 SendMessage 复活
-,resume 不可用才走 worktree 接手协议(细则同上表)——⛔ 不重跑原派发词;worktree 不新建;
-逐 hunk 读既有工作再决定;验证完整重跑; assignee/认领评论/分支全不动(既有认领的延续,不是新认
-领)。
+**资源与后端(维护者 2026-08-12 裁定:中级卡改子 agent、模型由 PM 按难度逐卡指定;覆盖
+2026-08-10 的「M 及以上默认云卡」)。** S 级机械 + M ⇒ `mode:subagent`(PM 容器内并行,档位按
+Model tiering 显式传参);S 级但不机械(判断面在设计不在门禁)按 M 待遇。`mode:cloud` 只保留给
+:L/XL、必须活过 PM 会话的工作、浏览器/dogfood 验证、以及逐卡判断的 build 重 M 卡(争用只来
+自 build+test,docs/指令类 M 卡碰不到;论证见 `references/dispatch-runbook.md`)。**归档义务只
+落在云卡**(遗忘容器面随之收窄到 L 级派发);OOM 死的单独重派;判定连同档位写进认领评论。
+
+**云卡四课**(细则见 `references/dispatch-runbook.md`;一次性云卡用 `create_session`,⛔ 不用
+create_trigger+fire —— 维护者 2026-08-07 拍板,trigger 流只留给定时/重复型):① 授权面随
+source 不随环境(带 `source_url` + `outcome_branch` + 显式 `model` + 车道名开头的 `title`)
+;② 派发词必带**自驱条款**(合法回合终点只有推送完成 + 终报,或硬阻塞详报);③ 交付通道 = dev
+自开 draft PR + 终报以 issue 评论交付;④ **云卡 draft PR 一存在立即 `subscribe_pr_activity`
+—— 硬步骤**(未订阅的云卡 PR 是轮询负债)。云会话 `SendMessage` not-reachable 是设计非故障(维
+护者 2026-08-11 裁定:事件驱动架构即长期方案),⛔ 不复测。**接手中断的 dev**:先试 SendMessage
+复活,resume 不可用才走 worktree 接手协议 —— ⛔ 不重跑原派发词;worktree 不新建;逐 hunk 读既
+有工作再决定;验证完整重跑;assignee/认领评论/分支全不动(既有认领的延续,不是新认领)。
 
 ### 收集
 
 
@@ -8,6 +8,15 @@
 一次性云卡用 `create_session`,⛔ 不用 create_trigger+fire(维护者 2026-08-07 拍
 板;trigger 流只留给定时/重复型)。
 
+**适用面与取舍论证(维护者 2026-08-12 裁定,覆盖「M 及以上默认云卡」)**:S 级机
+械 + M ⇒ `mode:subagent`(PM 容器内并行、逐卡显式 `model` 分档);云只保留给 L/XL、
+必须活过 PM 会话的工作、浏览器/dogfood 验证、以及逐卡判断的 build 重 M 卡 —— 共享
+容器争用只来自 build+test,docs/指令类 M 卡碰不到它。论证入档:云有三项固定税 ——
+归档债(实测一个座位积欠 11 个遗忘容器)、create/poke/subscribe/collect 派发收集管
+线、逐卡容器+clone 启动;subagent 的唯一实成本是「随 PM 会话死」,已由
+branch-early、draft-PR 时点报告、transcript 复活与 worktree 接手协议兜底。归档义务
+因此只落在云卡上,遗忘容器面收窄到 L 级派发。
+
 1. **授权面随 source,不随环境**:trigger 拉起的会话没有仓库授权(只能只读勘察);
    `create_session` 带 `source_url` 的会话出生即持推送授权。同时带
    `outcome_branch`(= 认领分支)、显式 `model`(trigger 流不可指模型)、`title`
 
@@ -19,6 +19,10 @@
   裁与活性判定优先用它对账正文。
 - **接管/移交 = 改该贴正文 + 一条审计评论;评论只作交接审计,不承载状态** —— 现状
   永远读正文,不读评论流(历史与现状挤同一通道,对账成本随评论数线性涨)。
+- **读侧边界(接管与巡检)**:读贴正文 + **只读晚于正文最后编辑时间的评论** —— 更早
+  的评论已在那次编辑被吸收进正文(接管压缩即存档动作),属存档不属现状(维护者
+  2026-08-12 批准)。评论无界增长而正文有界,读全评论是纯 token 税;正文编辑时刻与
+  评论时间戳都是平台盖章的硬读数,比对即得。
 - **班次叙事不进贴正文**:逐卡状态在卡与 PR 上本就必填,轮次合计走轮次报告;贴正
   文只在接管、移交、结构变更时编辑,⛔ 不逐事件追加(无界贴会超出单次读取上限)。
 - **接管压缩是标准步骤**:接任 PM 把交接的有效内容按六段模板重述为新正文,**编辑