Found while fixing #11642 (remainder notices for the truncating renders in build / validate / init). Out of that card's scope — it is a --jsonpayload shape question, the machine-contract class that card was explicitly fenced away from — but it is the one thing that can make those notices' remedy untrue, so it is recorded rather than fixed.
Adjacent to #11727 and NOT the same defect: that one is about two advisory lists computed under a !flags.json guard and therefore unreachable for the machine face at all. This one is about lists that do reach the payload — on one exit only.
Measured (read from source at origin/main945ffbea8; not executed)
packages/cli/src/commands/compile.ts publishes its advisory lists in the terminal success payload:
warnings: [...ruleAdvisories, ...unknownKeyWarnings],
Every earlier emitJson(...) in the same command is a failure payload with its own shape, and none of them carries warnings:
| exit | payload keys | carries warnings? |
|---|
strict-body: missing body | issues | no |
author-time rules failed | issues, warnings | yes |
capability provider preflight failed | issues | no |
access matrix drift | changes | no |
docs validation failed | issues | no |
runtime bundle failed | error | no |
| success | warnings, bodyExtractionWarnings, … | yes |
The text face prints the advisory blocks before those later gates run: the author-time advisories at step 3b, the undeclared-authoring-key findings at 3d, then the access-matrix gate at 3e and the package-docs gate at 3f.
Why it matters now
Since #11645 the advisory printer ends with — re-run with --json for the full list, and #11642 gives the undeclared-key block the same pointer (honest because #11643 put that list in the payload). Both are true only for a run that reaches the end. On a tree with, say, 60 undeclared authoring keys and a package-docs error:
os build prints Undeclared authoring keys (60), 50 rows, and … and 10 more undeclared authoring key(s) not shown (50 of 60) — re-run with --json for the full list, then fails at the docs gate;os build --json emits {"success":false,"error":"docs validation failed","issues":[…]} — the 60 keys are nowhere in it.
So the remedy the notice names returns a payload that does not contain the list, which is the "the remedy named is unreachable" shape #11643 and #11391 were about. The author cannot see the withheld entries by any route until the unrelated later failure is fixed.
Not proposed here
Which way to close it is a real decision, not a mechanical port, and it is a machine-contract change either way:
- carry the advisory lists on every failure payload (largest change; makes every exit's
warnings mean the same thing); - carry them only where the text face has already printed them (smaller, but the payload's shape then depends on how far the run got);
- leave the payload alone and weaken the pointer to name the condition.
Option 3 is the only one that touches no machine contract, and it is the one that makes the CLI's output worse, so it should not win by default.
Filed unassigned, no labels — severity and route are triage's call.
Found while fixing #11642 (remainder notices for the truncating renders in
build/validate/init). Out of that card's scope — it is a--jsonpayload shape question, the machine-contract class that card was explicitly fenced away from — but it is the one thing that can make those notices' remedy untrue, so it is recorded rather than fixed.Adjacent to #11727 and NOT the same defect: that one is about two advisory lists computed under a
!flags.jsonguard and therefore unreachable for the machine face at all. This one is about lists that do reach the payload — on one exit only.Measured (read from source at
origin/main945ffbea8; not executed)packages/cli/src/commands/compile.tspublishes its advisory lists in the terminal success payload:Every earlier
emitJson(...)in the same command is a failure payload with its own shape, and none of them carrieswarnings:warnings?strict-body: missing bodyissuesauthor-time rules failedissues,warningscapability provider preflight failedissuesaccess matrix driftchangesdocs validation failedissuesruntime bundle failederrorwarnings,bodyExtractionWarnings, …The text face prints the advisory blocks before those later gates run: the author-time advisories at step 3b, the undeclared-authoring-key findings at 3d, then the access-matrix gate at 3e and the package-docs gate at 3f.
Why it matters now
Since #11645 the advisory printer ends with
— re-run with --json for the full list, and #11642 gives the undeclared-key block the same pointer (honest because #11643 put that list in the payload). Both are true only for a run that reaches the end. On a tree with, say, 60 undeclared authoring keys and a package-docs error:os buildprintsUndeclared authoring keys (60), 50 rows, and… and 10 more undeclared authoring key(s) not shown (50 of 60) — re-run with --json for the full list, then fails at the docs gate;os build --jsonemits{"success":false,"error":"docs validation failed","issues":[…]}— the 60 keys are nowhere in it.So the remedy the notice names returns a payload that does not contain the list, which is the "the remedy named is unreachable" shape #11643 and #11391 were about. The author cannot see the withheld entries by any route until the unrelated later failure is fixed.
Not proposed here
Which way to close it is a real decision, not a mechanical port, and it is a machine-contract change either way:
warningsmean the same thing);Option 3 is the only one that touches no machine contract, and it is the one that makes the CLI's output worse, so it should not win by default.
Filed unassigned, no labels — severity and route are triage's call.