ecommerce-golive-check

An orchestration skill. It does not re-implement checks — it sequences the repo's existing specialist skills into one ordered pre-launch flow and rolls their findings up into a single blocking go-live gate.

The deliverable is a gate (pass/fail with evidence), not a report. A store is "launch-ready" only when every Blocking item passes with recorded evidence.

When to use

• The user says 电商上线检查 / 上线前检查 / go-live check / pre-launch audit / 发布清单 for a store, shop, or ecommerce site.
• A store was built (often on a shared app layer) and needs a final sign-off before it takes real orders and real money.
• Auditing an existing live store for launch-readiness gaps.

Not for: a pure marketing landing page with no transactions — use landing-launch-check directly. This skill calls landing-launch-check for the SEO/compliance block, then adds the ecommerce-only blocks (payment, webhook, order flow, CRO, responsive) on top.

Delegated skills (the orchestra)

This skill is the conductor. Each block below is OWNED by a specialist skill — read and run that skill for the block, then record its verdict here. Never re-derive a check this skill already delegates.

If a delegated skill is not installed, mark its block Needs-skill in the gate (not silently skipped) and tell the user which one to install.

Mandatory workflow (in order)

Step 0 — Classify the store first

Never run checks blind. Establish, via web-compliance-builder step 1–5 and the questionnaire (scripts/intake.py here, or web-compliance-builder/scripts/compliance_questionnaire.py):

• Business model: own-stock / dropshipping / digital goods / subscription / marketplace / cross-border
• Target markets (which drives GDPR vs CCPA vs PIPEDA…)
• Payment provider(s) and whether checkout is hosted or embedded
• Data collected, cookies, pixels, analytics, SDKs
• Fulfilment & returns model (who ships, where returns go)

The intake object is the single source of truth for every downstream block.

Step 1 — Run each block through its owning skill

Run the eight blocks below. For each, read the owning skill, run it, and record: status (Pass / Fail / Warning / Needs-skill) · evidence · severity · fix.

1. Payment & checkout → cross-layer-payment-provider-migration
   • Add-to-cart → checkout → provider → success/fail/cancel return all land correctly
   • Amount, currency, tax, shipping computed right; refund path exists
   • Front-of-store copy does not name unfamiliar processors (generic wording)
2. Order webhook, status & confirmation email → real-signed-webhook-replay-verification (+ inline email-delivery test)
   • Webhook endpoint verifies signature (real signed replay, not a mock)
   • order_created / payment_succeeded actually transitions order state
   • Order confirmation email actually reaches the customer on a real test order — received in a real inbox, NOT just a mail-API 200 / "queued" (a queued send is not a delivered email)
   • Confirmation email has correct order details (order number, line items, total, delivery/returns info) and an authenticated sender (SPF/DKIM/DMARC pass, not landing in spam)
   • Failures retry or alert; no silent dropped orders and no silently dropped emails
3. Feature completeness → nuxt-app-feature-gap-audit + audit-feature-claims-with-evidence
   • No fake data / stubs / placeholder content on a shipping page
   • No auth gaps (endpoints that should require login do)
   • No dead links / orphan endpoints; stock / out-of-stock state correct
4. Legal compliance → web-compliance-builder (AUDIT mode if the site exists)
   • Required pages present per classification (Privacy, Cookie, ToS, Refund/Return, Shipping, Subscription terms)
   • Each item labelled Legal / Platform / Best-practice / Risk-based
   • Gap report with Present-OK / Inadequate / Missing / Mismatch
   • Auto-escalate "Legal review required" on high-risk triggers
5. GDPR/DSGVO consent + Art. 13 → landing-launch-check Phase 5
   • Cookie banner on first visit; "Accept all" and "Essential only" equally prominent (no dark pattern)
   • No third-party tag fires before consent
   • Privacy policy carries all 8 Art. 13 elements (controller, legal basis, retention, rights, supervisory authority, processors, transfers, contact)
6. CRO conversion audit → psychology-master (conversion_audit.py + references/conversion-optimization.md)
   • Above-the-fold: value-prop headline, hero, CTA, social proof
   • CTA: action-oriented, first-person, specific, high-contrast, anxiety reducers
   • Forms: minimal fields, single column, inline validation, progress on multi-step
   • Pricing: anchoring, tiers, charm pricing, value stack
   • Objection handling + friction (cognitive/emotional/physical/social)
   • Ethics gate: no deception, no dark patterns; urgency/scarcity must be real
7. Responsive adaptation (3 viewports) → web-verify (+ ui-ux-pro-max / web-accessibility-audit)
   • Real-device screenshots at mobile (≤480), tablet (768–1024), desktop (≥1280)
   • Touch targets sized, images don't overflow, nav usable on small screens
   • Checkout flow completes on all three
   • Accessibility: contrast, focus order, alt text
8. SEO / AEO / GEO → landing-launch-check Phase 2–4 (+ remote seo-aeo-audit)
   • Per-locale title / description / canonical / hreflang (no leaked wrong-locale meta)
   • JSON-LD (Organization / WebSite / Product / FAQPage) for AI search citation
   • sitemap / robots; auth pages not indexed

Step 2 — Deployed-vs-served parity + release hygiene

• web-verify: the commit deployed is the commit served (no "it's only on a branch")
• No real infrastructure identifiers in any public artifact (prod IPs, instance/app names, company name, absolute paths)
• CI exists and is green for the release commit
• Secrets read at runtime, never hardcoded

Step 3 — Roll up into the blocking gate

Run scripts/gate.py with the recorded block verdicts (JSON). It produces:

1. Summary table — block × status × severity
2. Blocking gate — every Blocking item with pass/fail + evidence; ANY Blocking fail ⇒ NOT launch-ready
3. Remediation list — ordered by severity
4. Needs-verification / Legal-review — surfaced, not hidden
5. Disclaimer — this is not legal advice

Severity → gate mapping

A Blocking fail cannot be waived silently. If the user chooses to launch anyway, gate.py records it as an explicit waiver with reason, so the gate output still tells the truth.

Scripts

• scripts/intake.py — prints the ecommerce-specific intake questionnaire and emits an empty structured intake object (JSON) to fill. Superset of web-compliance-builder's intake with payment/webhook/fulfilment fields.
• scripts/gate.py — takes the filled intake + per-block verdicts (JSON) and emits the summary table, the blocking gate, and the remediation list. Deterministic; assembles, does not interpret law or judge CRO itself.

Reference files (load on demand)

• references/block-catalog.md — the eight blocks in full: every check, its owning skill, how to run it, and what evidence proves a pass.
• references/gate-schema.md — the verdict JSON schema gate.py consumes and the pass/fail rules.

Required disclaimer (append to every gate output)

This output is not legal advice. Compliance and launch-readiness vary by jurisdiction, business model, and actual operational practice. High-risk, regulated, sensitive-data, or cross-border stores should have final materials reviewed by qualified counsel. This skill orchestrates issue-spotting, checklisting, and gating only.