[Decision] `pnpm demo` 开箱即用时没有任何账号能打开「我的合同」——要不要让脚本建账号，与 #11 第一问耦合

[hotlong]

维护者速读

事情：卡 26（#26 / PR #27）把 120 份种子合同按相对方分给了 §10 的三个「业务承办」，43 / 43 / 34。但开箱即用时这三个账号并不存在，名字解析不到就静默落 NULL，所以 pnpm demo 跑完，「我的合同 › 我发起的」仍然是空的，要等你在 Setup 里建好账号、再跑一次 pnpm demo（数据集是 upsert，会自动交接）才填上。

为什么这不只是「少一步」：实测下来，开箱状态更彻底——pnpm demo 只产出一个账号（dev admin），而 dev admin 不持有任何 clm_* 权限集，GET /api/v1/meta/app/clm 给它返回 navigation: []。所以开箱即用时，没有任何一个账号能打开「我的合同」这个分区，跟这张卡改没改都无关。对一个「能直接卖」的产品，这意味着 demo 的第一屏永远要靠一段说明书才能看到。

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

---

选项

A — 维持现状（卡 26 已交付的形态）。 fixture 写好名字，操作者在 Setup 建账号再跑一次；README 写明了三个名字和分配，pnpm demo 结束时也会在终端打出来。
代价：§10 一字未动，没有虚构人物，但第一屏在操作者动手之前是空的。

B — 让 scripts/demo.mjs 自己建这三个账号并各授予 clm_requester。 之后 pnpm demo 一条命令就能演示。
代价：§10 说「用户不可种子」约束的是 fixture，脚本不是 fixture——但这仍然是建账号，而且要发明邮箱与密码，那是产品内容不是工程细节。约 40 行，用的两个端点这张卡的验收里已经跑通（POST /api/v1/auth/admin/create-user 加一行 sys_user_permission_set）。

C — 把 #11 第一问判成 B（「我的合同」去掉 clm_requester.access 门控，登录即见），然后让 dev admin 分一份合同。
代价：最省事，但它是另一张卡的决定，而且会掏空 §04/§05 那套 *.access 令牌体系的一致性。

两问为什么耦合

如果 #11 判 B，dev admin 就能看见「我的合同」；而平台的 claimSeedOwnership 在单次启动下本来就会把 120 份全认领给它（实测 adminPromoted: true, ownershipClaimed: 260）。也就是说 C 一步同时解决两件事，一个新账号都不用建——代价是拿走一个门控开关。

反过来，如果 #11 判 A（我推荐的，也是卡 07 已实现的），那 B 就是让 demo 开箱可用的唯一路子，因为 A 的世界里 dev admin 永远看不到那个分区。

⇒ 先回 #11 第一问，这一张的答案就基本定了。 单独回这一张也行，但两张一起回只用想一次。

四棱分析

实际业务需求 — 偏 B。这是买家 demo 的第一屏，「跑一条命令就能看到东西」和「先读一页说明书建三个账号」对销售转化不是一个量级。A 的成本全部落在最不该承担成本的人身上——第一次接触这个产品的人。

项目长远合理性 — 偏 A 或 B，明确反对 C。C 用一个门控决定去换 demo 数据的便利，是拿架构换演示，方向反了；§04/§05 整套导航建立在五个 *.access 令牌上，抽掉一个，下一个作者照抄的就是「分区可以不门控」。A 与 B 都不动架构，区别只在这段建账号的代码放在 fixture 外面算不算越界——我认为不算，§10 那句话防的是「种子数据里出现假用户」，脚本在开发机上建演示账号是另一回事。

防 AI 写错 — 偏 B，理由不直观。A 依赖的是操作者照着 README 把名字一字不差地打对（Business Requester 1），打错一个字符就静默落 NULL、无报错无告警——这正是这个仓库一直在防的失败形状：一个静默的空结果和一个正确的空结果不可区分。B 把这个交接从人手里拿走，变成代码里的一个常量。

创业阶段不扩散 — 偏 A。B 要发明三个人的邮箱密码，等于 demo 开始携带凭据；一旦发布，这三组凭据就是产品的一部分了。这是 B 唯一的实质代价，也是它必须由你而不是由循环来定的原因。

结论：四棱里三棱偏 B，一棱（不扩散）偏 A，C 被长远合理性明确反对。我推荐 B，并建议账号名换成像真人的名字（Business Requester 1 是我起的占位，卡 26 的 agent 也把这一条列为要你定的）。但 B 要发明产品内容，所以它是你的决定，不是循环的。

影响

不阻塞任何在途卡片。M3 的卡 09–14 都不读这一条。答案影响的是 scripts/demo.mjs、README 那一节，以及（若选 C）src/apps/clm.app.ts 第 81 行。

关联

#26 / PR #27（这一条的来源，fixture 半边已交付）· #11 第一问（耦合的那一半）· #19（另一块空屏：合同版本，另有原因，仍在等裁定）· #18 / PR #21（两次启动交接，也就是无意中关掉归属认领的那次修复）。

[hotlong]

补一条实测，它改变了 A 的代价

我在开这张卡时写的是「名字解析不到就静默落 NULL」。那是错的。 卡 10（#29 / PR #30）在做启动基线对比时报了这件事，我在 main @ fb549e3 上用全新数据库自己复跑，它是对的：

ERROR [SeedLoader] Deferred reference UNRESOLVED after pass 2 —
  clm_contract.owner_id stays NULL on record 'Master Services Agreement — Aurora Systems'.
  The row itself was seeded, so every row counter looks healthy while the relationship is
  MISSING: nothing links it to sys_user.name = 'Business Requester 1', because no such
  sys_user row exists … Nothing retries this: pass 2 is the last one.

