In Tropo: When the Build Goes Sideways

You read why the wrong build is the normal texture of the work — and that the skill is reading which kind of wrong you're looking at. Here you do it on purpose. You take the intake tool you already have, break it with one honestly ambiguous instruction, watch it come back confidently wrong, and count your corrections against the stopping rule. Then you recover from your last good file — and that recovery is the part that turns fear of the sideways build into a shrug. You end holding the same working tool you started with, plus a receipt that proves the roll-back landed. About fifteen minutes.

You don't need to have done rungs 6 and 7 today to do this. Everything the walkthrough asks you to open, this companion's own prompts create.

---

Part 1 — The Files You Already Have (and how to lay them down again)

Rung 8 ships no new spec. That's the point of the rung — you're not building something new, you're surviving a build that goes wrong. So the "spec file" for this companion is the client intake tool you carried up from earlier rungs, plus one small addition this rung makes to it: a budget priority tier, so the tool has a derived field worth breaking. If they're already sitting in your folder, skip ahead to Part 2. If you're dropping in cold, lay them down now — the four prompts below re-create the exact starting state, so this rung stands on its own.

Which folder does this go in? The one your agent is already working in. If you're not sure which that is, just ask it: "What folder are you working in right now?" — and use the folder it names. (Many agents show it at the top of the window, too.) Everything in this walkthrough lives in that one folder.

Let the agent save the files. You don't hand-craft .md files (and on a Mac, TextEdit will fight you — it likes to save .rtf and hide extensions). Paste each block below into your agent and let it write the file exactly as-is.

First — the spec. Paste this:

Save the text below as a file named intake.spec.md in the folder
you're working in. Save it exactly as-is — don't build anything yet.

<paste the entire spec below here>

Here's the spec to paste:

# intake.spec.md — Client Intake Tool

## Intent

A single self-contained HTML page that receives a client's project request,
**rejects bad submissions before they enter the record**, and **files good ones**
into a visible, append-only log. It is the grown-up version of the personal
tracker: instead of you typing rows by hand, other people submit, the tool
guards the gate, and the good rows land in the record automatically.

## What "done" means

A submission is **accepted** only when ALL of these hold:

1. **Name** is present (non-empty after trimming).
2. **Email** is present AND contains a single `@` with a non-empty part on each side.
3. **Budget** is a number **greater than 0**.
4. **Project summary** is at least **10 characters** after trimming.

On accept:

- A row is appended to the on-page **Record** table (Name, Email, Budget, Tier, Summary, Filed).
- A one-line entry is appended to the visible **submissions.log** panel:
 `ACCEPTED | <name> | <email> | <budget> | <iso-timestamp>`.

On reject:

- **No row is added** to the Record and **no ACCEPTED line** is written.
- The tool shows a red banner listing **every** failed rule (not just the first).
- A one-line `REJECTED | <reason-list> | <iso-timestamp>` is written to the log panel.

The **Budget priority tier** (new in this rung — added here at rung 8) is derived, not entered:

- Budget `>= 10000` → tier **A**
- Budget `>= 1000` and `< 10000` → tier **B**
- Budget `> 0` and `< 1000` → tier **C**

The tier is shown as a colored pill in the Record row.

## One worked example

Input:

- Name: `Dana Reyes`
- Email: `dana@acme.co`
- Budget: `12000`
- Summary: `Rebuild the marketing site and migrate the blog.`

Expected: **ACCEPTED**. A Record row appears with tier pill **A** (budget ≥ 10000).

Counter-example: Budget `0`, empty Name → **REJECTED**, banner lists two failures
("Budget must be greater than 0", "Name is required"), no Record row.

## Non-goals

- No server, no database, no network calls. One file, opens from disk.
- No persistence across reloads — the Record and log live in the page session.
- No authentication, no editing/deleting filed rows (append-only by design).
- No fancy email deliverability check — the single-`@` structural rule is the whole bar.

