System Requirements Document for mint-todo

1. Introduction

mint-todo is a simple todo application for personal tasks. It exists for one person managing their own list — capturing tasks as they come up, reviewing the list, marking items complete, and removing or adjusting tasks so the list stays accurate and trustworthy. There is no team, no sharing, and no shared workflow: the product's whole job is to let a single individual track and finish their own tasks.

The audience is that single individual — the Personal Task Owner — using the app in the small honest moments of everyday life: at a kitchen counter, at a workbench, on a phone in a coat pocket. The product should feel plain, sturdy and satisfying, like a good pen and a task list you actually finish.

2. System Overview

mint-todo is a first-party web application with custom UI and application-owned identity. It delivers:

• A focused New Task destination for capturing a new personal task into the todo list.
• A revisitable Tasks destination for viewing the personal task list and completing or removing tasks.

The durable state is the Personal Task Owner's own task list, bound to their identity so it can be resumed on return. Backend integration is required to persist tasks and identity.

Actors. The only active human actor is the Personal Task Owner. The application itself (identity and task persistence) is a system actor, not a persona.

Narrow exclusions. Scope is personal tasks only; there is no team or shared task workflow. No collaboration, assignment, commenting, sharing, or multi-user visibility is part of this product.

2a. Product Interpretation and Delivery Boundary

Current vs. future. Everything described in this document is current. No future-horizon requirements were accepted.

2b. Source Content Inventory

Not applicable — no reference directive with content_source was supplied.

2c. Page Content and Component Coverage

Sign Up

• Primary action: Submit enrollment details to create the account and establish identity.
• Supporting content: Link to Login for someone who already has an account.
• Domain entities: Owner identity (email/credential), created account record.
• Component responsibilities: Enrollment form fields; submit control; inline validation messaging; link to Login.
• States: Loading — submit control shows in-progress state while the account is created. Empty — pristine form. Success — identity established; the owner continues to Tasks (or New Task) with their list available. Error — invalid or already-used details shown inline against the offending field, form preserved for correction. Recovery — the owner corrects the field and resubmits; if they already have an account, the Login link is offered.

Login

• Primary action: Submit credentials to verify identity and resume the list.
• Supporting content: Link to Sign Up for someone without an account.
• Domain entities: Owner identity (email/credential), verified session.
• Component responsibilities: Credential fields; submit control; inline error messaging; link to Sign Up.
• States: Loading — submit control shows in-progress state while verification runs. Empty — pristine form. Success — identity verified; the owner lands on Tasks with their existing list loaded. Error — unrecognized credentials shown inline without revealing which part failed; form preserved. Recovery — the owner retries, or follows the Sign Up link if they have no account.

New Task

• Information/state: Focused capture destination for adding a new personal task to the todo list. Requires login. Presented as a ruled panel with a small uppercase section label pinned top-left.
• Primary action: Save the new task into the list.
• Supporting content: A path back to Tasks without saving.
• Domain entities: Task — task text, completion state (initially not complete), optional due date.
• Component responsibilities: Task text input; optional due-date input; save control; cancel/back control; inline validation messaging.
• States: Loading — save control shows in-progress state while the task is persisted. Empty — pristine capture form. Success — the task is added to the list and the owner continues to Tasks, where the new row appears stamped in from 96% scale. Error — a task with no text cannot be saved; the message appears inline and the entered text is preserved. Recovery — the owner supplies the missing text and saves again, or returns to Tasks without saving.

Tasks

