chore(deps): replace semver with verkit - #76

Reviewed changes — the complete semver → [email protected] swap across all 5 files, plus a call-site-by-call-site behavioural comparison against [email protected].

• package.json / pnpm-lock.yaml — drops semver and @types/semver, adds verkit pinned at exactly 0.4.0.
• utils/version.ts — semver.valid(v) !== null → isValid(v) in the pinned-devDependency guard.
• utils/packageManager.ts — the same isValid swap behind the concrete flag for both the packageManager and devEngines specs, and semver.satisfies → satisfies in the precedence resolution.
• utils/versioning.ts — semver.parse → tryParse, semver.satisfies → satisfies, and a new local minVersion helper wrapping findMinimumForRange + normalize to stand in for semver.minVersion.

Verification I ran locally, so it doesn't need repeating:

• Behavioural parity — compared verkit against [email protected] across every input shape these call sites can receive: 14 version strings for isValid (including v1.2.3, whitespace-padded, 1.2, 1.2.3+build, workspace:*, catalog:), 9 version/range pairs for satisfies (including prerelease exclusion and x-ranges like ^0.1.x), and 7 ranges for minVersion. Identical results on all of them. Notably verkit's satisfies also swallows malformed ranges and returns false rather than throwing, matching semver — that one matters, since devEngines.packageManager.version in utils/packageManager.ts:130 is arbitrary text from a user's package.json.
• Tests — 739 unit tests pass, including all 15 in utils/versioning.test.ts. (test/ci.test.ts fails in my sandbox for an unrelated directory-layout reason.)
• Packaging — pnpm install --frozen-lockfile succeeds under the pinned [email protected], and node esbuild.config.js inlines verkit into dist/ with no dangling external import. Since package.json has no dependencies and ships only dist/, a pure-ESM dependency was the thing most likely to break here, and it doesn't.

ℹ️ verkit is pre-1.0 on the path that gates every incoming payload

Not a defect, just a call only the maintainer can make. validateCompatibility is invoked on every payload the action processes (utils/payload.ts:143), and resolvePackageManagerSpec decides what gets pinned via corepack — so this swaps the reference SemVer implementation for a 0.x, single-maintainer package on load-bearing paths. Under SemVer a 0.x minor bump may carry breaking changes; the exact 0.4.0 pin contains that (and matches how agent-browser, opencode-ai, and skills are already pinned here), at the cost of not picking up patch fixes automatically.

# Pre-1.0 dependency on payload-compatibility path

## Affected sites
- `package.json:64` — `"verkit": "0.4.0"`, a pre-1.0 release
- `utils/versioning.ts:1` — imported by `validateCompatibility`, reached from `utils/payload.ts:143` for every payload
- `utils/packageManager.ts:4` — imported by `resolvePackageManagerSpec`, which drives corepack pinning

## Open questions for the human
- Is a `0.x` dependency acceptable on these paths, or should this wait for `verkit` 1.0?
- If it lands: is the exact pin the intended policy (no automatic patch uptake), and who owns bumping it?
- `utils/packageManager.ts` and `utils/version.ts` have no unit tests covering the `concrete` flag or the pinned-version guard. Parity is verified for this swap, but nothing in the repo would catch a regression on a future `verkit` bump.

ℹ️ Nitpicks

• pnpm-lock.yaml carries churn unrelated to the dependency swap: peer deps re-bucketed under optionalDependencies (ajv-formats, fdir, follow-redirects, xsschema, vitest), vite's peer hash gaining ([email protected]), and zod: {} / vite: {} dropping out of peerDependenciesMeta. I confirmed --frozen-lockfile still installs cleanly under the pinned [email protected], so this is benign — but it inflates the diff and will conflict with any other in-flight dependency PR. Regenerating the lockfile with only the semver/verkit delta would keep it reviewable.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus (free via Pullfrog for OSS) ｜ 𝕏}

ℹ️ Blocking typecheck failure is fixed. One leftover one-character nit inline.

Reviewed changes — only the delta since my previous review at a8ecc31, which is a single one-line change in 6236d93 Update versioning.ts.

• utils/versioning.ts:20 — adds the outer non-null assertion to minVersion, so normalize's string | null return no longer conflicts with the declared string return type.

Re-verified against the new head: pnpm typecheck passes clean (it failed on the previous head), and utils/versioning.test.ts still passes all 15 cases. My earlier thread on this is resolved.

The pre-1.0 dependency question I raised in the previous review is unchanged and still a maintainer call — nothing in this commit affects it.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus (free via Pullfrog for OSS) ｜ 𝕏}