RFCs and approving

An RFC, short for request for comments, is where you and the agents work on the same document. Reception drafts one with you or you write it by hand, and you argue about scope until it is worth building.

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.

How a plan gets in

A plan enters the factory when it lands in plans/active/ on plans_repo. That is the only way in, and everything downstream reads from that one branch: decomposition, dispatch, archive.

What differs between factories is the door onto that branch, and a factory has exactly one. Whether linear_team is in its config decides which.

The default door: a merged pull request

Reception opens a pull request that adds plans/active/<slug>.md, and the gaffer opens one when it has an RFC of its own to propose. Neither of them merges it. You merge it, and that merge is the approval. The next beat sees a new plan on the branch and dispatch follows from there.

Committing the file directly would not do, because reception has repo access and could commit it too, and a signal the machine can perform is not a signal. The merge is the one act nothing in the factory performs.

On an unprotected branch that is a rule the factory follows, and crossing it would be a defect rather than an impossibility. Switch on branch protection requiring a pull request and it becomes a 403. That switch has to be yours: a factory that could set it could unset it. The cost is that you also merge the factory’s bookkeeping commits, and contracts/approvals.md lays out the trade.

The better door: a Linear state

Name a linear_team and the RFC becomes a Linear issue whose description is the plan. 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 your behalf, so a plan on that branch is still what approved means to everything downstream, and writing one in by hand still works.

This door is better because it works from a phone. Linear holds the RFC, the asks and the queues, while GitHub holds branches, pull requests and CI, none of which is ever waiting on you. A queue that stalls because you were not at a desk has stopped on posture rather than on judgment.

It does not depend on the factory behaving, either. Linear lets an integration create labels but not workflow states, so the marker that carries the decision had to be handed to the factory rather than made by it. The gaffer works the rest of your board and is barred from exactly one transition, which is moving anything into the approved state.

Comments are how you steer

A comment is how you change an RFC. “Looks good but drop step 3” gets applied to the document, the gaffer replies saying exactly what it changed, and the RFC sits where you left it until you approve it. Order does not matter, because every unapplied comment is applied before the plan is committed, so an approval that arrives first still gets the amended document. What the factory will never do is dispatch against a version you asked it to change.

Where the rest of your attention goes

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, because a worker pushing to a work repo is work happening rather than somebody approving something.

Three queues carry everything else that needs you: verified work waiting on your review, anything blocked on a decision, and parked ideas nobody has committed to. With Linear they are your team’s own states and a blocked label, resolved from your real board at init rather than from a vocabulary the factory invented. Without it they are plans/blocked/ and plans/backlog/ in the plans repo, and work waiting on review is the open pull request itself. Either way anything blocked carries one ASK: question, edited as it sharpens and never reposted. contracts/queues.md is the taxonomy and the order the loop spends your attention in.

Finished plans archive with a dated stamp, so provenance stays greppable.