[spencerbeggs]

Dependency Updates

effected

Dependency	Type	Action	From	To
@okfit/plugin	devDependency	updated	^0.5.21	^0.5.22
@vitest-agent/plugin	devDependency	updated	^5.4.7	^5.4.8

Peer Dependencies

Package	Importer	Wanted	Found	Wanted by	Required
@effected/config-file	.	^0.17.0	0.18.0	@savvy-web/silk@4.3.13 -> @savvy-web/cli@3.7.10 -> @effected/cli@0.19.0	no

---

This PR was automatically created by silk-update-action

chore(deps): update devDependencies in effected

Signed-off-by: spencerbeggs[bot] <251231653+spencerbeggs[bot]@users.noreply.github.com>

[pullfrog]

✅ No new issues found.

Reviewed changes

I reviewed the two root devDependencies bumps and the lock they regenerate. Each bumped tool is a republish whose only real change is repinning this repo's own @effected/* packages.

• @vitest-agent/plugin 5.4.7 → 5.4.8: the code diff is bundler //#region comment churn, and index.d.ts has no non-comment change. Its package.json repins @effected/cli ^0.20, env ^0.5, glob ^0.14, walker ^0.19 and workspaces ^0.36.1, plus the exact-pinned sibling family. pnpm vitest run --project @effected/semver boots the new plugin cleanly: 252/252 tests pass.
• @okfit/plugin 0.5.21 → 0.5.22: @okfit/profiles 0.10.4 → 0.10.5 changes SoftwareProject.js only by region comments, so the okf/ types, tags and routes are unchanged. Both okfit sync lines in .husky/pre-commit exit 0 (I ran them with --dry-run). okfit validate --ci exits 0 on both the old and the new CLI, with the same 25 source-resource-missing warnings.
• Lock convergence (not listed in the PR body): the stale registry copies @effected/config-file@0.17.0, store@0.16.0, xdg@0.12.0 and app@0.24.0 are gone. Every surviving copy matches the workspace's released .version, and effect stays at a single 4.0.6. The frozen install passes the supply-chain policy, and pnpm catalog:check reports the catalogs in sync.
• The peer row in the PR body: the root importer's @effected/cli@0.19.0 → @effected/config-file ^0.17.0 warning is new here only because the 0.17 copy was removed. The peer is optional (peerDependenciesMeta), and cli's shipped ESM mentions it only in doc comments, so nothing breaks.

I can't read check runs from here, so I judged this PR on the diff and the local checks above.

ℹ️ The committed plugin builds were already stale on main

pluginfinity build --check fails with BuildStale on this branch. The cause is not this PR: origin/main's lock already resolves @pluginfinity/engine@0.3.4, while the four committed host.sh files still say PLUGINFINITY_LIB_VERSION=0.3.3, and this diff moves no @pluginfinity/engine version. If release.yml's plugin:check goes red here, it was red on main too. Fixing it belongs in a separate rebuild commit.

Technical details

# Stale committed pluginfinity builds on main

## Affected sites
- plugin/builds/claude/lib/pluginfinity/host.sh — PLUGINFINITY_LIB_VERSION=0.3.3, installed engine is 0.3.4
- plugin/builds/claude/hooks/lib/pluginfinity/host.sh — same
- plugin/builds/copilot/lib/pluginfinity/host.sh — same
- plugin/builds/copilot/hooks/lib/pluginfinity/host.sh — same

## Required outcome
- `cd plugin && pnpm exec pluginfinity build --check` reports `ok: true` on main.

## Suggested approach
- `pnpm build --filter @effected/ai-plugin` and commit the regenerated builds in their own PR, not this bot PR.

  ^{｜ View workflow run ｜ Using claude-opus-5-5 ｜ 𝕏}