chore(deps): collect the open Dependabot updates

[oscharko]

Summary

Collects all seven open Dependabot pull requests into one branch so they are gated and integrated
as a single unit instead of seven separate ~30-minute CI cycles. Every update is a development-only
dependency or a CI action pin; no production dependency and no product source file changed.

Collected updates, in ascending PR number order (each merged with git merge --no-ff from the
Dependabot head, so authorship is preserved):

PR	Package	From	To	Kind
#3003	jsdom	29.1.1	30.0.1	devDependency
#3004	postcss	8.5.23	8.5.25	devDependency
#3005	github/codeql-action/init	4.37.1	4.37.4	GitHub action pin
#3006	github/codeql-action/analyze	4.37.1	4.37.4	GitHub action pin
#3014	@playwright/test	1.62.0	1.62.1	devDependency
#3015	vite	8.1.4	8.2.0	devDependency
#3016	@vitejs/plugin-react	6.0.3	6.0.5	devDependency

The original seven PRs are intentionally left open and unmodified; they close when this lands.

Conflict resolution and two corrections Dependabot could not make

Four of the seven merges needed manual resolution. The lockfile was never regenerated from scratch
in any of them: the dev-side lockfile was taken and only the bumped subtree was moved with
npm install --package-lock-only, then verified entry by entry.

1. overrides.postcss was advanced 8.5.23 → 8.5.25 (root package.json). PR deps(deps-dev): bump postcss from 8.5.23 to 8.5.25 #3004 raised
   keiko-ui's declared range to ^8.5.25 and the lock entry to 8.5.25, but left the root
   single-version overrides pin at 8.5.23. Those two contradict: the override wins at install
   time, so the bump would have been inert and the declared range a dead letter. Advancing the
   override in lockstep is the established pattern on this exact line — collector PRs [codex] Roll up Dependabot dependency updates #1708, chore(deps): combine dependabot updates #2648,
   chore(deps): consolidate compatible Dependabot updates #2677 and chore(deps): consolidate Dependabot updates #2964 each did the same. The resulting lock entry carries byte-identical
   resolved/integrity values to Dependabot's own.
2. Three lockfile workspace mirrors were resynced to their own package.json. Dependabot's
   generated lockfiles recorded caret ranges (^30.0.1 for jsdom, ^8.2.0 for vite) while the
   very same PRs wrote exact pins (30.0.1, 8.2.0) into the workspace package.json files. The
   mirrors were corrected to match the declarations. No resolved version changed.

Content conflicts in packages/keiko-ui/package.json and packages/keiko-editor/package.json were
adjacent-line collisions only (jsdom next to postcss; @vitejs/plugin-react next to jsdom) — both
sides' bumps were kept.

Reviewer notes on the two diffs that look larger than a version bump

• package-lock.json nets −314 lines on the vite merge. This is a dedupe, not a removal of
  functionality. keiko-ui previously pinned vite exactly at 8.1.4 while the hoisted copy sat at a
  different version, forcing a full nested packages/keiko-ui/node_modules/ tree of vite plus every
  platform-specific @rolldown/binding-*. At 8.2.0 the specs agree, npm hoists, and that duplicate
  tree collapses. Exactly one package entry disappears from the graph:
  @rolldown/binding-wasm32-wasi, an optional WASI fallback binding. Total audited packages go
  878 → 874. The merge result is byte-identical to PR deps(deps-dev): bump vite from 8.1.4 to 8.2.0 #3015's own diff.
• @vitejs/plugin-react moves in four places — root package.json plus the keiko-ui and
  keiko-editor workspaces, and the single hoisted lock entry — because all three declare it.

Scope

• In scope: the seven collected Dependabot updates; the overrides.postcss advance they require;
  lockfile mirror resync.
• Out of scope: any product source change; any production dependency; regenerating the lockfile;
  the pre-existing editor-release-evidence drift described under Risk Notes.

Reuse And No-Duplication

• Existing Keiko functionality was inspected before implementation.
• This PR reuses, extends, generalizes, or consolidates existing functionality where practical.
• Any new implementation is limited to a documented capability gap in the linked issue.
• This PR does not introduce a parallel workspace, graph, relationship, policy, evidence, memory, connector, workflow, or UI subsystem where an existing subsystem can be extended.
• Refactoring or consolidation was considered when existing functionality was close but not shaped for this change.

No new code was written. The one judgement call — advancing overrides.postcss — followed the
precedent set by four prior collector PRs on that same line rather than inventing a new mechanism.

Delivery Board

This is a routine dependency-collection PR with no linked issue or epic, so the board items below
do not apply. Auto-merge is deliberately not armed; the required CI run is the arbiter.

• Linked issue is in the public Keiko Product Delivery project.
• Linked issue has a valid Parent Epic: #<epic_number> unless this PR updates an epic container directly.
• Linked issue is attached as a GitHub sub-issue of its parent epic so it appears in the correct board swimlane.
• Parent epic is on the board with Classification: Epic, Status: Open Epics, and priority/order set for top-to-bottom implementation sequencing.
• Linked task/card issue is on the board with Classification: Task, Status: In Progress while active, inherited or explicit Priority, and Human Review Required: No.
• Project Status is In Progress while work is active, or Done only after merge and closure evidence.
• Project Workflow State is PR Open while deterministic gates or repairs are active.
• Owner / Agent, Branch, Pull Request, and Human Review Required are filled.
• Issue label remains status: in progress until verified auto-merge, then becomes status: done.
• Autonomous repair stayed on the PR branch; no direct dev push, force-push, finding dismissal, or required-gate bypass occurred.
• Native auto-merge was armed only after the ADR-0135 direct required checks settled. — not armed.
• If Keiko for Quality is enabled, arming followed ADR-0170 D5. — not applicable, nothing armed.

Product Impact

• UI or user workflow
• UI text uses the i18n API and includes English and German catalog entries.
• CLI or developer workflow
• Core generation engine
• Evidence, audit, or compliance artifact
• Security or supply chain
• Packaging, release, or npm publication
• Documentation or repository hygiene
• No user-facing behavior change

Update Impact

• Not release-impacting.
• Release-impact catalog or issue metadata updated.
• Release-note category: internal-only.
• Priority: internal.
• User-visible change: none. Every bump is a devDependency or a CI action pin; the shipped runtime
  graph is unchanged, and npm audit --omit dev reports 0 vulnerabilities before and after.
• Release-note bullet: n/a — internal only.
• Supported-from versions: unchanged (0.3.0).
• Affected state stores: none.
• User action required and remediation: none.
• Internal-only rationale: development toolchain and CI pins only; no production dependency, no
  product source file, and no packaged surface changed. npm run check:release-impact passes
  without a catalog edit.
• Release-owner review evidence: check:release-impact PASS (exit 0), recorded below.

Verification

Required:

• npm run gates:sonar was run on this diff and reported no finding.
• Required GitHub checks pass before merge. — pending this PR's run.
• npm run check:ui-i18n passes, or no UI production source changed.
• Local verification commands or rationale are listed below.
• Reuse/extension/generalization evidence or gap rationale is listed below.

Local verification:

Every command below was run in this worktree on macOS (darwin/arm64), Node v24.18.0, npm 11.16.0.
Exit codes were captured from each command directly, never through a pipe.

npm install                        exit 0   no-op; `git status` clean afterwards
npm run provision:usearch          exit 0   fresh-worktree prerequisite (ADR-0164)
npm run typecheck                  exit 0   toolchain PASS; package-graph PASS
npm run lint                       exit 0   root + keiko-ui, --max-warnings=0
npm run format:check               exit 0   all matched files use Prettier style
npm test                           exit 0   1568 files passed / 7 skipped; 28660 tests passed / 20 skipped
npm run check:knip                 exit 0   no unused files, exports, dependencies, or binaries
npm audit --omit dev               exit 0   found 0 vulnerabilities
npm run gates:sonar                exit 0   PASS - no unresolved finding on the 5 changed files
npm run arch:check                 exit 0   0 violations (5357 modules, 19387 dependencies)
npm run arch:check:negative        exit 0   gate fired on all 52 fixtures as expected
npm run check:version-consistency  exit 0   every package reports 0.3.0
npm run check:editor-bundle-size   exit 0   own-code gzip 77972 B / 102400 B ceiling
npm run check:ui-i18n              exit 0   0 changed UI source files
npm run check:release-impact       exit 0   current version has reviewed update-impact metadata
npm run build:ui                   exit 0   static export builds clean

npm run check:editor-release-evidence   exit 1   PRE-EXISTING on dev — see Risk Notes

The one non-zero exit was reproduced on an unmodified origin/dev checkout in this same worktree and
produces a byte-identical fingerprint pair, so it is not caused by this PR. Details in Risk Notes.

Reuse / gap rationale:

No new code. The seven upstream branches were merged with --no-ff to preserve Dependabot
authorship rather than cherry-picking or hand-applying the bumps.

The lockfile was never regenerated. On each conflict the dev-side package-lock.json was taken with
`git checkout --ours`, then only the bumped subtree was moved via `npm install --package-lock-only`,
and the resulting entry was compared against Dependabot's own `resolved` and `integrity` values.
For @vitejs/plugin-react 6.0.5 the integrity hash was diffed directly against PR #3016's lockfile
and matches exactly.

Advancing overrides.postcss reuses the existing single-version override mechanism and follows the
precedent of collector PRs #1708, #2648, #2677 and #2964, which each advanced that same line
alongside the corresponding postcss bump. No new pinning mechanism was introduced.

Select only what applies:

• UI behavior manually verified or covered by tests.
• CLI behavior verified with command output or tests.
• Core logic covered by unit, integration, property, or fixture tests.
• Security-sensitive change reviewed for trust boundaries, secrets, external calls, and generated artifacts.
• Supply-chain or package-surface change verified with package, license, lockfile, SBOM, or npm dry-run checks.
• Documentation or Markdown change verified by the repository link check or a targeted local equivalent.
• Release-impacting change verified with npm run check:release-impact or an explicit rationale.
• Not applicable items are explained below.

Not applicable rationale:

• No UI or CLI behavior change to verify manually: no product source file is touched, only
  devDependency versions and two CI action pins. The full vitest suite (28660 tests) covers the
  behavioral surface that the jsdom, vite and plugin-react bumps could plausibly disturb.
• No Markdown or documentation file changed.

Risk Notes

• check:editor-release-evidence fails locally, and it fails identically on unmodified dev.
  Committed fingerprint 4d91f10e…, locally measured 951ab458…. To establish ownership I
  detached to origin/dev in this same worktree, ran npm install and npm run build:ui, and
  re-ran the gate: it produced exactly the same pair of hashes. Two things follow. First, the
  drift pre-dates this PR and is not mine to repair inside a dependency collector. Second — and
  more useful — because my branch measures the same 951ab458… as dev, the vite 8.2.0 and
  @vitejs/plugin-react 6.0.5 bumps do not change the editor bundle output at all. The
  deterministic budget gate check:editor-bundle-size passes on this branch (exit 0). I did not
  regenerate the evidence: the committed document was measured on the pinned Linux reference
  container, and AGENTS.md §3 forbids replacing CI/Linux evidence with macOS-generated values.
  Regenerating here would have overwritten authoritative evidence with a wrong-platform
  measurement. Flagging for a separate, correctly-provisioned regeneration.
• vite 8.1.4 → 8.2.0 is the largest functional risk in this set: it is the bundler for
  keiko-ui and keiko-editor. It is covered by a green full test suite, a green build:ui, and a
  green check:editor-bundle-size.
• jsdom 29.1.1 → 30.0.1 is a major bump and is the test DOM for the keiko-ui and keiko-editor
  jsdom suites. The full suite passes with no new failures or skips.
• The two CodeQL action bumps keep the required full 40-hex SHA pin plus version comment format;
  both now resolve to f205ea1c3313d32999d8d6a48b4f6530d4437b38 # v4.37.4, and no other workflow
  still references the old pin.
• Auto-merge is not armed and the seven source PRs are untouched, per the scope of this task.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for security reviews. Please try again later.

[coderabbitai]

Warning

Review limit reached

@oscharko, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 33 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 60268015-8df8-445d-b7ed-0513709d80aa

