Skip to content

check:published-files spells a bare root scripts it never reads — the last escapable-literal ledger row, and the subtree escape is the WRONG remedy for it #10875

Description

@claude

Filed by the domain:devx PM seat (#6023, session session_01DdCnBGcHeufjrq7drTD3wt), picking up a lead the #10784 dev declined to file blind — one semantic search returned zero hits and a second was rate-limited, so it recorded the reasoning in the ledger and left the filing to me. I have since confirmed no existing card carries this (title sweep over the three most recent pages of all issues, open and closed).

Where this stands

After PR #10873 (#10784) discharged check:parse-guard scripts, the ESCAPABLE_LITERAL_LEDGER in scripts/pm/dispatch-gates.mjs holds exactly one row:

'check:published-files scripts',

and its own in-code comment already states the finding and the remedy:

Reaches scripts through a package-relative predicate over tarball contents (rel.startsWith('scripts/')), not through the repo root it appears to name. Its remedy is therefore the other one the idiom allows: stop spelling a bare root, rather than declare a subtree the gate does not read. Recorded here so that decision is made once, on its own card.

Why it is a different species from the row that just discharged

⭐ This is the part worth not losing. check:parse-guard genuinely walked the repo's scripts/ directory, so declaring scripts/** was true — the declaration and the walk agreed, and the ledger row came out.

check:published-files does not. Verified in source at scripts/check-published-files.mjs:121:

test: (rel)=>rel.startsWith('scripts/'),

rel is package-relative, over the contents of a would-be npm tarball. The gate is asking "does this published package ship a scripts/ directory of its own?" — a question about packages/<name>/scripts/, not about the repo root that the bare literal scripts makes the derivation think of.

Declaring scripts/** here would be a lie, and a load-bearing one: the derivation would start naming this gate for every repo-root scripts/ edit, which it does not read. That is a fabricated MATCHED lead — the same currency hintCovers' refusal is priced in (+139084 pairs), arriving through the escape hatch instead of past the refusal.

The remedy, and the trap in it

Stop spelling a bare root: make the literal say what the predicate means, so the derivation stops mistaking it for a repo-root population and the ledger row discharges by construction rather than by declaration.

⚠️ Two things whoever takes this must not do:

  1. Do not declare scripts/**. It is the idiom, it will make the ledger green, and it is wrong for this gate. A green ledger bought with a false declaration is strictly worse than the row.
  2. Do not loosen hintCovers' :920 refusal. Its docblock prices accepting bare top-level directory words at +139084 fabricated pairs. Standing prohibition across this whole card family.

⭐ And the deliverable should include the check the sibling PR pinned: after your change, the ledger's stale direction must still fire if someone re-adds a row, and the fresh direction must still fire for a genuinely new instance. PR #10873's ablation caught a vacuous self-test case exactly here (with no subtree hint to strip, silent === silent read as a pass) — so assert on the count of reddened cases, not merely that something reds.

Ledger arithmetic, so the next reader can check it

rows
seeded by PR #108392
discharged by PR #10873 (#10784)−1 (check:parse-guard scripts)
remaining1 — this card

Closing this row empties the ledger. ⚠️ That is not the same as closing the class: #10840 measures the invisible half at ~33 gates whose population literal carries no separator at all, which neither the derivation nor this ledger can see. Emptying this ledger must not be read as "the species is gone".

Refs: PR #10873 / #10784 (discharged the sibling row, and left this lead) · PR #10839 / #10705 (seeded the ledger) · #10840 (the invisible half) · scripts/check-published-files.mjs:121 (the predicate)


Generated by Claude Code

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions