Skip to content

[finding] a pinned NON-rule in packages/spec justifies itself with a record-validator.ts line number that is 319 lines off, and nothing checks prose line anchors #16441

Description

@claude

Found by the #16159 round while checking the line-number-anchor family for its own diff. ⛔ Observation, not a runtime defect: the pins still pass and the code they describe is unchanged. ⛔ It is not caused by that PR — every reading below is taken on origin/main ac76425f0, before it. No assignee, no pm:queue; triage grades it.

The rot, in live spec source

packages/spec/src/kernel/functional-completeness.ts and its test cite packages/objectql/src/validation/record-validator.ts by line number to justify a pinned NON-rule — the decision that multiselect without options is deliberately not flagged:

packages/spec/src/kernel/functional-completeness.ts:38    `select`/`radio` w/o `options` -> `record-validator.ts:452`
packages/spec/src/kernel/functional-completeness.ts:41    NON-rule: `multiselect` w/o `options` - `record-validator.ts:471`
packages/spec/src/kernel/functional-completeness.ts:108   `record-validator.ts:452` skips validation on an empty list
packages/spec/src/kernel/functional-completeness.test.ts:12   `record-validator.ts:471`
packages/spec/src/kernel/functional-completeness.test.ts:103  `record-validator.ts:471, verbatim: "free-form (tags without options)"`

Measured on origin/main:

citation what it claims lives there where that text actually is drift
record-validator.ts:471 free-form (tags without options), quoted verbatim line 790, and the string occurs exactly once in the file 319 lines
record-validator.ts:452 the allowed.length empty-list gate allowed.length > 0 at line 772 320 lines

Line 471 on origin/main reads for (const [name, def] of Object.entries(objectSchema.fields)) {, and line 452 is blank.

Why this one is worth a card and the audit-doc ones below are marginal

⭐ The test's own comment states the rule that makes this load-bearing:

The runtime blesses this as a mode; flagging it would be a false prescription. If product direction ever changes, change the runtime first — this pin makes the lint follow the code, never lead it.

That discipline is executed by a human reading the citation. The assertion itself (expect(checkFieldCompleteness({ type: 'multiselect' })).toEqual([])) cannot notice that the runtime moved, so the citation is the only limb that ties the pin to the code it claims to follow — and it currently points 319 lines away from the sentence it quotes. This is the shape the liveness ledger already names in its own notes as "the plausible-neighbour shape of citation rot": the line still looks like plausible code, so nothing reads as broken.

⚠️ The quoted text itself is still true and still present, so this is a repointing job, not a re-decision: the NON-rule is intact.

Six more, lower stakes, listed so the census is complete

docs/audits/2026-06-fieldschema-property-liveness.md:30 (:127,130), docs/audits/2026-06-metadata-functional-completeness.md:68 (:205,212) and :69 (:222-225), docs/audits/2026-07-naming-drift-recheck.md:27 (:243-247), packages/rest/src/rest-hook-script-fault-envelope.test.ts:45 and :401 (:503-504). Each was checked line by line and none resolves to the content it claims. These are dated audit snapshots and a test comment rather than live justification, which is why they are named here and not argued for.

What no gate covers, which is the actual gap

check:system-context-census enforces path:NNN anchors for its own elevation-read population and is green; nothing enforces a path:NNN written in ordinary prose or in a comment. ⇒ every anchor above rotted silently, and any diff that changes a line count anywhere in a cited file rots more without a word. Whether that is worth a gate, a convention (cite a SYMBOL or a verbatim snippet, never a line — which is what packages/spec/liveness/field.json already does), or nothing at all, is the question this card is really asking.

Refs: #16159 · packages/spec/src/kernel/functional-completeness.ts · packages/spec/liveness/field.json


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions