Technical reference. For task-based help, see the corresponding user guide.

Documentation status: complete for the current implementation

Reviewed: 2026-07-21

Primary users: family members and assigned coaches with activity permissions

Surfaces: mobile web app and platform API

Activity Tracking records a baby's day-to-day care in seven consistent trackers. Each tracker combines fast entry, a full manual form, baby-scoped history, correction/deletion and timezone-aware grouping. Tracking remains available when premium analysis access is inactive.

Family tracking routes use /family/track/:activityType. Coach view-as uses /coach/families/:familyId/track/:activityType and carries an explicit babyId. Home cards, reminder notifications, floating timers and Analysis chart points can all open the same tracking/edit surface.

Supported activity types are breastfeed, bottle, sleep, nappy, pumping, medication and solids.

1. Confirm or switch the baby at the top of the tracker.
2. Use a tracker-specific quick action, choose timer/manual entry where offered, or open the full form.
3. Review the generated date/time and details, add an optional family note, then save.
4. The newly saved item appears in date-grouped history and updates Home/Analysis through refresh and realtime events.
5. Select a history row to correct it or delete it when the current actor has write permission.

Family notes belong to the family-authored record. A coach can read them as permitted but the coach edit flow does not overwrite them; coach-only context is stored through the separate private-note feature.

For Breastfeeding, Sleep and Pumping, the full form rejects invalid ranges and start/end values more than two minutes in the future. Sleep overlap or implausible-gap findings are presented as explicit warnings to review/confirm rather than silently rewriting the user's times.

1. History is filtered to the selected baby and current tracker, sorted newest first and grouped by the family's local date.
2. The space between records is labelled; Sleep uses awake-gap language.
3. Cursor pagination loads older records without replacing the current page.
4. Solids can be filtered to Reactions only.
5. Range activities show duration and start/end details; point activities show the recorded local time.
6. Sleep entries that cross midnight follow the product's sleep-day attribution so Home, history and Analysis agree.
7. Changing the selected baby resets the tracker query and prevents records from the previous baby appearing under the new heading.

New records send a UUID clientMutationId. The platform derives occurredAt from the relevant start/time, stores the supplied IANA timezone and a local-date key, and treats mutation retries idempotently. Timer saves also include activeTimerId so completing a stopped timer and creating its activity form one durable operation.

If a realtime refresh indicates that the open activity changed elsewhere, the editor blocks an overwrite and asks the user to reload or close the stale edit. Deletion requires an explicit user action and removes that activity from subsequent Home, history and Analysis views.

Only creates have a persistent offline outbox. An offline create appears as pending/failed and can retry or be discarded. Existing-record edits and deletes require the server and must not be presented as durably queued. Timer review and offline mechanics are detailed in Feature 08.

1. The coach route resolves the selected family and baby as the data subject while retaining the coach as actor.
2. A current assignment with canWriteActivities permits activity create, edit and delete; read-only assignments cannot mutate.
3. Coach-created/edited records are audited by the platform.
4. Coach writes omit the family note field, preserving any existing family-authored note.
5. Revocation or expiry is checked again on every API operation; hiding buttons is not the security boundary.

The API validates the discriminated details schema for the selected type and ensures the baby, activity, ladder/stage and media all belong to the resolved family subject.

1. New records carry the family/client IANA timezone and a server-derived local date.
2. Changing the family timezone affects future day boundaries and display, but does not rewrite the timezone saved on historical records.
3. Amounts retain their entered unit while analysis can normalize display to the family's preferred unit.
4. Realtime refresh and idempotency solve different problems: refresh detects concurrent changes, while clientMutationId prevents duplicate creates after retries.
5. Tracking data remains accessible without premium; only Analysis is entitlement-gated.

1. Every tracker validates and persists its documented details for the selected baby.
2. Quick actions produce reviewable records and timer-backed types hand off safely to timer review.
3. History groups by family-local date, paginates without duplication and supports corrections.
4. Offline create retries cannot make duplicate activities; edits/deletes are never falsely shown as queued.
5. A stale edit cannot silently overwrite a realtime external change.
6. Coach writes require current permission and preserve family-authored notes.
7. Activity APIs reject cross-family babies, records, ladder stages and media.

• mobile-web/src/routes/ActivityTrackingScreen.tsx
• mobile-web/src/timers/ActiveTimersContext.tsx
• mobile-web/src/offline/ActivityCreateOutboxContext.tsx
• mobile-web/src/realtime/use-resource-realtime-refresh.ts
• platform/apps/api/src/routes/family-routes.ts
• platform/apps/api/src/services/family-service.ts
• platform/packages/shared/src/family.ts
• platform/docs/multi-tenancy/06-existing-app-feature-inventory.md

• 05 — Family home
• 06 — Baby profiles and switching
• 08 — Active timers and durable saves
• 09 — Analysis and trends
• 11 — Allergy ladders
• 19 — Coach private notes