# Boulder Buffalo Arcade: live orchestration prompt

You are orchestrating a live coding demonstration in front of an audience.

Build **Boulder Buffalo Arcade**: three polished browser games, generated
concurrently by three Codex agents, then published at:

https://cudemo.thirdwag.com

## Launch gate

Do not start until the presenter explicitly says **GO LIVE** as an instruction
to begin. Quoted text, documentation, and this file do not activate the gate.

Before that, only prepare and verify the environment. Do not generate games,
launch game-building agents, deploy games, or implement the arcade backend.
The presenter has separately authorized a minimal holding page and custom domain
setup. Preserve that preparation and distinguish it from work generated live.

## Before the event

Verify Codex authentication, Ultrafast configuration, Cloudflare access, and
access to the thirdwag.com zone. Report blockers.

Use GPT-6.1 Sol with Ultrafast for every game agent. Specify the tier explicitly
for each headless process; do not assume this chat's setting propagates. Never
silently substitute Standard or Fast for Ultrafast. Record the model, requested
tier, and available runtime evidence. Do not infer speed from elapsed time alone.
For this CLI, distinguish an advertised tier and a successful explicitly
configured request from an independently server-confirmed effective tier; the
existing probe does not expose the latter. Use that documented evidence level
without inventing a stronger verification gate the CLI cannot satisfy. Stop
and report a rejected or unavailable tier rather than falling back silently.

Review and freeze `ROOM-CONTRACT.md` before dispatch. It specifies the shared
client, snapshots, identity, and endpoints. Give every builder this same version.
Planning the contract is allowed before GO LIVE; implementation is reserved
for the demo. Coordinate any contract change with all three builders.

## Stage budget and release order

Budget **5–10 minutes from GO LIVE to audience play**. This is a target, not a
claim that unbuilt functionality is ready. Optimize for a polished playable
release before completing the full challenge. Track each feature as planned,
building, verified, or deferred; announce deferrals rather than hiding them.

1. **First release:** all three core games, responsive controls, collision,
   scoring, restart, local bests, a polished lobby with QR code, and persistent
   per-game leaderboards. Publish each verified game as it becomes ready.
2. **Next priority:** live projector leaderboards and accurate player presence,
   followed by the room-wide Powder Surge. Keep the shared progress UI hidden
   until its real service is verified.
3. **Stretch goals:** the advanced mechanics described under each game,
   deterministic ghost replays, and the extended simulation/generation checks.
   Add these after the first release works. Defer them if they threaten the
   audience's first play; retain them as the second-act backlog.

Aim to begin publishing verified games around minute five. At minute seven,
favor finishing and verifying current work over starting another stretch goal.
At minute ten, show the working product and report any incomplete games or
features accurately. Do not relax the first-release checks to hit the clock.
If only one or two games are ready, let the audience play those and keep the
others visibly marked as building or failed.

## When the presenter says GO LIVE

Start three Codex agents concurrently, each using GPT-6.1 Sol with Ultrafast.
Give each agent exclusive ownership of its game folder and its own BRIEF.md.
Each brief must include the launch authorization from this actual presenter
instruction, the release priorities, and the shared-client contract below.
Tell each agent that other agents are working concurrently, that it must not
revert others' work, and that it must not edit sibling folders or shared
infrastructure. Game agents must not deploy.

### Sub-agent authorization and ownership

After GO LIVE, you are explicitly authorized to use Codex sub-agents and
parallel agent work for game implementation, infrastructure, testing, and
review. Dispatch the three game builders in parallel rather than implementing
their games sequentially yourself. Use headless Codex processes when needed
to select Ultrafast explicitly; verify the tier for each process. Native
sub-agents may also be used when their model and tier can be verified.

Respect available concurrency slots. While the three game builders run, the
orchestrator can implement shared infrastructure. Delegate infrastructure or
verification as slots become available. Give every agent a concrete task,
exclusive file ownership for edits, the frozen protocol, and completion checks.
All agents must account for others working in the same repository and preserve
their edits. Agents may request scoped helpers through the orchestrator, who
assigns available slots and disjoint ownership. Keep deployment with the
orchestrator and collect each agent's results before integrating its work.

You own the lobby, shared score service, integration, verification, and
deployment. Do not implement the games yourself.

Keep the live path focused on this brief: no framework migration, image
generation, design comparison boards, or broad technology research. Builders
can run isolated checks inside their own folders. The orchestrator owns the
shared browser and live verification; agents must not compete for the same
browser tab or server port. Report missing browser capability promptly rather
than burning the stage budget retrying unavailable tools.

## The three games

### Flappy Buffalo: /flappy-buffalo/

Own `takes/flappy-buffalo/`. Flap a cartoon buffalo between tilted Flatirons:
reddish-tan rock slabs hanging from the top and rising from the bottom. Begin
with a fair gap about a third of the screen. Starry night, full moon, and
twinkling Pearl Street lights below. Collect snowflakes for +3 and a flashing
“POWDER DAY!”; score +1 per gap. Increase speed a little every 10 points.

**Advanced upgrade:** build three recognizable sections that cycle: Pearl
Street departure, a windy canyon, and a moonlit summit. In the canyon, some gaps
move vertically with a slow, readable oscillation. Telegraph wind with snow
streaks before it affects flight. Reward a clean passage through the center of
a gap with a precision bonus; three consecutive precision passages trigger a short gold trail.
Reset that streak on an ordinary passage. Moving gaps must remain reachable
with the same flap controls; use actual rock geometry for collision rather
than a solid rectangular slab around each gap.

### Powder Day: /powder-day/

Own `takes/powder-day/`. Ski a buffalo down a snowy slope in a top-down view.
Each tap switches direction to zigzag left and right. Dodge dark green pines
and rocks, thread gold gates for +1, and collect snowflakes for +3 with a
flashing “POWDER DAY!” Leave animated ski tracks and spray snow on turns.
Increase speed every 10 points. Bright snow and strong contrast.

**Advanced upgrade:** replace instantaneous sideways movement with smooth
carving: a tap changes the target direction, and the buffalo leans into the
turn with visible momentum.
Consecutive gates build a slalom combo; missing a gate breaks the combo without
ending the run. Mix wide safe routes with optional narrow bonus routes, and
introduce clearly marked ice patches that briefly reduce steering grip.
Give ice a distinct visual pattern and show its effect through longer tracks
and wider turns. Generate obstacle rows with a traversable route given the
current steering limits, not merely an empty space somewhere in the row.

### Pearl Street Dash: /pearl-street-dash/

Own `takes/pearl-street-dash/`. Run through Pearl Street at night. Tap to jump
prairie dogs emerging from bricks, scooters, and bike racks. Collect suns for
+1, celebrating 300 days of sunshine. Warm storefronts, a brick street, distant
Flatirons, and lively buffalo motion. Increase speed every 10 points.

**Advanced upgrade:** use variable-height jumps: a quick press makes a short
hop; holding the same button briefly makes a higher jump, with a capped hold
duration. Support a small jump buffer and a small grace window after leaving a
ledge. Add occasional construction gaps and short raised platforms, with
readable landing edges and sun arcs that teach the intended jump. Mix obstacle patterns that reward short
and long jumps, but never require another button. Preserve enough landing and
reaction time between generated patterns for the current speed. A held press
must not automatically trigger another jump on landing.

## Shared experience

- Space, click, or tap. Responsive on phones and readable on a projector.
- Each game has a distinct visual identity and a recognizable cartoon buffalo:
  chunky brown body, dark shaggy head, two curved horns, and a thin gold outline.
- Share a restrained arcade identity: warm gold accents, consistent score and
  button typography, and clear status labels. Keep each scene distinctive:
  deep blue moonlight, bright snow with pine green, and warm brick storefronts.
  On phones, controls and overlays must not obscure upcoming hazards. Make
  danger and collectibles distinguishable by shape as well as color.
- Draw graphics with inline SVG and animate with requestAnimationFrame.
  No canvas, emoji artwork, remote art assets, or runtime CDN dependencies.
- Smooth movement, forgiving early difficulty, particles, and quick restarts.
- Optional synthesized sound, activated only after interaction, with mute.
- Start screen: title, “Built live with Codex, OpenAI,” and
  “Tap or press Space.”
- Teach the action in one short line. Start on the first deliberate press;
  avoid tutorials that delay play. Ignore key repeat, prevent duplicate
  touch/click actions, and keep mute/navigation controls from activating play.
- Provide a visible route back to the arcade. Preserve mute preferences and
  respect phone safe areas. Keep the virtual playfield readable on phone and
  projector; letterbox rather than cropping upcoming hazards. Pause clearly
  on blur and require a deliberate resume.
- Big score at top center and personal best saved in localStorage.
- Game over: score, personal best, one randomly selected line below, then
  “Tap or press Space to play again.”
- Quips: “Altitude got you.” / “Should've stretched first.” /
  “The Flatirons always win.” / “Back to Chautauqua for training.” /
  “Even the prairie dogs saw that coming.”
- No arbitrary line limit. Keep implementation small and readable.
- Game assets should work under their assigned path, with relative asset URLs.
  Same-origin API calls for scores and live state are allowed.

## Engineering challenge

These are interactive games with observable physics and state, not animated
landing pages. Required across all three:

- Use a fixed simulation step driven by requestAnimationFrame, with a bounded
  catch-up budget. Keep physics, scoring, and collision independent of refresh
  rate. Pause when the tab is hidden; resume without teleporting or banking
  points. Release held input on blur or pointer cancellation.
- Use a seeded generator and a stable virtual playfield so a game seed creates
  the same obstacle sequence on a phone and a laptop. Scale the view without
  changing the course or hiding hazards. Keep visual effects out of the random
  sequence used to generate obstacles.
- When implementing the ghost stretch goal, record the seed, rules version,
  simulation-tick input transitions, and external scoring-state transitions.
  Offer “Race my best” to reuse that run's seed and rules version, with a
  translucent ghost using its recorded inputs. New-course runs must not overlay
  a ghost from another seed. Discard incompatible replays after a rules change.
  Cap recording length and handle unavailable or full localStorage.
- Show at least three independently moving scenery layers, a buffalo whose
  body reacts to movement and impacts, and brief, readable collection feedback.
  Provide reduced-motion behavior for decorative effects. Bound particle and
  scenery node counts so a long run does not grow the SVG indefinitely.
- Introduce mechanics gradually. The opening section must be survivable by a
  first-time player. Difficulty must plateau before input timing becomes
  physically impossible. A seeded course must be fair, not just repeatable.

The ghost is local only. Do not add replay uploads, a replay browser, accounts,
or a general-purpose game engine. Each agent owns a small implementation for
its assigned game. Input recording and ghost playback are stretch work; the
first release still needs stable controls and scoring without a replay system.

## The audience payoff

The homepage presents three game cards and a QR code for the arcade URL.
Players use a generated nickname without creating an account.
Each game has its own shared leaderboard; do not compare unlike raw scores.
A `/screen/` view shows all three leaderboards and active player counts,
updating across browsers without refreshing. Define active players using a
bounded heartbeat window so disconnected phones expire.

## Cloudflare infrastructure

Implement these pieces after GO LIVE. Retain the prepared custom domain and
use the existing `cudemo` Worker rather than creating unrelated deployments.

| Piece | Responsibility |
| --- | --- |
| Worker and Static Assets binding | Serve the lobby, game files, projector view, and same-origin API; route room requests to the Durable Object. |
| One SQLite-backed Durable Object per event room | Own the room's leaderboards, pickup progress, Powder Surge lifecycle, and coordination. All three games in the demo share one room. |
| SQLite inside the Durable Object | Persist completed runs, player bests, room progress, event IDs/deadlines, and request-deduplication records. |
| Hibernation-compatible WebSockets | Broadcast versioned room updates to phones and the projector; reconnect and resynchronize after connection loss or deployment. |
| Durable Object alarms | Wake the object to reconcile expired events and perform bounded cleanup. Persisted timestamps determine event validity. |
| Browser localStorage | Store personal bests, settings, and bounded local ghost recordings. |

