Loop Operators

Abstract

Agile software development's planning apparatus — splitting work into parallel workstreams, recomposing them at will — rests on an assumption this series has already proven exactly true for deterministic operators and exactly not-guaranteed for invocable non-deterministic ones (PRR-2026-002 Theorem 6.1; PRR-2026-003 Theorem 7.1). This paper reads that scope boundary as a literal description of the transition from human-authored development to loop-programming: an autonomous coding agent's single invocation is not a deterministic operator, and composing its output the way Agile composes deterministic work is not guaranteed to commute the way it always did before. We concretize four further results onto the same domain without inventing new abstract structure: Definition-of-Done checklists as closure operators (PRR-2026-006 Theorem 4.2), loop health as the trajectory trichotomy (PRR-2026-006 Theorem 3.1), permissive versus unanimous code review as the Aggregate Pooling and Consensus Bounds (PRR-2026-008 Theorems 8.1–8.2), and multi-agent brainstorming versus classical independent parallel tasking as coherent versus decohered pooling (PRR-2026-009 Theorem 5.2). Two of the five mappings are independently confirmed already running in this project's own tooling, not merely plausible. We close with a discussion synthesizing all five into a concrete prescriptive sketch of software process for the loop-programming era.

Keywords. software development lifecycle; Agile; autonomous iteration; closure operators; trajectory trichotomy; code review policy; coherent exploration; Edwardian algebra

1. Introduction

Every result in this section was proven before this paper existed to apply it. That is a deliberate constraint, not a limitation: PRR-2026-007 established that this series' abstract structures can be concretized in a domain with no computation in it at all (prose fiction) without inventing a single new theorem to do it. This paper asks whether the same discipline holds for a domain adjacent to the series' own subject matter — software development, specifically the transition currently underway from deterministic, human-authored process to autonomous, loop-driven iteration. Agile's guarantees are not being discarded here. They are being scoped: shown to hold exactly, unconditionally, for the deterministic regime they were built for, and shown — by an already-proven theorem, not a new argument — not to extend for free into a regime that didn't exist when that methodology was designed.

2. Preliminaries

We reuse S and its order (PRR-2026-002 §2), R and C together with the Distributivity Obstruction (PRR-2026-003 §0, Theorem 7.1), closure operators and the trajectory trichotomy (PRR-2026-006 §4, Theorem 3.1–4.2), the cyclic-correctness plateau (PRR-2026-005 Proposition 7.1), ground-truth anchoring c_ω (PRR-2026-008 §4), the Aggregate Pooling and Consensus Bounds (PRR-2026-008 Theorem 8.1–8.2), and coherent pooling's absence of an aggregate bound (PRR-2026-009 Definition 5.1, Theorem 5.2). None are modified.

3. The Domain: Repository Facts and Definition of Done

S reinterprets, unmodified, as facts about a software system's state — "the auth suite passes," "feature X is merged to main," "the API contract for endpoint Y holds." Facts about a codebase compose under conjunction, disjunction, and negation exactly as any propositions do; nothing about the software domain obstructs Boolean- algebra closure, the same finding PRR-2026-007 made for narrative canon facts.

This is not a new construction. It is the vaguest part of the whole series — what "0" should mean on a bounded correctness scale — landing on a term software teams already use without prompting.

4. Deterministic Moves vs. Invocable Loop Iterations

R = a deterministic dev move: a human-authored commit, or a greedy/ temperature-zero AI edit — the same output for the same input, every time. C = one real invocation of a genuinely non-deterministic coding agent (nonzero temperature) — PRR-2026-003 §0's own discipline: a real, terminating call, one real answer, but not the same answer on every call. No new structure; this is PRR-2026-003's own definition, applied to a worker that happens to be an LLM rather than left abstract.

5. Where Agile's Composition Assumption Breaks

SDLC translation. Two tickets, same sprint, same underlying task, assigned to a loop-programming agent. Ticket A: the agent generates once; both branches build on that single generation. Ticket B: the agent is invoked fresh, independently, for each branch. Classical Agile planning treats these as freely decomposable and recomposable — the right-distributivity assumption, exactly true for deterministic human work. It is not exactly true the instant the worker samples at nonzero temperature: same ticket, same sprint, provably different final states depending on composition order, not from bad process but from the algebraic fact this series already proved.