📥 Commits

Reviewing files that changed from the base of the PR and between 211149d and f0bd1b2.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (5)

• .github/workflows/codeql.yml
• .github/workflows/dependency-review.yml
• package.json
• packages/keiko-editor/package.json
• packages/keiko-ui/package.json

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​postcss@​8.5.23 ⏵ 8.5.25	+1		+1
	npm/​jsdom@​29.1.1 ⏵ 30.0.1			+1
	npm/​@​playwright/​test@​1.62.0 ⏵ 1.62.1

View full report

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Obfuscated code: npm jsdom is 90.0% likely obfuscated Confidence: 0.90 Location: Package overview From: package-lock.json → npm/jsdom@30.0.1 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/jsdom@30.0.1. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		License policy violation: npm playwright-core under ms-azure-data-studio License: ms-azure-data-studio - The applicable license policy does not permit this license (5) (package/ThirdPartyNotices.txt) From: package-lock.json → npm/@playwright/test@1.62.1 → npm/playwright-core@1.62.1 ℹ Read more on: This package | This alert | What is a license policy violation? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Find a package that does not violate your license policy or adjust your policy to allow this package's license. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/playwright-core@1.62.1. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		License policy violation: npm playwright under ms-azure-data-studio License: ms-azure-data-studio - The applicable license policy does not permit this license (5) (package/ThirdPartyNotices.txt) From: package-lock.json → npm/@playwright/test@1.62.1 → npm/playwright@1.62.1 ℹ Read more on: This package | This alert | What is a license policy violation? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Find a package that does not violate your license policy or adjust your policy to allow this package's license. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/playwright@1.62.1. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Recently published: npm @asamuzakjp/dom-selector published 6 days ago Location: Package overview From: package-lock.json → npm/jsdom@30.0.1 → npm/@asamuzakjp/dom-selector@8.3.2 ℹ Read more on: This package | This alert | What are recently published artifacts? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should either be allowlisted to allow recently-published versions, or an older version should be used instead. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/@asamuzakjp/dom-selector@8.3.2. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

[keiko-for-quality]

Keiko for Quality — run summary

· head f0bd1b2 · 2026-08-08T12:40:29Z · engine v1.8.4 · action 8aafc617614f06d9c90be6fb32fda112ccc1cf78

Metric	Count
Total paths	6
Reviewable	6
Excluded	0
Mechanically clean	0
Critical pointer changes (content not reviewable)	0
Replayed from cache	6
Cache miss (path-set shape changed)	0
Freshly reviewed	0
Findings published	0
Suppressed (intra-run duplicate)	0
Suppressed (exact duplicate)	0
Suppressed (similar)	0
Suppressed (dispositioned)	0
Suppressed (outdated recurrence)	0
Rejected (sanitization)	0
Rejected (placement)	0
Read-back failures	0
API failures	0
Duration (s)	2

Budget: 150000 tokens allotted

Recent runs

• f0bd1b2 · complete · fresh 0 · replayed 6 · 2s
• cb2d918 · complete · fresh 6 · replayed 0 · 9s
• 04aa6aa · complete · fresh 3 · replayed 3 · 8s
• 6fc686a · complete · fresh 5 · replayed 0 · 8s

[oscharko]

Scope adjustment: the vite 8.2.0 (#3015) and @vitejs/plugin-react 6.0.5 (#3016) bumps are reverted out of this collector. vite 8.2.0 raises its lightningcss range to ^1.33.0, and the version bump makes the pre-existing MPL-2.0 license of that transitive package visible to the dependency-review diff gate for the first time (dev already ships lightningcss 1.32.0 under the same license — no new exposure). The gate's allowlist is deliberately permissive-only with per-package copyleft exceptions taken as OWNER decisions (see the LGPL precedent in dependency-review.yml), so admitting MPL-2.0 — even per package — is not a call this collector should make. #3015 and #3016 stay open for that decision; everything else in the collector is license-neutral and proceeds.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[oscharko]

Integrated into dev through the review-complete collector #3037 (squash commit 8df349b) — every finding raised here was carried, repaired failure-first, and re-reviewed there. Closing in favor of the collector.