In Tropo: Your First Checkpoint

You read why the checkpoint turn is the one to sharpen — that a gate asks "proceed?" and a decision point asks "how?", and that the choice you make at the pause shapes what happens next instead of just allowing it. Here you do it. You take a working intake tool, run a build that pauses at a real decision point, pick one of three options laid out for you, and have the agent write your choice down so it outlives the session. You end holding a tool that routes submissions the way you decided — and a decision log that wrote itself. About twenty minutes.

You'll build the whole thing here from scratch, so you can drop straight into this rung. Nothing carries over from an earlier rung that this walkthrough doesn't create for you.

Part 1 — The Spec File

Here's the spec. You're borrowing a good one again so you can watch the checkpoint turn run once, end to end, without also learning to author it. Read it. Notice it has two halves: a baseline that says what the tool already does, and an addendum that a build checkpoint fills in later — the addendum's routing behavior is written in the option you're going to choose, not decided in advance. That's the shape of a decision point on the page: a hole in the spec that your choice fills.

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.

Getting the spec into a file — the easy way. You don't need to hand-craft a .md file (and on a Mac, TextEdit will fight you — it likes to save .rtf and hide extensions). Let the agent do it. Paste the whole spec below into your agent and say:

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

<paste the entire spec here>

That's it — the spec is now a real file in your folder, created by the agent, spelled correctly, no extension surprises. (If you'd rather make the file yourself and you're comfortable doing it, go ahead — the result is the same.)

Here's the spec to paste:

# intake.spec.md

*Governed spec for the client-intake tool. This file is the source of truth: the build follows the spec, not the other way around.*

## Intent

A single-page tool that receives client submissions, catches bad ones before
they enter the record, and files the good ones into a plain-text log. It is the
machine-written, team-facing version of the personal tracker.

## What "done" means (baseline)

A submission is one row: **name**, **email**, **request**. The tool must:

1. Show a form with those three fields and a Submit button.
2. **Validate before filing.** A submission is *rejected* if:
 - name is empty, OR
 - email has no `@`, OR
 - request is under 10 characters.
 Rejected submissions show an inline reason and are NOT filed.
3. **File accepted submissions** as a log line appended to the on-screen log,
 in the exact `submissions.log` format below.
4. Show a running count of accepted vs. rejected.

## submissions.log format (one line per accepted submission)

```
<ISO-8601 timestamp> | ACCEPTED | <name> | <email> | <request>
```

## Worked example

Input: name `Dana Reyes`, email `dana@acme.co`, request `Need a Q3 landing page`.
All three checks pass →

```
2026-07-04T14:02:11Z | ACCEPTED | Dana Reyes | dana@acme.co | Need a Q3 landing page
```

Input: name `Dana Reyes`, email `dana-acme.co` (no @), request `hi` →
rejected, inline reason "email must contain @", nothing filed.

## Non-goals

- No server, no database, no network calls. One self-contained HTML file.
- No editing or deleting a filed submission (append-only record).
- No auth, no user accounts.
- No styling beyond a clean light theme.

---

## Addendum — Owner routing (new capability, decided at a checkpoint)

*Left deliberately blank below the "Routing behavior" heading. The build will
pause here and ask you which routing behavior to build. Your choice fills this
addendum in — and the choice, plus its reason, gets written to decisions.log.*

### Intent
Every accepted submission gets an **owner** so it lands on the right person's
desk instead of a shared pile.

### Routing behavior
*(chosen at the checkpoint — see the build walkthrough)*

### submissions.log format (adds an owner column)
```
<ISO-8601 timestamp> | ACCEPTED | <owner> | <name> | <email> | <request>
```

### Worked example
Request `Rebuild the pricing page` → keyword "pricing"/"page" → suggested owner
`web` → filed as:
```
2026-07-04T14:22:09Z | ACCEPTED | web | Dana Reyes | dana@acme.co | Rebuild the pricing page
```

### Non-goals (unchanged)
Routing is a suggestion, not auto-send. No notifications, no owner accounts —
`owner` is just a string in the log.

That's the whole spec. The baseline half is settled. The addendum half has a hole in it, on purpose — the routing behavior is the decision you're about to make at a checkpoint. You already write briefs with an open question in them for the room to settle. This is the same instinct, aimed at an agent.

Part 2 — The Build Walkthrough

Three turns. First you build the baseline tool. Then you run a checkpointed build that stops at the routing decision and hands you real options. Then you pick one and have your choice recorded. Each turn is a prompt you paste and a look at what comes back. The prompts below are the ones that produced the tool in this walkthrough — they work as written.

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 its whole point is that it's visual and it's yours. And one honest caveat about the replies below: 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 the behavior, not the phrasing. Tropo runs the same way across tools; the words matter, the chrome doesn't.

