System Requirements Document for marine-lime

1. Introduction

marine-lime is a household daily-management board. Its current, confirmed purpose is 物品管理 — keeping track of the things a family owns, specifically 药品 (medicines) and 食物 (food). The board exists so that a household can answer three questions at a glance: 家里有什么 (what do we have), 有多少 (how much), and 放哪里 / 什么时候过期 (where is it, and when does it expire).

The product intent is calm reassurance rather than operational efficiency. A family-run inventory is kept accurate by one person and used by everyone else; the board must therefore be legible from across a kitchen, honest about quantities and dates, and warm enough to feel like a well-kept pantry rather than a warehouse terminal. The audience is a household — a 家庭物品管理者 who registers and maintains the shared record, and 家庭成员 who consult it when taking something out or reminding someone to restock.

The board's scope is deliberately narrow at this stage: it covers household item records (name, quantity, storage location, expiry) for medicines and food. It does not currently cover chore division, shopping lists, scheduling, or expense tracking.

2. System Overview

marine-lime is delivered as a first-party web application with custom UI and application-owned identity. Two accepted human personas use it: the 家庭物品管理者, who establishes the household's shared item record and keeps it accurate, and 家庭成员, who shares that record and consults it. Both reach the board through an anonymous public entry, then through application-owned sign-up (first use) and login (returning use). Once inside, the shared item list is visible to both personas; registering, updating, and removing items is the manager's responsibility.

Current accepted behavior:

• A public entry surface introduces the household board and its current medicine-and-food item-management purpose, and leads into the item-management flow.
• A first-use self-service registration establishes the manager's application identity.
• A returning login verifies both the manager and family members.
• A shared item list shows household medicines and food with stock overview, storage location, and expiry, and opens into a single item's detail.
• A focused entry surface registers a new medicine or food item with its name, quantity, storage location, and expiry.
• An item detail surface shows the complete record of one item and carries the manager's update and remove actions.

Narrow exclusions: chore division, shopping lists, scheduling, and expense tracking are not current scope. The board is not an enterprise inventory system, and it is not a medical or dietary advisory tool.

2a. Product Interpretation and Delivery Boundary

The board is a first-party application: the household's item records live in the application, and the application owns the identity that keeps those records bound to the right household and the right person. Because a shared household record must persist between visits and remain attributable to the person who maintains it, identity is established once by the manager through self-service registration and verified on return through login. The public entry surface is anonymous and carries no household data; the shared item list, the new-item entry, and the item detail are protected and become available only after identity is established.

Access is not differentiated beyond what the accepted household model requires: the shared item list is visible to both the manager and family members, while registering, updating, and removing items belongs to the manager. No other permission tiers, roles, or administrative surfaces are part of the current product.

Everything described in this document is current. Chore division, shopping lists, scheduling, and expense tracking remain outside the current horizon and are not built, surfaced, or implied by any page or flow here.

2b. Source Content Inventory

Not applicable — no reference directive in this project declares content_source authority.

2c. Page Content and Component Coverage

Landing

• Information / state: Anonymous public entry. Introduces the household daily-management board and states its current purpose — managing household items such as medicines and food. Presents the three questions the board answers: 家里有什么 / 有多少 / 放哪里. No household data is shown; the illustrative rows are presentation of the board's own purpose, not live records.
• Primary action: 开始整理 — leads into the item-management flow (registration for a first-time manager, login for a returning household member).
• Supporting actions: Navigate to Sign Up; navigate to Login.
• Domain entities: None persisted. The board's own concept of an item (name, category, quantity, location, expiry) is presented illustratively.
• Component responsibilities: Full-bleed colour-block band holding the three oversized stacked words; warm still-life photograph of a labelled pantry shelf; paper-white card listing three illustrative item rows in tabular numerals; solid teal pill CTA pinned beneath the card; persistent left rail (家庭 / 物品清单 / 新增物品) on desktop, bottom tab bar at 375px.
• States: Loading — static content, no data fetch. Empty — not applicable. Success — page renders with band, photograph, card, and CTA. Error — not applicable. Recovery — not applicable.

Sign Up

