System Requirements Document for mellow-hey

1. Introduction

mellow-hey is a personal-use application for one person to keep a gentle, durable record of their own daily health and routine. The product exists because its requester wants a single place to note three things they already do every day — exercise, what they eat and drink, and how they sleep — and to be able to look back over those notes to understand their own routine.

The intent is deliberately narrow and personal. This is not a clinic tool, a coaching platform, a social fitness network, or a multi-user wellness dashboard. It is a quiet daily ritual: log the day, then review it. The audience is exactly one person — the requester — tracking their own body over months, in the calm moments at the start and end of a day.

The product must feel like care rather than surveillance. It records serious data (minutes moved, food and drink taken, hours slept) but presents it warmly, without scolding, streaks, deficits framed as failure, or gamified rewards.

2. System Overview

mellow-hey is a single-user web application with a first-party backend that stores the user's own health and routine records durably. The current delivery covers:

• Exercise tracking — recording exercise activity and reviewing recorded exercise.
• Nutrition tracking — recording what the user eats and drinks, and reviewing recorded intake.
• Sleep tracking — recording sleep and reviewing recorded sleep entries.
• History — reviewing previously recorded exercise, food and drink, and sleep entries together.

Because the records are personal and must persist across sessions and months, the application owns the user's identity: a first-use enrollment path establishes the account, and returning verification restores access to that person's own durable records. No other person is an actor in this product, and no differentiated roles, permissions, or shared-state visibility exist.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. All accepted behavior is delivered as first-party custom UI owned by the application, backed by the application's own backend and durable storage. There is no provider-owned or external-destination surface in the current product, and no headless-only delivery.

Identity and access. The application owns identity because the accepted journeys require durable, privately owned, resumable personal records bound to the correct person. The anonymous entry surface (Landing) explains the product before any identity is established. Login and Sign Up are themselves anonymously reachable — a protected destination cannot own the interaction that grants access to itself. Every tracking and review destination (Exercise, Exercise Entry, Nutrition, Nutrition Entry, Sleep, Sleep Entry, History) requires an established identity, because each one reads or writes records that must remain bound to the correct person across sessions.

Current vs. future. Everything in this document is current. No future-horizon requirements were stated by the user, and none are invented here. The only explicit constraint is that the app or software is for personal use — it is built for the requester's own tracking, not for other people's accounts, teams, or public sharing.

Narrow exclusions. The product does not include social features, coaching, medical diagnosis, calorie-deficit judgment, streak shaming, wearable integrations, or multi-user administration. These are excluded because they were never requested and would contradict the stated personal-use, non-judgmental intent.

2c. Page Content and Component Coverage

Landing

• Information / state: Anonymous first impression. Explains that mellow-hey is a personal app for keeping a daily record of exercise, food and drink, and sleep, and that the record is the user's own. No personal health data is shown here.
• Primary actions: Begin first-use enrollment (to Sign Up); go to returning verification (to Login).
• Supporting actions: Read the product explanation; view the three ritual areas named (Move, Nourish, Rest) as descriptions only, not as live data.
• Domain entities: None persisted. The three tracking domains (exercise, nutrition, sleep) are described, not read.
• Component responsibilities: Hero still-life composition with the oversized headline and a single sage pill call to action; a rotated cream summary card that illustrates the three metric shapes (Move, Nourish, Rest) as illustrative numerals, clearly not the visitor's own data; entry links to Sign Up and Login.
• States: Loading — static content, no data fetch. Empty — not applicable; the page is always fully populated with explanatory content. Success — visitor reaches Sign Up or Login. Error — if the visitor follows a link and the destination fails to load, the destination owns its own error state. Recovery — the visitor can return to Landing from either access surface.

Login

• Information / state: Returning verification form. Anonymous access. States that signing in restores access to the user's own durable health and routine records.
• Primary actions: Submit credentials to verify identity and continue to the tracking destinations.
• Supporting actions: Navigate to Sign Up if the user has not yet enrolled; return to Landing.
• Domain entities: Account identity (email/identifier and credential). No health records are read on this page.
• Component responsibilities: Aligned label-above-field credential inputs; a full-width sage pill submit control; an inline error region; a link to Sign Up.
• States: Loading — submit control shows an in-progress state while verification is checked. Empty — fields start blank. Success — identity verified; the user continues to a tracking destination. Error — incorrect or unrecognized credentials show an inline, non-judgmental message and keep the entered identifier so the user can correct it. Recovery — the user may retry, or move to Sign Up, without losing their place.