One thing to be clear about up front, because it's the difference between magic and confusion: the log you'll see is an on-screen log. The tool is a single HTML file you double-click open, and a page opened that way can't write files to your disk — so the accepted submissions it "files" appear in a log area on the page, held in memory for that session. The format matches the submissions.log file exactly, which is the point: the tool speaks the record's language. But don't go hunting your folder for a submissions.log that grew — it didn't. The record you're watching build is on the screen.

Step 1 — Build the baseline tool

The spec is now saved as intake.spec.md. First, build the settled half — the baseline intake tool, before any routing. You're not writing it; you're handing off a clear ask and letting the agent run.

Paste this:

I dropped a spec in this folder called intake.spec.md. Build the
BASELINE only — the "What done means (baseline)" section — as a
single openable HTML file named intake.html I can double-click.
Ignore the Owner-routing addendum for now; we'll decide that at a
checkpoint next. Don't ask me questions, just build the baseline
to the spec.

Roughly what comes back:

Built intake.html — one self-contained file, no server, nothing to
install.

It has the three-field form (Name, Email, Request) and a Submit button.
On submit it validates:
 · empty name → rejected
 · email with no "@" → rejected
 · request under 10 chars → rejected
Rejected submissions show an inline reason and are not filed. Accepted
ones get appended to the on-screen log in your submissions.log format:
 <timestamp> | ACCEPTED | <name> | <email> | <request>
There's a running Accepted / Rejected count above the log.

Open it with: open intake.html

Now open it. Find intake.html in your folder and double-click it — it opens in your browser. Type a good submission (a name, an email with an @, a request of ten characters or more) and hit Submit — you'll see a line appear in the log area and the Accepted count tick to 1. Try a bad one (drop the @) and you'll see the inline rejection and the Rejected count move instead.

[screenshot: your working intake tool, baseline] A clean light card on a #fafafa page, max ~640px wide. A heading "Client Intake," a form with Name, Email, and Request fields and a blue Submit button. Below it, "Accepted: 1 Rejected: 1," and a grey monospace log box showing one accepted line: 2026-07-04T14:02:11Z | ACCEPTED | Dana Reyes | dana@acme.co | Need a Q3 landing page.

You made that happen with a hand-off. Now comes the turn this rung is about.

Step 2 — Run the checkpoint: pick how, not whether

Here's the whole point of the rung. You're going to ask the agent to build the Owner-routing addendum — but instead of letting it run to the end and asking you to approve what it did (a gate), you tell it to stop at the routing decision and give you the real options (a decision point). Then you choose, and your choice — not the agent's default — is what gets built.

Paste this:

Now the Owner-routing addendum in intake.spec.md. Don't build it yet.
There's a real decision here: HOW should an owner get attached to an
accepted submission? Stop and give me the actual options in plain
language — not "proceed?" — with a one-line tradeoff for each, and
wait for me to choose before you build anything.

Roughly what comes back — notice it's a fork, not a yes/no:

Good call to pause here — how routing works is a judgment call, not a
detail. Three real options for attaching an owner:

 1. Auto-route. The tool guesses an owner from keywords in the request
 (e.g. "pricing page" → web) and files it immediately.
 Tradeoff: fastest, zero clicks — but silent, and a wrong guess
 lands in the record before anyone looks.

 2. Ask each time. On every accepted submission, the tool stops and
 asks you to type or pick the owner before filing.
 Tradeoff: always correct — but it nags on every single one, even
 the obvious ones.

 3. Flag for review. The tool suggests an owner from keywords AND holds
 the submission with a Confirm button, so a human accepts the guess
 or overrides it before it's filed.
 Tradeoff: keeps a human in the loop without blocking — one extra
 click, and nothing is filed until you say so.

Tell me which one and I'll build it, update the addendum to match, and
record the decision.

That is the difference the essay named. A gate you could answer without reading. This you can't — you have to actually weigh three tradeoffs to pick one. The structure of the question does the work.

Choose. For this walkthrough, pick flag for review — it keeps you in the loop without nagging on every row, and it's the most interesting to verify. Paste this:

Go with option 3, flag for review. Build it: on an accepted submission,
suggest an owner from the request keywords, show it in a hold state with
a Confirm button, and only file on Confirm. Update the addendum's
"Routing behavior" section to describe exactly this. Heads up — this
touches three places: the submit handler (hold instead of file), the
new hold UI, and the log-line format (add the owner column). Get all
three consistent.

