/decisions · 2026-09-02 · scribble-works · members-area-spec
The members area — what /account becomes, with wireframes
Founder decision, 2026-09-02 18:28 ET: AMEND. D1 the calendar shows a rolling two weeks while planning, the full history stays browsable over time, and the day unit is a playset, not one game. D2 one card per kid; the plan shows one kid at a time (two kids side by side worked, eight would not). D5 the free / free signed-in / paid signed-in line is delegated to a growth/GTM plan. D8 a content marketing strategy for retention: occasional email nudges (print your latest playset, review your upcoming plans) and reply-to-email feedback with comments and photos through the existing feedback@ door. Cadence: now.
D3, D4, D6, D7 and D9 were not mentioned and stand at Ray’s default, confirmed by the founder 18:31 ET (“anything I did not mention specifically I was good with the default”). Wireframes 04 and 05 below are superseded and kept as the record.
18:33 ET ruling 30: counsel is not a gate; the child-profile UI ships with the members area.
Seven routes, one desk. The taped-paper card you liked on the phone is the unit, not the page — every section is one sheet on the same desk mat. Home · Household · Kid profile · The week · Playsets & pages · Billing · Your data. Phone gets a stack of section cards; desktop gets a left rail of paper tabs. Ships with the fix for the bug you reported in the same message: the signed-in header gets a “Your account” link back.
The calendar is the product. A full Mon–Sun week (your 13:24 correction — weekends are planned by default, with a “school days only” toggle that ships off), one row per kid, and a slot is one game. “Fill my week” auto-fills empty slots only — by age band, then interests, then your focus topics, with a variety rule — and never overwrites something you chose. “Print the week” composes one playset PDF: a parent page first (week at a glance, supplies, what each game builds), then one page per game.
No notifications in v2. The week waits in the members area; it does not chase anyone. Push email gets its own decision (the charter’s rung-4 scheduled delivery) — shipping nudges alongside a first calendar is how a plan turns into nagging.
Billing is built but dark. Schema, routes and copy ship behind BILLING_ENABLED, off. Stripe Checkout to upgrade and the Stripe Billing Portal for card, receipts and cancel — so we build zero card fields and carry zero PCI surface. The one thing Ray cannot do: open the Stripe account under Ray Data LLC. That is yours. Everything else in v2 ships without it.
The six screens
01 · Account home
Who you are, the one thing worth doing today, six doors. Ray’s bubble names Tuesday’s game rather than cheering.
02 · Household
Up to three grown-ups (you, a spouse, a grandparent) by email invite, plus kid cards. Kid cap eight; over-cap asks “setting this up for a class?”
03 · Kid profile
Nickname, birth month + year, what she loves, what you want her working on. No photos, no last name, no day-of-birth.
04 · The week (superseded 18:28 ET)
Mon–Sun strip, weekends live, “school days only” toggle off. One row per kid; empty slots say so instead of substituting.
05 · Print the week (superseded 18:28 ET)
One playset, parent page first, day-then-kid order. Each day card also prints alone.
06 · Billing (flagged)
Top: what ships today with the flag off. Bottom: the same sheet once Stripe exists. No pricing shown — that is still your call.
The nine picks (MA-D1 … MA-D9)
| # | Question | Ray’s default |
|---|---|---|
| 1 | Calendar granularity | A slot is one game, one per kid per day. Alternative: a slot is a whole playset. Decided: amended (founder, 18:28 ET) — a rolling two weeks while planning, full history over time, and a playset per day. |
| 2 | One plan, or one per kid? | One grid, one row per kid. Parents plan the household’s week. Blocking — calendar schema. Decided: amended (founder, 18:28 ET) — one card per kid, one kid at a time; no multi-kid grid. Unblocked. |
| 3 | Can a spouse/grandparent edit a kid profile? | Yes for content (nickname, interests, focus topics), no for existence (create/delete), never billing, membership or consent. Splits charter §6’s “equal standing” against the relationship model’s lead-only rule. Decided: default — confirmed by the founder 18:31 ET (“anything I did not mention specifically I was good with the default”). |
| 4 | Billing tiers named? | Unnamed — “Free” and “Paid” until you pick names. Decided: default — confirmed by the founder 18:31 ET (“anything I did not mention specifically I was good with the default”). |
| 5 | What does the free tier get in here? | Household, kids, saved playsets, feedback, privacy — and one “this week’s playset” card instead of the grid, which is ruling 12 verbatim. The full Mon–Sun week is the paid surface. Blocking — calendar gate. Delegated 18:28 ET to a growth/GTM plan for the free / free signed-in / paid signed-in line (vault 2026-09-02-tier-line-plan.md, in progress). BILLING_ENABLED stays off. |
| 6 | Per-kid pricing? | No per-kid charge in v2 — one household price, kid cap eight (itself a Ray default, the relationship model’s Decision 8). Your ruling-11 lever, still open. Blocking — billing scaffolding. Decided: default — confirmed by the founder 18:31 ET (“anything I did not mention specifically I was good with the default”). Unblocked. |
| 7 | Print composition | One PDF, parent page first, day-then-kid. Alternative: one PDF per kid. Decided: default — confirmed by the founder 18:31 ET (“anything I did not mention specifically I was good with the default”); with one kid at a time the two options converge. |
| 8 | Nudges | None in v2. Push email decides separately. Decided: amended (founder, 18:28 ET) — occasional email nudges (print your latest playset; review upcoming plans) plus reply-to-email feedback with comments and photos via feedback@. Plan in progress (vault 2026-09-02-retention-nudges-plan.md). |
| 9 | Delete grace period | 7 days, one email at each end. Export is JSON on demand, signed link, 24-hour expiry. Decided: default — confirmed by the founder 18:31 ET (“anything I did not mention specifically I was good with the default”). |
No pricing numbers appear anywhere in the spec or the wireframes — charter §8 still owns that.
What ships when
- v2 (this spec): home · household adults + invites · kid profiles · the calendar with auto-fill, print-the-week, done/skip and carry-forward · playsets, customized pages and feedback lists · export + delete · billing scaffolded behind the flag.
- v2.1: billing switched on once the Stripe account exists · per-slot generate-to-fill for paid households (your ruling 26) · the desktop paper-tab rail · transfer lead.
- v3: classrooms, seats, enrollments, schools — untouched, per your 11:22 ruling.
What this is waiting on
- You open Stripe under Ray Data LLC. New external account; Ray cannot. Gates §2.6 only.
- The relationship model’s RM-D2 (birth granularity) is blocking on the kid-profile schema; that page is still open, and its own blocking rows are RM-D0 (counsel) and RM-D5 (consent posture).
- Consent rows and the field-mask read layer must exist before kid profiles render. Prerequisite, not a follow-up.
- Counsel on “directed to children” still gates kid profiles reaching production. Unchanged, not re-argued here.
- Thumbnail export (queued) for the playset and feedback lists — grey placeholders until then.
Not legal advice. The privacy and consent surfaces inherit the relationship model’s counsel flags.
Lock in
Ray builds the members area on the nine defaults above and stops at the three blocking rows only if you change them.
Approve + sendName the numbers and what to instead (e.g. “5: full week free”).
Amend + sendSay when, and Ray flips the billing work from scaffolding to live in v2.1 instead of v3.
Stripe + sendPush the members area to a date. v1 accounts keep shipping; /account stays the one card.
Defer + send