Upstream Sync

Upstream sync

The frameworks this app runs on move independently: eve and its satellites (@agent-browser/eve, @github-tools/eve-extension) from vercel/eve, and @vercel/connect from vercel/vercel. The twice-weekly run checks them, updates the app where warranted, and opens ready PRs only after verification. The PRs are the deliverable; nothing merges without a human.

1. What changed upstream

• Installed versions: apps/evi/package.json.
• Latest published versions: npm view <pkg> version from the sandbox, or the npm registry page, for eve, @agent-browser/eve, @github-tools/eve-extension, @vercel/connect.
• Release notes: GitHub releases on vercel/eve, vercel-labs/agent-browser, vercel-labs/github-tools, and the packages/connect changelog in vercel/vercel. For behavior changes, eve.dev/docs and the installed node_modules/eve/docs.

2. Map onto this repo

• eve APIs: everything under agent/ (channels, connections, extensions, schedules, sandbox.ts). node_modules/eve/docs is the framework reference.
• @vercel/connect/eve: channels/slack.ts, channels/photon.ts, channels/linear.ts, connections/vercel.ts, lib/github/credentials.ts.
• @agent-browser/eve: sandbox.ts, extensions/browser.ts. @github-tools/eve-extension: extensions/github.ts.
• packages/evlog/src/eve: the evlog integration for eve. A change there is user-facing and needs a changeset.
• docs/notes.md: the "eve", "github-tools" and "Vercel Connect" sections record workarounds. A newer version that fixes one means the workaround goes and the note goes with it.

3. Deliver the PRs

• One ready PR per coherent change: a dependency bump with its adaptation, or a workaround replacement. Never bundle unrelated updates.
• Branch off main in /workspace/repo, apply the change, run pnpm run lint, pnpm run typecheck and pnpm run test. Add a changeset when a consumer of evlog would notice the change.
• Push the branch and open a normal PR only when the local readiness gate in contributing is complete. Read CI, fix required failures, then request hugorcd as reviewer. If the change cannot clear the gate, report the blocker instead of opening a draft.

4. Track what needs a human in Linear

A ready PR is its own artifact and needs nothing else. But an upstream finding that could not become a safe PR (a deprecation to plan around, a breaking change to schedule, a new capability worth adopting deliberately) becomes a Linear issue via linear__save_issue on the evlog team: a title stating the situation, the upstream link, what it affects in this repo, and the decision Hugo has to make. One issue per finding; search linear__list_issues first so a recurring finding updates the existing issue instead of duplicating it.

Then post one summary to the thread: one line per ready PR and per Linear issue, links inline.

When nothing is warranted

One line in the thread: versions current, or nothing in the releases affects this app. Never invent work to fill the run, and never open a Linear issue to say nothing happened.