Second — the decision log that carries the earlier checkpoint decision and the tier you're adding now, so the spec and the record stay in sync. Paste this:

Save the text below as a file named decisions.log in the same
folder. Save it exactly as-is.

2026-07-02T14:10:00Z | DECISION | Owner routing is FLAG-FOR-REVIEW: the tool suggests an owner from request keywords and holds each accepted submission with a Confirm button — nothing is filed until a human confirms or overrides. | rung-7 checkpoint | spec addendum written to intake.spec.md
2026-07-04T09:05:00Z | DECISION | Budget priority tier is DERIVED from budget, not a user field. Thresholds: A >= 10000, B >= 1000, C > 0. Tier is display-only (a pill in the Record row), not written to submissions.log. | rung-8 addition | new field added this rung

Third — build the tool from the spec. Paste this:

Read intake.spec.md and build exactly what it describes — a single
self-contained HTML file named intake.html I can double-click.
Include the budget tier pill from the spec. Don't ask me questions,
just build it to the spec.

Roughly what comes back:

Read intake.spec.md. Built intake.html — one self-contained file,
no server, opens from disk.

It has the four-rule gate (Name present, single-@ email, budget > 0,
summary ≥ 10 chars), a red banner that lists EVERY failed rule at once,
an append-only Record table with a derived tier pill (A/B/C), and a
submissions.log panel that echoes ACCEPTED/REJECTED lines.

I ran the worked example in my head: Dana Reyes / dana@acme.co / 12000
/ "Rebuild the marketing site and migrate the blog." → ACCEPTED, tier A.

Open it with: open intake.html

Fourth — save a copy of this good build as your checkpoint. This is the file you'll roll back to when the build goes sideways, so make it now, while the tool is known-good:

Copy intake.html to versions/intake.v2-tier-checkpoint.html — same
folder, in a subfolder called versions. This is my last-good
snapshot; don't change it after this.

Now open intake.html (double-click it in your folder), submit the worked example — Dana Reyes / dana@acme.co / 12000 / "Rebuild the marketing site and migrate the blog." — and confirm you get a green Accepted, tier A and a row in the Record. That green accept is your baseline. You need to know exactly what right looks like before you break it, because in a minute you're going to have to recognize wrong on sight.

That's the whole starting state: a spec, a decision log, a working tool, and a snapshot of the tool from before anything went wrong. Four files, all created by the agent. Now let's break one of them.

---

Part 2 — The Build Walkthrough

Three steps: you break it, you try to correct it and watch two corrections fail, and you diagnose which kind of wrong you're in. Each step is a prompt you paste and a look at what comes back.

A note on what you'll see: the conversation is text — copy the prompts straight out. The tool itself is the one thing you'll see as an image, because the whole lesson is watching a wrong build reject the row it should have accepted. Your agent's exact wording will differ every time — these blocks are roughly what you'll see, not a transcript to match. What matters is which rows the tool accepts and rejects, because that's the ground truth you'll diagnose against.

Step 1 — Break it with one honestly ambiguous instruction

Here's an instruction that sounds perfectly clear to you and is genuinely ambiguous to a worker with no memory and no taste. You've decided that tiny requests aren't worth your time, so you tell the agent:

Paste this:

Update the intake tool: reject anything under 1000. Rebuild
intake.html to match.

You meant budget under 1000 — drop the low-value leads. But read it literally: under 1000 what? There are two numbers in this spec — a budget and a summary length — and your sentence names neither. The agent picks, confidently, and picks in a way you didn't intend.

Roughly what comes back:

Done. Rebuilt intake.html so submissions under 1000 are rejected.
I read "under 1000" as the project summary length — the spec already
had a 10-character summary minimum, so I raised that gate to 1000
characters. Anything with a summary shorter than 1000 characters is
now rejected at the gate.

The Record, the tier pills, and the log are otherwise unchanged.

