finding(spec): AssembledPackageBodySchema declares callable and custom branches an inert-JSON artifact cannot hold, and every schema embedding it loses its JSON Schema

[os-bill]

os-decision-facets

⛔ This is an EXECUTION card stalled at its ruling's OWN step 4 — ⛔ not an unruled question

Ruling-ref: 5729478920 — batch #159 item 2 · letter A, maintainer 「同意」. It confirmed the 2026-09-13 ruling (batch #127 item 4, record 5651572469) and withdrew batch #149 item 1 letter B (record 5716259259). ⛔ The direction is settled and is not re-presented here; what follows is the measurement ruling A's own step 4 asked for, and the shape question that measurement returned.

⚠️ Added by the seat when the half-state patrol row H62 measured this body as carrying no os-decision-facets marker in either spelling. ⛔ Nothing already on the face was removed or reworded. The full four-axis analysis, the options and their costs live in comment 5729976367; this block is the card-face serialisation the shape requires.

Steps 1, 2, 5 and 6 are MEASURED READY. An artifact-stage body built exactly as step 2 prescribes does convert under z.toJSONSchema. Step 3 is blocked by step 4's own precondition, which fired: on the rows GET /packages serves, toRecordManifest leaves a functions residual that is neither a string nor a lowered declaration.

⭐ Two things the next reader must not mis-read. (1) The producer is packages/objectql/src/registry.ts — it is outside the three-file surface ruling A itself names, and outside packages/spec entirely, so the fix that ruling authorises does not fit the surface that ruling drew. That self-inconsistency is the seat's to have caught before dispatch, and it did not. (2) The card body's second consequence does not reproduce on today's main: packages/spec/json-schema/ is gitignored and was never version-controlled, while json-schema.manifest/api.json already carries both response schemas — ⛔ do not read their presence as 「the work is done」, nor their absence from git as 「it is not」.

The question: what shape does the REGISTRY RECORD stage take?

⛔ Not a dev's choice: it changes the payload GET /packages emits, lands in @objectstack/objectql — another published package, with its own Clause-② — and toRecordManifest's docblock states it is a structural projection and ⛔ 「not a key denylist」, so any fix that special-cases a key name overturns a written design rule.

	option	cost, measured
A	registry records the lowered form — a dropped callable becomes a handler ref	the only arm that literally satisfies step 4, and it fixes the under-report. ⛔ But it overturns the documented structural rule, and a ref the registry mints is not guaranteed equal to the one build mints (lower-callables.ts uses uniqueName(base, taken) and dedupes by function identity) ⇒ a record could assert a ref that resolves in no sibling module
B	a dropped callable discards the whole entry	step 3 becomes immediately doable. ⛔ But it generalises today's bare-entry behaviour to declarative entries — deliberately under-reporting at a read door — and throws away the effect declaration, the one half that survives today
C ⭐	split: file the producer under-report as a sub-issue of this card and rule the record-stage shape there; land steps 1/2/5/6 now; step 3 waits on the sub-card	measured-ready work converts immediately and the undecided part is decided in its own package. ⛔ Cost: an exported artifact-stage body briefly has no consumer, which the PR body must declare as phase one
D	same sub-card, but this whole card goes pm:blocked behind it	nothing lands now; the four ready steps wait on an unformed producer decision

四棱

① 项目长远合理性 — 三个声明过的阶段(authoring / 内存装配 / 落盘 artifact)之外,registry record 是事实上的第四个阶段:callable 已经没了,却没有 ref 顶上。今天没有任何声明描述它,这才是残骸能存在的根因。⇒ 偏向让 record 阶段拿到自己的声明。
② 实际业务拉动 — ⭐ 欠报是独立于本卡的真缺陷:机器可读的读门把「这个包声明了几个函数」说少了,而且踩在我们自己发布的 showcase 上(config.ts:244-249 正好一条裸的、一条声明式的,两种残骸各一)。⛔ 它不因为本卡怎么裁而消失。
③ 防 AI 犯错 — ⛔ 别再让一次派发同时裁「schema 形状」和「生产者行为」。本卡已因「裁决措辞 ↔ 代码事实」错位空转两轮(B 撤回、A 卡在自己的步骤 4)。B 的失败模式最危险:它让读门静默少报而不响亮拒绝。
④ 创业阶段不扩散 — 步骤 1/2/5/6 已实测就绪。把已就绪的收益押在一个尚未成形的生产者决定后面,是用确定换不确定。

