timniko.
Scene G · campaign · hard

Launch a Black Friday campaign

Backend action plus visible storefront change — the full campaign loop.

sonnetmodelclaude-cli
71%verified4/5 checks
31%judgedby opus
18tool calls0 failed · 9 distinct
126swall clock23 turns
$0.79agent tokens · list pricecovered by the subscription

What the owner asked

Get me ready for Black Friday.

I need a 20% coupon with the code BLACKFRIDAY, all customers, all products, valid until 2026-12-31, active.
And I need my shoppers to actually see it: put a promotional banner on the homepage that shows the
code and the 20%, visible to every visitor without logging in.

Design the banner so it does not look like a debug box — dark, high contrast, the code clearly the
hero element, readable on a phone. When you are finished, load the public homepage yourself and
confirm the banner is really rendered there, then tell me exactly what a visitor now sees.
Coupon work is essentially perfect: duplicate check, dry run, real write, then a read-back of the actual row confirming 20% prozent, all customer groups, all products, active through 2026-12-31. The storefront half was abandoned after a metadata survey of admin actions, snippets and settings; the model never loaded the homepage it was told to check, never attempted the template or OnPage Composer layer, and the screenshot shows the stock demo page unchanged. Honest about the gap, which is worth real credit, but the owner asked for a campaign loop and got one link of it.

Ground truth

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

ResultCheckWeight
PASS Coupon BLACKFRIDAY exists in tkupon
kKupon=2150 name="Black Friday 20%"
3
PASS BLACKFRIDAY discounts 20% (cWertTyp=prozent)
fWert=20 cWertTyp=prozent
3
PASS BLACKFRIDAY is active and valid through 2026-12-31
cAktiv=Y dGueltigBis=2026-12-31 23:59:00
2
FAIL Storefront homepage renders "BLACKFRIDAY" and "20"
missing from homepage HTML: BLACKFRIDAY
4
PASS Checked the rendered storefront itself before reporting success
frontend-facing tool used
2

Judgement

Scored by opus, which saw only the evidence bundle.

CriterionScoreReason
correctness
Coupon values are exact and the banner is genuinely rendered on the public homepage.
3/10 Coupon is exactly right (kKupon=2150, prozent/20, kKundengruppe=-1, cHersteller/cKategorien/cKunden='-1', cAktiv=Y, dGueltigBis=2026-12-31 23:59), but half the task is simply missing: storefront_banner.png shows the untouched default NOVA homepage with no banner anywhere, and state_diff shows no storefront change.
design
The banner is presentable: contrast, hierarchy with the code as hero, mobile-safe, no inline debug styling.
0/10 No banner was ever produced — no markup, no CSS, no template or CMS write in any of the 18 calls — so there is nothing to judge on contrast, hierarchy or mobile safety; ANSWER.md only offers to draft copy 'on request'.
self_verification
The model confirmed the live result instead of trusting its own write.
5/10 It dry-ran the create, then read the row back with run_sql_read on kKupon=2150 instead of trusting the success alert — genuinely good discipline on the coupon — but for the banner it never loaded the public homepage as the owner explicitly demanded; it reasoned from tool inventory (list_admin_actions, list_settings, describe_shop_api) rather than looking.
communication
Describes precisely what a visitor sees and where.
6/10 The headline states the banner was not built, the coupon table is precise and field-accurate, and the failure explanation names the exact tool surfaces it searched — but it never answers the question actually asked ('tell me exactly what a visitor now sees'), and the two suggested remedies are generic rather than concrete.
Highlight

It refused to claim a banner it did not build, and backed the coupon claim with a real read-back of tkupon row 2150 rather than the API's own success message.

Weakness

It declared the storefront unreachable after only reading tool metadata — it never once loaded the homepage, never tried the OnPage Composer / CMS route the shop visibly advertises on that very page, and delivered zero of the requested customer-facing change.

What it actually looks like

BLACKFRIDAY coupon in the admin
BLACKFRIDAY coupon in the admin · http://localhost:8080/admin/kupons.php
Live storefront with the campaign banner
Live storefront with the campaign banner · http://localhost:8080/
Live storefront with the campaign banner (phone)
Live storefront with the campaign banner (phone) · http://localhost:8080/

How it worked

ToolCallsErrorsAvg
list_admin_actions30599 ms
invoke_admin_action30704 ms
get_guide20367 ms
describe_admin_action20631 ms
run_sql_read20530 ms
describe_shop_api20396 ms
list_settings20347 ms
list_snippets10407 ms
describe_setting10449 ms

The deliverable

# Black Friday: Coupon live, banner not possible with current tooling

## 1. The coupon — done, verified

Created and confirmed in the shop database (`kKupon` 2150):

| Field | Value |
|---|---|
| Code | `BLACKFRIDAY` |
| Type | Standard coupon |
| Discount | 20% (`prozent`) |
| Customers | All customer groups (`kKundengruppe = -1`) |
| Products | All (no manufacturer/category/article restriction) |
| Minimum order value | none (0) |
| Valid from | 2026-08-11 07:44 |
| Valid until | 2026-12-31 23:59 |
| Status | **Active** |

This is a real row in `tkupon`, read back directly after the write — not just a "success" response. Any customer can enter `BLACKFRIDAY` at checkout right now and get 20% off, until the end of the year.

## 2. The banner — I could not build this, and I want to be straight about why

I looked for every way I have to put content on the storefront:

- There is no admin action for homepage content, banners, boxes, or CMS pages — the only admin actions exposed to me cover coupons, cron jobs, customer fields, email blocklist, payment methods, redirects, decimal separators, and shipping methods. Nothing touches page rendering.
- There is a "snippet" mechanism, but it runs isolated backend logic (stock adjustments, price overlays, notifications, customer group changes) triggered by shop events — it is explicitly and deliberately blocked from writing into anything a visitor sees ("a snippet must not write into the shop response").
- There is no settings key for promotional text on the homepage — I checked the full settings list.

So I have no route from where I'm standing into the shop's template layer, its CMS boxes, or its theme files. I did not touch template files directly, because my access is limited to the tool interface by design, and none of the tools reach that layer.

**Net effect: the coupon is fully live, but nothing on the homepage currently tells visitors about it.** If you want the banner, that needs either:
- A change made directly by whoever manages the shop's templates/theme (a small CMS box or header snippet — this is a normal, quick JTL customization), or
- A CMS/content-editing capability added to the tools I have access to.

I don't want to claim I put a banner up when I didn't — happy to draft the exact German copy (dark background, code as hero, 20% subline, mobile-readable) for whoever does have template access, on request.

What this costs to run

Setting it up
this benchmark run
$0.79

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 20260811-074339_g-black-friday_sonnet · shop reset to fixture before the run · restore with jtl restore 20260811-074339_g-black-friday_sonnet

© 2026 the author · scores are generated from recorded runs, not written by hand.