Remediation

Everything up to now has been reading. Remediation is the first step that changes anything, and it is the one with no right answer for everyone. We define how far an agent should take the remediation for each project based on several factors, including client preferences and our own risk tolerance on a given project.

Three levels

1. Investigate only. The investigator finds the cause, writes a failing test that shows it, and proposes a fix in a comment on the issue. A person decides whether to make the change. Nothing leaves the investigator's worktree.

2. Draft pull request. The investigator makes the fix on its branch, gets the failing test passing, runs the project's full checks, and opens a draft pull request linked to the issue. A person reviews and merges it.

3. Merge on green. The same as a draft pull request, except the investigator marks it ready and merges it once CI passes. A person finds out from the pull request, not before it.

What decides it

Is a person still reading all of the code? If someone on the team reads every change that ships, a draft pull request costs them very little and catches the fix that is technically right and wrong for the codebase. If nobody reads every line any more, and on a lot of agent-built projects nobody does, then a draft just sits there. Be honest about which kind of project this is. Merge-on-green with strong checks can be safer than a review queue nobody gets to.

What happens if the fix is wrong? A marketing site that shows a stale price for an hour is not a billing system that charges someone twice. Think about the worst plausible bad fix: does it lose data, leak data, take money, lock people out?

How much would the checks catch? Merge-on-green is exactly as good as the gate it merges through. A project with a thorough test suite, static analysis and a required review agent can trust a green build much more than one with a few smoke tests.

How easy is it to undo? A change you can roll back with one revert and one deploy is a different risk from a migration that rewrites a table. Many teams allow merge-on-green for code changes and require a person for anything that touches the schema, the infrastructure or a dependency.

Who is affected? A change that breaks an internal tool is very different to a change that breaks a big customer-facing app with lots of paying users.

You can also mix levels inside one project. "Merge on green for performance fixes with a regression test; draft for anything else; never touch app/Billing" is a perfectly good rule.

Write it down where agents look

Rules only work if every investigator reads the same ones. Put them in a file at the root of each repository, which the investigator brief on the previous page points to:

# REMEDIATION.md

Level: draft-pr

- Always start with a failing test that reproduces the problem.
- Run `composer ready` before opening the pull request. Do not open it
  if anything fails.
- Performance fixes that only add an eager load, an index or a cache
  may be merged when CI is green.
- Never change files under app/Billing, database/migrations or
  config/, and never add or upgrade a dependency. Stop and comment on
  the issue instead.
- Link the pull request to the issue with "Fixes #N".

Because the file lives in the repository, it changes through review like anything else, and the history shows when you decided to trust the loop with more.

What the agent can never do

Whatever level you choose, some things are not up to the investigator:

• The Scalpels token stays read-only. No level of remediation needs the agent to change Hone, Reel or Wake. A read token cannot delete logs or rotate credentials, even if something in a log line asks it to.
• Fixes go through the repository. No investigator deploys directly. If a change cannot go through your normal branch, checks and deploy, it is not a change the loop should make.
• People can always see what happened. Every finding has an issue, every investigation has a todo, and every fix has a pull request. If the loop ever does something you cannot trace back through those three, turn off the cron job and find out why.

That last rule is the one that makes the rest safe to try. The loop is not asking you to trust an agent's judgment blindly. It is asking you to let it work in the open, and to give it more room only once you have watched it work.