Adapt: feedback edits the spec

One rung runs as a loop, and the dashed return at its end is where the team responds to what it learned. That return is adapt: the Operator and Author take the feedback from the demo and review, and carry it into the next sharpen. The whole arc rests on one rule, and it is the rule the rest of the course defends: feedback edits the spec, never the code directly.

The spec is the single source of truth (A1.02.1). When a change enters through it, the Author rebuilds from the edited spec, and the next rung is correct by construction — the spec still describes the system it specifies. The agent-era danger is the opposite move: an agent will hot-patch the code at the exact spot the feedback landed. Do that and the spec no longer matches the code — the precise DRY drift of A1.02.1, now between the spec and the system. The truth has forked, and every later rung builds on a lie.

Because every change enters through the spec, the spec and the code never fork: drift stays at zero by construction, turn after turn. And because each rung is accepted before the next begins, confidence accumulates — the mirror image of vibe coding's compounding entropy. The loop's product is two things kept in lock-step: a growing set of accepted rungs and a spec refined by every round of feedback.

Step the slider to run the turns forward. The two stacks rise together — one accepted rung and one spec edit per turn — and the drift readout stays pinned at zero, because the feedback never bypassed the spec on the way in. That zero is the whole point: it is what lets correctness, not only output, compound.

Feedback on the Portal — the learning platform this course builds — arrives as a sentence: “ids should also sort by time.” The adapt move edits the spec of Portal.ID — its contract — in one place. The Author regenerates Portal.ID.generate/1 from the edited spec, and every surface that calls it derives the new behaviour, because the id format lives once (A1.02.1). One edit; one rebuild; one truth.

The wrong move is to hot-patch the sort into the store, the bot, and the dashboard — three edits, a forked truth, and a spec that now lies about the code. The id format would live in four places that drift apart on the next change. Use only the established contract: Portal.ID.generate/1 produces the id, Portal.ID.decode/1 reads it back — edit what they promise, not where they are called.

# Feedback: "ids should also sort by time."

# Adapt — edit the spec once: the Portal.ID contract now also promises time order.
#   "a branded id sorts by creation time" → the Author regenerates generate/1 from it.
id_a = Portal.ID.generate(:user)   # earlier ms
id_b = Portal.ID.generate(:user)   # later ms
assert id_a < id_b                  # meets the edited spec → accepted

# Every surface derives it — store, bot, dashboard read Portal.ID, unchanged.
Portal.ID.decode(id_b).type      # => :user  (the contract still holds)

This module set the workflow in motion. Roles: two roles meet on a spec — the Operator decides what and whether it is done; the Author produces how; neither crosses the line. Turn: one rung travels through six owned stages, sharpen to accept, each handed back and forth across that line. Adapt: the return sends feedback back through the spec, never around it, so the next rung starts from a refined and still-truthful contract.

Put together, the loop is the workflow's motion — repeatable, accountable, and compounding, because the spec it turns on never forks from the code. Every later module is a deeper look at one part of this loop: how to decompose a rung, how to write the spec it turns on, how to brief the Author, how to make acceptance cheap. The motion is fixed; the rest is craft.

Primary sources for feedback, embracing change, and the single source of truth — and where adapt connects in the course.