# SESSION-0001.0 — ecomm bootstrap

**Date:** 2026-05-30
**Driver:** Ben Stull + Claude (Opus 4.8)
**Repos touched:** wiggleverse-ecomm-meta, wiggleverse-ecomm,
wiggleverse-ecomm-flotilla, wiggleverse-ecomm-prototype, engineering (local
edit, uncommitted)

> **Honesty note on this artifact.** This is a *session record* authored by
> the assistant from the conversation — faithful and uncurated as to
> decisions, sequence, and wrong turns, but **not** the raw byte-for-byte
> transcript. OHM publishes raw transcripts via `ohm-infra`'s
> `publish-transcript.sh`; ecomm has no such tooling yet. Building a
> transcript-dump path is a future roadmap item. Until then, records like
> this stand in — labeled as what they are.

---

## Purpose

First session of the ecomm project — the **first software built on the OHM
RFCs**. Goal was framing and bootstrap, not building the app: align on the
framework, capture the business context, and get the RFC-consumption flow +
repos set up. Per Ben: "don't worry about exactly what will be built yet."

## What happened, in order

1. **Framework alignment.** Read the canonical sources before answering:
   `engineering/README.md` (the wiggleverse pattern), `ohm-rfc/RFC-0001`
   (Human), `ohm-rfc/CONTRIBUTING.md` (RFC process), and crucially
   `ohm-rfc/OPERATIONAL-MODEL.md` (concept vs operational RFCs; the gate;
   "consume OHM as contracts"). Surfaced three forking questions.

2. **Three framework decisions (settled):**
   - **Everything becomes an OHM RFC** — every load-bearing concept, human
     *and* commerce (Product, Order, Cart, Payment), lands in `ohm-rfc`,
     defined in relation to the Human it serves. *Conscious tension noted:*
     this broadens OHM past its strictly-"Open Human Model" self-description
     (RFC-0001/README) — flagged for an explicit corpus note later.
   - **Prototype-first** (guide §2) — throwaway vibe-code → `SPEC.md` from
     it; binding code inherits nothing.
   - **New standalone product** — own framework repo + own flotilla;
     consumes OHM RFCs as contracts; shares no code with `rfc-app`.

3. **Created the bootstrap ROADMAP** (Waves 0–5: bootstrap → prototype →
   concept RFCs → spec → build → operate), in OHM's roadmap texture, with a
   next-session brief.

4. **Business context (Hasan & Connie).** ecomm is a **multi-tenant Shopify
   alternative** (online storefronts + in-person POS). This *resolved* the
   biggest open shape question — multi-tenant platform, not per-customer
   deployments. Hasan: 3D printing + laser/wood maker goods. Connie:
   miniatures, large Facebook-group following, B&M industry in crisis.
   Revenue: implementation/maintenance via Ben's consultancy "Ben bets on
   us" (hourly, not platform code); no referral/markup/ad revenue; the
   "breakage"/prepaid-balance mechanic funds the platform ethically.

5. **Payment Strategy doc received & integrated** (`load-rail-policy_7.md` →
   `specs/Payment Strategy.md`). This materially sharpened *and corrected*
   the model:
   - **Wrong turn corrected:** earlier we (Ben + assistant) both said
     balances "earn interest" for customers. The doc is explicit — the
     **platform** earns yield on **safeguarded float**, and you **cannot pay
     holders interest or lend the float**. The customer reward is a
     **discount at spend**, funded by avoided card fees + float yield +
     breakage. Roadmap + memory fixed.
   - **Legal gate elevated:** the cross-owner "platform credit" tier is
     **open-loop = money transmission** (trigger is common ownership, not
     cash-out). Needs a licensed program-manager/BIN sponsor and
     **attorney sign-off before building**. Captured as a hard pre-build
     gate. The closed-loop single-owner "shop gift card" tier is the light
     regime. Channel rule ("release only on settled funds") tied to the POS
     requirement.

6. **Repos configured.** Scaffolded four repos under `ecomm/git/`, moved the
   roadmap + renamed the payment spec into `-meta`, added a "standard repo
   set" table to `engineering/README.md` §5, initial-committed each, and
   pushed to Gitea:
   - `wiggleverse/wiggleverse-ecomm-meta` — roadmap, specs, sessions, docs
   - `wiggleverse/wiggleverse-ecomm` — implementation placeholder
   - `wiggleverse/wiggleverse-ecomm-flotilla` — operator-CLI stub
   - `ben.stull/wiggleverse-ecomm-prototype` — throwaway
   - *Wrong turn:* the assistant tried to ask remote-namespace + transcript
     questions via a structured prompt; Ben interrupted/rejected it and
     simply pasted the four created remote URLs — literal
     `wiggleverse-ecomm-*` names, prototype under `ben.stull/`. Faster.
   - Identified there's no `tea`/`gh` CLI on the machine, so remote creation
     was Ben's (operator) gesture; the assistant only wired `origin` +
     pushed (HTTPS creds were cached).

