fix(wix-manage): correct the store-wide coupon scope - #859

The defect

ecom-pricing-create-coupon.md documented the "all store products" coupon scope as

"scope": { "namespace": "stores", "group": { "name": "product" } }

with the entityId omitted — in both store-wide request examples, the Scope values for Wix
Stores table, the SITE row of the recommendation mapping, and the fix column of the error table.

The Coupons API rejects that combination for a percentage coupon. Verbatim, from a recorded run
transcript (POST https://www.wixapis.com/stores/v2/coupons):

Wix API error (400): {"message":"The provided combination of scope and coupon type is invalid.
Provided combination:
namespace=stores, group=product, entityId=empty, coupon type=PercentOff
Supported combinations:
- namespace=stores, group=empty, entityId=empty and coupon type is one of BuyXGetY
- namespace=stores, group=product, entityId=some-id and coupon type is one of BuyXGetY
- namespace=stores, group=collection, entityId=some-id and coupon type is one of BuyXGetY
- nam…

(the recorded error body is truncated at that point)

group is valid only together with its entityId; a store-wide coupon carries the namespace
alone. The Valid scope values
reference this recipe already links to says exactly that — Group is "optional - if not listed, the
coupon will apply to all products/services/events in the namespace", and Entity ID is "required
only when Group is listed". The recipe contradicted the page it cites.

Blast radius

Reproduced on five consecutive nightly runs of the same scenario. In each one the agent read
…/skills/pricing-create-coupon, sent the documented store-wide scope on its first create call,
took the 400, then retried with group removed and succeeded. The outcome judge scored 10/10 every
time — the user does get the coupon — while the path judge scored 6–7 and named the scope
combination as the gap.

The recovery is what the recipe cost: one rejected mutating call plus a retry, on the most common
coupon request there is.

The fix

Correct the shape everywhere the recipe already restates it (no new prose about API shape, per
Orchestration, not API shape), and add the 400 to the existing error table:

• both store-wide request examples and the query-response example → "scope": { "namespace": "stores" }
• Scope values for Wix Stores → "All store products" omits group and group.entityId
• SITE mapping row → { "namespace": "stores" }
• error table: the "scope or minimumSubtotal is not used" fix no longer suggests the invalid shape
• error table: one new row for "The provided combination of scope and coupon type is invalid."

+7 / −15 on the recipe. The front-matter description is unchanged — this corrects a shape, it does
not extend what the recipe covers, so the retrieval key should not move.

Routing

The failing agent read this recipe — ReadFullDocsArticle on
https://dev.wix.com/docs/api-reference/business-solutions/e-commerce/skills/pricing-create-coupon
was the call immediately before the rejected create, and the recipe is the only source of the wrong
shape. The upstream reference is already correct, so there is nothing to fix in the API docs, and
the API's own 400 is already explicit about the supported combinations. The defect is the recipe
restating a shape its own cited reference contradicts, so it is fixed here and only here.

Coverage

New scenario yaml/wix-manage-evals/ecommerce/pricing-promotions/ecom-pricing-create-coupon-store-wide-scope.yml,
three assertions per docs/eval-scenarios.md: ReadFullDocsArticle coverage on the recipe's doc
URL, an llm_judge on the outcome, and a gating llm_judge on the tool-call path that fails a
create call rejected with this 400 even when a retry recovers. The trigger prompt is the unmodified
request that produced the finding — it names no scope, so an agent with the old content still has
every reason to go wrong.

Validated against packages/evalforge-core/src/schema.ts (parseScenario), and the articleUrl
against the gate's canonicalDocUrl.

Note on checks

GitHub Actions is disabled repository-wide (actions/permissions → enabled: false), so no check
will appear on this PR. The gate was run manually against this branch; results are in a comment
below.