wiggleverse/wiggleverse-ecomm
2
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity

MVP: sign up and create a single storefront #1

New Issue
Closed
opened 2026-06-10 08:22:30 +00:00 by ben.stull · 1 comment
ben.stull commented 2026-06-10 08:22:30 +00:00
Owner
Copy Link
Copy Source

Summary

A person can sign up for ecomm (or log in), create their one storefront, and
land on its admin page — the first end-to-end vertical slice of the platform.

Problem / pain

ecomm is a clean greenfield rebuild with no app code yet. There is no way for
anyone to have an identity on the platform, let alone a storefront. Until a
merchant can sign up and own a storefront, every other capability of the
platform (catalog, orders, checkout, policies) has nowhere to attach — the
account → storefront spine is the substrate everything else needs.

Who feels it

  • Merchant (the storefront owner) — the primary persona: today they cannot
    exist on the platform at all.
  • The ecomm team — every subsequent release presupposes an authenticated
    account that owns a storefront; this Feature unblocks the whole line.

Desired outcome / value

A working first increment: a visitor becomes an authenticated merchant with
exactly one storefront and a stable admin surface to grow into — so that
subsequent releases can attach real features (catalog, orders, …) to a real
account + storefront spine instead of mocks.

Acceptance — "done right"

  • A new visitor can sign up, and is taken directly into creating their
    storefront.
  • A returning user without a storefront is prompted to create one on
    log-in.
  • A returning user with a storefront lands on that storefront's admin
    page     (intentionally empty for this release — a shell with the storefront's
    identity, nothing more).
  • One storefront per account is enforced in the UX (no "create another"
    affordance); the door stays open for many-per-account later.
  • The flows above work end to end against real persistence — no stubbed auth,
    no in-memory-only storefronts.
  • The flows hold in every environment — localhost/dev, PPE, and Prod —
    each with a defined bootstrap story: a fresh environment (empty
    persistence) reaches "first merchant signs up and creates the first
    storefront" through the product flows alone, with no hand-seeded data.
    • localhost/dev: a dev brings the app up from a clean checkout
      (deps, empty local store, migrations/schema) and completes sign-up →
      storefront → admin locally.
    • PPE: the deployed pre-prod environment bootstraps the same way and
      serves as the rehearsal for Prod.
    • Prod: same bootstrap path; day-one Prod is simply the bootstrap state.

Scope / non-goals

In scope: sign-up, log-in, the create-storefront flow (both entry points),
the empty admin landing page, and the environment story — the MVP runs in
localhost/dev, PPE, and Prod, each bootstrappable from empty (no environment is
"later").

Non-goals (this release):

  • Multiple storefronts per account (future — UX is 1-1 for now; whether the
    data model is 1-1 is a spec decision, lean toward keeping it open).
  • Any actual admin functionality (catalog, orders, settings, theming).
  • The shopper-facing public storefront.
  • Account-lifecycle polish (password reset, email verification, deletion) —
    the spec decides the minimum honest bar for the MVP.

Assumptions · constraints · dependencies

  • Greenfield: the architecture is intentionally undecided in
    wiggleverse-ecomm; this Feature's brainstorming/spec session is where it
    gets decided (multi-tenant, OHM-grounded — per the repo charter).
  • 1-1 account↔storefront is a UX constraint, not necessarily a schema
    constraint — the spec resolves how the model stays open to many-per-account.
  • The reference prototype (wiggleverse-ecomm-prototype, R01–R07) is read-only
    prior art — consult it, don't depend on it.
  • Environments follow the Wiggleverse standard: provisioning and deploy go
    through flotilla (handbook §8), with the PPE → Prod pipeline as the promotion
    path. The spec decides what "bootstrap" concretely is per environment
    (migrations, first-run state, any operator gesture) — but it must be a
    repeatable, documented gesture, not folklore.
  • Parent: none (first issue of the clean rebuild). Blocked by: nothing.
    Blocks: effectively all subsequent ecomm Features.

Source / signal

Self-originated — capture session ecomm-0019 (2026-06-10): the operator's
opening prompt describing the very first MVP of ecomm.

Priority (WSJF)

