The members area

Founder decision 2026-09-02 18:28 ET: AMEND. D1 the calendar shows a rolling two weeks while planning, full history 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; D5 the free / free signed-in / paid signed-in line is delegated to a growth/GTM plan; D8 occasional email nudges plus reply-to-email feedback (a content marketing strategy for retention). 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".

Founder, ruling 28, 2026-09-02 13:22 ET: "We should flesh out what you can do within that account page more. Add members to a household. Manage billing. Game calendar planning. All of that should be within the members area." Ruling 28 addendum, 13:24 ET: "I don't see why we would want games only on the weekdays. We should allow for planning daily. People want games/entertainment on the weekends." → the calendar is a full week, Mon–Sun.

Build spec for what /account becomes in Accounts v2. It does not re-open v1 (sign-in, sessions, the generative gate) or the entity model; [[2026-09-02-account-relationship-model-decision]] owns those and is still pending. No pricing numbers here: "paid tier" is the placeholder until the founder sets pricing (an open lever since ruling 11).

Wireframes (phone, 390px) in members-area-wireframes/: 01 home · 02 household · 03 kid · 04 calendar · 05 print · 06 billing; source wireframes.html. 04 and 05 are superseded by the 18:28 amendment (they show a fixed Mon-Sun week with two kids stacked and one game per day; the ruling is a rolling two weeks, one kid at a time, a playset per day). Kept as the record; a redraw is queued with the v2 build.

1. Information architecture

Seven routes, one desk. The taped-paper card from the built account preview (accounts-v1/2026-09-02-account-page-preview-phone.jpg) is the unit, not the page: every section is one sheet on the same desk mat.

