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> versionfrom the sandbox, or the npm registry page, foreve,@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 thepackages/connectchangelog invercel/vercel. For behavior changes,eve.dev/docsand the installednode_modules/eve/docs.
2. Map onto this repo
- eve APIs: everything under
agent/(channels, connections, extensions, schedules, sandbox.ts).node_modules/eve/docsis 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
mainin/workspace/repo, apply the change, runpnpm run lint,pnpm run typecheckandpnpm 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
contributingis complete. Read CI, fix required failures, then requesthugorcdas 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.