Network: cross-maker composite kits (multi-maker bundle, component referral fees, settlement) #15

New Issue

2026-06-11T06:59:00Z

ben.stull commented

2026-06-11 06:59:00 +00:00

Recast (session 0036). Under the network pivot, kits are no longer a single-store "bundled product groupings" feature — they become the cross-maker composite kit of network_strategy.md Appendix C: one SKU combining components from multiple makers, sold by a lead maker who is the principal reseller / assembler (merchant of record), with per-component referral fees, a non-cashable fee-offset settlement ledger, and assemble-and-consolidate fulfillment. This is a network-service concern (catalog index + referral/settlement ledger), not a storefront catalog feature. Re-scope against the network Solution Design when it exists.

Original (single-store) description retained below for history.

Summary

Kits: a merchant's catalog can represent kits — products offered as a
grouping of other products — alongside plain products.

Problem / pain

Real merchant catalogs are not flat: many sell bundled offerings (a kit
composed of other catalog products). With only flat products representable, a
merchant whose business includes kits cannot bring their catalog over
faithfully — the kit structure is lost on import, the catalog the platform
holds misrepresents what they actually sell, and every downstream capability
built on the catalog inherits that misrepresentation.

Who feels it

persona	role	what they need
Merchant with bundled offerings	storefront owner whose catalog includes kits	represent kits and their component products as they actually sell them
Migrating merchant	prospective customer switching platforms	a faithful import — kit structure preserved, not flattened away

Desired outcome / value

The catalog represents kits as first-class members: a kit and its component
products survive the trip into the platform intact, so merchants with bundled
offerings can adopt the platform without misrepresenting their business.

Acceptance — "done right"

A kit — a product grouping other catalog products — is representable in the
catalog.
Kits appear in the product list, and a kit's read-only detail view shows its
component products.
Kit data rides the same bulk CSV import/export mechanism as other product
data, round-tripping losslessly.

Scope / non-goals

In: representing kits and their components in the catalog; their
appearance in the list/detail surfaces; their carriage in CSV import/export.

Out: kit pricing/discount rules, inventory semantics, and
nested-kit-of-kits questions unless the Solution Design pulls them in — the
exact kit semantics are an open design question, deliberately not settled at
capture.

Assumptions · constraints · dependencies

Parent: #12 (Products MVP epic).
Siblings: depends on the catalog surfaces (list/detail Feature) and the data
mechanism (CSV import/export Feature) existing for kits to ride on.
Open question for the design: what a kit means here (pricing, inventory,
nesting) — the capture records the business need, not the semantics.
As a type/feature, requires a Solution Design before an implementation
plan (handbook §4.3 gate).

Source / signal

Operator ask, capture session ecomm-0026 (2026-06-10) — named by the
operator while decomposing Epic #12.

Priority (WSJF)

Value 5 · Time-criticality 3 · Opportunity-enablement 4 ÷ Size 4 ≈ 3.0 —
real but behind the two foundational siblings → priority/P2 (provisional;
raise if kit-carrying catalogs are the near-term migration target).

Decomposition

Deferred — slicing belongs to the Feature's Solution Design (handbook §4.3).

**Recast (session 0036).** Under the network pivot, kits are no longer a single-store "bundled product groupings" feature — they become the **cross-maker composite kit** of `network_strategy.md` Appendix C: one SKU combining components from multiple makers, sold by a lead maker who is the **principal reseller / assembler** (merchant of record), with **per-component referral fees**, a **non-cashable fee-offset settlement ledger**, and **assemble-and-consolidate** fulfillment. This is a network-service concern (catalog index + referral/settlement ledger), not a storefront catalog feature. Re-scope against the network Solution Design when it exists. --- _Original (single-store) description retained below for history._  ## Summary Kits: a merchant's catalog can represent kits — products offered as a grouping of other products — alongside plain products. ## Problem / pain Real merchant catalogs are not flat: many sell bundled offerings (a kit composed of other catalog products). With only flat products representable, a merchant whose business includes kits cannot bring their catalog over faithfully — the kit structure is lost on import, the catalog the platform holds misrepresents what they actually sell, and every downstream capability built on the catalog inherits that misrepresentation. ## Who feels it | persona | role | what they need | | --- | --- | --- | | Merchant with bundled offerings | storefront owner whose catalog includes kits | represent kits and their component products as they actually sell them | | Migrating merchant | prospective customer switching platforms | a faithful import — kit structure preserved, not flattened away | ## Desired outcome / value The catalog represents kits as first-class members: a kit and its component products survive the trip into the platform intact, so merchants with bundled offerings can adopt the platform without misrepresenting their business. ## Acceptance — "done right" - A kit — a product grouping other catalog products — is representable in the catalog. - Kits appear in the product list, and a kit's read-only detail view shows its component products. - Kit data rides the same bulk CSV import/export mechanism as other product data, round-tripping losslessly. ## Scope / non-goals **In:** representing kits and their components in the catalog; their appearance in the list/detail surfaces; their carriage in CSV import/export. **Out:** kit pricing/discount rules, inventory semantics, and nested-kit-of-kits questions unless the Solution Design pulls them in — the exact kit semantics are an open design question, deliberately not settled at capture. ## Assumptions · constraints · dependencies - Parent: #12 (Products MVP epic). - Siblings: depends on the catalog surfaces (list/detail Feature) and the data mechanism (CSV import/export Feature) existing for kits to ride on. - Open question for the design: what a kit *means* here (pricing, inventory, nesting) — the capture records the business need, not the semantics. - As a `type/feature`, requires a Solution Design before an implementation plan (handbook §4.3 gate). ## Source / signal Operator ask, capture session `ecomm-0026` (2026-06-10) — named by the operator while decomposing Epic #12. ## Priority (WSJF) Value 5 · Time-criticality 3 · Opportunity-enablement 4 ÷ Size 4 ≈ **3.0** — real but behind the two foundational siblings → `priority/P2` (provisional; raise if kit-carrying catalogs are the near-term migration target). ## Decomposition Deferred — slicing belongs to the Feature's Solution Design (handbook §4.3).

ben.stull added the type/feature priority/P2 labels 2026-06-11 06:59:00 +00:00

ben.stull referenced this issue

2026-06-11 06:59:36 +00:00

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

ben.stull referenced this issue

2026-06-12 16:16:23 +00:00

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

ben.stull changed title from ~~Products: kits — bundled product groupings in the catalog~~ to Network: cross-maker composite kits (multi-maker bundle, component referral fees, settlement)

2026-06-12 16:16:46 +00:00

ben.stull referenced this issue

2026-06-12 16:32:01 +00:00

Pivot: strip storefront → network-service seed (v0.9.0) #33

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiggleverse/wiggleverse-ecomm#15