Planning and checks
You say what you want. Tharas writes a specification and a task list, builds each task and checks the work by actually running it — then it goes live. There is no approval step, and work that fails its checks is fixed by the next round, never shipped broken.
Nothing waits for you#
Every checkpoint a build passes through — the specification, the plan, the checks, going live — is decided by Tharas itself. Saying what you want is the whole of your part.
This came out of a real incident. An approval used to be valid forever, so a plan blocked two weeks earlier still counted as consent to spend, and a run burned roughly 1.9M tokens with nobody watching. The fix was not "a human must click": a click from a fortnight ago is worthless. Evidence produced minutes ago, from the exact code about to go live, is not.
The checkpoints, and who decides them#
Every one is decided without you. What you see instead is the work: a card for each task being built, and a line as each one finishes saying what was done and what you can try.
| Checkpoint | What it covers | How it clears |
|---|---|---|
| The specification | What will be built | Decided by Tharas — a service it has no keys for is built against a stand-in, and it says so |
| The plan | How the work is split into tasks | Decided by Tharas |
| The checks | Each task, then the whole app | Automatic — see Verification |
| Going live | Adding the work to your project | Only when nothing failed — never by a setting |
What has to be true before work goes live#
If any of these fails, the work is held back and fixed — never shipped broken.
- QA
- Every task passed its checks on its own changes.
- Tests
- The combined code's own test suite passed, where it has one. A project with no suite is not held back for that, but a suite that runs and fails always is.
- Smoke
- The application actually started, answered its health check and served its pages.
- Clean
- No parts contradicting each other, and no merge conflicts.
Held back is not waiting
Work whose checks fail becomes the next round’s work, and that round fixes it. If it still cannot be finished, it stops with its reason — what is built is kept — and your next message carries on from there. Tharas never keeps retrying the same failure on its own. A design polish that does not pass is simply left out, and your project stays as it was.
There is no setting that ships unverified work
And none that makes a build wait for a person. A second guard re-checks the same rule as the work passes through it, so a bug in one place cannot push what the rule would refuse.
Why there is no approval step#
Being asked to approve an engineering specification you have no way to evaluate is not a safety control; it is a rubber stamp with extra steps — and a build that waits for one waits for as long as you are away.
What makes it safe instead is evidence: work goes live only on checks run minutes earlier against the exact code, and a spending governor stops a run that has stopped making progress.
Common questions
Can I make Tharas ask before every change goes live?
No — nothing waits on you. Tharas checks the work itself: what passes goes live, and what fails is fixed by the next round, or left out so your project stays as it was. There is no setting that ships unverified work either.
What happens if the test suite is missing rather than failing?
Skipped is not failed: a project Tharas generated usually has no suite to run, and holding it back would put a gate back under another name. A suite that runs and fails is never shipped.
How do I change what is being built?
Say so in the conversation. A message sent while a build runs is queued and built next — it is input, not an approval.
Watch it build your own project
Give it a goal and see each task appear, with what you can try as each one finishes.
Download Tharas →