Sign Up

• Information / state: First-use enrollment form. Anonymous access. Explains that the account exists so the user's own daily records persist and remain theirs.
• Primary actions: Create the account and continue into the tracking destinations.
• Supporting actions: Navigate to Login if the user already has an account; return to Landing.
• Domain entities: Account identity (identifier and credential) created for the single personal user.
• Component responsibilities: Aligned label-above-field inputs for the enrollment details; a full-width sage pill submit control; an inline validation and error region; a link to Login.
• States: Loading — submit control shows an in-progress state while the account is created. Empty — fields start blank. Success — account created and the user continues to a tracking destination. Error — invalid or already-used details show an inline message with the offending field identified. Recovery — the user corrects the field and resubmits, or moves to Login.

Exercise

• Information / state: Revisitable overview of the user's recorded exercise routine. Shows today's exercise summary, the last seven days as rounded bars, and a plain list of past exercise entries with date and value, with a terracotta dot on today's row.
• Primary actions: Open Exercise Entry to record a new exercise entry.
• Supporting actions: Browse the seven-day bar strip; read the past-entry list; open a past entry's detail for review.
• Domain entities: Exercise entry (date, activity, duration, optional note).
• Component responsibilities: Day-completion arc; seven-day rounded bar strip; reverse-chronological entry list with hairline row rules; the "log now" affordance in terracotta.
• States: Loading — the day arc and bars render at their final values once data arrives; a quiet placeholder holds the layout. Empty — a single soft pale-sage blob with a hand-drawn-feeling shoe line icon and an invitation to record the first exercise entry. Success — the recorded entries and today's summary are shown. Error — if records cannot be loaded, an inline message explains and offers a retry. Recovery — retry reloads the overview; the user can still open Exercise Entry.

Exercise Entry

• Information / state: Focused workspace for recording one daily exercise entry. Shows the fields for the entry and the current day's context.
• Primary actions: Save the exercise entry.
• Supporting actions: Discard the in-progress entry and return to Exercise; adjust field values before saving.
• Domain entities: Exercise entry (date, activity, duration, optional note).
• Component responsibilities: Single-column aligned label-above-field form; a full-width "Save entry" sage pill pinned at the bottom of the form; the day arc that nudges forward on save.
• States: Loading — the form is available immediately; any prefilled context loads quietly. Empty — fields start blank for a new entry. Success — the pill label changes in place to a past-tense confirmation (for example "Logged 34 min") and the day arc nudges forward; no toast, no modal. Error — a missing or invalid required field shows an inline message beside that field and the entry is not saved. Recovery — the user corrects the field and saves again; the entered values are preserved.

Nutrition

• Information / state: Revisitable overview of the user's recorded food and drink intake. Shows today's intake summary, the last seven days as rounded bars, and a plain list of past intake entries with date and value, with a terracotta dot on today's row.
• Primary actions: Open Nutrition Entry to record new food or drink intake.
• Supporting actions: Browse the seven-day bar strip; read the past-entry list; open a past entry's detail for review.
• Domain entities: Nutrition entry (date, item, kind — food or drink, amount, optional note).
• Component responsibilities: Day-completion arc; seven-day rounded bar strip in the pale-ochre nutrition band; reverse-chronological entry list with hairline row rules; the "log now" affordance in terracotta.
• States: Loading — the day arc and bars render at their final values once data arrives; a quiet placeholder holds the layout. Empty — a single soft pale-ochre blob with a hand-drawn-feeling cup line icon and an invitation to record the first intake entry. Success — the recorded entries and today's summary are shown. Error — if records cannot be loaded, an inline message explains and offers a retry. Recovery — retry reloads the overview; the user can still open Nutrition Entry.

Nutrition Entry

