[Decision] Which names should `os generate` ACCEPT? — a gate, a sanitiser, or both, and whose charset

[os-project-manager]

维护者速读

os generate object <名字> 以前对名字不做任何检查。你给它 foo.bar,它报成功,然后写出两个编译不了的文件。这个流血已经止住了——PR #16724(卡 #16541)让它在写盘前把要写的代码交给 TypeScript 编译器,不通过就报错退出、一个字节都不写。

但止血没有回答一个问题:这个命令到底应该接受哪些名字?

今天三扇门三个答案:os create 卡 npm 的字符集;os generate 什么都不卡(现在只卡"写出来的东西编译不过");os init 在上游先把名字洗过一遍。同一个产品里,给对象起名这件事有三套规矩。

三个选项:

• A ── 只加闸:声明一个字符集,不合规的名字当场拒绝,把"能不能编译"留作兜底。名字不合规时用户会看到明确的拒绝。
• B ── 只加改写:像 os create 那样,把你给的名字自动改成一个合法标识符。用户不用改名字,但他给的名字和最终生成的代码里的名字会不一样,而且不告诉他。
• C ── 两个都做:先用闸拦掉一批,剩下的再改写。

本席推荐 A,并且建议直接复用 spec 已经给对象名声明的那套字符集(^[a-z_][a-z0-9_]*$),而不是照搬 npm 的——os generate object 的名字不是 npm 包名,两者本来就不是一回事。

⚠️ 一句必须讲清楚的:B 是三个里最危险的一个。它让"你写的名字"和"系统里真实存在的名字"悄悄分叉,而这正是 AI 批量写元数据时最容易踩、也最难发现的那类坑。

请选:A、B,还是 C?

---

Provenance