• Information/state: The revisitable personal task list. Requires login. A single column of full-width ruled rows — checkbox on the left, task text, right-aligned uppercase 12px due badge — with a 2px ink rule beneath each row, reading like a page from a field notebook. On desktop the column sits in a 720px measure with a 280px sidebar of badge stamps (counts, streak, today) to its left.
• Primary action: Mark a task complete via its checkbox.
• Supporting actions: Remove a task; open New Task to add another; sign out.
• Domain entities: Task — task text, completion state, optional due date; list-level counts shown in the sidebar badges.
• Component responsibilities: Task row (checkbox, text, due badge, remove control); completion stamp (rotated −8deg mint DONE badge) and ink strike; sidebar badge stamps; New Task entry control; empty-state sprig drawing with the line "Nothing here. Enjoy it." and a single orange ADD A TASK button.
• States: Loading — the list area shows a loading state while tasks are fetched. Empty — the thick-line mint sprig drawing with "Nothing here. Enjoy it." in Oswald 500 and a single orange ADD A TASK button. Success — rows render; completing a task snaps the ink strike across the row in 140ms with a slight overshoot and fades in the rotated mint DONE stamp; removing a task slides the row out and collapses the gap in 200ms. Error — a failed completion or removal leaves the row in its prior state and surfaces a retryable message. Recovery — the owner retries the action; the list remains usable and consistent.

3. Functional Requirements

FR-1 — Create a simple todo project (todo app). (explicit) As a Personal Task Owner, I should have a simple todo application so that I can keep a list of my tasks.

• Trigger/input: The owner opens the application.
• Observable result: A working todo application is available with a Landing entry, identity access, task capture, and a task list.
• Access state: Landing is anonymous; task capture and the list require login.
• Failure/recovery: If the application cannot be reached, the owner retries by reloading.
• Continuation: The owner proceeds to enroll or log in and begin capturing tasks.

FR-2 — Personal tasks, single individual. (explicit) As a Personal Task Owner, I should use the app for my own personal tasks as a single individual so that my list reflects only my own work.

• Trigger/input: The owner uses the app.
• Observable result: The task list belongs to one individual; no team or shared workflow exists.
• Access state: Login required for the list.
• Failure/recovery: Not applicable — this is a scope constraint, not an operation.
• Continuation: The owner continues managing their own list.

FR-3 — Self-service enrollment before first use. (required_inference) As a Personal Task Owner, I should complete self-service enrollment before first use so that my personal task list is bound to me and can be resumed.

• Trigger/input: The owner chooses to start using the app from Landing and has no account.
• Observable result: An account is created and identity is established; the owner's list is available to them.
• Access state: Sign Up is anonymously reachable; the protected list remains unavailable until identity is established.
• Failure/recovery: Invalid or already-used details are shown inline against the offending field with the form preserved; the owner corrects and resubmits, or follows the Login link if they already have an account.
• Continuation: The owner continues to Tasks (or New Task) with their list available.

FR-4 — Returning verification to resume the durable list. (required_inference) As a Personal Task Owner, I should complete returning verification so that I can resume access to my durable personal task list.

• Trigger/input: The owner returns and submits their credentials on Login.
• Observable result: Identity is verified and the owner's existing task list loads.
• Access state: Login is anonymously reachable; the list becomes available only after verification.
• Failure/recovery: Unrecognized credentials are shown inline without revealing which part failed, with the form preserved; the owner retries or follows the Sign Up link.
• Continuation: The owner lands on Tasks with their existing list.

FR-5 — Capture a new personal task. (required_inference) As a Personal Task Owner, I should capture a new task into my list so that it is not forgotten.

• Trigger/input: The owner opens New Task and enters task text (and optionally a due date).
• Observable result: The task is added to the list in a not-complete state and appears as a new ruled row.
• Access state: Login required.
• Failure/recovery: A task with no text cannot be saved; the message appears inline and the entered text is preserved so the owner can supply the missing text and save again.
• Continuation: The owner continues to Tasks, where the new row appears stamped in from 96% scale.

FR-6 — Review the personal task list. (required_inference) As a Personal Task Owner, I should review my task list so that I know what is outstanding.

• Trigger/input: The owner opens Tasks.
• Observable result: The list renders as ruled rows with checkbox, task text, and right-aligned due badge, with sidebar badge stamps for counts, streak, and today.
• Access state: Login required.
• Failure/recovery: If the list cannot be fetched, a retryable message is shown and the list remains usable once the fetch succeeds.
• Continuation: The owner acts on a row or adds another task.

