The platform
One request.
Six stages.
No war room.
This is the whole pipeline, in order, with nothing hidden. A request lands on the board. A Project Manager plans it. You approve. Specialists build it on isolated branches. Gates sign it off. DevOps ships it to your server and watches the health check — and puts it back if the check fails.
Request to production
What actually happens, stage by stage
The pipeline is the same every time. What changes between projects is how many of these stages need your hand on them.
You file a request
Write what you want in the language you would use with a colleague. A request has a type, a priority and a position on the board — you can reorder it, park it, or archive it when it stops mattering. It belongs to a project, and a project holds the git repositories and the team of specialists the work will draw on.
- No specification required. "Card payments fail for European customers" is a request. So is "move the invoice PDF job off the web server".
- Types and priorities sort the board so the important thing is not the thing at the bottom.
- Talk it through first if you'd rather — chat with the Project Manager about the project and turn the conversation into a request when it's clear.
- One project, many repositories. Work that spans a front end and an API is still one request.
The Project Manager plans it
The Project Manager reads the request and your connected repositories, then writes a plan: a summary in plain English, a set of tasks, an owner for each task, and a depends_on graph saying what has to happen before what. Nothing has been built yet. This is the cheapest moment to disagree.
- Owners, not guesses. Each task is assigned to the role that should hold it — architect, backend developer, database engineer, QA.
- A dependency graph, so a migration lands before the code that reads from it, and independent work runs side by side.
- Written for a human. The plan summary is prose you can read in a minute, not a JSON blob with a font applied to it.
- A director brief frames the request in the context of the project before the tasks are drawn up.
You approve the plan
Read the plan. Approve it, edit it, or send it back with what it missed. Nothing is dispatched from a plan you have not approved — unless you have deliberately raised the autonomy level to skip that step, which is a decision you make once and can undo at any time.
- Manual — nothing runs until you press the button, including the planning.
- Supervised — planning starts on its own; work you have approved dispatches itself.
- Autonomous — healthy work ships without you, and review gates still stop for a human.
- Approval is per request. Trusting the pipeline for copy changes does not mean trusting it for a schema migration.
Specialists build it in isolation
Each task is dispatched to the specialist that owns it and runs on its own branch, in its own git worktree, from a base branch you control. Tasks with no dependency between them run at the same time. A task that depends on another simply waits, and you can see it waiting.
- No shared working directory. One agent cannot read another's half-finished edit, because it is not there to read.
- Abandoning is free. A task you kill is a branch you delete. There is nothing to unpick from your default branch.
- Watch it live. Run streaming shows the commands a specialist runs and the output it gets back, as it happens.
- It asks rather than assumes. A specialist that hits real ambiguity pauses mid-run and puts the question to you.
- Front-end work gets a preview link you can share with whoever needs to look at it before it merges.
T-02 task/t-02-auth-migration → .worktrees/t-02
T-04 task/t-04-sca-challenge → .worktrees/t-04
T-05 task/t-05-challenge-modal → .worktrees/t-05
Gates, then merge
Every task ends in a structured report: summary, files modified, risks, assumptions, recommendations and blockers. Governance roles read the work rather than produce it — the architect on shape, the code reviewer on the diff, the security engineer on exposure, QA on whether it does what the request asked for. Any role can be flagged requires_review, and when it is, dependent work stops until a human approves.
- Governance roles can reject. A reviewer that can only approve is decoration.
- Blockers surface early, in the report, rather than as a surprise in the merge.
- Review gates hold at every autonomy level. Autonomous does not mean unattended where you said it must not be.
- Branches merge into your base branch only once the gates you configured have passed.
Deploy, check, and roll back if needed
A deployment target is an SSH host with a deploy path, a deploy command, a health check, a diagnostics command and a rollback command. You write all five. A deployment run merges the work, runs your deploy command, then runs your health check. If the check fails, your rollback command restores the last commit known to be healthy — without waiting for anyone to wake up.
- Phased and legible. Merge summary, deploy output and health-check output are kept with the run, so a post-mortem has something to read.
- Automatic rollback is not a checkbox. It is your command, executed the moment the health check comes back unhealthy.
- Your infrastructure. We deploy into your servers and your repositories. There is no copy of your product living in ours.
- A failed run opens an investigation rather than a notification you have to act on yourself.
Merged 4 branches, no conflicts
Deployed to prod-web-1 over SSH
Health check failed — /healthz returned 503 twice
Rolled back to a3f91c2 — the last commit known healthy
Investigation INV-11 opened automatically
When it goes wrong
The stage everybody else stops before
Shipping is not the end of the story. A deployment run that fails opens an investigation, with an agent already assigned to it and read-only access by default.
Investigation
Someone is already looking at it
The rollback has run. The investigation opens against the failed deployment run, and an agent starts reading — logs, your diagnostics command, the diff that went out, the health-check output that refused to go green.
- Read-only by default — an investigating agent looks. It cannot change your server unless you raise its access level deliberately.
- Access you can raise — grant write access when you want it to act, and only then. The access level is recorded with the investigation.
- It ends in a summary — a written cause and resolution you can read, forward, or paste into a status update.
Opened by the failed deployment of REQ-142
Read journalctl -u tilltap-api on prod-web-1
Cause found — SCA_PROVIDER_KEY is not set on the production host
Opened REQ-143 to add the variable to the deploy configuration
The loop closes
The fix becomes the next request
An investigation that finds a cause can open a follow-up request itself, linked back to the run it came from. The fix re-enters the same pipeline as everything else: planned, approved, built on a branch, reviewed, deployed and checked.
- Linked, not orphaned — the new request carries the investigation it came from, so the history reads in order months later.
- No special path — an emergency fix goes through the same gates. That is precisely when gates earn their keep.
- You still decide — the follow-up request is a proposal on your board, not something already shipping while you sleep.
Added the 3-D Secure challenge step to the card payment path.
### Files Modified
- app/payments/challenge.py — new challenge handler
- app/payments/gateway.py — route into challenge
- tests/payments/test_challenge.py — 11 cases
### Risks
- Wallet payments untested against the live sandbox
### Recommendations
- Run T-06 before deploying to production
Your side of the line
What you control
An organisation you cannot configure is one you cannot trust. Every setting below is yours, and every one of them is reversible.
The team on the project
Add the specialists this project needs. Leave out the ones it doesn't. Work planned for a missing role is reassigned and the substitution is recorded.
Every role's contract
Each role's behaviour is a Markdown document you can read and edit. Tighten it, loosen it, or write the standards your codebase actually holds.
Which roles stop the line
Flag any role as requiring review. Dependent work then waits for a human at every autonomy level, without exception.
The autonomy level
Manual, Supervised or Autonomous, per project. Start low. Raise it when the plans stop surprising you.
The deployment target
SSH host, deploy path, deploy command, health check, diagnostics command, rollback command. You write them; Capybari runs them.
Model and effort
Override the model and the effort level per project, or for a single request that deserves more thought than the rest.
Investigation access
Read-only unless you say otherwise. Raising an investigation to write access is a deliberate act, not a default.
The base branch
Tasks branch from the base you nominate and merge back into it. Your branching model stays your branching model.
Autonomy
How much of the pipeline runs without you
Three levels, set per project. The gates do not move as you climb — only the number of buttons you press.
| Manual | Supervised | Autonomous | |
|---|---|---|---|
| Planning a filed request | You start it | Starts on its own | Starts on its own |
| Approving the plan | You approve every plan | You approve every plan | Healthy plans proceed |
| Dispatching tasks | One press per task | Approved work dispatches itself | Dispatches as dependencies clear |
| Roles flagged for review | Stops for you | Stops for you | Stops for you |
| A specialist's question mid-run | Reaches you | Reaches you | Reaches you |
| Isolated branch and worktree per task | |||
| Health check before a deploy is called good | |||
| Automatic rollback on a failed check |
Autonomy is also the most honest upgrade trigger we have: Manual is on the free plan, Supervised on Starter, Autonomous on Pro. You pay for trust as you earn it. See pricing.
Where the work happens
In your repositories. On your servers.
Repositories
Connect the repos you already have
A project holds one or more connected git repositories and the team that works on them. Capybari commits to branches in your repository — not to a fork, a mirror, or a copy that becomes the real one.
- Existing codebases welcome — the boring middle of a product's life is the case we built for, not greenfield demos.
- One history, one convention — one branch per task and one report per branch keeps a log somebody can still read next year.
- Leaving is a git operation — your code is already where it lives. There is nothing to extract.
Previews
Look at it before it merges
Front-end tasks generate a design preview with a shareable link, so the person with opinions about the button can have them at the point where changing it is cheap.
- Shareable — send the link to someone who has never seen the board and does not want to.
- Before the gate, not after — feedback arrives while the work is still on its own branch.
- Live output too — run streaming shows the commands and results behind the preview if you want the detail.
Shareable link, expires with the task. No deploy required.
Boundaries
What will not happen
Detail
Questions about the pipeline
How long does a request take to plan?
Planning is one agent run. The Project Manager reads the request and the connected repositories, then writes the plan summary, the tasks, the owners and the dependency graph.
It lands on the board for you to approve, edit or reject. Nothing has been built at that point, which is what makes disagreeing cheap.
Can two tasks change the same file at once?
Each task has its own branch in its own git worktree, so no task can see another's uncommitted work. Where the ordering genuinely matters, the Project Manager records it as a dependency and the later task waits until the earlier one is done.
What exactly does Capybari need on my server?
SSH access, a deploy path, a deploy command, a health check, a diagnostics command and a rollback command. You write all of them, which means they run the way your infrastructure already expects.
You can also run Capybari with no deployment target at all and merge by hand.
What happens if the health check fails?
Your rollback command runs and restores the last commit known to be healthy. The deployment run keeps its phases, merge summary, deploy output and health-check output, and an investigation opens against it with an agent assigned.
Can I stop a run half way through?
Yes. Work in progress lives on its own branch in its own worktree, so stopping is a local decision — nothing has touched your base branch. Live run streaming means you can see what you are stopping before you stop it.
What if a role I need isn't on the team?
Capability substitution reassigns the work to a role that can cover it, and records the substitution rather than performing it quietly. If nobody can cover it, the work stops and asks you.
Does the pipeline change for an urgent fix?
No, and that is deliberate. A fix from an investigation is planned, built on a branch, reviewed and health-checked like everything else. Skipping gates is how the second outage happens.
Where do I see all of this?
On the board. Requests, planned tasks, dependencies, running work, review gates, deployment runs and open investigations are one view. The features page lists what each part shows you.
Something specific to your setup? Ask us — a person replies.
Put one request through it
Connect a repository, file the thing that has been sitting on your list since March, and read the plan that comes back. Manual autonomy. Nothing runs without you.
No card required · Your repositories, your servers · Export everything, any time