• Information / state: Anonymous first-use surface for the 家庭物品管理者. Explains that registering creates the household's shared item record and the identity that maintains it.
• Primary action: Submit registration to establish the manager's application identity.
• Supporting actions: Navigate to Login for an already-registered household member.
• Domain entities: Application identity for the manager (credential and identifying fields as required to establish and later verify the identity).
• Component responsibilities: Single centred column capped at 640px on the cream field with a full-bleed colour-block band above it; labelled input fields with 10px radii; primary submit control in teal; inline field-level validation messaging.
• States: Loading — submit control shows in-progress state while the identity is being established. Empty — pristine form with all fields blank. Success — identity established; the manager continues into the item-management flow. Error — invalid or incomplete input, or an identity that cannot be established; the form retains entered values and states what must be corrected. Recovery — the manager corrects the indicated fields and resubmits, or switches to Login if an identity already exists.

Login

• Information / state: Anonymous returning surface shared by the 家庭物品管理者 and 家庭成员. Explains that signing in returns the household to its shared item record.
• Primary action: Submit credentials to verify identity and enter the board.
• Supporting actions: Navigate to Sign Up for a household that has not yet registered.
• Domain entities: Application identity (manager or family member).
• Component responsibilities: Single centred column capped at 640px on the cream field with a full-bleed colour-block band above it; credential inputs; primary submit control in teal; inline error region.
• States: Loading — submit control shows in-progress state during verification. Empty — pristine form. Success — identity verified; the household member lands on the shared item list. Error — credentials do not verify; the form retains the entered identifier and states the failure without revealing which part was wrong. Recovery — retry with corrected credentials, or navigate to Sign Up.

物品清单

• Information / state: Protected shared view of the household's medicines and food. Shows each item's name, category, quantity, storage location, and expiry, with a stock overview and expiry urgency. Visible to both the 家庭物品管理者 and 家庭成员.
• Primary action: Open a single item to see its full record (物品详情).
• Supporting actions: For the manager — navigate to 新增物品 to register a new item. Filter or narrow the list by category (食物 / 药品 / 日用) using the pill-shaped category chips.
• Domain entities: Household item (name, category, quantity, unit, storage location, expiry date), household item collection.
• Component responsibilities: Ruled, printed-inventory list on desktop with true numeric columns (name, category chip, quantity, location, expiry) in tabular figures; stacked ruled panels on mobile, each keeping label/value pairs in a two-column mini-grid; 4px teal left-edge bar marking the active category; category chips as a real labelling system (teal for 食物, mustard for 药品, walnut for 日用); tomato hairline under an item name that grows as expiry approaches, with the day-count numeral counting up on open; persistent left rail on desktop collapsing to a bottom tab bar at 375px.
• States: Loading — list region shows a restrained crossfade-and-rise as panels enter. Empty — no items registered yet; the list states that the household record is empty and, for the manager, points to 新增物品 as the next step. Success — items render in the ruled list with aligned numerals and expiry urgency. Error — the shared record cannot be retrieved; the list states the failure and offers a retry. Recovery — retry the retrieval; the previously loaded view is not silently replaced with stale or partial data.

新增物品

• Information / state: Protected focused entry surface for the 家庭物品管理者 to register a medicine or food item. Collects the item's name, quantity, storage location, and expiry.
• Primary action: Save the item into the household's shared record.
• Supporting actions: Cancel and return to 物品清单 without saving.
• Domain entities: Household item (name, category, quantity, unit, storage location, expiry date).
• Component responsibilities: Single focused form column; labelled inputs with 10px radii; category selection using the same chip labelling system as the list; primary save control in teal; inline field-level validation; clear indication of which fields are required.
• States: Loading — save control shows in-progress state while the item is written. Empty — pristine form with all fields blank. Success — the item is registered and appears in the shared item list; the manager continues to the list or registers another item. Error — required fields missing or invalid (for example an unparseable quantity or expiry); the form retains entered values and states what must be corrected. Recovery — correct the indicated fields and save again, or cancel back to the list.

物品详情

• Information / state: Protected view of one household item's complete record — name, category, quantity, storage location, and expiry, with the day-count to expiry. Visible to both personas; the manager additionally sees update and remove controls.
• Primary action: For the manager — update the item's recorded values, or remove the item from the household record.
• Supporting actions: Return to 物品清单.
• Domain entities: Household item (name, category, quantity, unit, storage location, expiry date).
• Component responsibilities: Detail header carrying the category colour as a left-edge bar; label/value pairs aligned in a two-column mini-grid; quantity and day-count numerals in tabular Karla 700 with a count-up on open; tomato reserved exclusively for expiry urgency and the destructive 移除 action; update controls for the manager; a confirmation step before removal.
• States: Loading — detail panels crossfade-and-rise as they enter. Empty — not applicable; a detail view always addresses one existing item. Success — the complete record renders; an update or removal completes and the household record reflects it. Error — the item cannot be retrieved, or an update/removal fails; the view states the failure and preserves the last known values. Recovery — retry the retrieval or the failed operation; after a successful removal the manager returns to 物品清单, which no longer lists the item.

