[robertjamesprior]

summary

Upgrade @onkernel/eve-extension for eve 1.0 compatibility per Shar's note in vercel-kernel and guide provided

changes

• update eve from 0.25.1 to 1.0.0-rc.5
• update @vercel/connect from 0.4.0 to 2.7.0
• upgrade direct zod dependency from 4.4.3 to 4.6.7
• raise the eve peer dependency floor to >=1.0.0-rc.5
• bump the extension package to 0.2.0

current validation

Validated against eve@1.0.0-rc.5:

• npm ci succeeds
• npm run typecheck passes
• npm run build passes
• the build emits the eve extension compatibility manifest
• CI passes
• npm audit --omit=dev --audit-level=high reports no vulnerabilities

The extension contains no eve event handlers, agent declarations, or stateful migration code, so no source-level API migration was identified.

GA verification still required

This PR is verified against the latest eve release candidate, not a stable eve@1.0.0 release. Before calling the extension GA-ready:

1. update the eve dev dependency and lockfile to the stable 1.0.0 release when published
2. rerun install, typecheck, build, and CI against stable eve
3. run a consumer smoke test that installs the packed extension, mounts it in an eve 1.0 agent, discovers the Kernel MCP connection, and exercises one representative tool
4. publish 0.2.0 only after those checks pass

Until then, this should be described as eve 1.0 RC compatibility rather than GA verification.

---

Note

Medium Risk
Major peer and Connect dependency upgrades break consumers still on eve 0.x until they upgrade, though the extension itself has no API migration in source.

Overview
This release aligns @onkernel/eve-extension with eve 1.0 by raising the eve peer and dev dependency floor from >=0.25 to >=1.0.0-rc.5, bumping the package to 0.2.0, and refreshing direct deps (@vercel/connect ^2.7.0, zod 4.6.7). The Node engines field is relaxed from 24.x to >=24.

Docs and release automation match the new baseline: README prerequisites and the release workflow ESM smoke test install eve@^1.0.0-rc.5 alongside the packed tarball. The lockfile reflects the eve 1.x toolchain (nitro, rolldown, etc.); no extension source files change in this PR.

^{Reviewed by Cursor Bugbot for commit 41c374c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 5168bcc. Configure here.}

[masnwilliams]

LGTM. The release smoke test fix in 41c374c resolves the peer conflict. I reran the pack → install eve@^1.0.0-rc.5 → import steps locally against the 0.2.0 tarball, and they pass.

Optional follow-ups, none blocking:

• Pin eve exactly and use a wildcard peer. eve 1.0 checks compatibility against builtWithEve in dist/extension/_manifest.json, not against the peer range. Its docs and eve extension init scaffold recommend devDependencies.eve pinned exactly and peerDependencies.eve: "*". Today the eve version is repeated across the devDep, the peer, the README, AGENTS.md and release.yml. With an exact pin, the smoke test could read the version from package.json and assert it matches builtWithEve. Worth doing before the next eve bump.
• Refresh AGENTS.md for 1.0. It still says the peer is floored at >=0.25, points to docs/extensions.md (now docs/extensions/index.md), and lists schedules as disallowed. The 1.0 scaffold's AGENTS.md is a good starting point.
• After 0.2.0 publishes, consider npm deprecate @onkernel/eve-extension@"<0.2.0". The >=0.25 peer on 0.1.x lets eve 1.0 consumers install it, but eve 1.0 rejects its formatVersion: 1 manifest.