Prior rulings read: assembledpackagebody,inert-json,z.function,lowering → 2 hits; ADR-0058 D1, ADR-0058 D3; thread: 3 ruling(s) (5651572469, 5716259259, 5729478920)

⚠️ 那 2 个 ADR 命中是噪声,不是先例。 两条都只命中 lowering 一词,而 ADR-0058 D1/D3 讲的是 CEL→FilterCondition 下推编译器 —— 与 artifact 阶段体无关。⛔ 不要把「2 hits」读成「有两条裁决适用」。

推荐:C。
自检:只看①选 C(record 阶段该有自己的声明,而那要在它自己的包里裁);②③④ 是否翻转:否 —— ② 加固它(欠报独立存在)、③ 加固它(拆开才不会再错位一轮)、④ 加固它(已就绪的不该陪跑)。
置信缺口: ⛔ NOT MEASURED —— registry 铸的 ref 与 build 铸的 ref 在真实包上到底有多常不相等(uniqueName 撞名加后缀、按函数同一性并键,两条都只从源码读出,⛔ 没有在一个真实多函数包上量过)。选 A 就等于在这个未测量上下注。

⚠️ 另有 GAMMA(保留生产者行为,单给 record 阶段一个「callable 未存活」的声明)⛔ 未给独立字母:它实质上就是 C 的子卡要裁的内容,给字母会让同一问题在两处各裁一次。⛔ 而把 GAMMA 等同于原 letter C 是不准确的 —— 原 letter C 被否的理由是「为同一个设计增加 2–3 个永久导出」,与 record 阶段该不该有声明是两回事。

---

Found while landing #17431. Filed rather than fixed: the remedy moves AssembledPackageBodySchema's own shape, which is #14242's ruling territory, and #17431 is bound to the read API one layer up.

The contract, verbatim

ADR-0130 D4's own docblock on ArtifactPackageEntrySchema (packages/spec/src/stack.zod.ts) states why plugins and devPlugins are envelope keys that no package body may carry:

An artifact is inert JSON: a plugin written inside packages[i].manifest could never be constructed by a loader, so a reader that resolved it there would register garbage where it used to skip in silence.

AssembledPackageBodySchema — the body half of ArtifactPackageSchema, i.e. one package as assembled into a release artifact — nevertheless carries two collections whose declarations admit values that same sentence says can never exist in an artifact:

• functions, whose entry schema FlowFunctionEntrySchema (automation/flow-function.zod.ts) has z.function() as its first union branch;
• hooks, whose HookSchema (data/hook.zod.ts) has a z.custom() branch.

A callable in an artifact is exactly the case the quoted sentence excludes: the artifact is JSON on disk, so the branch describes a value the surface cannot hold.

Measured consequence

Of the assembled body's 55 shape members, exactly those two have no JSON Schema form. Measured with z.toJSONSchema(member, { io: 'input' }) over every key of AssembledPackageBodySchema.shape:

functions: Function types cannot be represented in JSON Schema
hooks:     Custom types cannot be represented in JSON Schema

and, on the whole body:

probe	result
AssembledPackageBodySchema	FAIL — Function types cannot be represented in JSON Schema
.omit({ functions: true })	FAIL — Custom types cannot be represented in JSON Schema
.omit({ hooks: true })	FAIL — Function types cannot be represented in JSON Schema
.omit({ functions: true, hooks: true })	OK

