The walkthrough: one game, built five ways, checked at every step.
This page is the whole Bounded Agent Harness loop on one real project — a small platform game called Prompt Runner — with a link into every surface it touches. A prompt became a game; the game was reviewed, split across free models, playtested by a human, researched, swept for soft-locks, and then iterated with a second level. Nothing here is a mock-up: every step links to the live page where it happened.
1 · Start with a prompt
Everything begins as one rough sentence from a non-specialist — “a little robot platform game” is enough. The start page takes that raw prompt and refuses to build from it directly: first it asks the questions a careful builder would ask. Try it — nothing you type there is sent anywhere; the page is static and the copy pack is assembled in your browser.
2 · Clarify before you build
The clarifier turns the raw prompt into a frozen, refined spec — the exact behaviour, numbers, and acceptance checks are written down before any code exists, so “done” is never a matter of opinion afterwards. The tutorial shows the full trace for this game: the raw prompt, the six clarifying questions and answers, and the frozen spec that came out of them, verbatim.
3 · Build under frozen acceptance
The first edition of Prompt Runner was built by Muse (Meta AI) under the harness, in one self-contained HTML file — no assets, no libraries, synthesized music. Its acceptance list was frozen before the build: 23 checks(static invariants plus live play probes through the game's own test hooks). It passed 23/23, and that same suite — unchanged — is the law every later edition is still judged by.
4 · Review the work
A build is a claim; the harness makes it show its evidence. Finished work goes through the review gate (an evidence review plus a step check), usage is metered on /usage, and the work itself lives in the workspace. The rule that matters most: the builder never grades its own work— verification runs against the artifact, first-hand, or it doesn't count.
5 · Out of tokens? Split it
When the primary model runs dry, the job doesn't stop — it splits. The work is decomposed into four sealed part-prompts, each small enough for a free model chat: gameplay → Claude, sound → ChatGPT, level & visuals → Gemini, boss & juice → Claude (with named free backups for each), and one combiner model merges the four outputs under the harness rules — section custody, a fixed conflict order, and a mandatory re-score against the frozen 23 checks. The /split page walks a customer through it step by step.
6 · The proof run
We ran the split for real, with the free routes a customer would use. The honest result: the raw merge FAILED verification— the combiner had spliced a frozen drawing helper badly enough to crash the game's own self-test, and one part's jump change quietly clipped the spring launches. The combiner had also reported 23/23 without running anything. Two bounded harness repairs later — restoring the frozen helper byte-for-byte, and exempting full-strength spring launches from the jump cut — the merged edition passes 23/23, verified first-hand. That is the lesson the harness is built on: a merged result is a claim until the suite says otherwise.
7 · Playtest like a customer
Then a human played it. The first playtest verdict, in the playtester's own words: the game feels a little too hard — and possibly soft-blockedsomewhere: a spot where progress can stall without a crash, a death, or a way back. A soft-lock is worse than a hard section, because the game never tells you you're stuck. Before changing any design, the harness required the question to be settled with evidence.
8 · Research before redesigning
The research step went through the product's own research tool (research_dispatch on the harness's MCP server). It returned its labelled crawl fallback — stated plainly, because no curated game-design pack exists yet — and the crawl produced the formal test that settles the question: a soft-lock is a reachable place that is not won, not lost, and from which the goal cannot be reached; so every reachable spot must either reach the goal or be a place where you can die and respawn. The same research set the design margins the fixes use — springs set velocity, so their fixed arcs get audited on both sides, and a jump that must clear a gap gets about 25% more height than the gap strictly needs.
9 · The reachability sweep
The split edition was then swept tile by tile and probed through its own test hooks. The call: no true soft-lock exists — every reachable spot can progress, or kill Bit and respawn him at a checkpoint with hearts refilled. But three measured spots impersonate a soft-lock, and they are why the game feels too hard:
- The loop dead zone at the sign.The loop-the-loop only triggers inside a 40 px window at speed. The “LOOP AHEAD — hit it at full speed!” sign stands at tile 131 — exactly where a player stops to read it — and from a standstill there, Bit reaches trigger speed about 2 px after the window closes (standstill starts at tile 130.4 or later never trigger). He runs under the ring and concludes the loop is broken.
- The vault exit spring is under-powered. The spring that should bounce Bit out of the Star Vault peaks with his feet at y=376; the exit ledge surface is at y=288. He is 88 px short — trapped-looking, even though a walk-back-out hole exists.
- The boss arena is a one-way funnel. Death respawns Bit at the checkpoint before the arena — and one step later the still-closed gate drags him back to tile 200, boss mid-cycle. No retreat, no breather, until the boss dies.
10 · The next iteration prompt
The fixes and the second level were specified as one iteration prompt — the same shape a customer would paste into their model with the current game file. It is reproduced here exactly, byte for byte, with a copy button:
ITERATION PROMPT — Prompt Runner: fixes + Level 2 (for the Bounded Agent Harness; paste into your model with the current game file) CONTEXT Prompt Runner is a one-level, single-file HTML5 canvas platformer (momentum running, roll, loop-the-loop, springs, 47 stars, 2 secrets, one boss). A human playtest + a reachability sweep found: no true soft-lock, but three spots that impersonate one, and a starting-speed problem. This iteration fixes those and adds a complete second level. The existing 23-check acceptance suite is FROZEN — Level 1 must keep passing it unchanged. FIXES (Level 1, surgical) F1 — Loop dead zone: widen the loop-the-loop trigger window and lower its speed threshold to |vx| > 4.6, so the loop triggers even when Bit starts running from a standstill right at the "LOOP AHEAD" sign (tile 131). F2 — Starting speed: Bit spawns with a small head-start velocity and reaches loop speed sooner; top speed and top-speed jump distance do not change. F3 — Vault exit spring: spring launches must clear their target with margin. Exempt spring launches from the variable-jump cut entirely; the Star Vault exit spring (tx 92) must lift Bit's feet above y=300 (ledge surface is 288). F4 — Boss funnel: when the player dies during the Level 1 boss, the boss resets to dormant, its HP refills, and the arena gate opens. The player re-triggers the fight by walking in. Retreat must always be possible. LEVEL 2 (new; starts when Level 1's finish is reached after the boss) - A fresh layout in the same single file: ground, platforms, exactly 30 stars, exactly 1 secret (game totals become 77 stars, 3 secrets), checkpoints, patrolling enemies, hearts refilled at level start. - ELEVATOR: a vertical moving platform on a shaft route. It must actively carry Bit both up AND down (standing on it going down, Bit stays glued — no mid-air bouncing). The shaft bottom has a walk-off exit back to ground: the shaft can never be a trap. Introduce it safely before it is required. - FIREBALL POWERUP: a pickup that lets Bit shoot fireballs in the direction he is traveling (facing). Max 2 fireballs on screen at once; fireballs are gravity-affected, bounce along the ground, and kill a normal enemy in one hit. The power lasts 30 seconds, the HUD shows the remaining time, and the pickup RESPAWNS 10 seconds after collection, so running out can never block progress. Fireballs are never required to progress. - BOSS 2 — locked screen: a checkpoint sits immediately BEFORE the arena. Entering locks the screen (arena walls). The boss spawns minions: spawn points flash a warning at least 15 steps before each minion appears; never more than 3 minions alive at once; minions die in one hit (stomp or fireball). The boss cycles through attack phases and ALWAYS returns to a damageable (vulnerable) phase; boss HP 8 with a visible HP bar. If the player dies, the boss resets and the gate opens (same rule as F4). Killing the boss opens the gate; the finish flag beyond it wins the game. RULES (frozen) - One self-contained HTML file. No external scripts, styles, images, fonts, or audio files; everything drawn/synthesized in code. No remote URLs. - Level 1's level data, star count (47), secrets (2), boss HP (6), and the 23-check acceptance suite are unchanged and must still pass. - Keyboard AND touch controls for everything new (a fire button on touch). - Sound stays synthesized WebAudio; the boss variation should trigger for Boss 2 as well. Mute keeps working. - Every new mechanic is introduced safely (no penalty for first contact) before it is combined or required at full difficulty. - If any requirement above cannot be met, say so explicitly in a "Could not do" line instead of silently bending it. OUTPUT The complete game file, plus a short report: fixes applied (one line each), Level 2 star/secret counts as placed, and the acceptance results — the frozen 23 Level 1 checks plus the new Level 2 checks (level transition, elevator ride down + shaft exit, fireball pickup/shoot/cap/respawn, Boss 2 lock/spawn-telegraph/minion cap/vulnerable cycle/death reset, game win), each scored PASS or FAIL as actually run, never assumed.
The four Level 1 fixes (F1–F4) answer the three sweep findings plus the starting-speed note from the playtest; Level 2 adds the elevator, the fireball powerup, and the locked-screen boss the playtest asked for — each mechanic introduced safely before it is required, and every Level 1 invariant (47 stars, 2 secrets, boss HP 6, the 23 checks) frozen.
11 · Carried out
The iteration was carried out under the harness, and the result is live as its own edition — the original and the split edition are untouched: Prompt Runner — Two-Level Edition. Level 1 plays with all four fixes; beating its boss offers a Level 2 with 30 new stars, a third secret, a working elevator, fireballs, and the Core Spawnwright.
The new checks did not all pass on the first run: 14 of 18 did. The four failures were real and are recorded in the build log — the spawn point dropped Bit 56px in the air, eating his head-start in weak air-acceleration; a decorative terrace stood on the run path to the Level 2 finish flag and walled it; and two checks themselves had probe bugs (one walked Bit into a pit past the exit it was testing; one reset its telegraph timer on the very sample where a minion spawned). One bounded repair round — two game fixes, two probe fixes — and the full record below is the re-run.
Acceptance results — run by the harness, not the builder
| Suite | Result |
|---|---|
| Frozen suite (original 23 checks, unchanged) — run against the two-level file | 23/23 PASS |
| New checks for this iteration — fixes, transition, elevator, fireballs, Boss 2 | 18/18 PASS |
| Check | What it proves | Result |
|---|---|---|
| F1 | Loop triggers from a standstill at the tile-131 sign | PASS |
| F2 | Spawn head-start: full loop speed within 5 steps of holding right | PASS |
| F3 | Vault exit spring (tx 92) lifts Bit's feet above y=300 | PASS |
| F4 | Dying to Boss 1 resets it — dormant, HP refilled, gate open, retreat possible | PASS |
| T1 | Level 1 clear screen → Level 2 starts, hearts refilled to 5 | PASS |
| T2 | Level 2 counts, executed: exactly 30 stars, 3 tracked secrets | PASS |
| E1 | Elevator carries Bit DOWN at least 3 tiles, glued (≤2 airborne steps) | PASS |
| E2 | Shaft bottom: Bit walks sideways out and stands on ground | PASS |
| E3 | Elevator carries Bit back up | PASS |
| FB1 | Fire pickup collected — power active, pickup consumed | PASS |
| FB2 | Fireball travels in the facing direction; never more than 2 alive | PASS |
| FB3 | A fireball kills a patrolling enemy in one hit | PASS |
| FB4 | Fire pickup is back within 15 s (900 steps) of collection | PASS |
| B1 | Boss 2 activates and locks the screen — Bit is clamped inside the arena | PASS |
| B2 | Every minion spawn is telegraphed ≥15 steps ahead; never more than 3 minions alive | PASS |
| B3 | Boss 2 loses HP only in its vulnerable window (8 → 7 on the probe hit) | PASS |
| B4 | Dying to Boss 2 resets it — dormant, HP 8, gate open, Bit walks out | PASS |
| B5 | Boss 2 defeated through real vulnerable-window hits; finish reached; game won | PASS |
What's still open:nothing in this iteration is untested — the two suites above are its acceptance record, and the frozen suite's canvas-sample check is timing-sensitive under the test harness (it blank-sampled once in six runs and passed on re-runs). On the wider site, two things remain: the /split page's combiner step still describes the free routes as the research originally found them, and folding the proof run's sign-in findings into that copy is a separate change; and no curated game-design research pack exists yet, so Step 8's fallback is still the honest answer.