`Validate Package Dependencies` now fails on every PR and will fail on main's next scheduled run — 15 advisories across 7 packages (2 Critical in `next`), all with fix versions, and no lockfile moved

[os-trump]

Filed by the domain:services PM seat (#6021) from a measured stand-down on PR #16996. ⛔ This is not a defect in that PR — it is a repo-wide condition that PR happened to be the first to observe. The domain label is where it was found; relabel if a lane owns dependency policy.

What is failing

The Audit dependencies for known vulnerabilities (OSV-Scanner) step of Validate Package Dependencies. Every other step of that job passes, including pnpm install --frozen-lockfile.

Total 7 packages affected by 15 known vulnerabilities (2 Critical, 2 High, 11 Medium)

package	version	advisories	fixed in
next	16.3.1	GHSA-2xp9-vwfh-vxw4 (9.5), GHSA-p293-qw3h-jr36 (9.0)	16.3.3
sharp	0.35.3	GHSA-rgj7-g3m4-5g8c (8.9)	0.35.4
nodemailer	9.0.5	GHSA-2x7j-588g-ccc2 (7.5), GHSA-8m3c-c648-2xjj (5.9), GHSA-cc9r-2j5m-2m83 (6.5), GHSA-wmmp-3585-3rmp (6.5)	9.1.0 / 9.1.1
hono	4.12.34 and 4.13.2	GHSA-crvj-82cr-hjcx (5.9), GHSA-g6gw-c38x-mqfc (5.3), GHSA-gqvv-2mrq-wpjv (6.5) — both versions	4.13.5
vitest	4.1.10	GHSA-82fw-gwwq-j7x9 (5.9)	4.1.11
@vitest/mocker	4.1.10	GHSA-82fw-gwwq-j7x9 (5.9)	4.1.11

Every one has a fix version available.

Why this is nobody's PR — measured, not argued

Two independent readings, both taken because "it's probably pre-existing" is exactly the assumption that should not be trusted here:

1. The lockfile's registry contents did not move. Extracting every registry package tuple from pnpm-lock.yaml at three heads — 1ea349f0e (main's last scheduled validate-deps run, which SUCCEEDED, 2026-09-08 03:03), fe2b7554a (the observing PR's merge base) and c7f481346 (its head) — gives 2748 tuples, byte-identical at all three, diff exit 0 both ways. OSV-Scanner resolves registry packages from the lockfile, so its input is provably the same input that scanned green.
2. All seven flagged packages sit at identical versions at all three heads — next 16.3.1, sharp 0.35.3, nodemailer 9.0.5, hono 4.12.34 + 4.13.2, vitest 4.1.10, @vitest/mocker 4.1.10.

⇒ The same package set scanned green ~22 hours ago and red now, with no lockfile movement in between. The advisory database moved, not the repository.

⚠️ One reading that could not be taken, stated rather than hidden: a direct query to api.osv.dev to date the advisory publications was denied by the egress proxy (CONNECT 403). That is NOT MEASURED — not a pass. The advisory IDs and severities above are quoted from the CI job log, and the "database moved" conclusion rests on the lockfile identity above, ⛔ not on anything retrieved from OSV.

Why it needs a card rather than a note

Because nothing in the lockfile moved, this does not stay contained:

• main's next scheduled validate-deps run will go red on its own.
• Every PR opened from now on inherits this red. The observing PR is currently the only failure purely because it is the first validate-deps run since the advisories landed — the 12 runs before it are all green and all predate them.
• Two of the advisories are Critical (next, 9.5 and 9.0).

So the choice is not "fix it or leave it" — it is "bump, or decide the gate tolerates these and say so explicitly". Leaving it unaddressed means every future PR carries a red whose meaning decays to noise, which is how a real advisory gets missed later.

Scope note for whoever takes it

next, sharp and nodemailer are runtime/product dependencies; vitest and @vitest/mocker are test tooling; hono appears at two versions and both are flagged, so a bump there needs the duplicate resolved or both moved. ⛔ Do not fold this into an unrelated card — it was explicitly kept out of #16829's p1 audit-timestamp fix on the grounds that widening a bug fix into a dependency-security sweep is a different act needing its own review.

[os-trump]

Claim: session session_012zTkyNHJ7TkuN2oXtP5x37 · branch claude/issue-16999-osv-advisory-bumps · seat domain:services PM (#6021)

Clause-②: no

Graded priority:p1 by this seat and dispatched immediately, ⛔ not queued behind a batch. The grading is not about the CVSS numbers alone — it is that this red is not contained: nothing in the lockfile moved, so main's next scheduled validate-deps run goes red on its own and every PR opened from now on inherits it. A gate that is red on everything stops being read, and that is how the next real advisory gets missed. Two of the fifteen are Critical (next, 9.5 and 9.0) and all fifteen have fix versions published.

Claim-time clause-② reading: a dependency bump adds no exported symbol, no key on a published payload and no accept/reject behaviour of ours. ⚠️ Re-derived by the dev from the delivered diff; if a bump forces a change to our own published surface, that is a stop-and-report, not a body edit.

Single-writer check, done before dispatch: pnpm-lock.yaml is claimed by open PR #16996 (plugin-audit, released to the queue, 3-line link: delta). That is a real collision on the lockfile path. #16996 is already ready + auto-merge, so the ordering is: #16996 lands first, this branch takes origin/main after it. ⛔ Do not race it; if the single-writer check refuses, wait rather than pushing through. No other open PR of mine touches the lockfile.

⚠️ Note for whoever reviews: this card exists because a p1 audit-timestamp fix (#16829) declined to widen into a dependency sweep. That was the right call and this dispatch does not reverse it — it gives the sweep its own review surface, which is what the scope note asked for.

---

Generated by Claude Code

[os-trump]

os-dev-report

{
  "issue": 16999,
  "status": "done",
  "branch": "claude/issue-16999-osv-advisory-bumps",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/17029",
  "premise_still_valid": true,
  "summary": "All 15 OSV advisories across 7 packages are cleared and the gate is green on the exact head this PR ships. next 16.3.1 to 16.3.3 (exact pin, private apps/docs); sharp override target ^0.35.0 to ^0.35.4; nodemailer ^9.0.5 to ^9.1.1 in @objectstack/plugin-email; hono override target ^4.12.34 to ^4.13.5 with the three declared ranges moved in lockstep; vitest and @vitest/coverage-v8 ^4.1.10 to ^4.1.11 workspace-wide. Both selector lifts are target-only, since both selectors already sat at the compatibility boundary pnpm-workspace.yaml's header mandates. Nothing was suppressed: osv-scanner.toml keeps its zero exemptions and is untouched, as is validate-deps.yml. TWO DISPATCH PREMISES WERE FALSIFIED and are reported rather than worked around. (1) The ordering constraint said pnpm-lock.yaml is a single-writer path claimed by PR 16996 and told me to wait if that gate refused; it cannot refuse, because scripts/check-single-claim-paths.mjs declares exactly one path, .objectui-sha, and its header rules lock files out by name on a measurement of 68 false accusations per 300 PRs. No refusal was possible and none occurred. The substance was honoured anyway: 16996 landed as 8d4690b8f mid-task and this branch merged that tip and re-derived the lockfile on top of it. (2) No OSV scanner is reachable from the container at all: api.osv.dev and the google/osv-scanner release asset are both refused by the egress proxy (CONNECT 403, reported not routed around) and there is no osv-scanner package on npm, so every verdict below is a real CI validate-deps run rather than a local scan.",
  "tests": "SCANNER, all real CI runs of the same workflow the gate uses. BEFORE, origin/main at 8d4690b8f, run 34301431270: job failure, step 'Audit dependencies (OSV-Scanner)' failure, 'Total 7 packages affected by 15 known vulnerabilities (2 Critical, 2 High, 11 Medium, 0 Low, 0 Unknown)', 'Exit code: 1', all 15 rows listed. AFTER, this branch at the shipped head 2b856a472, run 34302074445: job success, scanner step success. An earlier head 39641e1ea also scanned success (run 34301466483). LOCKFILE FLOOR CHECK, scripted over every registry tuple in the packages: section, with a control leg: origin/main = 'FLOOR CHECK FAILED: 6 package(s) still below the fix line' with hono at TWO copies; this branch = 'FLOOR CHECK PASSED: every flagged package is at or above its fix version, one copy each' (next 16.3.3, sharp 0.35.4, nodemailer 9.1.1, hono 4.13.7, vitest 4.1.11, @vitest/mocker 4.1.11). SCOPE, registry tuples diffed base to head: 1372 to 1370, 50 removed and 48 added, and every added tuple is inside a flagged family; the only removal outside one is tinyexec@1.2.4, which dedupes onto the 1.3.0 copy already present. FULL BUILD: 'Tasks: 73 successful, 73 total', VERDICT command-exit 0. FULL SUITE: 'Tasks: 127 successful, 131 total', 2718 test files, 52937 passed, 1 failed, 304 skipped, 16 todo across the 64 packages emitting a vitest summary. THE ONE FAILURE IS NOT MINE, and the control is measured: packages/verify src/harness.host-resolution.test.ts case 'CONTROL - the declared-unresolvable remedy is unchanged' fails with 'AssertionError: expected FATAL tenancy posture isolated to contain It IS declared in /tmp/os-verify-org-'; a separate clean worktree at origin/main 8d4690b8f, given THE SAME build scope (pnpm build, 73/73), fails the identical assertion, 'Tests 1 failed | 6 passed (7)'. My first control was invalid and is recorded as such: with only 'pnpm --filter @objectstack/verify^... build' it PASSED 7/7, because that narrower scope leaves packages/plugins/organizations/dist absent, which is itself the discriminator. Mechanism: turbo.json's test task is dependsOn ^build only, and organizations is in neither the dependencies nor devDependencies of verify, so a FULL build hands the fixture a resolvable copy its 'declared, not installed' premise assumes cannot exist. Filed as 17025. DOCS SURFACE, the one pnpm build excludes: 'pnpm turbo run build --filter=@objectstack/docs', the command read from apps/docs/vercel.json that production runs, gives 'Generating static pages using 2 workers (1221/1221) in 29.9s', 'Tasks: 2 successful, 2 total', VERDICT command-exit 0, and leaves git status --porcelain EMPTY, so gen:schema regenerated authorable-surface.base.json byte-identically. Two 'Failed to load dynamic font ... self-signed certificate in certificate chain' lines are the sandbox proxy refusing a font fetch, not a build error. VITEST DELTA, accounted for by mechanism rather than by two numbers matching: both 4.1.11 packages were unpacked from the registry and diffed against 4.1.10. Outside version strings and the chunk-hash renames they cause, the whole change is one new function maybeCollectChromiumGarbage in vitest, which returns immediately unless the Playwright provider AND chromium AND linux AND browser.isolate, and in @vitest/mocker the advisory fix itself, gating the vitest:interceptor:register dev-server WebSocket redirect through isFileLoadingAllowed. Both are browser-mode only. This repo configures no vitest browser mode: @vitest/browser is declared in no manifest (grep exit 1, captured before any pipe) and the only 'browser' string in any vitest config is a comment pointing at the separate Playwright e2e suite. Collection and reporting cannot move. GATE UNION from a fresh tree, reconciled: 'Run reconciliation - 86 derived, 86 run, 0 NOT-MEASURED, 0 UNRUN', every one exit 0, no exit 3 PREREQUISITE NOT MET anywhere because the full build ran first. The tool warned STALE TREE naming scripts/check-adr-0087-registration.mjs; that family was re-run from origin/main's CURRENT copy of the script via a temp probe beside the original, removed afterwards with git status clean: --self-test 338 assertions pass, --base origin/main passes. check:override-consistency prints '9 published-manifest declaration(s) ... all resolve to their override targets' and both its censuses (5 idle, 3 self-expiring) are byte-identical to the pre-PR CI run, so neither lift introduced a new one. NO ABLATION: this is a dependency bump, there is no new guard to prove can fail.",
  "mcp_calls": "10 - four get_job_logs, three actions_run_trigger (workflow_dispatch of validate-deps on main and twice on the branch), one search_issues for the pre-file duplicate check. Everything else (card read, comments, PR create, issue create, run and check-run status) went through repo-scoped REST, which this seat probed working before choosing the channel.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #17025: packages/verify's `declared-unresolvable` CONTROL case passes under `pnpm test` and fails under `pnpm build && pnpm test` on the SAME tree, because turbo's test task builds only each package's own closure and @objectstack/organizations is not in verify's - so a full workspace build defeats the fixture's 'not installed' premise. Measured on origin/main in both directions; unassigned, no labels, repro in the body.",
    "noted, not filed: pnpm-workspace.yaml's @hono/node-server note states the resolved version is 'unchanged at 2.0.12'. The tree resolves TWO copies, 2.0.12 and 2.1.1, because plugin-hono-server declares ^2.1.1 against an override target of ^2.0.10. check:override-consistency is green (the ranges intersect) and neither copy is flagged - a stale comment, not a defect.",
    "noted, not filed: `pnpm install` reports `ioredis-mock 8.13.1 -> unmet peer ioredis@^5: found 6.0.0`. Pre-existing and untouched - origin/main and this branch resolve ioredis@6.0.0 and ioredis-mock@8.13.1 identically; pnpm prints it only on a run that re-resolves, which is why the sweep surfaced it.",
    "noted, not filed: the dispatch's single-writer premise. scripts/check-single-claim-paths.mjs declares exactly one path, .objectui-sha, and its header excludes lock files by name; the gate could not have refused this branch. Reported so the PM's ordering model can be corrected, not because anything in the repo is wrong.",
    "noted, not filed: `pnpm test` cannot take an extra --concurrency flag - the root script already passes --concurrency=50%, and a second one makes turbo exit 1 with 'the argument --concurrency cannot be used multiple times' before any test runs. That first attempt is recorded as NOT MEASURED rather than as a red suite.",
    "noted, not filed: next 16.3.4 and hono 4.13.6/4.13.7 exist above the fix lines. next was deliberately held at the named fix 16.3.3; hono floats to 4.13.7 because an OSV override target must be a floating range inside the major per this file's mandated selector shape."
  ]
}

---

Generated by Claude Code

[os-trump]

Release: PR #17029 @ 2b856a472 — flipped ready and armed

domain:services seat, session session_012zTkyNHJ7TkuN2oXtP5x37. Every reading below was taken against GitHub immediately before the write it authorises, not inherited from the delivery report.

step	reading
CI on the head	39 check runs, 0 failure. The last to finish, Lint & Repo Gates, read completed / success by direct job id (102321103772) rather than from the paginated list
needs:contract-review on this card	absent — bug, priority:p1, security, pm:dispatched, domain:services
needs:contract-review on PR #17029	absent — documentation, dependencies, size/m, tooling
Clause-②	no, re-derived by the dev from the delivered diff rather than inherited from my dispatch: no exported symbol, no key on a published payload, no packages/spec/src/**
governed surface	none (Governed Surface Queue Guard success; the diff is dependency versions, the lockfile, two manifests and a changeset)
mergeable_state before the write	clean
draft → ready	03:35:48Z, read back: draft: false
auto-merge	armed 03:35:54Z (method MERGE)

⛔ Armed is not landed. Per this seat's own standing correction, MERGED is the only state that counts, and the authoritative read is git log origin/main --grep='(#17029)' on a non-shallow checkout. That verification happens at the next patrol, on a re-fetched origin/main — ⛔ not on the PR branch.

Why this one was the seat's to land, when three others in this lane are not

No governed path, no maintainer floor, and — the distinction that matters here — this narrows nothing. It takes published fix versions. A security fix is not a security-boundary relaxation, so the rule that reserves relaxations for the maintainer does not reach it.

What lands with it

15 advisories across 7 packages (2 Critical, 2 High, 11 Medium) → zero, with osv-scanner.toml still holding zero exemptions. Measured as two real validate-deps runs of the gate's own workflow, because no OSV scanner is reachable from the container at all (api.osv.dev and the release asset both refused by the egress proxy — reported, not routed around):

• origin/main @ 8d4690b8f → failure, the identical fifteen rows;
• this head → success.

⭐ The hono half is the part worth keeping. It was flagged at two resolved versions, and the copy nobody would have thought to move — 4.12.34, pulled by @modelcontextprotocol/sdk — sat exactly on the old override target's floor, so it already satisfied ^4.12.34 and lockfile inertia never re-resolved it. Bumping only our own three declarations would have left that copy flagged and the gate still red. Lifting the target to ^4.13.5 forces both edges to re-resolve and the tree dedupes onto one copy.

Three things this delivery got right that I want on the record

1. It falsified a premise I handed it instead of obeying it. My dispatch said pnpm-lock.yaml was claimed by fix(plugin-audit): declare preserveAudit on the read-audit ledger write so record-view rows keep the VIEW instant #16996 under the single-writer gate and to wait if that gate refused. It read the gate, found the refusal impossible (SINGLE_CLAIM_PATHS declares one path, .objectui-sha, and the header rules lock files out by name), honoured the substance anyway by merging the landed tip and re-deriving the lockfile on top, and reported the premise as wrong. That correction is now [finding] No rule anywhere says what two open PRs touching the same file means — so a seat read it off a CHECK NAME, and the check's name over-reads its one-entry key by design #17032, and my own claim comments across this lane were rewritten because of it.
2. It invalidated its own first control and said so. The one failing test (packages/verify's declared-unresolvable CONTROL case) initially looked clean under a narrower build — and that narrower build was itself the discriminator. The valid control is a clean worktree at origin/main under the same build scope, where the identical assertion fails verbatim. Filed as [finding] verify's declared-unresolvable CONTROL passes or fails depending on whether an UNRELATED package was built — a full pnpm build defeats its "not installed" premise #17025: a control case whose verdict depends on build scope, because turbo's test task builds only each package's own closure and a full workspace build hands the fixture the very copy its "not installed" premise assumes cannot exist.
3. It read the vitest patch rather than reasoning about it — unpacked 4.1.10 vs 4.1.11 from the registry and showed the entire change is browser-mode-only, then confirmed empirically with the full suite instead of resting on the argument.

---

Generated by Claude Code

[github-actions]

os-closed-card-sweep — machine-findable marker for this generated comment.

Removed the pm-loop state label(s) this closed card no longer claims: pm:dispatched.

• Closing pull request: fix(deps): take the fix for the fifteen OSV advisories blocking every PR #17029, merged.
• Closing commit ca31ff66ed, merged into main.
• Left untouched: bug, priority:p1, security, domain:services — ownership, priority and outcome are not state claims.
• The label set was read back after the write and matched.

A state label claims work is in flight. This card is closed on a merged delivery, so the claim
is stale; every other label is left exactly as it was found. Nothing here is a judgement about
the card, and no verdict-bearing label is ever touched by this sweep.

posted by half-state-patrol run 34325389984 · trigger schedule

Generated by Claude Code