Reps With Friends — Game Design Document

Version 1.0 · 2 Sep 2026 · Owner: Alexei Brown (build) + Ben (design/vision) Companion doc: docs/25_DESIGN_BRIEF.md — the 2-page handout. This is the bible.

What this document is. The complete game design of Reps With Friends as it exists today — a working system, not a concept deck. Every mechanic described here is implemented and tested somewhere in this repo, and every section says where. Where the design is genuinely undecided (five founder-level decisions), this document says so honestly and lays out both sides.

How to run everything in this repo (a reader who has never seen it):

bun serve.ts          # → http://localhost:4173

The same content is publicly deployed at rwf.qalarc.com.

Source documents: Ben's original brief (summarised in docs/01_BUSINESS_ANALYSIS.md §2) · the founder-decision audit of his production Figma (figma/notes/analysis.md) · the element backlog (docs/07) · our MVP design spec (docs/13) · the wiki's own rules chapter (apps/wiki/game.html). Code references: packages/game-core (the TypeScript spec), apps/figma-app/engine.js (faithful browser port), apps/figma-app/daily.js (play-day/temporal layer), packages/bot-core (the chat bots).

1. The fantasy

Training stops being something you grind alone.

The target user is a 35–50 year old who used to be fit, isn't anymore, and has a group chat full of mates in exactly the same position. Every fitness app on earth sells them the same lonely loop: open app → log workout → stare at your own graph → feel vaguely guilty → churn by week three.

RWF replaces that with your mates. The gym session becomes a fixture of the group chat — with standings, deadlines, comebacks, theft, taunts and a charity pot. You are never training alone; someone is always ahead of you or coming for you. The game's promise, mechanically enforced (§4): everyone has a genuine shot until the last set.

Three load-bearing ideas arrived fully formed in Ben's original brief (docs/01 §2) and have survived every design pass unchanged:

1. The "300" format — a real training-ground game Ben brought with him:<br>the group agrees on exercises, then any reps, any order, any mix, first to<br>300 total. Self-balancing (you choose your own mix), zero setup friction,<br>instantly understandable in one chat message. The name does half the<br>marketing (&quot;tonight we do a 300&quot; needs no explanation to anyone who has<br>ever seen <em>300</em>).
2. The handicap system — effort and consistency compete, not raw fitness.<br>A couch player's push-up is <em>worth more</em> than an athlete's. This is the<br>moat: golf proved decades ago that handicaps keep weak players paying;<br>nobody in fitness does this well. It is also the hardest thing to get<br>right — which is why it's defensible (§4).
3. Taunting as a feature, charity as the stakes. Banter is the content<br>engine; filming a mate mid-set is the ad. The pot gives trash talk real<br>consequence without gambling: the winner directs the pot to charity —<br>never receives it (Nico's idea, adopted; legal structure pending,<br>docs/01 §5). Losing money to a mate is a grudge; losing it to charity is a<br>story.

Everything else in this document is those three ideas, elaborated.

2. The core loop

┌─ PREP ─────────────────────────────────────────────────────────────────────┐
│ crew picks play days + exercises → match created                           │
│ (waiting room + crew code) · bot: `rwf new` · app: create-battle screen    │
└────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌─ EVERY PLAY DAY (e.g. Mon/Wed/Fri) — loops ────────────────────────────────┐
│                                                                            │
│  log reps ───▶ live standings ───▶ deadline pressure ──▶ day closes        │
│  (chat or app)   effort-adjusted    DZ1 ─▶ DZ2 ─▶ DZ3   21:00 AEST         │
│                   comeback armed   ≤3h    ≤1h   ≤30min       │             │
│                                                              ▼             │
│  DAILY WINNER + RECAP — "YOU WON TUESDAY" · MOMENTS · next day opens       │
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘
    │  at any moment: the first RAW total to reach the target…
    ▼
┌─ FINALE ──────────────────────────────┐        ┌─ SEASON · 4 weeks ────────────┐
│ match CLOSES · closure bonus +15      │        │ 3/2/1 points · MVP +1         │
│ RESULT CARD + CHARITY POT             │ ─────▶ │ champion · A/B swap           │
│ (the winner directs the pot)          │        │ streaks · forgiveness $2      │
└───────────────────────────────────────┘        └───────────────────────────────┘
                   │
                   ▼
REMATCH — one tap, same crew, fresh pot ──▶ back to PREP

Each step, mapped to where it lives:

The loop is deliberately chat-first: every broadcast (standings, result cards, taunts) is an ad seen by the whole group chat; spectators convert via watch <code> (docs/01 §2 — "the second moat").

3. The battles

This is the founder's explicit ask: map out the battles. There are five battle forms — three shipped, one designed, one genuinely open.

3.1 The Classic 300 (shipped — the canonical form)

• Setup: the crew agrees on 2–4 exercises and a play schedule (2–3<br>days/week — anti-burnout by design; &quot;rest day, never *missed day*&quot;).<br>Default target 300 raw reps; a &quot;Light&quot; match is 150 (<code>new 150</code>).
• Play: any reps, any exercise from the agreed set, any order, any mix,<br>from the chat or the app. Reps can be camera-verified (<code>log pushups 25!</code>).
• Win condition — the twist that IS the product: the first player to hit<br>the <strong>raw</strong> target <em>closes</em> the match (logging locks instantly), but the<br>winner is the highest <strong>effort-adjusted</strong> score at closure. The closer gets<br>+15. An athlete can close on raw reps and still lose to a couch player who<br>moved less but earned more per rep.

entry value   = reps × tierMultiplier × (comeback? ×1.2) × (lightning? ×3)
match winner  = max(Σ entry values), +15 to the player who closed

Worked match (real numbers, from the live bot transcript — wiki → Bots): Target 150. Ben (couch ×1.5) logs 40 push-ups → 60 adj. Nico (athlete ×0.85) logs 80 squats → 68 adj. Ben is now >30% behind on raw (40 vs 80 → gap 50%) → comeback armed ⚡. Ben logs 110 push-ups: 110 × 1.5 × 1.2 = 198, and his raw (150) hits the target → match closes, +15 closure bonus. Final: Ben 273 (60 + 198 + 15), Nico 68. Ben closed and won — but against a fitter closer, the upset is live: if Nico had also finished, the adjusted column decides, not the clock.

3.2 Fast Battle vs Custom Battle (the two creation paths)

Ben's Figma defines both; the app ships the creation flow, the bots ship the one-line version.

3.3 Daily-rhythm multi-day battles (shipped in the app — the hybrid, see 3.5)

• Setup: a battle spans days — e.g. 2 weeks, active Mon/Wed/Fri. The group<br>shares one clock: every play day ends <strong>21:00 Australia/Sydney</strong> (each player<br>sees the local equivalent — the dual clock: &quot;ends 9:00 PM AEST · 7:00 PM for<br>you&quot;). Time Freeze (+30 min, §5) is the only thing that moves a deadline.
• Play: log any time during the day. The final three hours escalate the<br><strong>danger zone</strong>: DZ1 ≤3h (gold chip) → DZ2 ≤1h (orange banner, pulse) →<br>DZ3 ≤30min (red banner with live minute count — &quot;DANGER ZONE — 24 MINUTES<br>LEFT&quot; — heartbeat on the timer, full screen wash, &quot;LOG NOW&quot;). Layout never<br>changes; only colour and the timer escalate (motion law, docs/25).
• Win condition: at the deadline the day closes itself exactly once —<br>logging locks, the day's winner (highest adjusted among <em>that day's</em> entries<br>only) is recorded to <code>dailyHistory</code>, a recap renders, and the next play day<br>begins. Tie-break: adjusted → raw reps → earliest first entry. A day nobody<br>logs closes as &quot;NOBODY LOGGED. BRUTAL DAY.&quot; (streaks survive; pride doesn't).<br>Absences never chain-generate a pile of brutal days — only the boundary day<br>auto-closes empty.
• The recap card (FLOW-07): "YOU WON TUESDAY" / "SAM TOOK TUESDAY" · your<br>line (&quot;You finished 2nd at 92% — 10 RUF short.&quot;) · the sting (&quot;You led until<br>7:04 PM. Tomorrow, finish the job.&quot;) · nemesis tease · MOMENTS strip<br>(biggest set, comeback claimed, clean sweep, lead change) · tomorrow's<br>stakes in your timezone.
• Where: all of it is apps/figma-app/daily.js (isPlayDay /<br>deadlineFor / dangerLevel / closeDay / settleDay / recapFor), proven by<br><code>e2e-daily.mjs</code> which time-travels the whole ramp. Screens: <code>d13</code> calm →<br><code>d19</code> DZ1 → <code>d23</code> DZ2 → <code>d30</code> DZ3 → <code>d42</code> close → <code>d48/d59</code> recaps.

Worked day (numbers via the documented formula): You (casual ×1.25) log 40 push-ups at 7 AM → 50 adj. Sam (fit ×1.0) logs 60 squats at 6:30 PM → 60 adj. DZ2 fires at 8 PM. You log 20 push-ups at 8:20 — you're >30% behind on raw (40 vs 60), comeback armed → 20 × 1.25 × 1.2 = 30 → You 80, Sam 60. Day closes at 9 PM: "YOU WON TUESDAY" · "You beat Sam by 20 RUF today. They're coming for you." · pot grew $3 since yesterday's close · "NEXT BATTLE DAY: WEDNESDAY — logs open now".

3.4 Crew vs Crew (shipped in bots; corporate form designed)

• Setup: two group chats, one match. Crew A's captain runs<br><strong><code>challenge &lt;CREW-XXXX&gt;</code></strong>, crew B accepts (<code>challenge accept</code>). Corporate<br>variant in Ben's Figma: dept-vs-dept / office-vs-office with a<br><strong>contribution floor</strong> (team score only counts in full once every member<br>clears ~40 RUF — nobody rides the bench) and an <strong>Assist Boost</strong> send CTA.
• Play: identical to the classic 300, standings merged across both chats;<br>spectators in either chat see the combined board.
• Win condition: highest cumulative adjusted crew score at closure (bot<br><code>s</code> shows both crests); employer-funded charity pot is the cleanest stakes<br>structure for this form (docs/08 §6).
• Where: bot challenge + watch (bus.ts, live today); team battles +<br>contribution floor designed in Figma (V1.x); corporate surfaces seeded in<br>the <code>/hub</code> console (aggregate-only, k≥5 suppression).

3.5 The rhythm decision — his model vs ours, honestly (OPEN, §9 D3)

This is the one genuine structural fork left in the battle design, and it deserves a straight presentation rather than a dodge:

• Ben's model (his Figma, built as designed in /figma-app): multi-day<br>battles, <em>personalised daily targets</em> in RUF — Light 60 / Solid 120 / Hero<br>200, picked privately when joining — and the daily winner is whoever hits<br>the highest completion-% of their own target. Every level can win the day;<br>ability differences are hidden rather than spotlighted. Retention thesis:<br>losers get a fresh start tomorrow, so the loop never feels over.
• Our model (the bots / original engine): one shared target (300), one<br>match, first-to-close finale, handicap multipliers as the visible<br>spectacle — the standings are a running argument about who's really trying.
• What's actually shipped is the hybrid, and that's the honest answer:<br>the app runs Ben's rhythm (play days, nightly deadline, DZ ramp, daily<br>winners, recaps) on top of our engine (shared target, tier multipliers,<br>comeback, closure finale, charity pot). Daily winners give everyone a<br>fresh start tomorrow; the 300 closure gives the match a real finale.
• Recommendation: keep the hybrid, and resolve the last sub-question —<br>shared 300 target vs personalised RUF targets — at the founder call with<br>both variants playable side by side (§9).

4. The handicap system (the moat)

Thesis, verbatim from the code comment: effort and consistency compete, not raw fitness.

4.1 Tier multipliers (v1 — live)

Chosen at onboarding (self-set, socially policed), applied to every rep:

TIER_MULTIPLIERS — apps/figma-app/engine.js / packages/game-core/src/handicap.ts; expected volumes: TIER_EXPECTED_WEEKLY_REPS in baseline.ts.

4.2 The comeback multiplier ×1.2 — "everyone has a shot", mechanically enforced

More than 30% behind the leader in raw reps while the match is live → your next entry is tagged ×1.2. Once per player per match. Eligibility recomputes on every log; bot standings mark eligible players ⚡ so the group can see it coming. The boost is tagged onto the entry at log time, not a global multiplier — so it composes (a comeback entry inside a Lightning window scores ×1.2 ×3 = ×3.6, §5).

COMEBACK_THRESHOLD = 0.3, COMEBACK_MULTIPLIER = 1.2 — comeback.ts / engine.js comebackEligible / applyComeback.

4.3 The closure bonus +15

The player whose raw total hits the target first gets +15 adjusted points — urgency and glory for the closer, but deliberately small enough that real effort still beats raw speed. A closer who sandbagged their tier wins nothing: +15 doesn't rescue a thin adjusted column. (Found by the test suite — a bug in the original bonus placement was caught and fixed before it ever shipped.)

CLOSURE_BONUS = 15 — engine.js / match.ts finalStandings / winner.

4.4 Effort handicap v2 — %HRR blend (engine-ready, waiting on strap data)

When an entry carries a measured avgHrrPct (heart-rate reserve %, Karvonen, from a BLE strap) and the player has a learned baseline, the multiplier blends live evidence with the declared tier:

effortMultiplier = 0.7 × (avgHrrPct / baselineHrrPct) + 0.3 × tierMultiplier

70% measured, 30% declared. This makes effort itself the score — a couch player red-lining scores like a champion; an athlete phoning it in doesn't. The blend math is implemented and tested; it activates the day heart-rate straps land (docs/05 phasing).

HRR_WEIGHT = 0.7 — handicap.ts / engine.js effortMultiplier.

4.5 Anti-sandbagging — baseline drift (engine-ready)

Self-reported tiers have a loophole: a ringer declares "couch" and farms the ×1.5. Two drift correctors close it (baseline.ts, gated to at most one tier step per week):

• HR path: baselineHrrPct drifts toward your rolling measured average,<br>max <strong>10% per update</strong> — you can't tank your baseline in a weekend.
• Volume path: consistently logging >1.3× your tier's expected weekly<br>volume drifts your tier one step <em>fitter</em>. The &quot;couch&quot; player doing 5×<br>everyone's reps quietly becomes a casual.

4.6 The couch-beats-athlete worked example

The full thesis in one table (target 150, from the bot transcript):

The athlete did the bigger single set and led most of the match. The adjusted column says: Ben tried harder per rep, from further back, when it counted. That sentence is the product.

5. Power-ups & the economy

Four cards, live in the app (/figma-app, Figma FLOW-05; engine.js — figma-app only, deliberately not yet in game-core). All activations are pure functions returning a new match state + a result card; every activation is audit-logged to powerLog.

Drop odds (DROP_ODDS): common 50 / rare 30 / epic 15 / legendary 5 — daily-drop style, one card per battle day in the Figma economy. Rarity is cosmetic in v1: chip colour + drop odds only, no mechanical effect.

The counter-web is the design. Lightning is capped at one activation so it can't be chained. Steal targets only the current leading rival (preview shows exactly what you'd take and whether a shield is up — stealPreview), so you can't snipe someone harmless. Shield makes Steal honest: theft against a prepared leader is a wasted card, so steals happen when someone has actually run away with it — which is exactly when the table wants a correction. Steals never trigger the closure check; only real logged reps close a match.