• Information / state: Focused workspace for recording daily food and drink intake. Shows the fields for the entry and the current day's context.
• Primary actions: Save the nutrition entry.
• Supporting actions: Discard the in-progress entry and return to Nutrition; adjust field values before saving.
• Domain entities: Nutrition entry (date, item, kind — food or drink, amount, optional note).
• Component responsibilities: Single-column aligned label-above-field form; a full-width "Save entry" sage pill pinned at the bottom of the form; the day arc that nudges forward on save.
• States: Loading — the form is available immediately; any prefilled context loads quietly. Empty — fields start blank for a new entry. Success — the pill label changes in place to a past-tense confirmation (for example "Logged 1,840 kcal") and the day arc nudges forward; no toast, no modal. Error — a missing or invalid required field shows an inline message beside that field and the entry is not saved. Recovery — the user corrects the field and saves again; the entered values are preserved.

Sleep

• Information / state: Revisitable overview of the user's recorded sleep. Shows today's sleep summary, the last seven days as rounded bars, and a plain list of past sleep entries with date and value, with a terracotta dot on today's row.
• Primary actions: Open Sleep Entry to record a new sleep entry.
• Supporting actions: Browse the seven-day bar strip; read the past-entry list; open a past entry's detail for review.
• Domain entities: Sleep entry (date, bedtime, wake time, duration, optional note).
• Component responsibilities: Day-completion arc; seven-day rounded bar strip; reverse-chronological entry list with hairline row rules; the "log now" affordance in terracotta.
• States: Loading — the day arc and bars render at their final values once data arrives; a quiet placeholder holds the layout. Empty — a single soft pale-sage blob with a hand-drawn-feeling crescent-moon line icon and an invitation to record the first sleep entry. Success — the recorded entries and today's summary are shown. Error — if records cannot be loaded, an inline message explains and offers a retry. Recovery — retry reloads the overview; the user can still open Sleep Entry.

Sleep Entry

• Information / state: Focused workspace for recording one daily sleep entry. Shows the fields for the entry and the current day's context.
• Primary actions: Save the sleep entry.
• Supporting actions: Discard the in-progress entry and return to Sleep; adjust field values before saving.
• Domain entities: Sleep entry (date, bedtime, wake time, duration, optional note).
• Component responsibilities: Single-column aligned label-above-field form; a full-width "Save entry" sage pill pinned at the bottom of the form; the day arc that nudges forward on save.
• States: Loading — the form is available immediately; any prefilled context loads quietly. Empty — fields start blank for a new entry. Success — the pill label changes in place to a past-tense confirmation (for example "Logged 7h 20m") and the day arc nudges forward; no toast, no modal. Error — a missing or invalid required field shows an inline message beside that field and the entry is not saved. Recovery — the user corrects the field and saves again; the entered values are preserved.

History

• Information / state: One continuous reverse-chronological ledger of the user's previously recorded exercise, food and drink, and sleep entries, with month rules and a sticky month label. A month wheel shows the month's logging at a larger scale.
• Primary actions: Read past entries across all three domains.
• Supporting actions: Scroll through months; distinguish entry types by their ritual tone (sage for exercise, ochre for nutrition, terracotta for sleep); open a past entry's detail for review.
• Domain entities: Exercise entry, nutrition entry, and sleep entry, unified in one ledger.
• Component responsibilities: Sticky month label; full-width hairline month rules; the 180px month wheel; per-entry rows carrying date, value, and domain tone.
• States: Loading — the month wheel renders at its final value once data arrives; the ledger holds its layout. Empty — a single soft blob with an invitation to begin logging, since no entries exist yet. Success — the ledger shows all recorded entries in reverse-chronological order. Error — if the ledger cannot be loaded, an inline message explains and offers a retry. Recovery — retry reloads the ledger; the user can move to any tracking destination to add entries.

3. Functional Requirements

FR-1 — Personal-use health and daily routine tracking As a Personal Health Tracker, I should have a personal app for my own health and daily routine, so that my exercise, food and drink, and sleep are kept in one place.

• Provenance: explicit.
• Trigger: the user opens the application.
• Observable result: the application presents the personal tracking product and its three ritual areas.
• Access state: the anonymous Landing surface is reachable without identity; tracking destinations require an established identity.
• Failure/recovery: if the application cannot be reached, the user retries; no data is lost because nothing was written.
• Continuation: the user proceeds to enroll, verify, or open a tracking destination.
• Constraint: the app or software is for personal use.

FR-2 — Track exercise activity As a Personal Health Tracker, I should record my exercise activity, so that my movement for the day is captured.

