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

Products MVP — product catalog: list + read-only detail, bulk CSV import/export, kits #12

New Issue
Closed
opened 2026-06-11 06:49:26 +00:00 by ben.stull · 1 comment
ben.stull commented 2026-06-11 06:49:26 +00:00
Owner
Copy Link
Copy Source

Summary

Products MVP: a merchant's storefront holds a real product catalog — products
(including kits) browsable as a list with navigation to a read-only product
detail — populated by bulk CSV import/export for mass data and by single-product
authoring in the admin for one-off adds.

Problem / pain

The platform today has accounts, identity, and storefronts (SD-0001,
SLICE-1–3 shipped) — but a storefront is an empty shell with nothing to sell.
A merchant who signs up and creates a storefront hits a dead end immediately:
there is no way to represent their actual business in the system. Every
downstream capability of an ecomm platform — orders, checkout, merchandising,
inventory — is blocked on a catalog existing, so the build cannot progress past
"storefront exists" and the product cannot be demoed or validated as an ecomm
at all. Merchants coming from an existing platform feel it concretely: their
catalog lives in spreadsheets and platform exports of hundreds of products,
and entering that one product at a time would be a non-starter even if an
editing UI existed. The everyday case bites the other way too — once a catalog
exists, adding a single new product should not require authoring a bulk file.

Who feels it

persona role what they need
Merchant storefront owner on the platform get their existing catalog into their storefront in bulk, add one-off products directly, and see at a glance that it loaded correctly
Migrating merchant prospective customer switching from another ecomm platform bring hundreds of products over from an export file — including bundled offerings (kits) — not re-key them one by one
Platform builder dev building product-dependent capabilities (orders, storefront browsing) a populated, inspectable catalog to build and demo against

Desired outcome / value

The platform holds the merchant's real catalog: product data — plain products
and kits — can be loaded and maintained in bulk, authored one at a time for
one-off adds, inspected in place, and round-tripped back out. A storefront stops
being an empty shell, merchants can migrate without manual re-entry, the
everyday single-product add is no longer a bulk-file chore, and every
product-dependent capability downstream is unblocked.

Acceptance — "done right"

  • A merchant can populate and update their storefront's catalog in bulk, and
    extract it back out, losslessly.
  • A merchant can also create a single product directly in the admin, for the
    one-off case.
  • The catalog is inspectable in place: all products listed (with sort, search,
    and column selection), each with a read-only detail view.
  • Kits — products grouping other products — are representable alongside plain
    products.
  • Editing and deleting existing products remain out of the MVP: the product
    detail view stays read-only, and bulk CSV plus single-product create are the
    only ways product data enters the catalog.

(Each child Feature carries the observable acceptance detail.)

Scope / non-goals

In: product list (sort/search/column selection); read-only product detail;
bulk CSV import (add + update); bulk CSV export; single-product authoring in the
admin; kits.

Out (MVP non-goals):

  • Editing or deleting existing products via the UI — the detail view is
    read-only by design; only adding products (bulk CSV or single-product create)
    is in the MVP.
  • Bulk data mechanisms beyond CSV (external integrations, bulk APIs).
  • Shopper-facing storefront product browsing/merchandising — this epic is
    the merchant-side catalog; the buyer experience is its own future ask.
  • Catalog depth beyond the MVP (variants, inventory tracking, pricing rules,
    media management) except as plain fields the data carries.

Assumptions · constraints · dependencies

  • Assumes the shipped account/storefront model (SD-0001): products belong to a
    storefront within a merchant's account (multi-tenant).
  • Depends on: SLICE-1–3 of SD-0001 (skeleton, identity, storefronts) — shipped.
  • Constraint: read-only detail (no edit/delete) is a deliberate MVP boundary,
    not an accident — keep each increment small.
  • As a type/epic, this is decomposed into Features below; each Feature
    produces its own Solution Design before an implementation plan (handbook
    §4.3 gate).

Source / signal

Self-originated — operator ask, capture session ecomm-0025 (2026-06-10);
re-sized Feature → Epic and decomposed at operator direction in capture
session ecomm-0026 (same day); single-product authoring added and the
CSV-only boundary relaxed in capture session ecomm-0031 (2026-06-11).

Priority (WSJF)

Value 8 · Time-criticality 5 · Opportunity-enablement 8 ÷ Size 5 ≈ 4.2 —
the catalog is the keystone every downstream ecomm capability waits on →
priority/P1.

Decomposition (→ Features)

  • #13 — Products: bulk CSV import/export — bulk data mechanism in the
    MVP (priority/P1)
  • #14 — Products: list (sort/search/column selection) + read-only product
    detail view (priority/P1)
  • #25 — Products: create a single product via the admin UI (priority/P1)
  • #15 — Products: kits — bundled product groupings in the catalog
    (priority/P2)
