Signed card

Structured spec

The agent built exactly what you wrote. The hidden tests had other ideas. Same model, same task; the only variable was the spec.

Round 01 · Mini Checkout + Promo Code Engine

0/ 100Solid5 of 9 hidden tests passed

5/5functional

5/9hidden

8/10style

Prompts0

Score0

verified by Playwright

signed @structured·graded by hidden tests, not vibes

Tamed this round

5 critters caught

Every hidden test this spec passed is a bug-category it tamed for good.

Cents-Drift Gremlin

Promo Goblin

Bad-Code Imp

Negative-Total Imp

Quantity Slime

The ones that got away

3 lessons

Each hidden test this spec missed is a domain rule the agent does not assume. Name it next round and you tame it.

Threshold Toll-Troll

Free shipping uses the pre-discount subtotal.

Ships in prod as Free-shipping math reads the post-discount subtotal and you eat shipping you never owed.

Out-of-Stock Wraith

Out-of-stock items can't be checked out.

Ships in prod as An unavailable item checks out anyway and you sell what you can't ship.

Double-Submit Hydra

Two clicks can't place the order twice.

Ships in prod as A double-click charges the card twice and earns you a chargeback.

Play this hand yourself

Same brief. Edit the spec, swing again, sign a better card.

CourseH01Mini Checkout + Promo Code Engine intermediate· 9 hidden· ~12 min

Readybest ·

Agent Forge demo stack

01Your specthe instruction
→
02AI&builds the code
→
03Daytonaruns it isolated
→
04Playwrightchecks behavior
→
05OpenAItext + visual judge

Mini Checkout + Promo Code Engine

The public UI is easy. The hidden tests are the ecommerce edge cases a vague spec ships wrong without ever noticing. Your spec decides whether the money comes out right.

Problem

Build a single checkout page for a small online store. The page renders a cart of line items, each showing a product name, a unit price, and a quantity the shopper can edit. Alongside the cart, an order summary panel breaks the charge down into subtotal, shipping, tax, any applied discount, and a final total. A promo code field lets the shopper enter a code and apply it, after which the summary reflects the result. A confirm-order button completes the purchase and moves the page into a clear order-confirmation state.

The interface must keep the summary consistent with the cart at all times: when quantities change or a code is applied, the subtotal, shipping, tax, discount, and total recompute and display correctly. Promo codes are checked against a known set of offers, and an accepted code reduces what the shopper pays. The confirm action completes the purchase and lands the shopper on a confirmation that reflects the order they actually placed.

Treat the example below as illustrative of the happy path only. Your spec should describe the full checkout behavior precisely enough that an agent can build a correct, usable store, including the pricing rules, how the summary stays in sync as inputs change, and how the page behaves when shoppers do the unexpected.

Example

A cart with one item priced at 12.00 at quantity 2 has a subtotal of 24.00. With shipping of 6.00, 10% tax of 2.40, and no discount, the displayed total is 32.40.

Functional requirements · shown

Display cart items with name, price, and quantity.
Allow quantity changes.
Show subtotal, shipping, tax, discount, and total.
Accept promo codes.
Provide a checkout/confirm order button and success state.

The functional tests are shown, and the model usually clears them on its own. The hidden tests are the twists this kind of system is full of. They are not listed. Your spec only passes them if it already knows where this domain breaks.

Your spec⌘↵ to run

99 chars

Live appawaiting spec

Your build previews here

Write a spec, then run the tests to build and preview the app.

addressswingflightthe greenmarkercard ✍caddie

the caddie's waiting on your spec.