192 lines
6.8 KiB
Markdown
192 lines
6.8 KiB
Markdown
# Solution Design: ecomm MVP — sign up and create a single storefront
|
||
|
||
| | |
|
||
| --- | --- |
|
||
| **Anchor** | [wiggleverse/wiggleverse-ecomm#1](https://git.wiggleverse.org/wiggleverse/wiggleverse-ecomm/issues/1) (`type/feature`, `priority/P1`) |
|
||
| **Author(s)** | Claude (session ecomm-0020), for Ben Stull |
|
||
| **Reviewers / approvers** | Ben Stull |
|
||
| **Status** | `draft` |
|
||
| **Version** | v0.1.0 |
|
||
| **Source artifacts** | BDD corpus: [research/shopify](https://git.wiggleverse.org/wiggleverse/wiggleverse-ecomm-prototype-content/src/branch/main/research/shopify) (esp. [flows/first-run-experience.md](https://git.wiggleverse.org/wiggleverse/wiggleverse-ecomm-prototype-content/src/branch/main/research/shopify/flows/first-run-experience.md)) · Prototype: [wiggleverse-ecomm-prototype](https://git.wiggleverse.org/wiggleverse/wiggleverse-ecomm-prototype) (R01–R07) · Reference: Shopify first-run experience · Supersedes: — |
|
||
|
||
**Change log**
|
||
|
||
| Date | Version | Change | By |
|
||
| --- | --- | --- | --- |
|
||
| 2026-06-10 | v0.1.0 | Initial draft (session ecomm-0020) | Claude |
|
||
|
||
---
|
||
|
||
## 1. Business Context
|
||
|
||
*The business lens — solution-agnostic throughout. No mechanism is proposed until §2.*
|
||
|
||
### 1.1 Executive Summary
|
||
|
||
Independent merchants who want to sell online need a commerce platform that
|
||
treats them honestly — and today Wiggleverse has nothing to offer them: no way
|
||
to exist on the platform, no storefront to own, no surface to manage. This
|
||
design delivers the first real value of ecomm: a person can become a merchant —
|
||
establish their identity, claim their one storefront, and stand on a stable
|
||
management surface — in every environment the platform runs in, from day one.
|
||
The beneficiaries are the first merchants (who can finally exist on the
|
||
platform) and the ecomm line itself (every subsequent capability — catalog,
|
||
orders, checkout — gains a real account-and-storefront spine to attach to,
|
||
instead of mocks). Just as importantly, it proves the platform can be brought
|
||
to life anywhere from nothing: a fresh, empty environment reaches "first
|
||
merchant, first storefront" through the product alone, with no hand-seeded
|
||
data — so launching the real service is an ordinary, rehearsed act rather than
|
||
a one-off ritual.
|
||
|
||
### 1.2 Background
|
||
|
||
ecomm is Wiggleverse's multi-tenant, OHM-grounded alternative to Shopify — a
|
||
commerce platform whose mechanics are accountable to the
|
||
[OHM concept corpus](https://ohm.wiggleverse.org) (no dark patterns, data
|
||
minimization, durable addressability, honest pricing). The product was explored
|
||
in a first-pass prototype (`wiggleverse-ecomm-prototype`, releases R01–R07,
|
||
189 scenario-bound tests) built against a harvested corpus of ~1,238 BDD
|
||
scenarios describing Shopify's behavior. That prototype is read-only prior art;
|
||
`wiggleverse-ecomm` is the clean greenfield rebuild, stood up 2026-06-10 with
|
||
its architecture intentionally undecided until this design.
|
||
|
||
The strategic moment: the rebuild has repos, an issue tracker, and a charter —
|
||
but no app code and no users. Everything in the product line queues behind one
|
||
question: *how does a person come to exist on the platform and own a
|
||
storefront?* Until that is answered for real — against real persistence, in
|
||
real environments — no other capability can ship honestly.
|
||
|
||
### 1.3 Business Actors / Roles
|
||
|
||
| Role | Responsible for (in the business) |
|
||
| --- | --- |
|
||
| **Merchant** | A person running a (small) commerce business who wants to sell under their own storefront: they decide to join a platform, establish their business presence on it, and manage that presence over time. |
|
||
| **Platform operator** | The person/org running the ecomm service itself: stands up and maintains the environments the platform runs in, and is accountable for the service being available to merchants. |
|
||
| **ecomm team** | Builds the platform; needs each capability to rest on real, shippable foundations rather than mocks. |
|
||
|
||
(Shoppers — the merchants' customers — are deliberately *not* an actor in this
|
||
design; nothing here is shopper-facing yet. See §1.7.)
|
||
|
||
### 1.4 Problem Statement
|
||
|
||
A person cannot become a merchant on ecomm. There is no way to establish an
|
||
identity on the platform, no way to claim a storefront, and no surface from
|
||
which to manage one — the platform has no users because it cannot have users.
|
||
And even if it could, there is today no defined path from "fresh, empty
|
||
environment" to "working platform serving its first merchant": local
|
||
development, pre-production, and production bring-up are all undefined, so
|
||
nothing built on top can ever actually launch.
|
||
|
||
### 1.5 Pain Points
|
||
|
||
| # | Pain | Who feels it | Cost / frequency today |
|
||
| --- | --- | --- | --- |
|
||
| PP-1 | No way to establish an identity on the platform — a would-be merchant simply cannot exist on ecomm. | Merchant | Total exclusion; blocks every merchant, always. |
|
||
| PP-2 | No way to own a storefront or reach a management surface — even an identity would have nothing to hold. | Merchant | Total; there is no unit of "my business" on the platform. |
|
||
| PP-3 | Every subsequent capability (catalog, orders, checkout, policies) has nowhere real to attach — work would have to build on mocks and be redone. | ecomm team | Blocks the entire product line; rework risk on everything shipped against fakes. |
|
||
| PP-4 | No defined, repeatable path from an empty environment to a working platform — bring-up of dev, pre-prod, and prod is folklore. | Platform operator | The service cannot launch anywhere; every environment question is open-ended toil. |
|
||
|
||
### 1.6 Targeted Business Outcomes
|
||
|
||
<!-- §1.6 pending -->
|
||
|
||
### 1.7 Scope (business)
|
||
|
||
<!-- §1.7 pending -->
|
||
|
||
### 1.8 Assumptions · Constraints · Dependencies
|
||
|
||
<!-- §1.8 pending -->
|
||
|
||
### 1.9 Business Use Cases
|
||
|
||
<!-- §1.9 pending -->
|
||
|
||
---
|
||
|
||
## 2. Solution Proposal
|
||
|
||
<!-- §2 pending -->
|
||
|
||
---
|
||
|
||
## 3. Product Personas
|
||
|
||
<!-- §3 pending -->
|
||
|
||
## 4. Product Use Cases
|
||
|
||
<!-- §4 pending -->
|
||
|
||
## 5. UX Layout
|
||
|
||
<!-- §5 pending -->
|
||
|
||
## 6. Technical Design
|
||
|
||
### 6.1 Invariants
|
||
|
||
<!-- §6.1 pending -->
|
||
|
||
### 6.2 High-level architecture
|
||
|
||
<!-- §6.2 pending -->
|
||
|
||
### 6.3 Data model & ownership
|
||
|
||
<!-- §6.3 pending -->
|
||
|
||
### 6.4 Interfaces & contracts
|
||
|
||
<!-- §6.4 pending -->
|
||
|
||
### 6.5 Per–Product-Use-Case design
|
||
|
||
<!-- §6.5 pending -->
|
||
|
||
### 6.6 Non-functional requirements & cross-cutting concerns
|
||
|
||
<!-- §6.6 pending -->
|
||
|
||
### 6.7 Key decisions & alternatives considered
|
||
|
||
<!-- §6.7 pending -->
|
||
|
||
### 6.8 Testing strategy
|
||
|
||
<!-- §6.8 pending -->
|
||
|
||
### 6.9 Failure modes, rollback & flags
|
||
|
||
<!-- §6.9 pending -->
|
||
|
||
## 7. Delivery Plan
|
||
|
||
### 7.1 Approach / strategy
|
||
|
||
<!-- §7.1 pending -->
|
||
|
||
### 7.2 Slicing plan
|
||
|
||
<!-- §7.2 pending -->
|
||
|
||
### 7.3 Rollout / launch plan
|
||
|
||
<!-- §7.3 pending -->
|
||
|
||
### 7.4 Risks & mitigations
|
||
|
||
<!-- §7.4 pending -->
|
||
|
||
## 8. Traceability matrix
|
||
|
||
<!-- §8 pending -->
|
||
|
||
## 9. Open Questions & Decisions log
|
||
|
||
<!-- §9 pending -->
|
||
|
||
## 10. Glossary & References
|
||
|
||
<!-- §10 pending -->
|