Skip to content

[finding] Three files still tell authors check:cross-package-test-inputs recognises "exactly two seeds" — it recognises five, and the prose is load-bearing #10163

Description

@os-warren

Observation-class finding, measured while implementing #10029 (PR #10161). No gate is red today. Filed unassigned, no pm:queue.

Measured

scripts/check-cross-package-test-inputs.mjs resolves seed expressions in pathExpression(). On 2d3860df9 it recognises five directory-seed spellings, not two:

spellingwhere
dirname(fileURLToPath(import.meta.url)):631
__dirname:634
import.meta.dirname:637
dirname(import.meta.filename):638-640
import.meta.url / import.meta.filename (the FILE, walked at hereDepth + 1):653

plus new URL('<rel>', import.meta.url) as a seeded chain step (:661). The gate's own RECOGNISED_PATH_SPELLINGS (:493-505) — printed in its failure text — lists all of them correctly. #8995 and #9763 widened the set after the "two seeds" wording was written.

Three files outside the detector still tell the reader there are two:

  • packages/plugins/plugin-auth/src/managed-extension-fields.test.ts:306
  • packages/platform-objects/src/managed-api-method-affordance-sweep.test.ts:104
  • scripts/check-type-check-coverage.mjs:755"…is one of the two seeds check:cross-package-test-inputs recognises…"

Why it is worth recording rather than shrugging at

This is not idle prose. In both test files the sentence is the stated reason a specific seed may not be changed — it is what stops a future edit from making that package's declared radius invisible and reopening #7802's blind spot. A reader who checks the claim against the detector finds it false, and a reason that does not survive checking is a weak guard for a rule that matters. The check-type-check-coverage.mjs instance is worse-placed still: it is failure text an author reads at the moment they are choosing a seed, and it under-reports their options by three.

The drift direction is benign — the prose is narrower than the detector, so following it is still correct — which is exactly why nothing has caught it. Both extensions (#8995, #9763) updated RECOGNISED_PATH_SPELLINGS, which is the list the gate prints; neither swept for the count restated in prose elsewhere.

Related, and NOT the same claim

managed-extension-fields.test.ts:306-311 also says its walk is "the ONLY escaping read the gate can see in plugin-auth". PR #10161 makes that false by making rate-limit-storage-isolation.test.ts visible too:

$ node scripts/check-cross-package-test-inputs.mjs --list-escapes
@objectstack/plugin-auth (packages/plugins/plugin-auth)
packages/plugins/plugin-auth/src/managed-extension-fields.test.ts
packages/plugins/plugin-auth/src/rate-limit-storage-isolation.test.ts

That file was deliberately left untouched by #10161 (it is a hot single surface, and its load-bearing half — that it alone holds the packages/**/*.object.ts glob — stays true, since the rate-limit test holds only the two new consumer globs). Only the incidental "only" is now stale, so it belongs here with the rest of the sweep rather than as a rider on that PR.

Directions (not a decision)

  • A — correct the count in all three places and the "only" in the one, pointing at RECOGNISED_PATH_SPELLINGS as the single source rather than restating a number that drifts. Small, and removes the restatement that caused this.
  • B — additionally add a gate: no file outside the detector may restate the seed count. Retires the class; probably more machinery than the class is worth.
  • C — leave it recorded. The drift is in the safe direction.

A is cheap and is what stops the next extension from producing a fourth stale copy.

Refs

#10029 / PR #10161 (where this was measured) · #8995 and #9763 (the extensions that widened the set) · #7802 (the blind spot the prose guards against)


Generated by Claude Code

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions