System Requirements Document for moon-calculator

1. Introduction

moon-calculator is a simple calculator delivered as a single page design. A person opens the page, enters numbers and arithmetic operators, reads the current expression and the computed result, and clears the calculation to start over. There is no account, no navigation, no marketing surface, and no second page: the calculator slab itself is the entire product.

The audience is anyone who needs quick arithmetic in a browser — an everyday utility used in a calm, private register. The design intent is "emptiness as content": one instrument glowing quietly on a paper-white field with room to breathe, in the spirit of Kenya Hara's super-normal object design. The page is a still-life, not a control panel.

2. System Overview

moon-calculator is a single-page, anonymous, client-side calculator. The page presents one calculator slab containing:

• a numeric display showing the current expression and, after evaluation, the computed result;
• a 4×5 keypad of digits, arithmetic operators, and a clear control;
• a small eyebrow wordmark and a single muted helper line.

All calculation happens in the browser. There is no server-side computation, no persistence, no identity, and no cross-session state. The single accepted human actor is the Calculator User, who is anonymous and unauthenticated by design.

Current delivery is one custom page, Calculator, which is the anonymous public entry and the only destination. It hosts digit and operator input, expression evaluation with displayed result, and clearing to start over, all within the exact one-page constraint.

Removed from scope

• Multi-page navigation, headers, footers, and marketing copy around the calculator (also: header navigation, footer links)
• Accounts, sign-in, and user profiles
• Calculation history and saved calculations
• Scientific, programmer, or unit-conversion calculator modes
• Server-side computation or APIs

2a. Product Interpretation and Delivery Boundary

The product is a browser-delivered, single-page calculator with no backend dependency for its core behavior. The page is publicly reachable with no access requirement: a Calculator User arrives anonymously and immediately has the full instrument available. There is no first-use identity establishment, no returning verification, and no protected state, because nothing the user does is durable, private, or bound to a participant.

The current horizon contains exactly the accepted behavior: entering numbers and arithmetic operators, viewing the current expression and computed result, and clearing to start over. Nothing beyond that is current. There is no future roadmap committed in the source; any extension (history, memory keys, scientific functions) would be a new requirement, not an implied one.

2c. Page Content and Component Coverage

Calculator

The single page of the product. It is the anonymous public entry and the only destination; it owns the complete calculator lifecycle — input, evaluation, display, and clearing.

Information and state

• Current expression: the sequence of digits and operators the user has entered, shown in the display area.
• Computed result: the evaluated value, shown in the display after the user requests evaluation (equals).
• Active operator state: which arithmetic operator is currently pending, indicated by the single terracotta underline.
• Idle/initial state: display shows a starting value (0) with no pending operator and no result.
• Error state: when an expression cannot be evaluated (for example division by zero), the display shows an error indication instead of a numeric result.

Primary actions

• Press digit keys (0–9) to append digits to the current number entry.
• Press arithmetic operator keys (+, −, ×, ÷) to record the pending operation; the active operator receives the terracotta underline.
• Press equals to evaluate the current expression and display the result.
• Press clear (C) to reset the calculation to the idle state so the user can start over.

Supporting actions and elements

• Eyebrow wordmark "moon · calculator" flush left inside the slab — the only uppercase text on the page, acting as a maker's mark.
• A single muted helper line below the slab reading "clear to start over".
• A single 1px hairline rule separating the display from the keypad — the only line on the page.

Domain entities

• Expression: an ordered sequence of numeric operands and arithmetic operators.
• Operand: a number the user has entered.
• Operator: one of addition, subtraction, multiplication, division.
• Result: the numeric outcome of evaluating the expression.

Component responsibilities

• Display region: renders the current expression and the computed result in a large light-weight tabular-numeral typeface; cross-fades the result line over 180ms when a new equals is computed (instant swap under reduced motion).
• Hairline rule: visually separates display from keypad.
• Keypad grid: 4-column × 5-row grid of flat 8px-radius square keys with 12px gutters; digit keys, operator keys, equals, and clear.
• Operator underline: a 2px terracotta mark beneath the active operator key; slides 120ms when the active operator changes.
• Key press feedback: 90ms opacity/inset flash; pressed state is a 1px inset ink line rather than a fill change.
• Helper line: muted 12px text below the slab.