3. Functional Requirements

FR-1 — Household daily-management board As a household, I should have a daily-management board for the home, so that household information has one place to live.

• Provenance: explicit. Lifecycle: initiator — the household (represented by the 家庭物品管理者); observable result — the board exists and is reachable; continuation — the board's current scope is item management.
• Acceptance: The board is delivered as a first-party application with a public entry surface and protected household surfaces.

FR-2 — Current focus on household item management As a household, I should have the board focused on household item management, so that the board's purpose is unambiguous.

• Provenance: explicit. Lifecycle: initiator — the household; observable result — the board presents item management as its current purpose; continuation — item management is the only current scope.
• Acceptance: The board's public entry and protected surfaces present item management as the current purpose; chore division, shopping lists, scheduling, and expense tracking are absent.

FR-3 — Record and view household item information As a 家庭物品管理者, I should record and view information about the items in my home — such as name, quantity, storage location, and expiry — so that I know what we have, how much, where it is, and when it expires.

• Provenance: explicit. Lifecycle: initiator — the 家庭物品管理者; input — item name, quantity, storage location, expiry; observable result — the item appears in the household's shared record with those values; failure/recovery — invalid or incomplete values are rejected with the offending fields identified and the entered values retained; continuation — the manager can open the item again and update it.
• Acceptance: A registered item's name, quantity, storage location, and expiry are all recorded and are all visible when the item is viewed.

FR-4 — Medicines and food as the item categories in use As a 家庭物品管理者, I should be able to record items such as medicines and food, so that the board reflects what a household actually keeps.

• Provenance: explicit. Lifecycle: initiator — the 家庭物品管理者; input — the item's category alongside its other values; observable result — medicines and food are distinguishable in the shared record; continuation — the category is visible in the list and on the item's detail.
• Acceptance: An item can be recorded as a medicine or as food, and its category is visible wherever the item is listed or viewed.

FR-5 — First-use self-service registration As a 家庭物品管理者, I should be able to register an application identity myself on first use, so that the household's shared item record has a durable owner.

• Provenance: required_inference. Lifecycle: initiator — the 家庭物品管理者, anonymously on the Sign Up surface; input — the identifying and credential fields required to establish the identity; observable result — the identity is established and the manager enters the item-management flow; failure/recovery — invalid or incomplete input, or an identity that cannot be established, is reported with the entered values retained and the manager able to correct and resubmit or switch to Login; continuation — the manager registers the household's first items.
• Acceptance: A first-time manager can establish an application identity without any prior account, invitation, or provisioning step, and the identity persists for later verification.

FR-6 — Returning login verification As a 家庭物品管理者 or 家庭成员, I should be able to sign in when I return, so that I can reach the household's shared item record.

• Provenance: required_inference. Lifecycle: initiator — the returning manager or family member, anonymously on the Login surface; input — credentials; observable result — identity is verified and the person lands on the shared item list; failure/recovery — credentials that do not verify are reported without revealing which part was wrong, the entered identifier is retained, and the person can retry or navigate to Sign Up; continuation — the person views the shared list.
• Acceptance: Both the manager and a family member can verify their identity through the same login entry and reach the shared item list.

FR-7 — Shared list visibility and manager-only maintenance As a 家庭成员, I should be able to view the household's shared item list, and as a 家庭物品管理者, I should be able to register, update, and remove items, so that everyone can see what the household has while one person keeps it accurate.

• Provenance: required_inference. Lifecycle: initiator — the 家庭成员 viewing, or the 家庭物品管理者 maintaining; observable result — the shared list is visible to both personas, while registering, updating, and removing are available to the manager; failure/recovery — an attempt to maintain the record without the manager's identity does not change the record; continuation — the shared list reflects the manager's changes for both personas.
• Acceptance: The shared item list is reachable by both personas after login; registering, updating, and removing items are available only to the 家庭物品管理者.

FR-8 — Shared item list with stock overview, location, and expiry As a 家庭成员, I should be able to see the household's medicines and food with their stock, storage location, and expiry, so that I can take what I need or remind someone to restock.

• Provenance: required_inference. Lifecycle: initiator — the 家庭成员 or 家庭物品管理者 opening 物品清单; observable result — each item's name, category, quantity, storage location, and expiry are visible, with expiry urgency indicated; failure/recovery — if the shared record cannot be retrieved, the list states the failure and offers a retry rather than showing stale or partial data; continuation — the person opens a single item for its full record.
• Acceptance: The list shows every registered household item with its quantity, storage location, and expiry, and expiry urgency is visually distinguishable.

