Before a human ever sees an approve button
1
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.
2
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.
The approval card
Before tasksmind commits code or opens a PR, it posts an approval card in the thread with four buttons: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:Low or medium risk, tests passed
The PR is marked clean, your engineer can merge with confidence.
High/critical risk, unclassified, or tests didn't pass
Called out clearly on the PR, so it never merges without someone taking a closer look.
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.From customer report to pull request
Where these gates sit in the full pipeline.
See everything tasksmind can do
Back to the full use-case index.