• Provenance: explicit.
• Trigger: the user opens Exercise Entry and enters an exercise entry.
• Observable result: the entry is saved and appears in the Exercise overview and in History; the day arc nudges forward.
• Access state: requires an established identity, because the entry is durable personal data.
• Failure/recovery: a missing or invalid required field shows an inline message and the entry is not saved; the user corrects it and saves again with values preserved.
• Continuation: the user returns to Exercise to see the updated overview, or continues to another ritual area.

FR-3 — Track what the user eats and drinks As a Personal Health Tracker, I should record what I eat and drink, so that my daily intake is captured.

• Provenance: explicit.
• Trigger: the user opens Nutrition Entry and enters a food or drink entry.
• Observable result: the entry is saved and appears in the Nutrition overview and in History; the day arc nudges forward.
• Access state: requires an established identity, because the entry is durable personal data.
• Failure/recovery: a missing or invalid required field shows an inline message and the entry is not saved; the user corrects it and saves again with values preserved.
• Continuation: the user returns to Nutrition to see the updated overview, or continues to another ritual area.

FR-4 — Track sleep As a Personal Health Tracker, I should record my sleep, so that my rest for the day is captured.

• Provenance: explicit.
• Trigger: the user opens Sleep Entry and enters a sleep entry.
• Observable result: the entry is saved and appears in the Sleep overview and in History; the day arc nudges forward.
• Access state: requires an established identity, because the entry is durable personal data.
• Failure/recovery: a missing or invalid required field shows an inline message and the entry is not saved; the user corrects it and saves again with values preserved.
• Continuation: the user returns to Sleep to see the updated overview, or continues to another ritual area.

FR-5 — Review recorded exercise As a Personal Health Tracker, I should review my recorded exercise, so that I can understand my movement routine over time.

• Provenance: required_inference (indispensable observable result of FR-2).
• Trigger: the user opens Exercise.
• Observable result: today's exercise summary, the last seven days as rounded bars, and a plain list of past exercise entries are shown.
• Access state: requires an established identity.
• Failure/recovery: if records cannot be loaded, an inline message explains and offers a retry.
• Continuation: the user opens Exercise Entry to add another entry, or moves to another destination.

FR-6 — Review recorded food and drink intake As a Personal Health Tracker, I should review my recorded food and drink intake, so that I can understand my intake routine over time.

• Provenance: required_inference (indispensable observable result of FR-3).
• Trigger: the user opens Nutrition.
• Observable result: today's intake summary, the last seven days as rounded bars, and a plain list of past intake entries are shown.
• Access state: requires an established identity.
• Failure/recovery: if records cannot be loaded, an inline message explains and offers a retry.
• Continuation: the user opens Nutrition Entry to add another entry, or moves to another destination.

FR-7 — Review recorded sleep As a Personal Health Tracker, I should review my recorded sleep, so that I can understand my rest routine over time.

• Provenance: required_inference (indispensable observable result of FR-4).
• Trigger: the user opens Sleep.
• Observable result: today's sleep summary, the last seven days as rounded bars, and a plain list of past sleep entries are shown.
• Access state: requires an established identity.
• Failure/recovery: if records cannot be loaded, an inline message explains and offers a retry.
• Continuation: the user opens Sleep Entry to add another entry, or moves to another destination.

FR-8 — Review previously recorded entries together As a Personal Health Tracker, I should review my previously recorded exercise, food and drink, and sleep entries together, so that I can see my whole routine in one continuous record.

• Provenance: required_inference (indispensable review outcome spanning FR-2 through FR-4).
• Trigger: the user opens History.
• Observable result: one reverse-chronological ledger of all recorded entries with month rules, a sticky month label, and a month wheel.
• Access state: requires an established identity.
• Failure/recovery: if the ledger cannot be loaded, an inline message explains and offers a retry.
• Continuation: the user moves to any tracking destination to add entries, or continues reading.

FR-9 — Self-service enrollment As a Personal Health Tracker, I should be able to enroll myself on first use, so that my own durable health and routine records have an owner.

• Provenance: required_inference.
• Trigger: the user chooses to begin from Landing.
• Observable result: an account is created and the user continues into the tracking destinations.
• Access state: Sign Up is anonymously reachable; it does not itself require an established identity.
• Failure/recovery: invalid or already-used details show an inline message identifying the field; the user corrects it and resubmits, or moves to Login.
• Continuation: the user proceeds to a tracking destination.