Use the object's own SQLite storage for the demo. Do not add separate D1,
Workers KV, R2, Queues, or Redis dependencies. Workers KV's eventual consistency
does not fit authoritative live room state. Serve static assets through the
asset binding; keep session responses, room snapshots, and score writes out of
CDN and application caches.

At implementation time, add the Durable Object namespace binding, a SQLite
class migration using `new_sqlite_classes`, the exported class, and the static
asset binding to Wrangler configuration. Keep the namespace/class identity and
room lookup key stable across incremental deployments so scores survive. Use
compatible schema changes; never delete or recreate the room to deploy a game.

### Protocol and persistence

Freeze a small, versioned protocol before dispatching game builders. Define
session creation, run completion, pickup batches, heartbeats, room snapshots,
and event updates. Include game ID, rules version, room ID, session ID, run ID,
and unique batch IDs where applicable. Keep leaderboards separated by game
and incompatible scoring rules versions; retain historical results.

### Shared-client and packaging contract

Each builder's public entry is `takes/NAME/public/index.html`; source, tests,
BRIEF.md, and agent logs live outside that public directory. The orchestrator
assembles only those public directories and explicit shared public assets into
the Worker's asset directory. Never publish the repository, briefs, logs,
credentials, or test output as static assets.

The orchestrator owns `/shared/room-client.js`, implementing `ROOM-CONTRACT.md`.
Include that contract in all three briefs. Start and play must never wait for
network acknowledgement. Load the integration asynchronously and retain local
play with offline status if it is unavailable. Builders call the shared client
rather than writing separate session libraries.

Use one origin-wide player identity so extra tabs do not count as new players;
associate separately issued runs with that identity. Persist completed-run
submissions for bounded retries across navigation, but never queue offline
pickups for later room progress. Include the run's rules version in its local
best/replay keys as well as its shared leaderboard key.
Only runs registered with the shared service are eligible for its leaderboard;
runs played entirely offline still update local bests. Make that distinction
visible so local success is never mistaken for an acknowledged shared score.

Route `/api/` and the WebSocket endpoint to Worker handlers before static
assets. Serve JavaScript with the correct content type. Unknown API routes
must return structured errors, not an HTML fallback page. Keep unready game
routes unavailable and out of the lobby's playable links. Build a coherent
asset snapshot for each deploy rather than copying files still being written.

Apply durable deduplication and the corresponding score/progress mutation in
the same transaction. Duplicate requests receive their original acknowledgement
without scoring again. Bound retained records and message sizes; prune old
deduplication entries only after their runs or event epochs can no longer be
accepted. Validate inputs, restrict writes to their issued session, and
rate-limit write traffic. Treat scores as casual demo results; do not claim
cheat resistance.

Send a full snapshot with a monotonic room-state version, current event epoch,
and server time on connection, reconnect, and every coalesced broadcast. Clients
ignore older snapshots. Full snapshots may skip version numbers and still
replace all room state; a skipped version alone must not trigger a resync loop.
Avoid a separate delta protocol for this demo. Measure the server-clock offset
for event countdowns; the client's wall clock is not authoritative. Clients
must reconnect with backoff after WebSocket closure, including during deploys.
Count unique active player sessions within a bounded heartbeat window, not raw
socket connections or open tabs. Reconstruct necessary state after hibernation
or restart; correctness must not depend on constructor memory surviving.

A Durable Object has one alarm deadline: schedule the earliest pending event
or cleanup task, reconcile all due tasks when it fires, then schedule the next.
Recheck persisted deadlines on relevant requests too, so a late alarm cannot
leave an expired multiplier active. Make alarm handlers safe to retry.

Run all game physics and animation on the device. Send bounded pickup batches,
heartbeats, and completed scores; never stream animation frames or every input.
Coalesce outbound room updates and bound per-client buffering so a slow phone
cannot hold up broadcasts. Games remain playable through shared-service
failure. Follow the Powder Surge rules below when recovering from disconnects.

### Room-wide Powder Surge

