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

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