Part one
This is how we actually build and maintain Tourney — this bracket pool app, the real thing you're using right now — not a hypothetical process. Everything below describes real work, done for real, tracked as a series of items: a bug fix, a new feature, a docs pass, each one a single scoped piece of work with its own ID (T44, T81, and so on) that moves through every stage on this page in order.
An item's life doesn't start with a file. It starts with a conversation — the Principal and the Architect talking through what's actually needed, back and forth, no file yet, the same way any two people work out a plan out loud.
That conversation ends the moment it's written down. The output is a spec, committed to specs/ — and from that exact point on, a different rule takes over: every handoff is a committed file, not a conversation. No session listens to another; each reads what the previous one wrote. That's why a session can be closed, crash, or be replaced mid-stream without losing the thread. The conversation only ever happens once, right here, before anything else in this whole loop begins.
That coordination is a human job. The Principal is the one working across every seat on the team — Architect, Developer, Tech Writer — checking in with each of them and making sure the work lines up with what was actually asked for. Each of those seats works from its own written rulebook, loaded fresh every time a session starts, so the same standards hold no matter which session is doing the work that day.
The Principal and Architect turn a business need into something specifiable — a conversation, no file yet.
The conversation ends here. The Architect commits what was decided — acceptance criteria, owned files, the security rule it must preserve.
What happens to that spec next — checking the board, assigning it, everything from here to a released commit — is Working the Queue's job, not this page's.
Why files
Files are how the team talks, because the team cannot talk. No session can see another; each one starts blank. So every handoff is written down and committed.
A spec says what to build and how we will know it worked. A dispatch note assigns it. A report hands it back. A ledger records the verdict.
The test of each is the same: could someone who has never seen this project pick it up cold and do the work? If not, it is not written well enough.
Every seat's rulebook
Every AI seat — Architect, Developer, Tech Writer — reads its own rulebook the moment a session starts, and works inside it for as long as that session lasts. It's plain language, not code, and it covers the same five things for every seat.
Scope
what this seat may touch
Exactly which files and which piece of work belong to this seat today — and a firm stop at the edge of it. Wanting to fix something just outside that line doesn't widen the line.
Proof
what "done" has to show
What has to be run and shown before anything counts as finished — tests, security checks, and real output, not a claim that it works.
Escalation
what gets handed back
Anything the plan didn't cover, or that seems wrong, goes back to the Architect rather than being decided alone. Guessing is not part of any seat's rulebook.
Handoff
how the work gets written up
What the report has to say, so the next session — human or AI — can pick up the thread cold, without asking anyone what happened.
Hard no's
never, no matter what
A short list of things a seat is never allowed to do, even under pressure to move fast — the kind of rule that exists because skipping it once already cost something.