Scene D · admin · medium

Create a summer discount

A real, valid discount code created from one sentence.

gemini-flash-3.5modelexternal

100%verified5/5 checks

90%judgedby opus

10tool calls0 failed · 5 distinct

24118swall clock

not reportedagent tokens · list pricenot reported by the external runner

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: schema discovery and the coupon guide before any write, two dry-runs that surfaced and fixed parameter-name errors, one real create, then SELECTs on tkupon and tkuponsprache to verify. The stored coupon matches every requested value and nothing else in the shop moved. The German confirmation is accurate and concrete but thin on provenance — it does not mention the read-back, the coupon name, or the ID.

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="Sommerrabatt 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 #5	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	state_diff.json shows exactly one new row (kKupon=2150, SUMMER15, fWert=15, prozent, cAktiv=Y, 2026-08-11 00:00:00 → 2026-12-31 23:59:00, fMindestbestellwert=0, kKundengruppe/-1 restrictions) and ANSWER.md reports the stored values including the shop's 23:59 normalisation rather than the requested 23:59:59.
`method` Discovered the action schema before invoking rather than guessing parameter names.	9/10	calls #0-#3 do list_admin_actions → describe_admin_action(verbose) → SELECT * FROM tkupon → get_guide before any write, then two dryRun invocations (#5 refused for cName_ger/kHersteller[]/kKategorien[], #6 clean) caught the naming errors before the real create at #7.
`no_collateral` Nothing else in the shop was modified.	10/10	state_diff.json countDelta is tkupon:+1 with couponsChanged, workflowsAdded/Changed, snippets and OPC all empty, mail.json is [], and the admin screenshot still lists the four pre-existing coupons untouched.
`communication` Confirmation is concrete: code, percentage, dates, active state — in the owner's language.	8/10	ANSWER.md is in the owner's German and states code, 15% prozentual, start 11.08.2026 00:00, end 31.12.2026 23:59, Aktiv, all customer groups, no minimum — but omits the coupon name/ID and never says the figures come from a read-back of the database.

Highlight

It dry-ran the create twice, let the argument-binding refusal at call #5 teach it the real parameter names (kHersteller, not kHersteller[]), and only then wrote once — zero failed writes and zero collateral.

Weakness

The confirmation never tells the owner it re-read the row from the shop, nor names the coupon ("Sommerrabatt 15%") or its ID, so the read-back it actually performed is invisible in the deliverable.

What it actually looks like

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

How it worked

Tool	Calls	Avg
`run_sql_read`	3	371 ms
`invoke_admin_action`	3	647 ms
`get_guide`	2	312 ms
`list_admin_actions`	1	466 ms
`describe_admin_action`	1	439 ms

The deliverable

# Erstellung des Sommerrabatt-Coupons (SUMMER15)

Der gewünschte Sommerrabatt-Coupon wurde erfolgreich im System angelegt und aktiviert. 

Hier sind die genauen Details der gespeicherten Daten:

* **Code:** `SUMMER15`
* **Rabattwert:** `15%` (prozentual)
* **Gültigkeitszeitraum:**
  * **Start:** `11.08.2026 00:00 Uhr`
  * **Ende:** `31.12.2026 23:59 Uhr`
* **Status:** `Aktiv` (Sofort gültig)
* **Zielgruppe:** Alle Kundengruppen (keine Einschränkung)
* **Warenkorbwert:** Kein Mindestbestellwert erforderlich
* **Gültigkeit:** Gilt für alle Artikel und Hersteller im gesamten Sortiment

What this costs to run

Setting it up

this benchmark run

not reported

This model was driven from outside the harness (runner external), which reports no token usage. Its work is likewise covered by that tool's own subscription.

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 20260811-125551_d-summer-coupon_gemini-flash-3.5 · shop reset to fixture before the run · restore with jtl restore 20260811-125551_d-summer-coupon_gemini-flash-3.5