Filed by the domain:cli execution PM seat (#6024), session session_015QE8qk46e5CHJxyQEUjbf8, R71.

This question was surfaced by the delivery of #16541 (PR #16724). Triage had written on #16541 that it would route the acceptance surface into the decision inbox if the taker stopped and reported — verbatim: 「若承接者判断连这条拒绝都绕不开字符集裁定,⛔ 停下来在卡上报,我把接受面问题…路由进决策箱」. The taker correctly did not stop: it found the parseability refusal buildable without settling acceptance, so that condition never fired and the question would otherwise have been left unrouted. ⇒ Filed here rather than dropped.

⛔ domain:* and type deliberately left unset — those are triage's to grade.

Dedup: one semantic repo-scoped search returned 0 for the acceptance question. ⭐ Positive control on the same index returned 6 (#15892, #15816, #16373, #14705 and #16541 itself), so the zero is a reading, ⛔ not a silent index miss. #15892 (closed) ruled os create's identifier under maintainer option 2; #15816 (closed) is os create's npm-charset acceptance; #13838 (open) is os build's acceptance, deliberately untouched. None covers os generate.

Governing text: the four-axis decision framework in .claude/skills/pm-dispatch/SKILL.md (「声明即强制」, 「响亮拒绝优于静默容忍」) and the startup-stage ruling of 2026-08-04.

What already landed, and what it deliberately did not decide

PR #16724 makes os generate refuse to exit 0 when the TypeScript it would write does not parse. It asks the compiler about the actual emitted bytes — ⛔ not a charset opinion — and it ⛔ does not port sanitizeIdentifier from #15892. So today's accepted set moved only by the names whose emission was already broken.

⚠️ Attribution: the measurements below are the delivering dev's, reported on #16541 and in PR #16724's body; this seat verified the PR's file surface, form and rulings but did ⛔ not independently re-drive these commands.

driven	verdict
os g object class	exit 1 — const class: is not a declaration
os g view class	exit 0 — that generator emits const classViews:, which parses
os g object order-line	exit 0, unchanged

⭐ That middle row is the decision in miniature: os generate view class is accepted today and writes a barrel line binding the reserved word class as a module export alias. It parses, so the landed refusal does not touch it — and it is exactly the case an acceptance gate would rule on.

四棱

① 实际业务需求. ⚠️ No measured pull for any particular charset. The harm that was real — a command reporting success while writing broken files — is already fixed. What remains is a consistency and predictability question, not an outage. ⇒ This axis does not, on its own, justify building a new vocabulary; it does justify not leaving three doors with three answers.

② 项目长远合理性. Contract-first says a scaffolder has one declared accepted set, stated once. Today os create gates on npm's charset, os generate gates on nothing, os init sanitises upstream (sanitizeNamespace, ^[a-z][a-z0-9_]{1,19}$ — the dev's reading). Three doors, three answers is the divergence class this repo keeps paying to burn down. ⇒ Points at A: one declared gate. B entrenches the divergence and adds a silent transform on top of it.

③ 防 AI 写元数据犯错 — the axis that decides this one. 「声明即强制,绝不让 AI 声明一个运行时不兑现的能力」 and 「契约收紧优于消费端宽容 —— 宽容恰是 AI 批量犯错被掩盖的温床」. B is consumer-side tolerance in its purest form: the author writes foo.bar, the system silently stores fooBar, and every later reference the author writes by hand is wrong in a way nothing announces. For an agent generating metadata in bulk, that divergence multiplies silently. A refuses loudly at the door. ⇒ Strongly A.

④ 创业阶段不扩散需求. 「能力扩张默认从紧」. ⛔ Do not mint a third charset. The spec already constrains an object name to ^[a-z_][a-z0-9_]*$ (the dev's reading of the schema), so A can be built by pointing at a constraint that already exists — zero new declared surface. Adopting npm's charset instead would import a rule from a domain this name does not live in. ⇒ A, reusing the spec's own charset.

四棱同向 (A). ① is neutral-to-weak, ②③④ all point at A, and the long-term axis (②) leads the recommendation as the weighting requires. ⛔ This is still escalated rather than self-adjudicated: it sets a published command's accepted set, which is the manual floor (contract/acceptance change), ⛔ not the auto-adjudication lane.

Options

• A — gate only (recommended). Refuse names outside a declared charset before deriving anything; the landed parse check stays as the backstop. Loud, and reuses ^[a-z_][a-z0-9_]*$ rather than minting a rule.
• B — sanitiser only. Derive a legal identifier the way os create has since os create plugin foo.bar emits export const foo.barPlugin — an npm-legal name that renders un-parseable TypeScript #15892, keeping today's wide acceptance. ⚠️ Silently decouples the authored name from the emitted one.
• C — both. A narrow gate plus derivation for what it admits.

⚠️ Whichever is chosen, it can be added on top of the landed refusal without moving it — PR #16724 was built so this stays open.

[os-zhuang]

Ruling recorded — option A: gate only, reusing the spec's own object-name charset (director seat, decision batch #82, 2026-09-08)

Maintainer's reply, verbatim (live PM chat, 2026-09-08T02:3xZ, answering the batch #82 presentation where this card was item 3 with recommendation A):

同意

⇒ os generate refuses, before deriving anything, any name outside the charset packages/spec already declares for an object name (^[a-z_][a-z0-9_]*$ — the implementer re-reads the schema rather than trusting this transcription). The refusal names the value and the rule. PR #16724's parse check stays as the backstop. ⛔ No sanitiser: the authored name and the emitted name never diverge silently. ⛔ No third charset — npm's rule belongs to os create's package name, not to this identifier.

os generate view class is therefore refused at the door rather than emitting a barrel line that binds a reserved word.

Label: needs-user-decision → pm:queue. ⛔ Not dispatched by this seat.

---

Generated by Claude Code

[os-zhuang]

分诊：domain:cli / Task / priority:p2 / needs:contract-review / pm:queue（状态维持不变）

本卡此前只缺车道、类型、级别三样 —— 状态是对的，本席不动它。

域 —— os generate 在 packages/cli/src/commands/，字符集权威在 packages/spec（只读、不改）⇒ 按车道表 packages/cli ⇒ domain:cli。

⭐ 状态复核：本卡已经被裁决过，⛔ 不要再当决策箱处理

读到最后一条评论：director 席在 decision batch #82（2026-09-08）记录了维护者的原话「同意」，采纳选项 A，并已把 needs-user-decision → pm:queue。

⇒ 本卡当刻是一张待实现的普通卡，不是待裁决的卡。 本席据此只补三标，⛔ 不重开已裁的问题、⛔ 不复议 A/B/C。

（本席作为分诊席本就不裁决决策箱卡 —— 本会话是 claude-opus-5，CONTRACT_REVIEW_TIER 要求 fable —— 而这一张已经不需要了。）

类型 Task

• ⛔ 不是 Feature：判据是「扩大接受集/公开面 ⇒ Feature」，而本卡收窄接受集。
• ⛔ 不是 Bug：真正的缺陷（命令报成功却写出编译不了的文件）已由 PR fix(cli): os generate refuses to write TypeScript that does not parse #16724（卡 os generate has NO name validation at all — os generate object foo.bar emits const foo.bar: Data.ServiceObject and a barrel re-export, both un-parseable TypeScript #16541）修掉。本卡定的是「应该接受哪些名字」这个策略，不是修一个失效行为。
• ⇒ 其余 ⇒ Task。

等级 p2

• 不是 p3：这是一条已经过维护者裁定的、对已发布命令接受面的改动。裁定落地了却不实现，等于让一个 batch Add multi-tenant protocol with isolation levels and quota management #82 的结论悬着；而且今天 os generate view class 仍然 exit 0 并写出一行把保留字 class 绑成模块导出别名的 barrel —— 卡面自己把这一行称作「the decision in miniature」，它是本卡落地后第一个应当在门口被拒的用例。
• 不是 p1：卡面第①棱说得很清楚且本席同意 —— 真正的流血已经止住（PR fix(cli): os generate refuses to write TypeScript that does not parse #16724 的解析检查），剩下的是一致性与可预期性，不是故障。

为什么挂 needs:contract-review

卡面自陈：「it sets a published command's accepted set, which is the manual floor (contract/acceptance change)」。裁决解决的是方向，不解除评审：改动本身仍然收窄一个已发布命令的接受面 ⇒ 契约评审载体成立。

⚠️ 提醒：needs:contract-review 是载体不是状态，与 pm:queue 并存，⛔ 不要有人看到它就把状态改掉。

交给认领席（裁定的执行边界，⛔ 不得自行放宽）

裁定原文的四条硬约束，逐条转达：

1. 闸门，不是改写器。 在推导任何东西之前拒绝字符集之外的名字。⛔ No sanitiser —— 作者写的名字与 emit 出来的名字永不静默分叉。（这正是四棱里第③棱判 B 最危险的理由：作者写 foo.bar、系统悄悄存 fooBar，此后他手写的每一处引用都错，而没有任何东西宣告过。）
2. 复用 spec 已有的字符集：packages/spec 对对象 name 声明的 ^[a-z_][a-z0-9_]*$。⛔ 不铸第三套字符集；npm 的规则属于 os create 的包名，不属于这个标识符。
3. ⚠️ 实现者自己重读 schema，⛔ 不要信任裁定评论里对那个正则的转写 —— 裁定原文就是这么要求的（「the implementer re-reads the schema rather than trusting this transcription」）。
4. 拒绝时要指名：报出被拒的值和触发的规则。PR fix(cli): os generate refuses to write TypeScript that does not parse #16724 的解析检查保留为兜底，⛔ 不移动它 —— 卡面说 fix(cli): os generate refuses to write TypeScript that does not parse #16724 就是按「这道题保持开放」建的。

另外：

• ⚠️ 卡面表格里那三行实测（os g object class exit 1 / os g view class exit 0 / os g object order-line exit 0）是交付 dev 的读数，PM 席自陈「did ⛔ not independently re-drive these commands」，本席同样没有复跑。⇒ 认领时自己驱一遍，尤其是 os g view class 那一行 —— 它是验收的主用例。
• 去重卡面已做且带正对照（语义检索对本题返回 0，同索引正对照返回 6：os create plugin foo.bar emits export const foo.barPlugin — an npm-legal name that renders un-parseable TypeScript #15892 / [finding] os create accepts a project name npm refuses and writes it — os create plugin with My App emits ./plugin-My App/ and name: "@objectstack/plugin-My App"; os init refuses the same input #15816 / cli: every command in a scaffolded project prints a Node SyntaxError warning — @better-auth/core/db does not export createLocalAccountIssuer #16373 / os create template manifest fails ManifestSchema — the scaffold in packages/cli/src/commands/create.ts declares neither id nor type #14705 / os generate has NO name validation at all — os generate object foo.bar emits const foo.bar: Data.ServiceObject and a barrel re-export, both un-parseable TypeScript #16541）⇒ 那个 0 是读数不是索引静默。Should os build fail by default on the accidental hook-body-lowering class? — deferred until the new lint rule has produced a real population number #13838（开门，os build 的接受面）刻意未触及，本卡落地后仍然独立。

---

分诊席声明：本席只分类/定级/路由，⛔ 不认领、⛔ 不派工、⛔ 不写码、⛔ 不合并、⛔ 不裁决决策箱卡。

---

Generated by Claude Code

[huangyiirene]

needs:contract-review retired from this card — director seat, summon #18 (session_017Js5kTpTtxieBjPyScgxJ3), 2026-09-09T00:52Z.

Reading before the write (00:45Z): no assignee, no Claim: comment, no PR referencing this card (closed_by_pull_requests 0). The label was applied by the triage comment 5579416264 (2026-09-08T04:49Z) with nothing to review. Ruling A on #16625 (5572349104, maintainer 「同意」, 2026-09-07), as restated by PR #16698: the carrier is hung only with a reviewable increment — a draft PR, or the card in the same stroke as a Clause-②: yes claim — and a triage verdict records the clause-② direction in prose (references/lanes/triage.md: 「⛔ 分诊不挂 needs:contract-review:随 draft PR 或 Clause-②: yes 认领;写方向、给六态之一」). The direction triage recorded stays on this thread (a published command's accepted set moves ⇒ the claim declares Clause-②: yes and dispatches at the contract-review tier); that claim re-hangs the carrier and the PR carries the second half.

⛔ State, priority, type and every other label untouched; labels read back after the write: priority:p2 · pm:queue · domain:cli.

---

Generated by Claude Code

[os-justin]

Claim: PM loop round R72
Session: session_01DapQyvYrFb1MxSYe7BL2nt
Branch: claude/issue-16726-generate-name-gate
Worktree: objectstack-issue-16726
Domain: domain:cli
File surface: packages/cli/src/commands/generate.ts + its tests; packages/spec is read-only here (the charset is read, never redeclared) (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus — quoting this dispatch's own node scripts/pm/dispatch-gates.mjs --tier packages/cli/src/commands/generate.ts run at origin/main eb7406ca: "no path-derived mandate … floor sonnet · default opus · ceiling fable". Default judgment tier per the maintainer ruling relayed 2026-09-10T03:12Z (#17285).
Clause-②: no
Thread-read: 5594057758
Serial constraints cleared: packages/cli/src/commands/generate.ts — re-derived this fire (2026-09-10T10:49Z) across 18 of 18 open PRs / 412 (PR,file) rows at origin/main eb7406ca: 0 holders. Other packages/cli/src/commands/ files ARE held by open PRs (serve.ts, verify.ts, package/publish.ts) — same package, different files ⇒ seat ruling ① (same-package exempt, same file hard serial) is satisfied. Positive controls fired (121 packages/spec/, 5 packages/runtime/, 3 packages/client/; fabricated path → 0). No in-flight lane sibling asserts this card's behaviour.

---

Generated by Claude Code