One turn of the loop

One rung runs as one turn: six stages, each with a clear owner and a clear output, handed back and forth across the line.

Sharpen, demo, review, and feedback are the Operator's; build and ship are the Author's. Each stage exists to prevent a specific failure — drop one and a named failure from A1.01 returns. Step the view on the right to walk the turn stage by stage, then watch what breaks when a stage is missing.

The six stages Why each earns its place On the Portal References

Step through the turn

Stage 1 · sharpen — owner: the Operator. Output: a sharpened rung — scope plus what “done” means. The Author can spec from it.

The six stages of one turn

One rung is one turn of the loop, and the turn has six stages handed back and forth across the line set in A1.03.1. Four are the Operator's — sharpen, demo, review, feedback — the intent and the judgement. Two are the Author's — build, ship — the production. The order is fixed: sharpen, build, ship, demo, review, feedback, then the spec is edited and the loop turns again.

Each stage names exactly one owner and produces exactly one output, so the handoff is unambiguous. The Operator hands a sharpened rung to the Author; the Author hands back a shipped increment; the Operator demos and reviews it; and the Operator's feedback edits the spec the next turn starts from. Nothing in the turn crosses the line: the Operator never writes the increment, and the Author never decides the goal.

1 · sharpen: Operator — scope the next rung to a thin slice and fix what “done” means. Output: a sharpened rung the Author can spec from.
2 · build: Author — turn the sharpened rung into a spec, then build the increment from the spec and the brief. Output: the spec, and the increment built from it.
3 · ship: Author — ship the increment so it can be exercised for real. Output: the increment, shipped.
4 · demo: Operator — exercise what returned; see it run on something real. Output: the increment seen running.
5 · review: Operator — judge the increment against the spec. Output: a judgement — accept, or send it round again.
6 · feedback: Operator — record what to change; this edits the spec, and the loop runs again. Output: the edit that the next turn starts from (adapt).

The split is the one from A1.03.1, distributed across the turn: every stage the Operator owns is a point of intent or judgement; every stage the Author owns is production. The order is the contract for the handoff — sharpen before build, ship before demo, review before feedback.

Why each stage earns its place

The loop is not ceremony. Each stage removes the one property that makes a known failure possible, so the turn is the slice's acceptance distributed across six steps. Drop a stage and the property it removed comes back — and with it the named failure from A1.01. The figure makes the cost concrete: skip a stage and see which failure returns.

Skip sharpen and the Author builds with no spec — that is vibe coding: an unspecified, unacceptable diff. Skip review and unaccepted work ships — vibe coding's unaccountable diff again, now in production. Skip feedback and the spec never adapts, drifting back toward the big-bang spec the course opened by rejecting. Each kept stage is the answer to one of those failures.

Skip a stage · which failure returns

The loop holds: every rung is specified, accepted, and adapts. Each stage answers a failure, so all six together close the gaps the failures opened.

The stages are the slice's acceptance, distributed across one turn — each one the answer to a failure, so dropping it lets that failure back in.

One turn on the Portal

Take the rung “one branded id” on the Portal — the learning platform this course builds. The Operator sharpens it: a 14-char id that decodes to its type, unique within a node-ms — that is what done means. The Author specs that contract and builds Portal.ID.generate/1 to satisfy it, then ships. The Operator demos (the id decodes), reviews against the contract, and gives feedback — “also keep them sortable by time”.

The feedback edits the spec, and the next turn begins on an accepted rung. Each stage shows up once: sharpen sets the contract, build and ship are the Author's, demo and review are the Operator checking the increment against that contract, and feedback is the edit the next turn starts from. The line holds throughout.

# 1 sharpen — Operator: scope the rung and fix what "done" means (the contract).
#   "a 14-char id that decodes to its type, unique within a node-ms — that is done"

# 2 build / 3 ship — Author: spec the contract, produce the code, ship it.
id = Portal.ID.generate(:user)        # => "USR0NbAb1xcFCy"

# 4 demo / 5 review — Operator: exercise it, judge it against the contract.
assert Portal.ID.decode(id).type == :user   # decodes to its type → accepted

# 6 feedback — Operator: record what to change; this edits the spec, and the loop turns again.
#   "also keep them sortable by time" → the spec for the next turn

The principle

Six owned stages in a fixed order, each preventing a known failure: sharpen, build, ship, demo, review, feedback — then the spec is edited and the turn runs again.

On the Portal

One turn mints one accepted branded id: the Operator sharpens the contract; the Author builds and ships Portal.ID.generate/1; the Operator demos, reviews, and feeds back.

The loop is the slice's acceptance spread across one turn — six owned stages, and the next turn starts from an accepted rung.

Recap — one rung, one turn, six owned stages

One rung runs as one turn of six stages: the Operator sharpens, then demos, reviews, and feeds back; the Author builds and ships in between. Each stage has one owner and one output, so the handoffs across the line are unambiguous, and each stage earns its place by removing the property that lets a named failure in — drop sharpen or review and vibe coding returns, drop feedback and the big-bang spec creeps back. The final stage, feedback, is the one that makes the loop a loop: it edits the spec the next turn starts from.

Next in A1.03: A1.03.3 · Adapt: feedback edits the spec — the stage that closes the turn and reopens it, and how an edited spec carries the change into the next rung.

References

Primary sources for the short, owned cycle — build, ship, review, adapt — and where it connects in the course.

Sources

Beck, K. — Extreme Programming Explained — the short cycle and tight feedback that keep the increment honest.
Schwaber, K. & Sutherland, J. — The Scrum Guide — sprint → review → retrospective: the owned stages of one iteration.
Hunt, A. & Thomas, D. — The Pragmatic Programmer — feedback as the mechanism that corrects course.

Related in this course

A1.03.1 · The two roles — the line each stage hands across.
A1.03.3 · Adapt: feedback edits the spec — the next dive.
A1.03 · The Author/Operator loop — the module hub.
A1.01.1 · Vibe coding — the failure that returns without sharpen or review.
A1.01.2 · Big-bang specs — the drift that returns without feedback.
A1 · Why an agile agent workflow — the chapter.