When Your App's Build Breaks, VrittOS Now Notices First

There is a particular kind of stuck that only happens once your app is real. Everything has been going well — stories merging, features landing — and then one change breaks the build on your main branch. From that moment, every new piece of work would be built on top of something broken.

The old answer to this was honest but useless: VrittOS paused new work and showed you a link to a failing checks page. If you are a developer, that link is where you start. If you are not, it is a wall of red text in a tool you did not ask to learn, telling you something is wrong in a language that assumes you already know how to fix it.

That gap is now closed. When your app's build breaks, VrittOS notices on its own, works out what went wrong, and gives you the choice in plain language.

What happens now

1. We notice without being asked. Checking used to happen only at the moment you tried to start something new. Now the platform watches your app's main branch in the background, so a break is found whether or not you are at your desk — and recovery starts before you next open the project.
2. New work pauses, deliberately. Nothing new starts while the foundation is broken. This is a feature, not a failure: the alternative is five more stories built on top of a fault, each one making the eventual repair harder.
3. The AI reads the actual failure. Not the summary — the build logs, the workflow configuration, the change that most likely caused it. This is the same triage that already handles failing checks on individual pull requests, now pointed at your main branch.
4. You get options, not diagnostics. The result is a small set of choices written for you, each one saying what it would do and what it would cost. Pick one and the fix goes onto its own branch, opens a pull request, and merges when the checks pass.
5. Your project tells you, at the top. A banner on the workspace says your app's build is broken and that new stories are paused — and then points at exactly where your options are. While the analysis runs it shows a live timer rather than a frozen spinner, because a screen that never changes reads as abandoned.

The rules that don't bend

Repair touches your code, so the same constraints apply that govern everything else the platform does:

• Nothing is pushed to your main branch directly. Ever. A fix is a branch and a pull request, reviewed by the same checks as any other change. The repair path is not a back door around your own gates.
• Nothing is deleted to make a problem go away. A build that fails because a test fails is a build telling you something true. The options you are offered fix causes; they do not quietly remove the test that noticed.
• You decide. The AI recommends, and says why. On projects running in autonomous mode it will act on its own recommendation to keep the backlog moving — but that is a mode you turn on deliberately, not the default.

Why "we noticed" matters more than it sounds

Most of the value here is not the fixing. It is the noticing.

A build can break at 2am on a Saturday. Before this, the platform would wait — politely, invisibly — until the next time you clicked something, and only then tell you that your project had been stalled for two days. Every hour in that gap was an hour a founder spent believing work was happening when nothing was.

Detection now runs on its own schedule. The analysis starts, the options get prepared, and by the time you look, the question waiting for you is "which of these three fixes do you want" rather than "why has nothing moved since Friday".

Where this fits

Broken builds are one instance of a broader pattern we keep returning to: the platform should be the one to notice. The same idea already shows up elsewhere.

• A pull request whose checks go red gets triaged the same way, with the same kind of options.
• A run that stalls gets one free automatic restart; if it stalls again, you get choices instead of another silent retry.
• A deploy that fails verification comes with a Fix it for me button that investigates the root cause and opens a pull request.

None of these are the same feature. They are the same principle applied in different places: a founder should never have to detect a problem before the platform does.

What this doesn't do

It is worth being straight about the edges.

Not every broken build has a safe automatic fix. Some failures are genuinely ambiguous — two reasonable repairs with different trade-offs — and some need a decision only you can make about what the product should do. In those cases you get the honest version: what went wrong, in plain language, and the option to hand it to our team rather than a suggestion the AI is not confident about.

The goal was never a platform that claims nothing ever breaks. It is a platform that tells you when something has, in words you can act on, before you have to go looking.