CremaBuy-Me-A-Coffee

Crema is a tip page: pick a preset or custom amount, leave an optional name and a public note (or stay anonymous), and show up on a supporter wall. The point was to show that a payment button is only a small piece of a payment flow. Validation, cancellation, signed confirmation, duplicate handling, and a receipt are the rest of it, and I wanted all of that without moving any money.

No Stripe calls were made. The hosted test checkout and real webhook delivery were never exercised, only the signed local path. Storage is a single-process JSON file. This is a local demo, not a payment service, and it is not hardened.

This was a Codex row. On September 23 I brought Codex in, and the coordinator wrote 00-system/capstone-split.md: a Codex list, a Claude Code list, a tool-guard override authorizing Codex to build these, and a protocol. Each builder works only in its own project folders, writes a LOG-ENTRY.json there, and never touches the shared tracker or logs. Claude Code merges every entry after checking it.

The folder already held partial work from an earlier interrupted session. The split file said to keep whatever passes its tests, and Codex did: it reused a 257-check backend and core, added three tests for native constant-time comparison, built the interface, and ran the full demo in Chrome. The session time was about 0.12 hours on top of that earlier work.

The offline checkout signs a synthetic event and sends it through the same server verification and storage path the real webhook would use. The server refuses live Stripe keys and keeps demo records separate from test records. Node 24, native crypto, no third-party packages.

A small coordination detail: Crema's LOG-ENTRY.json starts with a UTF-8 byte-order mark. It was one of six Codex log files like that, and the merge script had to learn to strip it before parsing.

• A success redirect is not proof of payment. Support gets recorded only from a verified event.
• You need deduplication at the event level and the session level, because different events can describe one payment.
• A storage failure has to surface before you acknowledge the event. Events are handled one at a time, and state is published only after the atomic write succeeds.
• Integer minor units avoid floating-point money bugs, and raw-byte HMAC verification with a five-minute tolerance rejects tampering and replayed old signatures.
• PowerShell's default text decoding corrupted Unicode test fixtures. We restored them and used explicit UTF-8 from then on.

Crema was built on top of core work that already existed in the folder, which is the reuse story in miniature: nothing that passed its tests got thrown away. It also follows the house rules everyone shared (tested core in verify.mjs, serve.mjs on port 5152, ?demo=1, dark and light themes). No later project imports its code.

I would swap the JSON store for transactional storage, run a real hosted Stripe test session end to end, and add explicit fulfillment and refund states before doing anything beyond tips.