pnpm-workspace.yaml

packages:
  - packages/*
  - packages/apps/*
  - packages/drivers/*
  - packages/plugins/*
  - packages/qa/*
  - packages/triggers/*
  - packages/services/*
  - packages/adapters/*
  - packages/connectors/*
  - apps/*
  - examples/*

onlyBuiltDependencies:
  - better-sqlite3
  - esbuild
  - mongodb-memory-server
  - msw
  - sharp

# Patched dependencies. Written with `pnpm patch` / `pnpm patch-commit`, never
# by hand. `patch-commit` writes this key into package.json's `pnpm` field;
# move it here, beside `overrides` and `onlyBuiltDependencies`, then run
# `pnpm install`.
#   - tsup@8.5.1: its bundled rollup-plugin-dts gave every DTS entry its own
#     ts.Program. tsup always passes the tsconfig path, and on that path a
#     config-cache hit keyed each later entry by its own directory. The patch
#     keys every entry by the tsconfig's directory, so all entries share one
#     program. The same code is in rollup-plugin-dts 6.5.1. Twelve packages
#     here have more than one DTS entry; @objectstack/spec had 18 programs
#     and now has one, and its DTS pass went from 4997 MB to 882 MB of live
#     heap. Every one of the twelve emits the same types as before.
#     The key names the exact version. When the installed tsup is any other
#     version, the patch goes unused and `pnpm install` fails
#     (ERR_PNPM_UNUSED_PATCH), so a tsup upgrade cannot drop the patch
#     silently. Re-derive the patch, or retire it, on every tsup bump.
#   - tsx@4.23.15: this release moved its ESM-API registration out of a
#     dist/ chunk and into dist/esm/api/index.cjs, two directories deeper,
#     without rebasing three file-relative specifiers. The one that bites is
#     the module.register() hooks URL: it now names
#     dist/esm/api/esm/index.mjs, which does not exist. So a CommonJS caller
#     of `tsx/esm/api` gets ERR_MODULE_NOT_FOUND from register() on every
#     Node that lacks tsx's registerHooks path (below 22.22.3 on the 22
#     line, below 24.11.1 on the 24 line, and 25.0.x). The caller here is
#     @oclif/core's ts-path. It swallows the error, logs "Could not find tsx"
#     at debug level, and stays on dist/. Two things break on such a Node.
#     packages/cli/bin/run-dev.js, the SOURCE entry that the CLI's spawning
#     tests run, silently loads dist/commands instead of src/commands. And
#     the CONTROL leg of
#     packages/cli/test/published-entry-node-env-source-reroute.test.ts
#     cannot arm, so that file's absence legs stay green with the guard
#     they pin deleted. The patch points the three specifiers back at the
#     files 4.23.14 resolved: dist/esm/index.mjs (two of them) and
#     dist/loader.mjs. Nothing else in the file changes. It ships nowhere:
#     a published @objectstack/cli install resolves an unpatched tsx, and
#     its bin/run.js never lets oclif register tsx. Retire the patch when a
#     tsx release resolves those three paths itself. Until then the same
#     exact-version rule as tsup's applies on every tsx bump.
patchedDependencies:
  tsup@8.5.1: patches/tsup@8.5.1.patch
  tsx@4.23.15: patches/tsx@4.23.15.patch

# Transitive-dependency version pins. pnpm v10 reads `overrides` from THIS file
# — the `pnpm.overrides` block in package.json is silently ignored — so all
# pins must live here (previously orphaned in package.json: minimatch, tar).
#
# ⛔ SELECTOR SHAPE — the one rule every OSV pin below now follows (#6095).
# An OSV pin states a FLOOR ("nothing below the patched line"), so its selector
# must cover the whole major it guards and its target must be a range that
# floats up inside that major — UNLESS the package's export surface is one we
# compile against, in which case the target is an EXACT version and lifting it
# is a reviewed edit (the better-auth family, #16186: 1.7.3 deleted a public
# export in a PATCH). The selector rule below is unchanged either way, and it
# is what keeps an exact target a one-line lift.
# Concretely:
#     'pkg@>=<affected floor> <next major above the target>': '^<patched>'
# Never write the selector's exclusive upper bound AT the target's own version
# line (`pkg@<X.Y.Z` -> `^X.Y.Z`). That shape self-invalidates the day X.Y.Z
# itself gets an advisory: you lift the target and the selector silently stops
# covering the very versions you need to rewrite — the live specimen is
# `undici@>=7.23.0 <7.28.0` on the day 7.28.0 was flagged (#4961, #5032).
# With the bound at the major boundary, ONLY the target moves from now on.
# Equally never let the bound sit BELOW the target floor: the old
# `@hono/node-server@<2.0.5` -> `^2.0.10` left the whole 2.0.5 .. 2.0.10 band
# covered by nobody at all (#6095 fixed it).
# For a 0.x line the "major boundary" is the caret boundary (0.35.x -> <0.36.0),
# because that is where semver's compatibility break actually falls.
# `scripts/check-override-consistency.mjs` reports (never fails on) any entry
# that drifts back into the old shape. One carve-out deliberately keeps it:
# the three zero-consumer pins awaiting a #5835-style ruling
# (@tootallnate/once, react-router, @sveltejs/kit). (`@better-auth/scim` was
# the other carve-out while it held the rc; #3653 moved it onto stable with
# the bound at the major boundary, #13715 returned its TARGET to the family's
# `^`, and #16186 moved the whole family back to an EXACT target — see its
# note below. All three are about the resolved version, not the selector shape
# this rule governs.)
#   - esbuild: GHSA-gv7w-rqvm-qjhr (high). tsup/tsx/vite pulled 0.27.7 / 0.28.0
#     (< 0.28.1); force the patched line everywhere.
#   - form-data: GHSA-hmw2-7cc7-3qxx (high) — CRLF injection via unescaped
#     multipart field names. Pulled 4.0.5 transitively through @vscode/vsce;
#     force the patched >=4.0.6 line. Fails `pnpm audit --audit-level=high` (CI).
#     CONSUMER GONE (#5825): retiring packages/vscode-objectstack took @vscode/vsce
#     with it, and form-data no longer resolves anywhere in the tree — this
#     selector now matches nothing. Kept as defense-in-depth so a future
#     transitive reintroduction lands on the patched line instead of silently
#     re-arming the advisory; dropping a security pin is its own decision, not a
#     rider on a package retirement. Retire it deliberately or not at all.
#   - undici: GHSA-vmh5-mc38-953g (high) — TLS cert validation bypass via
#     dropped requestTls in SOCKS5 ProxyAgent. Pulled 7.27.2 through
#     @vscode/vsce > cheerio (declares undici ^7.19.0); force the patched
#     7.28.0 line (stays in the 7.x major cheerio supports). CI audit gate.
#     Then five more advisories landed on 7.28.0 itself — the version this pin
#     had settled on (GHSA-4cwx-7wf7-3272 7.4 high, GHSA-jr45-8vmc-qm54 5.9,
#     GHSA-8xcm-r25x-g524 / GHSA-v3r7-h72x-cjcm 4.8, GHSA-m8rv-5g2x-5cg5 4.2) —
#     so the target moves to ^7.29.0 (#5032). NOTE the recurring trap this
#     specimen taught: an exclusive upper bound stops covering the very version
#     it pinned once that version is itself flagged — same shape as the
#     brace-expansion 5.0.8 → 5.0.9 lift (#4945). That is why the selector is
#     now `>=7.23.0 <8.0.0` (#6095): the bound sits at the major boundary, so a
#     future lift moves the TARGET alone and the pin never silently misfires.
#     CONSUMER GONE (#5825): cheerio came in only through @vscode/vsce, which
#     left with packages/vscode-objectstack. The two undici copies that remain
#     are @ai-sdk/provider-utils' 7.29.0 and jsdom's 8.9.0. Under the old
#     `<7.29.0` bound BOTH sat outside the selector and it matched nothing;
#     under the `<8.0.0` bound of #6095 the 7.29.0 copy is back in scope (it
#     already satisfies the ^7.29.0 target, so nothing moved — measured), which
#     is exactly the point: the next 7.x advisory will now catch it. jsdom's
#     8.9.0 is a different major and stays outside, unaffected. Kept as
#     defense-in-depth on the same reasoning as form-data above.
#     2026-09-29: GHSA-3wwx-pv8p-q78v (5.9) flags BOTH remaining copies —
#     7.29.0 (fixed 7.29.1) and jsdom's 8.9.0 (fixed 8.10.2) — so the 7.x
#     target lifts to ^7.29.1 and the 8.x line gets its own selector; see the
#     OSV 2026-09-29 note at the foot of the overrides block.
#   - @better-auth/scim: GHSA-j8v8-g9cx-5qf4 (high) — account/provider
#     takeover, patched only in >=1.7.0-beta.4. The pin sat on the 1.7.0-rc.1
#     PRE-RELEASE while stable 1.7.x shipped the rc.2 REWRITE (no
#     `scimProvider` model, no generate-token endpoint, seven replacement
#     models: scimUser, scimGroup, scimGroupMember, scimSubject,
#     scimConnectionBinding, scimIdentityTombstone, scimProjectionGrant),
#     because moving it was the ADR-0134 feature migration tracked by #3653 —
#     NOT the version bump #3002 did for the rest of the family. That
#     migration has LANDED (#3653, epic #11632): the seven stable models are
#     provisioned as platform objects, connections are runtime data resolved
#     by an application-owned `verifyBearerToken` in plugin-auth, and
#     `sys_scim_provider` retires separately under #11757. The
#     `managedConnections` catalog (three more conditional models) is
#     deliberately NOT adopted — maintainer ruling 2026-08-25, no real
#     customers, no pull.
#     The TARGET is the family's `^1.7.2`. It was held at `1.7.1` EXACT while
#     the family sat on `^1.7.1`; #13715 was the follow-up that ruling named,
#     and it moved the whole family to `^1.7.2` in step — see the comment at
#     the override line below.
#     The rc-era better-call skew is GONE: stable 1.7.1 peers
#     `better-call@1.4.0` exactly — measured unchanged on 1.7.2, the version
#     this lockfile now holds, and still the one better-call copy — so
#     the scaffold `peerDependencyRules` entries for
#     `@better-auth/scim>better-call` retired with the pin move (#3653).
#     Its sibling line is better-auth's own stale `better-sqlite3@^12.0.0`
#     peer against our `^13.0.3`. That one is NOT reported here, because
#     `auto-install-peers=true` (.npmrc) quietly installs a second, unused
#     better-sqlite3 12.11.1 to satisfy it — which is why CI never saw what a
#     scaffolded project shows on its first screen. #10326 measured 1.7.1 as
#     behaviourally identical on 13.0.3 and 12.11.1 and left this workspace's
#     resolution untouched; only the scaffolds declare it (their
#     `better-auth>better-sqlite3` and `@better-auth/utils` entries do NOT
#     retire with #3653 — their conditions are separate and unmet).
#     `scripts/check-prerelease-pin-watch.mjs` now has nothing to watch and
#     says so — the self-retiring exit its own header promised.
#   - @better-auth/oauth-provider: GHSA-p2fr-6hmx-4528 — same better-auth
#     monorepo and same situation as @better-auth/scim above. The fix first
#     shipped in the 1.7.0 pre-release line; it is now in stable 1.7.x, and
#     #3002 moved this pin (and the whole family bar scim) off `1.7.0-rc.2`
#     onto `^1.7.1` — npm `latest` for every family member is 1.7.1, verified
#     by `npm view <pkg> dist-tags`. The 1.7 oauth-provider is exercised on the
#     sign-in path and imports symbols (e.g. CLIENT_ASSERTION_TYPE) that only
#     exist in @better-auth/core 1.7.x, so the ENTIRE family must stay on ONE
#     line — mixing a 1.7 plugin with 1.6.x core throws "Cannot set properties
#     of undefined (setting 'modelName')" during better-auth init and 500s
#     every auth endpoint at runtime. That is now cheap to hold: `better-auth`
#     itself declares EXACT dependencies on the rest of the family
#     (`@better-auth/core`, the five adapters, telemetry all at 1.7.1), so one
#     stable range on the root drags the family with it.
#     The pins are kept rather than dropped because two of them
#     (oauth-provider, scim) are OSV floors: a transitive reintroduction must
#     land on the patched line, and dropping a security pin is its own
#     decision, not a rider on a version bump (same reasoning as form-data /
#     undici above).
#     IMPORTANT: these overrides do NOT ship with published packages — a
#     downstream `npx create-objectstack` install resolves plugin-auth's own
#     declared ranges. plugin-auth therefore declares the same exact `1.7.2`
#     in its dependencies (a `^1.6.23` range there resolved to the broken
#     1.6.23 mix and 500'd every fresh 15.1.0 project; a `^1.7.2` range there
#     resolved to 1.7.3 and made every fresh 17.1.0–17.3.0 project unloadable,
#     #16186). Keep both in sync — CI enforces this via
#     scripts/check-override-consistency.mjs, and
#     scripts/check-vendor-export-contract.mjs enforces that the DECLARED
#     range admits exactly one version and that version exports every symbol
#     plugin-auth imports.
#   - uuid: GHSA-w5hq-g745-h8pq (high) — pulled 8.3.2 transitively; the fix
#     first lands in 11.1.1. Pin to the ^11.1.1 LTS line (uuid `legacy-11`
#     dist-tag) rather than the latest major to keep the jump conservative.
#   - postcss: GHSA-qx2v-qp2m-jg93 — a transitive path still resolves 8.4.31
#     (the direct `apps/docs` dep already tracks ^8.5.x); force the patched
#     ^8.5.10 line so the transitive copy is deduped onto it.
#   - cookie: GHSA-pxg6-pf52-xh8x — pulled 0.6.0 transitively; force the
#     patched 0.7.0 line (drop-in compatible).
#   - svelte: GHSA-9rmh-mm8f-r9h6, GHSA-f3cj-j4f6-wq85, GHSA-pr6f-5x2q-rwfp,
#     GHSA-rcqx-6q8c-2c42 — auto-installed (auto-install-peers) as an *optional*
#     peer-of-a-peer via better-auth > @sveltejs/kit at 5.55.3. An `overrides`
#     entry alone can't rewrite this resolution (pnpm rewrites the peer range
#     but leaves the locked 5.55.3), so the patched line is pinned by BOTH this
#     override AND a `svelte: ^5.55.7` devDependency in the root (private)
#     package.json, which gives the peer a concrete version to dedupe onto.
#     Keep both in sync; removing the root devDependency reintroduces 5.55.3.
#   - @tootallnate/once: GHSA-vpq2-c234-7xj6 (low) — pulled 1.1.2 through a
#     legacy agent chain; force the patched 2.0.1 line.
overrides:
  esbuild: '>=0.28.1'
  'minimatch@<11.0.0': '^10.2.3'
  'tar@>=2.0.0 <8.0.0': '^7.5.11'
  'form-data@<5.0.0': '>=4.0.6'
  'undici@>=7.23.0 <8.0.0': '^7.29.1'
  'undici@>=8.1.0 <9.0.0': '^8.10.2'
  # better-auth family — kept on one line (see @better-auth/oauth-provider note).
  # Off the 1.7.0-rc.2 prerelease and onto the stable line (#3002). Bounds sit
  # at the MAJOR boundary, so a future advisory lift moves only the TARGET.
  #
  # ⛔ EXACT TARGETS, not `^`, since #16186. This family removes public exports
  # in PATCH releases: 1.7.3 deleted `createLocalAccountIssuer` /
  # `createOAuthAccountIssuer` and the whole `account.issuer` column from
  # `@better-auth/core/db` (better-auth/better-auth#10909 rolled the
  # issuer-scoped account identity back), and `@objectstack/plugin-auth`
  # statically imported both names. A caret cannot express "the export surface
  # we compile against", so `^` here means the tested version and the shipped
  # version are free to differ — which is exactly what happened: this
  # lockfile held 1.7.2 and every CI job was green while every consumer of
  # published 17.1.0–17.3.0 resolved 1.7.3 and could not load the plugin at
  # all. The selectors keep their `<2.0.0` major boundary, so lifting the
  # family later is still a target-only edit.
  #
  # The target IS 1.7.3 since #17440: the platform adopted the vendor's
  # rollback rather than owning a fork of a model its author abandoned, so
  # nothing here imports the two deleted names any more and `sys_account`
  # no longer carries the column they served. What did NOT change is the rule
  # above — the exact target stays exact for the reason 1.7.3 demonstrated,
  # and 1.7.4 (published) is the next reviewed one-line lift, not a float.
  #
  # These targets are held EQUAL to the ranges `@objectstack/plugin-auth`
  # declares (`scripts/check-override-consistency.mjs` cross-checks that the
  # declared range admits the target; `pnpm check:vendor-export-contract`
  # requires the declared range to be exact and to export what we import).
  # Move all eleven together, in one commit, or better-auth init throws and
  # every auth endpoint 500s.
  'better-auth@<2.0.0': '1.7.3'
  '@better-auth/core@<2.0.0': '1.7.3'
  # scim carries the family's target — see the @better-auth/scim note
  # above. It was held at 1.7.1 EXACT, one deliberate step behind `^1.7.1`,
  # because `^1.7.1` then resolved scim to 1.7.2 while the installed family
  # was still 1.7.1: scim 1.7.2 peers `better-auth`/`@better-auth/core` at
  # `^1.7.2`, and these very overrides would have rewritten those peer ranges
  # down and SILENCED the mismatch rather than satisfy it (#3653 ruling,
  # 2026-08-27, which named the fix as its own follow-up "with the family
  # moved in step, never a side effect of a lockfile refresh"). #13715 IS that
  # follow-up: all eleven members move together in one commit, for the reason
  # the @better-auth/oauth-provider note gives — one line, or better-auth init
  # throws and every auth endpoint 500s.
  # The step is measured gone. `npm view <pkg> dist-tags.latest` reads 1.7.2
  # for all eleven; the install resolves all eleven to 1.7.2 (one copy each),
  # so scim's `^1.7.2` peers are SATISFIED by the installed 1.7.2 pair rather
  # than silenced — the condition the exact hold existed for no longer holds.
  # It carried `^1.7.2` from #13715 until #16186, on two arguments the 1.7.3
  # release answered. Structural — "the siblings peer `^1.7.2` and carry `^`,
  # so an exact scim would be the one asymmetric member" — is moot now that
  # ALL eleven are exact; the family is symmetric again, one line lower.
  # Security — "this pin is also the GHSA-j8v8-g9cx-5qf4 floor, and a floor
  # that cannot take the next patch is the wrong shape" — was the reasoning
  # 1.7.3 refuted: taking the next patch UNREVIEWED is what a floor must not
  # do when the vendor deletes public exports in one. 1.7.2 is above the
  # patched line for GHSA-j8v8-g9cx-5qf4 and GHSA-p2fr-6hmx-4528, so the floor
  # still holds; what changed is that lifting it is now a reviewed edit, which
  # is the only way an export-surface change gets read before it ships. That
  # review has somewhere to land: `pnpm check:vendor-export-contract` fails on
  # a lift whose new version drops a symbol `plugin-auth` imports.
  # What stays true: the whole family still moves as ONE line, and a bump that
  # moves scim alone is still the mistake the #3653 ruling named.
  '@better-auth/scim@<2.0.0': '1.7.3'
  '@better-auth/oauth-provider@<2.0.0': '1.7.3'
  '@better-auth/sso@<2.0.0': '1.7.3'
  '@better-auth/drizzle-adapter@<2.0.0': '1.7.3'
  '@better-auth/kysely-adapter@<2.0.0': '1.7.3'
  '@better-auth/memory-adapter@<2.0.0': '1.7.3'
  '@better-auth/mongo-adapter@<2.0.0': '1.7.3'
  '@better-auth/prisma-adapter@<2.0.0': '1.7.3'
  '@better-auth/telemetry@<2.0.0': '1.7.3'
  'uuid@<12.0.0': '^11.1.1'
  'postcss@<9.0.0': '^8.5.10'
  'cookie@<0.8.0': '^0.7.0'
  svelte: '^5.55.7'
  '@tootallnate/once@<2.0.1': '2.0.1'
  # OSV batch 2026-07 — transitive-only fixes (no publishable package declares these):
  # brace-expansion GHSA-mh99-v99m-4gvg (via minimatch@10.x), then GHSA-rgw5-rvv9-x895
  # (7.5 high) which affects 5.0.8 itself — the version the first pin landed on — so the
  # target moves to ^5.0.9 — the selector keeps its <6.0.0 major boundary (#6095), which is
  # what makes this a target-only lift. Still transitive-only through minimatch (ts-morph, eslint,
  # @typescript-eslint, glob, archiver — @vscode/vsce left with #5825's retirement,
  # the rest still pull it, so this pin stays live); sharp GHSA-f88m-g3jw-g9cj
  # (next optionalDep ^0.34.5 excludes the fix); react-router GHSA-qwww-vcr4-c8h2 has no
  # 7.x fix — fumadocs-core peer allows 8.x and docs uses the next adapter, so jump to 8;
  # @sveltejs/kit GHSA-866w-xmhq-wj7x/GHSA-wqjv-9729-c5q2 (better-auth optional peer);
  # 2026-09-09 (#16999): sharp GHSA-rgj7-g3m4-5g8c (8.9 high) — the target lifts
  # from ^0.35.0 to ^0.35.4; the selector is untouched, because <0.36.0 already
  # sits at the 0.x compatibility boundary this block's header names. Still
  # transitive-only via next's optional dependency, and 0.35.4 is a patch inside
  # the 0.35 line the pin already held, so nothing declares a range that has to
  # move in lockstep.
  # 2026-10-06 (#22013): sharp GHSA-wq5f-xc86-pv6w (8.9 high, a memory bug in
  # the librsvg its prebuilt binaries bundle; range introduced:0 -> fixed:0.35.5,
  # read from the OSV offline npm database the scanner downloads) — the target
  # lifts again, from ^0.35.4 to ^0.35.5, and the selector stays untouched at
  # the <0.36.0 caret boundary. A dedupe, not a forced upgrade: next@16.3.6
  # declares the optional `sharp: ^0.35.4`, which already admits 0.35.5, and
  # 0.35.4 was the single resolved copy. Its prebuilt @img/sharp-* binaries
  # move with it (0.35.5, libvips 1.3.4), because sharp pins them exactly.
  # @hono/node-server GHSA-frvp-7c67-39w9 has no 1.x fix — @modelcontextprotocol/sdk
  # declares ^1.19.9 and only imports getRequestListener, which 2.x still exports.
  # ⚠️ @hono/node-server is the exception to this block's "transitive-only" heading:
  # plugin-hono-server declares it directly (^2.0.12). Under the <3.0.0 bound that
  # declaration is now in the selector's scope and the lockfile records ^2.0.10 as its
  # specifier — the resolved version is unchanged at 2.0.12, because the ^2.0.10 target
  # floats to the newest 2.x (measured, #6095).
  # brace-expansion, 2026-09-30 (#20769): three MORE advisories, GHSA-6j4f-fj2g-mc7p,
  # GHSA-qhr7-859c-m2p7 and GHSA-q2hr-2g5m-vwhr, fixed in 5.0.12 — target lifted from
  # ^5.0.9, selector stays at the <6.0.0 major boundary. This floor keeps THIS
  # workspace's resolution from re-locking 5.0.9; overrides do not reach downstream
  # installs, so a consumer's own brace-expansion copy is theirs to lift.
  'brace-expansion@>=5.0.0 <6.0.0': '^5.0.12'
  'sharp@>=0.34.0 <0.36.0': '^0.35.5'
  'react-router@<8.3.0': '^8.3.0'
  '@sveltejs/kit@<2.69.1': '^2.69.1'
  '@hono/node-server@<3.0.0': '^2.0.10'
  # OSV batch 2026-08 (#5032) — all three name a fixed version, so they are
  # upgrades, not exemptions (the osv-scanner.toml route #4965 defines is for
  # advisories with NO fix and does not apply here):
  #   fast-uri GHSA-7p8r-x3mc-p8w7 (7.5 high) — transitive-only via ajv@8.20.0
  #     (declares ^3.0.1), which reaches @modelcontextprotocol/sdk, objectql,
  #     secretlint and table. Nothing declares fast-uri directly.
  #     2026-09-03 (#14732): four MORE fast-uri advisories, GHSA-5jgf-p345-68v8,
  #     GHSA-f65p-4m7j-42xc, GHSA-fph4-wmhf-6fwf and GHSA-jqff-g426-hqxp (7.5
  #     high each), fixed in 3.1.6 — target lifted from ^3.1.5, selector stays
  #     at the 4.0.0 boundary. ajv@8.20.0's ^3.0.1 already admits 3.1.6, so
  #     this is a dedupe onto the patched line, not a forced upgrade.
  #     2026-09-30 (#20769): GHSA-hrr3-gc8f-f4qj, fixed in 3.1.8 — target lifted
  #     from ^3.1.6, selector stays at the 4.0.0 boundary. ajv@8.20.0's ^3.0.1
  #     admits 3.1.8, so this is again a dedupe onto the patched line. The floor
  #     binds this workspace's resolution only; overrides do not reach downstream
  #     installs.
  #   hono GHSA-8j4g-w8fx-2239 (5.3) — the one entry here that is NOT
  #     transitive-only: two versions resolved, 4.12.32 from our own packages
  #     and 4.12.33 pulled by @modelcontextprotocol/sdk. The override moves the
  #     transitive copy; the declared ranges are bumped to ^4.12.34 in lockstep
  #     (plugin-hono-server dependency, plugin-auth + @objectstack/hono
  #     devDependencies) so a downstream install — which never sees these
  #     overrides — resolves the same patched line that CI tested. The
  #     @objectstack/hono PEER range stays the permissive ^4.12.8 on purpose: a
  #     peer states what host hono we work against, and a host that pins an old
  #     hono owns that copy; narrowing it fixes nothing here and only breaks
  #     compatibility. check-override-consistency.mjs covers both forms.
  #     2026-09-09 (#16999): three MORE hono advisories, GHSA-crvj-82cr-hjcx
  #     (5.9), GHSA-g6gw-c38x-mqfc (5.3) and GHSA-gqvv-2mrq-wpjv (6.5), fixed in
  #     4.13.5 — target lifted from ^4.12.34, selector stays at the 5.0.0
  #     boundary, so this is the target-only lift that shape exists to allow.
  #     The lift is ALSO what collapses the duplicate: the scanner flagged hono
  #     at TWO resolved versions, 4.12.34 (pulled by @modelcontextprotocol/sdk)
  #     and 4.13.2 (our three declarations, floated up by the old ^4.12.34
  #     target). 4.12.34 satisfied ^4.12.34, so lockfile inertia left the
  #     transitive copy sitting on the floor while ours moved; ^4.13.5 excludes
  #     it, both edges must re-resolve, and the tree deduplicates onto one hono.
  #     A bump that moved only our declarations would have left the 4.12.34 copy
  #     flagged and the gate red. @hono/node-server peers hono ^4.12.34, which
  #     4.13.x satisfies, so neither node-server version has to move.
  #     The declared ranges go to ^4.13.5 in lockstep for the downstream-install
  #     reason above; the @objectstack/hono PEER range stays ^4.12.8, unchanged,
  #     for the reason above it.
  'fast-uri@<4.0.0': '^3.1.8'
  'hono@<5.0.0': '^4.13.5'
  # OSV 2026-08-07 (#6407) — transitive-only, and the same "it has a fix, so
  # take the fix" disposition as the batch above:
  #   dompurify GHSA-55q2-fjhq-7xh7 (5.1 medium) — an IN_PLACE hook removal
  #     leaves a detached subtree executable (XSS). Advisory range is
  #     introduced:0 → fixed:3.4.13, i.e. every version up to and including
  #     3.4.12 is affected, so the selector's floor is the package floor and
  #     only the upper bound needs stating. Transitive-only via mermaid
  #     (apps/docs declares mermaid ^11.16.0; mermaid@11.16.1 declares
  #     dompurify ^3.3.3). Nothing in this workspace declares dompurify
  #     directly, so there is no publishable manifest to keep in lockstep —
  #     check-override-consistency.mjs will list this as an override it cannot
  #     cross-check against a declared range, which is correct for this shape.
  #     ^3.4.13 sits INSIDE mermaid's own ^3.3.3 range, so this is a dedupe onto
  #     the patched line rather than a forced upgrade past what mermaid supports.
  #     Bound at the 4.0.0 major boundary per this block's header rule — never
  #     `<3.4.13`, which would self-invalidate the day 3.4.13 is itself flagged
  #     (the undici 7.28.0 / brace-expansion 5.0.8 specimens, #4961 / #5032).
  #     2026-10-01 (#21055): that day came. GHSA-p98j-92pf-mc4p (2.3 low) — an
  #     IN_PLACE node-removing afterSanitize hook leaves the detached subtree's
  #     event handlers armed (DOM XSS); range introduced:3.4.13 → fixed:3.4.16,
  #     read from the OSV offline npm database the scanner downloads. Target
  #     lifted from ^3.4.13, selector unchanged at the 4.0.0 boundary — the
  #     target-only lift that boundary exists to allow. mermaid@11.16.1's
  #     ^3.3.3 admits 3.4.16, so this is again a dedupe onto the patched line.
  #     The floor binds this workspace's resolution only; overrides do not
  #     reach downstream installs.
  'dompurify@<4.0.0': '^3.4.16'
  # OSV 2026-08-08 (#6529) — same "it names a fixed version, so take the fix"
  # disposition as the two batches above; no exemption is involved.
  #   nanoid GHSA-2v37-7h3g-55p8 / CVE-2026-67213 (8.2 high) — a custom
  #     alphabet generator loops forever when `size` is zero, so an
  #     attacker-influenced size is a denial of service. The advisory carries
  #     TWO affected ranges: introduced:0 → fixed:3.3.17, and
  #     introduced:4.0.0 → fixed:5.1.6. Only the first one is live here.
  #     Transitive-only via postcss@8.5.25, which declares nanoid ^3.3.16 and
  #     was the single consumer pulling the flagged 3.3.16 (measured: one
  #     `nanoid:` edge in the whole lockfile). Nothing in this workspace
  #     declares a 3.x nanoid directly, so — exactly as for dompurify above —
  #     check-override-consistency.mjs lists this as an override it cannot
  #     cross-check against a declared range, which is correct for this shape.
  #     ^3.3.17 sits INSIDE postcss's own ^3.3.16 range, so this is a dedupe
  #     onto the patched line, not a forced upgrade past what postcss supports.
  #     ⚠️ The four drivers that declare nanoid ^6.0.0 (driver-mongodb,
  #     driver-sql, driver-sqlite-wasm, driver-turso) are deliberately OUT of
  #     this selector: 6.0.0 is above the advisory's second fixed line (5.1.6)
  #     and is not affected, and the <4.0.0 bound is what keeps it that way —
  #     a bound written at the package ceiling would have dragged that whole
  #     major back onto the 3.x line.
  #     Bound at the 4.0.0 major boundary per this block's header rule — never
  #     `<3.3.17`, which would self-invalidate the day 3.3.17 is itself flagged
  #     (the undici 7.28.0 / brace-expansion 5.0.8 specimens, #4961 / #5032).
  'nanoid@<4.0.0': '^3.3.17'
  # OSV 2026-09-02 (#14639) — four advisories, every one naming a fixed
  # version, so this is the "take the fix" path osv-scanner.toml's own header
  # describes and NOT an exemption; that ledger holds zero entries and the
  # triage ruling is that it stays at zero.
  #   @xmldom/xmldom GHSA-6gmq-8vp8-gcm6 (6.3 medium) — flagged on BOTH
  #     resolved lines: 0.8.13 (fixed 0.8.15) and 0.9.11 (fixed 0.9.12). That
  #     is why this needs TWO selectors and not one. A single lower-bounded
  #     selector at the fixed 0.9.12 would drag the 0.8 consumers across a 0.x
  #     MINOR — the compatibility boundary for a 0.x package — past every
  #     range they declare. Measured dependents and their declared ranges:
  #       0.8.13 <- @authenio/xml-encryption@2.0.2 (^0.8.6),
  #                 samlify@2.13.1 (^0.8.11), xml-crypto@6.1.2 (^0.8.10)
  #       0.9.11 <- @better-auth/sso@1.7.2 (^0.9.10)
  #     Each of those ranges already admits its own fixed version, so both
  #     entries are a dedupe onto the patched line rather than a forced
  #     upgrade past what a dependent supports — the dompurify / nanoid shape
  #     above, and the reason no dependent manifest has to move in lockstep.
  #   qs GHSA-4mjr-xmp4-gh2g and GHSA-x5fp-wj9c-mxmx (6.3 medium each) — one
  #     resolved line, 6.15.3, fixed 6.16.0. Dependents body-parser@2.3.0
  #     (^6.15.2) and express@5.2.1 (^6.14.0) both admit it.
  #   Transitive-only, like dompurify and nanoid above: no workspace manifest
  #     declares either package, so there is no publishable declared range to
  #     keep in lockstep and check-override-consistency.mjs lists both as
  #     overrides it cannot cross-check against a declared range. That is
  #     correct for this shape, and it is a report, never a failure.
  #   Bounds sit at the compatibility boundary — 0.9.0 and 0.10.0 for the two
  #     0.x lines, 7.0.0 for qs — per this block's header rule, never at the
  #     fixed version itself, which would self-invalidate the day that version
  #     is the one flagged (the undici 7.28.0 / brace-expansion 5.0.8
  #     specimens, #4961 / #5032).
  '@xmldom/xmldom@>=0.8.0 <0.9.0': '^0.8.15'
  '@xmldom/xmldom@>=0.9.0 <0.10.0': '^0.9.12'
  'qs@>=6.0.0 <7.0.0': '^6.16.0'
  # OSV 2026-09-18 (#18930) — one advisory, and it names a fixed version, so
  # this is the "take the fix" path osv-scanner.toml's own header prescribes
  # and NOT an exemption; that ledger stays at ZERO entries.
  #   devalue GHSA-9rgm-9g3h-6x36 (5.3 medium) — flagged at the single resolved
  #     line 5.9.0, fixed 5.9.2. It turned `Validate Package Dependencies` red
  #     on `main` itself (scheduled run 35301766597, step 13), so every PR
  #     touching any package.json inherited a red that was not its own.
  #     Transitive-only: no workspace manifest declares devalue, so there is no
  #     publishable declared range to keep in lockstep and
  #     check-override-consistency.mjs lists it as an override it cannot
  #     cross-check against a declared range — correct for this shape, and a
  #     report, never a failure. Reached through svelte@5.56.9, which declares
  #     `devalue: ^5.8.1` — a range that ALREADY admits 5.9.2, so this is a
  #     dedupe onto the patched line rather than a forced upgrade past what the
  #     dependent supports (the dompurify / nanoid shape above).
  #     Why the pin rather than a bare resolver refresh: the lockfile sat on
  #     5.9.0 purely through lockfile inertia — 5.9.0 satisfied ^5.8.1, so
  #     nothing re-resolved it when 5.9.1 and 5.9.2 published, the same
  #     mechanism the hono note above records. `pnpm update devalue -r --depth
  #     Infinity` does clear it, but it re-resolves the whole tree and moved
  #     twelve unrelated packages (type-fest, seroval, postcss, nanoid, knex,
  #     picomatch, ip-address, isbot, node-abi, use-sync-external-store …) in
  #     one 107/87-line lockfile churn; the override moves devalue alone and
  #     leaves a floor behind, so a future transitive reintroduction lands on
  #     the patched line instead of silently re-arming the advisory.
  #     ONE resolved copy in the whole tree (measured, `pnpm why devalue`), so
  #     the floorless selector forces nothing else onto the 5.x line.
  #     Bound at the 6.0.0 major boundary per this block's header rule, never
  #     `<5.9.2`, which would self-invalidate the day 5.9.2 is itself flagged
  #     (the undici 7.28.0 / brace-expansion 5.0.8 specimens, #4961 / #5032).
  #     ⚠️ The advisory's CONTENT is NOT characterised here: api.osv.dev and
  #     GitHub's /advisories endpoint are both refused by the authoring
  #     container's egress proxy, so the severity and the fixed version above
  #     are read off the scanner's own output line and nothing else.
  'devalue@<6.0.0': '^5.9.2'
  # OSV 2026-09-29 (#20561, scan run 36510180397) — seven Medium findings,
  # every one naming a fixed version, so this is the "take the fix" path
  # osv-scanner.toml's header prescribes and NOT an exemption; that ledger
  # stays at ZERO entries. Advisory ranges below are read from the OSV
  # offline npm database the scanner itself downloads; nodemailer (the one
  # DIRECT dependency flagged) is taken in plugin-email's declared range and
  # needs no pin here.
  #   ip-address GHSA-2vr4-cq9g-pvrc (6.9; NAT64 local-use 64:ff9b:1::/48
  #     classified as global, affected >=10.2.0) and GHSA-rpw4-54j3-4h4q
  #     (6.3; isLinkLocal() checks fe80::/64 instead of fe80::/10, affected
  #     from 0) — both fixed in 10.5.1. Flagged at TWO resolved copies:
  #     10.4.0 <- express-rate-limit@8.6.1 (^10.2.0) <- @modelcontextprotocol/sdk,
  #     and 10.5.0 <- socks@2.8.9 (^10.1.1) <- mongodb. Both declared ranges
  #     already admit 10.5.1, so this is a dedupe onto the patched line rather
  #     than a forced upgrade past what a dependent supports (the dompurify /
  #     nanoid shape above); both copies sat below it purely through lockfile
  #     inertia, the mechanism the devalue note records. Transitive-only: no
  #     workspace manifest declares ip-address, so there is no published
  #     declared range for check-override-consistency's manifest rule to hold
  #     in lockstep with the target (it has none to cross-check, and says
  #     nothing about this entry). GHSA-rpw4's range starts at 0, so
  #     the selector's floor is the package floor and only the upper bound is
  #     stated (the dompurify shape); the bound sits at the 11.0.0 major
  #     boundary per this block's header rule, never `<10.5.1`.
  #   undici GHSA-3wwx-pv8p-q78v (5.9; a malformed permessage-deflate frame
  #     past the size limit crashes the process from the WebSocket client) —
  #     three affected lines, >=6.25.0 <6.28.1, >=7.28.0 <7.29.1 and
  #     >=8.1.0 <8.10.2.
  #     Two are live here, one copy each: 7.29.0 <- @ai-sdk/provider-utils
  #     (^7.28.0), and 8.9.0 <- jsdom@30.0.1 (^8.9.0). The 7.x copy is already
  #     inside the existing `>=7.23.0 <8.0.0` selector, so that entry is a
  #     TARGET-ONLY lift to ^7.29.1 — exactly the edit its major-boundary
  #     bound exists to allow. The 8.x copy sat OUTSIDE every selector (the
  #     undici note at the head of this file recorded it as a different,
  #     unaffected major), so it gets its own entry, floored at the
  #     advisory's 8.1.0 and bounded at the 9.0.0 major boundary. Both
  #     dependents' ranges admit their fixed version, so both are dedupes
  #     onto the patched line. No 6.x copy resolves anywhere, so no 6.x pin is
  #     written. Transitive-only and dev-only: nothing publishable declares
  #     undici, and both paths reach the tree through devDependencies.
  'ip-address@<11.0.0': '^10.5.1'
  # OSV 2026-10-06 (#21945, scheduled scan run 37407261685) — one advisory that
  # names a fixed version, so this is the "take the fix" path osv-scanner.toml's
  # header prescribes and NOT an exemption.
  #   katex GHSA-238p-pmpm-9mq7 (2.1 low) — an inherited `Object.prototype.trust`
  #     is read as an explicit `trust: true`, so a prototype pollution that
  #     already exists elsewhere lets attacker math emit links or load external
  #     resources. Range introduced:0.11.0 -> fixed:0.18.2, read from the OSV
  #     offline npm database the scanner downloads. Flagged at the single
  #     resolved copy 0.16.47.
  #   ⚠️ Unlike the dedupes above, this is a FORCED upgrade past the dependent's
  #     declared range. The one consumer is mermaid@11.16.1 (apps/docs declares
  #     mermaid ^11.16.0), which declares katex ^0.16.45, and no published
  #     mermaid admits the fix: 11.17.0 through 12.1.0 all declare ^0.16.47
  #     (npm view, 2026-10-06). mermaid touches katex in one place, a lazy
  #     `import("katex")` that calls the default export's renderToString() with
  #     { throwOnError, displayMode, output } for a `$$...$$` label. The 0.17 and
  #     0.18 breaking changes (the internal __defineFunction API, prefixed
  #     internal CSS classes) touch neither that call nor the outer `.katex`
  #     class mermaid styles. Measured: a mermaid 11.16.1 flowchart with a
  #     `$$...$$` label renders MathML through katex 0.18.10 in Chromium, under
  #     the same initialize() options apps/docs/components/mermaid.tsx passes.
  #     The target resolves to 0.18.10, not 0.18.11: 0.18.11 is deprecated on
  #     npm ("Accidentally published with breaking changes"), and pnpm skips it.
  #   Transitive-only and docs-only: nothing publishable declares katex, so
  #     check-override-consistency.mjs's manifest rule has no declared range to
  #     hold in lockstep and says nothing about this entry (measured; neither
  #     census lists it: mermaid consumes it, and the bound clears the target
  #     floor). The floor is the advisory's 0.11.0; the bound is 0.19.0, the
  #     caret boundary of the 0.18 target line, per this block's header rule —
  #     never `<0.18.2`.
  #     Re-check when a mermaid release declares a katex range that admits
  #     0.18.2: the entry then turns into a dedupe and stays as the floor.
  'katex@>=0.11.0 <0.19.0': '^0.18.2'
  # OSV 2026-10-06 (#22013, PR #22002 run 37483796939) — one more advisory that
  # names a fixed version, so this is the "take the fix" path osv-scanner.toml's
  # header prescribes and NOT an exemption. (The same scan's sharp row is the
  # target lift on the sharp entry above.)
  #   shell-quote GHSA-pqg4-j6r4-53mv (9.2 critical) — quote() lets a line
  #     terminator in a string after a `{ comment }` token end the comment, so
  #     the rest of that string runs as shell input. Range introduced:1.8.4 ->
  #     fixed:1.11.0, read from the OSV offline npm database the scanner
  #     downloads. Flagged at the single resolved copy 1.10.0.
  #   A dedupe onto the patched line, not a forced upgrade: the one path is
  #     launch-editor@2.14.1 (declares `shell-quote: ^1.8.4`, which admits the
  #     fix) <- @changesets/cli@3.0.3 <- the root package.json's
  #     devDependencies, and the copy sat on 1.10.0 through lockfile inertia
  #     (the devalue mechanism above).
  #   Why an override and not a bump: no release up that path forces the fix.
  #     @changesets/cli 3.0.3 is npm `latest` and declares launch-editor
  #     ^2.14.1; launch-editor's latest, 2.14.2, declares shell-quote ^1.10.0,
  #     which still admits the flagged 1.10.0 (npm view, 2026-10-06). So a bump
  #     would move a devDependency and still leave the floor to this entry.
  #   The ^1.11.0 target floats to 1.12.0, the newest 1.x. launch-editor calls
  #     shell-quote in one place, parse() on the editor command (guess.js);
  #     1.11.0 and 1.12.0 only teach parse() ANSI-C quoting and more operators,
  #     and the vulnerable quote() is never called on this path. The fix is
  #     taken anyway: the gate reads the lockfile, not the call graph.
  #   Transitive-only and dev-only: nothing publishable declares shell-quote,
  #     so check-override-consistency.mjs's manifest rule has no declared range
  #     to hold in lockstep. The floor is the advisory's 1.8.4; the bound sits
  #     at the 2.0.0 major boundary per this block's header rule, never
  #     `<1.11.0`.
  'shell-quote@>=1.8.4 <2.0.0': '^1.11.0'