Stacking rule: comeback and lightning both tag the entry, so they multiply — a couch player's comeback set inside a lightning window is ×1.5 ×1.2 ×3 = ×5.4 per rep. Rare, loud, and earned from behind. That's the point.

What is deliberately unpriced. Nothing in the current build can be bought: cards are granted (grantPowerUp / daily drop), never sold. Ben's Figma designs the full economy — store packs ($1.99–$4.99), daily loot chest, Reps Pro subscription with 12 inventory slots — under one hard rule we adopt verbatim: "Cosmetic and convenience only — you can't buy the win." Whether any of that ships in the MVP is open decision #4 (§9).

6. The social layer

• Taunts (live). Bot taunt <name> — AI-generated cheek via the<br>server-side GLM proxy with canned fallback (2s timeout), because taunting<br>is a feature, not abuse: the crew opted in by joining. Proposed: per-crew<br><strong>roast-tier setting</strong> — gentle / standard / feral — gates the AI engine<br>(also the corporate-safe switch, docs/07 G-34). Line that must never move:<br>cheeky, never mean; &quot;rest day&quot;, never &quot;missed day&quot;; money screens drop all<br>banter.
• MVP vote (live). One vote, best effort not winner, locks on tap.<br>Feeds the season (+1 point) — the second podium, so showing up hard with a<br>bad multiplier still gets recognised.
• Nemesis (live). Auto-detected from head-to-head history: your nemesis<br>is the opponent who has beaten you the most, with ≥2 shared matches and ≥1<br>loss (someone you always beat is prey, not a rival). Bot <code>nemesis</code>; shown<br>on profiles and result cards — every player gets a personal storyline, not<br>just the leaders'. <code>packages/game-core/src/nemesis.ts</code>.
• Photo finish (live). Top two within 5% adjusted → special result<br>card + slow-mo styling. Manufactures shareable drama from close matches.<br><code>photo-finish.ts</code>, <code>PHOTO_FINISH_PCT = 5</code>.
• Monday digest (live). AI-written weekly recap auto-postable to the<br>chat: results, margins, MVPs, pot total, rivalry callout, one-liner. Bot<br><code>digest</code> / alias <code>monday</code>; <code>packages/bot-core/src/digest.ts</code>. Re-opens the<br>loop every week without anyone lifting a finger.
• Spectators (live). watch <code> — read-only standings of another crew<br>in your chat; standings show 👁 count. Spectators are the funnel: they see<br>the leaderboard without joining, and joining is one command.
• Result cards — the viral artefact (live). Every match end auto-<br>generates a branded 1200×675 card (SVG from the bots — <code>/cards/…</code>, PNG<br>export from the app). Direction adopted from Ben's file: server-rendered,<br>no health data, pre-written editable message, join link — every result<br>card is an ad with a call to action.
• Drop-cam (proposed). 10-second clip capture during verified sets —<br>Ben's &quot;friends filming friends&quot; content engine (docs/07 C-14).
• The charity pot ritual (live as a pledge ledger). Players chip in<br>(<code>pot 500</code> = $5.00); at result time the <strong>winner directs</strong> the pot to a<br>charity of their choice (<code>designate</code>) — a dedicated picker screen, the one<br>moment the product goes quiet and warm. Pot growth is recapped daily<br>(<code>potDeltaCents</code> — growth since the previous day's close).
• The legal line. No cash ever moves to a winner; the pot is a pledge<br>ledger today and stays one until a proper legal opinion lands (AU<br>state-law raffle/betting classification risk — docs/01 §5, docs/08 §6).<br><strong>Employer-funded pots are the clean interim structure</strong> — the company<br>puts the money in, the winning crew directs it; nothing to classify.<br>Ben's full cash-wagers suite (KYC, regions, responsible-play limits,<br>separate ledger, never the word &quot;escrow&quot;) is designed behind a<br>feature flag and stays there (§9, D17).

7. Progression & retention

The retention stack answers the week-3 cliff (docs/01 §5) with four layers — each one cheap, each compounding:

1. Seasons (live). 4-week series. Every finished match feeds<br><code>recordMatch</code>: 1st +3, 2nd +2, 3rd +1, MVP vote +1. Ladder sorts<br>points → wins → MVPs. At season end: champion crowned (the belt —<br>physical trophies proposed, docs/07 F), and <strong>A/B division swap</strong> —<br>bottom of A ↔ top of B — so mid-table stays meaningful all season.<br><code>season.ts</code>; app <code>48-49-season-ladder.png</code>; bot <code>season ladder</code>.
2. Streaks + forgiveness (live). Streaks count played weeks (you chose<br>your days — no streak guilt for resting). A streak about to break can be<br>saved <strong>once per season</strong> by topping the charity pot <strong>≥ $2</strong> —<br>preserved, not extended. Guilt converts to pot money; no free rides<br>(<code>FORGIVE_MIN_CENTS = 200</code>, <code>forgiveStreak</code>).
3. The avatar/creature system — the identity layer (in active build).<br>The founder's tamagotchi concept: your avatar evolves with your<br>training. The reference creature is the dragon — three stages already<br>modelled and rigged: <strong>Hatchling</strong> (round, stub-winged, all eyes) →<br><strong>Fledgling</strong> (wings come in, nub horns, first spikes) → <strong>Elder</strong><br>(<code>site/avatar-styles/dragon2.js</code> — stages driven by a <code>stage</code> param,<br>ready to wire to season/streak milestones). Learned the hard way<br>(documented post-mortem, <code>notes_avatars_investigation.md</code>): creatures are<br>built on a <strong>dedicated creature rig</strong> (<code>site/creature-rig.js</code>, horizontal<br>silhouette — a dragon doesn't squat), never as humans-in-suits. The same<br>pipeline already carries 11 humanoid styles + 12 rigged GLBs across<br>species; the Outfit Atelier (<code>/atelier</code>) stress-tests garments through<br>every extreme exercise pose. Design intent: your creature grows when you<br>show up — the identity layer makes absence <em>visible</em> and progress<br><em>adorable</em>.
4. Awards & badges (designed, from Ben's file — adopt). Auto-computed on<br>final results: 🏅 most consistent · 🚀 best comeback · ⚡ most active ·<br>💪 personal best — zero coordination, covers the &quot;effort ≠ winning&quot; value<br>the MVP vote serves. Plus PB detection cards for the non-competitive half<br>(docs/07 G-29).

Non-winner retention is a stated design lane in Ben's architecture ("the loop must create a social ripple even when you lose") and everything above feeds it: comeback, MVP, awards, nemesis, revenge rematch prompts, daily fresh starts.

8. Verification & fairness — the trust ladder

The existential technical problem (docs/01 §5): if reps are self-reported the game is a lying contest; if verification is annoying nobody plays. The answer is a ladder, not a gate — every rung is optional and every rung is visible:

Server-authoritative everything (Ben's engineering posture, adopted): the server computes all scoring, multipliers and deadlines; the client never decides a danger-zone level. The camera rung is deliberately the positive verification ("honest by design" — show off) with peer challenge as the social backstop, in that order (the sequencing itself is one of the adjacent open calls, §9).

9. The five open decisions

Full evidence and the 30-row divergence log: figma/notes/analysis.md (§4, §6 — the founder-call one-pager). The five that reshape the game:

① Fairness model — the deepest divergence

• Ben's design: personalised daily targets (Light 60 / Solid 120 / Hero<br>200 RUF), winner = completion-% of <em>your own</em> target; tier private.<br>Ability differences hidden — privacy, simple math, &quot;every level can win<br>the day&quot;.
• Our build: shared target + tier multipliers; the handicap is the<br>spectacle — effort visible in the numbers.
• Recommended hybrid: personalised targets and our comeback multiplier<br>on top (both &quot;everyone can win&quot; mechanics, one hidden one visible).
• Downstream: standings math, comeback triggers, result cards, the whole<br>adjusted-score narrative reshape around this. Decide first.

② Platform / distribution

• Ben: native app, app-store IAP, push notifications (DZ nudges basically<br>require push).
• Ours (shipped): PWA + WhatsApp/Slack bots day one — no install, <30s<br>cold start, the chat IS the arena. The bots are built and are the<br>differentiation.
• Recommended: staged — bots + PWA now, native when retention is proven.
• Downstream: onboarding (12-screen native flow vs our <20s name+tier),<br>notification strategy, payments.

③ Battle rhythm

• Ben: daily winners inside multi-day battles + nightly danger zone.
• Ours: single match to 300 with the close-moment finale.
• What's built: the hybrid — daily winners + DZ on top of the 300<br>closure (§3.5), running in <code>/figma-app</code> today.
• Recommended: keep the hybrid; settle the shared-target vs personalised-<br>target sub-question with both playable side by side.
• Downstream: if daily rhythm fully wins, seasons become its container<br>and the closure finale becomes the season finale.

④ Power-ups in the MVP?

• Ben: 4 power-ups + rarity + daily drop + store + Pro inventory slots in<br>the launch gate — the monetisation spine.
• Ours (shipped): the same 4 power-ups, fully mechanised app-side; no<br>store, no prices, drops only.
• Recommended: ship the four cards (they're done and tested), hold the<br>store/Pro economy for post-retention-proof. Never break: &quot;you can't buy<br>the win.&quot;
• Downstream: a whole component family (cards, chest, banners) and the<br>Pro paywall design hang on this.

⑤ Brand — gold vs lime

• Ben's file: gold #FFC821 + purple #8B5CF6 + Anton/Inter, domain<br>reps.fit — &quot;game&quot; energy; he flags the palette as needing sign-off.
• Ours: lime #c6f32e + coral #ff5c38 + Space Grotesk, rwf.app —<br>&quot;athletic&quot; energy.
• Where it stands: both now exist as complete, switchable themes<br>(<code>/styles</code> — Lime Athletic, Gold Arcade, Sunset Brutalist, Midnight Neon,<br>Forest Retro); the test app ships Anton + Inter <em>and</em> Space Grotesk. This<br>is now a founder-taste call, not a build problem.
• Downstream: D5/D6 lock → tokens map 1:1 (figma/notes F3-ready), the<br>Figma variable table converts, the domain registers.

Adjacent decisions already leaning resolved — money at launch (charity-only, wagers flagged; D17) and verification sequence (camera MVP → peer challenges V1; D10) — both with Ben's craft adopted and our shipped work kept.

10. Numbers appendix — every constant, one table

All values verified against the code on 2 Sep 2026. Any change to a number here must update this table, the wiki Game Rules page, and the tests.

Proof of correctness (run any of these yourself):

cd packages/game-core && bun test   # 59 tests, 134 expect() calls — engine spec
cd apps/figma-app   && bun test engine.test.js   # 23 parity tests: TS vs JS side by side
cd packages/bot-core && bun test    # 64 tests — command bus, cards, AI fallback
cd apps/figma-app   && bun e2e.mjs && bun e2e-daily.mjs   # full app walks, injected time

90+ green across the repo, CI-gated on every push (docs/17).

Cross-links: docs/25_DESIGN_BRIEF.md (design handout) · docs/01 (Ben's brief + market) · docs/02 (phasing) · docs/05 (verification research) · docs/07 (element backlog A–G) · docs/08 (legal) · docs/11 (systems) · docs/13 (our MVP spec + 30-row divergence log) · docs/17 (progress) · figma/notes/analysis.md (the Figma audit + founder-call one-pager) · wiki: /wiki/game.html, /wiki/app.html, /wiki/bots.html, /wiki/verification.html, /wiki/avatars.html, /wiki/status.html.