-
-
A real repair asked for S; MINOR estimated L across four areas. Monitoring had no changed file and still had to accept.
-
Promise: at most 1% server errors for 3 h. It broke: real incident #21, rollback. The fix held: 9 of 9 readings, closed.
-
“It's just a faucet” becomes a wall and a neighbor. Google's SRE book: roughly 70% of its outages come from changes.
-
One real change through all nine GitLab stages, from plan to govern, each with its public evidence and its limit.
-
MINOR (Not Minor): the true size of “just a tweak”. Know a change's real size before anyone says yes, then watch its promise.
-
Same engine, live on Google Cloud Run, on a synthetic HR example: moving a start date after the offer. Asked S, estimated L.
-
The rules are data: areas, owners and checks live in notminor.yml on main. A new rule is a commit, not a new build.
Inspiration
"It's just a faucet. Five minutes." Every plumber has heard it. Then the job turns into shutting off the building's water, opening a wall and warning the neighbor downstairs.
Software works the same way. Google's SRE book reports that roughly 70 % of its outages come from changes to a live system. Now AI agents open merge requests all day, and every one of them says it is small. "Small" is a word, not evidence.
We built MINOR (Not Minor) to give every change the plumber's honest answer, before anyone says yes.
What it does
MINOR gives a change its real size before anyone says yes, then watches the release against its written promise. For every merge request it shows:
- Its real size, next to the size the requester perceived.
- Who it touches, including areas where no file changed: the neighbor downstairs.
- Which rules apply: pass, fail or unknown. Unknown is never treated as approval.
- Who has to decide, bound to that exact evaluation. Every affected area accepts, one by one.
- What was promised and what happened next: release, observation, closure or rollback.
It works at GitLab's Assisted level. Agents propose and explain; a person says yes before anything ships. Our custom GitLab Duo agent, the MINOR Change Explainer, published in the AI Catalog, turns the engine's report into plain words for the person who decides. The rules are data in the repository, so a new rule is a commit, not a new build. A new kind of operation is a new configuration, not new software.
One real change, nine stages
Our strongest use case is an AI software factory. Agents write the code and MINOR is the gate before the release. Our earlier agent factory built a small reservation service and wrote a repair for two of its bugs. We replayed that repair here as two merge requests and let MINOR handle it from plan to govern. Everything MINOR did is real and on the public record.
- Plan. "Five minutes." The request called it a focal repair, size S. MINOR writes that down before measuring anything.
- Create. The GitLab Duo agent explained the evaluation in plain words and left the decision to a person.
- Verify. Bigger than it looked. MINOR estimated L, two sizes bigger, across four areas. One of them, monitoring, had no changed file and still had to accept.
- Package. The repair was built into an image identified by its digest, and that identity travels with the change.
- Secure. SAST and secret detection ran on each merge commit, and every finding got a recorded decision.
- Release. Keep the old faucet at hand. Released to Google Cloud Run with a written promise: server errors at most 1 % for three hours. When the promise broke, the owner authorized a rollback and traffic went back to the previous version.
- Configure. Check the pipes against the drawing. The live service is compared with its declaration in the repository. After the rollback, the drift report named the change.
- Monitor. Does it leak? For the first repair, yes. The monitor's test request got server errors, and about three minutes after the first failure it opened incident #21, a real regression and not a drill. MINOR reopened the change. A second merge request fixed what the first one broke: nine readings out of nine passed, the promise held and the change was closed.
- Govern. The neighbor downstairs signs too. The owner decided and accepted each area in a note bound to that exact evaluation, monitoring included. MINOR opened a task for that area and closed it when the acceptance existed. The change passport stamps all nine stages for both merge requests.
Watch it in 2:47: the demo video.
How we built it
- GitLab CI runs a trusted evaluator in a fixed container image. It reads each merge request as data and never runs the candidate's code. Reports are published as pipeline artifacts, and change cards are readable without signing in.
- GitLab objects do the work:
- notes on the merge request carry decisions, which CI binds to the evaluation;
- CI opens issues for unknown rules and for areas that must accept;
- incidents open and close from the monitor;
- GitLab Releases carry a receipt for each change;
- scheduled pipelines are the observation windows.
- GitLab Duo:
- a custom agent in the AI Catalog explains each evaluation;
- Duo Code Review reviewed four of our merge requests;
- Duo Agent Platform's Developer Flow ran three recorded sessions on an earlier case.
- Google Cloud:
- MINOR's evaluator and the repaired service run on Cloud Run;
- CI deploys and rolls back through Workload Identity Federation, with no stored keys;
- the monitor reads Cloud Monitoring and Cloud Logging against objectives kept as data.
Challenges
Keeping every claim tied to a public record, including our own failures. Failed pipelines, a deploy job marked failed and direct commits to main are listed, not hidden. Where the Developer role could not use GitLab's own compliance tools, we built public substitutes and say they are substitutes.
Accomplishments
- A real agent-made merge request of 60 files that its requester called M was measured L across three areas, and the owner's decision was recorded by the engine.
- One change through all nine stages, including a real regression caught by our own monitor, a rollback, and a repair whose promise held.
- MINOR's own evaluator was deployed, rolled back and redeployed on Cloud Run from GitLab CI, passing 17 of 17 post-deploy checks.
- A drill, an intentional fault behind a feature flag and labelled as one, ran the incident loop end to end.
- The same engine evaluates a synthetic HR example, an invented company, live on Cloud Run: moving a start date after the offer is asked for as small and estimated as large.
What we learned
A passing stage proves something ran, not that it was right. The first repair passed every pipeline gate, and the regression was found after the deploy, by the monitor's probe. That is why MINOR keeps watching after the yes.
What's next
- Sign the decision records and authenticate the person who decides.
- Tie each passport stamp to its own release.
- Let teams bring their own operations as configurations.
What we do not claim
- Sizes are MINOR's estimates, not measurements.
- Decisions are local attestations from the owner's GitLab account, not signatures, and one person accepted all areas.
- The repair code was written by our earlier factory, not by an agent of this project.
- The monitor's probe already carried the failing request before the deploy, so the defect was expected.
- No clean-scan claim and no third-party adoption.
- Service, commerce and HR examples are synthetic.
The full list is in the README.
Links
- Video (2:47): https://youtu.be/CHcT3uHrDA8
- Repository (MIT): https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/43264264/showcase
- One change, nine stages, with every link and limit: README · docs/stages.md
- Change cards: readable without signing in
- Live evaluator on Google Cloud Run: /health · synthetic HR example
- GitLab Duo agent, MINOR Change Explainer: AI Catalog
Log in or sign up for Devpost to join the conversation.