RFCs and approving

An RFC — request for comments — is where you and the agents work on the same document. It is a Linear issue whose description is the plan, and you argue about scope in the comments until it is worth building.

Linear is where everything that needs a person lives. GitHub holds branches, pull requests and CI, none of which is ever waiting on you. That split is what makes this approvable from a phone, which was always the point: a queue that stalls because you were not at a desk is friction, not judgment.

An RFC is a work list, not an essay: what changes for the user, why now, how success is measured, and steps with acceptance conditions specific enough that an agent cannot fill a gap with a guess. plans/README.md is the house style, including the 120-line budget.

You approve by moving the issue into one state. That is the entire signal, and a comment is not one. Which state is linear_approved_state, picked from your team’s own states at init. The gaffer then commits the plan to plans/active/ on plans_repo and builds from there, so a plan on that branch is still what “approved” means to everything downstream, and writing one in by hand still works.

Approved intent has one home even when the work has several. plans_repo is a single repo and plans_branch a single branch, which is why the gaffer’s watermark is one <branch> <sha>: it senses decisions, and a decision lands in one place. The repos a plan’s steps touch are repo_scope, and progress across them is counted per merged pull request rather than off the watermark — a worker pushing to a work repo is work happening, not somebody approving something.

A comment is how you change an RFC — “looks good but drop step 3” gets applied to the document, and then the issue sits exactly where you left it until you move it. contracts/approvals.md is the mechanism. Finished plans archive with a dated stamp, so provenance stays greppable.

The factory works your board, with one exception. It moves issues to in progress when workers start and to done when a plan archives, because a board that does not track the work is not worth reading. It is barred from exactly one transition: moving anything into the approved state. That exclusion is the whole boundary, and it holds up because Linear lets an integration create labels but not workflow states — the marker that carries the decision had to be handed to it.

The rest of your court is on the same board, in your team’s own columns rather than a vocabulary the factory invented: verified work waiting on you goes to linear_review_state, parked ideas to linear_backlog_state, both named at init. Anything blocked on a decision gets a blocked label, which sits alongside whatever state the work is in, and carries an ASK: comment with the one question — edited as it sharpens, never reposted. contracts/queues.md is the taxonomy and the order the loop spends your attention in.