Split out of #14639 by triage. That card is the current instance — four fixable OSV advisories red in the lockfile — and is queued as a take-the-fix repair. This card is the question it records but deliberately does not answer: why this class keeps being discovered by accident.
The measured lineage (from #14639, which assembled it)
| Card |
Advisory |
Disposition |
| #4945 |
brace-expansion |
closed, took the fix ("cleared in ten minutes") |
| #5032 |
undici / hono / fast-uri, 8 fixable, red on main |
closed |
| #5039 |
fast-uri / hono / undici, "队列级阻塞" |
closed |
| #6407 |
dompurify via mermaid |
closed |
| #6506 |
nanoid, "有 fix,缺 override" |
closed |
| #14639 |
@xmldom/xmldom ×2, qs ×2 |
open |
Six in a month. Every one was fixable at the time it was found. Every one was found by whichever seat happened to trip over it, never by anything watching.
The mechanism
.github/workflows/validate-deps.yml runs on two triggers that do different jobs and are not synchronised:
schedule: cron '0 3 * * 1' — weekly, Mondays. This is the discovery trigger.**/package.json, pnpm-lock.yaml, .changeset/config.json, pnpm-workspace.yaml, osv-scanner.toml — per-PR. This is the blocking trigger.
Between Monday scans, a new advisory lands in the OSV database and nothing in the repo changes. The first PR that touches any manifest then runs the scan and eats a red that has nothing to do with its diff. So the blocking trigger is doing the discovery, six days late, on a random author.
Options
- A — tighten the scan cadence (daily rather than weekly). Discovery moves ahead of blocking without adding anything new. Does not change who acts on it.
- B — give the scheduled scan an outlet: a red scheduled run opens a card. The job already holds
issues: write, so the capability is present and unused.
- C — status quo. Keep discovering by collision. Six data points say what that costs.
A and B are not exclusive.
What this card does NOT cover
⛔ The four current advisories. Those are #14639's, and that card is pm:queue — do not fold the repair in here, and do not wait for this ruling to take the fix.
<!-- os-decision-facets -->
- ① 项目长远合理性(权重 ≥50%,领起推荐) —— 平台有两道触发器:一道每周扫一次(负责发现),一道对每个碰 manifest 的 PR 生效(负责阻塞)。两者之间有六天的窗口,于是阻塞那一道在替发现那一道干活 —— 而且是在一个跟这件事毫无关系的作者身上。长远终态很朴素:发现要早于阻塞。①指向「让定时扫描的红有一个出口」,而不是继续让下一个提 PR 的人充当探测器。
- ② 实际业务拉动 —— 一个月六次,每次都是「某个席位恰好撞上」,而且每次都跨车道。这是已测的、重复发生的代价,不是假想。
- ③ 防 AI 犯错 —— 出错时谁看到什么:一个 agent 提了个只加一行
scripts 的 PR,CI 红了,红的原因跟它的改动毫无关系。它会去读 OSV 报告、可能去动锁文件、甚至可能去 osv-scanner.toml 加豁免 —— 而那个文件的规则明令有 fix 时禁止豁免。⚠️ 把不相关的红扔给最不该修它的人,正是最容易诱发错误修法的形状,而这里连正确的修法都写在一个它未必会读的文件头里。
- ④ 创业阶段不扩散 —— ⚠️ 这一棱反对 B:自动开卡是往 backlog 里新增一个自动生产者,而生产者集合是有永久代价的 —— 每张自动卡都要被分诊、去重、关闭,而这正是本席这个座位的负载。提频(A)不新增生产者,只是把同一条信号提早。④明确偏 A。
推荐:A —— 先提频到每日,不自动开卡。 ②有重复拉动、③要的是提早发现,提频就足以给到;④明确反对新增自动生产者;①两者都满足,而 A 更便宜。
回退:B —— 若维护者判定「提频只是让红更早出现,而没有人负责去看」,那就给定时扫描一个出口(该 job 已持有 issues: write)。代价必须同批裁定:自动卡的去重规则、关闭规则,以及它算不算 finding 箱的输入 —— ⛔ 否则它会变成一个没有人负责清空的第二条队列。
⛔ 不荐 C。 六次是已测数据。
置信缺口(本分析看不见什么): 没有量提频后的噪声 —— 每日扫描会不会在同一条未处理的通告上连续红七天,取决于谁在看 scheduled run 的结果,而「谁在看」本轮没量。这是 A 唯一可能不成立的地方,也正是 B 想解决的那件事。
Refs: #14639 (the current instance, and the card that assembled this lineage) · #4945 · #5032 · #5039 · #6407 · #6506.
Generated by Claude Code
Split out of #14639 by triage. That card is the current instance — four fixable OSV advisories red in the lockfile — and is queued as a take-the-fix repair. This card is the question it records but deliberately does not answer: why this class keeps being discovered by accident.
The measured lineage (from #14639, which assembled it)
mainSix in a month. Every one was fixable at the time it was found. Every one was found by whichever seat happened to trip over it, never by anything watching.
The mechanism
.github/workflows/validate-deps.ymlruns on two triggers that do different jobs and are not synchronised:schedule: cron '0 3 * * 1'— weekly, Mondays. This is the discovery trigger.**/package.json,pnpm-lock.yaml,.changeset/config.json,pnpm-workspace.yaml,osv-scanner.toml— per-PR. This is the blocking trigger.Between Monday scans, a new advisory lands in the OSV database and nothing in the repo changes. The first PR that touches any manifest then runs the scan and eats a red that has nothing to do with its diff. So the blocking trigger is doing the discovery, six days late, on a random author.
Options
issues: write, so the capability is present and unused.A and B are not exclusive.
What this card does NOT cover
⛔ The four current advisories. Those are #14639's, and that card is
pm:queue— do not fold the repair in here, and do not wait for this ruling to take the fix.<!-- os-decision-facets -->
scripts的 PR,CI 红了,红的原因跟它的改动毫无关系。它会去读 OSV 报告、可能去动锁文件、甚至可能去osv-scanner.toml加豁免 —— 而那个文件的规则明令有 fix 时禁止豁免。推荐:A —— 先提频到每日,不自动开卡。 ②有重复拉动、③要的是提早发现,提频就足以给到;④明确反对新增自动生产者;①两者都满足,而 A 更便宜。
回退:B —— 若维护者判定「提频只是让红更早出现,而没有人负责去看」,那就给定时扫描一个出口(该 job 已持有
issues: write)。代价必须同批裁定:自动卡的去重规则、关闭规则,以及它算不算finding箱的输入 —— ⛔ 否则它会变成一个没有人负责清空的第二条队列。⛔ 不荐 C。 六次是已测数据。
置信缺口(本分析看不见什么): 没有量提频后的噪声 —— 每日扫描会不会在同一条未处理的通告上连续红七天,取决于谁在看 scheduled run 的结果,而「谁在看」本轮没量。这是 A 唯一可能不成立的地方,也正是 B 想解决的那件事。
Refs: #14639 (the current instance, and the card that assembled this lineage) · #4945 · #5032 · #5039 · #6407 · #6506.
Generated by Claude Code