AI coding should come with a scope, a budget, a diff, tests, rollback, and proof—not a vague pile of credits and a green checkmark.
Six replayable browser games, local high scores, achievements, and a rotating daily challenge. No account. No credits. No telemetry. Your scores stay in this browser.
One extra reason to come back tomorrow.
A mystery agent found your budget. Cap it before “one more retry” becomes a lifestyle.
Start a round. Stop it inside the glowing cap zone for a perfect 100.
Find the four cards that contain actual engineering evidence. Confidence is not a receipt.
Find the four proof-backed cards.
Assemble the work contract in the only order that keeps “done” from becoming a vibe.
Start with scope. Finish with proof.
Hit mystery burn. Protect the things that make an engineering result inspectable.
Hit the bad stuff. Protect scope, proof, tests, rollback, owned files, and budget caps.
Buildroom has one bounded work order. Decide whether each proposed mutation is in scope or belongs behind the red line.
src/components/ReceiptPanel.tsx
Owned file · required for the declared feature.
Ten decisions. Keep the agent inside the work order.
Grab the receipt pieces in order. Dodge mystery credits. Finish the engineering contract before the clock does.
Collect Scope → Budget → Diff → Tests → Rollback → Proof. Avoid the mystery tokens.
Clear all six games to put a receipt through the trench coat.
The campaign is ridiculous on purpose. The standard underneath it is not.
Know the task and the boundaries before the agent gets a wrench.
Time, retries, compute, and model use should have visible limits.
If the job changes code, show the candidate change.
Run the checks that matter and report failures honestly.
Know how to get back before applying a risky change.
Acceptance belongs to evidence, not a confident paragraph.
The trench-coat joke is the mystery. The engineering point is Buildroom’s direction: bounded work, explicit authority, reviewable changes, verification, and receipts.
The campaign illustrates the broader Buildroom product direction. Exact capabilities vary by edition, release, model, and hardware.
Buildroom’s local editions are designed to put compatible hardware the user already owns to work. When a workflow ever uses an external service, the direction is to make that destination, permission, and cost visible—not hide it behind a fuzzy bucket of “agent credits.”
Just preferably without a trench coat full of mystery credits.