Desk roles

A single session that implements a brief, reviews the resulting change, and then records that the change was verified has produced three artifacts and one signal. Splitting those jobs across windows is what makes the three signals independent, and the split has to be structural rather than a matter of intent: an agent asked to "review this objectively, even though you wrote it" will comply enthusiastically and tell you nothing.

So each role is a distinct session with its own context, its own instructions, and its own identity for anything it writes. Four of the roles are loops that move work forward. The fifth is a coordinator that moves none of it — it arbitrates across streams and keeps the registers honest, and deliberately owns no transition of its own.

Work moves left to right: intake-desk → worker-desk → pr-review-desk → verify-desk, with the-desk watching all four. The middle column is what each role produces; the right column is the boundary that defines it.

The desk flow, drawn against the lifecycle stages, is on the methodology overview.

What it is. The single entrance. Everything inbound — a human's request, another agent's suggestion, a filed bug, a finding, a process change out of a retrospective — arrives here and leaves classified.

Why it exists. Without one front door, work enters through whichever surface the requester happened to use, and the board stops being a description of what is happening. The desk's routing test is a single question: could a worker take this as-is? Work-shaped items are filed as issues, where the issue body stays the specification. Idea-shaped items become numbered entries in the intake register, and every entry gets a recorded disposition — accepted, deferred, rejected, or duplicate — so a "no" is a record with a number, not a silence.

How it works. The desk runs as its own window with a single inbound watcher, because two watchers double-file everything they see. Its writes leave as draft pull requests. It may file an issue freely; it may close one only in a single narrow case — a fix that was reviewed and merged, where the merge itself is the authorization. A pull request that is approved but not yet merged is explicitly not enough, because the merge may still not happen.

An example. Someone drops a paragraph describing a rough idea. It is not takeable as-is, so it does not become an issue; it becomes a numbered intake entry. A later triage pass rules it accepted, which queues brief authoring — it does not author the brief on the spot. The number stays attached to the idea from the paragraph all the way to the brief, and if the ruling had been "rejected", the number and the reasoning would still be in the register.

What it is. The dispatcher. It reads the computed queue across every board it watches, claims a batch, and starts one worker session per brief.

Why it exists. Parallel agent work has two failure modes that a dispatcher is uniquely placed to prevent. The first is collision: two sessions picking the same brief, or writing into the same checkout. The second is the quiet stall: a worker that stops mid-flight and leaves a pull request nobody is driving. So the dispatcher claims each brief through a durable, shared claim marker rather than a machine-local lock — a second dispatcher asking for the same brief is refused rather than accommodated — and it sweeps for stranded pull requests before it starts anything new.

How it works. Each worker gets its own isolated checkout cut from current mainline, implements exactly one brief, and opens a draft pull request. Workers do not set verified or done, do not flip their own draft ready, and do not post a verdict on their own work. That last one is worth stating plainly: the platform itself refuses to let an author approve their own pull request, so the boundary is not merely a convention here — a worker physically cannot self-certify. The dispatcher holds a standing pool rather than firing one wave and stopping, and it refills as workers finish.

An example. A brief carrying a human gate still gets dispatched normally. The human gate binds approval — the review, the merge, the sign-off — not the implementation. Treating a gated brief as undispatchable would stall the work while adding no oversight, since the oversight all lands after the code exists.

What it is. The standing pre-merge window. It watches the open pull-request queue, dispatches a reviewer to anything new or newly updated, drives the fix-and-re-review cycle, and flips a draft to ready once it is genuinely ready.

Why it exists. Review that happens once, early, is review of a commit that no longer exists. The unit here is not the pull request but the head: a new verdict is required at each new head, so a change pushed after an approval does not inherit it.

How it works. The reviewer posts a real review under an identity the implementer does not hold, with a verdict in a fixed, parseable shape. Higher-risk changes additionally get a separate security pass, and a risk-gated change is not flippable while that artifact is missing — producing it is the desk's own work, not a reason to wait. When a verdict is approved at the current head and the checks are green, the desk performs the ready flip; the implementer never does. Findings that fall outside the change's scope are filed as issues and named in the review, rather than expanding the change under review.

An example. A reviewer approves, and a fix is then pushed to address a separate comment. The approval no longer applies to the head, so the desk re-dispatches rather than flipping. This is the ordinary case, not an edge case — most changes take more than one head to converge.

What it is. The post-merge window. It drains the queue of briefs that merged but have not been independently checked.

Why it exists. Merging is not completion. It is the moment a change becomes everyone's, and it says nothing about whether the brief's own definition of done was met. A merged brief that nobody re-checks is an assumption wearing the costume of a result, and an unwatched queue of them is where briefs rot at implemented.

