docs: refine maker strategy — money-flow dial, cross-merchant transparency, membership gate

§7 + Appendix C refinements from the trust/referral working session:
- §7 money flow: spell out the Stripe Connect dial (charge type × account
  type); the out-of-flow stance holds only at Standard + direct charges +
  application_fee; flag the destination-charges default as a trap and label
  Connect config a legal-posture constraint.
- Appendix C.2: default kit-supplier settlement is now money-free (merchant
  handles obligations directly); platform notifies a supplier when their item
  sells in another's kit but moves no money; Models B/C demoted to optional.
- §7 network service: holds full per-maker order history (since join) and a
  cross-maker component-metadata layer on the catalog index.
- §7: new 'cross-merchant order transparency' principle (grocery scan-based /
  DSD analogy) — one order-history asset, three uses.
- §7 verification: the membership gate phases (start invitation-only end to
  end, loosen toward open signup once roots + density exist).
- §10 backlog: add item 8 (hybrid makers — original + resale catalogs).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/maker-platform-strategy.md

@@ -100,7 +100,12 @@ The white-label model enforces this: each storefront is the maker's brand on the
 
 **Why staying out is right:** no money-transmitter/escrow licensing (holding customer funds triggers state-by-state MTL in the US); no chargeback exposure (it hits the maker's processor, not you); no delivery-risk balance-sheet exposure; clean SaaS margins and a faster launch; and it's maker-aligned (their brand, processor, payouts, customer, data). The cost is forgoing payment take-rate — but that's exactly the slice that carries the risk you're declining, a fair, deliberate trade. The cross-maker identity moat doesn't need checkout anyway: **the asset lives at the *follow*** ("who follows which makers and commits early"), captured at the account / "notify me" / club layer you own regardless of whose processor runs the charge.
 
-If you ever want transaction economics without the MTL burden, **Stripe Connect** is the middle path — the *maker* stays merchant of record, Stripe is the transmitter, and you take an `application_fee` per transaction without holding funds. *(Verify the liability split across account types with Stripe's docs and a payments attorney before architecting — it varies by type. Not legal advice.)* But the default money model is the out-of-flow ACH/invoice fee below, with Connect reserved for the deliberate later crossings (cashable wallets, kit/taste-maker payouts).
+If you ever want transaction economics without the MTL burden, **Stripe Connect** is the middle path — but it is a *dial, not a single choice*, and only one setting preserves the stance above. Two independent knobs decide who is merchant of record and who eats the risk:
+
+- **Charge type.** *Direct charges* keep the **maker** as MoR — disputes and chargebacks hit the maker's balance, the maker pays the processing fees. *Destination charges* and *separate-charges-and-transfers* make the **platform** MoR — your balance is auto-debited for disputes, and you are now indirectly collecting and transmitting the buyer's payment, i.e. a **marketplace facilitator** for sales-tax purposes (§10 #3).
+- **Account type.** *Standard* accounts leave negative-balance and dispute liability with the maker. *Express/Custom* push it onto the **platform**, with Stripe holding reserves against *you* for connected-account shortfalls.
+
+The stance holds **only at Standard accounts + direct charges + `application_fee`**: the maker stays MoR, disputes stay on the maker's balance, you skim a fee without entering the flow. The trap is that Stripe's own marketplace tutorials default to *destination* charges (the canonical "marketplace" pattern), which silently flips every one of those properties — the payments-layer cousin of the "buy through their store" creep this memo warns about elsewhere. So **the Connect configuration is a legal-posture constraint, not an implementation detail.** The default money model remains the out-of-flow ACH/invoice fee below; Connect is reserved for the deliberate later crossings (cashable wallets, kit/taste-maker payouts), and even there uses the arm's-length setting. *(Verify per account type and per state with a payments/SALT attorney before architecting. Not legal advice.)*
 
 ### Unified phasing
 
@@ -193,7 +198,7 @@ Distinct from maker-originating ESP email, the network runs its **own** marketin
 
 Verification sits at the boundary between the commodity layer and the moat layer. Three states, not two:
 
-- **Unverified → full SaaS, zero network.** Any maker gets the complete commitment-commerce storefront (drops, pre-orders, clubs, own processor) — a paying customer of a genuinely good tool, but in *nothing* trust-gated (no referrals, no Curated-By either direction, no buyer feed, no agent feed). The storefront is commodity; gating it would suppress the Phase-1 wedge. Let everyone in the front door.
+- **Unverified → full SaaS, zero network.** Any maker gets the complete commitment-commerce storefront (drops, pre-orders, clubs, own processor) — a paying customer of a genuinely good tool, but in *nothing* trust-gated (no referrals, no Curated-By either direction, no buyer feed, no agent feed). The storefront is commodity; gating it would suppress the Phase-1 wedge. Let everyone in the front door — *once the membership gate has loosened to open signup* (the phasing note below; at launch the door itself is invitation-only).
 - **Verified → eligible** for referrals, Curated-By, buyer feed, and agent feed — eligibility, not automatic inclusion.
 - **One gate, then independent switches.** Verification is the single floor; the channel opt-ins (network, agent) are independent choices within it.
 
@@ -203,6 +208,8 @@ Verification sits at the boundary between the commodity layer and the moat layer
 
 **Verification is aspirational, not punitive — by design.** Because it gates the *demand* (referrals, feed, agents), not the *tool*, makers are pulled toward verifying rather than blocked at signup, and the unverified SaaS tier becomes a **verification funnel** (already paying, catalog in-system, upgrade = "verify → unlock demand"). It also keeps the trust guarantee **absolute**: both consumer-facing surfaces are hard-gated, so anything a buyer or agent sees is verified.
 
+**The membership gate itself phases — start closed, loosen toward open.** The three states above and the "front door / funnel" framing describe the **loosened end-state**. At **launch the gate is invitation-only, end to end**: there is no self-signup even for the unverified tool — every maker enters by invitation from an existing member who vouches they make original art or craft, rooted in a seed set Wiggleverse staff verify directly (the *originating edge*; full mechanics in the trust-&-safety section). Early scarcity is a feature: it lets word-of-mouth carry the beachhead, keeps the trust guarantee absolute while the rooted web is small, and makes every early edge high-intentionality. **Loosen toward open signup once roots and beachhead density exist** — then the unverified-tool front door opens, verification still gates the demand, and the funnel above kicks in at scale. This is the membership-gate analog of the peer-verification sequencing below (verify-makers-yourself-early → peer-verify-once-roots-exist): both start closed and open only as the trust web earns it.
+
 **Peer verification — the scaling mechanism.** Makers verify makers, staking reputation. It's *provenance verifying provenance* (real makers spot real makers), the web *is* a trust graph (harder to copy than a checkmark DB — it deepens the moat), and vouching doubles as community formation. **But it's the highest-stakes mechanism** — a Sybil/collusion surface that fails *catastrophically* (one polluted item in the "verified" feed breaks the guarantee). Build a *rooted, staked, multi-vouch trust web with a sampling audit*, never flat "anyone verified can verify anyone":
 
 - **Real, slashable stake** — a bad vouch costs the voucher (authority revoked, status reviewed), or "staked reputation" is a farmable click.
@@ -239,10 +246,12 @@ A consumer surface (site/app + email) where buyers see followed makers' drops, "
 **Two layers, kept separate — the core architectural decision.** A *storefront layer* (per maker) sits under a *shared cross-maker network service* (the moat). Conflating them couples the moat to one storefront engine and to single-tenant boundaries.
 
 - **Storefront layer (per maker).** Either your **white-label storefront** (headless backend + themed frontend) or the maker's **existing Shopify store** (federated). Handles that maker's catalog, cart, checkout, orders, and own payment processor (MoR).
-- **Shared network service (cross-tenant — the moat).** Verification graph, **canonical catalog index**, cross-maker identity/follow graph, referral/Curated-By attribution + fee/wallet ledger, buyer feed, agent/ACP feed. A standalone service with its own datastore, spanning *all* makers and federating over heterogeneous storefronts — deliberately **not** part of any storefront engine.
+- **Shared network service (cross-tenant — the moat).** Verification graph; **canonical catalog index** — *with a cross-maker component-metadata layer* ("this product contains a component made by Maker Y," the kit/BOM relationship expressed in the catalog itself); cross-maker identity/follow graph; **a complete per-maker order history** (every order since the maker joined — captured because referral/fee computation must see orders, and reused for the transparency below); referral/Curated-By attribution + fee/wallet ledger; buyer feed; agent/ACP feed. A standalone service with its own datastore, spanning *all* makers and federating over heterogeneous storefronts — deliberately **not** part of any storefront engine.
 
 **The canonical catalog index lives in the network service — not a Medusa "mega-store."** Every maker's catalog (Shopify via Admin API, your Medusa storefronts via their API, anything else via adapters) is transformed into one normalized, verified index that powers Curated-By, the feed, and agents. A Medusa instance is a *storefront* (cart, checkout, one MoR, sellable inventory); the network catalog is a read-optimized *index* of products that live and sell elsewhere. Pouring all makers into one Medusa instance would make a thing shaped like a store that must never behave like one, and couple the neutral network to one engine. Keep each storefront as the system of record; the network holds a normalized verified *projection* — which also keeps Shopify and Medusa products *co-equal sources*, not Shopify imports into a competitor-shaped container.
 
+**Cross-merchant order transparency — the positive-sum twin of the money-flow "no."** Because the network already sees every maker's orders (it must, to compute referrals) and knows which products contain other makers' components (the catalog metadata layer), it can hand each maker something no single-store tool can: **visibility into every order that touches their work anywhere in the network** — their item sold inside another maker's kit, a referral they sent that converted, a component of theirs moving through a partner's store. This is the grocery **scan-based / Direct-Store-Delivery** pattern: the supplier sees the sell-through and knows when to restock or re-engage, *without being the store*. It costs the network nothing to give (it already holds the data), it is **uniquely the network's to give** (only the cross-tenant vantage sees across stores — which deepens the moat), and it stays firmly on the right side of the line: **transparency and coordination are free; custody is not** (the kit-supplier notification in Appendix C.2 is one instance). One asset, three uses — the same order history powers the referral ledger, the network-health metrics (§10 backlog #4), and this reporting.
+
 **Build the white-label storefront on a headless backend (Medusa recommended).** "Build the 20%, rent the 80%" in code: the headless backend (Medusa — Node/TS, modular, payment-agnostic, no per-order revenue share; alternatives Saleor, Vendure, Spree) supplies cart, catalog, orders, customers, fulfillment, BYO payment, and you add the commitment-commerce engine — **drops, pre-orders, clubs, raffle/queue — as custom backend modules.** Mental model: in Medusa, *modules are backend domain logic; the storefront is a separate frontend app* consuming the Store API. So **the storefront is not a module** — the commitment-commerce *features* are modules, the storefront is their client, and the network service above is neither (standalone). Multi-tenancy (one shared instance vs. per-maker instances) is decoupled from the moat because the network service is separate either way; for two pilots, a single instance + shared theme is plenty.
 
 **Shopify makers: federate, don't migrate.** The network is storefront-agnostic, so a Shopify maker keeps Shopify (their MoR/processor) and joins via two hooks: **catalog sync** (Admin API + product webhooks into the verified index → eligible for Curated-By/feed/agents) and **referral handoff + attribution** (the Curated-By link carries a signed token that rides in as a **cart attribute → order note_attribute**, read from the order webhook to bill B / credit A — no checkout customization, any plan). **Hybrid wedge:** evergreen catalog stays on Shopify; the maker uses your platform only for the commitment-commerce *events* Shopify handles badly. Migrate later only if earned.
@@ -337,6 +346,8 @@ This memo is deep on the architectural/strategic axes (money flow, network mecha
 
 7. **Governance, concretely.** The non-profit's trust rests on governance that's been floated ("open governance / maker council") but never specified: who sets and changes verification standards, board/maker representation, and how disputes about *the network itself* resolve.
 
+8. **Hybrid makers — original + resale in one catalog.** Membership gates on a vouch that the person makes *original* art or craft, but many real makers also *resell* (supplies, others' finished goods, curated retail) alongside their own work. Open: does verification/provenance attach per-*maker* (a membership property) or per-*item* (only original pieces are trust-surface-eligible)? The moat needs per-item provenance — surfacing a verified maker's *resold*, mass-produced, or drop-shipped goods in Curated-By / the buyer feed / the agent feed would launder non-original supply through a trusted face, rebuilding Etsy's pollution from the inside. Likely shape to pressure-test: the storefront *tool* serves the whole catalog, but only items the maker attests as their own original work are eligible for the trust surfaces — which then needs an honest line between *making* (incl. finishing/assembling components) and *reselling*, per-item provenance labeling, and an enforcement/audit hook (ties to #1 accountability). Interacts with the consignment/resale "avoid" fork (§7) and the no-walled-garden value rule (Appendix D).
+
 ---
 
 ## Appendix A — Choosing a beachhead vertical (and sequencing expansion)
@@ -393,13 +404,15 @@ Model 1 has two physical variants: **A assembles** (components ship to A, A buil
 
 **Custody is the line:** the moment funds rest in an account you control and you pay them onward, you're a transmitter. "Facilitate without being in the flow" means facilitating the *coordination* (or netting on your own account as principal), never custody.
 
+**The default stance: the kit merchant (A) handles every supplier obligation; the platform moves no money at all.** A is MoR and a principal reseller, so A owes X and Y on whatever wholesale terms they agreed and **settles with them directly, off-platform**, the way any two businesses do. The platform's role is **transparency, not transfer**: it can *notify* a supplier when their item sells in someone else's kit ("your *Frostfang Drake* sold 3× in **Hearthforge**'s 'Winter Warband' kit"), so makers see their cross-maker pull — **without facilitating any payment between them.** Notification is pure coordination (free); routing a single dollar from A to X is custody (the line). This knowingly re-weighs the peer-to-peer friction below: accept the friction (notification softens it) to keep the platform *entirely* money-free. Models B and C are then **optional conveniences a maker may elect**, never the platform stepping into the flow.
+
 | Model | Mechanism | In the flow? |
 |---|---|---|
-| **A. Bookkeeper / peer-to-peer** | Platform records the payable; A→X money moves directly. | No — cleanest, but makers chasing each other is friction. |
-| **B. Net through the existing fee ledger** | X's receivable → credit in X's fee-offset wallet; A's payable → charge on A's next invoice. Principal on both sides. | No — *for the non-cashable portion.* **Recommended default.** |
+| **A. Bookkeeper / peer-to-peer (default)** | Platform records the payable and *notifies* the supplier; A→X money moves directly, off-platform. | No — the cleanest; notification offsets the "makers chasing each other" friction. |
+| **B. Net through the existing fee ledger** | X's receivable → credit in X's fee-offset wallet; A's payable → charge on A's next invoice. Principal on both sides. | No — *for the non-cashable portion.* **Optional, maker-elected** (still cashless: a fee credit, not a transfer). |
 | **C. Connect direct payout** | Buyer pays A; platform routes component cost to X/Y connected accounts; Stripe is the transmitter. | Yes — scoped re-entry. **B2B-first is the safest place to cross** (verified, KYC'd, mandate-on-file makers). |
 
-**Supplier choice with a carrot:** each supplier chooses **non-cashable wallet credit** (nets their own fees, out of flow) or **Connect payout** (real money, scoped in-flow), with a **bonus for wallet**. Caveat: wallet credit only helps a maker who *has fees to offset* — a **pure supplier** (supplies many kits, rarely sells) accrues trapped credit and needs Connect regardless. Plan for both. Phasing: Phase 1 = Models A/B (record + net, settle the remainder peer-to-peer); Phase 2 = Model C for pure suppliers, on the shared cashable rail.
+**Supplier choice with a carrot:** beyond the money-free default (A), a supplier may elect **non-cashable wallet credit** (nets their own fees, out of flow) or **Connect payout** (real money, scoped in-flow), with a **bonus for wallet**. Caveat: wallet credit only helps a maker who *has fees to offset* — a **pure supplier** (supplies many kits, rarely sells) accrues trapped credit and needs Connect regardless. Plan for both. Phasing: Phase 1 = Models A/B (record + notify + net; settle the remainder peer-to-peer); Phase 2 = Model C for pure suppliers, on the shared cashable rail.
 
 ### C.3 Fee economics — taxed once