Decide whether `os build` should compute the four structural advisories `os validate` raises (measured: missing computation, not a dropped list)

[os-zhuang]

Split out of #11727 so the question survives that card closing. #11727 fixed the
two genuinely dropped advisory lists on the os build --json payload
(capability-provider #3366, package-docs ADR-0046). This third item is a
different shape and was deliberately not ported there.

Measured

At origin/main 589758d22:

• packages/cli/src/commands/validate.ts computes four structural advisories
  and carries them in both faces:

  No objects defined — this stack has no data model
  No apps or plugins defined — this stack may not do much
  Missing manifest.id — required for deployment
  Missing manifest.namespace — required for multi-app hosting
  

  They were themselves the subject of [finding] os validate --json never carries the four inline non-blocking warnings the text summary prints (no objects / no apps+plugins / missing manifest.id / missing manifest.namespace) #10953, which hoisted them above the
  if (flags.json) branch so the machine face could reach them.

• packages/cli/src/commands/compile.ts computes none of them, in any
  face. None of those four strings appears in the file.

So this is a missing computation, not a list computed and then discarded —
which is why it takes a different fix from #11727's two and is a judgment call
rather than a mechanical port.

What makes it cheap, and what makes it a judgment

The inputs are already present and identical. Both commands call the same
helper on the same object:

const stats = collectMetadataStats(config); // compile.ts and validate.ts alike

compile.ts already publishes that stats object in its --json payload. So
the four conditions are derivable at the build site with no new input — the
open question is not feasibility, it is whether they belong there:

• For: a CI consumer reading warnings off os build --json still gets a
  strictly smaller advisory set than os validate --json on the same tree, and
  the remaining difference is exactly these four. That residual difference is
  the same class of surprise os build --json also drops the capability-provider and package-docs warnings that os validate --json carries #11727 closed for the other two lists.
• Against: os build writes an artifact. "No apps or plugins defined" and
  "No objects defined" describe a stack that builds perfectly well, and the
  build path has never claimed to be a completeness review — that is what
  os validate is for. Adding them makes every artifact build for a
  library-shaped or plugin-shaped package advise about absent apps.

There is a scope-discipline angle too: this widens what the build command
asserts about a stack, for a consumer that can already run os validate --json
and get exactly these four.

Current state after #11727

The residue is pinned rather than left implicit —
packages/cli/test/build-json-advisory-parity.e2e.test.ts asserts that the
ONLY member os validate --json reports and os build --json does not is the
structural set. Whichever way this is decided, that pin is the thing to update:
porting them turns it red on purpose, so the decision gets made in the open,
and meanwhile a fifth genuinely dropped list cannot hide in the gap.

Filed unassigned and unlabelled; severity and lane are triage's call.

---

Generated by Claude Code

[os-zhuang]

Triage: routed to the decision inbox (needs-user-decision + domain:cli, type Feature — the machine boundary test reads "add four advisories to the build payload" as widening what os build asserts, which is the manual floor). 四维分析(从业务角度):

① 项目长远合理性:validate 与 build 的分工是长期契约 —— build 是产物门,validate 是完整性审查。把完整性建议并入 build 会扩大 build 的断言面(特例增生);维持现状则保住「一个问题一个门」的清晰分界。
② 实际业务拉动:零。今天没有任何消费者报告撞上这个差异;#11727 修的两类是「算了又丢」的真缺陷,这四条是 validate 专属计算,从未在 build 面承诺过。library/plugin 形态的包每次 build 都会收到「没有 apps」的无关建议,反而是新噪声。
③ 防 AI 写代码犯错:现状已闭合 —— parity pin(build-json-advisory-parity.e2e.test.ts)钉死「唯一允许的差异 = 这四条」,第五类真掉落无法藏进缝里;移植会训练消费端把结构建议当 build 常态噪声容忍。
④ 创业阶段不扩散需求:不加。消费者今天就能用 os validate --json 拿到全部四条,零新能力面,零新维护义务。

推荐 B。选项:A = 把四条结构建议移植进 os build --json(pin 翻转,决策公开);B = 维持现状,本卡以「已裁不移植」关闭,parity pin 继续钉住残差。
置信缺口:本分析看不见 out-of-tree CI 管道是否存在只读 os build --json 的 warnings 并依赖其完整性的消费者。

<!-- os-decision-facets -->

---

Generated by Claude Code

[os-support-ai]

Maintainer ruling — B: not ported; the parity pin stays the record

Source: maintainer, 2026-08-25, live PM chat (decision-inbox batch 3 review, session session_01KWRU3s15AJz7PGW7a7wdCh), verbatim: 「同意」 — accepting the batch's presented recommendation for this card: B — os build does not compute the four structural advisories.

Grounds as presented and accepted: the build/validate division of labour is the long-term contract (build gates the artifact, validate reviews completeness); zero measured pull; library- and plugin-shaped packages would receive irrelevant "no apps" advisories on every build; and the residue is already closed by identity — packages/cli/test/build-json-advisory-parity.e2e.test.ts pins that the ONLY member os validate --json reports and os build --json does not is exactly this structural set, so a fifth genuinely-dropped list cannot hide in the gap.

Recorded reopening condition (the analysis's stated blind spot): an out-of-tree CI consumer that reads warnings off os build --json and depends on its completeness — such a report reopens this with evidence.

Closing completed (ruled: not ported); needs-user-decision off in the same write.

---

Generated by Claude Code