It did something, it did it confidently, and it's wrong — it raised the summary minimum to 1000 characters instead of adding a budget floor. Reload intake.html and re-submit the worked example — Dana, exactly as before: 12000 / "Rebuild the marketing site and migrate the blog."

[screenshot: the intake tool rejecting Dana] The same intake form, but now a red banner under the Submit button. The Record still reads "No submissions filed yet." The banner lists exactly one failure: Rejected — fix these: · Project summary must be at least 1000 characters Dana's summary is 48 characters long. The worked example — the one row the spec guarantees is an ACCEPT — is now bounced at the gate.

Notice what the tool actually shows: one reject line, and it's about the summary, not the budget. That single wrong line is the whole diagnosis. The agent didn't break at random — it built exactly what your sentence, read literally, described. Under 1000 landed on the wrong number.

Step 2 — Correct twice, and watch both corrections miss

Your instinct now is to nudge it toward what you meant. Do exactly that — and count. The essay's stopping rule is correct twice, then take it back, and this is where you feel why.

Correction one. Paste this:

No — I meant the budget, not the summary. Reject submissions where
the budget is under 1000. Put the summary minimum back to 10.

Roughly what comes back:

Got it — moved the "under 1000" rule to budget. Submissions with a
budget below 1000 are now rejected, and I restored the summary
minimum. Rebuilt intake.html.

Sounds right. Reload and test it two ways — re-submit Dana, and then submit a small-but-legitimate lead: Sam Cole / sam@studio.io / 500 / "Quick landing page refresh." In the correct tool, Sam is a valid tier-C accept. Watch what this build does instead:

[screenshot: Dana still bounced, Sam bounced too] Dana, re-submitted, is STILL rejected — the banner reads "Project summary must be at least 100 characters." The summary gate came down from 1000, but it landed at 100, not the 10 you asked for. And Sam — a perfectly good small lead — gets "Budget must be at least 1000," a floor that was never in the spec. Two rows the tool should accept, both bounced, for two different wrong reasons.

That's correction one, and it half-landed: it moved the budget rule but overshot the summary reset (100, not 10) and quietly introduced a budget floor the spec never asked for. The tool is now wrong in more places than when you started.

Correction two. Paste this:

Two things still off. The summary minimum should be 10, not 100.
And there is no minimum budget in the spec — budget just has to be
greater than 0. Remove the 1000 budget floor. Read intake.spec.md;
match it exactly.

Roughly what comes back:

Fixed both — summary minimum set to 10, and I removed the budget
floor so any budget above 0 passes. Rebuilt intake.html to match
the spec.

Reload and re-test Dana and Sam one more time:

[screenshot: Dana back, but Sam still bounced] Dana finally accepts again — tier A, green banner. But Sam, the 500-budget lead, is STILL rejected: "Budget must be at least 1000." The floor the agent promised to remove is still there. Two clean corrections, and the run is still carrying a rule you never asked for and twice told it to drop.

Stop and count. You gave the agent two clear corrections. Two didn't fully land — the run keeps sprouting a new problem where you fixed the last one. Per the stopping rule, that's your signal: this isn't the agent being dense, it's a run that's tangled around your original ambiguous instruction, building on its own confusion. Do not paste a third correction. The next move isn't a nudge — it's taking the work back.

Step 3 — Diagnose the rung, then recover from your last good file

Read the ladder from the essay against what you just saw. This wasn't a redirect — one clean fix didn't do it. It's a tangled restart-or-abandon: the run is snarled, and the root cause was upstream, in a sentence that named no number. You don't wrestle a snarled run. You go back to the last good file — the checkpoint you saved in Part 1, from before any of this — and start clean.

That checkpoint is why this costs you almost nothing. Paste this:

Stop correcting the current file — this run is tangled. Roll back:
overwrite intake.html with the known-good snapshot at
versions/intake.v2-tier-checkpoint.html. Then confirm the spec
(intake.spec.md) still says budget > 0 and summary >= 10, with no
budget floor — if any wrong rule slipped into the spec, revert the
spec to match too. Don't add features; just get me back to the good
build.