That last line matters, and it's the honest catch of this build. Flag-for-review isn't a one-spot change — it's a multi-touch change. The agent has to (a) change what Submit does so it holds instead of files, (b) add the whole hold-and-Confirm card that wasn't there before, and (c) add an owner column to the log line. If any one of those three lags behind, you get a tool that looks done and is quietly wrong — which is exactly what Part 3 catches.

Roughly what comes back:

Built option 3, flag-for-review. Changes:

 · Submit no longer files. A valid submission is now HELD: the form
 hands off to a review card instead of writing to the log.
 · New hold card: shows the name, email, and request, plus a
 "Suggested owner" dropdown pre-set from the request keywords
 (page/landing/pricing/site → web; logo/brand/identity → brand;
 everything else → general). You can override it in the dropdown.
 · "Confirm & file" is the only thing that files. On Confirm the line
 is appended to the on-screen log WITH the owner column:
 <timestamp> | ACCEPTED | <owner> | <name> | <email> | <request>
 · Updated intake.spec.md's addendum "Routing behavior" to describe
 flag-for-review exactly, so the spec and the build agree.

The baseline validation and counts are unchanged. Reload intake.html
to see it.

Reload intake.html in your browser. Submit a valid request that mentions "pricing" or "landing page" — instead of filing straight away, a hold card appears with web pre-selected as the suggested owner and a Confirm button. Only when you hit Confirm & file does the line drop into the log, now with the owner in it.

[screenshot: your intake tool, now holding a submission for review] The same light card. Below the form, a pale-amber hold card headed "Needs review before filing," showing the pending submission's name, email, and request, a "Suggested owner:" dropdown reading web, and a green "Confirm & file" button. The log below is still empty — nothing is filed until Confirm.

You didn't approve what the agent chose. You chose, from real options, and the build followed your choice. That's the checkpoint turn.

Step 3 — Have the decision recorded

Here's the quiet second prize the essay promised: the choice you just made is a decision with a reason, and if you have the agent write it down as it happens, it outlives the session. Next month a new build inherits your judgment instead of re-asking a settled question.

One honest note on what this file is. decisions.log is a plain-text record you're keeping in your work folder — a captured trail of what you decided and why. It is not a governed vault entry, and writing it doesn't "govern" anything; it's a log you can read back later. (Turning a file into something your studio governs and tracks is a different move — see the last section for what that actually takes. A .log sitting in a folder isn't it.)

Paste this:

Record the routing decision. Create decisions.log in this folder if it
doesn't exist, and append one line in this format:
 WHAT (the choice) | WHEN (ISO-8601 timestamp) | WHY (one line)
The choice was flag-for-review. Write the WHY in your own words from the
tradeoffs you laid out. Then show me the file.

Roughly what comes back:

Appended to decisions.log:

routing = flag-for-review | 2026-07-04T14:20:33Z | auto-route is silent
and hard to trust on day one; ask-each-time nags; flag-for-review keeps
a human in the loop without blocking

That's the checkpoint decision on the record — what was chosen, when, and
why. New line appends here each time you make a call like this.

Open decisions.log in your folder and read the line. That's your decision log, started. It's a plain file the agent can add to and read back — every future fork appends one more line.

Part 3 — The Verification Checklist

Directing is half the job. This is the harder half — deciding whether what came back is right, not just whether it exists. "It looks finished" is not "it's correct," and a multi-touch change like flag-for-review is exactly where a build looks finished while one of its three pieces quietly lags. So don't read this as a row of checkmarks to admire. Perform it. You review other people's work all the time; you know the difference between glancing and actually checking.

Go to the reloaded intake.html and do this now, before you call it done:

Submit a valid request that mentions "pricing" or "landing page." The tool must not file it. Instead a hold card should appear with a suggested owner of web and a Confirm button. If it filed immediately with no hold card, the submit handler didn't get the flag-for-review change — piece (a) lagged. Send it back (fix prompt below).
Look at the hold card's suggested owner, then override it. Change the dropdown from web to brand, then hit Confirm & file. The log line that appears must carry the owner you chose (brand), in its own column, right after ACCEPTED: … | ACCEPTED | brand | …. If the owner column is missing, or it filed web even though you picked brand, the log-format piece or the override lagged — piece (c). Send it back.
Submit another valid request but this time DON'T confirm it. While it's held, check the Accepted count and the log. Nothing should have moved — a held submission is not a filed one. If the count ticked up or a line appeared before you confirmed, "nothing is filed until Confirm" is broken.
Submit a bad one (drop the @). It must still be rejected inline with the Rejected count moving, and no hold card. The baseline validation has to survive the addendum untouched. If a bad submission now reaches the hold card, the change bled into the wrong path.
Read decisions.log. One line, in WHAT | WHEN | WHY format, naming flag-for-review. If it's empty or the format is off, the record didn't actually get written — and the record is half the deliverable.

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