FR-9 — Register a new medicine or food item As a 家庭物品管理者, I should be able to register a new medicine or food item with its name, quantity, storage location, and expiry, so that the household record stays complete.

• Provenance: required_inference. Lifecycle: initiator — the 家庭物品管理者 on 新增物品; input — name, category, quantity, storage location, expiry; observable result — the item is written into the shared record and appears in 物品清单; failure/recovery — missing or invalid required values are reported with the entered values retained and the manager able to correct and save again or cancel; continuation — the manager returns to the list or registers another item.
• Acceptance: A newly registered item appears in the shared list with all four recorded values.

FR-10 — View a single item's complete record As a 家庭成员 or 家庭物品管理者, I should be able to open one item and see its complete record, so that I can confirm exactly what it is, how much remains, where it is kept, and when it expires.

• Provenance: required_inference. Lifecycle: initiator — either persona selecting an item from 物品清单; observable result — the item's name, category, quantity, storage location, and expiry render together, with the day-count to expiry; failure/recovery — if the item cannot be retrieved, the view states the failure and offers a retry; continuation — the person returns to the list, or the manager updates or removes the item.
• Acceptance: The detail view shows all recorded values for exactly one item and offers a return to the list.

FR-11 — Update a registered item As a 家庭物品管理者, I should be able to update a registered item's values, so that the household record stays truthful as quantities change and items are moved.

• Provenance: required_inference. Lifecycle: initiator — the 家庭物品管理者 on 物品详情; input — corrected values; observable result — the shared record reflects the update and the list shows the new values; failure/recovery — an invalid value or a failed write is reported, the last known values are preserved, and the manager can retry; continuation — the manager returns to the list.
• Acceptance: An updated value is visible on the item's detail and in the shared list.

FR-12 — Remove an item from the household record As a 家庭物品管理者, I should be able to remove an item from the household record, so that used-up or discarded items stop appearing as available.

• Provenance: required_inference. Lifecycle: initiator — the 家庭物品管理者 on 物品详情; decision — confirmation before the removal takes effect; observable result — the item no longer appears in 物品清单; failure/recovery — a failed removal is reported and the item remains in the record; continuation — the manager returns to the list.
• Acceptance: After a confirmed removal, the item is absent from the shared list and its detail is no longer reachable.

4. User Personas

家庭物品管理者 (Household Item Manager)

Product context. The manager is the person in the household who takes responsibility for the shared record — the one who notices that the cold medicine is down to two boxes, that the rice moved to the lower shelf, that something in the bathroom cabinet is about to expire. They are not an operations professional; they are doing this in the margins of a normal day, often standing in front of the shelf with the item in hand.

Primary goal. 家里东西一目了然 — to be able to say, without hunting, what the household has, how much of it, where it is kept, and when it expires, so that nothing is quietly wasted behind a box of tea and nothing gets bought twice.

Distinct accepted responsibilities. The manager is the only persona who establishes the household's application identity on first use (FR-5), and the only persona who registers new items (FR-9), updates recorded values (FR-11), and removes items from the record (FR-12). They also view the shared list and open individual items, exactly as family members do.

Relevant inputs and decisions. Item name, category (medicine or food), quantity, storage location, and expiry — entered when registering and corrected when updating. The manager decides when a value has drifted from reality, and decides when an item should leave the record entirely, confirming that removal before it takes effect.

Interactions with other accepted participants. The manager's work is what the 家庭成员 sees. Every registration, update, and removal the manager makes is immediately the household's shared truth; the manager's accuracy is the family member's ability to trust the board.

Observable success. A newly registered item appears in the shared list with all four values; an updated value is visible on the detail and in the list; a confirmed removal makes the item disappear from the list. The manager can return later, sign in, and find the record exactly as they left it.

家庭成员 (Household Member)

Product context. The family member lives with the manager and shares the household's things. They are the one standing at the cabinet wondering whether there is another box of plasters, or whether the milk in the fridge is still good. They did not build the record and do not maintain it; they depend on it.

Primary goal. To check, at the moment of need, what the household has, how much remains, where it is kept, and when it expires — so they can take what they need or remind someone to restock, without asking around the house.

Distinct accepted responsibilities. The family member views the shared item list (FR-8) and opens a single item's complete record (FR-10). They do not register, update, or remove items; that maintenance belongs to the manager. Their distinct contribution is consumption and awareness — they are the reason the record needs to be accurate and the reason it needs to be readable at a glance.