FR-10 — Returning verification As a Personal Health Tracker, I should verify myself when I return, so that I can reach my own durable health and routine records.

• Provenance: required_inference.
• Trigger: the user chooses to sign in from Landing.
• Observable result: identity is verified and the user continues to a tracking destination.
• Access state: Login is anonymously reachable; the destinations it unlocks require an established identity.
• Failure/recovery: incorrect or unrecognized credentials show an inline, non-judgmental message and keep the entered identifier so the user can correct it; the user may retry or move to Sign Up.
• Continuation: the user proceeds to a tracking destination.

4. User Personas

Personal Health Tracker

Product context. This is the single intended user of mellow-hey, and the only human actor in the product. They are building a personal record of their own body and daily routine — not managing anyone else, not being managed. They use the app in quiet moments: at the start of a day to note how they slept, and at the end of a day to note what they ate and drank and how they moved. Their horizon is months, not a single session.

Primary goal. To have their own exercise, food and drink, and sleep captured and reviewable in one place, so they can understand their own routine over time.

Distinct accepted responsibilities.

• Recording exercise activity (FR-2).
• Recording what they eat and drink (FR-3).
• Recording their sleep (FR-4).
• Reviewing each of those records individually (FR-5, FR-6, FR-7).
• Reviewing all of them together as one continuous record (FR-8).
• Establishing their own account on first use (FR-9) and verifying themselves when they return (FR-10).

Relevant inputs and decisions. The user supplies the substance of every entry: the activity and duration for exercise; the item, whether it is food or drink, and the amount for nutrition; bedtime, wake time, and duration for sleep. They decide when to log and when to look back. They decide whether to correct a rejected entry or abandon it.

Interactions with other accepted participants. There are none. This is a personal-use product with exactly one human actor. The application itself is the counterparty that stores, returns, and preserves the user's records; it is not a persona.

Observable success. The user's own entries are saved, appear in the relevant overview and in History, and remain available when they return in a later session. The day arc advances as the day's logging completes.

What makes this role distinct. The work is self-directed and self-observed. There is no reporting relationship, no comparison to other people, and no external judgment. The register is care, not compliance — the user is the subject, the author, and the only reader of their own record.

5. Core User Flows

Flow A — First use: enroll and record the first day

1. The user opens mellow-hey and lands on Landing without any identity established. They read what the product is: a personal record of exercise, food and drink, and sleep.
2. The user selects the sage pill call to action and arrives at Sign Up.
3. On Sign Up, the user enters their enrollment details and submits. The submit control shows an in-progress state while the account is created.
4. If a detail is invalid or already in use, Sign Up shows an inline message identifying the field, and the user corrects it and resubmits. Their other entered values are preserved.
5. On success, the account is created and the user continues into the tracking destinations. Their records now have an owner.
6. The user opens Exercise Entry and records their exercise for the day — activity and duration. They press the "Save entry" sage pill. The pill label changes in place to a past-tense confirmation and the day arc nudges forward. No toast, no modal.
7. The user opens Nutrition Entry and records what they ate and drank — item, whether it is food or drink, and amount. They save, and the same in-place confirmation and day-arc nudge occur.
8. The user opens Sleep Entry and records their sleep — bedtime, wake time, and duration. They save, and the same in-place confirmation and day-arc nudge occur.
9. The user opens History and sees all three entries in one reverse-chronological ledger under the current month rule, with the month wheel showing the month's logging.
10. Continuation: the user closes the app. Their entries are durable and will be there when they return.

Flow B — Returning: verify and log the day

1. The user returns to mellow-hey and lands on Landing.
2. The user selects the path to Login.
3. On Login, the user enters their credentials and submits. The submit control shows an in-progress state while verification is checked.
4. If the credentials are incorrect or unrecognized, Login shows an inline, non-judgmental message and keeps the entered identifier so the user can correct it. The user may retry, or move to Sign Up if they believe they have no account.
5. On success, identity is verified and the user continues to a tracking destination.
6. The user opens Exercise, sees today's summary arc, the last seven days as rounded bars, and the plain list of past exercise entries with a terracotta dot on today's row. They open Exercise Entry to add today's exercise, save it, and return to the updated overview.
7. The user opens Nutrition, reviews today's intake summary and the seven-day bars, opens Nutrition Entry to record a meal or drink, saves it, and returns to the updated overview.
8. The user opens Sleep, reviews today's sleep summary and the seven-day bars, opens Sleep Entry to record last night's sleep, saves it, and returns to the updated overview.
9. Continuation: the user opens History to read the day in the context of the month, then closes the app.

