System Requirements Document for autumn-simple

1. Introduction

autumn-simple is a single-page browser calculator. The product intent, taken directly from the authoritative requirement thread, is to create a simple single-page calculator design: one page, one arithmetic object, nothing else. The user asked for a design of a calculator, and the accepted scope is exactly that — a four-function calculator delivered as a single page.

The audience is anyone who needs four-function arithmetic in under five seconds: students, shoppers, cooks, engineers checking a figure. The tool is a utility object, not a product. It should feel like a well-made household object the visitor already knows how to use, not an application that wants to be noticed. The project name autumn-simple supplies a warm, restrained, seasonal register — paper, unbleached cotton, a single fallen-leaf accent — without becoming decorative.

This document specifies the calculator's behavior, its single page, its one accepted persona, its visual language, and its delivery boundary.

2. System Overview

autumn-simple is a client-side, single-page calculator. The visitor arrives at the page, sees a calculator object on a warm paper ground, enters numbers and operators, reads the running expression and the computed result, and clears the current calculation to begin a new one. There is no navigation bar, no footer columns, no marketing sections, and no additional pages.

Actors

• Calculator User — the single accepted active human persona. A person who wants to perform basic arithmetic quickly in the browser.
• Browser runtime — a non-persona system actor. It executes the arithmetic, holds the current calculation state for the life of the page, and dispatches keyboard input to the calculator.

Accepted behavior

• Entry into the calculator from the page root.
• Entry of digits and a decimal point to build an operand.
• Selection of one of four operators (÷, ×, −, +).
• Evaluation of the pending expression when equals is pressed.
• Display of a two-tier readout: a muted expression line above a large result numeral.
• Clearing the current calculation with AC or the Esc key.
• Sign change (±) and percent (%) on the current entry.
• Keyboard input as an alternative to pointer input.
• Tactile key feedback and an armed-operator state.

Ownership

All accepted behavior is owned by the application's single page. There is no provider-owned surface, no external destination, and no headless delivery. Arithmetic is computed in the browser; no server round-trip is required for any accepted capability.

Narrow exclusions

• No additional pages, navigation bars, footers, or any section that is not the calculator object and its hint strip.
• No history that survives a reload; history is cleared on reload.
• No memory keys, no scientific functions, no unit conversion, no graphing, no tape/history panel.
• No accounts, sign-in, or persisted user state.

2a. Product Interpretation and Delivery Boundary

Delivery. autumn-simple is delivered as a single first-party page rendered in the browser. The calculator object is the whole page. There is no separate backend service, no API, and no server-side computation: the arithmetic is performed by the browser runtime as the visitor interacts with the object. Nothing about the accepted behavior requires a network call, a database, or a background worker.

Access. The page is openly reachable. No identity is established, no sign-in is required, and no protected state exists. The visitor's calculation lives only in the page's memory for the duration of the visit; reloading the page clears it. Because no durable, actor-specific state, commitment, entitlement, or value transfer is created, application-owned identity is neither required nor introduced.

Current boundary. Everything specified in this document is current: the single page, the calculator object, the four functions, the two-tier readout, the keypad, the keyboard support, the hint strip, and the tactile feedback.

Future boundary. Nothing in the authoritative requirement thread asks for a future capability. No future section is created, because inventing one would add scope the user did not request.

2b. Source Content Inventory

Not applicable. No reference directive in this request declares a content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

The page contract is exact and contains one page. It is represented once below.

Landing

The single page of autumn-simple. It is the public entry surface and the calculator itself; there is no separate entry screen, no gate, and no second destination. The visitor arriving at the root lands directly on the calculator object.

Information and state