How it works. The desk always dispatches a fresh verifier and never verifies inline, and that verifier must not be the brief's implementer — a session verifying its own implementation is void, not merely weak. The verifier re-runs the Verify table against merged mainline, records a per-row result with a date and a runner, and advances the row. A failure files a tracked bug immediately and the brief does not advance; the desk keeps draining rather than stopping on it. For a change that cannot be undone, a model verifier records the evidence but does not flip the status — that flip is routed to a named human, because a model cannot pre-close an unfixable change.

An example. A verify run reaches the rows but cannot reach the deliverable — a sibling repository is absent, or a token will not resolve it. That is not a pass and not a failure; it is could-not-check, and it is recorded as such. An empty result from a command that found nothing to look at is the most dangerous green in the system, because it is indistinguishable from success unless someone insisted on the third state.

What it is. One standing session that watches the whole board: arbitrating across streams, authoring briefs, keeping the registers honest, and turning what the loops learned into filed entries.

Why it exists. Every one of the four loops is, correctly, narrow — each sees its own queue. Something has to hold the cross-stream view: which stream is starving, which finding is aging past its threshold, which brief was authored against a fact that has since changed. That work is judgment, it is nobody's loop, and if it is not somebody's window it does not happen.

How it works. The-desk advances work by authoring, filing, routing, relaying, and arbitrating — and that list is exhaustive on purpose. It does not dispatch a batch, does not flip a pull request ready, does not merge, and does not run a review in its own session. When it wants a review, it files a request and stops. Its one board-level transition is the claim itself: marking a brief in-progress at the moment of dispatch.

Four constraints appear in every desk's instructions, which is the sign that they are the load-bearing ones rather than local policy.

• The merge is always the human's. No desk merges, on any tier, for any reason. Every other authority in the system is delegated; this one is not.
• Nobody signs off on their own work. Workers do not approve or flip their own pull requests; a verifier is never the implementer; the dispatcher does not review what it dispatched; the-desk does not review at all.
• Branch and draft, never mainline. Pushing a feature branch and opening a draft pull request is standing-authorized for every role. Pushing to the mainline branch is not, and neither is triggering a deployment.
• File rather than ask. Filing an issue is durable, reversible, and cheap, so no role needs permission to file one. The corollary matters more: a question is a filed artifact, not a halt, and a parked question must never strand finished work.

Putting the roles together on a single item:

1. A request arrives. The intake-desk classifies it — here, work-shaped — and it is filed with the request itself as the specification.
2. the-desk authors it into a brief with typed dependencies, a risk answer set, and a Verify table, and it lands on the board as todo.
3. worker-desk claims it, marks it in-progress, and starts one worker in an isolated checkout. The worker implements, runs the Verify table itself, fills its own evidence, opens a draft pull request, and stops at implemented.
4. The pr-review-desk dispatches a reviewer, which posts a verdict under an identity the worker does not hold. Once the verdict is approved at the current head and the checks are green, the desk flips the draft ready.
5. A human merges. Nothing about the merge advances the brief.
6. The verify-desk dispatches a verifier who did not write the change. It re-runs the Verify table on merged mainline, records dated per-row evidence, and advances to verified — then to done once the recorded review is in place.

Six roles touch the brief and no role touches it twice in a way that would let it grade itself. That is the whole design; everything else is the machinery that keeps it true when nobody is watching.

It does not make any individual review good. The separation guarantees that a distinct actor performed each step and is answerable for it. It does not guarantee that the actor was thorough, competent, or awake. A rubber-stamp review from a separate identity satisfies every structural rule in this page.

Its identity separation is uneven. The review stamp is posted under an identity a worker session does not hold, so a forged review is genuinely hard. The verification gate is not yet held to the same standard: a verifier's attribution is text written into a document by the verifying session. Extending identity attribution from the review stamp to the verification gate is designed, not shipped, and until it lands the two gates have different strengths despite looking alike on the board.

The roles are conventions carried by instructions, not permissions enforced by a platform. Some boundaries have real teeth — a platform refusing an author's self-approval, a credential a session does not hold, a check that fails a merge. Others are text a session is asked to obey. Where a boundary has no enforcement, this page is describing a discipline, not a lock.

Not covered here. This page describes the five lifecycle roles. It does not cover reporting and metrics roles, competitive or market scanning, or the installation runbook for standing the desks up in a new project — those ship alongside the desks but own no lifecycle transition. Nor does it cover the operational specifics — how a window boots, watches, claims, and reports — which are project configuration rather than methodology, and which vary between projects that have adopted the same roles.