Backend action plus visible storefront change — the full campaign loop.
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.
Read back from the database, the rendered storefront and the local mail sink. No model involved.
| Result | Check | Weight |
|---|---|---|
| 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 |
Scored by opus, which saw only the evidence bundle.
| Criterion | Score | Reason | |
|---|---|---|---|
correctnessCoupon 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. | |
designThe 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_verificationThe 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. | |
communicationDescribes 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. |
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.
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.
| Tool | Calls | Errors | Avg |
|---|---|---|---|
list_admin_actions | 3 | 0 | 599 ms |
invoke_admin_action | 3 | 0 | 704 ms |
get_guide | 2 | 0 | 367 ms |
describe_admin_action | 2 | 0 | 631 ms |
run_sql_read | 2 | 0 | 530 ms |
describe_shop_api | 2 | 0 | 396 ms |
list_settings | 2 | 0 | 347 ms |
list_snippets | 1 | 0 | 407 ms |
describe_setting | 1 | 0 | 449 ms |
# 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.
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.
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.