A software factory by ConsensusLabs · Amsterdam
Hand Rose a ticket. You get back a pull request.
On the way, one agent writes the tests before any code exists. Another writes the code, and may not change those tests. Up to seven reviewers read the change. Every check that ran is filed as a carbon copy.
You sign twice: the plan, and the merge.
Work item · Jira or GitHub issue
A ticket comes in. Before anyone reads it, the clerk checks one thing: can this repo prove its own work? Rose looks for the build, test and lint command your CI already runs. If there is none, it warns you and waits.
Then it gathers the ticket, the linked docs and the team wiki into one brief. For a bug, it first tries to reproduce it.
The planner turns the acceptance criteria into assertions a test can check. It reads the decisions earlier runs recorded, so it does not undo one by accident. Large work is split into sub-tickets, and each one that matters is designed twice before a design is chosen.
Then the plan waits on your desk. Nothing is built until you sign.
One agent writes the tests, before the code exists. It works from the plan's assertions, runs the tests, and shows they fail for the right reason. Then it commits them.
A mechanical check matches every assertion in the plan to a committed test, so nothing is dropped on the way. The tests leave through a one-way hatch. The agent that writes the code works in a different context: it gets the tests, not the reasoning behind them.
One implementer per sub-ticket, each in its own git worktree, so your checkout is never touched. Before it writes, it is told the bug classes this repo has already paid for.
It must make the acceptance tests pass without weakening them, add its own tests, and keep build, tests and lint green. Then a probe breaks the new code on purpose. If the tests still pass, they were not testing anything.
Five tries. Then it stops and asks you.
Correctness also checks every caller of a contract that changed. A blocking finding about behaviour must say how to show the failure. It goes back to the workshop, and only the desks that raised it look again.
If the implementer disputes a finding, a judge in a separate booth, who has seen neither side's reasoning, rules on the evidence. Five rounds. Then it stops and asks you.
The branch is rebased onto the latest code, with a check that the fix survived the rebase. The pull request is written for a reader who never saw the pipeline: what changed, the ticket quoted word for word, a diagram of the change, and each acceptance criterion mapped to the test that holds it.
Then the rose copy is filed: which gates ran, on which commit. A script can check it against the pull request.
The pull request lands on your desk. You read it. You merge it, or you send it back.
Two signatures: the plan, and the merge. Everything in between is checked by something other than the agent that did the work.
In an office, forms go out in triplicate. The original travels. The rose copy stays behind and proves what happened. Rose keeps all three.
Quoted word for word in the pull request, so the reviewer reads what was asked, not a summary of it.
Original
Specimen: the values are made up. The fields are the real ones.
DuplicateSpecimen
Bot findings, shipped bugs, hotfixes and your own corrections. Each becomes a proposed rule for the reviewers. You decide which ones stay.
Triplicate
Some jobs are bigger than one ticket. They run when you call them; the night watch can also run on a schedule.
Night shift roster
| Job | Runs | Leaves behind |
|---|---|---|
Night watch /sentry-sweep | Daily on a schedule, or when you call it | A ticket for each new production error, with the stack trace attached |
Cleaning crew /drift-sweep | When you call it | A dated report on patterns that spread across the whole codebase, and up to five draft tickets |
Day report /journal | When you call it | Runs landed, minus the ones reverted, minus the ones that needed a hotfix |
Desk check /lens-consistency | When you call it | How often three runs of one reviewer agree on the same change |
Rose opens the pull request. The merge is yours.
The main loops have a hard limit. At the limit, the run stops and asks you. The hook catches a count recorded past the cap, not a loop that never records one.
Tests come from one agent, code from another, review from up to seven more.
What Rose learns is proposed as a rule. You decide what gets published.
Every room on the floor says what it does not cover.
Rose is a Claude Code plugin. It runs inside Claude Code, against any repo with a build and a test command. Its state is plain files in your repo — run state, ledgers, a bug index — so a run can stop and resume, and you can read everything it did.
Form R-1 · Inventory
.claude/state/workflow/The code is private. Ask us, and we will show you how it runs on your repo.
ERequest accessrose
One ticket in. A reviewed pull request out. Two signatures.