## Decisions citable later

- OHM = single dictionary for all concepts (human + commerce). [framework #1]
- Prototype-first; standalone product. [framework #2, #3]
- Multi-tenant platform; Hasan & Connie are merchants #1 and #2.
- Float yield ≠ holder interest; reward is discount-at-spend. [Payment Strategy §5]
- Platform-credit tier = money transmission → attorney gate before build.
- Standard repo set documented in engineering guide §5.

## Open / carried forward

- **engineering/README.md §5 edit is uncommitted** — left for Ben to land
  (branch+PR per the guide's own rule) or handle in the engineering repo.
- **Pending input:** the broader payments / business-model walkthrough (the
  ethics/economics doc is in hand).
- **Transcript tooling** for ecomm (a `publish-transcript`-equivalent) is
  not built; records are hand-authored for now.
- **OHM self-description broadening** wants an explicit corpus note/RFC.

## Next session

**Wave 1 — vibe-code the throwaway prototype** in
`wiggleverse-ecomm-prototype`. The kickoff prompt below was handed to Ben in
chat at session close (per engineering guide §6 — next-session prompt
delivered before publishing).

```
This is Session 2 of the ecomm project — Wave 1: vibe-code the throwaway prototype.
ecomm is the first software built on the OHM RFCs, following the wiggleverse
engineering pattern. Don't build the "real" software this session — this is
discovery.

READ FIRST (in this order):
- Your memory for this project (ecomm-business-context, ecomm-framework-decisions,
  wiggleverse-engineering-pattern).
- ~/projects/wiggleverse/ecomm/git/wiggleverse-ecomm-meta/ROADMAP.md — especially
  the "Operating instructions for the next session" block at the bottom, and the
  "Payments & credits model" section.
- ~/projects/wiggleverse/ecomm/git/wiggleverse-ecomm-meta/specs/Payment Strategy.md
- ~/projects/wiggleverse/ecomm/git/wiggleverse-ecomm-meta/sessions/SESSION-0001.0-TRANSCRIPT-2026-05-30.md
- ~/projects/wiggleverse/engineering/README.md §2 (prototype-first) and
  ~/projects/wiggleverse/ohm-rfc/OPERATIONAL-MODEL.md (concept→operational RFCs).

TASK: Build a throwaway, vibe-coded prototype of the ecomm platform in the
wiggleverse-ecomm-prototype repo (~/projects/wiggleverse/ecomm/git/wiggleverse-ecomm-prototype).
ecomm is a multi-tenant Shopify alternative: merchants run online storefronts AND
take in-person payment (it replaces their POS register).

DRIVE IT WITH REAL SCENARIOS:
- Hasan — 3D printing + laser cutting/engraving on wood (physical maker goods).
- Connie — miniatures / dollhouse items / knick-knacks; big Facebook-group following.
- The in-person POS flow (a sale at a trade show / in the shared shop).

CONSTRAINTS (this is a prototype, not the product):
- Super wobbly. No spec, no tests, no deploy discipline, no engineering standards.
- Runs locally or on a tiny disposable VM we tear down. Nothing is operated or kept.
- FAKE the credits/load/spend UX freely — mock money, no real ACH, no KYC, no
  licensing. BUT keep two things visible because they drive the real design:
  (1) the two-tier credit structure (platform credit vs. shop gift card), and
  (2) the channel rule "release value only on funds confirmed settled in your own
  account" (in person: refresh YOUR app, never the customer's screen).
- Do NOT write into the real implementation repo (wiggleverse-ecomm), do NOT deploy,
  do NOT touch real money or real customer data.

GOAL: Discover the shape — data model, the hard parts, what feels right. Collect the
load-bearing concepts you surface (Merchant, Storefront, Product, Cart, Order,
Payment, Credit/Balance, etc.) toward a concept inventory for Wave 2 — but do NOT
halt the vibe-code to author RFCs (that's a later wave). Build more than one framing
if the shape is unclear.

DONE WHEN: we can describe the system as contracts and invariants rather than "watch
it run" — that's the signal to stop prototyping and move to SPEC.md (Wave 3). End the
session by listing the concepts that surfaced and any shape questions for the spec.
```

*Session 1 closed here.*