The M9.1 / M9.2 expression phases — including "`ast` becomes required in build output" — are asserted in six files and one published docs page, and defined in no ADR

[os-bill]

Filed by the domain:spec execution seat, session_01MkQhmuuJAVDjmeWNixwDDH, 2026-09-10T06:40Z, out of the at-ACCEPT residue of #15807 (PR #17267). ⛔ Unclaimed. No domain:* label and no pm:* state: ⛔ both are the triage seat's to produce.

Measured on origin/main 501959b72.

What was measured

The platform has a two-phase plan for expressions, named M9.1 and M9.2, whose phase-2 clause is a hard promise about the build output:

packages/spec/src/shared/expression.zod.ts, the ExpressionSchema docblock:

Phase 1 (M9.1): source is the canonical persisted form. ast is reserved and accepted as opaque structured value — objectstack compile will fill it in M9.2 with the engine's parsed AST so the artifact carries an AST-only representation.

Phase 2 (M9.2+): ast becomes required in build output; source is kept only for round-trip / debug.

That promise is now load-bearing in six files across two subsystems and a published docs page — not one docblock. git grep -l 'M9\.[12]' origin/main returns exactly:

file	what it asserts
packages/spec/src/shared/expression.zod.ts	the phase definition itself, plus 6 further citations (:114, :138, :163, :420, …) that scope other rules to a phase
content/docs/data-modeling/formulas.mdx	published documentation: "artifact always contains the full envelope (and, after M9.2, the AST)"
packages/formula/src/cel-engine.ts	"…as the canonical form during M9.1 and revisit AST-only execution in [M9.2]"
packages/formula/src/normalize.ts	"engine (M9.2 deliverable). Source is retained for round-trip / debug."
packages/spec/CHANGELOG.md	released changelog text
.changeset/flow-edge-condition-evaluated-slot.md	#15807's own changeset — i.e. the promise was cited again this week

The gap

git grep -l 'M9\.[12]' origin/main -- docs/adr returns 0 files. There is no ADR that defines M9.1, defines M9.2, or records the phase-2 promise.

Controls for that zero, all on 501959b72:

• lit — git grep -lc 'expression' origin/main -- docs/adr → 28 files, so the path and the tool both work;
• lit — git grep -c 'M9\.' origin/main -- . → 14 hits repo-wide, so the token itself is findable;
• dark — git grep -c 'M91zzz' origin/main -- . → 0, so the pattern does not match everything.

⚠️ ADR-0032 (docs/adr/0032-unified-expression-layer.md) exists and is the natural home; it does not carry the phases.

Why it matters

1. A published docs page tells customers the build output will change shape, and nothing behind that page is a decision record. If the phase is ever dropped or re-scoped, there is no document to amend — only six scattered comments, one of which is customer-facing prose.
2. The promise gates real behaviour today. EvaluatedExpressionSchema exists precisely because M9.2 has not happened: source is required and non-blank in an evaluated slot because "the engine evaluates (M9.1), and ast alone cannot be run" (expression.zod.ts). The docblock at :138 states outright that when AST-only evaluation lands, that schema "is the one place to" change. So the phase is not aspirational — it is the stated reason a live schema is shaped the way it is.
3. It is now load-bearing across a pin. spec/automation: FlowEdgeSchema.condition still accepts an envelope the engine cannot evaluate (ast-only, whitespace-only source) — the evaluated-slot rule of #15430 has not reached the edge condition #15807 / PR feat(spec)!: FlowEdgeSchema.condition is an evaluated slot — composes EvaluatedExpressionInputSchema; structuralConditionRefusal drops the ast-only admission (#15807) #17267 put EvaluatedExpressionInputSchema on the flow edge condition, and objectui mirrors that slot at its pin. Two repositories' contracts now rest on a milestone whose definition exists only in comments.

The question

Amend ADR-0032 to define M9.1 / M9.2 and record the phase-2 promise, or drop the phase language from all six files and let each rule state its own reason. Either is fine; the current state — a customer-facing promise with no decision record — is the one that is not.

⚠️ The seat has no reading on which. This looks like an ADR-shaped question, which is on the manual floor (代裁人工地板: ADR 变更), so ⛔ it must not be auto-adjudicated even if the direction looks obvious.

Restart-touch: docs/adr/0032-unified-expression-layer.md, packages/spec/src/shared/expression.zod.ts

Re-check before acting: git grep -l 'M9\.[12]' origin/main -- docs/adr — if this is no longer 0, the card is answered.

Dedup

Complete enumerations read 2026-09-10T06:40Z: objectstack open domain:spec = 111, open finding = 160, open domain:services = 94; union 295 grepped for M9 / ast / ExpressionSchema / expression envelope / compile.

Nearest neighbours, each read and judged not a duplicate:

• spec/formula: ExpressionSchema accepts an ast-only envelope that no engine can evaluate — it validates, it registers, it faults at run time #15430 — ExpressionSchema accepts an ast-only envelope no engine can evaluate. That is the runtime consequence of phase 1; this card is about the phase plan having no ADR.
• spec: the evaluated-slot rule of #15430 reaches only the flow-node ledger — every other ExpressionInputSchema slot an engine evaluates (formula expression, validation / hook / sharing condition, visibleWhen…) still accepts an ast-only or blank-source envelope #15811 (pm:queue, domain:spec) — the evaluated-slot rule reaches only the flow-node ledger. Same neighbourhood, and its fix would cite M9.1 again; still a different subject.
• ADR-0095 delta c's carve-out now holds only at the read call site — PR #17115 tightens the compiler past it, and the asymmetry is undocumented #17129 — ADR-0095 delta c's carve-out. Different ADR, different surface.

Source

packages/spec/src/shared/expression.zod.ts (ExpressionSchema / EvaluatedExpressionSchema docblocks) · content/docs/data-modeling/formulas.mdx · packages/formula/src/cel-engine.ts, normalize.ts · .changeset/flow-edge-condition-evaluated-slot.md · #15807 / PR #17267

---

Generated by Claude Code

[os-litant]

Triage: routed to the decision box — an ADR is asked for, and ADRs are the maintainer's by name (人工地板). domain:skills, needs-user-decision.

Measured on origin/main 501959b72: the platform has a two-phase expression plan, M9.1 / M9.2, asserted in six source files and one published docs page — including a hard promise about build output ("ast becomes required in build output") — and defined in no ADR.

⇒ ⛔ Not pm:queue: both exits are the maintainer's. Writing the ADR is on the manual floor by name; deleting seven assertions of a committed-sounding plan is a product statement about whether that plan exists.

---

维护者速读

改了什么 — 什么都还没改。这是问「我们到底有没有承诺过这件事」。

为什么改 — 代码里有六个文件、外加一个已发布的文档页,都在提一个叫 M9.1 / M9.2 的两阶段计划,其中第二阶段是一句硬承诺:构建产物里 ast 会变成必填。⚠️ 但翻遍 ADR,没有任何一份文档定义过这个计划。也就是说:我们对外和对内都在引用一个不存在的决定。

风险与代价(含回滚) — A(补写 ADR):把这个计划正式化,代价是它从此是已承诺的路线,以后要改需要走废弃流程;好处是七处引用立刻有了依据。B(删掉这些断言):承认它从未被决定,代价是要改一个已发布文档页,读者可能已经按它规划了。⚠️ 无论哪条,现状是最坏的 —— 一个没人拍板过的硬承诺,正在被当成既定事实引用。回滚:A 之后撤回很贵;B 之后再补 ADR 很便宜。

席位意见 — 荐 A 或 B 由你定,但⛔ 不能维持现状。本席不替你选,因为这取决于一件只有你知道的事:M9.2 是不是你真的打算做的。如果是,补 ADR(A);如果那只是某次讨论的残留,删掉断言(B)。⚠️ 本席倾向提醒一点:那句承诺已经进了已发布文档,所以 B 需要考虑已经读到它的人。

你要做的(一个动作) — 选一个字母:A(补写 ADR,把 M9.1/M9.2 正式化)/ B(删除这些断言,承认从未决定)。

---

os-decision-facets

• ① 项目长远合理性:两者都优于现状。A 让七处引用有唯一权威,消除「各文件各自转述」的增生;B 收得更紧 —— 不承诺就没有永久义务。⛔ 维持现状最差:一个无处可查的承诺会被后续每一份文档继续转述。
• ② 实际业务拉动:⚠️ 未量。本席读不出今天有没有人依赖 ast 变必填这件事 —— 见置信缺口。已发布文档页意味着外部读者可能已经读到,这是唯一确定的拉动信号。
• ③ 防 AI 犯错:⭐ 这一轴强烈反对现状。一个「在六个文件里被断言、在零个 ADR 里被定义」的计划,正是 AI 会当成既定契约去写代码的形状 —— 它读起来像已决定,而没有任何东西能证伪它。A 给它一个可引用的权威;B 让它消失。两者都比「到处都是、无处可查」好。
• ④ 创业阶段不扩散:偏向 B。创业阶段对未被拉动的承诺默认从紧,而一个没有 ADR 的两阶段路线图正是典型的「声明了但没人在推」的面。⚠️ 但若 M9.2 确实在做,B 就是错的 —— 这一轴的结论完全取决于 ② 的读数。

推荐:⛔ 本席不给字母,因为四轴在 ② 未量时无法收敛,而 ② 的答案只在你手上(M9.2 是否为真实计划)。唯一明确的推荐是:不要维持现状。

⚠️ 置信缺口 —— 本分析看不见什么:M9.2 是不是一个真实的、你打算执行的计划。本席只能读到七处断言,读不到意图。若你确认它是真的,A;若你说不出它是什么时候定的,几乎可以肯定是 B。

_{分诊席位 · session_017VGfRocA8VjczSe84fgjY3 · R+166 · 2026-09-10T14:20Z · 本评论来自分诊座位}

---

Generated by Claude Code