Relevant inputs and decisions. The family member's input is a query, not a record: which item, and what they need to know about it. Their decision is whether to take the item, and whether to tell the manager that something is running low or nearing its expiry.

Interactions with other accepted participants. The family member signs in through the same login entry as the manager (FR-6) and reads the same shared list the manager maintains. When they notice a discrepancy — a quantity that no longer matches the shelf — the resolution is to tell the manager, who holds the update and removal responsibility.

Observable success. The family member signs in, sees the household's medicines and food with their quantities, locations, and expiry, opens the one item they care about, and gets a complete answer without asking anyone. Expiry urgency is visible enough that they can flag it before the item is wasted.

5. Core User Flows

Flow A — The manager establishes the household record (first use)

1. The 家庭物品管理者 arrives at Landing without an identity. The page states the board's purpose — household item management for medicines and food — and presents 开始整理.
2. The manager selects 开始整理 and is taken to Sign Up, since the household has no record yet.
3. On Sign Up, the manager enters the identifying and credential fields required to establish an application identity and submits.
4. The application establishes the identity. The manager is now inside the board and lands on 物品清单.
5. 物品清单 is empty, because no items have been registered. The list states that the household record is empty and points the manager to 新增物品.
6. The manager selects 新增物品 and lands on 新增物品.
7. On 新增物品, the manager enters the item's name, category (药品 or 食物), quantity, storage location, and expiry, then saves.
8. The item is written into the household's shared record. The manager returns to 物品清单, where the item now appears with its quantity, location, and expiry in aligned numeric columns.
9. The manager repeats steps 6–8 for each item they want in the record, then stops. The household record now exists and is bound to the manager's identity.

Failure and recovery: If registration input is invalid or the identity cannot be established at step 3, Sign Up reports what must be corrected, retains the entered values, and lets the manager resubmit — or switch to Login if an identity already exists. If a required item value is missing or invalid at step 7, 新增物品 reports the offending fields, retains everything already entered, and lets the manager correct and save again, or cancel back to 物品清单 without saving.

Continuation: The manager can leave and return later; Login verifies the identity and returns them to 物品清单 with the record intact.

Flow B — The manager keeps the record accurate (returning use)

1. The 家庭物品管理者 returns and goes to Login.
2. On Login, the manager submits their credentials.
3. The application verifies the identity and lands the manager on 物品清单, showing the household's medicines and food with their quantities, storage locations, and expiry.
4. The manager scans the list. Expiry urgency is visible as a tomato hairline under the item name, growing as the expiry date approaches, with the day-count numeral counting up as the list opens.
5. The manager selects an item whose values have drifted — a quantity that is now wrong, or a location the item has moved from — and opens 物品详情.
6. On 物品详情, the manager sees the item's complete record: name, category, quantity, storage location, and expiry, with the day-count to expiry.
7. The manager corrects the values and saves the update.
8. The shared record reflects the update. The manager returns to 物品清单, where the item now shows the corrected quantity and location.

Failure and recovery: If the credentials do not verify at step 2, Login reports the failure without revealing which part was wrong, retains the entered identifier, and lets the manager retry or navigate to Sign Up. If the shared record cannot be retrieved at step 3, 物品清单 states the failure and offers a retry rather than showing stale data. If the update fails at step 7, 物品详情 reports the failure, preserves the last known values, and lets the manager retry.

Continuation: The manager can open another item and repeat steps 5–8, or leave the board; the corrected record persists for the next visit.

Flow C — The manager removes an item that is gone

1. The 家庭物品管理者 is signed in and on 物品清单.
2. The manager selects an item that has been used up or discarded and opens 物品详情.
3. On 物品详情, the manager sees the item's complete record and chooses 移除.
4. The manager confirms the removal. Tomato is used here, and only here and for expiry urgency.
5. The item is removed from the household's shared record. The manager returns to 物品清单.
6. 物品清单 no longer lists the item, and its detail is no longer reachable.

Failure and recovery: If the removal fails at step 4, 物品详情 reports the failure and the item remains in the record; the manager can retry or return to the list. If the manager does not confirm, nothing changes.

Continuation: The manager continues maintaining the rest of the record, or leaves the board.

Flow D — A family member checks what the household has

