> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tasksmind.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The Approval & Safety Gate

> What has to be true before tasksmind can touch your repo: risk classification, sandbox test verification, and a human-only approval that only a signed-in person can give.

What has to be true before a fix reaches you, and what has to be true before it can ship after you
approve it.

## Before a human ever sees an approve button

<Steps>
  <Step title="Risk classification">
    Every proposed fix is scored for risk before the pipeline continues. This is a hard gate, not
    a formality: if the risk score can't be recorded, the fix generation aborts rather than
    continuing with an unclassified fix.
  </Step>

  <Step title="Sandbox test run">
    Your test suite runs in an isolated sandbox before you're ever asked to approve, unless a
    project has explicitly turned that off. A project can also override exactly which commands
    run in the sandbox.
  </Step>
</Steps>

## The approval card

Before tasksmind commits code or opens a PR, it posts an approval card in the thread with four
buttons:

| Button              | What it does                                                       |
| ------------------- | ------------------------------------------------------------------ |
| **Approve**         | Proceed: tasksmind commits and opens the PR for your team to merge |
| **Request Changes** | Reject with feedback; the job stops                                |
| **Stop**            | Cancel the job immediately                                         |
| **Escalate**        | Mark for human review; job is paused                               |

## Who can approve

Only a signed-in person can approve a fix, using their own dashboard or Slack identity. An API key
can trigger a run or read its status, but it can't sign off on one. Approval always resolves to a
real person, and every approval records who gave it.

## What approving actually does

Approving opens the pull request for your team. One of your engineers reviews it and merges it.
tasksmind never merges on its own. What the two gates above change is how that review goes:

<CardGroup cols={2}>
  <Card title="Low or medium risk, tests passed" icon="circle-check">
    The PR is marked clean, your engineer can merge with confidence.
  </Card>

  <Card title="High/critical risk, unclassified, or tests didn't pass" icon="triangle-alert">
    Called out clearly on the PR, so it never merges without someone taking a closer look.
  </Card>
</CardGroup>

<Note>
  tasksmind has read access to code and pull requests, and write access to pull requests on the
  repos you select. It has no write access to `main`. Merging is always a person, on GitHub.
</Note>

<CardGroup cols={2}>
  <Card title="From customer report to pull request" icon="git-pull-request" href="/use-cases/report-to-pr">
    Where these gates sit in the full pipeline.
  </Card>

  <Card title="See everything tasksmind can do" icon="sparkles" href="/use-cases/overview">
    Back to the full use-case index.
  </Card>
</CardGroup>