• Phone: /account/ is a stack of section cards (label · one-line state · chevron); inside a section, a back link above the sheet. No tab bar, since the header sheet already carries site nav. Ships with the ruling-28 bug fix: the signed-in header gets a "Your account" link.
• Desktop (≥900px): a left rail of paper tabs, section sheet to its right. Same routes. The tab rail is a proposed new frame-motif variant, not one the design contract already names.
• Signed out on any /account/* route → the v1 sign-in sheet, ?next= preserved.

2. Sections

2.1 Home

• Job: confirm who I am, name the one thing worth doing today, one tap into any section.
• Data: masked email + verified pill (v1, unchanged) · household name · kid count · next planned day · plan tier.
• States. First run: one Ray line, one button, "Add your first kid". Normal: a "next up" line over the six section cards. Free: the calendar card reads "This week's playset" (ruling 12 verbatim) until the tier-line plan (MA-D5) says otherwise. Error: session expired → sign-in sheet, no half-rendered account chrome.
• Permissions: identical for lead and adult, except the billing card, which reads "Managed by ".

2.2 Household

• Job: add my spouse and a grandparent; manage kid profiles.
• Data: adults (name, masked email, role pill, joined date, max 3) · kid cards (nickname, age band derived from birth_date (full ISO date — founder ruling 2026-09-05: "Birthday input was the full date. That was already decided."; migration 0005 L120), up to three interest chips). No photos anywhere, adult or kid.
• Invite flow: lead enters an email → 14-day single-use link on the v1 magic-link rail → invitee signs in, lands on /account/household/ with an accepted banner. Pending invites are a dashed card with Resend and Cancel.
• States. Empty: "It's just you in here." Pending: "Invited 2 days ago." At cap: the add button becomes "Three adults is the limit." Kid cap (8, relationship model RM-D8, Ray default): the add button asks "Setting this up for a class?" and routes to the classroom waitlist — its v3 demand signal.
• Permissions: lead adds/removes adults and creates/deletes kids; an added adult edits a kid's interests, focus topics and nickname (Ray default, MA-D3 — the relationship model is lead-only on children) but cannot create or delete one, bill, or touch membership or consent. Any adult can leave this household from here (the only home for that action); the lead must transfer lead first.

2.3 Kid profile (edit)

• Fields, the relationship model's exactly: first_name_or_nickname · birth_date (full date; a date input — founder ruled 2026-09-05 that the full date was already decided; the earlier month+year line is superseded) · interests_json (chips + free text) · focus_topics_json · languages + dominance · read-only skill states (introduced / practicing / secure).

• One quiet privacy line and a Privacy link (ruling 22 register), not a retention essay: "Their name stays inside your household. It never goes to the AI."

• States. New: nickname + age are the only required fields; the plan still works on age alone. Saved: inline "Saved" with undo, no modal. Delete: type-the-nickname confirm, then immediate hard delete of the profile, its slots and its personalized artifacts.

2.4 The calendar — the core loop

The paid surface, and what the charter calls the product. Amended 18:28 ET (MA-D1, MA-D2): the calendar plans a rolling two weeks, one kid at a time, and the day unit is a playset.

• Window: a rolling two weeks while planning - today plus the next 13 days, every day of the week, Mon-Sun (the 13:24 ruling stands: weekends are planned days; the window is simply a rolling one, not a fixed week). A household toggle, "School days only" (default OFF), hides Sat/Sun. On phone: a 14-day strip with a today marker; tapping a day opens that day's playset.
• History: days that have passed do not vanish. Scrolling back from today walks the full history over time, month by month, with each day's playset and its done marks intact. History is read-only apart from Done ticks; planning happens in the two-week window.
• One kid at a time (MA-D2): the plan shows one kid's two weeks, chosen by a kid switcher at the top of the sheet (cards, one per kid, the active one lifted). There is no multi-kid grid; a household with eight kids sees eight cards and one plan. The switcher remembers the last kid opened.
• A day is a playset (MA-D1): the unit in each day is a playset - the set of games for that day, sized by the kid's age band (typically two to four games, the same sizing the generative shelf uses). Games remain the ruled unit inside a playset; a parent still hands a child one game at a time, but plans by the day.
• Auto-fill ("Fill the next two weeks" - one button, never automatic on load):
  1. Eligibility: age band from birth month/year; language matches the kid's dominant language.
  2. Interest weighting: games tagged with interests_json rank first; user-generated-content (UGC) theme variants count as their base game's theme.
  3. Focus boost: focus_topics_json matches outrank interest matches. The parent's curriculum beats the child's preference.
  4. Variety: no game twice in 4 weeks; within a playset no two games in one skill family; no two consecutive days led by the same skill family; max two of any game type per kid per week.
  5. Empty days only. Auto-fill never overwrites a playset the parent has touched; a cleared day stays cleared.
  6. Shortfall is honest. If the shelf cannot fill a playset it ships short and says so. Paid households get generate-to-fill as a per-day button, never a silent substitution (extends ruling 26, which rules it at playset level).
• Editing: tap a day → its playset opens: Swap a game (the shelf, filtered to that kid) · Remove · Add · Move the whole playset to another day.
• Print: each day's playset prints alone, parent page first (charter: every pack opens with one) - scribble-works-<kid>-<YYYY-MM-DD>.pdf. Print the plan composes one PDF from every planned day in the visible two weeks for the active kid, ordered by day, with a two-week parent page in front: days at a glance, supplies per day, one line per game on the skill it builds. scribble-works-<kid>-plan-<YYYY-MM-DD>.pdf. (MA-D7's day-then-kid order collapses to one kid's days under MA-D2; a household-wide print is a v2.1 question.)
• Done / skip: each game in a playset has a Done tick and a Skip; a day reads done when every game in it is. Done writes activity_id + date only (charter retention: never the sheet) and advances that skill's state. Skip records nothing about the child.
• Carry-forward: as the window rolls, a new day enters it empty. Skipped games move into the next empty playset first (each carries once, then drops), then auto-fill takes the rest. The parent always sees a plan they can still change.
• Nudges (MA-D8, amended): occasional email, never push or badges in v2. Two nudges to start: "your latest playset is ready to print" and "here is what's planned for the next few days, take a look". Cadence and copy live in the retention plan ([[2026-09-02-retention-nudges-plan]], in progress); one unsubscribe line per email, honored per household.

2.5 Playsets, customized pages, feedback

• Job: find an earlier playset or page without rebuilding it.
• Three lists on one sheet: saved playsets (name, date, reprint) · customized pages (game, theme words, reprint; the ask text is never shown back, which extends ruling 21 — that strips personally identifiable information (PII) at storage and is silent on display) · feedback sent (date, game, thumbnail, status received / fixed with a before-and-after link).
• Empty: "Nothing saved yet. Build a playset and it lands here." Feedback rows appear only for verified households (ruling 25's screening, surfaced).
• Feedback by reply (MA-D8, amended): the nudge emails solicit feedback - "what did they think of the game? Reply to this email with your comments and a picture of it in play." Replies land on the existing feedback@ door (ruling 25's screening applies unchanged: PII stripped, photos held under the same retention as feedback thumbnails) and show up on this sheet as feedback rows, source "email". No new inbox, no new pipeline.

2.6 Billing (behind BILLING_ENABLED, default off)

• Job: see the plan, change the card, get a receipt, cancel without emailing anyone. Where the free / free signed-in / paid signed-in line sits is MA-D5, delegated to the growth/GTM tier-line plan; BILLING_ENABLED stays off regardless.
• Data: plan tier · renewal date · payment method (brand + last four, from Stripe, never stored by us) · invoice list · cancel.
• We build no card fields. Stripe Checkout to upgrade, Stripe Billing Portal for card/invoices/cancel. Our surface is a summary sheet and two buttons that leave, so the Payment Card Industry (PCI) surface is zero and the build is about a day.
• States. Flag off (today): "Coming soon", the preview's footnote register. Free: what the paid tier adds, one button. Paid: plan, renewal, card, invoices, cancel. Past due: one line and a fix-card button; the calendar stays readable, because a child's plan is not hostage to a card. Cancelled: access to period end, then past weeks go read-only and the household reverts to free. A cancellation deletes nothing.
• Permissions: lead only. Adults see "Managed by ".

2.7 Privacy and data

• Download my data: JSON export of household, adults (email + role), kid profiles, plan history, saved playsets, customization records and consent rows — generated on demand, emailed as a signed link, 24-hour expiry.
• Delete account: type-to-confirm, then a 7-day grace. Signing in during the window cancels it; after it, hard delete per the relationship model's retention table (consent rows survive, reduced to child ids). One email at each end.
• Lead only. Leave this household lives on §2.2 instead, the one surface an added adult can reach.

3. Phasing

• v2: home · household adults + invites · kid profiles · calendar with auto-fill, print the plan, done/skip, carry-forward · playsets/pages/feedback lists · export + delete · billing scaffolded behind the flag (schema, stripe_customer_id, routes, copy), no live keys.
• v2.1: billing on once the Stripe account exists · per-slot generate-to-fill for paid households · the desktop paper-tab rail (v2 ships phone-first) · transfer lead.
• v3: classrooms, seats, enrollments, schools — untouched here, per ruling 27.

4. Dependencies

1. Stripe account under Ray Data LLC, founder-owned. A new external account; Ray cannot open it. Nothing in §2.6 goes live without it; everything else in v2 does.
2. Relationship-model RM-D2 (birth granularity) is blocking on the §2.3 schema; RM-D0 (counsel) and RM-D5 (consent posture) are that doc's other blocking rows. RM-D3 (who adds adults) is not blocking there, and is not escalated here.
3. Consent rows must exist before kid profiles render: the field-mask read layer is a v2 prerequisite, not a follow-up.
4. Identities (v1) carry invite acceptance; Google/Apple assumed, not required.
5. Thumbnail export (queued) for the playset and feedback lists; grey placeholders until then.
6. Counsel on "directed to children" is not a gate (ruling 30, 18:33 ET): the child-profile UI ships with the members area; counsel review runs alongside and can only change copy and consent wording.

5. Copy — headings and empty states

Ray speaks in his bubble on Home, Kid profile, the calendar and the print sheet only: one bubble per sheet, each carrying an action rather than encouragement (design contract, checklist 4).

6. Founder decisions — Ray defaults

Numbered MA-D1…MA-D9 (the relationship model's own list is cited as RM-D*). Silence proceeds on the default. MA-D2, MA-D5 and MA-D6 were blocking on the v2 build; after the 18:28 amendment MA-D2 and MA-D6 are unblocked and MA-D5 is delegated. Founder decision 18:28 ET: AMEND; statuses below.

MA-D1. Calendar granularity. Ray default: a slot is one game, one per kid per day. Alternative: a whole playset per slot. Decided: amended (founder, 18:28 ET) - a rolling two weeks while planning, the full history browsable over time, and a playset per day, not one game.

MA-D2. One plan or one per kid? Ray default: one grid, one row per kid. Parents plan the household's week, not each child's separately. Blocking on the calendar schema. Decided: amended (founder, 18:28 ET) - one card per kid, the plan shows one kid at a time. Two kids side by side worked in the mock; eight does not. Unblocked.

MA-D3. Can an added adult edit a kid profile? Ray default: yes for content (nickname, interests, focus topics), no for existence (create/delete), never for billing, membership or consent. Splits charter §6's "equal standing" against the relationship model's lead-only rule. Decided: default (confirmed by founder 18:31 ET: "anything I did not mention specifically I was good with the default").

MA-D4. Billing tiers named or unnamed? Ray default: unnamed, "Free" and "Paid" until you pick names; naming now costs a rename across the marketing surface. Decided: default (confirmed by founder 18:31 ET: "anything I did not mention specifically I was good with the default").

MA-D5. What does the free tier get inside the members area? Ray default: household + kid profiles + saved playsets + feedback + privacy, and one "this week's playset" card instead of the grid — ruling 12 verbatim; the full Mon–Sun grid is the paid surface. Blocking on the calendar gate. Delegated 18:28 ET to a growth/GTM plan for the free / free signed-in / paid signed-in dividing line (vault [[2026-09-02-tier-line-plan]], in progress). BILLING_ENABLED stays off; the calendar gate builds behind a tier flag until the plan lands.

MA-D6. Per-kid pricing? Open lever from ruling 11. Ray default: no per-kid charge in v2, one household price, kid cap 8 (RM-D8, also a Ray default). Blocking on billing scaffolding. Decided: default (confirmed by founder 18:31 ET: "anything I did not mention specifically I was good with the default"). Unblocked.

MA-D7. Print composition. Ray default: one PDF, parent page first, day-then-kid. Alternative: one PDF per kid. Decided: default (confirmed by founder 18:31 ET: "anything I did not mention specifically I was good with the default"); under MA-D2 the print is one kid's days, so the two options converge.

MA-D8. Nudges. Ray default: none in v2; push email decides separately. Decided: amended (founder, 18:28 ET) - a content marketing strategy for retention and engagement: occasional email nudges (print your latest playset; review your upcoming plans) and reply-to-email feedback with comments and photos, routed through the existing feedback@ door. Plan in progress (vault [[2026-09-02-retention-nudges-plan]]).

MA-D9. Delete grace. Ray default: 7 days, one email at each end. Decided: default (confirmed by founder 18:31 ET: "anything I did not mention specifically I was good with the default").

Not legal advice; the privacy and consent surfaces inherit the relationship model's [counsel] flags.

Changelog

• 2026-09-02 18:28 ET - founder decision AMEND (iMessage): D1 rolling two weeks while planning, full history over time, a playset per day; D2 one card per kid, the plan shows one kid at a time; D5 delegated to a growth/GTM tier-line plan; D8 email nudges plus reply-to-email feedback via feedback@, retention plan in progress. D3, D4, D6, D7, D9 at Ray's default. §1 route table, §2.1, §2.4 (rewritten), §2.5, §2.6, §5 copy and §6 updated; wireframes 04 and 05 marked superseded, files kept.
• 2026-09-02 18:31 ET - founder confirmed the unmentioned rows stand at Ray's default ("anything I did not mention specifically I was good with the default"): MA-D3, MA-D4, MA-D6, MA-D7, MA-D9 marked decided-default; the 18:30 "Ray's assumption" hedge removed from the header and this log.
• 2026-09-02 18:33 ET - ruling 30: counsel is not a gate; the child-profile UI ships with the members area. §4 dependency 6 rewritten from a production gate to a parallel review.