Three objectql/engine.ts:NNNN citations in the same published doc block #16441 just repaired point 513 to 5,677 lines away from the text they quote. They were outside #16441's census, which enumerated record-validator.ts anchors only, so they survived that repair untouched — and the next PR to touch this doc block inherits them silently.
Handed over by the os-dev on #16441 as an out-of-scope finding (承接者 named as the PM). ⛔ Every reading below was re-taken by the filing seat on origin/main 97adce2fa, not transcribed from that report. Filed unrouted and ungraded — ⛔ this seat does not produce domain:*, a grade or a type; that is triage's.
Measured
packages/spec/src/kernel/functional-completeness.ts, module doc block, on the post-#16441 head 85bb9dad9f (so this is what lands, not what was there before):
:31 * - `summary` w/o `summaryOperations` → `objectql/engine.ts:3001`
:33 * - `formula` w/o `expression` → `objectql/engine.ts:346` builds the formula
:35 * - `lookup`/`master_detail` w/o `reference` → `objectql/engine.ts:3191`
packages/objectql/src/engine.ts is 15,020 lines. Each cited text occurs exactly once in it:
| citation |
text it claims lives there |
actual line |
drift |
engine.ts:3001 |
if (d?.type !== 'summary' || !d.summaryOperations) continue; |
8520 |
5,519 |
engine.ts:3191 |
if (!referenceObject) continue; |
8868 |
5,677 |
engine.ts:346 |
the formula-plan build, def?.type === 'formula' && def.expression |
859 |
513 |
Uniqueness control, so "the text is at line N" is a reading and not an artefact — grep -cF on origin/main: 1 / 1 / 1.
⭐ Why this is class (a) wrong-not-incomplete, in the shape triage already graded on #16441
What sits at the cited lines today:
346: * `populate`'s name list) that belongs to the RPC/protocol layers, so folding
3001: * asked the reader to keep them in step; sharing the function is what
3191: for (let index = 0; index < rows.length; index++) {
Two are prose inside a comment block; the third is the head of an indexed for loop. :3191 is the dangerous one — it reads as plausible code, so a reader following the citation lands somewhere that looks like a real answer and never learns they were sent to the wrong place. That is the same "plausible-neighbour shape of citation rot" the liveness ledger names and that triage cited when grading #16441 Bug.
These citations do the same job the repaired ones did: they are the only limb tying a rule's justification to the runtime that implements it, and that limb is executed by a human reading the citation. The assertions in the module cannot notice that the runtime moved.
⭐ The drift is an order of magnitude worse than the card that just landed
#16441's anchors were off by 373/374 lines. These are off by up to 5,677 — 15× worse — in a file 15,020 lines long. Nothing detects either: check:system-context-census enforces path:NNN anchors only for its own elevation-read population, and this block is not in it.
Scope, and the fence that kept them out of #16441
⛔ This is not rework on #16441 and must not be read as one. That card's census was explicitly record-validator.ts-only; its dev measured these three read-only, left them, and reported them rather than widening a seven-site repointing into an eleven-site one. That was the correct call — the fence held, and this card is the intended way for the remainder to survive.
Executable criterion
The three citations name the enclosing symbol and, where load-bearing, quote a verbatim snippet, instead of a line number — the convention packages/spec/liveness/field.json already uses and the one #16441 applied to all seven of its sites. All three snippets above are unique in engine.ts today, so the convention is satisfiable here without loss of precision; the seven-for-seven result on #16441 is the precedent.
⛔ Out of scope, ⛔ do not widen into it: whether prose/comment path:NNN anchors deserve a repo-wide gate. That is #16441's closing question and needs its own population count and its own card.
⭐ One datum for whoever writes that gate card, produced free by #16441 and confirmed here: all seven sites on that card, and all three here, had a symbol or a unique snippet available. That argues for a convention gate (cite a symbol or a snippet, never a line) over a line-number-freshness gate. Observation only — no population count was taken.
Refs: #16441 · packages/spec/src/kernel/functional-completeness.ts · packages/objectql/src/engine.ts
Generated by Claude Code
Three
objectql/engine.ts:NNNNcitations in the same published doc block #16441 just repaired point 513 to 5,677 lines away from the text they quote. They were outside #16441's census, which enumeratedrecord-validator.tsanchors only, so they survived that repair untouched — and the next PR to touch this doc block inherits them silently.Handed over by the
os-devon #16441 as an out-of-scope finding (承接者 named as the PM). ⛔ Every reading below was re-taken by the filing seat onorigin/main97adce2fa, not transcribed from that report. Filed unrouted and ungraded — ⛔ this seat does not producedomain:*, a grade or atype; that is triage's.Measured
packages/spec/src/kernel/functional-completeness.ts, module doc block, on the post-#16441 head85bb9dad9f(so this is what lands, not what was there before):packages/objectql/src/engine.tsis 15,020 lines. Each cited text occurs exactly once in it:engine.ts:3001if (d?.type !== 'summary' || !d.summaryOperations) continue;engine.ts:3191if (!referenceObject) continue;engine.ts:346def?.type === 'formula' && def.expressionUniqueness control, so "the text is at line N" is a reading and not an artefact —
grep -cFonorigin/main: 1 / 1 / 1.⭐ Why this is class (a) wrong-not-incomplete, in the shape triage already graded on #16441
What sits at the cited lines today:
Two are prose inside a comment block; the third is the head of an indexed
forloop.:3191is the dangerous one — it reads as plausible code, so a reader following the citation lands somewhere that looks like a real answer and never learns they were sent to the wrong place. That is the same "plausible-neighbour shape of citation rot" the liveness ledger names and that triage cited when grading #16441Bug.These citations do the same job the repaired ones did: they are the only limb tying a rule's justification to the runtime that implements it, and that limb is executed by a human reading the citation. The assertions in the module cannot notice that the runtime moved.
⭐ The drift is an order of magnitude worse than the card that just landed
#16441's anchors were off by 373/374 lines. These are off by up to 5,677 — 15× worse — in a file 15,020 lines long. Nothing detects either:
check:system-context-censusenforcespath:NNNanchors only for its own elevation-read population, and this block is not in it.Scope, and the fence that kept them out of #16441
⛔ This is not rework on #16441 and must not be read as one. That card's census was explicitly
record-validator.ts-only; its dev measured these three read-only, left them, and reported them rather than widening a seven-site repointing into an eleven-site one. That was the correct call — the fence held, and this card is the intended way for the remainder to survive.Executable criterion
The three citations name the enclosing symbol and, where load-bearing, quote a verbatim snippet, instead of a line number — the convention
packages/spec/liveness/field.jsonalready uses and the one #16441 applied to all seven of its sites. All three snippets above are unique inengine.tstoday, so the convention is satisfiable here without loss of precision; the seven-for-seven result on #16441 is the precedent.⛔ Out of scope, ⛔ do not widen into it: whether prose/comment
path:NNNanchors deserve a repo-wide gate. That is #16441's closing question and needs its own population count and its own card.⭐ One datum for whoever writes that gate card, produced free by #16441 and confirmed here: all seven sites on that card, and all three here, had a symbol or a unique snippet available. That argues for a convention gate (cite a symbol or a snippet, never a line) over a line-number-freshness gate. Observation only — no population count was taken.
Refs: #16441 ·
packages/spec/src/kernel/functional-completeness.ts·packages/objectql/src/engine.tsGenerated by Claude Code