Skip to content

[Decision] Should the driver-sql suite REFUSE to report green when live dialect cells were skipped? — shape 2 of #18200, reserved to the maintainer as a new required gate #18653

Description

@huangyiirene

Filed by the domain:engine execution seat, session_01CqmCgU5RGDoJYhHUMVp2af, R1, out of #18200 / PR #18649. ⛔ No domain:* and no priority:* asserted.

The #18200 dispatch built shape 1 (make the skip loud) under a seat ruling, and explicitly reserved shape 2 to the maintainer's floor because a suite that refuses to report green is a new required gate. The dispatch invited the dev to make the case if the work produced one. It did, and the case rests on a number the card did not have.


维护者速读

driver-sql 的本地测试跑完会说「178 通过 | 11 跳过」。⭐ 那个 11 是假的 —— 真实情况是 189 个文件里有 67 个含被跳过的 live 单元格,其中 56 个报告为「通过」。也就是说,一次本地全绿看不见 688 个测试,占这个套件能跑的 21%

这一轮里它已经咬了三次:#17469 带着四个红 CI 交付、今天 #17231 又花掉一整轮补丁、而我自己在诊断那个红时差点重复立卡席当初的同一个误判,只因为多拉了一次基线日志才没踩进去。

#18200 已经修好了「看得见」那一半(PR #18649):跑完会明说哪些方言没跑、设哪个环境变量能跑、67/56 的拆分,没有 PG 时还打印一份跑过才写下来的七行本地起库配方。

剩下的问题只有一个:要不要让它在 live 单元格被跳过时直接不给绿?

⚠️ 这是新增必需门禁,属您的地板,所以我没裁。

做法 代价
A(席位荐) 就到 shape 1 为止,先看它够不够 0;但它要求读的人真的去读
B live 单元格被跳过且没传显式 opt-out 就非零退出 每个没有 PG/MySQL 的本地跑都要带 opt-out;而人人都传的 opt-out 等于没有门禁

席位推荐 A,但带一个具名的重新触发条件:shape 1 落地之后若再出现第四次同类事故(本地绿 → CI 在没人跑过的 live 单元格上红),那就是 B 的证据,直接照 B 办,⛔ 不必再讨论一次。

请裁:A / B?


四棱

① 实际业务需求 —— 有实测拉动,而且是重复的。 三次实例(#17469 四个红 CI;#17231 一整轮补丁;加上本席的近失误)。⛔ 不是投机面,代价是每次一整轮。⚠️三次都发生在 shape 1 存在之前 —— 这一轮之后的复发率是未知数,而 B 的论据恰恰依赖那个未知数。

② 项目长远合理性 —— 中性偏 A。 「声明即强制」在这里的具体形态是:套件不该报告一个它没验证过的状态。shape 1 已经让它不再报告假状态 —— 它现在明说自己没跑什么。⇒ 长远形态的核心已经拿到;B 买的是「强迫读者注意」,那是人机工程,⛔ 不是契约正确性。

③ 防 AI 写错 —— 唯一明确指向 B 的一棱,且理由不弱。 本仓的 dev 是 AI。一个 grep 0 failed 的 agent 不会读那个块。 shape 1 帮的是会看的读者,B 帮的是不看的⚠️ 但反向读数也要如实记:今天 #17231 的 dev 确实如实申报了它跳过了两个单元格 —— 它读了、它说了,⛔ 然后 CI 还是红了,因为申报不等于覆盖。⇒ 该轴支持 B,但 shape 1 之后它的边际收益未经测量

④ 创业阶段不扩散 —— 指向 A,而且理由是机械的。 B 让每一次没有 PG/MySQL 的本地跑都需要 opt-out。⚠️人人都传的 opt-out 与没有门禁等价 —— 那就不是收紧,是新增一道人人绕过的仪式,还附带一个「大家都学会了自动加这个 flag」的长期成本。⛔ 已发布零消费的能力不因沉没成本获得豁免,同理:一道零人遵守的门禁不因它看起来严格而获得价值。

⇒ ③ 指 B,④ 指 A,①② 中性偏 A。⭐ 分歧的真正来源是一个没人测过的量:shape 1 之后还会不会再发生。 所以席位推荐的不是「不做 B」,而是先让那个量可测,并预先说好什么读数会触发 B。

Governing text: 人工地板条款 —— 「新增必需门禁/hook/棘轮」恒交维护者(SKILL.md 代裁人工地板段)。以及 #18200 卡面自陈的失败形态:「it ran, it reported healthy, and nothing was delivered」。


读数

来自 PR #18649 的两状态实测(dev 测,本席按下述方式佐证):

状态 结果
A(无服务器) 178 passed | 11 skipped (189) / 2627 passed | 168 skipped ⇒ 块报「3 个方言跑了 1 个」,168 个跳过散在 67/189 个文件里,11 个 vitest 报为 skipped,另外 56 个它报为 PASSED
B(真 PostgreSQL 16.13) 186 passed | 3 skipped (189) / 3315 passed | 85 skipped ⇒ 「3 个方言跑了 2 个」
差额 688 个测试,占可跑总量的 21%

no-op 对照:改动前在同一基线上跑,摘要逐字节相同 ⇒ 这个 reporter ⛔ 不动任何计数、不动退出码。这是 shape 1「纯声明」成立的证据。

本席的佐证(非重跑,如实标明):driver-sql.test.ts 文件 189 个(卡片写的 188 已过期,#17231 今早加了一个);静态 grep 引用 live-cell 守卫的文件 76 个 —— 比 dev 实测的 67 大,方向正确(静态上界含不止 live 守卫的 skipIf)。必中对照:含 describe( 的文件 185;暗对照:伪造的环境变量名 0⚠️ 本席没有重跑套件,67/56 这个运行期普查是 dev 的读数。

⚠️ 一个已测的设计限制,支持"不要指望更精细的归因":vitest 4.1.11 里被跳过的 TestCase 携带 meta {} 且没有 skip 原因,唯一的逐测试通道是测试名;本包有 9 个文件用手写 skipIf 守 live 单元格,名字里没有 testkit 写的标记 ⇒ 按名字归因会少报。所以 shape 1 报的是文件级普查而非逐测试归因,这是测出来的边界,⛔ 不是偷懒。


查重词

driver-sql live cell skipped green · OS_EXPECT_LIVE_DIALECT_MATRIX opt-out · live-dialect-coverage reporter · refuse green on skipped dialect · 67 of 189 skipped live cell

相关


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

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions