spec(§1.6–1.9): outcomes, business scope, assumptions, business use cases BUC-1..5

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

specs/SD-0001-mvp-sign-up-and-single-storefront.md

@@ -88,19 +88,150 @@ nothing built on top can ever actually launch.
 
 ### 1.6 Targeted Business Outcomes
 
-<!-- §1.6 pending -->
+| Outcome | Success metric | Baseline → Target | Guardrail (must not regress) | How / when measured |
+| --- | --- | --- | --- | --- |
+| Merchants can exist on the platform | A real person can go from stranger to merchant-with-storefront, unaided | impossible → possible in every environment | No dark patterns at the door: no trial clock, no payment demand, no plan wall (OHM: Agency & Anti-Manipulation) | Walk the flow end-to-end in each environment at release |
+| The product line is unblocked | Subsequent Features attach to a real account + storefront spine | everything mocked → nothing mocked | The spine doesn't need rework to host the next Feature (no throwaway auth/tenancy) | First post-MVP Feature builds on it without spine changes |
+| Launching anywhere is routine | A fresh, empty environment reaches "first merchant signs up and creates the first storefront" through the product flows alone | folklore → documented, rehearsed gesture | Zero hand-seeded data in any environment | Bootstrap rehearsal executed on pre-prod, then prod, at release |
 
 ### 1.7 Scope (business)
 
-<!-- §1.7 pending -->
+- **In scope:** a person establishing an identity on the platform (joining and
+  returning); a merchant establishing their one storefront; the merchant
+  standing on a stable management surface for it; the platform being
+  bring-up-able from empty in every environment it runs in (local development,
+  pre-production, production).
+- **Out of scope (later designs):** anything sold or bought — catalog, orders,
+  checkout, payments; the shopper-facing public storefront; teams/staff
+  (anyone besides the one merchant touching the storefront); plans, billing,
+  or any commercial relationship between merchant and platform; storefront
+  settings/management beyond simply *having* the surface.
+- **Non-goals:** gating who may join (the prototype admitted users by
+  invitation; ecomm is an open product — anyone may become a merchant, and
+  re-introducing an admission gate is explicitly not pursued); supporting more
+  than one storefront per merchant *in this design* (the business wants the
+  door left open, not the capability now).
 
 ### 1.8 Assumptions · Constraints · Dependencies
 
-<!-- §1.8 pending -->
+- **Assumptions:**
+  - One storefront per merchant is the right *experience* bar for the MVP;
+    multiple-storefront merchants are a future need, not a current one. Risk
+    if wrong: an early merchant genuinely needs a second storefront — accepted;
+    the door is designed to stay open (§1.7, #1 acceptance).
+  - Merchants are reachable by email and will complete an email-based step to
+    join. Risk if wrong: an entry channel rethink — accepted at MVP scale.
+- **Constraints:**
+  - OHM-groundedness is a charter constraint: entry must be honest — no
+    manufactured urgency, no data collected beyond need, no lock-in mechanics.
+  - The three environments are a constraint, not a stretch goal: Feature #1's
+    acceptance says no environment is "later".
+  - Wiggleverse engineering standards apply (handbook): provisioning and
+    deploy via flotilla (§8), secrets never in repos or transcripts (§6.3),
+    private repos by default (§5.5).
+- **Dependencies:**
+  - **flotilla / launch-app** for environment provisioning and deploy (the
+    operator-run front door, handbook §8.5) — needed when the pre-prod and
+    prod environments are stood up.
+  - An **email delivery channel** for the entry step in real environments —
+    needed by the production-readiness slice (§7).
 
 ### 1.9 Business Use Cases
 
-<!-- §1.9 pending -->
+**BUC-1 — As a merchant, I can establish my identity on the platform, so that I can begin doing business there.**
+
+```gherkin
+Scenario: BUC-1 — A stranger becomes known to the platform
+  Given a person who has never dealt with the platform
+  When they present themselves and prove who they are
+  Then the platform knows them as a returning individual from then on
+  And they were asked for nothing beyond what proving who they are required
+```
+
+```gherkin
+Scenario: BUC-1a — A person who cannot prove who they are is not admitted as someone else
+  Given a person presenting an identity they cannot prove
+  When their proof fails
+  Then the platform does not mistake them for the claimed identity
+  And the genuine owner of that identity is unharmed
+```
+
+- **BUC-1 acceptance criteria:** the same person, returning later, is
+  recognized as the same merchant; two different people are never conflated;
+  no personal data beyond the minimum was demanded (OHM: Privacy & Data
+  Minimization).
+
+**BUC-2 — As a returning merchant, I can resume my standing on the platform, so that my business presence persists beyond a single visit.**
+
+```gherkin
+Scenario: BUC-2 — A known merchant returns
+  Given a merchant the platform already knows
+  When they return and prove who they are
+  Then they resume exactly the standing they had — same identity, same storefront
+```
+
+- **BUC-2 acceptance criteria:** returning costs only the proof-of-identity
+  step; nothing about their standing is lost or reset.
+
+**BUC-3 — As a merchant, I can establish my storefront, so that my business has a presence of its own on the platform.**
+
+```gherkin
+Scenario: BUC-3 — A merchant claims their storefront
+  Given a merchant known to the platform who has no storefront yet
+  When they establish their storefront
+  Then the platform holds exactly one storefront that is theirs
+  And establishing it cost them nothing and committed them to nothing
+```
+
+```gherkin
+Scenario: BUC-3a — One storefront is the bar
+  Given a merchant who already has their storefront
+  When they deal with the platform
+  Then they are never led toward acquiring a second one
+```
+
+- **BUC-3 acceptance criteria:** every merchant who completes the step has
+  exactly one storefront; no payment, plan, or commitment was demanded
+  (corpus: 14.01.0015, 14.01.0016); the platform's books would still be
+  correct if a merchant were someday allowed several (the 1-1 bar is an
+  experience rule, not a law of the data — Feature #1 constraint).
+
+**BUC-4 — As a merchant, I can stand on a management surface for my storefront, so that everything I will later do for my business has a home.**
+
+```gherkin
+Scenario: BUC-4 — The merchant arrives at their storefront's home
+  Given a merchant with a storefront
+  When they return to the platform
+  Then they arrive directly at their storefront's management surface
+  And it is honestly empty — it claims no capability that does not exist yet
+```
+
+- **BUC-4 acceptance criteria:** arrival is direct (no dead ends, no limbo —
+  a merchant *without* a storefront is guided to establish one instead, never
+  stranded); the surface carries the storefront's identity and nothing
+  fabricated.
+
+**BUC-5 — As a platform operator, I can bring the platform to life in a fresh environment, so that merchants can be served there without any hand-built state.**
+
+```gherkin
+Scenario: BUC-5 — An empty environment reaches its first merchant
+  Given a brand-new environment with empty persistence
+  When the operator performs the documented bring-up gesture
+  And the first merchant walks the ordinary product flows
+  Then the environment serves that merchant a working storefront
+  And no data was placed by hand at any step
+```
+
+```gherkin
+Scenario: BUC-5a — Bring-up is rehearsable
+  Given the bring-up gesture documented for one environment
+  When it is performed in the next environment (dev → pre-prod → prod)
+  Then it is the same gesture, and day-one production is simply the bootstrap state
+```
+
+- **BUC-5 acceptance criteria:** bring-up is a repeatable, documented gesture
+  (not folklore); it holds identically in local development, pre-production,
+  and production; the first merchant arrives through the product flows alone.
 
 ---