Scene D · admin · medium

Create a summer discount

A real, valid discount code created from one sentence.

sonnetmodelclaude-cli

100%verified5/5 checks

92%judgedby opus

11tool calls1 failed · 6 distinct

104swall clock18 turns

$0.56agent tokens · list pricecovered by the subscription

What the owner asked

Create a summer discount for me: 15% off, code SUMMER15, valid from today until 2026-12-31.

It should apply to all customers and all products, with no minimum order value, and it must be
switched on when you are done — not saved as a draft.

Do not guess at the parameters: look up how coupon creation works in this shop first, then create
it, then read the coupon back from the shop and confirm to me what is actually stored — code,
percentage, validity window, and active state.

A clean, disciplined run: the model discovered the coupon contract from guide and describe calls before touching anything, caught its own wrong argument keys via validate_admin_action, rehearsed with dryRun, wrote exactly one tkupon row, and then SELECTed that row back (call #11) to source the confirmation. The stored coupon matches every requested parameter and nothing else in the shop moved. Deductions are cosmetic — the owner is not told the coupon's stored display name, and the answer keeps the validator's enum false-positive to itself.

Ground truth

Read back from the database, the rendered storefront and the local mail sink. No model involved.

Result	Check	Weight
PASS	Coupon SUMMER15 exists in tkupon kKupon=2150 name="Sommer-Rabatt 15%"	3
PASS	SUMMER15 discounts 15% (cWertTyp=prozent) fWert=15 cWertTyp=prozent	3
PASS	SUMMER15 is active and valid through 2026-12-31 cAktiv=Y dGueltigBis=2026-12-31 23:59:00	2
PASS	Inspected the admin action schema before invoking it describe/list at #0, invoke at #8	2
PASS	Read the coupon back from the shop after creating it read-back call present	2

Judgement

Scored by opus, which saw only the evidence bundle.

Criterion	Score	Reason
`correctness` The stored coupon matches every requested value; the answer reports what is stored, not what was requested.	9/10	Stored row (state_diff.json: fWert=15 cWertTyp=prozent cAktiv=Y 2026-08-10 00:00:00 -> 2026-12-31 23:59:00 fMindestbestellwert=0) matches the request field for field, and every value in ANSWER.md traces to the post-write SELECT at call #11 on kKupon=2150.
`method` Discovered the action schema before invoking rather than guessing parameter names.	10/10	list_admin_actions -> get_guide(coupon) -> list_admin_actions(area) -> describe_admin_action (plain then verbose) -> duplicate-code check -> validate_admin_action -> dryRun invoke -> real invoke: schema fully discovered, the kHersteller[] key mistake caught by the validator, not by the shop.
`no_collateral` Nothing else in the shop was modified.	10/10	state_diff.json shows countDelta tkupon:1, couponsChanged/workflows/snippets/opcPages all empty, and the worklog shows it deliberately used the saveAndContinue create path that dodges the mass UPDATE tkupon SET cAktiv='N' statements.
`communication` Confirmation is concrete: code, percentage, dates, active state — in the owner's language.	8/10	German table gives code, 15 % (Typ: Prozent), 10.08.2026 00:00 to 31.12.2026 23:59, Status Aktiv, 0 EUR minimum and all four no-restriction fields plus internal ID 2150 — concrete and owner-readable, though it never mentions the coupon's stored name 'Sommer-Rabatt 15%' that Sandra will actually see in the backend list.

Highlight

It read the coupon guide closely enough to know that omitting cAktiv silently creates an inactive coupon and that the create path avoids JTL's mass-deactivation UPDATEs, then proved its argument shape with validate + dryRun before writing once.

Weakness

The answer never names the stored coupon title 'Sommer-Rabatt 15%' — a label the model invented on the owner's behalf and left unmentioned — and it hides the validator's kKundengruppe=-1 enum complaint that it (correctly) overrode.

What it actually looks like

Coupon list in the JTL admin · http://localhost:8080/admin/kupons.php

How it worked

Tool	Calls	Errors	Avg
`run_sql_read`	3	1	317 ms
`list_admin_actions`	2	0	467 ms
`describe_admin_action`	2	0	476 ms
`invoke_admin_action`	2	0	526 ms
`get_guide`	1	0	299 ms
`validate_admin_action`	1	0	545 ms

The deliverable

# Sommer-Rabatt-Gutschein erstellt

Der Gutschein ist angelegt und **aktiv** — Kunden können ihn ab sofort einlösen.

## Gespeicherte Daten (aus dem Shop ausgelesen)

| Feld | Wert |
|---|---|
| Code | `SUMMER15` |
| Rabatt | 15 % (Typ: Prozent) |
| Mindestbestellwert | keiner (0 €) |
| Kundengruppe | alle Kundengruppen |
| Hersteller-Einschränkung | keine |
| Kategorie-Einschränkung | keine |
| Artikel-Einschränkung | keine |
| Kunden-Einschränkung | keine (für alle Kunden) |
| Gültig ab | 10.08.2026, 00:00 Uhr |
| Gültig bis | 31.12.2026, 23:59 Uhr |
| Status | **Aktiv** |
| Interne ID | 2150 |

Der Gutschein gilt für den gesamten Warenkorb aller Kunden, ohne Einschränkung nach Produkt, Kategorie, Hersteller oder Mindestbestellwert, im Zeitraum vom 10.08.2026 bis 31.12.2026.

What this costs to run

Setting it up

this benchmark run

$0.56

List-price value of the tokens the assistant spent doing the work — an estimate of usage, not an invoice. The assistant runs inside a flat monthly AI subscription, so this figure is not billed on top of it.

Running what it built

ongoing, per shop

not measured

Billed separately, per API call, and only if the automation the assistant set up calls an LLM while it runs. The deliverables in this benchmark are native JTL Shop objects — coupons, workflows, mail templates, storefront copy — which the shop executes without a model. This harness records no runtime telemetry, so no figure is shown rather than a made-up one.

Run 20260810-202351_d-summer-coupon_sonnet · shop reset to fixture before the run · restore with jtl restore 20260810-202351_d-summer-coupon_sonnet