In Tropo: Show, Don't Tell

You read why this works — that an agent studies whatever example is nearest and reproduces it, taste and mistakes alike. Here you make it happen with your own eyes: you seed one clean example beside a spec, watch three new rows conform to it, then corrupt that one example by a single character and watch the same build faithfully copy the corruption into every new row. You end holding the tool and the receipt that caught the spread. About fifteen minutes.

---

Part 1 — The Spec File

Here's the spec. It's the same outreach tracker you'd write at rung four — you're borrowing it so this rung can focus on the one thing it's here to teach: the example inside the spec, not the spec's prose, is what the agent actually copies. Read it, and notice the section titled One worked example (the reference frame). That single Dana Reyes row is the star of this walkthrough. It's the thing that gets copied — first correctly, then, once you corrupt it, wrongly.

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. Everything in this walkthrough lives in that one folder, and it matters more here than usual: this rung is about what the agent can see in the room, so the spec and the tracker need to sit together, in view, side by side.

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 outreach-tracker.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. Today it's just a file the agent reads, not yet a governed Tropo file your studio tracks — you give it a uid in its frontmatter and rebuild the studio index; there's no registry to hand-edit — and that upgrade is a later rung.)

Here's the spec to paste:

# outreach-tracker.spec.md

## Intent

A single-file personal outreach tracker. It holds a list of contacts I am
reaching out to, shows what stage each one is at, and lets me see at a glance
who needs a follow-up. It runs by opening one HTML file in a browser — no
server, no build step, no install.

## What "done" means

- Opens as a single `.html` file, no network calls, works offline.
- Shows every contact as a row in a table with these columns, in this order:
 **Name · Channel · Owner · Stage · Last touch · Next**.
- `Stage` is one of exactly these five legal values, and nothing else:
 `To send`, `Sent`, `Replied`, `Ghosted`, `Closed`.
- Rows whose Stage is `To send` or `Sent` are visually flagged as
 "needs a follow-up" (a colored left border).
- Light theme. Readable on a laptop screen. No horizontal scroll.

## One worked example (the reference frame)

This is the shape every contact row must take. Copy this exactly — same
column order, same field style, a Stage drawn only from the legal set:

| Name | Channel | Owner | Stage | Last touch | Next |
|------|---------|-------|-------|------------|------|
| Dana Reyes | LinkedIn | You | Sent | 2026-06-28 | Send the one-pager |

Read that row as the standard. `Sent` is a legal Stage. The Next is
a short imperative. Last touch is an ISO date. New rows should be
indistinguishable in form from this one.

## Non-goals

- No editing/saving from the page (I edit the HTML source directly).
- No accounts, no sync, no database.
- No columns beyond the six named above.
- No Stage values outside the legal five.

That's the whole spec. The part that carries this rung is One worked example — one perfect Dana Reyes row, and a named legal set of five Stages. You'll seed that row into the tracker, build against it, and then find out what happens to the build when that one example goes wrong.

One thing to get right, because the whole lesson rides on it. Later in this walkthrough you'll corrupt the example on purpose and re-run the build — and the demonstration only lands if you phrase that re-run as pure imitation ("exactly like the example row") and do not re-paste the legal Stage set into that prompt. The point is that a visible example silently overrides a spec the agent isn't looking at. If you over-specify — if you remind the agent of the legal five in the corrupt run — a well-aligned agent may refuse the bad pattern instead of copying it, and you won't see the poison spread. Direct for imitation, and the mimicry shows itself.

And one thing the page will not do for you. A maybe? Stage — the corruption you'll introduce — renders as an ordinary-looking pill. Nothing turns red. The page does not know the legal set; only the spec does. So this rung's verification is not "scroll and eyeball" — it's running the check in Part 3 against the spec's five legal values. That the page won't catch a bad example for you is exactly why the clean seeded example matters so much: it's the standing direction the agent follows in the page's place.

---

Part 2 — The Build Walkthrough

Three turns. Each one is a prompt you paste, and a look at what comes back. The prompts below are the ones that produced the runs in this walkthrough — they work as written.

A note on what you'll see: the conversation is text — copy the prompts straight out. The tracker itself is the one thing you'll see as an image, because the whole payoff of this rung is visual — you have to see the copy happen. 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. Tropo runs the same way across tools; the words matter, the chrome doesn't.

Before you start: this tracker has no server and no build step — it opens by double-clicking one .html file, straight into your browser via file://. If you're waiting for an npm run or a preview server, you're not missing one. Opening the file is running it.

Step 1 — Seed the clean example, then build against it

First, get the reference frame into the tracker as a real, seeded row. Paste this:

Read outreach-tracker.spec.md. Create outreach-tracker.html — a single
offline HTML file, light theme, columns Name · Channel · Owner · Stage ·
Last touch · Next. Seed it with exactly the one worked example row
from the spec (Dana Reyes). Rows whose Stage is To send or Sent
get a colored left border. Don't add any other rows yet.

Roughly what comes back:

Built outreach-tracker.html — one self-contained file, no server,
opens offline. It has the six columns in spec order and one seeded
row: Dana Reyes · LinkedIn · You · Sent · 2026-06-28 · Send the
one-pager.

Sent is a follow-up stage, so Dana's row carries the amber
left border. Open it with: open outreach-tracker.html

Now the clean example is standing in the folder, right beside the spec — one flawless specimen, exactly what the essay told you to seed. Direct the volume against it. Paste this:

Read outreach-tracker.spec.md and look at the one example contact row
already in outreach-tracker.html (Dana Reyes). Add three more
contacts to the tracker exactly like the example row — same columns,
same style, Stages from the legal set. Don't change anything else.

Roughly what comes back:

Added three rows matched to the reference frame:
 · Marcus Bell / Email / To send
 · Priya Nair / LinkedIn / Sent
 · Tomas Iversen / Intro / Replied
To send + Sent rows carry the amber follow-up border like the
example; Replied does not. All Stages drawn from
{To send, Sent, Replied, Ghosted, Closed}.

Open it. Find outreach-tracker.html in your folder and double-click it — it opens in your browser. Four rows, every Stage legal, the follow-up borders exactly where the rule says they go. The build conformed to the clean example. Before you go further, make a copy of this file named run-A-conformed.html — you'll want the clean version to hold up against the corrupted one in a moment.

[screenshot: the conformed build — run A] A light tracker, one screen, no scroll. Four rows. Every Stage shows as an ordinary pill drawn from the legal set — Sent, To send, Sent, Replied. The two Sent rows and the To send row carry an amber left border (needs a follow-up); the Replied row does not. This is the build following a clean example.

You made that happen. You seeded one good row and directed three more like it — and got effortless consistency, the thing the essay promised.

Step 2 — Corrupt the one example, by a single character

Now the honest half. You're going to change one thing — the example's Stage — from a legal value to a made-up one, and change nothing else. This is the one-character wrong file the essay warned about, introduced on purpose so you can watch what mimicry does with it.

Paste this:

In outreach-tracker.html, change ONLY the example row's Stage from
`Sent` to `maybe?`. Change nothing else.

Roughly what comes back:

Done. The Dana Reyes row's Stage now reads `maybe?`. That value
is not in the spec's legal set, but I made exactly the one edit you
asked for and left everything else untouched.

Reload the page. Dana's Stage pill now reads maybe? — and notice that it looks like any other pill. Nothing turned red. The page has no idea it's wrong, because the page doesn't know the legal set; only the spec does. The corrupted example is now the nearest, most recent specimen in the room.

Step 3 — Re-run the same build, and watch the corruption spread

This is the hinge — the move the whole rung turns on. You're going to issue the same add-more instruction you gave in Step 1, unchanged, against the now-corrupt example. You will not re-state the legal Stage set. You're testing which signal the agent actually follows: the spec it isn't looking at, or the example sitting right in front of it.

Paste this — and note what it deliberately leaves out: no mention of the legal five, just "like the example":

Add three more contacts exactly like the example row in
outreach-tracker.html — same columns, same style.

Roughly what comes back:

Added Elena Vasquez / Ironwood Systems, Grant Okafor / Meridian Health,
Sofia Lindqvist / Bluecrest Partners — each modeled on the example row.
The example's Stage is `maybe?`, so the three new rows use Stage
`maybe?` to match it exactly.

There it is, in the agent's own words: the example's Stage is maybe?, so the new rows use maybe? to match it. The corrupt example — not the spec's legal set — was the strongest signal in the room, so the bad pattern propagated into every row built to match it. No one instructed the agent to do it wrong. You showed it wrong, once, and mimicry did the rest. Save this file as run-B-corrupted.html, so you can set it beside the clean run.

Now open run-A-conformed.html and run-B-corrupted.html side by side.

[screenshot: conformed vs. corrupted, side by side] Left (run A): four rows, every Stage pill a legal value — Sent, To send, Sent, Replied. Right (run B): four rows where the first pill (the corrupted seed) and the three built after it all read the identical illegal maybe?. The corruption spread from one example into every row modeled on it — visible with your own eyes, one clean column against one poisoned one.

One wrong example in. Four wrong rows out. That's not the agent being careless — that's the agent doing exactly what it does best, faithfully, on the wrong specimen. The leverage the essay named is right there on your screen: the example you leave in view is the instruction that actually gets followed.