States

• Loading: none — the page is fully client-side and renders immediately; no loading indicator is required.
• Empty/initial: display shows 0, no pending operator, no result.
• Success: after equals, the display shows the computed result; the expression remains visible above or alongside it.
• Error: an unevaluable expression (e.g., division by zero) shows an error indication in the display; the user recovers by pressing clear and starting over.
• Recovery: clear (C) always returns the page to the idle state from any state, including error.

3. Functional Requirements

FR-1 — Single-page calculator delivery (explicit) As a Calculator User, I should get the entire calculator on one single page, so that I can do arithmetic without navigating anywhere.

• Trigger: the user opens the page.
• Observable result: the calculator slab with display and keypad is present on the one page; there is no other page or navigation.
• Access: anonymous, no access requirement.
• Failure/recovery: not applicable — the page is static and client-side.
• Continuation: the user proceeds directly to entering numbers.

FR-2 — Enter numbers and arithmetic operators (explicit) As a Calculator User, I should enter numbers and arithmetic operators, so that I can build the calculation I want to compute.

• Trigger: the user presses digit keys and operator keys on the keypad.
• Observable result: the entered digits appear in the display as the current expression; the pressed operator is recorded and marked with the terracotta underline.
• Access: anonymous.
• Failure/recovery: if the user enters an unintended digit or operator, they can clear and re-enter (FR-4).
• Continuation: the user presses equals to compute (FR-3).

FR-3 — View the current expression and computed result (explicit) As a Calculator User, I should view the current expression and the computed result on the page, so that I can read what I entered and what it evaluates to.

• Trigger: the user presses equals after entering an expression.
• Observable result: the display shows the computed result; the current expression remains visible. The result line cross-fades over 180ms (instant swap under reduced motion).
• Access: anonymous.
• Failure/recovery: if the expression cannot be evaluated (e.g., division by zero), the display shows an error indication; the user recovers via clear (FR-4).
• Continuation: the user may continue entering a new expression or clear.

FR-4 — Clear the calculation to start over (explicit) As a Calculator User, I should clear the calculation, so that I can start over from a clean state.

• Trigger: the user presses the clear (C) key.
• Observable result: the display returns to the idle state (0, no pending operator, no result); the active-operator underline is removed.
• Access: anonymous.
• Failure/recovery: clear works from any state, including error, and is the recovery path for all error states.
• Continuation: the user begins a new calculation.

4. User Personas

Calculator User

Product context. A person who needs quick everyday arithmetic in a browser. They arrive at the page anonymously, with no account and no prior state, and expect the instrument to be immediately usable. The register is calm and private: no brand, no marketing, no noise.

Primary goal. Get an accurate arithmetic result from one self-contained page, quickly and without distraction.

Distinct accepted responsibilities.

• Enter numbers and arithmetic operators to build an expression.
• Read the current expression and the computed result.
• Clear the calculation to start over, including recovering from an error.

Relevant inputs and decisions. Which digits and operators to enter; when to press equals; whether the displayed result is correct or whether to clear and re-enter.

Interactions with other participants. None. The Calculator User is the only accepted human actor; there is no counterparty, recipient, or beneficiary whose state changes. All work is local to the user's browser session.

Observable success. The display shows the correct computed result for the entered expression, and the user can clear to start a new calculation at any time.

5. Core User Flows

Flow 1 — Perform a calculation

1. The Calculator User opens the moon-calculator page in a browser. The page renders the calculator slab on a paper-white field: eyebrow "moon · calculator", display showing 0, hairline rule, and the 4×5 keypad. No sign-in or setup is required.
2. The user presses digit keys to enter the first operand. The digits appear in the display as the current expression.
3. The user presses an arithmetic operator key. The operator is recorded, and the terracotta underline slides beneath that key (120ms) to mark it as the active operator.
4. The user presses digit keys to enter the second operand. The display shows the full expression.
5. The user presses equals. The result line cross-fades over 180ms (instant swap under reduced motion) and the display shows the computed result alongside the expression.
6. Success: the user reads the result. They may continue with a new expression or press clear to start over (Flow 3).

Flow 2 — Recover from an unevaluable expression

