Observation found while implementing #10428 (fixing the spec-blob vacuity path). Filed rather than fixed there: it is a different input — the stamp's shape, not the tree's spec — and whether it should fail is a judgement call rather than something existing evidence pins, so it did not qualify for an in-scope fix.
What I measured
readStamp() in scripts/console-spec-probes.mjs shape-checks parsed.packages with Array.isArray(...), which accepts []. A dist stamped {"stampVersion": 1, "packages": []} then reaches the end of evaluate() with asserted === 0, prints
ℹ Nothing assertable in this stamp; the dist was not contradicted.
and exits 0 — including under --require-stamp.
That is structurally the same shape #10428 closed one input over: a run that satisfies --require-stamp while making no assertion at all about the artifact it is guarding. --require-stamp currently proves a stamp exists and is well-formed, not that it says anything.
Why it is not urgent
Not reachable from the real producer. scripts/assert-console-spec-injection.mjs calls writeStamp(distDir, [...]) at exactly one site (line 119) with a single hard-coded @objectstack/spec entry, and both of its exit paths (skew and no-skew) go through it. So an empty packages array today means a hand-assembled, truncated, or corrupted stamp — not any output this repo produces. The no-skew case is a populated entry with skew: false, which is handled separately and honestly.
That also makes it cheap to keep as-is deliberately, which is why this is a finding and not a queued bug: someone should decide whether "a stamp that asserts nothing" is a state --require-stamp ought to refuse, or one it is right to tolerate on the same reasoning that lets a no-skew stamp pass.
Shape if it is taken
Under --require-stamp only, treat stamp.packages.length === 0 as a refusal with the same remedy block the other --require-stamp failures print. The bare invocation should keep its ℹ, matching how #10428 left the unbuilt-spec notice in place for a bare checkout.
Refs: #10428 (the sibling vacuity path, fixed) · #9706 · #9667
Observation found while implementing #10428 (fixing the spec-blob vacuity path). Filed rather than fixed there: it is a different input — the stamp's shape, not the tree's spec — and whether it should fail is a judgement call rather than something existing evidence pins, so it did not qualify for an in-scope fix.
What I measured
readStamp()inscripts/console-spec-probes.mjsshape-checksparsed.packageswithArray.isArray(...), which accepts[]. A dist stamped{"stampVersion": 1, "packages": []}then reaches the end ofevaluate()withasserted === 0, printsand exits 0 — including under
--require-stamp.That is structurally the same shape #10428 closed one input over: a run that satisfies
--require-stampwhile making no assertion at all about the artifact it is guarding.--require-stampcurrently proves a stamp exists and is well-formed, not that it says anything.Why it is not urgent
Not reachable from the real producer.
scripts/assert-console-spec-injection.mjscallswriteStamp(distDir, [...])at exactly one site (line 119) with a single hard-coded@objectstack/specentry, and both of its exit paths (skew and no-skew) go through it. So an emptypackagesarray today means a hand-assembled, truncated, or corrupted stamp — not any output this repo produces. The no-skew case is a populated entry withskew: false, which is handled separately and honestly.That also makes it cheap to keep as-is deliberately, which is why this is a
findingand not a queued bug: someone should decide whether "a stamp that asserts nothing" is a state--require-stampought to refuse, or one it is right to tolerate on the same reasoning that lets a no-skew stamp pass.Shape if it is taken
Under
--require-stamponly, treatstamp.packages.length === 0as a refusal with the same remedy block the other--require-stampfailures print. The bare invocation should keep itsℹ, matching how #10428 left the unbuilt-spec notice in place for a bare checkout.Refs: #10428 (the sibling vacuity path, fixed) · #9706 · #9667