1. The 家庭成员 returns and goes to Login — the same entry the manager uses.
2. On Login, the family member submits their credentials.
3. The application verifies the identity and lands the family member on 物品清单, showing the household's medicines and food with their quantities, storage locations, and expiry.
4. The family member scans the list for what they need. Category chips and left-edge colour bars let them separate 食物 from 药品 at a glance, and the aligned numeric columns let them read quantities and day-counts without hunting.
5. The family member selects the item they care about and opens 物品详情.
6. On 物品详情, the family member sees the item's complete record — what it is, how much remains, where it is kept, and when it expires — with the day-count to expiry counting up as the page opens.
7. The family member takes what they need, or notes that the item is running low or nearing expiry.
8. The family member returns to 物品清单, or leaves the board.

Failure and recovery: If the credentials do not verify at step 2, Login reports the failure without revealing which part was wrong, retains the entered identifier, and lets the family member retry or navigate to Sign Up. If the shared record cannot be retrieved at step 3, 物品清单 states the failure and offers a retry. If the item cannot be retrieved at step 5, 物品详情 states the failure and offers a retry.

Continuation: The family member does not change the record — registering, updating, and removing belong to the manager. When they notice a discrepancy between the board and the shelf, they tell the manager, who resolves it through Flow B or Flow C. The family member can return to 物品清单 and check another item at any time.

6. Visuals, Colors and Theme

Muse and headline. Charles & Ray Eames — order you can live inside. The board is a piece of storage furniture: modular, labelled, warm, and honest about what it holds. Colour is a labelling system, not decoration; the numbers are the ornament.

Mode. Light mode only.

Colour tokens (exact hex, by role).

Proportion. Roughly 60% cream ground, 25% paper surfaces, 10% teal, 5% tomato.

Typography.

• Headings: Fraunces, soft optical settings (SOFT 40, WONK 0), 600–700 for display, 500 for section heads, tight leading 0.98–1.05, slight negative tracking at the largest sizes. Chinese runs fall back to Noto Serif SC 600 so 物品清单 reads with the same editorial warmth.
• Body: Karla 400/500/700, 1.6 line-height, 0.01em tracking for prose.
• Numerals: all quantities, dates, and day-counts use Karla 700 with tabular figures, so the pantry column aligns like a printed inventory.
• Scale: 1.333 modular — 64 / 48 / 36 / 27 / 20 / 16 / 13. Hero display clamp(40px, 9vw, 104px); page h1 clamp(32px, 5vw, 56px); section head 27px; card title 20px; body 16px; label/caption 13px uppercase with 0.08em tracking.

Shape language. Organic-modern and modular: 14px radii on cards and panels, 10px on inputs and chips, fully pill-shaped filter chips and category tags. Soft offset shadows — 0 2px 0 rgba(43,39,33,0.06), 0 10px 24px -14px rgba(43,39,33,0.28) — reading as printed card stock rather than glass. Thin 1px rules in #E3DACB act as shelf edges; a 4px teal left-edge bar marks the active category. No gradient meshes, no frosted glass, no neon glow.

Layout. A gallery-like modular grid: 12 columns on desktop with a persistent left rail (家庭 / 物品清单 / 新增物品) as an Eames-style labelled drawer stack, collapsing to a bottom tab bar at 375px. The inventory page is a ruled table-like list on desktop — name, category chip, quantity, location, expiry — becoming stacked ruled panels on mobile, each panel keeping its label/value pairs aligned in a two-column mini-grid. Landing and auth pages use a single centred column capped at 640px on the cream field with a full-bleed colour-block band above it. Section transitions are horizontal rules, not cards floating in space.

Imagery. Warm photographed still lifes on plain cream or walnut grounds — a labelled medicine box, a stack of tins, a shelf with a single object lit from the side — treated as mid-century product photography with visible material honesty (paper, glass, tin, cardboard). Flat two-tone pictograms in teal and tomato for categories (药 / 食 / 日用), plus a hand-drawn accent rule or arrow. No 3D renders, no gradient blobs, no stock people, no illustration for its own sake.

Avoid. Pure white #FFFFFF grounds or pure black text; blue or indigo primary or accent anywhere; glassmorphism, frosted panels, gradient blobs, or soft multicolour gradients; a grid of identical hover-lift cards; rounded cartoon illustration or emoji as category icons; bouncy spring easing, confetti, or motion beyond one purposeful reveal and a numeral count-up; a centred hero headline with a subtitle and button underneath; tomato used for anything other than expiry urgency or destructive actions. The generic indigo/blue-on-white SaaS template is forbidden for this project.

7. Signature Design Concept

The shelf of labelled drawers.