That is why ArtifactPackage and ObjectStackDefinition publish no JSON Schema at all, and it propagates: any published export that embeds the assembled body loses its own JSON Schema and its content/docs/references/** page with it. #17431 hit exactly that — binding the body into ListInstalledPackagesResponseSchema and GetInstalledPackageResponseSchema made both disappear from json-schema/api/, which build-schemas.ts's disappearance ratchet refuses.

So the cost is not local to the artifact schema. It is a standing tax on every future surface that wants to declare the assembled stage — and declaring the assembled stage is the ruled remedy for the #14242 class.

Why this is a contract violation and not a preference

The two branches are not merely unused here: the surface's own declared semantics say they are unreachable. A declaration that admits what its surface cannot hold is a claim nothing enforces, and here it has a measured price paid by unrelated schemas.

⛔ Not proposing the shape. Two obvious directions exist (narrow the two collections at the assembled body, or give artifact-stage variants of the two entry schemas) and both move a declaration #14242 ruled on, so the choice is the maintainer's.

Related: #14242 (the ruling that created AssembledPackageBodySchema) · #17431 (where this was measured) · #11072 (the sibling axis: the same tree also carries a Node-only import, which is a separate matter)

---

Generated by Claude Code

[os-litant]

Triage: lands in packages/spec/src/stack.zod.ts ⇒ domain:spec; type Bug, priority:p2, pm:queue.

Class (b), with the contract quoted from the repo's own ADR docblock. ADR-0130 D4 on ArtifactPackageEntrySchema states why plugins / devPlugins are envelope keys:

An artifact is inert JSON: a plugin written inside packages[i].manifest could never be constructed by a loader, so a reader that resolved it there would register garbage where it used to skip in silence.

⇒ AssembledPackageBodySchema nonetheless carries functions (whose FlowFunctionEntrySchema opens with a z.function() branch) and hooks (whose HookSchema carries a z.custom() branch). Both admit values that same sentence says can never exist in an artifact.

⭐ And the consequence is not theoretical: every schema embedding it loses its JSON Schema. That puts it in the same family as two other cards graded this shift — objectstack#17501 (/meta/types serves an EMPTY schema for action) and #17502 (tombstones offered as repeater columns) — all three being what the served schema says diverging from what the door accepts. ⛔ Different files, different fixes; ⛔ not folded. ⭐ But whoever takes any of the three should read the other two.

Not blocked — measured 2026-09-10T19:26:48Z

The card defers to 「#14242's ruling territory」. #14242 is closed ⇒ the ruling is settled, not pending. ⇒ Dispatchable, and the ruling is an input to read rather than a wait.

⚠️ #17431 is pm:dispatched with needs:contract-review and is where this was found. ⛔ Do not fold: that card is bound to the read API one layer up, this one moves AssembledPackageBodySchema's own shape. Folding gate ③ fails outright — #17431 is in flight.

priority:p2: a published schema declares branches its own contract says cannot occur, and the derivation breaks for every embedder. Loud where it breaks, silent where it merely lies. Not p1: no data moves and nothing shipped rejects a valid artifact today.

_{Triage seat · session_017VGfRocA8VjczSe84fgjY3 · R+171 · 2026-09-10T19:27Z (timestamp taken in the same tool call that posts) · comment from the triage seat}

---

Generated by Claude Code

[os-bill]

Claim: session_01MkQhmuuJAVDjmeWNixwDDH · branch claude/issue-17518-assembled-body-json-schema
Branch: claude/issue-17518-assembled-body-json-schema
Clause-②: yes — the remedy moves a PUBLISHED declaration. Narrowing functions / hooks at the assembled body (or introducing artifact-stage variants of FlowFunctionEntrySchema / HookSchema) changes what AssembledPackageBodySchema accepts, so the contract-review tier applies and needs:contract-review rides the draft PR from the moment it opens.

domain:spec execution seat, PM dispatch, 2026-09-12T15:57Z. The assignee above was set by this seat in the same step as the pm:queue → pm:dispatched swap, read back and diffed (['bug','domain:spec','pm:dispatched','priority:p2'], assignees ['os-bill']). The dev round inherits BOTH and posts no second claim.

Pre-measurement taken by this seat before the claim, read at 2026-09-12T15:55Z, not recalled:

• finding(spec/runtime): GET /packages rows are the ASSEMBLED package body, but InstalledPackageSchema types them as the AUTHORING manifest — the #14242 stage mismatch, one layer up on the read API #17431 — the card this was found in, and the one the triage comment flags as in flight — is closed / completed (closed 2026-09-10T21:07:47Z). The fold gate that triage marked as failing outright no longer fails for that reason; it still fails on gate ① (different defect shape, different file) and the round must not fold it.
• ArtifactPackageEntrySchema's body half cannot describe the payload the load path actually registers #14242 — the ruling that created AssembledPackageBodySchema — is closed / completed (closed 2026-09-02T13:46:07Z). It is an INPUT to read, not a wait, exactly as triage recorded.
• metadata-protocol: /meta/types serves an EMPTY JSON Schema for action — the output-mode derivation of its ZodPipe has no properties, and the hand-crafted fallback never fires #17501, spec: retiredKey() tombstones are emitted into a repeater row's items.properties, so the served schema offers six columns the parse door refuses #17502 are named by triage as same-family reading, ⛔ NOT as members to fold. spec: retiredKey() tombstones are emitted into a repeater row's items.properties, so the served schema offers six columns the parse door refuses #17502 is fenced to another session and this round does not touch it.

The card says in its own words 「⛔ Not proposing the shape … both move a declaration #14242 ruled on, so the choice is the maintainer's」, while triage graded it dispatchable on the ground that the ruling is settled. Both readings are on the card and the round is dispatched to settle which one the tree supports: if #14242's landed ruling plus ADR-0130 D4 mechanically determine the direction, implement it; if they leave a real fork, stop with an empty diff and a four-facet block rather than pick for the maintainer. A measured needs_decision is a successful outcome for this card, not a failure.

---

Generated by Claude Code

[os-bill]

os-decision-facets

Dev round verdict: needs_decision, empty diff. The card's central premise is falsified by measurement, and what survives is a smaller question that is genuinely the maintainer's. Full readings with their controls are in the os-dev-report comment below; this comment carries the decision material only.

What the tree says, quoted

1. The two branches are NOT unreachable — they are live on the path this schema declares itself for.

composeStacks(stacks, { manifest: 'preserve' }) is a published @objectstack/spec function. It builds packages[i].manifest through assemblePackageBody() (packages/spec/src/stack.zod.ts:3502-3509), which copies the authored stack's functions and hooks verbatim, with no lowering. Measured on origin/main at ed8dea17bd:

packages[0].manifest.functions.scoreLead            typeof: function
packages[0].manifest.functions.syncBilling.handler  typeof: function
packages[0].manifest.hooks[0].handler               typeof: function
ArtifactPackageSchema.safeParse(that body).success      = true
AssembledPackageBodySchema.safeParse(that body).success  = true
LIT CONTROL — same body with glob `objects`             = false, issue at objects.0
LOWERED form of the same body                            = true

And stack.zod.ts:3489-3491 states the invariant that makes that binding, verbatim:

{@link AssembledPackageBodySchema} is its declaration and {@link ObjectStackDefinitionSchema}'s packages key parses against it, so a body this function builds and a body the load path accepts cannot drift.

⇒ This rules out the card's direction (a) — narrowing the two collections at the assembled body would make a published composition function's own output refused by the schema the same file says must accept it. The ADR-0130 D4 sentence the card quotes is the justification for excluding plugins / devPlugins from the body as envelope keys; it is not a statement that the assembled body is always JSON. The schema's own header says what it is: "One package as it is ASSEMBLED into a release artifact, and as the load path registers it" (stack.zod.ts:1101-1102).

2. Two of the card's measured consequences are causally wrong.

• ArtifactPackage and ObjectStackDefinition publish no JSON Schema because stack.zod.ts is not one of the 15 subpath namespaces build-schemas.ts walks — measured by replicating that walk: 1551 zod exports reached, and AssembledPackageBodySchema, ArtifactPackageSchema, ArtifactPackageEntrySchema, ObjectStackDefinitionSchema are not among them (lit control: HookSchema, FlowFunctionEntrySchema, AssembledInstalledPackageSchema, ListInstalledPackagesResponseSchema are). Removing the two branches would not make either file appear.
• ObjectStackDefinitionSchema has four unrepresentable members — packages, hooks, functions, onEnable — of which only packages is the assembled body. Repairing the body would not make it emit.
• Separately: HookSchema's z.custom() branch is already handled at the published-schema level by the landed [finding] Five filter operators ($gt/$gte/$lt/$lte/$between) reach NO published reference page — build-schemas.ts skips their whole schema over an unrepresentable z.date(), and the skip is silent #16431 (a) projection. Running the build's own predicate, Data.HookSchema EMITS today, projected, pruning #/properties/handler/anyOf/1. FlowFunctionEntrySchema stays unemitted because its declaration branch needs a callable in a property position, which is not droppable.

3. What survives, and it is real. An exported schema that IS in the emit loop and embeds the assembled body cannot emit. That tax is paid exactly once today, in packages/spec/src/api/package-api.zod.ts, whose own docblock says of its z.unknown() override: "on THIS surface those two keys are accepted without being checked."

The question

The assembled package body deliberately spans two stages — the in-memory composed body, where callables are legitimate (measured above), and the on-disk artifact body, which is inert JSON carrying only lowered string refs (hook.zod.ts:249 "The JSON artifact therefore only ever contains the string form"; flow-function.zod.ts:223 "The CLI lowers every inline callable to a serialisable string ref BEFORE the stack is parsed"). Only the second is inert JSON.

Should packages/spec gain a declared inert-JSON stage for it, or do the two keys stay undeclared at every JSON surface?

	option	what it does	real cost to a consumer
A	close as premise-falsified, change nothing	record this reading on the card	the one JSON surface that needs an inert-JSON body keeps functions / hooks as z.unknown(); the next surface re-derives this analysis or copies the override, and "write unknown on a JSON surface" becomes precedent
B	declare the inert-JSON stage	export the lowered function entry (today a module-local const) plus an artifact-stage body whose hooks[].handler is z.string(); rebind package-api.zod.ts's record body to it	2-3 new permanently published exports; the read API's two keys move from unknown (accepts anything) to a real declaration, which narrows what those two responses accept at runtime. AssembledPackageBodySchema is untouched, so composeStacks is untouched
C	invert the names	make AssembledPackageBodySchema the JSON-only declaration, give the live stage a new name	a published export's meaning changes under every existing consumer with no compile-time signal; an ADR-0087 disposition becomes owed; composeStacks's own return type moves

四棱

① 项目长远合理性:B 用一个已声明的阶段替掉读 API 上那处 unknown 空洞,缩小特例;C 扩大特例(把一个已发布声明的含义就地换掉);A 不动任何东西,但把「JSON 面就写 unknown」留成先例。
② 实际业务拉动:今天只有一处真正撞上——GET /packages 行的 functions / hooks 两个键不受检。卡面所称的 ArtifactPackage / ObjectStackDefinition 掉 JSON Schema 与掉参考页,实测不是这两个分支造成的,所以真实拉动远小于卡面。
③ 防 AI 犯错:A 让下一个作者照抄 unknown 覆写,失败方向是静默容忍;B 让写错的 lowered 形状落在具名拒收里,响亮;C 最危险——同名换义,消费者编译通过而语义已变,没有任何提示。
④ 创业阶段不扩散:A 零新增永久义务;B 新增 2–3 个永久发布导出;C 既新增又搬迁一个已发布名字。按本轴 A 优于 B 优于 C。

推荐:B(回退:A)。 ⛔ 拒绝 C:它把一个已落地的已发布声明的含义在消费者脚下换掉,而这正是本仓库所有仪器都抓不到的那一类失败。

置信缺口(本分析看不见什么): 我没有对着生产行数据实测 GET /packages 这条 wire 上真实流过的 functions / hooks 值形状——只对着 toRecordManifest 的 JSON 投影推断。若真实行里存在既非 string 也非 lowered-record 的残留,B 会把今天能读的行变成拒收;A 不会。

The four axes above are this repository's own standing set (.claude/skills/pm-dispatch/references/decision-analysis.md), written in Chinese as that reference prescribes; the dispatch word carried no decision frame, so no axes were invented here.

⛔ No PR was opened: the round's finding is that neither of the card's two proposed directions should be implemented as filed, and an empty diff is the honest carrier for that. Branch claude/issue-17518-assembled-body-json-schema is pushed and carries no commits.

---

Generated by Claude Code

[os-bill]

os-dev-report

{
  "issue": 17518,
  "status": "needs_decision",
  "branch": "claude/issue-17518-assembled-body-json-schema",
  "pr": null,
  "premise_still_valid": false,
  "summary": "Empty diff, by measurement. The card's DEFECT premise is falsified: the two branches are not unreachable, they are LIVE on the path the schema declares itself for. composeStacks(stacks, { manifest: 'preserve' }) -- a published @objectstack/spec function -- builds packages[i].manifest via assemblePackageBody(), which copies the authored stack's `functions` and `hooks` VERBATIM with no lowering; measured, packages[0].manifest.functions.scoreLead is typeof 'function', functions.syncBilling.handler is typeof 'function', hooks[0].handler is typeof 'function', and BOTH ArtifactPackageSchema.safeParse and AssembledPackageBodySchema.safeParse accept that body (lit control on the same body: globs at `objects` are refused at objects.0; lowered form also accepted). stack.zod.ts:3489-3491 states the invariant that makes this binding: 'AssembledPackageBodySchema is its declaration and ObjectStackDefinitionSchema's packages key parses against it, so a body this function builds and a body the load path accepts cannot drift.' So the card's direction (a) -- narrow the two collections at the assembled body -- would make a published composition function's own output refused by the schema the same file says must accept it. Two of the card's measured consequences are also causally wrong: ArtifactPackage / ObjectStackDefinition publish no JSON Schema because stack.zod.ts is NOT one of the 15 subpath namespaces build-schemas.ts walks (measured: 1551 zod exports reached, these 4 names not reached), not because of the two branches; and ObjectStackDefinitionSchema has FOUR unrepresentable members (packages, hooks, functions, onEnable), only one of which is the assembled body, so repairing the body would not make it emit. What survives is real but smaller: an exported schema that IS in the emit loop and embeds the assembled body cannot emit, and that tax is currently paid exactly once, in packages/spec/src/api/package-api.zod.ts, with an `unknown` override its own docblock calls 'accepted without being checked'. Whether packages/spec should gain a declared INERT-JSON stage is a real fork with a real consumer cost, so it stops here with the four-facet block and one question rather than a picked side.",
  "tests": "NO CODE CHANGED -- the diff is empty, so no package is touched and neither the affected-package build closure nor the per-package test/typecheck is owed; the narrowing is declared here rather than silently taken. Run anyway as a baseline and as a control that the probe environment is sane, through scripts/pm/os-verify-lock.sh with OS_VERIFY_LOCK_SLOT=issue-17518, verdict read from the wrapper's own 'VERDICT command-exit' line: (1) pnpm --filter @objectstack/spec exec vitest run src/assembled-package-body.test.ts src/api/package-api.test.ts src/kernel/manifest-unknown-keys.test.ts --maxWorkers=2 -- VERDICT command-exit 0, 3 files / 84 tests passed. (2) pnpm --filter @objectstack/spec test:repo -- VERDICT command-exit 0, 30 files / 520 tests passed (held the lock 498s on a SHARED box, not idle-box seconds). NO ABLATION IS OWED OR PRESENTED: an ablation proves a fix can fail, and there is no fix; every reading below is instead a direct probe carrying its own lit and dark control. PROBES (all run with OS_EAGER_SCHEMAS=1 via tsx against src on head ed8dea17bd): P1 z.toJSONSchema(member,{io:'input'}) over all 55 keys of AssembledPackageBodySchema.shape -> EXACTLY 2 fail, functions ('Function types cannot be represented in JSON Schema') and hooks ('Custom types cannot be represented in JSON Schema'); whole body FAILS; .omit({functions}) FAILS on custom; .omit({hooks}) FAILS on function; .omit(both) OK; lit control z.string() OK, dark control z.function() FAILS. So the card's own table reproduces exactly on my head. P2 replicating build-schemas.ts's namespace walk over its 15 subpath imports: 1551 zod exports reached; AssembledPackageBodySchema, ArtifactPackageSchema, ArtifactPackageEntrySchema and ObjectStackDefinitionSchema are NOT among them (lit control: HookSchema, FlowFunctionEntrySchema, AssembledInstalledPackageSchema and ListInstalledPackagesResponseSchema ARE). 22 raw skips, matching the 17-entry unemitted-schemas.baseline.json plus the 5 the union-branch projection repairs. P3 running the build's OWN predicate projectByPruningUnionBranches: Data.HookSchema EMITS today (projected, io=input, pruned=[{at:'#/properties/handler/anyOf/1',type:'custom'}]) -- so the hooks z.custom branch is ALREADY handled by the landed #16431(a) projection at the published-schema level; Automation.FlowFunctionEntrySchema stays SKIPPED because its declaration branch needs a callable in a PROPERTY position, which is not droppable; lit control z.object({a:z.string()}) EMITS, dark control z.object({a:z.function()}) SKIPPED. P4 ObjectStackDefinitionSchema per-member: 44 members, 4 unrepresentable -- packages, hooks, functions, onEnable. P5 the composeStacks preserve measurement quoted in the summary. P6 FlowFunctionLoweredDeclarationSchema is a module-local const, not exported (measured against src/automation's 76 zod exports; lit controls FlowFunctionDeclarationSchema and FlowFunctionEntrySchema both present; zero exports match /Lowered/).",
  "mcp_calls": "3 -- two mcp__github__search_issues (the dedup query for the finding below, plus a control query that HIT, returning #17518 / #14242 / #17431, so the search channel was live this session) and one mcp__github__issue_write create. Every GitHub READ went through the public-repo zero-quota page-payload channel (issues 17518, 14242, 17431, 17501) and every tree read through git; the issue-body repair and this report comment went through repo-scoped REST (probed first, HTTP 200).",
  "open_questions": [
    {
      "question": "AssembledPackageBodySchema deliberately spans two stages -- the IN-MEMORY composed body, where functions and hooks legitimately hold live callables (measured), and the ON-DISK artifact body, which is inert JSON carrying only lowered string refs (hook.zod.ts:249 'The JSON artifact therefore only ever contains the string form'; flow-function.zod.ts:223 'The CLI lowers every inline callable to a serialisable string ref BEFORE the stack is parsed'). Only the second is inert JSON. Should packages/spec gain a DECLARED inert-JSON stage for it, or do the two keys stay undeclared at every JSON surface?",
      "options": [
        "A -- close as premise-falsified and change nothing; record this reading on the card. COST: the one JSON surface that needs an inert-JSON body (the GET /packages record rows) keeps functions and hooks as z.unknown(), and the next surface that wants the assembled stage either re-derives this whole analysis or copies the unknown override; 'write unknown on a JSON surface' becomes precedent. BENEFIT: zero published-surface growth, nothing landed moves, zero risk to composeStacks.",
        "B -- declare the inert-JSON stage: export the lowered function entry (FlowFunctionLoweredDeclarationSchema, today a module-local const) and an artifact-stage body whose hooks[].handler is z.string(), then rebind package-api.zod.ts's AssembledPackageRecordBodySchema to it. COST: 2-3 new permanently published exports in @objectstack/spec (clause-2 surface growth), and the read API's two keys move from unknown (accepts anything) to a real declaration, which NARROWS what those two responses accept at runtime -- a consumer serving a residual value that is neither a string nor a lowered record would start being refused. BENEFIT: the only paid instance of the tax is repaid with a declaration instead of a hole; every other key stays exactly as declared; AssembledPackageBodySchema is untouched, so composeStacks is untouched; and unemitted-schemas.baseline.json's claim that 'the lowered record -- FlowFunctionLoweredDeclarationSchema -- ... publishes normally' becomes true instead of false.",
        "C -- invert the names: make AssembledPackageBodySchema the JSON-only declaration and give the live stage a new name. COST: a published export's MEANING changes under every existing consumer with no compile-time signal; an ADR-0087 disposition becomes owed; composeStacks's own return type moves. BENEFIT: the name would match 'an artifact is inert JSON' and future JSON surfaces would be free."
      ],
      "recommendation": "B, with A as the fallback if published-surface growth is not wanted this cycle. C is refused: it changes a landed published declaration's meaning under consumers, which is the one failure mode none of the instruments in this tree can catch. The four-facet block below uses this repository's own standing axes (.claude/skills/pm-dispatch/references/decision-analysis.md) -- the dispatch word carried no decision frame, so no axes were invented."
    }
  ],
  "out_of_scope_findings": [
    "filed as #17873: os generate schema (packages/cli/src/commands/generate.ts, runSchemaGeneration) can never succeed. Its one load-bearing line is z.toJSONSchema(ObjectStackDefinitionSchema, { target: draft-2020-12 }) with no io, and the catch below it exits 1. Reproduced with that exact options object on head ed8dea17bd: THROWS Transforms cannot be represented in JSON Schema; lit control with the same call shape on z.object({a: z.string()}) returns OK. Both directions fail for different causes -- the input fallback throws Function types instead. NOT fixed by any of this card options: three of the four blocking members (hooks, functions, onEnable) are the AUTHORING stage where callables are correct, and the output-mode throw is a transform, a fourth cause again. Dedup-searched first with a lit control.",
    "noted, not filed: packages/spec/unemitted-schemas.baseline.json reason for Automation.FlowFunctionDeclarationSchema states that the lowered record FlowFunctionLoweredDeclarationSchema is the serialisable half and that it publishes normally. Measured false: it is a module-local const at flow-function.zod.ts:211, is not re-exported from src/automation, is not among the 76 zod exports build-schemas.ts reaches there, and publishes nothing. build-schemas.ts requires that reason field precisely so the author who goes looking for this schema reference page is pointed somewhere real. Not filed because option B in the question above makes the sentence true in the same edit. CARRIER: whoever takes the maintainer decision on this card -- if the answer is A, this line needs its own correction and a card is owed then.",
    "noted, not filed (platform reading, no carrier needed): MCP issue_write create STRIPS a trailing attribution block (rule line plus bare footer) from an ISSUE BODY -- measured on #17873, read back at 0 footers and 0 rule lines with the rest of the body byte-intact. A REST PATCH of the same body stores it byte-exact at exactly one footer (HTTP 200; note a PATCH without an explicit Content-Type header answers 415). This is the issue-BODY surface and does NOT generalise to the comment surface, which appends rather than strips."
  ]
}

---

Generated by Claude Code

[os-bill]

席位复核 — 采信 needs_decision,并独立重取三处承重读数

domain:spec 执行席,session session_01MkQhmuuJAVDjmeWNixwDDH,复核取数 2026-09-12T16:20Z,读的是 origin/main(先 git fetch,再 git show origin/main:PATH),⛔ 不是轮次的工作树、⛔ 不是本席记忆。

⭐ 这一轮是本席派它去测「卡面与分诊哪一个读数被树支持」的,结论是两个都不完全对 —— 卡面说「形状是维护者的选择」,分诊说「#14242 已关 ⇒ 裁决已定、是输入不是等待」;实测的答案是卡面所述的缺陷本身不成立,而它底下另有一个更小、确实属于维护者的问题。⛔ 轮次没有替维护者选边,这是它被要求做的事,不是它没做成的事。

本席逐条重取的三处承重读数(轮次的其余读数见 os-dev-report,本席采信但未逐条重跑):

1. packages/spec/src/stack.zod.ts 的不变量句,逐字核对一致:

   {@link AssembledPackageBodySchema} is its declaration and {@link ObjectStackDefinitionSchema}'s packages key parses against it, so a body this function builds and a body the load path accepts cannot drift.

   ⇒ 卡面方向 (a)(在 assembled body 上收窄那两个集合)会让一个已发布组合函数自己的输出被同一个文件声明「必须接受它」的 schema 拒收。

2. packages/spec/src/data/hook.zod.ts 的 handler 文档块,逐字核对一致:「objectstack build automatically lowers inline functions to the string form … The JSON artifact therefore only ever contains the string form.」

3. packages/spec/src/automation/flow-function.zod.ts 的 FlowFunctionLoweredDeclarationSchema 确为模块内 const(非导出),其上方文档块写着「The CLI lowers every inline callable to a serialisable string ref BEFORE the stack is parsed」。

⇒ 三处合起来给出同一个读数:AssembledPackageBodySchema 跨两个阶段 —— 内存中组合出来的 body(可调用值合法,已实测 typeof: function 且两个 schema 都 safeParse 通过),与落盘的 artifact body(inert JSON,只含 lowered 字符串 ref)。只有后者是 inert JSON,而 ADR-0130 D4 那句话约束的是 envelope 键 plugins / devPlugins,⛔ 不是「assembled body 恒为 JSON」。

⚠️ 对本席自己派发令的一处更正:派发令写着「若 #14242 + ADR-0130 D4 机械决定方向就实施」。它们确实机械地决定了一个方向不能走(a 被排除),⛔ 但没有决定该走哪一个 —— 「排除一个选项」不等于「决定一个方向」,这两件事本席在派发令里写成了一件。

---

维护者速读

一句话:这张卡报的缺陷不成立,但它底下露出一个真的选择题。

卡面说 AssembledPackageBodySchema 声明了「artifact 里不可能存在的东西」。实测不是:那两个键(functions / hooks)在内存里刚组合好、还没落盘的那个阶段是合法的活函数,而且 composeStacks 这个已发布函数就是这么产出的。真正只允许字符串的是落盘之后的 artifact。所以这一个名字同时承担了两个阶段。

卡面列的代价也测错了两条:ArtifactPackage / ObjectStackDefinition 没有 JSON Schema,原因是 stack.zod.ts 根本不在生成器扫描的 15 个入口里,和这两个分支无关;修掉分支它们也不会出现。

真正还剩下的代价只有一处:读 API 的 GET /packages 那一行里,functions 和 hooks 两个键今天写成「不检查,什么都收」。

要不要给「落盘后的 inert JSON 阶段」一个自己的声明?

• A — 不动。零新增发布面,零风险;代价是那处「不检查」继续留着,下一个要用这个阶段的接口照抄它,「JSON 面就写不检查」变成先例。
• B — 声明它(推荐)。新增 2–3 个永久发布导出,把那处「不检查」换成真声明;AssembledPackageBodySchema 一个字不动,composeStacks 不受影响。代价:那两个键从「什么都收」变成「按形状收」,如果生产数据里真有既不是字符串也不是 lowered 记录的残值,今天能读的行会开始被拒。
• C — 换名。⛔ 本席与轮次都拒绝:它把一个已发布名字的含义在消费者脚下换掉,编译不报错、语义已变,这是本仓库所有仪器都抓不到的那一类失败。

⚠️ 轮次自己声明的置信缺口(本席采信且认为是对的):没有对着生产行数据实测那条 wire 上真实流过的值形状,只对着 JSON 投影推断。若要选 B,这一测是它的前置。

要不要给落盘后的 inert JSON 阶段一个自己的声明?A(不动)、B(声明它)还是 C(换名)。

---

⛔ 无 PR,分支 claude/issue-17518-assembled-body-json-schema 已推、零 commit。卡从 pm:dispatched 转 needs-user-decision,assignee 保留(agent 会话的 presence bit,⛔ 非人工指派)。⚠️ 轮次另立了一张裸卡 #17873(os generate schema 命令恒失败,与本卡三个选项都无关,已带点亮对照去重),与本卡不折叠。

---

Generated by Claude Code