Found by the per-edge audit on #14013 (provenance; that card is an audit, ⛔ not a fix, so this is filed separately per its triage fence). Measured on a39b02a6b.
The claim and the code disagree
scripts/pm/dispatch-gates.mjs, in the fourth-edge docblock above packageManifestTargets (around line 5273), opens:
The three follows above all end at a PROGRAM — a module the gate imports, a file whose program text it opens, a program it spawns — and inherit that program's declared population.
The middle one does not. readProgramTargetsInSource fills entry.reads / entry.readOrigin, and nothing ever feeds those into hintsOfModule. discoverFamilies runs three population follows — entry.imports (label import), entry.runs (label run), entry.manifests (label manifest) — and there is no fourth loop over entry.reads. coveringKey's edge-label map is literally two entries, run and manifest.
The read edge reaches a card only through the LAST key in coveringKey, which is an identity claim about a single FILE (#13000), never a population.
Measured on this tree:
EDGE import: 27 famil(ies), 37 (family,target) pairs
EDGE run: 1 famil(y), 1 pair
EDGE manifest: 10 famil(ies), 10 pairs
EDGE read: 12 famil(ies), 16 pairs, 15 distinct targets
INHERITED HINTS BY EDGE LABEL:
import: 369 hint(s) across 13 famil(ies)
manifest: 7 hint(s) across 7 famil(ies)
run: 1 hint across 1 famil(y)
read: 0
The two numberings inside the one file also disagree, which is the second half of the evidence: discoverFamilies calls the spawn follow the SECOND edge and the manifest follow the THIRD (a numbering in which the read edge is not a follow at all), while the docblock above packageManifestTargets calls the manifest one the FOURTH (a numbering in which it is).
⛔ The repair is the PROSE, not the behaviour — that half is measured too
Following the read edge for population the way run and manifest are followed would add 54 hints across 6 families; 12 of those come from targets that are themselves discovered gate files and would be refused by the rule both other follows already make, leaving 42 across 4 families. Those 42 are fabrication-shaped, not leads:
- 29 come from
packages/runtime/src/dispatcher-error-vocabulary.ts into check:dispatcher-error-vocabulary. That gate PARSES the file for a vocabulary; it does not perform its work, so the file's own imports are not the gate's inputs. apps/docs/source.config.ts contributes fumadocs-mdx/config and fumadocs-core/source/schema — both already marked dead leads by today's --residue sweep.scripts/bump-objectui.sh contributes packages/console/dist (a build output) and one specific .changeset/console-*.md.
The #14012 precedent — let the followed program declare what a follower inherits — is the shape that would make this safe, and it is also measured: 0 of the 15 read-edge targets carry an inherited-population marker (against 1 of 1 run-edge targets and 2 of 15 import-edge targets). So a declaration-gated read follow adds exactly 0 leads today; it would be an instrument that cannot demonstrate itself on the live tree, which is the shape readProgramTargetsInSource's own docblock prices as "a restriction measured only through itself".
⇒ Reading a program's TEXT is not performing its work. Identity-only is the correct behaviour; the sentence claiming otherwise is the defect.
Suggested repair
Correct the fourth-edge docblock so it names what the read edge actually contributes (an identity key, #13000) rather than a population, and reconcile the two edge numberings so a reader is not told there are three population follows when there are three follows and one identity key. No behaviour change.
Re-check
node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --residue scripts/pm/dispatch-gates.mjs
⚠️scripts/pm/dispatch-gates.mjs changes several times a day — re-derive rather than quoting any figure above.
Found by the per-edge audit on #14013 (provenance; that card is an audit, ⛔ not a fix, so this is filed separately per its triage fence). Measured on
a39b02a6b.The claim and the code disagree
scripts/pm/dispatch-gates.mjs, in the fourth-edge docblock abovepackageManifestTargets(around line 5273), opens:The middle one does not.
readProgramTargetsInSourcefillsentry.reads/entry.readOrigin, and nothing ever feeds those intohintsOfModule.discoverFamiliesruns three population follows —entry.imports(labelimport),entry.runs(labelrun),entry.manifests(labelmanifest) — and there is no fourth loop overentry.reads.coveringKey's edge-label map is literally two entries,runandmanifest.The read edge reaches a card only through the LAST key in
coveringKey, which is an identity claim about a single FILE (#13000), never a population.Measured on this tree:
The two numberings inside the one file also disagree, which is the second half of the evidence:
discoverFamiliescalls the spawn follow the SECOND edge and the manifest follow the THIRD (a numbering in which the read edge is not a follow at all), while the docblock abovepackageManifestTargetscalls the manifest one the FOURTH (a numbering in which it is).⛔ The repair is the PROSE, not the behaviour — that half is measured too
Following the read edge for population the way
runandmanifestare followed would add 54 hints across 6 families; 12 of those come from targets that are themselves discovered gate files and would be refused by the rule both other follows already make, leaving 42 across 4 families. Those 42 are fabrication-shaped, not leads:packages/runtime/src/dispatcher-error-vocabulary.tsintocheck:dispatcher-error-vocabulary. That gate PARSES the file for a vocabulary; it does not perform its work, so the file's own imports are not the gate's inputs.apps/docs/source.config.tscontributesfumadocs-mdx/configandfumadocs-core/source/schema— both already marked dead leads by today's--residuesweep.scripts/bump-objectui.shcontributespackages/console/dist(a build output) and one specific.changeset/console-*.md.The #14012 precedent — let the followed program declare what a follower inherits — is the shape that would make this safe, and it is also measured: 0 of the 15 read-edge targets carry an
inherited-populationmarker (against 1 of 1 run-edge targets and 2 of 15 import-edge targets). So a declaration-gated read follow adds exactly 0 leads today; it would be an instrument that cannot demonstrate itself on the live tree, which is the shapereadProgramTargetsInSource's own docblock prices as "a restriction measured only through itself".⇒ Reading a program's TEXT is not performing its work. Identity-only is the correct behaviour; the sentence claiming otherwise is the defect.
Suggested repair
Correct the fourth-edge docblock so it names what the read edge actually contributes (an identity key, #13000) rather than a population, and reconcile the two edge numberings so a reader is not told there are three population follows when there are three follows and one identity key. No behaviour change.
Re-check
scripts/pm/dispatch-gates.mjschanges several times a day — re-derive rather than quoting any figure above.