1. The user has entered an expression that cannot be evaluated (for example, division by zero) and presses equals.
2. The display shows an error indication instead of a numeric result.
3. Recovery: the user presses clear (C). The display returns to the idle state (0, no pending operator, no result), and the active-operator underline is removed.
4. Continuation: the user re-enters a valid expression (Flow 1, step 2).

Flow 3 — Clear and start over

1. From any state — mid-entry, after a result, or after an error — the user presses the clear (C) key.
2. The display resets to the idle state; the active-operator underline is removed.
3. Continuation: the user begins a new calculation (Flow 1, step 2).

6. Visuals Colors and Theme

The creative direction is authoritative for this section. Muse: Kenya Hara; headline idea: "Emptiness as content — a calculator that whispers."

Palette (light mode)

Typography

• Family: Zen Kaku Gothic New for both headings and body.
• Weights: Light 300 only. No bold anywhere; hierarchy comes from size and space.
• Wordmark "moon": Light 300, wide letter-spacing 0.08em at small sizes.
• Numeric display: same family, weight 300, tabular-nums so digits align like an odometer.
• Type scale (1.5 modular): display clamp(40px, 6vw, 72px); result 28px mobile / 44px desktop; key labels 18px mobile / 20px desktop; eyebrow 11px mobile / 12px desktop with 0.16em tracking.
• Body line-height 1.7; numbers line-height 1.

Shape language

• Soft-cornered squares: calculator body is a 12px-radius slab with a 1px hairline border and no shadow.
• Keys are 8px-radius squares on a 4-column grid with 12px gutters, flat fills (no gradient, no bevel).
• Pressed state is a 1px inset ink line rather than a colour change.
• One thin horizontal rule separates the display from the keypad — the only line on the page.

Layout

• Single centred column, max-width 420px on desktop, with the slab vertically centred in a full-viewport paper field.
• Above the slab, a tiny eyebrow line "moon · calculator" in 0.16em-tracked 11px caps sits flush left within the slab's width.
• Below, a single muted line at 12px reads "clear to start over" — no footer, no navigation, no cards.
• Mobile: slab edge-to-edge with 20px side gutters so the keypad stays thumb-friendly.
• Tablet: centred with 24px margins.
• Desktop: floats in a generous 1280px field with empty paper visible on all four sides.

Imagery

• No photography, no illustration. The calculator slab is the only visual subject, treated like a still-life on a plain ground.
• The only decorative gesture is a barely-visible paper grain (2% opacity SVG noise) on the background field, plus the 1px hairline rule that acts like the edge of a table in a Hara photograph.

Accessibility of text and controls

• All readable text and controls stay whole at 375px, 768px, and 1280px, wrapping or scaling to fit; no element covers any part of them.
• The terracotta accent is never the sole carrier of meaning: the active operator is also indicated by the underline's position beneath the key.

7. Signature Design Concept

