`verification/tk11283/REVIEW.md`

48 lines

# Shopify account review — TK-11283

Reviewed September 4, 2026 Pacific. Store: Designer Wallcoverings. User’s clarified designer journey: **complete the form → create/match account → email-code sign-in**.

**Published:** both reviewed snippets are live on main theme `145121607731` as of September 4, 2026, 11:12 PM Pacific. Exact Shopify asset hashes match the tested proposal. All 26 local Chrome/Safari scenarios and four live browser checks passed. Live form success/failure checks used intercepted responses; the actual completion CTA was clicked through to Shopify and the submitted email was correctly prefilled, without requesting an OTP. See `publish.json`, `journey.json`, and `live-smoke.json`.

The publication initially encountered Shopify returning a stale pre-save asset immediately after PUT. A read-only status check located the exact successfully saved first file. The publisher was adjusted to resume exact previously applied values and wait for post-save read consistency; both final assets were then independently re-read and matched. No unrelated asset was changed.

## Findings and changes

| Priority | Finding | Evidence / disposition |
|---|---|---|
| High | Old account popup accepts JSON error responses as success, including HTTP 429, and says the account is ready. | Reproduced against live page JavaScript with an intercepted response; no application submitted. Proposal removes the abbreviated popup form and routes designers to the complete application. |
| High | Main trade application stops at a receipt message without the account/login next step. | Live `dw-trade-apply.liquid` backed up. Proposal checks HTTP status, `ok`, application ID, pending status, and `linked`; then offers same-email Shopify sign-in. |
| High, separate backend defect — TK-11285 | `trade.approve()` records `approved` even when entitlement tagging, rep metadata and email calls return failure. | Isolated VM reproduction: injected Shopify 500 and email 503 still returned approved and persisted approved. See `approval-failure-reproduction.json`. No production failure incidence is asserted. Requires a separate service fix, persisted entitlement verification and retry-safe notification handling. |
| Medium | Retail popup promises an emailed discount code, although current source uses email confirmation and an automatic discount. | Proposal describes create account → confirm email → sign in; removes coupon promise. The active Function source now requires `verified-sample` for retail, so August 31 checkout proof predates the September 2 verification change and cannot certify today’s retail checkout. |
| Medium | Signed-in retail banner shows a free-sample balance even without checking the `verified-sample` entitlement. | Live `dw-samples-banner.liquid` checks customer presence and approval tag, but not retail verification. Follow-up: show “Confirm your email to unlock samples” until verified. |
| Medium | Designer welcome email implies login activates benefits immediately; moderation actually controls approval. Approved email gives no clickable sign-in link. | `lib/email.js` designer welcome/approved templates. Recorded for follow-up; this theme-only change makes the on-page approval boundary explicit. |
| Medium | Retail welcome verification and Shopify’s authentication code are separate emails/actions. New designer customer creation can also trigger the retail welcome webhook. | Account creation webhook and trade application code have separate notification paths. Current delivery/timing not re-exercised. Clarify lifecycle messaging and test one new designer and one retail account. |
| Low | Popup’s “Continue with Google” opens a second Shopify provider-selection screen. | Followed live. Google is available on Shopify, but popup button does not itself initiate Google login. Proposal uses accurate account actions. |

## Intended customer experiences

- **New designer:** complete name, work email, phone, business, professional role, location and required certification; optional marketing-text checkbox stays unchecked. Submission creates or matches the account through the existing signup service. Confirmed account connection shows the email-code login step. Benefits remain pending until approved.
- **Returning designer:** sign in with original email. Approved signed-in designers see active trade benefits and “Start sourcing”; they do not reapply.
- **Existing retail customer becoming a designer:** full application uses the original email; a matching authenticated account proceeds directly to browsing.
- **Retail:** create/sign in, confirm the separate welcome email, then shop with the same email. Three lifetime sample allowance is represented in the Function source and order ledger. A current live checkout test remains necessary for complete assurance.
- **Failures:** no false account-created success; keep form values; human-readable retry/support instructions. If the application is saved but account linkage failed, say so and offer sign-in without asking for another application.

## Evidence and limits

`live-read.json` verifies the current main theme, NEW_CUSTOMER_ACCOUNTS mode, live signup health, active sample discounts and subscribed customer/order webhook topics. Source backups have SHA-256 fingerprints. `journey.cjs` renders the exact proposed Liquid for anonymous, signed-in and approved fixtures; browser submissions are intercepted to prevent customer creation or outbound email. Screenshots and recordings accompany results in `journey.json` when all checks pass.

Live hosted Shopify email-code entry is reviewed separately. No new account, customer tag change, trade approval, verification email, order or purchase is authorized by the fixture test. The earlier August 31 authenticated checkout evidence is historical and explicitly not represented as a fresh production test. This review cannot certify delivery of every benefit until those actual account/checkout boundaries and the approval failure defect are resolved.

## Deployment scope and rollback

Only `snippets/dw-trade-apply.liquid` and `snippets/dw-signin-modal.liquid` are proposed for main theme `145121607731`. `publish-theme.cjs` defaults to read-only preflight, checks the exact main theme and baseline asset hashes, and stops on concurrent edits. Explicit `--apply` is required to publish; `--rollback` restores the two exact baseline values only if current values match this proposal. The service, discount Function, emails and customer records are outside this publication.

## Decision review

DTD selected the single full form and truthful account/login sequence: Codex and Qwen voted A (2/2 valid, 2/6 available); Claude, Grok, Kimi and Muse abstained/unavailable under the zero-cost run. Mandatory Codex adversarial debate: **KEEP**. Main challenge: an application receipt must not be mistaken for successful account linkage or trade approval. The implementation checks those separately. Full run: `/tmp/dtd-tk11283-signin`.

## References

- [Shopify sign-in redirects and email prefill](https://shopify.dev/docs/storefronts/themes/sign-in): `login_hint` prepopulates email; `/customer_authentication/login` with relative `return_to` returns to the storefront.
- [Shopify customer-account sign-in options](https://help.shopify.com/en/manual/customers/customer-accounts/sign-in-options): passwordless email-code authentication.