docs: add §10 open-sections backlog to maker platform strategy

Records the seven undeveloped operational axes (trust & safety, demand
GTM, legal/compliance, sustainability economics, MVP scope, data model,
governance) in rough priority order, each flagged as a future session.

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

docs/maker-platform-strategy.md

@@ -319,6 +319,26 @@ Two makers justify a thoughtful, portable data model. They do not justify a plat
 
 ---
 
+## 10. Open sections to develop (backlog)
+
+This memo is deep on the architectural/strategic axes (money flow, network mechanics, moat theory, consent) and thin on several operational ones that matter as much or more. The gaps cluster on the un-fun, operational side — which is usually where ventures actually die. Each below is a separate future session. Rough priority order; recommended next is #1.
+
+1. **Trust & safety / maker accountability (post-verification) — highest priority, moat-critical.** Verification is currently only an *entry* gate; the doc is silent on what happens when a *verified* maker behaves badly afterward. Commitment commerce makes this the signature failure mode: taking money before delivery means "verified maker collects pre-orders/deposits and ghosts" is the structurally most-likely scam, not an edge case. The money-flow stance solved the *financial* exposure (maker is MoR) but not the *reputational* one — a verified maker scamming buyers detonates the verification guarantee the whole moat rests on. Needs: verification-revocation triggers and process; a buyer-harm/dispute framework; a buyer-protection stance (mediate? warn? nothing?); how revocation propagates through the peer-verification graph (slashing the voucher); non-delivery handling given you're deliberately not in the flow.
+
+2. **Demand strategy / buyer-side go-to-market — the keystone, currently only *admitted* as a risk.** The doc names "demand is the unvalidated keystone" repeatedly but never attempts a plan; everything concrete is supply-side. Needs: a crisp *buyer-side* value proposition (why a buyer shows up and comes back, stated as its own thing); a first-100 / first-1,000-buyers plan; a content/community/SEO posture for the buyer side; and a §8 extension that tests buyer demand, not just supply. Naming the risk ≠ grappling with it.
+
+3. **Legal & compliance, consolidated — especially marketplace-facilitator sales tax.** The scattered legal points (MTL, raffle/lottery, GDPR/CCPA, FTC disclosure) need one consolidated section, and **sales-tax / marketplace-facilitator nexus is entirely absent and high-consequence**: facilitator statutes can attach tax-collection duties to a "marketplace" even when you're not the merchant of record, and the trigger is often "facilitating the transaction" — which referrals, kits, and a Phase-3 shared checkout could implicate. The staying-out-of-the-flow stance feels like it should cover this but doesn't. Also restore the **freedom-to-operate / patent check** and the **"is this novel" competitive finding** (components exist, combination is novel-but-unproven) that didn't survive generalization.
+
+4. **Sustainability economics & health metrics — there are no numbers anywhere.** "Non-profit" doesn't mean "needn't cover its costs." Needs: a back-of-envelope unit-economics model (does referral take + network subscription cover the network service + verification labor + hosting at N makers / X GMV?); and a North Star + network-health/liquidity metrics (% of GMV that's cross-maker-referred, follower growth, drop sell-through, repeat-buyer rate). The §9 gates are all qualitative.
+
+5. **Concrete MVP scope / build roadmap.** The phasing is *conceptual* (Phase 1/2/2+/3); there's no literal "v1 ships these features, in this order." Given volunteer capacity is the stated single point of failure, scope discipline is existential — define the minimum lovable build.
+
+6. **The data model (sketch the entities).** Named as the load-bearing portable asset ("cheap now, expensive to retrofit") and referenced everywhere (canonical catalog index, variant/kit BOM, referral ledger, consent records, verification graph, follow graph) but never drawn. Deserves at least an entity diagram. (May already exist in prior schema work — if so, this is a pointer, not net-new.)
+
+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.
+
+---
+
 ## Appendix A — Choosing a beachhead vertical (and sequencing expansion)
 
 The platform serves makers in general, but it must *launch* into one dense community. This is the selection method, with miniatures as the worked candidate.