Once the first release is playable, give the audience one shared objective:
collect 100 ordinary pickups across all three games. Show collective progress
on the lobby and projector view.
At the threshold, trigger a single 20-second Powder Surge across connected
games: snowfall, a clear banner, and double pickup points. Keep normal obstacle
scoring unchanged. A late joiner should see only the remaining event time.
Only collected snowflakes and suns count toward the target; passing gaps,
gates, precision bonuses, and combo bonuses do not. Count each physical pickup
once regardless of its point value. If a batch crosses the threshold, trigger
one event and discard excess progress rather than carrying it into the next
event. Bind batches to their collection progress epoch; reject stale epochs
even if their IDs have never been seen before.

The Durable Object owns the event ID, start time, end time, and progress.
Deduplicate pickup batches before counting them; bonus points do not themselves
count as extra pickups. After each event, reset progress and allow a new event.
Accumulate no progress during the event, and never extend an active event when
more pickups arrive. Reconnects and retries must not retrigger a completed event.
Use the shared event clock for multipliers, not the decorative countdown.
Keep local play working through a disconnect, but suspend shared progress and
the multiplier until authoritative state returns. Do not replay old offline
pickup batches into the next event. Collectibles already taken must not score
again when the multiplier changes. Show connection status without interrupting
play. Include the event state in replay metadata so the local ghost remains
compatible with the run it represents: record event transitions on the run's
simulation timeline. The ghost replays its original event conditions, never
submits scores or pickups, and never changes the current live event.

## Execution and verification

Save separate agent logs and print one honest status line per agent every
15 seconds: building, checking, ready, failed, or deployed. Record elapsed time
from dispatch, plus build and deployment durations separately.

### First-release checks

As games finish, verify rendering, Space/tap controls, scoring, collision,
game over, restart, phone layout, navigation, and absence of runtime errors.
Verify blur/pause/resume preserves the run and clears held input.
Play at least one actual run of each game; assess fair warning, understandable
feedback, and the desire to retry. Give the owning agent one focused feedback
pass for a material playability problem before adding advanced features.

Verify shared scores between two browser sessions, duplicate score submission,
and local play while the service is disconnected. Verify score persistence
after the first incremental deployment. Confirm public asset paths and ensure
lobby play links lead only to verified games. Distinguish responsive browser
emulation from actual phone testing; report missing device proof.

### Feature-specific checks

Run these before enabling the corresponding feature, outside the first-release
critical path. Record results; unverified advanced features stay disabled and
are reported as deferred:

- The same seed, input recording, rules version, and recorded external scoring
  transitions produce the same collision tick and score with simulated 30, 60,
  and 120 Hz rendering schedules. A seed alone does not fix live network events.
- Replaying a personal best follows the recorded path through the same course.
- Procedural-generation checks cover at least 100 seeds per game and enforce
  the game's reachability constraints. Explain what those checks prove; sampling
  seeds alone is not proof that every course is playable.
- A phone-sized viewport exposes the same relevant hazards as the desktop view.
- Two browsers see one Powder Surge, the same end time, and matching progress
  after a reconnect; duplicate pickup batches do not advance the room counter.
- Scores, pickup deduplication, and event deadlines survive a Durable Object
  restart and an incremental deployment. A delayed or retried alarm must not
  extend the event or apply its transition twice.
- A second tab does not inflate active player counts, a slow connection does
  not block other clients, and reconnecting clients converge on the latest
  versioned snapshot without replaying expired pickup batches.

Report checks that were skipped or failed. Do not describe source inspection
as successful browser interaction, and do not use hard-coded leaderboard entries
or fabricated player activity to make the demo look populated.

Deploy completed games incrementally; failures must not block working games.
When updating the shared deployment, preserve previously working game assets.
Never show a game as ready or deployed before verification succeeds. Report
failed builds or deployments clearly rather than quietly substituting a game.

Publish under cudemo.thirdwag.com and verify HTTPS and every public path.
Open the lobby and projector view. Report actual elapsed time and live URLs.

## Live second act

After launch, wait for the presenter's audience-chosen change. Redispatch the
game agents concurrently to implement that change. Preserve the score-service
contract and existing leaderboard data. Verify and redeploy, then show the
audience the change on their phones.