A run is not a chat.
It's a pipeline.
Every stage below is a discrete, inspectable step. If one fails, the run row says which, and nothing half-finished lands in your repository.
STAGE 01
Context
Before an agent sees anything, the run assembles the case file: the work item, its parents, the acceptance criteria, and the files in the bound repository that the keyword extractor judges relevant. The detected stack profile rides along, so the agents write Express and Drizzle rather than generic pseudocode.
WHAT GOES IN
Work item title, description and acceptance criteria
The epic and story above it, for intent
Relevant repository files and the detected stack
Your refinement prompt, if you wrote one
STAGE 02
Two answers
Raptia and Fovea run in parallel against the same case file. They reason differently by design — when one misreads the acceptance criteria, the other usually does not.
WHY PARALLEL
One shared context, two independent reasoning paths
No sequential prompting, so no shared blind spot
Either answer is committable — Synthesia tells you which, with a confidence score from 0 to 100
Both are kept on the run for later comparison
STAGE 03
Synthesia ranks
Synthesia scores each suggestion on five dimensions — correctness (35%), readability (20%), diff size (15%), convention adherence (15%), and AC coverage (15%) — then flags the leader as Recommended with a confidence score and a plain-English explanation of its reasoning. Two additional behaviour signals track ambiguity handling and surgical precision.
SCORED ON
Correctness — does it solve the stated problem? (35%)
Readability — is it clear and maintainable? (20%)
Minimal diff — does it change only what is needed? (15%)
Convention adherence — does it match existing patterns? (15%)
AC coverage — how many criteria does it address? (15%)
Confidence score 0–100 and a plain-English explanation
STAGE 04
Commit
Committing creates the deterministic branch task/<id>, writes the change, and opens a pull request titled with the work item. The item moves to review and the run records which suggestion won.
WHAT LANDS
Branch task/<id>, from the default-branch head
One commit containing the chosen suggestion
PR titled [Blue Mantis] <work item title>
Work item moved to review, run marked succeeded
STAGE 05
Schedule and sweep
A run can be queued up to thirty days out. Every five minutes the dispatcher claims what is due, runs it, and emails you the outcome — including the failures, with the reason attached.
THE LOOP
Up to twenty pending runs per user
Claimed two at a time, no double-dispatch
Runs stuck over twenty minutes are failed
Completion and failure both send email
STAGE 06
Veria reviews
After you commit a suggestion, Veria reads the committed code against the acceptance criteria and writes a structured review: what was addressed, what was missed, and what the human reviewer should focus on.
WHAT VERIA CHECKS
Which acceptance criteria are fully covered
Which are partially addressed or missing
Specific strengths in the committed code
Risks or gaps to watch in code review
STAGE 07
Aegis secures
After commit, Aegis scans the change for security vulnerabilities — injection flaws, hardcoded secrets, authentication bypasses, OWASP Top 10. High and Critical findings block the PR via a GitHub commit status check. Medium and Low findings create sub-tasks in your tracker. Remediate Now creates the ticket, syncs it to the board, and starts a new run with the remediation brief pre-filled — closing the security loop without leaving Blue Mantis.
WHAT AEGIS CHECKS
OWASP Top 10 (2021) — all ten categories
Injection: SQL, NoSQL, command, LDAP
Hardcoded secrets, API keys, and credentials
Authentication and authorisation flaws
Missing input validation on sensitive endpoints
High/Critical → PR blocked · Medium/Low → tracker ticket
STAGE 08
Narratia documents
Narratia generates an operational runbook from the completed run: what changed and why, deployment steps specific to this change, rollback procedure, validation commands, and a summary of Veria and Aegis findings. Pushed to Confluence via REST API, Notion via the Notion API, or committed as docs/runbooks/ITEM-KEY.md to the same PR branch — zero extra credentials for the Markdown option.
RUNBOOK SECTIONS
Summary — what changed and why
Deployment steps — specific to this change
Rollback procedure — referencing the branch and PR
Validation — how to verify it is working in production
Test cases — from the generated test suite
Security notes — Aegis gate status and findings
What a run costs you in attention
30 sec
Opening the panel, writing a refinement line, pressing Run.
2 answers
What comes back to review — not a transcript, not a chat log.
1 review
The pull request, in the tool you already review pull requests in.