Planning and approval
You give Tharas an objective. It comes back with a specification, a task graph and an honest statement of what it cannot do — and then it holds gates on the way out, so nothing reaches your remote that has not been proven minutes earlier.
Consent has to be tied to evidence that is current#
The governing rule came out of a real incident. An approval used to be per-gate and valid forever, so a plan blocked two weeks earlier still counted as consent to spend. A run woke on its own and burned roughly 1.9M tokens with nobody watching.
The obvious conclusion was "a human must click". That was the wrong conclusion. A click from a fortnight ago is worthless. A green test suite and a running application, produced from the exact tree about to be pushed, minutes ago, is not.
So Tharas does not ask you to re-approve things it can prove. It asks about the things it genuinely cannot.
The four gates#
Running a goal is standing approval for Gates 1 and 2 for that one bounded run — everything they guard is local and reversible. Gate 3 is the only outward action in the system and is never auto-approved by a setting.
| Gate | What it guards | How it clears |
|---|---|---|
| Gate 0 | The specification | Auto-approved unless the risk is high or it needs something only you have |
| Gate 1 | The plan and its tasks | Standing approval for the run |
| Gate 2 | Consolidated QA | Standing approval for the run |
| Gate 3 | Opening the pull request | Evidence only — never a configuration flag |
What Gate 3 requires before it opens a PR#
All five, or the work stays local and you get told which one is missing.
- QA
- Every task passed the QA gate on its own diff.
- Forge
- The merged tree's own test suite ran and passed. Ran, not skipped — no test suite found is not evidence of anything.
- Smoke
- The application actually started, answered its health check and served its declared routes.
- Clean
- No contract defects and no merge conflicts.
- Reachable
- The repository has a remote and the GitHub CLI is signed in.
There is no setting that ships unverified work
The opt-in review setting can only make the bar stricter, never looser. A second guard re-checks the same rule as the run passes through it, so a bug in a caller cannot push what the rule would refuse. Asking twice is proportionate for the one action that leaves your machine.
Why the specification is approved by default#
It used to require an explicit opt-in per goal, which meant the normal experience was being asked to read and sign off an engineering specification you had no way to evaluate. That is not a safety control; it is a rubber stamp with extra steps.
Two hard limits did not change, and they are what make the inversion safe: never on high risk, whatever any setting says, and never when the spec needs something only you have — a credential, repository access, a failing environment check. Approving a build that preflight will immediately fail just burns budget.
Common questions
Can I make Tharas ask before every ship?
Yes. The review-before-ship setting makes Gate 3 require you explicitly. It can only tighten the gate — there is no corresponding setting that loosens it.
What happens if the test suite is missing rather than failing?
Gate 3 treats it as unproven and does not open the pull request. A repository with no suite is exactly the one a human should look at.
See the gates on your own repository
Install Tharas, point it at a repo and give it a goal. The plan comes back before anything is built.
Download Tharas →