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

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.
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.
Created the bootstrap ROADMAP (Waves 0–5: bootstrap → prototype → concept RFCs → spec → build → operate), in OHM's roadmap texture, with a next-session brief.
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.
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.
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.

8.8 KiB Raw Blame History Unescape Escape