FR-7 — Complete a task. (required_inference) As a Personal Task Owner, I should mark a task complete so that my list stays accurate.

• Trigger/input: The owner toggles the checkbox on a task row.
• Observable result: The ink strike snaps across the row in 140ms with a slight overshoot and a rotated −8deg mint DONE stamp fades in over the row; the task's completion state is persisted.
• Access state: Login required.
• Failure/recovery: If the completion cannot be persisted, the row returns to its prior state and a retryable message is surfaced.
• Continuation: The owner continues reviewing or completing other tasks.

FR-8 — Remove a task. (required_inference) As a Personal Task Owner, I should remove a task so that my list stays trustworthy.

• Trigger/input: The owner uses the remove control on a task row.
• Observable result: The row slides out and the gap collapses in 200ms; the task is removed from the persisted list.
• Access state: Login required.
• Failure/recovery: If the removal cannot be persisted, the row remains and a retryable message is surfaced.
• Continuation: The owner continues reviewing the list.

FR-9 — Empty list state. (required_inference) As a Personal Task Owner, I should see a clear empty state when I have no tasks so that I know the list is genuinely empty rather than unloaded.

• Trigger/input: The owner opens Tasks with no tasks in the list.
• Observable result: A thick-line mint sprig drawing with the line "Nothing here. Enjoy it." in Oswald 500 and a single orange ADD A TASK button.
• Access state: Login required.
• Failure/recovery: Not applicable — this is a display state.
• Continuation: The owner uses ADD A TASK to open New Task.

4. User Personas

Personal Task Owner

Product context. A single individual managing their own personal tasks in a simple todo app. They are the only human actor in the product; there is no team, no sharing, and no shared workflow. They use the app in the small honest moments of everyday life — at a kitchen counter, at a workbench, on a phone in a coat pocket.

Primary goal. Keep their own tasks tracked and finished, with a list that stays accurate and trustworthy, without needing any team or shared workflow.

Distinct accepted responsibilities.

• Complete self-service enrollment before first use, so their list is bound to them.
• Complete returning verification to resume access to their durable personal task list.
• Capture tasks as they come up, through the focused New Task destination.
• Review their list on Tasks, reading ruled rows with checkbox, task text, and due badge.
• Mark items complete, seeing the ink strike and mint DONE stamp.
• Remove or adjust tasks so the list stays accurate and trustworthy.

Relevant inputs or decisions. Task text; optional due date; the decision to complete a task; the decision to remove a task; the decision to add another task; enrollment and credential details.

Interactions with other accepted participants. None — the Personal Task Owner is the only active human actor. The application itself persists identity and tasks on their behalf.

Observable success. Their own tasks are tracked and finished. The list reflects reality: completed tasks are visibly stamped DONE, removed tasks are gone, and the empty state reads "Nothing here. Enjoy it."

What makes this role's work different. There is no coordination, no assignment, and no shared visibility to reason about. Every decision in the product is the owner's own, about their own list, and the only correctness criterion is whether their personal list matches what they actually need to do.

5. Core User Flows

Flow 1 — First use: enroll and capture the first task

1. The Personal Task Owner opens mint-todo and lands on Landing (anonymous). They see the MINT TODO wordmark, a single line of body copy, and a cream card showing three task rows, one stamped DONE.
2. They choose the mint CTA and arrive at Sign Up (anonymous).
3. They enter their enrollment details and submit. The submit control shows an in-progress state while the account is created.
4. Observable result: identity is established and their personal task list is available to them.
5. Failure/recovery: if the details are invalid or already used, the message appears inline against the offending field with the form preserved; they correct it and resubmit, or follow the Login link if they already have an account.
6. Continuation: they arrive at Tasks, which is empty, showing the mint sprig drawing with "Nothing here. Enjoy it." and a single orange ADD A TASK button.
7. They use ADD A TASK to open New Task, enter the task text (and optionally a due date), and save.
8. Observable result: the task is added to the list in a not-complete state.
9. Failure/recovery: if they try to save with no task text, the message appears inline and their entered text is preserved; they supply the text and save again, or return to Tasks without saving.
10. Continuation: they continue to Tasks, where the new row appears stamped in from 96% scale.