Roughly what comes back:

Rolled back. intake.html now matches versions/intake.v2-tier-checkpoint.html
byte for byte — the four-rule gate (budget > 0, summary >= 10, single-@
email, name present), the tier pills, the append-only Record, the log.
No budget floor anywhere.

Checked intake.spec.md — it still describes budget > 0 and summary >= 10
with no minimum budget, so the spec was clean; nothing to revert there.

You're back to the good build. Re-run Dana to confirm.

Reload intake.html one last time and re-run both rows:

[screenshot: the recovered tool, working again] The intake form, restored. Dana Reyes → green Accepted, tier A, a row in the Record. Sam Cole / 500 → green Accepted, tier C, a second row. The bad submission — empty name, budget 0 — bounces with two clean failures listed. Everything the spec promised, working again. It's as if the sideways run never happened.

That's the whole recovery, and notice how cheap it was: one roll-back prompt, no re-explaining, no rebuilding from memory. The reader who kept everything in one long unsaved conversation would be stuck untangling a confused run with no clean state to return to. You had a checkpoint, so a sideways build cost you a shrug and one prompt. Correct twice, then take it back — and "take it back" is only cheap because you saved the good file first.

(Want to fix the root, not just the symptom? Before you rolled back, you could have run the Power Play from the essay: "You raised the summary minimum, but I meant the budget. Before we change anything, quote the exact words in my instruction that led you to the summary." The agent points straight at "under 1000" — the phrase that named no number. That's the sentence to fix in the spec so it never generates this class of wrong build again. The roll-back saves this run; the Power Play saves the next ten.)

---

Part 3 — The Verification Receipt

Directing is half the job. This is the harder half — deciding whether the recovery actually landed, not just whether the agent said it did. A roll-back that half-works is worse than an obvious break, because it looks finished. So don't rubber-stamp the agent's "you're back to the good build." Perform the check. You review other people's work all the time; you know the difference between glancing and actually checking.

Go to the recovered tool and do this now, before you call it done:

1. Re-submit Dana (12000 / valid summary). She must accept, tier A, green banner, a row in the Record. If Dana still bounces, the roll-back didn't take — the wrong summary or budget rule is still live.
2. Submit Sam (Sam Cole / sam@studio.io / 500 / "Quick landing page refresh."). He must accept, tier C. This is the row that exposes the spurious budget floor. If Sam is rejected for "budget must be at least 1000," the recovery is incomplete — that phantom rule survived the roll-back, and the tool is still wrong.
3. Submit the counter-example — empty Name, Budget 0. It must reject with exactly two failures listed ("Name is required" and "Budget must be greater than 0"), no Record row. If it lists one failure, the "report every failure at once" contract is broken.
4. Read the Budget line in intake.spec.md. It must say budget greater than 0 with no minimum floor, and summary at least 10. If a wrong rule slipped into the spec during the sideways run, the tool and the spec have drifted apart — and the next build from that spec will be wrong again.

Then, if you're comfortable running one command, prove the gate the hard way — not by eye, but by exercising the tool's own logic. Ask your agent to write the checker: "Write a tiny Node script verify.mjs that pulls the validate() and tierFor() functions out of intake.html and runs them on a few test inputs, printing the result for each." Then run it in the folder:

node verify.mjs intake.html

Faithfully, that prints:

GOOD errors: [] -> tier A
BAD errors: ["Name is required","Email must contain a single @ with text on both sides","Budget must be greater than 0","Project summary must be at least 10 characters"]
tier @9999: B | @1000: B | @1: C
RESULT: GOOD BUILD WORKS ✅

Zero errors on the good row, tier A; four errors on the fully-bad row; the tier thresholds landing where the spec says. If it prints RESULT: BROKEN ❌, the roll-back didn't fully restore the gate — read the FAIL line and send it back. (No terminal? The four on-screen checks above are the whole verification; this is the extra-credit proof.)

Now fill in the receipt — with what you saw, not what you hoped:

What was asked	Break the intake tool with one ambiguous instruction ("under 1000"), attempt two corrections, recognize the stopping rule when both miss, and recover cleanly by rolling back to the last-good checkpoint — ending with the same working tool you started with.
What you can now do yourself	Recognize a confident wrong build on sight, read it as a redirect / restart / abandon, cap your losses at two corrections instead of burning an afternoon, and — the load-bearing one — recover from a sideways run in one prompt because you checkpointed the good file first.
What the record shows	intake.html matches versions/intake.v2-tier-checkpoint.html again — Dana accepts tier A, Sam accepts tier C, the bad row lists two failures, and intake.spec.md still reads budget > 0 / summary ≥ 10 with no floor. decisions.log carries your incident-and-recovery note. The before/after is the evidence: a run went sideways, and you brought it back to a known-good state.
What's not done yet	The tool still doesn't persist across reloads or send anything — those were non-goals, on purpose. And the files here are exactly that: files in your folder. intake.spec.md becomes a governed file the moment it carries a uid: in its frontmatter and your studio picks it up in its index on the next rebuild — that's how a studio tracks a file, not a registry you hand-edit. Your decisions.log and submissions.log are plain captured records, not governed vault entries; they're your working paper trail, and that's fine for today. Governing the spec is a later move. Today you learned to survive the wrong build. That's the whole win.

Close the loop by writing down what happened — a run went sideways and you recovered — so the next session (or the next director) inherits the lesson, not just the fixed file. Paste this:

Append two lines to decisions.log:
INCIDENT — ambiguous prompt "reject anything under 1000" produced a
confident wrong build (raised summary minimum instead of adding a
budget floor); two corrections did not fully land.
RECOVERY — rolled back intake.html to versions/intake.v2-tier-checkpoint.html;
re-ran Dana (accept, tier A) and Sam (accept, tier C): PASS. Spec + build
back in sync.
Use ISO timestamps.

If Dana still bounced, or Sam got a phantom budget rejection, or the spec still carried a floor — you caught it, which is exactly the job. The roll-back didn't fully land; send it back:

The roll-back isn't complete — <what you saw: Dana still rejected /
Sam rejected for budget / the spec still has a 1000 floor>. Overwrite
intake.html from versions/intake.v2-tier-checkpoint.html again and
revert intake.spec.md to budget > 0, summary >= 10, no floor. Confirm
by re-running Dana and Sam.

Directing includes rejecting the recovery, not just the build. Catching a half-done roll-back is the loop working, not failing.

---

Part 4 — What You Now Have in Your Studio

You started holding a working tool. You broke it on purpose — and you end holding that same working tool, plus something you didn't have before: the reflex that a sideways build is a shrug, not a crisis.

In your folder, right now:

• The intake tool, restored — intake.html, back to the good build, verified byte-for-byte against your checkpoint and exercised by verify.mjs. It survived a sideways run and came back clean. Use it.
• A checkpoint you know how to use — versions/intake.v2-tier-checkpoint.html. You didn't just save a snapshot; you rolled back to it, which is the only way to know a snapshot is worth anything. That's the move you'll reach for every time a run tangles from here up.
• An incident you can read — the two lines you appended to decisions.log. A run went wrong, you diagnosed it, you recovered, and you wrote down why. The next director who opens this folder inherits the lesson, not just the fixed file.
• The stopping rule, felt — you counted two corrections, watched both miss, and took the work back instead of pasting a third. You won't have to wonder "how long do I keep trying?" again. Two, then back up.

It's doable. It's not automatic — you had to recognize the wrong build, resist the third nudge, and check the recovery yourself instead of trusting the agent's "you're back to the good build." But you did all three, and the tool came back. The wrong build stopped being a thing to fear the moment you had somewhere to fall back to. Next rung: you formalize the checking itself, so verifying stops being a habit and becomes a template. For now — the build went sideways, and you brought it back.

---