Flow C — Reviewing a routine over time

1. The user is already verified and opens History.
2. The ledger loads in reverse-chronological order with month rules and a sticky month label. The 180px month wheel renders at its final value.
3. The user scrolls back through months, distinguishing exercise, nutrition, and sleep rows by their ritual tone — sage, ochre, and terracotta.
4. The user opens a past entry's detail to review it.
5. Continuation: the user moves to Exercise, Nutrition, or Sleep to add a new entry, or continues reading.

Flow D — Recovering from a failed load or a rejected entry

1. The user opens a tracking destination — Exercise, Nutrition, Sleep, or History — and the records cannot be loaded.
2. The destination shows an inline message explaining the failure and offering a retry. The layout holds; nothing is fabricated.
3. The user retries. On success, the overview or ledger loads with the day arc and bars at their final values.
4. If instead the user was saving an entry and a required field was missing or invalid, the entry form shows an inline message beside that field and the entry is not saved.
5. The user corrects the field and saves again. Their other entered values are preserved, and the in-place confirmation and day-arc nudge occur on success.
6. Continuation: the user returns to the relevant overview or to History.

Flow E — First entry when nothing has been recorded yet

1. The user is verified and opens Exercise (or Nutrition, or Sleep) before any entry exists in that area.
2. The overview shows a single soft blob in the area's pale tone — pale sage for exercise and sleep, pale ochre for nutrition — with a hand-drawn-feeling line icon inside and an invitation to record the first entry.
3. The user opens the matching entry workspace, records the entry, and saves it.
4. The overview now shows today's summary arc, the seven-day bars, and the first row in the past-entry list.
5. Continuation: the user repeats this for the other ritual areas, or opens History, which shows its own empty invitation until entries exist.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section: Humane technology — soft forms for a daily ritual of care, after Yves Béhar. The muse is Yves Béhar; the headline idea is Your day, kept gently. The register is calm, warm, encouraging, and non-judgmental — a well-made object you keep on a nightstand, not a productivity tool.

Color tokens

Light mode (the only mode):

Distribution target: roughly 70% oat ground / 20% cream surface / 7% sage / 3% terracotta. No pure white. No blue anywhere. No indigo, violet, gradient-blob heroes, glassmorphism, frosted panels, neon glows, or dark-mode tech surfaces.

Typography

• Headings: Fraunces at low optical softness (SOFT 40, WONK 0), weight 500–600, tracking −0.01em, sentence case, never all-caps. Numerals inside headings are set in Work Sans tabular figures so hours and grams align.
• Body: Work Sans 400/500 at generous size with 1.65 line-height.
• Labels: Work Sans 600 at 12px with 0.08em tracking in muted #8C8271.
• Scale (1.25 modular): display 56px mobile / 88px desktop; section head 34/52; card title 24/28; body 17/17; label 13/13; metric numeral 40/64 (tabular).
• Forbidden: Inter, Roboto, Arial, Helvetica, Poppins, system-ui, and any geometric display face for headings.

Shape language

Soft, continuous, product-like. Radii are large and consistent: 28px on cards, 999px on pills and buttons, 20px on inputs. No sharp corners anywhere except the 1px hairline rules that separate data rows. Charts are filled organic arcs and rounded bars with 12px end-caps — never thin technical strokes. Empty states are a single soft blob in pale sage or pale ochre with a small hand-drawn-feeling line icon inside. Every control has a visible resting shape, a 2px sage focus ring, and a soft 0 2px 0 rgba(38,35,31,0.06) shadow — no hover-lift, no glass.

Layout

Single-column, reading-measure layout with a persistent left rail on desktop (240px) and a bottom bar on mobile. The rail holds the four ritual anchors — Today, Move, Nourish, Rest — plus History, each as a 44px rounded row with a soft icon, and it shows the current day's completion as a small filled arc. Content is a 720px column at 1280px, full-width with 20px gutters at 375px. Sections are separated by full-width 1px hairlines in #E3DACB rather than cards floating in space. Entry forms use aligned label-above-field pairs in one column, with the primary "Save entry" pill pinned at the bottom of the form. Overview pages use a warm stacked sequence — today's summary arc, then the last seven days as rounded bars, then a plain list of past entries with date, value, and a small terracotta dot on today's row. History is one continuous reverse-chronological ledger with month rules and a sticky month label.