Flow 2 — Returning: verify and resume the list

1. The Personal Task Owner returns to mint-todo and goes to Login (anonymous), either directly or from the Landing page.
2. They submit their credentials. The submit control shows an in-progress state while verification runs.
3. Observable result: identity is verified and their existing task list loads on Tasks.
4. Failure/recovery: if the credentials are unrecognized, the message appears inline without revealing which part failed and the form is preserved; they retry, or follow the Sign Up link if they have no account.
5. Continuation: they review their list and act on it.

Flow 3 — Complete a task

1. From Tasks, the Personal Task Owner reads the ruled rows — checkbox, task text, right-aligned due badge — and the sidebar badge stamps for counts, streak, and today.
2. They toggle the checkbox on a task.
3. Observable result: the ink strike snaps across the row in 140ms with a slight overshoot and a rotated −8deg mint DONE stamp fades in over the row; the completion state is persisted.
4. Failure/recovery: if the completion cannot be persisted, the row returns to its prior state and a retryable message is surfaced; they retry.
5. Continuation: they continue reviewing or completing other tasks.

Flow 4 — Remove a task

1. From Tasks, the Personal Task Owner decides a task no longer belongs on their list.
2. They use the remove control on that row.
3. Observable result: the row slides out and the gap collapses in 200ms; the task is removed from the persisted list.
4. Failure/recovery: if the removal cannot be persisted, the row remains and a retryable message is surfaced; they retry.
5. Continuation: they continue reviewing the list, which now reflects only what remains.

Flow 5 — Add another task to an existing list

1. From Tasks, the Personal Task Owner uses the New Task entry control and arrives at New Task.
2. They enter the task text (and optionally a due date) and save.
3. Observable result: the task is added to their existing list in a not-complete state.
4. Failure/recovery: if they try to save with no task text, the message appears inline and their entered text is preserved; they supply the text and save again, or return to Tasks without saving.
5. Continuation: they return to Tasks, where the new row appears stamped in from 96% scale alongside their existing tasks.

6. Visuals Colors and Theme

Muse: Aaron Draplin. Field-notes boldness for personal tasks. The emotional register is not "productivity SaaS" — it is plain, sturdy and satisfying, like a good pen and a task list you actually finish. Mint is the brand promise (a plant on the windowsill, a fresh start), so the visual language carries mint as a real material colour against kraft and black rather than a pastel accent on white.

Headline: plain talk, thick strokes, workwear colours, badge-like logo system — the confidence of a tool rather than the neutrality of a dashboard.

Colour tokens

Light mode (the only mode):

Nothing is pastel; every colour is a field-notes material. Blue and indigo are forbidden anywhere in the palette, including focus rings and links — focus rings and links use mint #2E6B45 or orange #E4572E.

Typography

• Headings: Alfa Slab One at 400 only, uppercase, tracking tightened to -0.01em, set in huge sizes so the slab serifs read as stamped metal. Headlines are short and declarative, never sentences.
• Body: Oswald 400/500/600 carries all body copy, labels and numerals — always uppercase for labels with +0.08em tracking, sentence case for reading copy at 16–18px with 1.6 line-height.
• Scale: 1.333 modular — 72/54/40/30/22/18/16, with display sizes clamped: hero clamp(44px, 9vw, 104px), section heads clamp(30px, 5vw, 54px), card titles 22px, body 17px, micro-labels 12px uppercase.

Shape language

Hard edges and thick borders. Cards are 2px ink-bordered rectangles with a 6px offset solid shadow in ink or mint — never blurred, never lifted. Corners are square except the checkbox, which is a 4px-radius square. Badges are circle-and-banner stamps with a 3px outline. Checked tasks get a diagonal ink strike drawn as a 2px rotated rule, not a text-decoration strikethrough.

