`Validate Package Dependencies` stays red after #14639 lands — 4 NEW fixable `fast-uri` advisories (3.1.5 -> 3.1.6, all 7.5 high)

[claude]

Found while verifying #14639 on branch claude/issue-14639-osv-xmldom-qs-fix, by running the workflow's own scanner locally. Not #14639's failure and not in its scope — its triage (5513075222) ruled the scope to @xmldom/xmldom and qs and forbade other dependency moves, and these four advisories did not exist when that card was filed. Filing so the queue damage #14639 describes is actually cleared: Validate Package Dependencies stays red after #14639 merges, on these four alone.

Measured

OSV-Scanner v2.3.8 (osv-scanner --offline-vulnerabilities, npm offline database downloaded 2026-09-02 22:27 UTC — the same scanner .github/workflows/validate-deps.yml pins).

Baseline, origin/main 4d0d9445a lockfile — 8 vulnerabilities, 4 packages:

Total 4 packages affected by 8 known vulnerabilities (0 Critical, 4 High, 4 Medium, 0 Low, 0 Unknown)
8 vulnerabilities can be fixed.

Four of those eight are #14639's (@xmldom/xmldom 0.8.13 / 0.9.11, qs 6.15.3 — all 6.3 medium). The other four are new:

OSV URL	CVSS	PACKAGE	VERSION	FIXED VERSION
https://osv.dev/GHSA-5jgf-p345-68v8	7.5	fast-uri	3.1.5	3.1.6
https://osv.dev/GHSA-f65p-4m7j-42xc	7.5	fast-uri	3.1.5	3.1.6
https://osv.dev/GHSA-fph4-wmhf-6fwf	7.5	fast-uri	3.1.5	3.1.6
https://osv.dev/GHSA-jqff-g426-hqxp	7.5	fast-uri	3.1.5	3.1.6

After #14639's fix, same scanner, same database — the four the card names are gone and only these remain:

Total 1 package affected by 4 known vulnerabilities (0 Critical, 4 High, 0 Medium, 0 Low, 0 Unknown)
4 vulnerabilities can be fixed.

These post-date the card: #14639 quotes its CI run as Total 3 packages affected by 4 known vulnerabilities (0 Critical, 0 High, 4 Medium, 0 Low, 0 Unknown) — no High at all. They are also higher severity than the four the card was graded p1 for: 7.5 high, against 6.3 medium.

Dependents — transitive-only, nothing in the workspace declares it

pnpm why -r fast-uri:

fast-uri@3.1.5
└─┬ ajv@8.20.0
 ├─┬ @modelcontextprotocol/sdk@1.30.0
 │ ├── @objectstack/connector-mcp@17.2.0 (dependencies)
 │ ├── @objectstack/example-showcase@0.3.16 (dependencies)
 │ └── @objectstack/mcp@17.2.0 (dependencies)
 ├── @objectstack/lint@17.2.0 (dependencies)
 ├── @objectstack/objectql@17.2.0 (dependencies)
 └─┬ ajv-formats@3.0.1
 ├── @modelcontextprotocol/sdk@1.30.0 [deduped]
 ├── @objectstack/lint@17.2.0 (dependencies)
 └── @objectstack/objectql@17.2.0 (dependencies)

ajv@8.20.0 declares fast-uri at ^3.0.1, which already admits 3.1.6, so this is a dedupe onto the patched line and not a forced upgrade past what the dependent supports. No workspace manifest declares fast-uri (grep over every non-node_modules package.json = 0 hits), so there is no published declared range to keep in lockstep.

The fix shape is already decided by the file that carries the pin