<!-- Set the type/* label --> ## Summary Products MVP: a merchant's storefront holds a real product catalog — products (including kits) browsable as a list with navigation to a read-only product detail — populated by bulk CSV import/export for mass data and by single-product authoring in the admin for one-off adds. ## Problem / pain The platform today has accounts, identity, and storefronts (SD-0001, SLICE-1–3 shipped) — but a storefront is an empty shell with nothing to sell. A merchant who signs up and creates a storefront hits a dead end immediately: there is no way to represent their actual business in the system. Every downstream capability of an ecomm platform — orders, checkout, merchandising, inventory — is blocked on a catalog existing, so the build cannot progress past "storefront exists" and the product cannot be demoed or validated as an ecomm at all. Merchants coming from an existing platform feel it concretely: their catalog lives in spreadsheets and platform exports of hundreds of products, and entering that one product at a time would be a non-starter even if an editing UI existed. The everyday case bites the other way too — once a catalog exists, adding a single new product should not require authoring a bulk file. ## Who feels it | persona | role | what they need | | --- | --- | --- | | Merchant | storefront owner on the platform | get their existing catalog into their storefront in bulk, add one-off products directly, and see at a glance that it loaded correctly | | Migrating merchant | prospective customer switching from another ecomm platform | bring hundreds of products over from an export file — including bundled offerings (kits) — not re-key them one by one | | Platform builder | dev building product-dependent capabilities (orders, storefront browsing) | a populated, inspectable catalog to build and demo against | ## Desired outcome / value The platform holds the merchant's real catalog: product data — plain products and kits — can be loaded and maintained in bulk, authored one at a time for one-off adds, inspected in place, and round-tripped back out. A storefront stops being an empty shell, merchants can migrate without manual re-entry, the everyday single-product add is no longer a bulk-file chore, and every product-dependent capability downstream is unblocked. ## Acceptance — "done right" - A merchant can populate and update their storefront's catalog in bulk, and extract it back out, losslessly. - A merchant can also create a single product directly in the admin, for the one-off case. - The catalog is inspectable in place: all products listed (with sort, search, and column selection), each with a read-only detail view. - Kits — products grouping other products — are representable alongside plain products. - Editing and deleting existing products remain out of the MVP: the product detail view stays read-only, and bulk CSV plus single-product create are the only ways product data enters the catalog. (Each child Feature carries the observable acceptance detail.) ## Scope / non-goals **In:** product list (sort/search/column selection); read-only product detail; bulk CSV import (add + update); bulk CSV export; single-product authoring in the admin; kits. **Out (MVP non-goals):** - Editing or deleting existing products via the UI — the detail view is read-only by design; only adding products (bulk CSV or single-product create) is in the MVP. - Bulk data mechanisms beyond CSV (external integrations, bulk APIs). - Shopper-facing storefront product browsing/merchandising — this epic is the merchant-side catalog; the buyer experience is its own future ask. - Catalog depth beyond the MVP (variants, inventory tracking, pricing rules, media management) except as plain fields the data carries. ## Assumptions · constraints · dependencies - Assumes the shipped account/storefront model (SD-0001): products belong to a storefront within a merchant's account (multi-tenant). - Depends on: SLICE-1–3 of SD-0001 (skeleton, identity, storefronts) — shipped. - Constraint: read-only detail (no edit/delete) is a deliberate MVP boundary, not an accident — keep each increment small. - As a `type/epic`, this is decomposed into Features below; each Feature produces its own Solution Design before an implementation plan (handbook §4.3 gate). ## Source / signal Self-originated — operator ask, capture session `ecomm-0025` (2026-06-10); re-sized Feature → Epic and decomposed at operator direction in capture session `ecomm-0026` (same day); single-product authoring added and the CSV-only boundary relaxed in capture session `ecomm-0031` (2026-06-11). ## Priority (WSJF) Value 8 · Time-criticality 5 · Opportunity-enablement 8 ÷ Size 5 ≈ **4.2** — the catalog is the keystone every downstream ecomm capability waits on → `priority/P1`. ## Decomposition (→ Features) - [ ] #13 — Products: bulk CSV import/export — bulk data mechanism in the MVP (`priority/P1`) - [ ] #14 — Products: list (sort/search/column selection) + read-only product detail view (`priority/P1`) - [ ] #25 — Products: create a single product via the admin UI (`priority/P1`) - [ ] #15 — Products: kits — bundled product groupings in the catalog (`priority/P2`)
ben.stull added the type/featurepriority/P1 labels 2026-06-11 06:49:26 +00:00
ben.stull changed title from Products MVP — catalog list + read-only detail; CSV bulk import/export as the only data mechanism to Products MVP — product catalog: list + read-only detail, bulk CSV import/export, kits 2026-06-11 06:59:36 +00:00
ben.stull added type/epic and removed type/feature labels 2026-06-11 06:59:36 +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).

The Products MVP epic was storefront catalog UX (list/detail + bulk CSV import). The canonical catalog model survives as the network's index-ingestion layer, but the epic's storefront framing is superseded. Kits split out and recast (#15).

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). The Products MVP epic was storefront catalog UX (list/detail + bulk CSV import). The canonical catalog model survives as the network's index-ingestion layer, but the epic's storefront framing is superseded. Kits split out and recast (#15). 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/epic
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#12
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?