What was asked	A client-intake tool: three-field form, validate-before-file, on-screen accepted/rejected log and counts. Then, at a checkpoint: choose how owner routing works from three real options, build the chosen one (flag-for-review), and record the decision.
What you can now do yourself	Run a build that pauses at a real decision point and hand yourself the options instead of rubber-stamping the agent's default; pick one and watch the tool build to your choice; and keep a decision log that writes itself as you go — so next month's build inherits this call instead of re-asking it.
What the record shows	`intake.html` now holds submissions for review with a suggested owner and files only on Confirm, with an owner column in the log line. `intake.spec.md`'s addendum was updated to describe flag-for-review, so spec and build agree. `decisions.log` carries one line: the routing choice, when, and why. The choice, the build, and the reason all line up.
What's not done yet	The log lives on the screen, in that session — a double-clicked HTML file can't write `submissions.log` to your disk (that's a non-goal today; a served or governed version is a later rung). And `decisions.log` is a captured record in your folder, not yet a Tropo file your studio governs and tracks — that upgrade is below. Today you ran the checkpoint turn once, chose from real options, and got both the tool and the trail. That's the whole win.

If a valid submission filed with no hold card, or the owner column was missing, or the owner you overrode to didn't stick, or a held submission got counted before you confirmed — you caught it, which is exactly the job. Send it back:

The flag-for-review flow isn't right yet. It must: (1) HOLD a valid
submission instead of filing it — no log line, no count change until
Confirm; (2) let me override the suggested owner in the dropdown; and
(3) file on Confirm with the owner I chose in its own column, right
after ACCEPTED. Fix whichever of those is off and keep the baseline
validation unchanged.

Directing includes rejecting. That's not the loop failing; that's the loop working.

Part 4 — What You Now Have in Your Studio

You started by handing off a baseline. You end having stood at a checkpoint, picked how the work should go from three real options, and watched the tool build to your call — with the reason written down.

In your folder, right now:

A working intake tool — intake.html, a real tool that catches bad submissions, suggests an owner, holds each one for your Confirm, and files it with the owner attached. Not a demo. It's the team-facing version of the tracker you built at rung one.
A spec that carries your decision — intake.spec.md, its addendum now written to describe the flag-for-review flow you chose. The hole you saw in Part 1 is filled with your judgment.
A decision log that writes itself — decisions.log, one line so far: what you chose at the checkpoint, when, and why. Every future fork appends another. That's the trail that lets next month's build inherit this call instead of re-asking it.
Your receipt — the checklist above, filled with what you actually saw. That habit — checkpoint, then verify with evidence — is the one you carry up every rung after this.

Want the decision log to survive as a real Tropo file your studio governs? That's a small, honest move, and it's worth knowing the truth of it — because it is not hand-editing a registry. A file becomes governed and tracked when it has a uid: in its YAML frontmatter and your studio picks it up in its index the next time the studio rebuilds. Ask the agent:

Turn decisions.log into a governed Tropo file. Give it YAML frontmatter
with a uid you generate (openssl rand -hex 4 — it's random, so generate
a fresh one), keep the decision lines as the body, and tell me the one
command to rebuild so my studio's index picks it up.

The agent generates a fresh random uid — something like <uid> — writes the frontmatter, and names the rebuild step. Then your studio tracks the file by that uid: it shows up in the studio's index (vault/00-index.jsonl) when the rebuild runs. No registry to hand-edit, no line to append yourself — the uid plus the rebuild is the whole gesture. That's how a loose record becomes something your studio remembers across sessions. (One caveat worth stating plainly: the rebuild is not automatic. A governed file is picked up when the rebuild runs, not the instant you save it — so "give it a uid" and "run the rebuild" are two steps, the same way "edit the spec" and "rebuild it" were two steps back at rung one.)

It's doable. It's not automatic — you had to weigh three options instead of clicking approve, and you had to check all three pieces of a multi-touch change yourself. But you did both, and you ended with the tool and the reason it works that way. Next rung: the build goes sideways on purpose, and you practice pulling it back. For now — you didn't hover, you didn't rubber-stamp. You decided at the checkpoint, and the record shows it.