The Two-Speed Engine, applied — one app, built end to end

A real app, taken from a raw brief to a shipped, deployable product entirely through the framework's own tools. This is the worked example: every step, what each tool did, where it helped, where it hit its honest limit — and the improvements the run fed back into the tools themselves. Read it as a walkthrough, not a highlight reel.

The app: Sixty-Four (built under the working title "Mandala Canvas"; Mandal-Art is the method) — it turns one north-star goal into 64 daily, binary habits, laid out on the Ohtani / Mandal-Art 9×9 chart (1 core goal + 8 strategic pillars + 64 actions = 73 nodes) on a flat, normalized data model. The roles: Agent (builds) = Claude · Owner (decides) = a human. Every "the machine did X, the human did Y" below is literal. The self-contained build: examples/mandala-canvas.html — the interactive prototype (Runs A–D), with its executable spec shipping inside the page. Real generation (Run E) and the field-test harness are a separate Node app.

The map — how the pipeline runs

Five moves, in order. Each has a tool, and each tool has exactly one job:

The spine underneath all of it: the machine verifies the executable; the human owns what can't be reduced to a test. Watch that division of labor hold, step by step.

Step 1 · /shape — find the bet; kill the wrong build cheap

The brief arrived detailed and solution-first — a beautiful how with no evidenced why. /shape refused to accept it as-is. It forced two things:

• A falsifiable bet: "a user completes the decomposition and returns to check off ≥1 habit on ≥3 of the next 7 days." Not "users will love it" — a claim reality can prove wrong.
• The riskiest assumption: the brief named dependencies with total confidence — "Astryx by Meta," an on-device LLM — but never proved them.

/shape's rule is probe-or-build: if the riskiest assumption is unproven, run the cheapest test before building. So we did — a two-minute web search. Result: Astryx is real (a Meta release that landed after the reviewer's knowledge cutoff). The probe corrected the reviewer's stale belief, not the brief.

The framework's deepest rule — verify, don't assume; trust reality over authority — held against its own reviewer's certainty. That's the strongest demonstration there is: it works even on its authors.

What you learn here: a brief is a set of bets wearing a suit. /shape undresses it.

Step 2 · /frame — split into Runs (bets), not tasks

/frame split the goal by the Four Ones — one bet, one owner, one test, one scope. It separated three very different bets that the brief had blended together:

• Run A — architecture (buildable now): the flat manifest renders and mutates 73 nodes.
• Run D — demand (deferred, needs real users): people come back.
• Run E — feasibility (deferred, needs real inference): a model can actually generate a good chart.

The scope pass also caught a contradiction the brief had papered over: its named tools were web/React, yet it also claimed native-mobile. Owner's call: build the web prototype; native and inference are later Runs.

What you learn here: you don't estimate the machine's hours, so you stop writing task tickets. You isolate bets, so a human can judge each one and reality can settle it.

Step 3 · /spec — make "correct" executable

/spec turned "correct" into tests that ship inside the app and run live — so "done" can't be argued, only demonstrated. The high-value half was the Miss tests: the plausible-but-wrong failures a visual review would never catch.

• M1 — renders 73 nodes but secretly stores a nested tree (smuggled structure)
• M2 — looks instant, but silently re-renders everything on each change (no real targeted mutation)
• M6 — a pillar shown in two grid cells stays in sync — one flat node, two views

These proved the brief's invisible architecture claim — the thing you can't see on screen but that decides whether the app scales. The spec went 15/15.

What you learn here: a naive test confirms the happy path. The Miss test is where the real coverage — and the real value — lives.

Step 4 · Build → Review → Log — the human owns what no test can

Three build passes. And here is the pivotal fact of the whole exercise: the executable spec passed 15/15 while the UI was wrong three times in a row. Every fix came from the Owner's Review verdict, not from a failing test:

1. redirect → the radial node layout was illegible; rebuild as the 9×9 grid (more legible and truer to the method).
2. hold → differentiate the cells by type so the structure reads at a glance.
3. hold → bigger boxes → the board now scrolls (which surfaced the brief's "infinite canvas" idea organically).
4. ship.

Then Runs B/C/D turned the static mock into a real app: goal input → streaming pillar generation → on-demand action regeneration → check-off, edit, and localStorage persistence.

The central claim, shown live and repeatedly: the machine verifies the executable (15/15); the human owns what can't be reduced to a test — legibility, authenticity, taste. The division of labor wasn't theory. It was the actual sequence of events.

Step 5 · Run E — real generation, the deferred bet made real

Run E was the feasibility bet, first shipped as an honest labeled mock. Later it was built for real: a small Node app whose endpoints call claude-opus-4-8 with structured outputs — the model is constrained to return a valid chart shape at the schema layer (the modern equivalent of the grammar-constrained decoding the brief asked for). The frontend swapped mock → real behind the same interface; the executable spec came along and now runs on live output.

Building it, the spec earned its keep twice — and note what kind of bug it caught: both were structural, not creative, and both were caught before the Owner ever saw them.

• The API client crashed at boot when no key was set — which would have violated the graceful-failure Miss test. Fixed so a missing key becomes a clean error and the server stays up.
• The structured-output helper needed a newer version of a dependency than assumed (a real SDK version drift). Caught by booting the server, not by reading the code.

Then the one test the machine couldn't run itself: the Owner supplied the key and ran the live collision (goal: "start my youtube channel"). Verdict: ship. The surprise reversed the direction of risk. Going in, quality looked like the thing a human would have to iterate on. On the first real generation it landed clean — the pillar mix held, habits were daily and checkable, and the typing was even self-aware (it paired "check daily view stats" with "avoid vanity metric obsession"). The residual danger was never relevance — it was plumbing, exactly what the Miss tests exist to catch.

What you learn here: structured outputs guarantee shape, never taste. And when a task is well-scoped, a strong model can nail relevance first-try more often than you'd guess — which means the human's Review moves from "is it good?" to "is the wiring safe?"

Step 6 · The field test — the one loop code can't close

Everything to this point is a loop the machine can close. The demand bet — do people actually come back? — is not. No amount of building settles it; it needs the app in front of real users for a real week.

So the last step is a Tier-0 field-test harness — the cheapest instrument that can produce the refuting observation:

• An invite gate, per-visitor and global daily caps, and a kill-switch — every one of them running before any paid model call, so a handful of testers can't run up a bill and a bad day can be paused instantly. (The real spend backstop is a billing limit set at the provider, not app code — set one.)
• Two events — chart completed and habit checked — tagged with an anonymous per-browser id, flowing to an analytics tool that draws the 7-day return curve.

The bet, sharpened for a small first cohort: refuted if 0 of ~8 recruited testers return on ≥3 of the next 7 days. Directional at that size, not statistical — and named as such. A couple of genuine returners earns a bigger test.

What you learn here: the framework tells you which loops are the machine's and which are reality's — and it refuses to let a green build masquerade as proven demand.

Step 7 · Turn the last two tools on the machine loop and its metrics

Two tools in the kit hadn't been exercised by the build — /loop-design (the machine/inner loop) and /metric-audit (the dashboard). The honest move is to run them where they genuinely apply and skip them where they'd be theatre — not to fake full coverage. Both applied cleanly.

/loop-design on the generation workflow. The build is a two-stage fan-out — one pillar-generator, then eight parallel action-generators. The audit's finding: the dominant contextual-transaction-cost sink is cross-pillar blindness — each action-generator sees only its own pillar, so two pillars can independently produce overlapping habits. The org-form is sound (the 1→8→64 fan-out is intrinsic to Mandal-Art, not human-imitation waste), and the eight generators are genuine task-partition diversity, not redundant voices — nothing to cut. The lever it surfaced is a trade-off the tool refuses to resolve for you: pass the sibling pillar titles into each call to trade a few tokens for less overlap — worth it or not depending on how much overlap costs you. Here the Owner took the trade, and the machine implemented it: each action call now carries the other seven pillars and is told to keep its habits distinct. That short sequence — the tool surfaces the trade-off, the human makes the call, the machine executes it — is the mesh in miniature. The audit also named the one mandatory-judgment boundary — chart-quality Review — with its answerable owner (the Owner), which the spec panel already makes explicit.

/metric-audit on the field-test dashboard. The events the harness fires — chart completed, habit checked — read like success. The metric test says otherwise: optimising either just produces more output, not better judgment, so they're throughput/funnel and belong on the panel as cost, not score — "200 charts generated" is the new story points. The one metric that survives as a judgment metric is the return rate — of the people who completed a chart, the fraction who come back on ≥3 of the next 7 days: the demand bet itself. The panel the test runs toward: return rate (judgment) · completed-but-never-returned rate (the Miss analog) · cost per returner (unit economics — where the token spend lives, labelled cost). The rule posted on it: the only score that counts is whether people came back.

What you learn here: the framework is honest about its own coverage. Two tools fit this build and two didn't (/practice-audit retires team ceremony a solo app never had; the Run board is a team visual for many Runs in flight). Forcing all nine would be exactly the ritual-for-ritual's-sake the framework exists to kill.

Step 8 · From worked example to real product — and the loop that won't close from a keyboard

Once the app stopped being a demo and started aiming at real users, a second class of learning appeared — and the framework's fingerprints are on all of it:

• The executable spec is for the builder, not the user. The live spec panel (73 nodes, 72 edges, "GBNF") proved the invisible architecture — invaluable to the builder, meaningless to a goal-setter, and actively corrosive to trust in front of a tester. It's dev scaffolding, so we gated it behind ?dev=1. The lesson generalises: the machine's proof of correctness is not the human's product. Green tests belong backstage.
• A chart is a plan; a list is the execution. The 9×9 grid is a superb planning artifact and a terrible daily tracker — nobody performs 64 habits a day. The two speeds made the split obvious: the grid is the rare outer-loop artifact (set once, hang on the wall); a weekly-focus list is the frequent inner-loop surface (a short set you check daily). We built the list as the real return surface — which is where the demand bet actually lives.
• Structure, not sequence. "Should the pillars be dependent?" No — they're habits, not tasks; nothing gets finished, so nothing gates. Independence held; the sequencing people genuinely need ("where do I start?") lives in a soft guidance layer — a suggested focus order the model generates — not hard dependencies. Model the world as it is (parallel habits), not as a Gantt chart.
• Name the product, not the method. "Mandala Canvas" named the method; a newcomer can't decode it. "Sixty-Four" names the promise — one goal, 64 daily habits. Method names are for builders, product names for users: the same builder/user split, applied to branding.

The demand loop — wounded at Calibration, on purpose

We put the still-open demand bet — "a user completes the chart and returns to check off ≥1 habit on ≥3 of the next 7 days" — through a full /judgement-loop. It never reached reality; it got wounded in Calibration, which is the loop working. The strongest objection: Tier-0 runs nudge-less, so a 0-of-8 result wouldn't prove "no demand," only the predictable — a static chart with no reminder doesn't retain. Rather than spend a deploy to learn something you could guess, the loop's own rule fired: break it cheaper first. The current state is a designed 3-tester probe ("would you come back without a reminder?"), not a build — most beliefs should die cheap in argument, not in production.

What the run taught the tools — the deltas

Running the framework through its own Reality Collision produced real residuals, and each one was fed back into the tools (the loop closing on itself):

1. /spec now discloses its coverage gap. Green tests induced over-trust — a spec went 15/15 while the UI was wrong. A less careful operator ships on green. The fix: /spec must state what it does not verify (taste, legibility, UX, the demand bet), making human Review mandatory. "A green spec is necessary, not sufficient." The rebuilt app renders this gap right on its spec panel.
2. /frame now scales to the work. The Four Ones is a gate, not a ceremony — on a one-person job, "one owner" gives no signal, so don't perform it.
3. Run E validated the /spec fix under fire. On real generation, the coverage gap correctly flagged quality as the human's call — and the residual risk turned out to be plumbing, which the Miss tests caught. The fix held; it wasn't stressed only because quality happened to land first-try.

Scorecard

Where it stands — and why we close it here

• Closed (the machine's loops): architecture, real generation, and the product itself — built, verified, shipped as Sixty-Four (full-width readable grid, weekly-focus tracker with guidance, spec panel dev-gated), with a Tier-0 field-test harness ready to run.
• Open, by nature (the human's loop): whether real users return. It's parked at Calibration with a cheap probe designed; it closes with people and a week, not another commit.

We stop here on purpose. Every loop a keyboard can close is closed. The one that remains is reality's to settle — and shipping more features to make it retain would be the exact cognitive-surrender trap the framework names. The sample did its job: it put the framework under sustained load — brief, build, redesign, rebrand, real generation, field test, and a live judgment call — and the framework held, and got sharper, the whole way.

That's the point in one line: the build was never the hard part. The machine's loops close fast; the loops that decide whether the thing matters belong to reality — and the discipline is knowing which is which, and never mistaking one for the other.

Companion to two-speed-engine.md and running-the-engine.md. Same rule: adapt it, measure it, let reality have the last word.