A doc fix and a payments schema migration need different gates in the same repository

The state machine in the proposal has no cursor: no component tracks that a change is on step four. A process advances when a fact appears in the system that owns it, and rules react ^[18]. Those facts sit in the repository, CI, the cluster and the tracker, and no single tool owns them ^[15]. An event that arrives late, twice, or after a restart is handled like any other, because rules only react to current state ^[19]. A release freeze slots in as one more condition on a rule, so the definition itself stays as it is ^[20].

Gates only work if something stops the agent. A gate written as a prompt instruction depends on the model following it ^[21]. The New Stack puts the determinism in the agent harness, which stops the agent between actions until a gate is answered, and leaves the rest to infrastructure ^[22].

Everything else in the argument rests on the volume claim. Anthropic's playbook says "code is no longer the bottleneck" ^[2], and the constraint moves to planning, review, verification, deployment and governance once agents can produce an implementation in minutes ^[3]. The risk the post names is "producing ten times the changes at the same quality per change or worse, with no way to identify which changes are the bad ones" ^[4]. Hold the defect rate per change constant, and ten times the changes gives ten times the defective ones to find ^[24]. According to the post, one person looking at each change stops working at that volume ^[5].

The tools do not model risk class. A documentation fix, a dependency upgrade and a schema migration in a payments service need different levels of verification, different approvers and different records ^[11]. In regulated domains the process itself is part of the compliance obligation, and auditors expect a record of who approved each change and based on what evidence ^[12]. When one process is prescribed, the post argues, "teams route around it for changes that don't fit, which is the worst outcome because the real process becomes invisible" ^[13]. Teams usually escape through configuration, and enough of it turns the tool into a workflow engine that nobody fully understands ^[14].

For a fixed stage sequence to be the right default, every change in a repository would have to carry similar risk and require the same record. One deploy target, no regulated data and a thin dependency surface would make that true. Otherwise one definition per repository still falls short, because every change in that repository travels the same path ^[23]. The post reports no defect rates, no review times and no organization that has run rules-as-data at volume; the case it makes is a design argument ^[25].