Landing opens on a full-bleed horizontal band of three flat colour blocks — cream, teal, tomato — running edge to edge at roughly 38vh. Each block holds one oversized word stacked vertically in Fraunces: 家里 / 有什么 / 放哪里, set at clamp(40px, 9vw, 104px) so the type fills its block and the three blocks read as a shelf of labelled drawers rather than a headline. The band is the product's thesis rendered as furniture: the board's three questions, each in its own labelled compartment.

Beneath the band, flush-left rather than centred, a single warm photograph of a labelled pantry shelf bleeds off the right viewport edge. A paper-white card overlaps it, listing three illustrative rows in tabular Karla — 药品 · 感冒灵 · 2盒 · 浴室柜 · 剩 14 天 — so the visitor sees the board's actual shape before signing in. The CTA 开始整理 is a solid teal pill pinned under the card, not in the middle of the screen.

At 375px the band becomes three stacked colour rows with the type wrapping inside each block, and the photograph drops below the card. Every headline, label, number, and control stays entirely inside the viewport and its container at 375px, 768px, and 1280px; the photograph and the colour blocks may bleed and overlap freely, but they never cover readable text or a control.

The concept recomposes only accepted content — the board's purpose, its three questions, an illustrative item row, and the entry action. It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the three edge-to-edge flat colour blocks (cream / teal / tomato), each holding one oversized stacked Chinese word in Fraunces, with the warm pantry photograph and the overlapping paper-white item card beneath.
• Input → transformation → outcome thesis: as the page settles, the colour-block band and its caption separate by a gentle 8px parallax, so the band reads as a shelf and the caption as its label; the paper-white card rises 12px into place over the photograph in a 400–600ms crossfade-and-rise. The outcome is a composed first frame in which the board's three questions are legible from across a kitchen and the CTA sits pinned under the card, ready.
• Motion vocabulary: slow crossfade-and-rise (12px) on entering panels; gentle 8px parallax between the colour-block band and its caption; a count-up on quantity and day-count numerals when a detail page opens; a 4px teal rule sliding in from the left and a 1px lift on inventory-row hover — tactile, not bouncy.
• Composed first frame: the three colour blocks fill the top ~38vh edge to edge with 家里 / 有什么 / 放哪里 stacked inside them; the photograph bleeds off the right edge below; the paper-white card with three tabular rows overlaps the photograph; the teal 开始整理 pill sits under the card, flush-left.
• Reduced-motion state: under prefers-reduced-motion everything collapses to instant static state — no transform, no parallax, no counting. The band, photograph, card, and CTA render in their final positions, and the inventory list and detail views show their numerals at their final values.

9. Non-Functional Requirements

NFR-1 — Legibility at a glance. The board must be readable from across a kitchen: item names, quantities, locations, and expiry day-counts are set in tabular figures and aligned in true columns, with a type scale that keeps body text at 16px and labels at 13px. Provenance: explicit (the board is a household daily-management board used in the home). Rationale: the board's value depends on being read quickly and correctly by a family member standing at a shelf.

NFR-2 — Warm, non-clinical visual register. The interface uses the cream ground, ink-brown text, teal structural colour, and tomato signal colour defined in section 6, with no pure white grounds, no pure black text, and no blue or indigo primary or accent. Provenance: explicit (user design constraints and creative direction). Rationale: the board must feel like a well-kept pantry, not a warehouse terminal.

NFR-3 — Colour as a labelling system. Category colour is consistent across chips, list rules, and detail headers: teal for 食物, mustard for 药品, walnut for 日用. Tomato is reserved exclusively for expiry urgency and destructive actions. Provenance: explicit (creative direction). Rationale: colour carries meaning in this product; using tomato for anything else would make expiry urgency unreadable.

NFR-4 — Responsive integrity. 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. Imagery and decoration may be cropped, bled, rotated, overlapped, or cut as the direction asks, provided they cover no readable text or control. Provenance: explicit (creative direction). Rationale: the board is used on phones at the shelf and on larger screens in the kitchen.

NFR-5 — Reduced-motion usability. Under prefers-reduced-motion, all motion collapses to instant static state with no transform and no counting, and every item remains fully readable. Provenance: explicit (creative direction). Rationale: the board must remain usable for household members who have reduced motion enabled.

NFR-6 — Durable shared record. The household's item record persists between visits and remains bound to the household's established identity, so that a returning manager or family member finds the record as it was left. Provenance: required_inference. Rationale: the accepted journeys depend on returning to a shared record that has not been lost or detached from its owner.

