A dependency-update alert answers one question: is a newer version available?
For patch releases, that may be most of the work. For a breaking SDK or framework release, it is only the first line of the ticket.
The remaining work usually looks like this:
- find the release notes that actually match the target version;
- separate API breaks from unrelated announcements;
- locate the affected call sites and configuration;
- update the package manifest and lockfile together;
- adapt code without drifting into a refactor;
- run the repository's real setup and checks; and
- explain the result well enough for a human to review it.
That is the middle mile PatchFlow is designed to own.
Detection and migration are different products
Detection is mostly a graph problem: inspect manifests, resolve versions, and apply an update policy. Migration is repository-specific engineering under uncertainty.
A useful migration system must carry more context than “upgrade package X.” It needs the exact before and after versions, the evidence class behind the change, the repository's required checks, and a strict edit boundary. It also needs to preserve uncertainty instead of converting every result into a green badge.
PatchFlow records migration evidence as one of three levels:
| Level | Meaning |
|---|---|
| Structured playbook | Known before-and-after patterns for the transition |
| Release notes | Exact upstream release evidence is available |
| Inferred | The agent must reason from the repository and generic version context |
An inferred migration can still be useful. It should simply receive more human scrutiny than a transition backed by a precise playbook.
“Tests passed” needs a subject
CI status is not a free-floating fact. A verdict belongs to a commit.
If a branch moves after tests start, the old result cannot authorize the new head. If a required check never appears, absence cannot mean success. If an agent can edit the workflow that judges its own patch, the check is not an independent boundary.
PatchFlow therefore treats verification as a tuple:
repository + pull request + immutable head SHA + named checks
The system waits for those checks and records the exact commit they evaluated. Missing or failed checks stop the run. Humans retain merge authority.
The product is the review boundary
The interesting promise is not “AI updates dependencies.” Coding agents can already change code.
The product is a controlled path from a postponed upgrade to a draft pull request with enough evidence, scope control, verification, and cost data for an engineer to make a decision.
That framing is narrower than autonomous maintenance. It is also far more useful to a team deciding whether to trust the first migration.