Scoped, not a blanket claim. PRR-2026-002 Theorem 6.1 says the guarantee holds exactly for deterministic work — most of software development until very recently. The claim here is narrower and precise: the guarantee is scoped to R, and loop programming lives in C, where it isn't free.

6. Definition of Done as a Closure Operator

A DoD check is inflationary (never un-satisfies an already-met criterion), monotone (a more-complete state never fails a check a less-complete one passed), and idempotent (re-running it changes nothing) — PRR-2026-006 §4's exact definition of a closure operator, satisfied by construction rather than by analogy. Its corresponding meet-closed family (PRR-2026-006 Theorem 4.2) is exactly the finite set of named acceptance criteria, and Corollary 4.4's caution transfers directly: a fully green DoD checklist is only locally maximal within what was actually checked — not the same claim as "nothing is wrong."

7. The Trajectory Trichotomy as Loop Health

An autonomous dev loop's iteration ρ^n(x) — apply the agent's edit operator n times to the repository state — is a literal instance, not a metaphor:

• Stabilizing — the loop converges to a fixed point. Shipped, done.
• Eventually periodic — thrashing: fix A breaks B, fixing B re-breaks A, forever. PRR-2026-005 Proposition 7.1 (cited) adds a sharp fact: a correctness- nondecreasing operator whose trajectory genuinely cycles has correctness constant across the entire cycle — a safe-looking thrashing loop is not quietly still improving between cycles. It has already stopped.
• Aperiodic — open-ended live-service iteration, never stabilizing, never repeating.

8. Two Review Policies, Two Guarantees

Map ⊞ to a permissive merge policy — either reviewer's approval suffices, the result joins what each would independently allow. Map ⊙ to a unanimous merge policy — every reviewer must independently agree, the result meets what each would allow. Theorem 8.1: a permissive two-reviewer policy never scores worse, in aggregate expectation, than either reviewer alone. Theorem 8.2, the sharper reading: a unanimous policy never scores better than the most cautious reviewer alone.

Unanimous review is not a way to exceed your best reviewer's judgment. It is, provably, a way to never exceed your most cautious one — not a criticism of consensus process, which is often exactly the point for high-stakes work, but a precise statement of what the policy buys, replacing the vague intuition that more agreement is unconditionally safer.

9. Coherent Exploration vs. Classical Parallel Tasking

Map decohered, classical pooling (⊞) to "run agent A on approach 1 and agent B on approach 2, fully independently, evaluate each, then merge the better result" — genuinely bounded below by Theorem 8.1, safe by construction. Map coherent pooling (⊕_Q^θ) to "let several agents jointly explore multiple approaches before any one is committed or tested, influencing each other's still-uncommitted direction" — real brainstorming, and it inherits no such floor: it can land better than any single approach, or worse than all of them, and PRR-2026-009 Theorem 5.2's own structural point (the earlier proof needs two already-realized samples to take a join of, and brainstorming never produces those before combining) explains exactly why no bound transfers.

The prescription is not "avoid coherent exploration." It is: know which regime you are in before trusting the outcome. Decohered merging inherits a proven floor. Coherent exploration does not, by an equally proven theorem. Treating the second as if it inherited the first's guarantee is the actual risk, not the practice of brainstorming itself.

10. Toward a New SDLC

Synthesizing §5–9 into a concrete sketch, not a new formal object: treat merges as sequential-invocation compositions with a stated order, not interchangeable parallel work units, once any worker in the pipeline is genuinely non-deterministic (§5). Prefer automated, closure-operator-shaped Definition-of-Done gates over manually re-checked checklists — idempotence is a property to engineer for, not assume (§6). Monitor a loop's trajectory type as a first-class health signal alongside velocity: a stabilizing loop needs nothing further, an eventually-periodic one needs to stop and change approach rather than iterate again, and an aperiodic one needs an explicit decision that open-endedness is intended (§7). Choose merge policy — permissive or unanimous — for the guarantee it actually provides, not the one it's assumed to provide (§8). And default to decohered, independently-evaluated exploration unless the unbounded upside and downside of coherent, pre-commitment brainstorming has been explicitly accepted as a deliberate risk for the task at hand (§9). None of this discards what Agile taught about deterministic, human-paced work. All of it is scoped to where that teaching's own guarantees, proven decades before loop programming existed, stop extending for free.

Peer Review