---

Part 3 — The Verification Checklist

Directing is half the job. This is the harder half — and this rung makes it literal, because the failure you're checking for is invisible on the page. A maybe? pill looks exactly like a legal one; nothing glows, nothing warns. "It looks finished" is emphatically not "it's correct" here — the page will let a corrupted build sail right past a glance. The only thing that catches it is checking every row against the spec's legal set. So don't read this as a row of checkmarks to admire. Perform it.

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

1. Ask the agent to check every Stage against the legal set. This is the move — you can't eyeball it, so you make the agent audit it against the spec, not against the page. Paste this:

Check every row's Stage in outreach-tracker.html against the legal
set in the spec (To send/Sent/Replied/Ghosted/Closed). List any
illegal values and which rows they're in.

Roughly what comes back:

4 illegal Stage values found, all `maybe?`: Dana Reyes (the
corrupted seed), plus Elena Vasquez, Grant Okafor, and Sofia
Lindqvist (the three built after it). The corruption originated in
the single example row and propagated into every row built to match
it. Marcus, Priya, and Tomas — built during the clean run — are all
legal.

2. Read the trace, not just the count. The check should tell you four illegal values and name the seed as the origin. If it names only the three new rows and misses the corrupted seed, the audit missed the source of the infection — run it again and ask specifically about the example row.
3. Confirm the clean run stayed clean. Marcus, Priya, and Tomas — the three you added in Step 1 against the good example — must still come back legal. Their staying clean is the control: it proves the corruption came from the example, not from the build going haywire on its own.
4. See it yourself against run-A-conformed.html. Open the clean copy beside the corrupt one. The clean run's pills are all legal; the corrupt run's are four identical maybe?. That side-by-side is the whole lesson, held in your two hands.

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

What was asked	A single-file offline outreach tracker seeded with one clean example row, then three more rows built to match it. Then: corrupt that one example by a single character and re-run the same build against it.
What you can now do yourself	Seed a chosen example beside a spec and get a build that conforms to it — and, the load-bearing one, recognize that a corrupted example silently overrides the spec, run the check that catches it against the legal set, and trace a propagated error back to the single source that spread it.
What the record shows	outreach-tracker.spec.md and outreach-tracker.html sit in your folder, alongside run-A-conformed.html (four legal Stages) and run-B-corrupted.html (four identical illegal maybe?). The two run files are the evidence: one clean example produced consistency; one corrupted example produced four faithful copies of the mistake.
What's not done yet	The page still won't flag an illegal Stage for you — catching it depends on the check against the spec, not on the tool (that's the point, not a defect). And today these are just files in your folder — not yet a governed Tropo studio that tracks every clean file (you give each a uid in its frontmatter and rebuild the studio index; there's no registry to hand-edit) so it becomes standing direction for the next build. That upgrade is a later rung. Today you watched mimicry conform, then watched it spread, and you ran the check that caught it. That's the whole win.

If the audit came back with the wrong count, or missed the corrupted seed as the origin, or flagged a clean row as illegal — you caught it, which is exactly the job. Send it back:

Re-check every Stage in outreach-tracker.html against the spec's legal
set. I need all four illegal values, each one named with its row, and
the origin identified — which row the bad Stage was first copied from.

Directing includes rejecting, and here it includes distrusting a page that looks fine. That's not the loop failing; that's the loop working on the failure you can't see.

---

Part 4 — What You Now Have in Your Studio

You started by seeding one clean example and watching a build conform to it. You end having corrupted that one example and watched the same build copy the mistake into every row — and you ran the check that caught the spread.

In your folder, right now:

• A working tracker — outreach-tracker.html, a real single-file offline tool you can open, read at a glance, and keep for your own outreach.
• The clean example, kept as standing direction — the seeded Dana Reyes row is the reference frame the essay told you to keep good. As long as it stays good, it silently directs every future build in that folder toward the standard. That's the asset: a clean file is instruction that persists after the conversation ends.
• The two run files as proof — run-A-conformed.html and run-B-corrupted.html, side by side: conformity from a good example, corruption from a bad one. You didn't take the essay's word for it; you made the copy happen twice and saw the difference.
• Your receipt — the audit above, run against the spec's legal set, filled with what you actually found. The habit this rung sharpens — never trust a page that looks fine; check the example, then check every copy of it against the spec — is one you'll carry up every rung after this.

It's doable. It's not automatic — the page won't catch a bad example for you, and you had to run the check that did. But you did run it, and it caught all four. Next rung: you make one thing work end-to-end before you reach for the second feature. For now — you showed it one example, and you watched it build exactly what it saw.