Value 8 · Time-criticality 8 · Opportunity-enablement 9 ÷ Size 5 = 5.0 —
priority/P1. It is the keystone first increment: high enablement (everything
queues behind it), no external deadline.

Decomposition

Provisional slice checklist (JIT — firmed up at spec/plan time, one level only):

  • Account sign-up and log-in (auth foundation)
  • Create-storefront flow (post-sign-up, and the log-in-without-storefront
    prompt)
  • Storefront admin landing page (empty shell)
  • Environment bootstrap (localhost/dev · PPE · Prod): fresh-environment
    bring-up to first sign-up, repeatable and documented

Solution notes (optional — NOT a design)

  • Architecture (stack, tenancy model, storage) is decided in the Feature's
    brainstorming session, not here.
  • The prototype's R01–R07 layering (layered backend, pluggable
    platform/storage) is available as reference material.
  • Cloud SQL sizing (2026-06-10, post-spec discussion): start PPE and
    Prod at db-f1-micro while the customer count is ~2. Knowingly accepted:
    shared-core tiers carry no Cloud SQL SLA (consistent with the pre-v1
    availability bar in SD-0001 §6.6) and cap connections (~25 — fine for one
    app process with a small pool). Resizing later is a config edit + a
    minutes-long restart, so undersizing is cheap to undo. PPE's instance can
    be stopped when idle (storage-only cost). Per SD-0001 v0.3.0 (D-7,
    INV-8) the tier is deployment config, set at SLICE-4 provisioning — not
    spec or framework content.
