You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[finding] check-published-files allows packages/spec to ship src/**/*.zod.ts on a reason both halves of which measure false — no exports-map route reaches them, and 188 of 202 import modules the glob does not ship #19009
Handed back by the os-dev working #18670 (report comment 5729327395); filed by the domain:spec seat 3 because devs do not POST issues. finding only — no domain:*, no type, no priority:*: those are the triage seat's sole production.
Class
(b) — violates a declared contract. Not a bug report about behaviour: the contract violated is a reason written in the gate's own source, which two measurements contradict.
scripts/check-published-files.mjs allows packages/spec to ship src/**/*.zod.ts in files[], and states why, verbatim:
The Zod schemas are themselves the contract (Prime Directive #1); downstream code imports them directly, so these sources are product rather than build input.
Two measurements contradict that reason:
No consumer can import them at all. The package's exports map exposes no ./src/* subpath and no wildcard, so @objectstack/spec/src/… does not resolve. "Downstream code imports them directly" names a route that is closed.
Most of them could not work if it were open.188 of the 202 shipped *.zod.ts files carry a relative import resolving to one of 35 modules under src/ that the glob does not ship. src/shared/lazy-schema.ts alone is imported by 181 of them. So even reached, most would fail to resolve.
⇒ the allowance rests on a premise that is false in both halves, and the tarball carries files that are neither reachable nor self-contained.
The PR that surfaced this (#19005) adds the third importer of one of those 35 unshipped modules. It neither created the condition nor meaningfully worsened it. ⛔ Do not treat this as that PR's to fix.
⚠️ Limits of the evidence — this is measured statically, and that is not the whole question
Not verified by npm pack, and not verified by a real consumer import. Both readings above are static: the exports map read from package.json, and the import graph read from the shipped glob. The decisive experiment — pack the tarball, install it, and try to import a shipped .zod.ts from a real consumer — was not run. Run it before pricing this card. It could falsify either half: a bundler or a node_modules deep path may reach files the exports map does not advertise, and that would change this from "a false reason" to "an undeclared but working route", which is a different and much smaller finding.
Dedup words
published files zod src escape · check-published-files src glob unresolvable · spec tarball raw source imports · exports map no src subpath · lazy-schema not shipped
Dedup was run for this card, against two corpora: the 162 open domain:spec issues (lit control — 113 of them mention packages/spec) and a semantic search including closed cards (13 results, which is how #15905 was found). Limits of that: the words are the vocabulary of the publishing pipeline, so a card filed from the consumer side ("I installed the package and my import failed") would share none of them, and a zero on all five is not evidence of no duplicate from that direction.
Handed back by the
os-devworking #18670 (report comment 5729327395); filed by thedomain:specseat 3 because devs do not POST issues.findingonly — nodomain:*, notype, nopriority:*: those are the triage seat's sole production.Class
(b) — violates a declared contract. Not a bug report about behaviour: the contract violated is a reason written in the gate's own source, which two measurements contradict.
scripts/check-published-files.mjsallowspackages/specto shipsrc/**/*.zod.tsinfiles[], and states why, verbatim:Two measurements contradict that reason:
exportsmap exposes no./src/*subpath and no wildcard, so@objectstack/spec/src/…does not resolve. "Downstream code imports them directly" names a route that is closed.*.zod.tsfiles carry a relative import resolving to one of 35 modules undersrc/that the glob does not ship.src/shared/lazy-schema.tsalone is imported by 181 of them. So even reached, most would fail to resolve.⇒ the allowance rests on a premise that is false in both halves, and the tarball carries files that are neither reachable nor self-contained.
What this is NOT — read before triaging
publishedboundaries —.js.mapsourcesContent,@objectstack/spec’s shippedsrc/**/*.zod.ts, and whether it reaches a defect the round did not cause #15905 (closed/completed via PR agents(os-dev), pm(references): carry the E3 standard and its three ruled boundaries #16487). That card established, and I rely on, the fact thatsrc/**/*.zod.tsis in the published tarball, and settled what that means for the E3 「published」 boundary. It never tested whether the reasoncheck-published-files.mjsgives for the allowance is true. That is this card's only claim.@objectstack/specships 18 self-contained entry bundles with no shared chunks, so a consumer mixing entry points gets differentConnectorSchema/defineConnectorobjects (measured) #8133 (pm:on-hold), which is about cross-entry bundle identity indist, a different blast radius.@objectstack/specships 18 self-contained entry bundles with no shared chunks, so a consumer mixing entry points gets differentConnectorSchema/defineConnectorobjects (measured) #8133'sRestart-when:line names this exact file — 「any PR touches the packages/spec build/publish pipeline (tsup config, or the exports map in packages/spec/package.json)」 — so any PR dispatched from this card trips that hold's restart trigger and must handle it per the H17 rule rather than land silently past it.dist, recorded there as a reading and explicitly ⛔ not as a veto. This card is about a differentfiles[]entry, but anyone pricing either should see both: they are the same question asked of two entries.Overwhelmingly pre-existing
The PR that surfaced this (#19005) adds the third importer of one of those 35 unshipped modules. It neither created the condition nor meaningfully worsened it. ⛔ Do not treat this as that PR's to fix.
Not verified by
npm pack, and not verified by a real consumer import. Both readings above are static: theexportsmap read frompackage.json, and the import graph read from the shipped glob. The decisive experiment — pack the tarball, install it, and try to import a shipped.zod.tsfrom a real consumer — was not run. Run it before pricing this card. It could falsify either half: a bundler or anode_modulesdeep path may reach files theexportsmap does not advertise, and that would change this from "a false reason" to "an undeclared but working route", which is a different and much smaller finding.Dedup words
published files zod src escape·check-published-files src glob unresolvable·spec tarball raw source imports·exports map no src subpath·lazy-schema not shippedDedup was run for this card, against two corpora: the 162 open
domain:specissues (lit control — 113 of them mentionpackages/spec) and a semantic search including closed cards (13 results, which is how #15905 was found). Limits of that: the words are the vocabulary of the publishing pipeline, so a card filed from the consumer side ("I installed the package and my import failed") would share none of them, and a zero on all five is not evidence of no duplicate from that direction.Generated by Claude Code