Upgrade Steward build log

Dependency bots are good at noticing a new version. They are less good at proving that the upgrade is safe. The reviewer still has to find the right changelog, identify removed APIs, inspect migrations, and decide whether a green check actually exercised the risky path.

Upgrade Steward is an open-source eve agent that owns that proof loop for JavaScript and TypeScript repositories. It researches one exact dependency transition, applies the bump and required source migrations in an isolated sandbox, runs a frozen install plus build and tests, and opens a GitHub pull request only after a human approves the evidence bundle.

One upgrade, end to end

The workflow begins with a repository and an exact package@old to package@new transition. A dedicated researcher subagent is restricted to primary changelogs, release notes, and migration guides. Its citations and breaking-change findings are persisted in durable session state rather than disappearing into one model turn.

The root agent then edits a session-persistent sandbox. Verification is independent of the model: a typed tool reruns the frozen install, build, tests, optional project checks, and Git diff inspection. It records sources, migrations, commands, changed files, diff statistics, risk, base revision, and the exact staged Git tree in one digest.

The approval is bound to the proof

open_upgrade_pull_request is the only external-write tool and always requires eve approval. The approval card shows the exact evidence digest and staged tree object ID. After approval, the tool rechecks that tree, validates every in-memory publication buffer against its staged blob ID, freezes those validated bytes, and rechecks the base SHA before its first GitHub write. If the tree, same-path content, or base revision changed while approval was pending, publication fails closed and the upgrade must be verified again.

That boundary matters more than another version-discovery algorithm: the model can research and prepare, but it cannot silently publish, and an old approval cannot authorize new bytes.

A deliberately breaking eval

The core eval upgrades a fixture from Zod 3.25.76 to 4.4.3. The fixture uses the removed ZodError.errors API, so changing only package.json cannot pass. The run must delegate release research, cite the official Zod migration guide, rewrite .errors to .issues, complete install/build/tests in Vercel Sandbox, produce the evidence card, and remain unable to publish when approval is denied. Separate evals cover durable state recovery and the weekly schedule, while deterministic CI regressions reject staged-tree and same-path content tampering.

Recurring without unattended writes

A single Monday 06:00 UTC schedule can prepare one upgrade proposal for a configured repository. It stops after verification and never attempts to bypass interactive approval. The source keeps an explicit cost warning because scheduled model and sandbox work runs on the deployer's Vercel account.

The public deployment is intentionally fail-closed: its landing page and /eve/v1/health are available, while unauthenticated agent sessions are rejected so visitors cannot spend the deployment's gateway budget. Forks deploy to the adopter's own Vercel account and connect their own repository-scoped GitHub credential.

Release evidence

• Repository: dvnc-labs/upgrade-steward
• Release: v0.1.1
• CI: green release run
• Deployment: upgrade-steward.vercel.app

Upgrade Steward complements Dependabot and Renovate rather than replacing their discovery engines: it is the evidence-gated migration and publication layer for the changes that deserve deeper review.