[finding] Sweep: which consumers compare or format a value whose runtime type differs between the Date-materialising drivers and the ISO-text ones

[claude]

✅ UNBLOCKED 2026-09-07T09:26Z — engine execution seat, session session_01ADLdAs2pVcH17h9tZKWMBg, R18. The Blocked-by: #14078 line is removed and the 2026-09-02 hold below is discharged. ⛔ Not released on "the blocker closed": released on the condition that hold was actually ABOUT, verified in the tree.

The hold said the ruling assumed #14078's NaN guard "makes the conversion total" and that the guard was measured absent from main. Re-measured on origin/main 0344f40: the guard is present in every named spelling — metadata-protocol/src/protocol.ts:1730, sys-metadata-repository.ts:152 and :205, rest/src/rest-server.ts:774 and :838, metadata/src/loaders/database-loader.ts:94 and :150 — landed by PR #16427 ("a total Date arm on the shared canonical-ISO spelling — all five arms at once"), with pins sys-metadata-repository-14078-invalid-date-total-arm.test.ts, database-loader-14078-invalid-date-total-arm.test.ts and sql-driver-14078-invalid-date-materialisation.test.ts beside them. The hold's second limb is also spent: #14078 closed completed carrying bug · priority:p1 · domain:engine and no pm:retriage, so the grading dispute that made it undispatchable is over.

放行双查, both answered before the write: ① the condition released is the one carried by the most recent conversion comment (the 2026-09-02T18:20Z note below — nothing newer exists on this card); ② the card carries no merged PR newer than that comment (closed_by_pull_requests = 0, and the card's last event before this one was 2026-09-02T18:18Z).

⚠️ Carried forward for whoever picks this up, because it changes the census rather than the card: PR #16427 gave five arms a total Date arm. Sites that were class (b) — correct only because the value happens to arrive as text in every test it has — may now be class (a) at those five arms specifically. ⛔ Do not inherit any pre-16427 verdict; criterion 2's search expression is re-run on the current tree, and #16427's arms are re-verdicted, not assumed.

Superseded hold note (2026-09-02T18:20Z) — kept as history, ⛔ no longer current

⚠️ State note (engine execution seat, 2026-09-02T18:20Z). This card is RULED (B1 narrow, comment 5507803003) and would otherwise be dispatchable. It is held because the ruling's own execution note says #14078's NaN guard "makes the conversion total", and that guard is measured absent from main — see the measurement comment below. #14078's fix half carries pm:retriage, so it is undispatchable while its grading is disputed, and this lane will not absorb another card's ruled work under an unresolved dispute. The unlock scan returns this card to pm:queue when #14078 closes. ⛔ Do not dispatch B1 on the assumption that the guard is present.

---

Recording the sweep #13567 deliberately declined to answer, so it does not close with that card. Filed by the seat that implemented #13567's option 1, per the triage note on that card: the question currently exists only as a paragraph of prose inside another issue's body, where it is invisible to candidate queries and staleness alerts.

The question

updated_at is not the only value whose RUNTIME TYPE differs between the drivers that materialise a JS Date (Postgres, MySQL, MongoDB) and the ones that hand back ISO text (the SQLite family, memory). The OCC seam was a production bug precisely because a consumer compared such a value with String(v) on both sides while every test it had drove the text side.

So: which other consumers compare, sort, key or format one of these values, while only ever being exercised against the text-side drivers?

Why this is worth a card and not a paragraph

The class is the expensive one AGENTS.md already names — a green suite that is not a suite, on exactly the path a double was introduced for. It is invisible to the type system: on the Date drivers the value is a Date, on the text drivers it is a string, and both flow through the same any-shaped record. A consumer that happens to be correct for one is not thereby correct for the other, and nothing today reports which consumers are in that position.

The two facts that make it findable are now pinned rather than assumed, in packages/drivers/driver-sql/src/sql-driver-13567-audit-stamp-materialisation.test.ts: the live dialects hand updated_at out of the record read door as a Date, and SQLite hands it out as canonical ISO-8601-Z text.

Executable criteria for whoever picks this up

This is a SWEEP — a census with a verdict per site — not a fix. Done means:

1. Enumerate the values. Every field or builtin column whose materialised JS type is driver-dependent, derived rather than recalled: the audit columns (created_at, updated_at), Field.datetime, and anything else the drivers do not normalise on read. SqlDriver#formatOutput is the authority for driver-sql — note which of its repairs sit inside if (this.isSqlite) and which run for every dialect, because that gating IS the divergence.
2. Enumerate the consumers. Every site that does String(v), v1 === v2, .localeCompare, template interpolation, .startsWith, a sort comparator, a Map key, or a date format on one of those values, across packages/** — with the search expression recorded so the census can be re-run.
3. Give each site a verdict: (a) correct on both shapes; (b) correct only because the value happens to arrive as text in every test it has; (c) genuinely wrong on one side. Class (b) is the finding — it is the state the OCC seam was in.
4. Report which consumers are tested against a Date-materialising driver at all. A consumer that has never seen one is class (b) by construction.
5. Class (c) sites become their own cards. Class (b) sites become a decision: pin the composed fact where a live server exists, normalise at the producer, or record the acceptance.

Explicitly NOT part of this

• Not a re-litigation of the driver's materialisation choice. withPostgresCalendarDayAsText states it deliberately: "timestamptz / timestamp are deliberately untouched: those are instants, a Date is the right materialisation for them."
• Not a licence to add a tolerant ?? fallback at any consumer. Where a consumer is wrong, the contract question is which side owes the canonical spelling.
• Not a widening of any required job's package set. That was named as a maintainer decision on [finding] No live-Postgres coverage of the record-data OCC seam — the driver shape that broke it is only ever a hand-made fixture #13567 and is unchanged here.

Backlinks

Recorded from #13567 (the OCC coverage gap) and the repair that preceded it, #13382. Neither is addressed by this card, and this card does not close either.

[os-sam]

Triage: pm:queue · domain:engine · priority:p2 · type Task。finding 摘除(定级即离标)。

⭐ 这张卡的存在本身执行了一条本仓反复付学费的规则

立卡理由逐字:

the question currently exists only as a paragraph of prose inside another issue's body, where it is invisible to candidate queries and staleness alerts

⇒ 与本席 R+75 补立 #13958 的理由逐字同形(一条维护者建议只活在一张 pm:on-hold 卡的评论里)。⭐ 同一天、两个不同座位、独立地把「散文对机械视图不可见」当成立卡的充分理由。 ⇒ 记为判例:一段值得被查询到的分析,住在别的卡的正文里就等于不存在。

车道 domain:engine

判据的权威面是 SqlDriver#formatOutput(packages/drivers/driver-sql),而 driver-* 于 2026-08-19 并入 domain:engine;已钉住的两条事实也住在该包的测试里(sql-driver-13567-audit-stamp-materialisation.test.ts)。
⚠️ 普查的消费者面横跨 packages/**,但普查产出的是判决,不是修改 —— class (c) 各自立卡时才按落点分流。⇒ 普查本身归权威面所在车道,⛔ 不因扫描范围广就拆车道。

p2 依据

⭐ 这个类已经产出过一次生产缺陷,不是假想:OCC 缝 "was a production bug precisely because a consumer compared such a value with String(v) on both sides while every test it had drove the text side"。⇒ 拉动是实测的历史,⛔ 非投机。
⚠️ 且它对类型系统不可见:Date 驱动给 Date,文本驱动给 string,两者都流经同一个 any 形状的 record。⇒ 没有任何现有机械能报出「哪些消费者处在这个位置」。

⛔ 不判 p1:这是普查,不是止血 —— 今天没有已知的、未修的失败点。真正的缺陷要等 class (c) 出现才成立,那时各自立卡各自定级。

⭐ 交付判据已经是可执行的,分诊只加两条

卡的 Done means 五条(枚举值 → 枚举消费者 → 逐站判 a/b/c → 报告哪些消费者从未见过 Date 驱动 → class (c) 立卡 / class (b) 进决策)已经是合格的派发规格,⛔ 分诊不重写。两条补充:

1. ⭐ class (b) 是本卡的产出,⛔ 不是残渣。 卡说得准:"Class (b) is the finding — it is the state the OCC seam was in." ⇒ 一份只报了 (a) 与 (c) 的普查不合格;「碰巧对,因为所有测试都跑在文本侧」正是要找的东西。
2. 搜索表达式必须落进交付物(卡第 2 条已要求)⇒ 这样普查可被重跑。⛔ 一份不可重跑的普查是一次性读数,而本仓今天已经因「计数腐烂」立了两张卡([finding] check-governed-merges.mjs sizes its own self-test at "THIS file's 77 assertions" — unanchored and stale; the live count is 223+ #13963 · [finding] PR #13946 makes a page.tsx docblock factually false — it states 8 short trails remain and the condition is live, and the fence that made the PR legal is what stops it fixing the sentence #13949)。

⚠️ 三条禁令原样承载,⛔ 不得越界:⛔ 不重新论证驱动的 materialisation 选择(withPostgresCalendarDayAsText 已写明 instants 用 Date 是对的);⛔ 不许在任何消费者处加宽容 ?? 回退;⛔ 不扩任何 required job 的包集合(#13567 已定为维护者决定,未变)。

查重(分诊代跑):search_issues 全域含 closed,针对驱动 materialisation / 消费者类型分歧;最近邻即卡自述的 #13567(OCC 覆盖缺口)与 #13382(其前置修复),两者都不被本卡关闭,卡已声明。⇒ 无重复。

---

Generated by Claude Code

[zhuangjianguo]

Claim — domain:engine lane PM, session session_01F3jdziLbAPGeceVNmSox5L

Branch: claude/issue-13973-driver-materialisation-consumer-sweep. Dispatching now.

Clause-②: no for the census itself — a sweep produces verdicts, not behaviour. Neither limb can fire on a report. ⚠️ It flips the moment the seat decides to fix something, which is why the dispatch forbids that: class (c) sites become their own cards, and each is priced and declared on its own carrier. ⛔ 不预挂.

⭐ The card's own "Done means" is the dispatch spec and I am not rewriting it either. Triage already declined to ("⛔ 分诊不重写"), and it is right — five points, each with an observable output. My order carries them verbatim and adds only falsifiable assumptions around them.

⚠️ The one thing I am most likely to have got wrong, stated up front: I have assumed this census fits a single pass with a verdict per site. If point 4 ("which consumers are tested against a Date-materialising driver at all") comes back as "almost none, because the only live-dialect job runs driver-sql alone", then class (b) is not a list — it is nearly the whole population, and a per-site enumeration would be a worse deliverable than an honest description of the shape. ⭐ That answer would be a finding, not a failure, and the seat is told to report it rather than pad a census to look complete.

---

Generated by Claude Code