Features / Capture & fix
A change your engineer approves, or doesn't
Tore keeps one registry of risk classes, authentication, billing, migrations, tenant isolation and secrets, and those are locked. A change that touches a locked class is clamped to human review, whatever any other setting says.
Risk-class registry
Locked classes can never be loosened in any domain.
What the AI may do · Code
Without it
The dangerous bugs stop you automating the boring ones
You would happily let something fix a null check in a list view. But the same switch also governs the billing code and the migration folder, so the switch stays off and you keep hand-fixing null checks.
Nobody can tell you what the AI is currently allowed to do
Someone loosened a setting for one repository during a bad week in March. It is still loose. There are four screens where autonomy can be set and no single screen that answers the question.
Approving means reading a diff with no context
A pull request appears. You do not know what it was trying to fix, what it checked, or whether anything ran. Reviewing it properly costs more than writing it would have, so it sits for three days.
How it works
One registry says what counts as dangerous
Authentication and access, billing and payments, database migrations, personal data, tenant isolation, secrets. These are locked, and you can add your own classes for anything else you consider load bearing, like a new payments module.
Ceilings are set per domain, and may only get tighter
Four rungs: automatic, confidence-gated, approval required, human review. You set them separately for conversations, for code, and for workflows. A domain can make a class more restrictive than the registry. It can never make it less.
The number that matters
4rungs
Fixed by the product, not by whoever is on shift.
The clamp applies when the value is read, not when saved
A locked class resolves to human review at the moment of the decision, even if some older setting stored something looser. Tighten the registry and every domain tightens with it, so a stale permissive setting cannot leak through.
The case is assembled before it reaches you
The one file it touches, the diff, the checks that ran, the reproduction, the confidence, and why it believes this is the cause. Who may approve, how many approvals are needed, and the minimum confidence are all set per policy.
What that includes
Hard caps sit above all of it
Actions per hour, pull requests per day, a refund ceiling above which a human always signs. These apply regardless of risk class, so a rule written badly at 2am cannot run all night.
What it means for you
The dull work can move without betting the database on it
You can be genuinely permissive about a typo in a template and genuinely paranoid about a schema change, at the same time, and not have to hold both in your head.
There is one honest answer to “what is it allowed to do?”
One page, one registry, and every other screen reads from it. When your auditor, your co-founder, or your own memory asks the question, the answer is not an archaeology project.
Reviewing is quick because the argument is already made
You are not reconstructing intent from a diff. You are agreeing or disagreeing with a case that shows its work, which is a decision you can make between two meetings.
The honest limit: Opening the pull request on your repository is not switched on yet. The change is prepared, checked, and held at the approval gate, and the code that would publish a branch and open the PR exists but nothing calls it. Today your engineer takes the approved change and applies it.