session-history/ecomm/0007/SESSION-0007.0-TRANSCRIPT-2026-06-01.md

SESSION-0007.0 — Money-rails / Load & Reward spec → BDDs (new credits/ domain)

Date: 2026-06-01 Driver: Ben Stull + Claude (Opus 4.8) Repos touched: wiggleverse-ecomm-meta (spec + corpus + release plan + session record)

Honesty note on this artifact. This is a session record authored by the assistant from the conversation — faithful as to decisions, sequence, and wrong turns, but not the raw byte-for-byte transcript.

---

Purpose

Bring the Load & Reward Policy (ecosystem-credits / money-rails spec) into the BDD corpus, keep the canonical spec doc in sync, and re-cluster the release plan to match. Two iterations of the source doc arrived mid-session (v8 then v9), so the work happened in passes. Standing rule honored throughout: "update the release clusters any time we add a new BDD."

What happened, in order

1. Oriented in the corpus + tooling. Re-read the memory, the corpus layout, the id machinery (assign_ids.py, gherkin_corpus.py — four scenario shapes), the pre-commit id-gate, and release_plan.py (the RELEASE-PLAN parser contract). Baseline: 1162 scenarios, 14 domains, parse clean.

2. Decided placement (via AskUserQuestion + Ben's correction). Asked where the money-rails scenarios should live. Ben's call: direct order payment goes into the existing payments feature (settings/payments.md, 13.10); the credit/stored-value spec gets its own new credits domain. That split tracks the spec's own §3 "two separate paths" framing exactly.

3. First spec version in play was the stale specs/Payment Strategy.md. Ben then supplied load-rail-policy_8.md (newer — it has the §3a ACH-only-credit vs. §3b vendor-handled-direct-payment split). Built the BDDs from v8.

4. Wrote the credits domain (4 feature files, shape B / raw-Gherkin like flows/): credit-instruments.md (§1–2 tiers + closed-vs-open-loop on common ownership), funding-and-loads.md (§3a/4/5 ACH-only minting, $50 floor, discount-at-spend), settlement-and-clearing.md (§6/7 pending-vs-available hold, KYC/velocity/risk, virtual value release), credit-tax.md (§8). Every file carries a GATED — do-not-build banner in its prose.

5. Added direct order payment to settings/payments.md (shape C, matching the file): vendor card / Venmo business / manual order-ID lane + the §7 "shown ≠ received ≠ settled" receipt-verification rule.

6. Assigned ids. --dry-run then real run. New credits domain = 15 (append-only max+1); features alphabetical (credit-instruments=01, credit-tax=02, funding-and-loads=03, settlement-and-clearing=04). Froze 53 credit scenarios + 11 payment scenarios (13.10.0010-0020). Corpus 1162 → 1226.

7. Updated RELEASE-PLAN (pass 1). Direct payment → R14 (9 → 20). Credits domain → the existing GATED bucket by feature-count (no ids enumerated, per the parser contract). Footer recount 369/1226. Verified: zero 15.* leaked into any buildable release.

8. Spec rename. On Ben's instruction, replaced specs/Payment Strategy.md content with v8 and renamed it specs/PaymentStrategy.md (no space). Rewrote every in-repo reference; left the historical SESSION-0001 transcript untouched. Caught a gotcha: one reference in settlement-and-clearing.md was wrapped across a line break (specs/Payment / Strategy.md), so the sed missed it — fixed by hand.

9. v9 arrived. Ben supplied load-rail-policy_9.md. Diffed v9 vs v8 and added only the genuinely new behavior:

   • settings/payments.md 13.10.0021-0026: PayPal goods&services (API + protection but priciest), PayPal sweep/freeze risk, Zelle (free/final/no-API), Zelle-is-strongest-in-person, Cash/Other off-platform, Cash/Other-still-taxable.
   • credits/funding-and-loads.md 15.03.0016-0020: PayPal/Zelle/cash each can't mint credit, "ACH is the only rail with both low cost + a confirmation API," and the §5 "when the avoided alternative is free, the discount leans on float/breakage/lock-in."
   • credits/settlement-and-clearing.md 15.04.0014: the hold exists only because ACH is reversible; final rails like Zelle wouldn't need one but don't fund credit. Replaced PaymentStrategy.md with full v9. Corpus 1226 → 1238.

10. Updated RELEASE-PLAN (pass 2). R14 20 → 26; GATED bucket counts bumped (15.03 15→20, 15.04 13→14; credits domain now 59); footer 375/1238. Re-verified zero gated leakage, R14 parses to 26 members, 0 scenarios without ids.

11. Committed + pushed. One commit 2952261 (12 files, +1756/−58; the rename detected at 56% similarity), pushed 949c92f..2952261 to origin/main over SSH. Pre-commit id-gate passed. Push fires the gitea webhook → VM re-ingest.

Decisions citable later

• credits/ is corpus domain 15 — the full ecosystem-credit / Load & Reward spec as BDDs. 59 scenarios across 4 features. GATED in perpetuity until a payments attorney confirms the licensing path AND the OHM concept→operational RFCs exist. Do NOT pull any 15.* into a build session.
• The §3 two-path split is the organizing principle. Funding credit = ACH only (the regulated, money-transmission tier → credits domain, gated). Direct order payment = vendor-handled, non-custodial, never mints credit (→ settings/payments.md 13.10, buildable in R14). "Software, not facilitator."
• Direct order payment is buildable; it's the safe side of the line. R14 holds it (now 26 scenarios) precisely because the platform records the order but the vendor collects/confirms out-of-band — no custody, no money transmission.
• Rails, ranked (v9): ACH = only credit funder (cheap+flat AND confirmable). PayPal = has API+protection but priciest → direct-only, disqualified on cost. Zelle = free+final but no merchant API → direct-only, disqualified on confirmability; strongest in-person rail. Venmo business = ~1.9%+$0.10 to shopper. Cash/Other = off-platform catch-all, still a taxable sale.
• Spec file is specs/PaymentStrategy.md (renamed from Payment Strategy.md, no space), tracking load-rail-policy v9. The BDDs cite it by that path.

Open / carried forward

• Money-rails stays GATED. Nothing in credits/ ships ahead of its RFCs + counsel. R14's direct-payment block is the only buildable money-in path for now.
• Placeholder numbers in the spec (card ~2.9%+$0.30, ACH ~$0.30, discount 2.5–3%, $50 floor) — swap for real processor rates before any build.
• Zelle revisit hook — if a bank/processor ever exposes a Zelle confirmation API, reconsider it as a credit funder (its finality would beat ACH); spec §3b notes this explicitly.
• OHM RFCs for the credit mechanic — still the gating prerequisite (Agency / Consent / Epistemic Authority / Dignity). Out of scope this session.

Session 7 closed here.