← All privacy impact assessments

PIA: A record of first uses, and a Home that knows how new you are

Status: Built — written before the code, and revised against the shipped code the same day. Both pieces of work it gates are live: the first-use record, and the welcome and hint surfaces on Home. The build followed the design with one change, and §3 says it: the tools the day-two welcome names are the ones the group's own records show it uses (a baby it tracks, a meal plan it has adopted, a game it has turned on), read from the same answer that decides what Home shows, rather than from the reader's own list of tiles — so the sentence and the screen cannot disagree. A 25 October 2026 addition (§1D) assesses tool cards on a quiet Home and a one-time tip, which read this record for the purpose §3 states; it is assessed before release. Written: 19 September 2026 · Last revised: 25 October 2026 (§1D: tool cards on a quiet Home, and a one-time Tools tip; amended the same day for one own-age read per session, Security HC2) · 10 October 2026 (§1C: a planned first-week suggestion, sent as a notification) · 29 September 2026 (short additions, §1A and §1B; §1's description of the first sitting brought up to the needs-based setup as built) Nothing here is legal advice. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 December 2026).

1. Purpose and scope

A member who joined a group this morning opens the app to a Home screen built for somebody who has used it for months: a question card, a "needs somebody" section, a brief that assumes they know what a plan is. The design makes Home quieter for a new member and teaches the app gradually, in four steps that depend on how long the member has been in this group:

• The first day in a group: the question card and the "needs somebody" section are not shown. Nothing new is collected for this — it is a rule about what to draw.
• The first three days: the slot that usually holds the daily brief holds a welcome instead — a short line walking the member through what the group already has (its next events, its open tasks, the tools the group already uses), written by the model where the brief would have been, and by a fixed sentence of our own where it would not.
• Days four to seven: the ordinary brief, with one small hint beneath it — add a task or an event, look at a tool.
• From then on, for every member: at most once a week, one line beneath the brief about a feature the member has never used. Never the same feature twice.

During the first three days in a group, Home offers each member setup once on this device. Since 29 September 2026 that first sitting is needs-based: the member is asked "What would you like help with?", is set up for the tools they choose and no others, through each tool's own existing flow, and can go to their group after the first useful result or explore first. A joiner is first shown what the group already has. The device records that setup was shown for that member and group, so it does not keep interrupting them, and keeps a small separate record of which tools were chosen and which steps are pending, skipped or finished, so that setup can resume; both are stored on the device and are not shared with their other devices. Neither is part of the first-use record below. The design, and the record's exact contents, are assessed in our Home, widgets and setup assessment §7.

"Never used" is the part that needs a record. The app cannot honestly say "you haven't tried the photo wall yet" from what it remembers on one phone: a member who uses the photo wall every day from their other device would be told, wrongly, that they have never opened it. So the design adds one small table, private to each member, holding the first time they opened each feature — and nothing else about how they use it.

Why build this at all, in one sentence: the app should not lecture somebody about a feature they already use, and should not overwhelm somebody on their first day with surfaces they have no context for.

In scope: the first-use record (what it holds, who can read it, how long it lives); what reaches a model for the welcome and what does not; how the hint is chosen; children. Out of scope, covered elsewhere: the daily brief itself and where it is processed (the cloud-inference assessment — the welcome is a mode of the same request, and inherits its residency and spend position wholesale); the question card and "needs somebody" section, which this design only hides for a day; the motivation layer's own rules about what may never be counted (the intentions assessment), which this design applies rather than revisits.

1A. Addition, 29 September 2026: two changes that touch this record

Two changes assessed in our Home, widgets and setup assessment sit next to this record. Both are built, as described there, and neither changes the record itself.

• Arrange by use keeps its own data, on the phone, and never writes here. The option to arrange a member's Home by their use of it keeps a separate, device-local record — for each of a handful of tools, one yes/no per day for 28 days — in its own storage on the phone. It is never sent to our servers, and it is never written into user_feature_first_uses, which stays what §2 says it is: a first use per feature, with no count, no last-used and no per-group split. This table is not turned into a usage log to serve that feature or any other; a proposal to do so is a review trigger under §9 ("a column added", "any reader of the table other than the member").
• Needs-based setup changes the description of the first sitting in §1, which now says so. In place of the fixed set of seven skippable setup steps, a new member is asked what they want help with and set up for those jobs only, with a quiet way to finish later. The phone keeps a small, separate record of which jobs were chosen and which steps are pending, skipped or finished, so that setup can resume and the "you haven't tried X" hint does not suggest a tool the member has just set up or chosen not to. That record is on the phone only, holds no typed answers and no timestamps, and is not part of this table. The existing on-the-phone note that setup was offered is kept, and members who have already seen setup are not asked again. The hint itself is still chosen as §3 describes, from this record and the phone's shown set, and still never reaches a model or our servers.

1B. Addition, 29 September 2026: the welcome and the brief's cache

The daily brief is being redesigned, as assessed and accepted in our home brief assessment. Two consequences for this assessment; the record itself does not change.

• The welcome becomes a fixed sentence, written on the phone. App versions carrying the redesign stop asking our server for a model-written welcome in a member's first three days: the welcome is our own sentence, built on the phone from the group's own items, and nothing about it reaches a model. Older app versions keep the model-written welcome described in §3 until they are updated. The hint beneath the brief becomes a short action the member can tap (for example "Add a task"), chosen by the same rules, from the same device-local shown set, with a way to dismiss it that is also kept on the phone.
• The brief's cache is being made readable only by its own member. §3 and §8 describe the welcome as cached in a row "readable by the group's active members". That read rule is wider than a per-member cache should be — it also let members read one another's briefs, which include the reader's own plan — and it is fixed with the redesign: each cached row becomes readable only by the member it was written for, and expired rows are swept three days after they expire.

1C. Addition, 10 October 2026: a planned first-week suggestion, sent as a notification

Planned, not built. Today everything this document describes is drawn on a screen the member has already opened: the day-0 quiet Home, the three-day welcome, the hint on days 4 to 7. The app is being changed so that, in a member's first six days in a group, it may also send them one suggestion a day — a notification they did not ask for, which opens the screen where they would act on it.

• At most one a day, and only while a suggestion applies. On days 1 to 6 after joining, the app picks the first suggestion that still applies, from facts it already holds about the group: you are the only person in this group → "Invite someone to Smiths"; the group has no routines → "Set up your first routine in Smiths"; the group has no meal plan → "Plan this week's dinners in Smiths". It stops at day 7, and sooner if none of them applies any more. A member who does all three on day 1 is sent nothing at all.
• It never says what somebody has not done. The suggestion names the next thing to do, in the group it is about. It is not a reminder of anything the member promised, and it never counts, compares or scores — the rule that holds everywhere else in this document.
• It collects nothing, and it uses nothing new. Which suggestion applies is worked out from the group's own records — how many active members it has, whether it has routines, whether it has a meal plan — and from how many whole days the member has been in the group, the same measure §1 already uses. The first-use record is not read, and nothing is written to it: no row, no column, no "we sent this" mark. §9's review triggers ("a column added", "any reader of the table other than the member") are untouched. No AI model is involved in deciding whether to send one or which one to send.
• What it names. The group, and nothing else. No task, no event, no other member.
• Excluded. Child accounts, the shared display's account and profiles are never sent one.
• It is inside the daily limit. The app is separately being changed to send a small number of notifications nobody asked for, limited to three a day per member across all of them; of those three, at most one may be a first-week suggestion, and at most one may be the existing daily catch-up. Reminders a member set, and a daily brief they chose, do not count. It has its own switch, which can be found again.
• Residual risk, accepted. This is the first thing the app sends a member who has asked it for nothing, and the first six days are exactly when somebody is least sure what they agreed to. Three things are offered against it: it stops on its own at day 7 and cannot be restarted, the suggestion is only ever sent while it is still true of the group, and a member can switch it off without losing any other notification. What is not offered: a member cannot be asked first — being asked would be the same interruption — so the first one arrives unannounced, after the app's own explanation of notifications and the one permission request that follows it.

1D. Addition, 25 October 2026: tool cards on a quiet Home, and a one-time Tools tip

Assessed before release, against the build. Nothing in it reaches our servers or a model.

What it is. When a member's Home in a group is quiet — fewer than three tool sections (each widget and the photo strip count as one) — Home may show up to four cards under the heading "Start with a tool". Each card invites the member to start one of the app's own tools, in a fixed order: Meals, Routines, Photos, Mail Sifter, then Shopping. A card shows the tool's name, the same one-line description the Tools menu uses, and a verb ("Plan dinners", "Add a routine"); a ✕ beside it hides it. After the member starts a tool from one of these cards, the next time they are back on Home a small tip says where to find it next time — "Next time, open Routines from Tools, at the top left." — with a hand-drawn highlight on the Tools button for as long as the tip shows. For adults, the assistant's small waving figure sits beside the tip. All of this is drawn inside the app; none of it is ever a notification.

What it reads. What the phone already holds for Home, and one age check, for this member:

• their own first-use rows for Meals, Photos and Mail Sifter, read for the purpose §3 gives the record — so a card never explains a tool the member already uses. Routines and Shopping have no first-use row; for those, whether the group already has a routine or a shopping list stands in.
• their account type, their role in the group and the group's privacy level;
• whether they are under 18, read once per session from their own birth month through the same shared, cached check the app uses for AI consent, and forgotten at sign-out. Until it is known, no card and no tip is shown;
• whether the group already has that tool's thing on Home: a current meal plan, a routine, a photo, Mail Sifter switched on or an item waiting, a shopping list. Every member can already see all of these.

Nothing is collected, nothing is written to the first-use record or anywhere else on our servers, the only request is that one age check, nothing is counted or logged, and no AI model is involved. §9's review triggers are untouched: no column is added and no new reader of the table appears.

It fails closed. No card and no tip is shown while the member's first-use rows, their account type or their age has not been read, and no card for a tool while it is not yet known whether the group already has that tool's thing. A card about a tool somebody already uses would be the untrue sentence this record exists to prevent. The shared display's account never reaches Home, so it never sees a card or a tip.

What the phone keeps. Three short lists, each entry a person and a tool and nothing else: the cards this person started a tool from, the tips they have been shown, and the cards they hid. There is no time and no count in them, and adding the same entry twice changes nothing. They are kept on that phone only and never sent anywhere. They are deleted when the member signs out, and when another account signs in on the same phone, every entry that isn't the new account's is removed. A member with a second phone may see a card or a tip once more there; we accept that for the same reason §8 accepts it for hints. Edit Home has one row, "Tool suggestions show here while Home is quiet", with a switch that hides every card or brings hidden ones back, on that phone.

Children and 16- and 17-year-olds. A child account, and a member aged 16 or 17, sees only the Meals, Routines and Shopping cards:

• never Photos, because adding photos of people is sharing personal information, and the Children's Code (exposure draft) covers everyone under 18;
• never Mail Sifter, because it sends forwarded email to an AI model, and 16- and 17-year-olds need their own consent before anything of theirs does.

A child account sees the tip without the figure, because the figure is the assistant's mark and a child account has no assistant. Why this is not a nudge: it appears only on the member's own quiet Home, inside the app; it never says what somebody hasn't done; nothing is counted, and there is no streak, score or reward; the tip follows the member's own tap and only explains where something is; every card can be hidden for good; and nothing leaves the phone. §7's rule holds: a member is only ever pointed at a tool they have.

About the reader only. No card or tip names another member or compares anybody with anybody. Whether the group has a meal plan, a routine, photos or a shopping list is something every member can already see.

Arrange by use is unchanged. Tapping a card opens the tool directly; it is not one of the four ways Arrange by use notes a use, and nothing about the cards is recorded in its record.

The ban self-assessment. Choosing what to display from account information re-runs that assessment's personal-Home section; the re-run is its §15.15. It treats the cards as a further instance of a recommender feature (a condition already treated as met), adds no logged-in feature, and leaves its open finding about under-16 accounts open. It records that the Photos card, shown to known adults only and only while a group has no photos, weakens the design argument about purpose; the founder accepted that on 25 October 2026, and the card is on.

Residual risk we accept.

• A card is a suggestion the member did not ask for. It is bounded: only on a quiet Home, at most four, about the app's own tools, never again once used or hidden, and the whole set can be switched off.
• For Routines and Shopping, "used" is read from the group, not the person. A member in a group where somebody else set up a routine never sees the Routines card. That under-offers rather than over-claims, which is the direction this record already prefers. A first-use row for each of the two would fix it, and needs its own change to this table and a revision of this assessment.
• The lists are per phone, as above.
• The age rule, the child filter and the wording are conventions. Tests pin them, and tests can be deleted. This register is the memory.

1E. Addition, 8 November 2026: tips after meals and shopping actions

Approved by the founder before implementation. Twelve short tips explain the next step or result of a member's own action in Meal planner or Shopping. To avoid repeating them across phones, a separate user_guidance_seen row records the account, a closed-list tip key and the time the tip was seen. Existing members have no rows and can see each tip once. The privacy policy adds a description and change notice; the founder approved their wording on 8 November 2026. The closed keys are meals_after_adopt_v1, shopping_online_cart_v1, shopping_in_person_v1, shopping_modes_v1, shopping_staples_v1, shopping_select_v1, meals_choose_plan_v1, meals_dates_v1, meals_review_v1 meals_share_out_v1, shopping_notes_v1 and shopping_pantry_check_v1. The two shopping keys were approved on 10 November 2026, including for existing accounts. They explain product preferences, the grocery and pantry sections, and checking what is at home before sending a selection. The record is per account so it survives a second phone or reinstall; it contains no group data or free text.

Only the account owner can select or insert their rows. Clients cannot update or delete them, and no service role is granted access. Rows cascade on account deletion. Children are included under the same owner-only rule; their tips do not show an assistant figure. Where an account has no Online/In person switch, the In person tip follows its first opening of Shopping (HQ clarification, 8 November 2026). The record is a small fact about a person's use, accepted to prevent repeated explanations; a database administrator retains the ordinary direct database access described in §8. Passive viewing marks a tip only after one second on screen. Choosing “Got it” or using its anchor records an explicit dismissal immediately; leaving earlier without either action records nothing. A failed read suppresses tips rather than guessing.

2. Data involved

Strictly necessary, item by item (exposure draft s 38(2)(b)):

• user_id and feature are the whole question: has this person ever opened this surface. Nothing less can answer it, and the primary key is exactly these two columns, so a second opening of the same surface has nowhere to go — the design cannot count even by accident.
• first_used_at is not read by any rule in the app. It is kept for one reason: so that a request under the Code to see what we hold can be answered as a dated fact ("you first opened the photo wall on 3 October") rather than a bare list. If that reason is found too thin, dropping the column is a narrowing that needs no re-assessment.

Not collected, and could have been. Each absence is a decision:

• No count of uses. A count is the first step towards a score, and a score per feature per person is the profile this app has refused to build everywhere else (see the intentions assessment). The table's shape makes a count impossible rather than merely unwritten.
• No "last used". That would make the record a log of activity — when the person was in the app and what they touched — rather than a record of a first. A first is a fact that never changes; a last is surveillance of habit.
• No per-group split. The record is per person, not per person per group: somebody who has used the calendar in one group has used the calendar. A per-group row would double the record and, incidentally, write down which groups a person is active in — more than the question needs. (Tenure, by contrast, is per group, because "how new are you here" is a question about a membership, and it is read from the membership row that already exists.)
• No completion state, no dismissals, no "hint seen" on the server. Which hints a device has shown is kept on that device only. It is a rendering preference, not a fact about the person, and it does not need to survive a reinstall.
• Nothing about other members. The record answers a question about the reader and is shown only to the reader. Nothing in this design displays to anybody how another member uses the app, and no comparison ("most of your group uses the photo wall") is ever derived — see §6.

3. Flows and locations

The lines that carry the design:

• The first-use record never reaches a model and never reaches our server. The hint is chosen deterministically on the device: the first feature in a fixed order with no first-use row and no entry in the device's "shown" set, and only if seven days have passed since the last hint. There is no request in which the rows travel, so "what features have you never used" is not something any model or any log ever learns.
• The welcome carries no more than the brief does, plus one small number. The ordinary brief already sends the group's horizon items on the member's own request; the welcome mode adds which of the first three days this is. The roster is not sent, and the welcome line is validated before display for the same rule the beneficiary question already obeys — it may not contain a personal name. A line that fails is replaced by our own fixed sentence for that day.
• A whole day, never a timestamp. The tenure day joins the cache key for the brief, so the welcome regenerates when the day rolls over and not before; the join time itself never enters a prompt or a key. This is the same discipline the brief already keeps against minute-granular values: the clock is not a reason to spend, and a precise join time in a request is a precise fact about a person that the sentence does not need.
• Device-only groups get the fixed welcome and never the model's. The welcome is a mode of the brief request, and that request is refused server-side for a Device-only group before anything is composed. The fixed sentences for days 0–2 are composed on the phone from rows the phone already holds, which is the promise that level makes.
• Nothing here is logged in a way that names a person beyond what the brief already logs. The first-use write is an ordinary row insert through the member's own session; it carries a user id and a feature name, and no diagnostic line records either.

4. Legal basis and consents

No new consent purpose. The record is created by the member's own act of opening a surface; the welcome and the hint are rendered on the member's own Home screen, to the member alone; and the one thing that reaches a model — the welcome — reaches it on the same terms and under the same group-level control (the privacy level) as the brief it replaces. Nothing is bundled with any existing consent, and nothing expires, because nothing new is consented to.

Precondition, as for every collection this app adds: before the record ships, the privacy policy's list of what we hold gains a line naming it, in these words or close to them — which features of the app you have opened, and the date you first opened each, kept so that the app does not explain a feature you already use; visible only to you; deleted with your account — and the policy's version moves so the addition is dated. A record that the policy does not describe is a collection a member was not told about, whatever its size.

For a child account the record is created the same way, by the child's own use, and is held under the same rule: readable by the child alone. The child privacy policy points at the main policy's list, so the line above covers it; §7 says what the child is told on the surface itself.

5. Risks and mitigations

6. Structural versus conventional

Structural: the record's shape — two-column primary key, no count, no recency, no UPDATE or DELETE for any client, so a first is written once and cannot be edited into a log; row-level security that admits only the member whose row it is, with no group predicate and no server grant; the cascade from the member's account, so deletion reaches it without a sweep; the closed feature list, enforced by a CHECK constraint mirrored in the code; the server-side refusal of the brief request (and so of the model-written welcome) for a child account and for a Device-only group; the welcome request's shape, which has no field for the roster or the first-use rows to travel in.

Conventional, each to be pinned by a test in the build: the deterministic hint choice (first feature in a fixed order with no row and no "shown" entry); the once-a-week cadence and the never-twice rule; that every hint names a control that exists on the screen it points at; the no-comparison, no-count, no-streak vocabulary of every welcome and hint sentence; the validator that drops a welcome line naming a person; the device-side filter that keeps a child's hints to the surfaces a child has; the day-0 gating of the question card and needs section; the whole-day (never timestamp) granularity of what joins the cache key.

The rule we hold ourselves to, in our own words: nothing in this app shows a member how others engaged with what they posted, and nothing in the motivation layer is counted, scored or ranked. A first-use record is about the reader alone, is shown to the reader alone, and is never aggregated. A hint may say "you haven't tried the photo wall"; it may never say "you've used 4 of 9 features", because that is a score, and it may never say how anybody else compares, because that is a report on other people.

7. Best interests of the child

A child account is a member, and gets the welcome and the hints — for the surfaces a child has.

• What it gives the child: the same thing it gives an adult, arguably more so. A thirteen- year-old added to a family group is the member least likely to know what the app is for, and the one most likely to be handed a screen full of adult coordination on day one. A quieter first day and a plain welcome are in their interest.
• What it costs them: a record, held under their account, of which surfaces they have opened and when — about a dozen rows at most, no counts, no dates beyond the first. Readable by the child alone: not by a guardian, not by an admin, not by us through any server path. The record is deleted with the account.
• The safer design considered: writing no first-use rows for a child at all, and giving them only the tenure hints. It was not chosen because the alternative is a hint that explains a surface the child already uses — noise on the one screen that should be quiet — and because the record's content (a surface name and a first date, for the child's own eyes) is about as small as a record can be. We note it as the design to return to if the record ever grows (§9).
• Where the child's and the adult's interests diverge: nowhere in this feature, because no adult can read the child's record. There is no "see what your child has explored" view, and the guardian rule that lets an adult see what a child does within the group does not reach this table — the record is not group content.
• What the child is told (the s 33 posture): the hint itself is the disclosure — "you haven't tried X yet" is a sentence the child can check against their own memory, and the child page that lists what the adults in the group can and cannot see does not list this record among the things they can. The child-directed policy carries the same line as the main one (§4).
• Nothing here names the assistant tab for a child. A child account has no assistant, and a hint that pointed at it would be a door onto a surface that does not exist for them. The hint list is filtered by the same predicate that hides the tab.