×120，外加一条 WARN [Seeder] ✗ … and 100 more error(s) 汇总。行数不受影响（820 行，120 份合同 owner_id 全 NULL）。

我第一次复测时也拿到了「0 错误」——因为 820 行内联种子超了 8 秒预算，转入后台继续，而我在 Server is ready 之后就去 grep 了。就绪横幅出现在 23:51:07，错误出现在 23:52:22，我早看了 75 秒。这是同一个失败形状的又一次变装：过早读取的日志和干净的日志不可区分。

对选项的影响

A 的代价要重写。 原来写的是「第一屏在操作者动手之前是空的」。实际是：

第一屏是空的，而且每一次开箱 pnpm demo 都会打 120 条 ERROR，永远如此。

对一个把「启动打了告警就不算通过」写进 AGENTS.md 的仓库，把 120 条 ERROR 当作稳态是自相矛盾的。这一条把四棱里的「防 AI 写错」和「长远合理性」都进一步推向 B——原来只有「实际业务需求」和「防错」偏 B，现在是四棱里三棱明确偏 B，只剩「不扩散」（B 要发明三组凭据）还站在 A 那边。

还有一点值得注意：平台那条错误信息自己开出的药方，正是 §10 禁止的那一味——"Add the missing sys_user record to the seed"。也就是说平台认为「种子里该有这个用户」，而设计文档说「用户不可种子」。这个分歧本身就是这张卡要你裁的那一刀，只是现在它被平台用 120 条错误每次都喊出来。

C 仍然不推荐，理由不变：拿架构换演示数据的便利，方向反了。但要说清楚——C 同样能消掉这 120 条错误（dev admin 持有合同，名字解析得到），所以它现在是「一步解决三件事」而不是两件。这不改变我的建议，只是让你知道它的全部诱惑。

我的建议仍是 B，现在更强。但它要发明产品内容（三个人的名字、邮箱、密码，且一经发布就是产品的一部分），所以仍然是你的决定，不是循环的。

---

Generated by Claude Code

[hotlong]

选项 B 不是新发明——隔壁仓库已经做过一遍，而且是完整版

我在给卡 11 找 i18n 参考时翻到 objectstack-ai/hotcrm，发现它面对的是同一个问题，答案就是 B，而且已经跑了很久：

package.json:
  "demo:staff": "tsx scripts/demo-staff.ts"
  "demo:reset": "… echo '… then run: pnpm demo:staff'"

scripts/demo-staff.ts（它的 #640）做四步，全部幂等：

1. 用 POST /api/v1/auth/admin/create-user 建人——它的注释特意说明为什么必须走这个口而不是直接插 sys_user：后者被 ADR-0092 的写入守卫拒绝，就算插进去也是个登不进去的行；
2. 分配岗位（sys_user_position）；
3. 重新求值每一条生效的共享规则；
4. 以每个 demo 用户的身份验证三层真的连通了，不通就非零退出。

而人员名单单独放在 src/sharing/demo-staffing.ts，objectstack.config.ts 从不 import 它——「真实部署不会装进这些人」是结构性的，不是靠自觉。名单本身还有一条纪律：

「一个岗位背后没有机制，就算填上去更整齐也留空……给岗位配人是一个决定，不是一次整理」

这对 #28 的影响

B 的主要代价没有了。 我原来写 B 的代价是「要发明邮箱密码，一经发布就是产品的一部分」。隔壁的做法把这条消掉了：名单文件不进产物，脚本只打本机（它连 --url 不是本机都拒绝执行，理由是「客户组织里出现合成用户」是 #640 无条件排除的结果）。所以 B 不是「让 demo 携带凭据」，是「让 demo 能被本机脚本一键配好人」。

而且它顺带解掉了我刚报的那个平台坑。 上一轮我报了 objectstack#16712——给引导后创建的用户插 sys_user_position 不解析权限。HotCRM 的脚本头解释了其中一半：

plugin-sharing 的授权是从记录写入钩子里物化的，而该钩子在 isSystem 写入时提前返回，每一行种子数据都是 isSystem: true 写的。所以无论谁持有岗位，种子账号都不带任何授权，直到某条规则被重新求值。

也就是说第 3 步不是可选的，而是「光配人不够」的原因。我已经把这段补进 #16712，并说明我报的那一半（导航为空 = 权限集没解析）可能和这一半（行级授权没物化）是两个不同的机制，我没有分开测过，不该让那张卡暗示一个它没验证的区分。

建议不变，但理由更硬了

仍然推荐 B。现在它是：照抄隔壁一个已经在跑、有验证步骤、有「不进产物」结构保证的方案，而不是从零发明产品内容。

⛔ 但仍然是你的决定，有两点必须你定：

1. 三个业务承办叫什么。 Business Requester 1/2/3 是我起的占位名，卡 26 的 agent 也把这一条列为要你定的。
2. 要不要顺带把 §04 的七个岗位也配上人。 HotCRM 的纪律是「岗位背后没有机制就留空」——按这条，HotCLM 该配的是能让机制跑起来的那几个（审批阶梯的审批人、法务受理人），而不是七个填满。这一条比名字更值得你花两分钟。

如果你回 B，我会照 demo-staff.ts 的形状派一张卡，并要求它把「第 3 步不可省」和验证步骤原样带过来——那是这个方案里最容易被省掉、省掉后又完全看不出来的一步。

---

Generated by Claude Code