Imagery

Product-in-real-life and material photography, softly lit, never stock gym imagery and never stock people. A single hero still life: a ceramic cup, a linen-folded surface, a worn notebook, an apple on an oak table, shot at a low warm angle with morning light and long soft shadows. Supporting imagery is close-up texture — linen weave, oat ceramic glaze, the grain of a wooden spoon — used as full-bleed 8px-radius bands between sections. Charts are the other imagery: rounded sage and ochre arcs and bars that read as objects, with hand-drawn-feeling line icons (a shoe, a cup, a crescent moon) at 28px, 2px stroke, rounded caps.

7. Signature Design Concept

The day arc, kept gently.

The public entry is a full-bleed warm-oat canvas split unevenly. On the left, flush-left in a 520px column, sits an oversized Fraunces headline stacked across three lines — Your day, / kept / gently. — with a 60px-wide terracotta rule above it and a single sage pill call to action beneath it. On the right, edge-to-edge to the viewport edge, a single large warm photograph of a morning table still life, cropped so the ceramic cup sits on the vertical third line; it bleeds off the right and bottom edges and is masked with a 32px top-left radius only. Overlapping the photo's inner edge by 40px sits one cream card, rotated −2deg, showing today's three metrics as tabular numerals — Move 34 min, Nourish 1,840 kcal, Rest 7h 20m — with pale sage and pale ochre arcs drawn behind each number. These numerals are illustrative of the product's shape, not the visitor's own data.

The signature move is the day arc: a single rounded sage arc that fills clockwise as the day's logging completes, repeated at three scales — 28px in the nav rail, 72px on Today, 180px on History as a month wheel. It is the one motif that carries from the anonymous entry through every tracking destination, and it is the product's whole idea in one shape: a day, filling quietly.

Supporting signature moves: metric numerals as ornament — every headline figure set in Work Sans tabular figures at 40/64px with a 1px ochre underline sitting 8px below the baseline, so numbers read as objects rather than dashboard text; the rotated −2deg cream summary card with a 1px #E3DACB hairline and no shadow lift, the one element that breaks the grid, on every page; the ritual nav rail of four 44px rounded rows (Today, Move, Nourish, Rest), each carrying its own muted tone — sage, ochre, terracotta, slate — so the navigation itself is the colour code, with the active row expanding to reveal a 7-day mini bar strip; and the in-place save confirmation, where the full-width "Save entry" sage pill's label changes to a past-tense confirmation ("Logged 7h 20m") with the day arc nudging forward 3px — a state change with no toast, no modal, no confetti.

No centred headline, no gradient, no blue button. No streak shaming, no red warning states, no calorie deficits framed as failure, no gamified badges or confetti.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject: the morning table still life — ceramic cup, linen-folded surface, worn notebook, apple on oak — with the rotated cream summary card overlapping its inner edge.
• Input → transformation → outcome thesis: on load, the day's completion arc draws from 0 to its value over 700ms with cubic-bezier(0.22, 0.61, 0.36, 1), and the current metric numeral counts up once. The visitor's arrival is the input; the arc filling is the transformation; the outcome is a page that has quietly shown what a kept day looks like, with the sage pill call to action waiting beneath the headline.
• Motion vocabulary: breathing, slow easing. One purposeful motion per screen. Section changes fade content in at 240ms with a 12px rise, no stagger chains. Buttons compress to 0.98 on press and return over 140ms. Charts animate only when their data changes. No parallax, no bounce, no looping ambient motion.
• Composed first frame: the warm-oat canvas, the three-line Fraunces headline, the 60px terracotta rule, the sage pill, the photograph bleeding off the right and bottom edges, and the rotated cream card — with the day arc at 0 and the numerals at their resting values, ready to draw and count once.
• Reduced-motion state: with prefers-reduced-motion, arcs and numerals render at their final value immediately and transitions become instant. The layout is unchanged and fully usable.

9. Non-Functional Requirements