8. Residual risk we accept

• A first-use record is, in the smallest possible way, a record of behaviour. It says which parts of the app a person has tried. We hold it because the alternative is telling people things about their own use that are false, and we bound it by shape (no count, no recency, no reader but the person). We accept that "which features somebody has opened" is a fact about them that did not exist before.
• "Used" means "opened once". A member who tapped into the games tab by accident and left is recorded as having used games and never gets the hint that might have explained it. Accepted: the alternative is a measure of how much they used it, which is the count this design refuses.
• The shown set is per device. A member with two phones may see the same hint on each, and the once-a-week cadence is per device too. Accepted: the alternative is a server-side record of which hints a person has been shown, which is more about the person than the thing it would fix.
• The welcome is cached in a row the group can read. It describes the group's own events and tasks, which every active member can already read, and names nobody; what a co-member could infer is that somebody is new, which the member who invited them knows. Accepted. 29 September 2026: that read rule is being narrowed to the member the row was written for, and app versions carrying the redesigned brief no longer write a model welcome at all (§1B).
• A database administrator with direct access can read the table, as any table. No application role can. This is the standing residual for every plaintext row in this app and is not specific to this feature; it is stated so its absence is not read as a claim.
• The cadence, the no-comparison rule and the child filter are conventions. Tests will pin them; tests can be deleted. This register is the memory.