Layout

Poster-like vertical sections separated by 2px ink rules that run the full viewport width. Each section is a ruled panel with a small uppercase section label in the top-left corner, like a form on a clipboard. The task list is a single column of full-width ruled rows with checkbox, task text, and a right-aligned due badge; on desktop the column sits in a 720px measure with a 280px sidebar of badge stamps (counts, streak, today) to its left. Everything aligns to an 8px baseline grid, and every control is at least 44px tall on touch.

Imagery

Thick-line vector marks only: a mint sprig, a checked box, a coffee cup, a wrench, a stamp ring. Halftone-dot texture at 6% opacity over the kraft ground. No photography, no 3D renders, no stock people. Iconography is 2px-stroke, 24px grid, all-caps label beneath when used in the sidebar badges.

7. Signature Design Concept

The landing page is a stamped field-notes cover.

The public entry is a full-bleed kraft paper field (#EFE6D4) with a 2px ink rule running edge to edge at the top. The dominant element is the wordmark MINT TODO set in Alfa Slab One, uppercase, clamp(44px, 9vw, 104px), left-aligned and allowed to span nearly the full viewport width on desktop, wrapping to two lines on mobile without ever clipping. The wordmark is a stamp: it sits inside a 3px ink-outlined rectangle with a 6px mint offset shadow — the same badge that repeats at the top of every authenticated screen as a small 28px mark.

Beneath the wordmark, a 2px ink rule, then a single line of Oswald body copy, then a mint-filled rectangular CTA with a 6px ink offset shadow. To the right on desktop (below on mobile) sits a cream card (#FBF6EA) showing three real-looking task rows with checkboxes, one already stamped DONE with a rotated mint stamp — the product's own list, shown as it actually looks.

There is no centred stack, no gradient blob, and no floating screenshot. The composition is a poster: rule, stamp, rule, line, button, evidence.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the MINT TODO wordmark stamp — Alfa Slab One, uppercase, inside a 3px ink-outlined rectangle with a 6px mint offset shadow, on the full-bleed kraft field.
• Input → transformation → outcome thesis: on load, the hero headline's ink rule draws left-to-right in 400ms; the wordmark stamp and the cream task-row card are already composed in place. The outcome is a fully readable poster — no element moves after the rule completes.
• Motion vocabulary: snap, stamp and collapse only. One purposeful entrance: the hero headline's ink rule draws left-to-right in 400ms on load. No parallax, no float, no bounce loops.
• Composed first frame: the kraft field with the top edge-to-edge 2px ink rule, the wordmark stamp left-aligned, the rule beneath it, the single Oswald body line, the mint CTA with its 6px ink offset shadow, and the cream three-row task card with one DONE stamp — all present and legible before any motion runs.
• Reduced-motion state: with prefers-reduced-motion, the ink rule is drawn at full width immediately and nothing animates. The page is a complete, usable static poster; the CTA and Login link remain fully visible and operable.

In-app motion (restrained, snap/stamp/collapse)

• Checkbox toggles snap the strike across the row in 140ms with a slight overshoot.
• New tasks stamp in from 96% scale with a 180ms ease-out.
• Deleting a task slides the row out and collapses the gap in 200ms.
• Completing a task stamps it: a rotated −8deg mint DONE badge fades in over the row while the ink strike snaps across the text in 140ms.
• Section transitions are full-width 2px ink rules with a small uppercase label pinned top-left, so scrolling the app feels like flipping pages of a ruled pad.
• With prefers-reduced-motion, all of the above resolve instantly to their end state; the list remains fully readable and every control remains operable.

9. Non-Functional Requirements

NFR-1 — Personal-scope integrity. (explicit) The product must not introduce team or shared task workflow. Scope is personal tasks only. Rationale: explicit hard constraint in the authoritative user evidence.

NFR-2 — Identity continuity. (required_inference) The Personal Task Owner's task list must remain bound to their identity and resumable across sessions. Rationale: the accepted journey requires returning verification to resume a durable personal task list.

NFR-3 — Readable text and controls at every viewport. (explicit, from creative direction) Headlines, wordmarks, labels, numbers, cards' text and controls must 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, and no other element may cover any part of them. Imagery, decoration and motion may be cropped, bled off an edge, rotated, overlapped or cut as the direction asks, as long as they cover no readable text or control. Rationale: explicit direction constraint.

NFR-4 — Reduced motion. (explicit, from creative direction) With prefers-reduced-motion, a usable static arrangement must be provided; motion resolves instantly to its end state and every control remains operable. Rationale: explicit direction constraint.

NFR-5 — Touch target size. (explicit, from creative direction) Every control is at least 44px tall on touch. Rationale: explicit direction constraint.

NFR-6 — Palette discipline. (explicit, from creative direction) Blue and indigo must not appear anywhere in the palette, including focus rings and links; focus rings and links use mint #2E6B45 or orange #E4572E. The kraft #EFE6D4 field must cover the majority of every screen. Rationale: explicit direction constraint.

NFR-7 — Task persistence. (required_inference) Task creation, completion, and removal must be persisted so the list survives across sessions and devices. Rationale: the accepted journey requires a durable, resumable personal task list.

10. Tech Stack

• Frontend: React (web), custom UI. [Default — not specified by user]
• Backend: Python / FastAPI. [Default — not specified by user]
• Storage: A persistent datastore for owner identity and tasks. [Default — not specified by user]
• Packaging: Docker / docker-compose. [Default — not specified by user]

No source-specified technology choices were given; the above are labeled defaults. Kubernetes is not required by any accepted requirement.

11. Assumptions and Constraints

Constraints (binding):

• Scope is personal tasks only; no team or shared task workflow. (explicit)
• The product is a simple todo app. (explicit)
• The only active human actor is the Personal Task Owner. (from the closed persona catalog)
• The page inventory is exactly: Landing, Sign Up, Login, New Task, Tasks. (from the versioned page contract)
• Landing, Sign Up, and Login are anonymously reachable; New Task and Tasks require login. (from the versioned page contract)
• Identity is application-owned and established by self-service enrollment, then returning verification. (required_inference)
• The creative direction is authoritative for palette, typography, shape, layout, imagery, and motion.

Assumptions (narrow, labeled):

• [Assumption] The Personal Task Owner uses the app on both desktop and mobile; the layout is specified for 375px, 768px and 1280px.
• [Assumption] A task consists of task text, a completion state, and an optional due date; no other task fields were accepted.
• [Assumption] Identity is a single-owner account; no roles, permissions, or differentiated visibility exist, because there is only one owner of the list.
• [Assumption] Signing out returns the owner to an anonymous state; no separate sign-out destination was accepted, so the control lives on Tasks.

12. Glossary

• Personal Task Owner — The single individual who uses mint-todo to manage their own personal tasks. The only active human actor.
• Task — A single personal to-do item: task text, a completion state, and an optional due date.
• Task list — The Personal Task Owner's durable, identity-bound collection of tasks, shown on Tasks.
• Completion stamp — The rotated −8deg mint DONE badge that fades in over a row when a task is completed, paired with the ink strike.
• Ink strike — The diagonal 2px rotated rule drawn across a completed task's text, replacing a text-decoration strikethrough.
• Wordmark stamp — The MINT TODO mark in Alfa Slab One inside a 3px ink-outlined rectangle with a 6px mint offset shadow; large on Landing, 28px on authenticated screens.
• Kraft ground — The #EFE6D4 paper field that covers the majority of every screen.
• Badge stamp — A circle-and-banner stamp with a 3px outline, used in the desktop sidebar for counts, streak, and today.
• Self-service enrollment — The anonymous Sign Up interaction that establishes the owner's identity before first use.
• Returning verification — The anonymous Login interaction that re-establishes the owner's identity to resume their durable list.