• NFR-1 — Durable personal records. The user's exercise, food and drink, and sleep entries must persist across sessions and remain bound to the correct person. Provenance: required_inference, from the accepted need to review records over months. Rationale: without durability the review journeys are meaningless.
• NFR-2 — Private ownership of records. Each entry belongs to the single user who created it, and no other person can read or write it. Provenance: explicit (personal use) plus required_inference. Rationale: the product is for one person's own body data.
• NFR-3 — No differentiated permissions. Because there is exactly one human actor and no shared product state, the product defines no roles, role-based visibility, or permission controls. Provenance: required_inference from the closed single-persona catalog.
• NFR-4 — Readable text and controls at every viewport. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit. No other element covers any part of them. Provenance: explicit creative direction. Rationale: the direction's imagery may bleed and overlap, but readable content must not.
• NFR-5 — Accessible contrast and focus. White text on sage #3E5C4B passes contrast; ink #26231F on oat #F4EFE6 and cream #FBF7F0 passes contrast. Every control has a visible 2px sage focus ring. Provenance: explicit creative direction.
• NFR-6 — Reduced-motion support. With prefers-reduced-motion, arcs and numerals render at final value immediately and transitions become instant. Provenance: explicit creative direction.

• NFR-7 — No blue, no pure white. The palette contains no blue, indigo, or violet accent and no pure-white ground. Provenance: explicit creative direction.
• NFR-8 — Non-judgmental presentation. No streak shaming, red warning states, calorie deficits framed as failure, or gamified badges and confetti. Provenance: explicit creative direction.

10. Tech Stack

• Frontend: React, single-page application with client-side routing across the ten destinations. [Default — not specified by user]
• Backend: Python with FastAPI, serving the application's own API for accounts and for exercise, nutrition, and sleep entries. [Default — not specified by user]
• Storage: A relational database for durable, user-owned records — accounts, exercise entries, nutrition entries, and sleep entries. [Default — not specified by user]
• Containerization: Docker with docker-compose, running the frontend and the backend as the project's runnable services. [Default — not specified by user]
• Kubernetes: Not required. The product is a single-user personal application and its deployment does not call for orchestration. [Default — not specified by user]

No source-specified technology choices were given by the user; the above are labeled defaults and do not alter product behavior.

11. Assumptions and Constraints

• Constraint (explicit): The app or software is for personal use. It is built for the requester's own tracking, not for other people's accounts, teams, or public sharing.
• Assumption: The single user is the only human actor, and no second person ever reads or writes their records. This follows from the explicit personal-use constraint and the closed single-persona catalog.
• Assumption: The application owns identity because the accepted journeys require durable, privately owned, resumable records bound to the correct person. This is a required_inference, not a source-stated feature.
• Assumption: Login and Sign Up are anonymously reachable, because a protected destination cannot own the interaction that grants access to itself.
• Assumption: The tracking destinations require an established identity, because each reads or writes durable personal records.
• Assumption: No future-horizon requirements were stated. Nothing in this document is deferred.
• Assumption: No provider-owned, external-destination, or headless-only delivery was stated or is required.
• Assumption: The creative direction's illustrative hero numerals (Move 34 min, Nourish 1,840 kcal, Rest 7h 20m) are examples of the product's shape on the anonymous Landing surface, not the visitor's own data.

12. Glossary

• Day arc — the single rounded sage arc that fills clockwise as the day's logging completes; repeated at 28px in the nav rail, 72px on Today, and 180px on History as a month wheel.
• Exercise entry — one recorded exercise activity for a day: date, activity, duration, and an optional note.
• History — the single reverse-chronological ledger of all recorded exercise, nutrition, and sleep entries, with month rules and a sticky month label.
• Month wheel — the 180px day arc on History, showing a month's logging at a larger scale.
• Nutrition entry — one recorded item of food or drink for a day: date, item, kind (food or drink), amount, and an optional note.
• Personal Health Tracker — the single intended user of mellow-hey, and the only human actor in the product.
• Ritual anchors — the four navigation rows Today, Move, Nourish, Rest, each carrying its own muted tone, plus History.
• Sleep entry — one recorded sleep for a day: date, bedtime, wake time, duration, and an optional note.
• Tracking destination — any of Exercise, Exercise Entry, Nutrition, Nutrition Entry, Sleep, Sleep Entry, or History; each requires an established identity.