• Wordmark — AUTUMN · CALCULATOR, 18px, Jost 300–400, wide-tracked small caps. Sits above the object.
• Quiet copy line — Four functions, one page, nothing else. One line of body copy beneath the wordmark.
• Expression line — the running expression (for example 128 ÷ 4), right-aligned, muted (#8C857A), small. Empty on first load.
• Result numeral — the current value or computed result, right-aligned, Jost 300 with tabular figures, clamp(40px, 9vw, 72px), ink (#2A2723). Shows 0 on first load.
• Armed-operator state — the currently selected operator key fills with the accent (#C25A2E) for as long as it is armed, until the next number is entered.
• Hint strip — three hairline-separated hints at 12px caps with 0.14em tracking: keyboard support, clear with Esc, history cleared on reload.

Primary actions

• Press a digit key (0–9) to append to the current operand.
• Press the decimal key to begin or extend a fractional operand.
• Press an operator key (÷, ×, −, +) to arm that operator and commit the current operand.
• Press equals to evaluate the pending expression and display the result.
• Press AC to clear the current calculation and return the display to 0 with an empty expression line.
• Press ± to change the sign of the current entry.
• Press % to apply percent to the current entry.

Supporting actions

• Type digits, ., +, -, *, /, Enter, and Escape on a physical keyboard; these map to the same behavior as the corresponding keys.
• Press Esc to clear, equivalent to AC.

Domain entities

• Operand — the number currently being entered.
• Pending expression — the left operand, the armed operator, and the right operand, held in page memory.
• Result — the evaluated value shown in the result numeral.
• Calculation state — the whole in-memory state of the current calculation; discarded on reload.

Component responsibilities

• Calculator body — a single rounded object (28px radius) on the paper ground, 360px wide at 375px viewport, 420px at 768px, 460px at 1280px, vertically centred with generous breathing room above and below, carrying one low wide shadow (0 18px 40px rgba(42,39,35,0.08)).
• Display tray — 20px radius, holding the muted expression line above the large ink result numeral, right-aligned like an instrument readout.
• Keypad grid — four columns with 12px gutters, fixed order: AC ± % ÷ / 7 8 9 × / 4 5 6 − / 1 2 3 + / 0 spanning two columns, decimal, equals. Keys at 16px radius; the equals key is the single full capsule and the only saturated element on the page.
• Key — paper-light with a hairline warm-grey border, or a soft ink-dark block for digits; depresses 1px with a 90ms ease-out and returns.
• Hint strip — three hairline-ruled lines beneath the object.

States

• Loading — not applicable in a material sense; the page renders its object immediately. No spinner, no skeleton, no placeholder.
• Empty / first load — result numeral shows 0, expression line is empty, no operator is armed.
• Success — the displayed result matches the arithmetic the visitor intended; the expression line shows what was evaluated.
• Error / recovery — division by zero and any non-finite result display a clear non-numeric indication in the result numeral rather than a silent wrong number or a crash; the visitor recovers by pressing AC or Esc and beginning a new calculation. Malformed or incomplete input (for example an operator pressed with no operand, or equals pressed with no pending operator) is ignored or treated as a no-op rather than producing an error state. Repeated decimal points in one operand are ignored after the first.

3. Functional Requirements

Each requirement is a distinct story point with its provenance and observable acceptance.

FR-1 — Single-page delivery (explicit) As a Calculator User, I should reach the calculator on one page with no other pages, so that the tool is exactly as simple as it was asked to be.

• Lifecycle: the visitor arrives at the root and the calculator object is present. There is no second destination to navigate to.
• Observable acceptance: the entire product is one page; no navigation bar, footer columns, or marketing sections exist.
• Failure/recovery: not applicable; there is no navigation to fail.
• Continuation: the visitor proceeds directly to entering a calculation.

FR-2 — Digit entry (explicit) As a Calculator User, I should press digit keys 0–9 to build the number I want to calculate with.

• Trigger/input: a pointer press on a digit key, or the corresponding keyboard digit.
• Observable result: the digit appends to the current operand and the result numeral updates to show the operand being built.
• Access state: open; no identity required.
• Failure/recovery: none material; a digit press always appends.
• Continuation: the visitor presses another digit, a decimal, an operator, or equals.

FR-3 — Decimal entry (required_inference) As a Calculator User, I should press the decimal key to enter a fractional number.

• Trigger/input: a pointer press on the decimal key, or the . key.
• Observable result: a decimal point is placed in the current operand and subsequent digits extend the fractional part.
• Access state: open.
• Failure/recovery: a second decimal point in the same operand is ignored, so the operand stays well-formed.
• Continuation: the visitor continues entering digits or selects an operator.
• Rationale for inference: four-function arithmetic on real inputs is not usable without fractional entry; this is the minimum mechanic that makes the accepted arithmetic work.

FR-4 — Operator selection and armed state (explicit) As a Calculator User, I should press one of ÷, ×, −, + to choose the operation, and see which operator is armed.

• Trigger/input: a pointer press on an operator key, or the corresponding keyboard operator.
• Observable result: the operator is armed, its key fills with the accent (#C25A2E), and the current operand is committed as the left operand with the expression line showing the pending expression.
• Access state: open.
• Failure/recovery: pressing an operator with no operand entered leaves the state unchanged rather than producing an error.
• Continuation: the visitor enters the right operand and presses equals, or presses a different operator to change the armed operation.
• Note: the accent fill persists for as long as the operator is armed and clears when the next number is entered.

FR-5 — Evaluation with equals (explicit) As a Calculator User, I should press equals to compute the result of my expression.

• Trigger/input: a pointer press on the equals key, or the Enter key.
• Observable result: the pending expression is evaluated and the result numeral shows the computed value; the expression line shows what was evaluated.
• Access state: open.
• Failure/recovery: equals with no pending operator is a no-op; division by zero and any non-finite result display a clear non-numeric indication instead of a wrong number or a crash.
• Continuation: the visitor may continue calculating from the result, or press AC/Esc to start a new calculation.

FR-6 — Two-tier readout (explicit) As a Calculator User, I should see a small muted expression line above a large result numeral, so that I can read both what I asked and what came back.

• Observable result: the expression line shows the running expression in muted type, right-aligned; the result numeral shows the current value or result in ink, right-aligned, with tabular figures.
• Access state: open.
• Failure/recovery: on first load the expression line is empty and the result numeral shows 0.
• Continuation: the readout updates on every accepted input.

FR-7 — Clear the calculation (explicit) As a Calculator User, I should clear the current calculation to begin a new one.

• Trigger/input: a pointer press on AC, or the Escape key.
• Observable result: the result numeral returns to 0, the expression line empties, and no operator remains armed.
• Access state: open.
• Failure/recovery: clearing is always available and always succeeds.
• Continuation: the visitor begins a new calculation.

FR-8 — Sign change (explicit) As a Calculator User, I should press ± to change the sign of the current entry.

• Trigger/input: a pointer press on the ± key.
• Observable result: the current operand or result toggles between positive and negative and the result numeral reflects the change.
• Access state: open.
• Failure/recovery: pressing ± with no entry leaves the state unchanged.
• Continuation: the visitor continues the calculation with the negated value.

FR-9 — Percent (explicit) As a Calculator User, I should press % to apply percent to the current entry.

• Trigger/input: a pointer press on the % key.
• Observable result: the current entry is converted to its percent value and the result numeral reflects the change.
• Access state: open.
• Failure/recovery: pressing % with no entry leaves the state unchanged.
• Continuation: the visitor continues the calculation with the percent value.

FR-10 — Keyboard support (explicit) As a Calculator User, I should be able to use my physical keyboard instead of the on-screen keys.

• Trigger/input: digits, ., +, -, *, /, Enter, and Escape.
• Observable result: each key produces the same behavior as its on-screen counterpart, including the armed-operator state and the readout updates.
• Access state: open.
• Failure/recovery: unrecognized keys are ignored and do not disturb the calculation.
• Continuation: the visitor may switch freely between keyboard and pointer input.

FR-11 — Tactile key feedback (explicit) As a Calculator User, I should feel a key respond when I press it, so that the object feels like a physical thing.

• Observable result: a pressed key depresses 1px with a 90ms ease-out and returns; the result numeral cross-fades over 120ms when it changes.
• Access state: open.
• Failure/recovery: with prefers-reduced-motion, the depression is replaced by a 1px border-colour change and the cross-fade becomes an instant swap; the calculator remains fully usable.
• Continuation: the visitor keeps calculating.

FR-12 — Hint strip (explicit) As a Calculator User, I should see the three quiet hints beneath the object so I know what the page supports.

• Observable result: three hairline-separated hints at 12px caps with 0.14em tracking state keyboard support, clearing with Esc, and that history is cleared on reload.
• Access state: open.
• Failure/recovery: not applicable; the strip is static.
• Continuation: the visitor uses the hints or ignores them.

FR-13 — In-memory calculation state (required_inference) As a Calculator User, I should have my current calculation held for the life of the page and discarded when I reload.

• Observable result: the calculation persists across interactions within the page and is gone after a reload, matching the stated hint that history is cleared on reload.
• Access state: open; no identity, no persistence, no storage.
• Failure/recovery: a reload is a clean start, not an error.
• Continuation: the visitor begins a new calculation after reload.
• Rationale for inference: the accepted hint strip explicitly states that reload clears history, which requires the calculation to be held in page memory and nowhere else.

4. User Personas

Calculator User

Product context. The Calculator User arrives at the page with a number in mind and a small piece of arithmetic to do. They are not shopping for a tool, not evaluating a product, and not looking for a workspace. They want the answer in seconds and then they want to leave. The page is a tabletop with one object on it.

Primary goal. Perform a four-function calculation quickly and read a result that matches the arithmetic they intended.

Distinct accepted responsibilities. This persona is the only active human actor, and their work is narrow and complete: enter digits and a decimal point to build an operand; select one of ÷, ×, −, + and see which operator is armed; press equals to evaluate; read the two-tier readout; use ± and % on the current entry; clear the calculation with AC or Esc to start again; and use the physical keyboard instead of the on-screen keys when that is faster.

Relevant inputs and decisions. The digits and operators they press or type; whether to correct an entry with AC or continue from the current result; whether to use the keyboard or the pointer. Their one real decision is whether the displayed result is the answer they wanted.

Interactions with other accepted participants. There are no other accepted human participants. The Calculator User's only counterpart is the browser runtime, which evaluates the expression and holds the calculation state for the life of the page. No handoff to another person, provider, or external service occurs.

Observable success. The result numeral shows the value the visitor intended, the expression line shows what was evaluated, and the calculation can be cleared and restarted without friction. The visitor's work is complete when they have read the answer; nothing is saved, sent, or shared.

What makes this role different. The role is defined by speed and disappearance. There is no account, no history to manage, no collaboration, and no configuration. The measure of success is that the visitor never has to think about the tool at all.

5. Core User Flows

Flow 1 — A first four-function calculation

1. The Calculator User opens the page root and lands directly on the calculator object. The wordmark AUTUMN · CALCULATOR and the line Four functions, one page, nothing else. sit above it; the result numeral shows 0 and the expression line is empty.
2. The visitor presses the digit keys 1, 2, 8. Each key depresses 1px and returns; the result numeral updates to 128.
3. The visitor presses ÷. The key fills with the burnt-sienna accent and stays filled; the expression line shows 128 ÷ and the operator is armed.
4. The visitor presses 4. The accent fill clears as the new number is entered; the result numeral shows 4.
5. The visitor presses equals. The result numeral cross-fades over 120ms to 32 and the expression line shows 128 ÷ 4.
6. Observable result: the visitor reads 32 and the expression that produced it.
7. Continuation: the visitor either continues calculating from 32 or presses AC to begin again.

Flow 2 — Correcting a mistake and starting over

1. The visitor is mid-calculation and realizes the entry is wrong.
2. The visitor presses AC, or presses Escape on the keyboard. The result numeral returns to 0, the expression line empties, and no operator remains armed.
3. Observable result: the object is back to its first-load state.
4. Continuation: the visitor enters the correct calculation from the beginning.

Flow 3 — Using the keyboard instead of the keys

1. The visitor prefers typing. With the page focused, they type 9, *, 7, Enter.
2. Each keystroke produces the same behavior as its on-screen counterpart: the digits build the operand, * arms multiplication and fills the × key with the accent, and Enter evaluates.
3. Observable result: the result numeral shows 63 and the expression line shows 9 × 7.
4. Failure/recovery: if the visitor types a key the calculator does not recognize, nothing happens and the calculation is undisturbed.
5. Continuation: the visitor presses Escape to clear, or continues typing.

Flow 4 — Sign change and percent on the current entry

1. The visitor has entered 250 and wants ten percent off.
2. The visitor presses %. The current entry is converted to its percent value and the result numeral reflects the change.
3. The visitor presses ±. The sign of the current entry toggles and the result numeral reflects the change.
4. Observable result: the readout shows the adjusted value, and the visitor can continue with an operator or press equals.
5. Failure/recovery: pressing % or ± with no entry leaves the state unchanged rather than producing an error.
6. Continuation: the visitor completes the calculation or presses AC.

Flow 5 — Division by zero

1. The visitor enters 8, presses ÷, enters 0, and presses equals.
2. The result numeral displays a clear non-numeric indication rather than a wrong number or a crash; the expression line still shows 8 ÷ 0.
3. Observable result: the visitor understands the calculation could not be completed.
4. Recovery: the visitor presses AC or Escape and begins a new calculation.
5. Continuation: the calculator is fully usable again immediately.

Flow 6 — Reload clears the calculation

1. The visitor has a result on screen and reloads the page.
2. The page renders the calculator object fresh: result numeral 0, empty expression line, no armed operator.
3. Observable result: the calculation is gone, exactly as the hint strip states.
4. Continuation: the visitor begins a new calculation.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. It names Naoto Fukasawa and his super normal language as the muse, with the headline idea that a browser calculator is a utility object, not a product: an object whose design disappears into use, with obvious affordances, calm proportions, and no styling for its own sake. The project name autumn-simple adds a warm, seasonal, restrained register — paper, unbleached cotton, a single fallen-leaf accent — without becoming decorative.

Palette (light mode)

Proportion. 70% paper ground, 20% ink/dark key blocks, 8% light surface, 2% accent. The accent is the only saturated colour on the page.

Typography

• Headings: Jost, 300–400 weight, for the wordmark and section titles; geometric, quiet, wide-tracked small caps for labels (CALCULATOR), never shouting.
• Display numerals: Jost 300 with tabular figures and tight-but-open tracking, so the result reads as an instrument readout rather than a headline.
• Body: Karla.
• Scale: 1.25 modular — 44 / 34 / 26 / 18 / 16. Display numerals clamp(40px, 9vw, 72px); key numerals 26px; wordmark 18px; label 12px caps with 0.14em tracking; body 16px / 1.6.

Shape language. Rounded blocks with continuous curves: keys at 16px radius, the calculator body at 28px, the display tray at 20px. No blobs. No pills except the single equals key, which is a full capsule. Soft 1px borders in a warm grey, and a single low, wide shadow under the calculator body — 0 18px 40px rgba(42,39,35,0.08) — so it sits on the paper like an object, not a floating card.

Layout. A single centred column on the paper ground. The calculator object is the whole page: a 360px-wide body at 375px viewport, 420px at 768px, 460px at 1280px, vertically centred with generous breathing room above and below. Inside: the display tray at the top (right-aligned running expression in muted, large result beneath in ink), then a 4-column keypad grid with 12px gutters in a fixed order — AC ± % ÷ / 7 8 9 × / 4 5 6 − / 1 2 3 + / 0 spanning two columns, decimal, equals. Above the object, a single wide-tracked wordmark AUTUMN · CALCULATOR and one line of quiet copy; below it, three tiny hairline-separated hints. No navigation bar, no footer columns, no marketing sections.

Imagery. None. The interface is the image. The only visual incident is the paper texture of the ground (a very faint 2% noise, or nothing at all) and the single burnt-sienna accent on the equals key. No illustrations, no icons beyond the four operator glyphs and the ± and % characters set in the same type as the numerals.

Avoid. Any blue or indigo primary or accent (#0057FF, #2563EB, #4F46E5, #6366F1, #7C3AED and neighbours) on a white ground; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or numerals; gradient-blob backgrounds, glassmorphism panels, frosted cards, and hover-lift tiles; a centred marketing hero with a headline, subheadline, and coloured CTA above the calculator; neumorphic soft-extruded keys, drop-shadowed circular buttons, and skeuomorphic LCD textures; dark mode by default, neon accents, or more than one saturated colour anywhere on the page; entrance animations, counting-number flourishes, parallax, or any motion beyond the 1px key press; additional pages, navigation bars, footers, or any section that is not the calculator object and its hint strip.

Readable text and controls. Headlines, the wordmark, labels, numbers, 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, and no other element covers any part of them. Decoration and motion may be cropped or bled off an edge as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The tabletop. The first screen is not a hero in the marketing sense — it is a tabletop. A warm unbleached-paper ground (#F4F1EA) fills the viewport. Dead centre sits one rounded calculator object, 360–460px wide, softly shadowed, its display tray showing 0 in 40–72px Jost Light, right-aligned, with an empty muted expression line above it. The wordmark AUTUMN · CALCULATOR sits above the object in 18px wide-tracked caps, and a single line of body copy — Four functions, one page, nothing else. — sits beneath it. The equals key is the only saturated element on the screen: a burnt-sienna capsule at the bottom-right of the grid. There is no gradient, no blob, no centred marketing headline, no blue button; the composition reads as a photographed object on a sheet of paper.

Signature moves

• The calculator is treated as a physical object on a paper tabletop: a single rounded body with one low wide shadow, centred on an unbleached-paper ground, with no card grid, no panels, and no surrounding chrome.
• A single burnt-sienna capsule equals key is the only saturated colour in the entire page — every other key is either paper-light with a hairline border or a soft ink-dark block, so the eye always knows where the answer lives.
• The display is a two-tier readout: a small muted expression line (128 ÷ 4) above a large Jost Light result numeral with tabular figures, right-aligned like an instrument, not a headline.
• Keys depress 1px on press with a 90ms ease-out, and the armed operator key fills with the accent until the next number is entered — tactile feedback instead of hover-lift animation.
• A three-line hairline-ruled hint strip sits beneath the object (keyboard input, Esc to clear, reload clears history) at 12px caps with 0.14em tracking — the only place the page speaks, and it speaks quietly.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: still Hero Dimensionality: flat

The creative direction sets the tempo at the muse's ceiling: still, with only tactile key feedback. This section copies that tempo rather than re-deciding it.

Landing Hero Motion Brief

• Focal subject. The calculator object itself, centred on the unbleached-paper ground, with the burnt-sienna equals key as the single point of colour.
• Input → transformation → outcome thesis. A key press is the only input. The transformation is tactile and immediate: the key depresses 1px over 90ms and returns, the result numeral cross-fades over 120ms when its value changes, and the armed operator key fills with the accent for as long as it is armed. The outcome is a readout that has visibly responded to the visitor's touch — the object acknowledges the press without performing for it.
• Motion vocabulary. Still. No entrance animations, no hover lift, no parallax, no counting numbers. The only movement is the 1px key depression, the 120ms result cross-fade, and the accent fill on the armed operator.
• Composed first frame. Paper ground filling the viewport; the wordmark and one line of copy above; the calculator object centred with its low wide shadow; the display tray showing 0 in Jost Light with an empty muted expression line above it; the keypad in its fixed order with the burnt-sienna equals capsule at the bottom-right; the three-line hint strip beneath.
• Reduced-motion state. With prefers-reduced-motion, the key depression is replaced by a 1px border-colour change and the result cross-fade becomes an instant swap. The calculator remains fully usable and the composition is unchanged.

No 3D or WebGL scene is requested by the user and the direction's hero dimensionality is flat, so no Canvas, R3F, or Drei requirement is introduced.

9. Non-Functional Requirements

NFR-1 — Single-page constraint (explicit) The design must be a single page. The product is delivered as one page with no additional pages, navigation bars, footers, or any section that is not the calculator object and its hint strip.

• Rationale: the authoritative requirement thread asks for a simple single-page calculator design, and the page contract fixes the count at one.

NFR-2 — Responsive integrity (explicit) Headlines, the wordmark, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them.

• Rationale: stated in the creative direction's readable-text rule.

NFR-3 — Reduced motion (explicit) With prefers-reduced-motion, the key depression is replaced by a 1px border-colour change and the result cross-fade becomes an instant swap, with the calculator fully usable.

• Rationale: stated in the creative direction's motion rules.

NFR-4 — No persistence (explicit) The calculation is held in page memory only and is cleared on reload. No storage, no account, and no server-side state is used.

• Rationale: the hint strip states that history is cleared on reload, and no accepted capability requires persistence.

NFR-5 — No network dependency for arithmetic (required_inference) The four functions are computed in the browser; no server round-trip is required for any accepted capability.

• Rationale: the accepted behavior is a client-side calculator with no server-side requirement in the source; introducing a network call would add latency and failure modes the product does not need.

NFR-6 — Accessibility of the readout and keys (required_inference) The result numeral and expression line are readable text, and every key is an operable control with a visible pressed state; keyboard input is a first-class alternative to pointer input.

• Rationale: the accepted keyboard support and the readable-text rule require the controls and readout to remain whole and operable.

NFR-7 — No saturated colour beyond the accent (explicit) The burnt sienna (#C25A2E) is the only saturated colour on the page, used only on the equals key and the one live operator state.

• Rationale: stated in the creative direction's palette and signature moves.

10. Tech Stack

The authoritative requirement thread does not name a technology. The following are the minimal, coherent choices for a single-page client-side calculator, labelled as defaults.

• Frontend: React with a single-page component tree. [Default — not specified by user]
• Styling: plain CSS with custom properties for the palette tokens, the type scale, and the radius and shadow values. [Default — not specified by user]
• Arithmetic: computed in the browser; no backend, no API, and no database. [Default — not specified by user]
• Build and serving: a static build served as a single page. [Default — not specified by user]

No backend service, queue worker, container orchestration, or additional infrastructure is introduced, because no accepted capability requires server-side behavior.

11. Assumptions and Constraints

Assumptions

• A-1 — The visitor's browser supports modern CSS custom properties, clamp(), and prefers-reduced-motion. [Default — not specified by user]
• A-2 — The page is served at the root and the visitor lands directly on the calculator object. [Default — not specified by user]
• A-3 — The four functions are the whole arithmetic surface; no scientific, memory, or conversion functions are present. (explicit, from the accepted scope)
• A-4 — The calculator object is the whole page; there is no surrounding chrome. (explicit, from the creative direction)

Constraints

• C-1 — The design must be a single page. (explicit)
• C-2 — The product is one page; no additional pages, navigation bars, footers, or any section that is not the calculator object and its hint strip. (explicit)
• C-3 — The palette, typography, shape language, layout, motion, and imagery follow the creative direction exactly as specified in sections 6, 7, and 8. (explicit)
• C-4 — No blue or indigo primary or accent on a white ground; no Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or numerals; no gradient blobs, glassmorphism, frosted cards, or hover-lift tiles; no centred marketing hero; no neumorphic keys or skeuomorphic LCD textures; no dark mode by default; no more than one saturated colour. (explicit)
• C-5 — No entrance animations, counting-number flourishes, parallax, or any motion beyond the 1px key press. (explicit)
• C-6 — No accounts, sign-in, or persisted user state. (explicit, from the accepted scope)

12. Glossary

• AC — All clear. The key that resets the current calculation to 0 with an empty expression line and no armed operator. Equivalent to the Escape key.
• Armed operator — The operator most recently selected, held in state until the next number is entered. Its key fills with the accent while armed.
• Calculator object — The single rounded body containing the display tray and the keypad; the whole page.
• Display tray — The 20px-radius area at the top of the calculator object holding the expression line and the result numeral.
• Expression line — The small muted line above the result numeral showing the running expression, for example 128 ÷ 4.
• Hint strip — The three hairline-separated hints beneath the calculator object: keyboard support, clear with Esc, history cleared on reload.
• Keypad grid — The four-column grid of keys in fixed order: AC ± % ÷ / 7 8 9 × / 4 5 6 − / 1 2 3 + / 0 spanning two columns, decimal, equals.
• Operand — The number currently being entered.
• Pending expression — The left operand, the armed operator, and the right operand, held in page memory.
• Result numeral — The large ink numeral showing the current value or computed result, right-aligned with tabular figures.
• Super normal — Naoto Fukasawa's design language: an object whose design disappears into use, with obvious affordances and calm proportions. The muse for this project.
• Two-tier readout — The display pattern of a small muted expression line above a large result numeral.