[finding] The #13357 negative pin in objectql is now in a tsc program and still unchecked where it counts — its recording driver is const driver: any and the AST it witnesses is any #14117

Filed by the os-dev seat that implemented #13676 (PR #14115). ⛔ Recording only — no severity asserted, routing is triage's.

Why this is filed separately

#13676 put packages/objectql's test corpus in front of tsc for the first time. Its stated motivation was one file: src/engine-filter-array-lowering.test.ts, the negative pin required by maintainer ruling #13357 execution point 3 (landed in #13673), which proves a refused filter shape cannot reach the reference matcher.

That inclusion is now done and the pin is in a tsc program. It reports zero errors — and the zero is nearly empty of information. Putting the file in a program was the precondition for checking it, not the check. This is the part #13676 does not fix and deliberately did not smuggle in.

Measured

At 2a181174a6, under the new packages/objectql/tsconfig.test.json, src/engine-filter-array-lowering.test.ts reports 0 errors, so it correctly carries no entry in test-typecheck-debt.json. Within the same 635-line file:

The two that carry the proof:

• const driver: any = { ... } — the recording driver double. Its captured AST is the unreachability evidence.
• interface SeenRead { ast: any } — so const lastWhere = () = ...ARROW... reads[reads.length - 1]?.ast?.where, the expression every assertion in the file reads, is typed by nothing.

⇒ A drifted IDataDriver signature would not redden this file. The double could stop matching the interface it is standing in for, and the pin would keep passing. That is the specific guarantee a tsc program is supposed to add here, and it is not yet added.

The file argues against its own spelling

This is not a style opinion imposed from outside — the file's own header states the rule and gives the reason:

as unknown as EngineQueryOptions is how: it names the contract being bypassed, keeps the rest of the call type-checked, and greps as an intentional act — none of which a bare as any does.

asFilterArrayQuery implements exactly that and is used 14 times. 31 call sites use the bare form anyway. Note the header's middle clause is the load-bearing one: as unknown as EngineQueryOptions keeps the rest of the call checked, while as any on the options bag does not.

⚠️ Deliberately not claimed: that the ~31 call-site casts are all wrong. Many feed shapes that are off-contract by declaration — that is the point of a negative pin, and the header says so. The narrow claim is about the witness side (driver, SeenRead.ast), which is not off-contract input and has no such justification.

⛔ What is NOT claimed

• ⛔ Not claimed the pin is wrong or that it fails to test what it says. It passes, and at runtime it does witness the lowering. The gap is that tsc cannot tell you when it stops doing so.
• ⛔ Not claimed this is a gate defect. check:test-typecheck is green and correctly so: an unledgered file with zero errors is exactly what the ratchet wants. The gate cannot see through any — nothing asks it to.
• ⛔ Not a request to loosen tsconfig.test.json. Strictness there is inherited and untouched; the repair is in the test file.
• ⛔ No claim about cost. Typing the double against IDataDriver may surface real errors — that interface is the same one whose 14 TS2345 mismatches dominate src/datasource-mapping.test.ts in the new ledger. Nobody has counted them for this file.

Dedup — the channel fired, so this zero is a reading

One targeted semantic search returned 27 on-topic results, including this repo's #13676 itself as a known-hit control. Nearest neighbours:

⇒ No open card covers the witness seam of the #13357 negative pin.

Related

#13676 / PR #14115 (the inclusion that made this measurable) · #13357 / #13673 (the ruling and the pin) · #7264 (same class, no longer open, corpus-wide) · #12573 (the sibling ledger-paydown card for packages/rest)

Generated by Claude Code