This project runs like a real software team — a product owner, an architect, developers, a tech writer, a reviewer, QA. Most of those seats are filled by AI, working under a written contract instead of tenure. This page names every seat, who fills it, and what it's never allowed to do. For the pipeline a change actually moves through, see The Process.
One team, mapped onto AI
| On a human team | Here | Filled by | Never |
|---|---|---|---|
| Product owner · BA · project manager | The Principal | A person | Nothing — final, non-delegable authority |
| Backlog sequencing · status reporting | The PM Session | AI | Dispatch work, write a spec, or record a verdict |
| Solution architect · tech lead | The Architect | AI | Write or delegate product code |
| Developers | Developer(s) | AI, one or several | Redesign scope — kicks back instead |
| Technical writer | The Tech Writer | AI | Edit anything outside /about/* |
| Code reviewer | Qcoder, then the Architect | Tools + AI | Substitute for the Architect's own review |
| QA · user acceptance testing | Business testing in SIT | A person | — |
Good teams don't let a developer approve their own pull request — segregation of duties. The person who defines the work, the person who does it, and the person who accepts it are never the same session. That matters more here than on a human team: a person who's unsure tends to hesitate; an AI that's wrong sounds exactly like an AI that's right.
Human
Product owner, architecture approver, lead tester, and release authority. Decides what gets built and in what order, tests it for real before calling it done, and holds every credential no agent can substitute for — Tailscale login, production sudo.
AI
Reads the board's spec headers and tells the Principal what to build next and what's waiting on him. Never assigns work itself — only the Principal's dispatch names which spec a session takes.
AI
Turns a need into a written spec, then reviews every build against it and records a verdict — using one of the strongest available models, and never the session that built the item, since a verdict's job is to disprove the builder. Never writes product code, and never delegates it.
AI · one or several
Builds exactly the spec, in the files it names, with tests in the same commit. If the spec is wrong or silent on something, that stops and goes back to the Architect — not a redesign, not an improvisation.
AI
Owns everything under /about/* — writes it, then checks every claim back against the real code before shipping it, the same discipline a Developer's tests provide elsewhere.
Tools + AI
Every changed file runs security and lint scans plus an independent AI review (Qcoder) before a build is reported done. Catches a different class of defect than a human glance — and still isn't a substitute for the Architect's own review.
How a role gets loaded
A session doesn't know what it is until it reads a file. Nobody opens a "developer window" — a session opens blank, is told which spec to build, reads the dispatch note naming its role, and works under that role's contract for the rest of the session.
Three refusals are hard, every time: a session already holding a different role stops rather than wearing both; if the dispatch note and the spec disagree about the role, the session stops and asks rather than guessing; and a session that has already built one item in this session starts fresh for the next rather than chaining. And the role never widens mid-build — a Developer who finds the work needs a documentation page hands it back rather than writing it itself.