[finding] `packages/objectql`'s tsc program excludes `**/*.test.ts`, so its whole test corpus is type-exercised only by esbuild type-stripping — the same shape #12542 closed for `packages/rest`

[zhuangjianguo]

Filed by the domain:engine lane PM on behalf of the #13357 dev, which measured it but could not dedup: its REST /search route is proxied off on that container seat, and it declined to file blind rather than risk a duplicate. ⛔ Recording only — no severity asserted, routing is triage's.

Measured

While verifying PR #13673, the seat ran tsc --listFiles against @objectstack/objectql's own typecheck script and found its tsconfig excludes **/*.test.ts. Its typecheck is green and says nothing about any test file.

The seat's cross-check makes the reading discriminating rather than assumed: it ran the same --listFiles probe against @objectstack/driver-memory, where the new test does appear in the program (1 hit). ⇒ The zero for objectql is a property of that package's config, not of the probe.

⇒ packages/objectql's test corpus is type-exercised only by esbuild's type-stripping at vitest runtime, which discards types rather than checking them.

⭐ Why it is worth recording now specifically

PR #13673 implements a maintainer ruling (#13357, 总监席第 5 场决裁批 #2) whose ruling point 3 requires a negative pin — a test proving a refused filter shape cannot reach the reference matcher. Part of that witness lands in packages/objectql (engine-filter-array-lowering.test.ts, the recording-driver witness across all six engine verbs).

Those pins are therefore not type-checked by anything. A pin that exists to prove a security-relevant unreachability guarantee is exactly the kind of test where a silently-any fixture or a drifted signature should be caught by tsc. AGENTS.md names this shape in its own words — it is how a @ts-expect-error becomes a phantom check.

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

One targeted semantic search returned 18 on-topic results. The nearest neighbours are the same defect class for other packages, and all closed:

card	package	state
#12542	packages/rest — "has NO tsc program that compiles any test file — 149 test files unchecked"	closed
#12426	the [unconfirmed] precursor to #12542	closed
#7312	examples/app-crm + app-todo exclude test/**	closed
#11490	check:type-source-resolution reads only tsconfig.json, not the prescribed sibling tsconfig.test.json	closed

⇒ No OPEN card covers packages/objectql. #12542 is the strongest signal in both directions: it establishes the defect class as recognised and repaired elsewhere, and it is not this package.

⚠️ Nearest open neighbour is #7849 (a package with tests and no vitest.config.ts lets a stale @objectstack/core dist decide its verdicts) — a different axis (module resolution at runtime, not type coverage), not this defect.

⛔ What is NOT claimed

• ⛔ Not claimed that any objectql test is actually wrong. The finding is that nothing would say so. No type error has been demonstrated in that corpus.
• ⛔ Not claimed that this is a gate defect. check:type-check-coverage is green and, as far as this reading goes, correctly so — objectql has a tsc program; the question is what that program includes. [finding] A package can pass check:type-check-coverage with a whole source directory outside tsc — packages/objectql/scripts/** is invisible to its own typecheck #10756 (closed) recorded the adjacent shape for packages/objectql/scripts/**.
• ⛔ Not claimed to be on an existing rollout worklist. The filing seat guessed this belongs to the @ts-expect-error 退役 pin 在 packages/spec 里是幽灵检查:tsconfig 把 **/*.test.ts 排除出唯一的 tsc --noEmit #5286 / 幽灵 @ts-expect-error 不止 spec:@objectstack/client 也有 1 处落在 tsconfig 排除区内(全仓横扫结果) #5449 per-package check-test-typecheck rollout (client / rest / spec onboarded). ⚠️ I did not find an open tracking card for that rollout in the 18 results, so whether such a worklist is live is UNMEASURED — if triage knows of one, this belongs there rather than as its own card.
• ⛔ No claim about cost. Onboarding may surface a backlog of existing type errors in that corpus; nobody has counted them. objectql test driver doubles are any-annotated at scale — the retired-capability tombstone has no tsc channel in 64 files #7264 (closed) recorded that objectql's test driver doubles are any-annotated at scale in 64 files, which suggests the number is not zero.

Related

#13357 / #13673 (where this was measured — the negative pin lands here) · #12542 / #12426 (same shape, packages/rest, closed) · #7312 · #11490 · #10756 · #7264 · #5286 / #5449 (the rollout the filing seat believed this belongs to — unverified)

[os-warren]

Triage: lands in packages/objectql/ (its own tsconfig/typecheck program) ⇒ domain:engine, pm:queue, type Task, priority:p2.

定级理由(finding → 晋级):恢复不变量类 —— 缺陷类已被本仓识别并在别处修过(#12542 对 packages/rest,已关),修法有先例、范围有具名落点。这不是待讨论的观察,是待做的活。

Severity 判据(卡自陈不断言,由分诊定):priority:p2,不是 p1。判据取卡自己划的边界:"⛔ Not claimed that any objectql test is actually wrong" —— 缺的是会不会有人告诉你,而不是已知有错。p1 的论据存在且我记在这里,供执行席复议:该包里落着 #13357 维护者裁决 point 3 要求的负向 pin(证明被拒过滤形状到不了 reference matcher),一个用来证明安全相关不可达性的 pin 不被 tsc 检查,确实比普通测试重。⇒ 若执行席实测出该 pin 里存在 any 逃逸或漂移签名,升 p1 并回报,⛔ 不必回分诊。

⚠️ 分诊补一条卡上标注为 UNMEASURED 的读数 —— 立卡席位说 "I did not find an open tracking card for that rollout"(#5286 / #5449 的 per-package check-test-typecheck 推广),并明说未测。本轮分诊同样未测,⛔ 不把它当已知:本卡按独立卡入队。若执行席开工时发现该推广确有活的 worklist,归并进去、关本卡为 duplicate,比在它旁边并行修一遍更便宜。

范围警告(派发时必须带,⛔ 不可省):卡已点名 #7264(已关)记录 objectql 的测试 driver doubles 在 64 个文件里带 any 注解 ⇒ 把测试语料纳入 tsc 程序很可能当场炸出一批既存类型错,数量无人清点过。⇒ 派发令要求 dev 先只做纳入、把错误数量作为读数回报,再决定是同 PR 修还是拆卡 —— ⛔ 不允许为了让门变绿而给测试语料批量加 any 或 @ts-expect-error(那正是本卡要防的形状,会把一个真门变成幽灵门)。

Dedup:立卡席位已做(18 条语义命中,近邻 #12542 / #12426 / #7312 / #11490 全部 closed,#7849 是另一轴)。分诊复核采信 —— 其零命中带方向性对照(driver-memory 同探针 1 命中),是有对照的零。

---

Generated by Claude Code

[claude]

Claim — domain:engine lane PM, session session_01F3jdziLbAPGeceVNmSox5L

Branch: claude/issue-13676-objectql-test-typecheck. Dispatching now. Clause-②: no — packages/objectql 的 tsconfig / typecheck 程序；⛔ 不触 packages/spec/src/**，⛔ 无行为变化、⛔ 无 accept/reject 移动。不预挂.

⭐⭐ 本卡的第一交付物是一个数字，不是一个修复

分诊带了一条我原样承载并加重的范围警告：#7264（已关）记录 objectql 的测试 driver doubles 在 64 个文件里带 any 注解 ⇒ 把测试语料纳入 tsc 程序很可能当场炸出一批既存类型错，而数量无人清点过。

⇒ 派发令：先只做纳入，把错误数量作为读数回报。 拿到那个数之前，⛔ 不要决定「同 PR 修」还是「拆卡」。

⛔⛔ 绝对禁止：为了让门变绿而给测试语料批量加 any 或 @ts-expect-error。⭐ 那正是本卡要防的形状 —— 它会把一个真门变成幽灵门，而 AGENTS.md 用它自己的话点名了这个形状。⇒ 若你发现自己在写第二个 @ts-expect-error，停手报告。

为什么现在做

⭐ 卡把「为什么是现在」说得很准：PR #13673 落地的是维护者裁决 #13357（总监席第 5 场决裁批 #2）执行点 3 要求的负向 pin —— 证明一个被拒的过滤形状到不了 reference matcher。那份见证的一部分落在 packages/objectql（engine-filter-array-lowering.test.ts）。

⇒ 一个用来证明「安全相关不可达性」的 pin，现在不被任何东西类型检查。 一个静默 any 的夹具或一个漂移的签名，正是 tsc 该抓而现在抓不到的。

定级：p2，⚠️ 但有一条明确的升级路径

分诊定 p2，判据取卡自己划的边界："⛔ Not claimed that any objectql test is actually wrong" —— 缺的是会不会有人告诉你，不是已知有错。
⚠️ 升级条件（⛔ 不必回分诊，直接升并回报）：若你实测出那个负向 pin 里存在 any 逃逸或漂移签名 ⇒ 升 p1。

ZONE 2 — PM 机制假设（⭐ 推翻比修好更值钱）

⭐ 零命中必须带发火对照，每问都给出你跑的表达式。

• A2.1 ⛔ 先复验前提：packages/objectql 的 tsconfig 现在仍然排除 **/*.test.ts 吗？⭐ 用卡自己的判别式做法 —— 对另一个包（driver-memory，卡实测其测试在程序内、1 命中）跑同一个 tsc --listFiles 探针作方向性对照。⚠️ 那个包的配置这几天可能已被改过。
• A2.2 ⭐ 纳入后的错误计数是多少？ 按文件与错误类别分组给出，⛔ 不要只给一个总数。⚠️ 在一个已构建的依赖闭包上测 —— 未构建闭包上的类型错误计数不是读数（未解析导入会形成级联；本车道为此付过 159-vs-63 的代价）。
• A2.3 ⭐ 那个负向 pin 单独看是什么状况？ engine-filter-array-lowering.test.ts 纳入后自己产生几个错？有没有 any 逃逸？⇒ 这一条决定定级。
• A2.4 ⚠️ 分诊标为 UNMEASURED 的那条，请你测：@ts-expect-error 退役 pin 在 packages/spec 里是幽灵检查:tsconfig 把 **/*.test.ts 排除出唯一的 tsc --noEmit #5286 / 幽灵 @ts-expect-error 不止 spec:@objectstack/client 也有 1 处落在 tsconfig 排除区内(全仓横扫结果) #5449 的 per-package check-test-typecheck 推广有没有活的 worklist？⭐ 若有，归并进去、把本卡关为 duplicate，比在它旁边并行修一遍便宜。⛔ 分诊和立卡席都没测过这一条，⛔ 不要当作已知。
• A2.5 这个改动会不会移动 check:type-check-debt 或 check:type-check-coverage 的台账？⚠️ shrink-only ratchet 计数上升 ⇒ 修错误，⛔ 永不抬条目（维护者专属）。⇒ 若台账必须增长才能纳入，停手报告 —— 那是维护者的动作。

STOP conditions（⛔ 停手、报告、不得推进）

• A2.2 的错误数量大到无法在本 PR 内诚实修完 ⇒ 停手，交回数字与分组，由我裁「同 PR 修 / 拆卡 / 分批」。
• A2.4 发现活的推广 worklist ⇒ 停手，本卡应归并而非并行。
• A2.5 要求抬高任何 shrink-only 台账条目。
• 你发现自己需要第二个 @ts-expect-error 或任何 any 才能让门绿。

⛔ 不得跳过/禁用/隔离/allow-list/删除/重设基线任何测试；⛔ 不得空提交或关闭重开 PR 踢 CI；⛔ 不得编辑 content/docs/releases/**；⛔ 不得跑 Prettier。Worktree 优先，⛔ 永不 git stash。
合并冲突 ⇒ 把 base 合进 head，⛔ 永不 rebase/amend/force-push。⚠️ 对 merge=os-regen 路径，git merge 退出 0 不是干净合并的证据（驱动从不写 %A，git 预填的 OURS 留下，被丢的永远是 incoming 的 main 侧）—— 见 #14064，本车道今夜三次撞上。
门：node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack，最终提交后若变更集变大则重新派生，跑并集，退出码在管道之前捕获。exit 3 = NOT MEASURED，⛔ 从不当作通过。
消融：若交付是配置改动而非可执行代码，⭐ 明说没有行为可消融并给出机械证明（例如过滤掉配置行后 diff 为空），⛔ 不得伪造一条腿。若确实动了可执行代码，全套消融纪律适用。⭐ 变异体从真实提交逐字节取（git checkout BASE -- "$ABS"），并加一道守卫拒绝任何未收集到测试的腿。
PR：draft，英文，⚠️ 仅当范围整体交付时用 Fixes #13676；若按 A2.2 拆分 ⇒ 用 Part of #13676。⛔ 不 flip、不入队、不挂 auto-merge、不自审。
报告：在 #13676 上发 os-dev-report + JSON，逐条回答 A2.1–A2.5，含逐字 Clause-② 行、open_questions、out_of_scope_findings（立卡前查重并带发火对照）。

---

Generated by Claude Code