Review dependency updates against your team's rules
The problem and the outcome
A dependency bot opens updates every week. Most change one version number and pass the tests; a few touch a package the team wants a person to look at. Reviewing them all by hand costs the same attention either way. The outcome of this workflow is one written rule that says which updates meet the normal checks, a verdict per update with its reasons, and a person deciding only the rest.
The change under review
#2187: the framework, a patch step
A patch update of Next.js, the web framework. The rule names the framework on the list a person merges, whatever the size of the step, so the verdict is to hand it on. A person merged it the same day.
#2188: three routine packages
A grouped update of three packages, minor and patch steps, in the shape the rule allows. Before anything merged it, main moved on and the bot replaced it with a fresh pull request of the same updates, which a person merged that evening.
Test and policy evidence
- Who opened itOnly the dependency bot, and every commit the bot’s own, signed by the platform. A commit a person pushed makes it a person’s change.
- What it touchesOnly package manifests and lockfiles. A workflow file or any other file is code, and goes to a person.
- How far it movesEach version a patch or minor step of a released version. A major version is a planned upgrade with its own issue.
- The held listPayments, the framework, the database and sign-in clients, and one pinned driver are never merged without a person.
- The testsEvery workflow run on the update’s commit finished and passed, the required one among them.
When the agent may merge, and when a person decides
| Verdict | What it means | Who acts |
|---|---|---|
| Merge | Every check holds. Maplith may merge it after checking every condition again on the live pull request and waiting for the tests. | Maplith, under the written rule, on its own repository. |
| Hand on | Any check fails, with the reasons listed. A work item asks for the changelog to be read and the touched flow tested. | A code agent prepares; a person merges a held package or a workflow change. |
| Major version | A planned upgrade, never a weekly bump. | The founder, with its own issue. |
The recorded outcome
Each update is one signal in Maplith with the files it touches, each version it moves, the test state and the verdict with its reasons. A merge Maplith carries out is recorded as an action with the request, the commit it checked and the result; a hand-on is recorded as a work item with the reasons. The signal clears itself when the pull request is merged or closed.
Who does what
What Maplith supplies
The signal per update with its facts and verdict, the rule as the team wrote it, the merge of an update that passes, and the record.
What the agent does
Reads each signal in its daily passes, asks Maplith to merge the ones that pass, and opens a work item with the reasons for the rest.
Where a person decides
A held package, a workflow change, a major version, or a failing test. The person reads the changelog and merges, or closes it.
Prerequisites
| Part | Why |
|---|---|
| A repository with a dependency bot and tests that gate the main branch | The rule reads the bot’s commits and the test results; without them there is nothing to check. |
| A written rule: the held list, the allowed step sizes, the files allowed | The rule is what makes the verdict explainable and the same for every update. |
| An agent that reads the signals and asks for the merge | The verdict is a fact; acting on it is a request Maplith carries out or refuses. |
Questions people ask
Can I use this on my repository today?
The rule and the merge run on Maplith's own repository. Connecting your repository gives you the hosted GitHub integration, which comments and proposes and does not merge. Ask us if you want the merge path.
Who wrote the rule?
The founder, in a reviewed pull request. The held list is shortened or lengthened the same way.
What if the tests are still running?
An update that passes everything else keeps its verdict, and Maplith waits for the tests before it merges, for a bounded time. If they fail, the update is handed on.
Read the internal workflow
The guide walks through the two updates of 2 November 2026 with the rule's verdict, the checks and who merged what.