NFR-7 — Honest failure reporting. When the shared record cannot be retrieved, or a registration, update, or removal fails, the surface states the failure and offers a retry rather than silently showing stale or partial data. Provenance: required_inference. Rationale: a household board that quietly shows wrong quantities or dates is worse than one that admits it cannot read the record.

NFR-8 — No adjacent capabilities. Chore division, shopping lists, scheduling, and expense tracking are not built, surfaced, or implied. Provenance: explicit (hard constraint). Rationale: the board's current scope is item management for medicines and food.

10. Tech Stack

• Frontend: React with a component-based UI, implementing the custom pages in section 2c. Provenance: basic_default — the source specifies custom UI but no framework.
• Backend: Python with FastAPI, serving the household item record and the application-owned identity endpoints. Provenance: basic_default — the source requires backend integration but names no framework.
• Storage: A relational database for household items (name, category, quantity, unit, storage location, expiry) and application identities. Provenance: basic_default — the source requires a durable shared record but names no store.
• Packaging and local run: Docker with docker-compose for the application and its database. Provenance: basic_default — not specified by the user.
• Deployment: Kubernetes is not required at the current scope; a single application service with its database is sufficient. Provenance: basic_default — not specified by the user.

All items in this section are [Default — not specified by user] except where the source establishes the capability itself (custom UI, backend integration, application-owned identity).

11. Assumptions and Constraints

Constraints (binding).

• The board's current scope is limited to item management — medicines and food. Chore division, shopping lists, scheduling, and expense tracking are not confirmed current scope and are not built. (explicit)
• The board is a first-party application with custom UI and application-owned identity. (from Planning Scope delivery shape)
• The visual register is fixed by the creative direction: cream ground, ink-brown text, teal structural colour, tomato reserved for expiry urgency and destructive actions, Fraunces headings with Noto Serif SC fallback, Karla body with tabular numerals. (explicit)
• The generic indigo/blue-on-white SaaS template is forbidden for this project. (explicit)

Assumptions (narrow, labeled).

• Assumption — household scale. The record serves a single household, not multiple households or an organisation. The accepted personas are one manager and family members of the same household. (required_inference)
• Assumption — one shared record per household. The manager's registration establishes the household's record; family members reach the same record through login. No multi-household switching is assumed. (required_inference)
• Assumption — item fields. The recorded values are name, category, quantity, storage location, and expiry, as stated in the accepted requirements. Units are recorded alongside quantity so that 2盒 and 500g are distinguishable. (required_inference)
• Assumption — category set. Medicines and food are the categories in current use. 日用 appears in the creative direction's labelling system as a category tint; it is available as a label but is not an accepted current requirement to record daily-goods items. (explicit for 药品/食物; creative direction for 日用)
• Assumption — identity fields. The specific identifying and credential fields for registration and login are not specified by the source; they are chosen to be sufficient to establish and later verify an identity. (required_inference)
• Assumption — no differentiated permissions beyond the accepted split. The shared list is visible to both personas; registering, updating, and removing belong to the manager. No further roles, tiers, or administrative surfaces are assumed. (required_inference)

12. Glossary

• 家庭日常管理看板 (household daily-management board): The product — a shared board for a household's daily information. Its current scope is item management.
• 物品管理 (item management): The board's current and only confirmed scope: recording and viewing the household's items.
• 物品 (item): A thing the household owns and tracks — currently medicines and food — described by name, category, quantity, storage location, and expiry.
• 药品 (medicine): An item category. Carries the mustard category tint in the labelling system.
• 食物 (food): An item category. Carries the teal category tint in the labelling system.
• 日用 (daily goods): A category tint (walnut) present in the creative direction's labelling system; not an accepted current requirement to record such items.
• 家庭物品管理者 (household item manager): The persona who establishes the household's application identity and registers, updates, and removes items.
• 家庭成员 (household member): The persona who shares the household and views the shared item list and individual item records.
• 物品清单 (item list): The protected shared list of the household's medicines and food, with stock overview, storage location, and expiry.
• 新增物品 (add item): The protected focused entry surface where the manager registers a new medicine or food item.
• 物品详情 (item detail): The protected view of one item's complete record, carrying the manager's update and remove actions.
• 存放位置 (storage location): Where an item is kept — for example 浴室柜 or the lower pantry shelf.
• 有效期 (expiry): The date by which an item should be used, expressed with a day-count to expiry.
• 过期 (expired / expiring): The expiry-urgency state, signalled by the tomato hairline and day-count.
• 移除 (remove): The manager's destructive action that takes an item out of the household record, confirmed before it takes effect.
• 开始整理 (start organising): The public entry's primary action, leading into the item-management flow.