The slab as still-life. The public entry is a full-viewport paper-white field (#F7F5F0) with the calculator slab floating in the optical centre at 420px wide — no headline above it, no hero image, no CTA. The slab is the hero: a 1px-bordered off-white rectangle whose top third is an empty display area holding a 72px light-weight tabular number, with a 1px hairline rule under it and a 4×5 key grid beneath. In the top-left of the slab, an 11px tracked eyebrow "moon · calculator" anchors the composition asymmetrically. The single terracotta accent sits as a 2px underline beneath the current operator key. Roughly 60% of the desktop viewport is empty paper — the negative space is the design.

Signature moves

• The calculator slab as a still-life object: a 420px hairline-bordered rectangle floating in a full-viewport paper field, with no surrounding headline, card, or CTA.
• A 72px light-weight tabular-numeral display with a single 1px ink rule beneath it, so the current expression reads like an odometer on a MUJI appliance rather than a UI input.
• One terracotta accent (#B75A34) used exactly once — a 2px underline beneath the active operator key.
• A 4×5 keypad of flat 8px-radius squares on a 12px gutter grid, with pressed state as a 1px inset ink line instead of a fill change — keys that feel like membrane switches, not buttons.
• An 11px, 0.16em-tracked eyebrow "moon · calculator" flush left inside the slab, the only uppercase text on the page, acting as a maker's mark rather than a brand header.

Avoid: drop shadows, bevels, glossy key gradients; header navigation, footer links, or marketing copy; more than one accent colour; bold weights, tight tracking, or all-caps button labels; gradient blobs, glassmorphism, or card grids; decorative animation, floating elements, or looping motion; photography or illustration; a centred headline + subtext + button above the calculator.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the calculator slab itself — a 420px hairline-bordered off-white rectangle floating in a full-viewport paper-white field, with the 72px tabular numeral display as its focal point.
• Input → transformation → outcome thesis: the user presses a key → the key flashes with a 90ms opacity/inset ink line and the digit or operator appears in the display → the expression builds; on equals, the result line cross-fades over 180ms and the computed result settles into the display. The active operator's terracotta underline slides 120ms when the operator changes. Nothing loops, nothing floats.
• Motion vocabulary: 90ms key-press opacity/inset flash; 180ms result cross-fade; 120ms operator-underline slide. No other motion.
• Composed first frame: the paper-white field fills the viewport; the slab sits in the optical centre with the eyebrow "moon · calculator" flush left at the top of the slab, the display showing 0, the hairline rule beneath it, and the 4×5 keypad below. The terracotta underline is absent until an operator is pressed.
• Reduced-motion state: with prefers-reduced-motion, the result cross-fade becomes an instant swap; the key-press flash and underline slide remain as instantaneous state changes. The static arrangement is fully usable.

9. Non-Functional Requirements

• Single-page constraint (explicit): the calculator design must be a single page. There is exactly one page, Calculator, and no other route or destination.
• Simplicity (explicit): the design is a "simple single page design of the calculator" — no features beyond entering numbers and operators, viewing the expression and result, and clearing.
• Client-side computation (required_inference): all arithmetic evaluates in the browser; no server round-trip is needed for a result, so the page works without a backend.
• Anonymous access (required_inference): the page has no access requirement; no identity, session, or persistence is established.
• Responsive integrity (explicit, from creative direction): readable text and controls stay whole at 375px, 768px, and 1280px; the slab adapts edge-to-edge on mobile, centred on tablet, and floats in a 1280px field on desktop.
• Reduced motion (explicit, from creative direction): prefers-reduced-motion replaces the result cross-fade with an instant swap.
• No decorative motion (explicit, from creative direction): nothing loops, floats, or animates beyond the specified key-press, result, and underline transitions.

10. Tech Stack

• Frontend: React single-page application (one route, the Calculator page).
• Styling: CSS with the specified tokens — Zen Kaku Gothic New (Light 300), tabular numerals, the palette above, 12px slab radius, 8px key radius, 12px gutters.
• Computation: client-side JavaScript arithmetic; no backend service is required for the accepted behavior.
• No database, no authentication provider, no external API — none is needed for a stateless, anonymous, single-page calculator.

11. Assumptions and Constraints

• Assumption (required_inference): the calculator supports the four basic arithmetic operations (+, −, ×, ÷), decimal digits, equals, and clear, as the minimum set implied by "enter numbers and arithmetic operators to compute a result" and "clear the calculation to start over". No scientific functions, memory keys, or history are included.
• Assumption (required_inference): the display shows a starting value of 0 in the idle state.
• Assumption (required_inference): an unevaluable expression (e.g., division by zero) shows an error indication, and clear is the recovery path.
• Constraint (explicit): exactly one page; no navigation, header, footer, or marketing copy.
• Constraint (explicit, from creative direction): the terracotta accent #B75A34 appears exactly once on the page; no bold weights; no shadows, gradients, or decorative motion.
• Constraint (explicit, from creative direction): the generic indigo/blue-on-white SaaS template is forbidden.

12. Glossary

• Calculator User — the single accepted human actor; an anonymous person performing arithmetic on the page.
• Expression — the ordered sequence of operands and operators the user has entered.
• Operand — a number entered by the user.
• Operator — one of addition, subtraction, multiplication, or division.
• Result — the numeric outcome of evaluating the expression.
• Slab — the 420px hairline-bordered calculator body that is the page's only visual subject.
• Eyebrow — the 11px, 0.16em-tracked "moon · calculator" wordmark flush left inside the slab.
• Active operator underline — the single 2px terracotta mark beneath the currently selected operator key.