<!-- Set the type/* label: type/feature --> ## Summary A person can sign up for ecomm (or log in), create their one storefront, and land on its admin page — the first end-to-end vertical slice of the platform. ## Problem / pain ecomm is a clean greenfield rebuild with no app code yet. There is no way for anyone to have an identity on the platform, let alone a storefront. Until a merchant can sign up and own a storefront, every other capability of the platform (catalog, orders, checkout, policies) has nowhere to attach — the account → storefront spine is the substrate everything else needs. ## Who feels it - **Merchant** (the storefront owner) — the primary persona: today they cannot exist on the platform at all. - **The ecomm team** — every subsequent release presupposes an authenticated account that owns a storefront; this Feature unblocks the whole line. ## Desired outcome / value A working first increment: a visitor becomes an authenticated merchant with exactly one storefront and a stable admin surface to grow into — so that subsequent releases can attach real features (catalog, orders, …) to a real account + storefront spine instead of mocks. ## Acceptance — "done right" - A new visitor can **sign up**, and is taken directly into creating their storefront. - A returning user **without** a storefront is prompted to create one on log-in. - A returning user **with** a storefront lands on that storefront's **admin page** (intentionally empty for this release — a shell with the storefront's identity, nothing more). - **One storefront per account** is enforced in the UX (no "create another" affordance); the door stays open for many-per-account later. - The flows above work end to end against real persistence — no stubbed auth, no in-memory-only storefronts. - The flows hold in **every environment** — localhost/dev, PPE, and Prod — each with a defined **bootstrap story**: a fresh environment (empty persistence) reaches "first merchant signs up and creates the first storefront" through the product flows alone, with no hand-seeded data. - **localhost/dev:** a dev brings the app up from a clean checkout (deps, empty local store, migrations/schema) and completes sign-up → storefront → admin locally. - **PPE:** the deployed pre-prod environment bootstraps the same way and serves as the rehearsal for Prod. - **Prod:** same bootstrap path; day-one Prod is simply the bootstrap state. ## Scope / non-goals **In scope:** sign-up, log-in, the create-storefront flow (both entry points), the empty admin landing page, and the **environment story** — the MVP runs in localhost/dev, PPE, and Prod, each bootstrappable from empty (no environment is "later"). **Non-goals (this release):** - Multiple storefronts per account (future — UX is 1-1 for now; whether the data model is 1-1 is a spec decision, lean toward keeping it open). - Any actual admin functionality (catalog, orders, settings, theming). - The shopper-facing public storefront. - Account-lifecycle polish (password reset, email verification, deletion) — the spec decides the minimum honest bar for the MVP. ## Assumptions · constraints · dependencies - **Greenfield:** the architecture is intentionally undecided in `wiggleverse-ecomm`; this Feature's brainstorming/spec session is where it gets decided (multi-tenant, OHM-grounded — per the repo charter). - 1-1 account↔storefront is a **UX constraint**, not necessarily a schema constraint — the spec resolves how the model stays open to many-per-account. - The reference prototype (`wiggleverse-ecomm-prototype`, R01–R07) is read-only prior art — consult it, don't depend on it. - Environments follow the Wiggleverse standard: provisioning and deploy go through flotilla (handbook §8), with the PPE → Prod pipeline as the promotion path. The spec decides what "bootstrap" concretely is per environment (migrations, first-run state, any operator gesture) — but it must be a repeatable, documented gesture, not folklore. - Parent: none (first issue of the clean rebuild). Blocked by: nothing. Blocks: effectively all subsequent ecomm Features. ## Source / signal Self-originated — capture session **ecomm-0019** (2026-06-10): the operator's opening prompt describing the very first MVP of ecomm. ## Priority (WSJF) Value 8 · Time-criticality 8 · Opportunity-enablement 9 ÷ Size 5 = **5.0** — `priority/P1`. It is the keystone first increment: high enablement (everything queues behind it), no external deadline. ## Decomposition Provisional slice checklist (JIT — firmed up at spec/plan time, one level only): - [ ] Account sign-up and log-in (auth foundation) - [ ] Create-storefront flow (post-sign-up, and the log-in-without-storefront prompt) - [ ] Storefront admin landing page (empty shell) - [ ] Environment bootstrap (localhost/dev · PPE · Prod): fresh-environment bring-up to first sign-up, repeatable and documented ## Solution notes (optional — NOT a design) - Architecture (stack, tenancy model, storage) is decided in the Feature's brainstorming session, not here. - The prototype's R01–R07 layering (layered backend, pluggable platform/storage) is available as reference material. - **Cloud SQL sizing (2026-06-10, post-spec discussion):** start PPE **and** Prod at **db-f1-micro** while the customer count is ~2. Knowingly accepted: shared-core tiers carry no Cloud SQL SLA (consistent with the pre-v1 availability bar in SD-0001 §6.6) and cap connections (~25 — fine for one app process with a small pool). Resizing later is a config edit + a minutes-long restart, so undersizing is cheap to undo. PPE's instance can be **stopped when idle** (storage-only cost). Per SD-0001 v0.3.0 (D-7, INV-8) the tier is deployment config, set at SLICE-4 provisioning — not spec or framework content.
ben.stull added the type/featurepriority/P1 labels 2026-06-10 08:22:30 +00:00
ben.stull commented 2026-06-12 16:16:23 +00:00
Author
Owner
Copy Link
Copy Source

Closing as part of the pivot from a generic multi-tenant Shopify-alternative storefront to the commitment-commerce + cross-maker verified referral network direction (see ecomm-content/rfcs/network_strategy.md; session 0036).

Single-storefront sign-up/onboarding is old-direction: the storefront becomes a separate headless Medusa engine, and sign-up/identity move to the platform-wide wgl-identity service. Superseded.

Nothing is lost — code stays in git history and the issue can be reopened if it resurfaces under the network architecture.

Closing as part of the pivot from a generic multi-tenant Shopify-alternative storefront to the commitment-commerce + cross-maker verified referral **network** direction (see `ecomm-content/rfcs/network_strategy.md`; session 0036). Single-storefront sign-up/onboarding is old-direction: the storefront becomes a separate headless Medusa engine, and sign-up/identity move to the platform-wide `wgl-identity` service. Superseded. Nothing is lost — code stays in git history and the issue can be reopened if it resurfaces under the network architecture.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
priority/P0
Priority: highest — drop everything
 priority/P1
Priority: high
 priority/P2
Priority: medium
 priority/P3
Priority: low / someday
 type/bug
Type: a defect in shipped behaviour — small leaf work, straight to a plan
 type/epic
Type: a large body of work spanning many features
 type/feature
Type: a deliverable capability under an epic
 type/story
Type: a user story — the smallest valuable increment
 type/task
Type: a concrete unit of work under a story
No Label priority/P1 type/feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ben.stull (Ben Stull) ohm-bot
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: wiggleverse/wiggleverse-ecomm#1
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?