pnpm-workspace.yaml already pins fast-uri from the 2026-08 OSV batch (#5032), and its comment states why the bound sits where it does: the selector's exclusive upper bound is at the 4.0.0 major boundary, "so a future advisory lift moves only the target". This is that lift, and the ledger entry proves the shape rather than leaving it to judgement:

• move the target from ^3.1.5 to ^3.1.6 (3.1.7 is also published; either satisfies the advisories, and ^ floats to the newest 3.x either way)
• leave the selector alone — moving it to the fixed version is the self-invalidating shape check:override-consistency reports on, and the entry is deliberately not in that shape today
• regenerate pnpm-lock.yaml with pnpm install --lockfile-only; do not hand-edit it

⛔ No osv-scanner.toml exemption. All four name a fixed version, so this is the take-the-fix path that file's own header describes; the ledger holds zero entries and #14639's triage ruled that it stays at zero.

Why this is a separate card and not folded into #14639

#14639's fixed scope is @xmldom/xmldom and qs, with ⛔ no other dependency moves, no unrelated lockfile churn — the diff must be explainable line by line as these two packages' resolution moving. A fast-uri move is a third package and a different advisory set, filed after that scope was ruled. It is also a one-line change that can land in minutes on its own.

Dedup

Listed the 100 newest open items (REST repos/objectstack-ai/objectstack/issues?state=open, covering #14573 through #14730) and matched titles and bodies against fast-uri: the only two hits are #14639 and #14645, and both mention the package only in the historical lineage of the 2026-08 batch. No open card names GHSA-5jgf-p345-68v8, GHSA-f65p-4m7j-42xc, GHSA-fph4-wmhf-6fwf or GHSA-jqff-g426-hqxp. #14645 (the weekly-scan cadence question, needs-user-decision) is adjacent but is a design question about the outlet, not a repair for these four — and this card is a live demonstration of exactly the gap it records: the advisories landed between Monday scans and surfaced only because someone happened to run the scanner by hand.

Related: #14639, #14645.

---

Generated by Claude Code

[huangyiirene]

Triage — graded. bug · tooling · security · priority:p1 · pm:queue · domain:devx. Adopted as filed; every load-bearing premise re-measured at origin/main, and the central claim is now observed rather than predicted.

The card's premises, verified

• pnpm-workspace.yaml:253 reads 'fast-uri@<4.0.0': '^3.1.5' — the Validate Package Dependencies is red on main — 8 FIXABLE OSV advisories (undici / hono / fast-uri), so every PR inherits a red required-ish check #5032 pin, selector bounded at the 4.0.0 major boundary exactly as the card says.
• The block's own comment (:239-241) already records the topology this card depends on: "transitive-only via ajv@8.20.0 (declares ^3.0.1) … Nothing declares fast-uri directly." git grep 'fast-uri' origin/main -- '*/package.json' 'package.json' returns empty, confirming it independently. So there is no declared range to move in lockstep, and check-override-consistency.mjs will list this as an override it cannot cross-check — correct for the shape, a report and never a failure.
• ⛔ The exemption route is foreclosed by osv-scanner.toml's own header, not merely by preference: "When an advisory HAS a fixed version, you take the fix — that path stays untouched. This file exists for the other case only." The ledger holds zero entries and states that is the intended steady state. The card's ⛔ no-exemption is therefore the ledger's rule, not an added constraint.

⭐ The claim is already observed on CI

The card predicts the check "stays red after #14639 lands". That is no longer a prediction. PR #14736 (the fix for #14639, open) carries Validate Package Dependencies = failure on its own head — 38 of 39 checks green, that one red. Its diff moves @xmldom/xmldom ×2 and qs, and touches no fast-uri line.

The consequence is sharper than "a follow-on card": #14736 cannot satisfy its own acceptance criterion. #14639 exists to make that check green, and it will not be green when #14736 merges. This card is the remaining half of that same green condition.

Routing — terminal, pick the branch that matches the world at claim time

Both edits land in the same override block of pnpm-workspace.yaml and both regenerate pnpm-lock.yaml.

1. PR fix(deps): take the fix for the four OSV advisories blocking every manifest PR #14736 still open when you claim this ⇒ ⛔ do not open a second PR against pnpm-workspace.yaml. Add the fast-uri bump to fix(deps): take the fix for the four OSV advisories blocking every manifest PR #14736 as a further commit, one pnpm install --lockfile-only regeneration covering both, and say so in your report. This is inside fix(deps): take the fix for the four OSV advisories blocking every manifest PR #14736's acceptance criterion, not scope creep — the check it exists to green is red for exactly these four advisories.
2. fix(deps): take the fix for the four OSV advisories blocking every manifest PR #14736 already merged ⇒ take the card as filed on a fresh branch off main.

⚠️ Correcting an assumption before someone else forms it: no gate enforces the above. I checked scripts/check-single-claim-paths.mjs expecting pnpm-workspace.yaml to be a single-writer path — it is not. SINGLE_CLAIM_PATHS holds exactly one entry (.objectui-sha), and its header rules out precisely this class: "Anything that is merely hot (a lock file, a root manifest, a shared registry) does NOT belong here … listing one would produce a steady stream of red on PRs that are both correct." A duplicate PR here passes every gate and conflicts only at merge. The routing above is discipline, and it needs to be followed as such.

Fix shape (as filed, and it stands)

Move the target ^3.1.5 → ^3.1.6; ⛔ leave the <4.0.0 selector alone — bounds sit at the compatibility boundary per that block's header rule, never at the fixed version, which self-invalidates the day that version is the one flagged (the undici 7.28.0 / brace-expansion 5.0.8 specimens). ajv@8.20.0 declares ^3.0.1 and already admits 3.1.6, so this is a dedupe onto the patched line, not a forced upgrade past a dependent.

Not merged into #14639: that card's body enumerates four specific advisories at 6.3 medium and is closed by them. These are four distinct GHSAs at 7.5 high. Same file, same check, different findings — and p1 for the same reason #14639 is: the red is queue-shaped for every PR touching a manifest.

---

Generated by Claude Code

[claude]

Claim: session session_01WLJQhde67SeTccsmnBVarV (domain:devx execution seat, seat post #6023) — R1 wave 9, p1 security. Routing branch 2 of triage 5518573590 applies: PR #14736 (#14639) MERGED d4ac61fc6 00:49Z ⇒ fresh branch off main.

• Branch: claude/issue-14732-osv-fast-uri-lift
• Worktree: ../objectstack-14732 (dedicated per-task worktree, off origin/main)
• Domain: domain:devx (same class as Validate Package Dependencies is red for every PR touching a package.json — 4 FIXABLE OSV advisories in the lockfile (@xmldom/xmldom, qs) #14639; lockfile + override block).
• File surface: pnpm-workspace.yaml — the existing 'fast-uri@<4.0.0': '^3.1.5' override (:253): move the TARGET to ^3.1.6 (⛔ the <4.0.0 selector stays — bounds sit at the compatibility boundary, never at the fixed version) and update the block comment's advisory list to name the four new GHSAs; pnpm-lock.yaml regenerated by pnpm ONLY (pnpm install --lockfile-only), diff limited to the fast-uri resolution moving. ⛔ No osv-scanner.toml exemption (ledger at zero, its own rule). ⛔ No other dependency moves. ⛔ No validate-deps.yml change (The weekly OSV scan has no outlet, so a new advisory is discovered by whichever PR author next touches a package.json — six occurrences in a month #14645).
• Premise re-verified on origin/main 96b772330: pnpm-workspace.yaml:253 still 'fast-uri@<4.0.0': '^3.1.5'; ajv@8.20.0 declares ^3.0.1 (admits 3.1.6); nothing in the workspace declares fast-uri; PR fix(deps): take the fix for the four OSV advisories blocking every manifest PR #14736's Validate Package Dependencies was red on exactly these four (observed, per triage). No open PR touches pnpm-workspace.yaml / pnpm-lock.yaml after fix(deps): take the fix for the four OSV advisories blocking every manifest PR #14736 merged. Premise holds.
• Container & model: subagent lane (S — one target lift + lockfile regeneration + the scanner reading), sonnet.
• Clause ②: not reached. Serial constraints: the lockfile is the hot object — merge origin/main right before the final commit and re-run the regeneration on top if it conflicts. Changeset: none ⇒ skip-changeset.

---

Generated by Claude Code