A7 · orientation dive 3
How the loop runs here
A7 runs the Author/Operator loop once on the Portal, end to end — the roles unchanged, one production-grade rung shipped before the next.
A6 makes each rung production-grade; A7's run is worth running only because each rung it ships was hardened first. This dive shows the loop running once, uninterrupted: the Operator decomposes, roadmaps, specs, briefs, and accepts; the Author builds and hardens; each rung ships to production quality before the next. Advance the ledger on the right to watch the rungs ship one at a time, the gate held at each.
The rung-by-rung ledger · advance the run
The loop, run once
A7 runs the Author/Operator loop once on the Portal, end to end. The roles do not change. The Operator owns decomposition, judgement, and acceptance; the Author is the fast, well-specified implementer. The loop ships one production-grade rung at a time, in dependency order, until the multi-surface Portal is deployed.
The seven steps are the ones the course taught one at a time: A7.01 decomposes the vision, A7.02 plans the roadmap, A7.03 specs the rung, A7.04 briefs the Author, A7.05 builds the increment, A7.06 hardens it to production, and A7.07 accepts and ships. The difference here is that none of them stops at a worked fragment. Each rung is shipped to production quality before the next begins, so the run never accumulates un-hardened work. The ledger above advances one rung at a time; the gate holds at every rung.
- what runs
- The seven steps A7.01–A7.07, in dependency order, as one uninterrupted loop.
- the rule
- Each rung ships to production quality — STATUS: PASS — before the next begins.
- the Operator
- Owns decomposition, judgement, and acceptance: A7.01–A7.04 and A7.07.
- the Author
- The fast, well-specified implementer: A7.05 build and A7.06 harden.
The per-step internals of A7.01–A7.07 are detailed once the chapter's triad is seeded; this dive runs the loop at roadmap altitude — one composed run, the gate held at each rung.
Who owns each step
The thesis the whole course argues holds across the whole run: a Claude agent is a fast, tireless implementer of well-specified thin slices; the human is the source of decomposition, judgement, and acceptance. Read the run step by step and the ownership is exact. The Operator owns five of the seven steps — the framing and the acceptance; the Author owns the two that turn a brief into production code. Select a step below to report its phase and its owner.
Two lanes · pick a step
Ownership is fixed for the run: the Operator frames and accepts, the Author builds and hardens. The agent implements well-specified work; it does not decide what to build.
On the Portal
The Portal is what makes the run a real run. It is one multi-surface system — a branded store, an event-sourced engine behind one facade, a Phoenix web app, a Telegram bot, and a student dashboard — carried from an empty repository to a deployed platform. The surfaces come up in dependency order: the engine before the surfaces that read it, each shipped to production quality before the next is briefed.
The companion Functional Programming in Elixir course builds those surfaces for
real, with the OTP internals it cites rather than re-teaches; its F6 Phoenix
chapter ships the web surface end to end from a real roadmap. Inside the loop, the increment's boundary
parses untrusted input into a typed value — Portal.ID.generate/1 mints a
branded id, Portal.ID.decode/1 reads its .type and
.timestamp back — and a supervisor isolates a crash so one surface failing
does not take the platform down.
The principle
Run the whole loop once, uninterrupted, shipping a production-grade rung before the next — the Operator owns judgement and acceptance, the Author owns implementation.
On the Portal
The five surfaces come up in dependency order; the Operator decomposes, roadmaps, specs, briefs, and accepts, the Author builds and hardens; the boundary parses untrusted input into a typed value, and a supervisor isolates a crash.
The loop ships one production-grade rung at a time, end to end, with the roles unchanged.
Recap — one composed run, the loop closed
A7 runs the Author/Operator loop once on the Portal, end to end: the Operator decomposes, roadmaps, specs, briefs, and accepts; the Author builds and hardens; each rung ships to production quality before the next. The five surfaces come up in dependency order, from an empty repository to a deployed platform. The roles the course argued for hold across the whole run — the human owns decomposition, judgement, and acceptance, the agent owns the well-specified build. With the run shown end to end, the course returns to its home: the loop is closed.
This is the last dive of the last chapter. The next step returns to the course home — the loop closes where it began, with the whole method demonstrated once on the Portal.
References
Primary sources for running the whole system end to end, the inspect-and-adapt loop run whole, and keeping the result releasable at every rung — and where the moves the loop composes are taught in the course.
Sources
- Humble, J. & Farley, D. — Continuous Delivery — releasable at every increment; the production-quality bar held at each rung.
- Hunt, A. & Thomas, D. — The Pragmatic Programmer — tracer bullets: the system runs end to end, then the backlog fills in.
- Beck, K. — Extreme Programming Explained — the inspect-and-adapt loop, one rung at a time.
Related in this course
- A7 · Portal exemplar — the chapter landing.
- A7 · Why an exemplar — why the whole run is its own Part.
- A3 · The roadmap layer — the delivery move the loop runs second.
- A4 · The spec layer — the definition move the loop runs third.
- A2 · Decomposition — the first move the loop composes.
- Companion · Phoenix (F6) — the Portal's web surface, built end to end.
- Companion · Functional Programming in Elixir — the Portal's Elixir and OTP foundations.