9. Review trigger

Re-read and revise this assessment before building any of:

• a column added to user_feature_first_uses — a count, a last-used time, a per-group key, a dismissal. Any of these changes what the table is, and §2's argument that it cannot become a profile stops being true;
• any reader of the table other than the member — a guardian view, an admin view, a server route, an export, an aggregate ("how many members have tried X"). The last of these is also a question for the ban self-assessment, because a per-feature adoption figure shown to anybody is one step from a comparison;
• the first-use rows, or the "shown" set, reaching a model — for "smarter" hint selection or a personalised welcome. The hint is deterministic on purpose;
• the welcome request carrying the roster, a name, or the join time itself rather than the day number;
• a hint that references anybody but the reader, or any sentence that counts features used;
• the feature shipping — this draft is replaced by a revision against the code, which says what was built as designed and what was not.

10. Checklist against exposure draft s 38(2)

s 38(3): this assessment precedes the build. s 39: listed on the published register.

11. Sources

Primary: the Children's Online Privacy Code exposure draft, ss 10, 13, 33, 38, 39; the Online Safety (Age-Restricted Social Media Platforms) Rules 2025, s 4A (the feedback-feature limb that the no-comparison rule in §6 keeps this feature clear of).

Sibling assessments: ./cloud-inference.md (the brief's residency and spend position, which the welcome inherits); ./intentions.md (nothing in the motivation layer is counted); ./2026-09-ban-self-assessment.md §5.3 (what a feedback feature is); ./child-accounts.md (which surfaces a child account has, and the server-side refusal of the brief for a child); ./privacy-levels.md (what Device-only promises).

In repo: agent-server/src/insight/index.ts (the brief route: what the request carries, the child-account and privacy-level refusals, and the cache write the welcome shares); agent-server/src/insight/beneficiaryAsk.ts and lib/beneficiaryAsk.ts (the no-personal-name validator the welcome line copies); hooks/useDashboardInsight.ts (the cache key the tenure day joins, and the byte-identical-across-ticks rule); lib/dashboardFallbackBrief.ts (the fixed sentence the welcome falls back to); lib/groupScopedState.ts (the classification of per-person state that survives a group switch, which the first-use record and the shown set will join); supabase/migrations/20260729040000_group_invites_and_approvals.sql (the membership row's status column tenure is counted from); supabase/migrations/20260804135141_add_group_dashboard_insights.sql and supabase/migrations/20260909010328_insight_cache_member_write.sql (the group-readable brief cache, §8); components/Chat/__tests__/noFeedbackFeatures.test.ts and lib/__tests__/motivationCopy.test.ts (the vocabulary scans the hint and welcome copy will sit under); constants/legalTexts.ts (the privacy policy list that gains the line in §4); our internal engineering rules on the home brief being promoted, on the prompt and the cache key answering different questions, on nothing in the motivation layer being counted, and on the app showing nobody how others engaged with what they posted.

For §1D (25 October 2026): lib/starterCards.ts (which cards a member sees, failing closed, and the per-person markers), constants/starterCards.ts (every word the cards and the tip say), store/slices/createStarterCardsSlice.ts (the three lists, and their clearing on sign-out and on another account signing in), components/Home/StarterCards.tsx and components/Home/TrayTip.tsx (the cards and the tip), and their tests lib/__tests__/starterCards.test.ts, store/__tests__/starterCardsSlice.test.ts and components/Home/__tests__/TrayTip.test.tsx; lib/__tests__/toolUseCallSites.test.ts (still exactly four ways Arrange by use notes a use).