System Requirements Document for icy-simple

1. Introduction

icy-simple is a calculator application for people who need immediate, legible arithmetic in a focused visual environment. The product delivers calculator input, arithmetic operation selection, result display, and clearing or correction within the locked Calculator page.

The current scope does not retain the earlier request for a “simple single page design.” The current product is a calculator with a precise, graphic, poster-like interface guided by Swiss arithmetic design principles. The versioned page contract remains limited to the single Calculator page.

2. System Overview

icy-simple is a first-party custom user interface that provides everyday calculator interactions directly in the browser or application runtime.

Current Delivery

• The application provides one custom page: Calculator.
• The Calculator page is anonymously accessible; no account, sign-in, profile, role, or permission model is required.
• A Calculator User enters numbers and operators through an on-screen keypad.
• The system displays the current expression or running value and the resulting arithmetic value.
• The user can select an operation, complete a calculation, clear the current calculation, or correct the active entry.
• The calculator is a self-contained interface and does not require external providers, recipient handoffs, stored histories, saved calculations, or account continuity.

Current Scope

The current scope includes:

• On-screen number entry.
• Arithmetic operator entry.
• A visible calculator display.
• Calculation result display.
• Clear and correction controls.
• Operation-state feedback.
• The single contracted Calculator page.

Narrow Exclusions

The current scope excludes:

• Additional pages, secondary navigation, dashboards, or settings areas.
• User accounts, authentication, profiles, roles, permissions, or saved calculation history.
• Sharing, exporting, printing, collaboration, or external calculator integrations.
• Photography, decorative illustration, generic SaaS dashboard styling, glassmorphism, rounded card layouts, or decorative 3D objects.
• A generic simple single-page design treatment; the calculator must instead follow the supplied monumental Swiss arithmetic direction.

2a. Product Interpretation and Delivery Boundary

icy-simple is delivered as a focused calculator interface owned by the application. The Calculator page is publicly available and does not require identity establishment because calculations are ephemeral and no durable user-specific state is accepted in scope.

The application owns visible calculator input, expression state, operation selection, calculation output, clearing, and correction. Calculation evaluation may be performed locally within the application runtime. No external provider, external destination, account system, or persistence layer is needed for the accepted experience.

The current product boundary is intentionally narrow: one Calculator page containing the entire accepted calculator workflow. Future calculator capabilities, account-based continuity, history, conversion tools, or multi-page navigation are not current requirements.

2c. Page Content and Component Coverage

Calculator

• Purpose and information

  • Presents the active numeric entry, expression state where applicable, selected arithmetic operation, and calculated result.
  • Shows the calculator as a high-contrast Swiss poster-like composition rather than a generic utility panel.
  • Keeps all current calculator behavior within the contracted Calculator page.

• Display area

  • Uses an oversized numeric display for the current value or result.
  • Clearly distinguishes the value currently being entered from a completed calculated result.
  • Uses tabular numerals to maintain stable digit alignment.
  • Clips oversized display numerals cleanly at the display boundary when required by the visual composition.

• Operation state

  • Shows the active arithmetic operation when an operator has been selected.
  • Includes a coordinate-like operation label such as OP / 03 and a matching circular yellow operation marker.
  • Uses signal red for selected operators and equals-related emphasis.
  • Uses the small yellow registration dot as the active decimal indicator when decimal input is active.

• Keypad

  • Provides on-screen numeric keys for entering values.
  • Provides arithmetic operator keys.
  • Provides an equals control for completing a calculation.
  • Provides clear and correction controls for resetting or amending input.
  • Uses square keys, visible 1px black grid boundaries, and intentionally varied key spans.
  • Includes one uninterrupted signal-red vertical equals key spanning two keypad rows at the far-right side of the keypad.

• Primary actions

  • Enter a digit.
  • Select an arithmetic operator.
  • Enter the next numeric value.
  • Complete the calculation with equals.
  • Clear the active calculation.
  • Correct the active entry.

• Supporting interaction states

  • Initial state: Displays a neutral starting value and no selected operation.
  • Input state: Displays entered digits and preserves the current active value.
  • Operator-selected state: Highlights the selected operation and updates the operation marker.
  • Result state: Displays the evaluated arithmetic result.
  • Correction state: Removes or replaces the active entry according to the selected correction control.
  • Cleared state: Returns the calculator to its initial calculation state.
  • Invalid-operation state: Prevents an unusable arithmetic result from being presented as a valid numeric answer and keeps the user able to clear or correct the expression.
  • Recovery state: Lets the user correct the active entry or clear the calculation and begin another calculation without leaving the Calculator page.

3. Functional Requirements

FR-01 — Use the Calculator Interface

As a Calculator User, I should be able to access the Calculator page without authentication so that I can begin an arithmetic calculation immediately.

• Provenance: required_inference
• Access state: Anonymous/public access.
• Trigger or input: The Calculator User opens the application.
• Required behavior:
  • The system shall present the Calculator page as the application’s available calculator surface.
  • The system shall make the calculator display, keypad, operator controls, equals control, clear control, and correction control available on that page.
  • The system shall not require sign-in, account creation, profile setup, or identity verification before calculator use.
• Observable result: The Calculator User can start entering a calculation immediately.
• Failure and recovery: If the calculator cannot initialize, the interface shall communicate that calculation controls are unavailable and allow the user to retry initialization within the same page context.
• Continuation: The user proceeds by entering a number, selecting an operator, or clearing the display.

FR-02 — Enter Numeric Values

As a Calculator User, I should be able to enter numbers through on-screen numeric controls so that I can compose an arithmetic calculation.

• Provenance: required_inference
• Access state: Anonymous/public access.
• Trigger or input: The user selects one or more numeric keypad controls.
• Required behavior:
  • The system shall append or replace the active numeric entry according to the calculator’s current calculation state.
  • The system shall visibly update the display after each accepted numeric input.
  • The system shall preserve readable digit alignment in the display through tabular numeral styling.
• Observable result: The active numeric value visibly reflects the user’s entered digits.
• Failure and recovery: If an input cannot be accepted because it would create an invalid entry state, the system shall retain the last valid display state and allow the user to enter a valid digit, correct the entry, or clear the calculation.
• Continuation: The user may enter more digits, select an arithmetic operator, correct the value, clear the calculation, or evaluate it where a complete expression exists.

FR-03 — Select an Arithmetic Operation

As a Calculator User, I should be able to select an arithmetic operation so that I can combine numeric values.

• Provenance: required_inference
• Access state: Anonymous/public access.
• Trigger or input: The user selects an available arithmetic operator control after entering or displaying a numeric value.
• Required behavior:
  • The system shall set the chosen arithmetic operator as the active operation.
  • The system shall visibly distinguish the selected operator from inactive operator controls.
  • The system shall update the operation marker to communicate that an operation is active.
  • The system shall preserve the first numeric value as part of the active calculation state.
• Observable result: The selected operator is visibly active and the user can enter the next numeric value.
• Failure and recovery: If an operator is selected without a usable preceding numeric value, the system shall retain a valid calculator state and allow the user to enter a value, select another operator where valid, or clear the calculator.
• Continuation: The user enters the next numeric value and may then evaluate the expression.

FR-04 — Complete an Arithmetic Calculation

As a Calculator User, I should be able to select equals after entering a valid arithmetic expression so that I can view the resulting value.

• Provenance: required_inference
• Access state: Anonymous/public access.
• Trigger or input: The user selects the equals control after entering a valid calculation.
• Required behavior:
  • The system shall evaluate the active arithmetic expression.
  • The system shall display the resulting numeric value in the calculator display.
  • The system shall visually emphasize the equals control as the calculation-completion control.
  • The system shall transition the calculator into a result state that can be cleared, corrected where applicable, or used as the basis for a subsequent calculation.
• Observable result: The Calculator User sees the calculated result in the display.
• Failure and recovery: If the expression cannot be evaluated, including an invalid arithmetic condition, the system shall not present an incorrect result as valid. It shall keep the active state available for correction or clearing.
• Continuation: The user may begin another calculation, select a new operator using the displayed result where supported by the calculation state, correct the entry, or clear the calculator.

FR-05 — Indicate Active Decimal Input

As a Calculator User, I should be able to recognize when decimal input is active so that I can enter a decimal value accurately.

• Provenance: explicit
• Access state: Anonymous/public access.
• Trigger or input: The user activates decimal input while entering a numeric value.
• Required behavior:
  • The system shall use a small yellow registration dot in place of the ordinary decimal-point presentation when decimal input is active.
  • The system shall ensure the yellow registration dot communicates the active decimal state without obscuring the entered number.
• Observable result: The user can identify that the current numeric entry includes active decimal input.
• Failure and recovery: If decimal input is not valid for the active numeric entry, the system shall preserve the last valid entry and allow correction or clearing.
• Continuation: The user continues entering digits, selects an operator, evaluates the expression, corrects the entry, or clears the calculator.

FR-06 — Clear a Calculation

As a Calculator User, I should be able to clear the active calculation so that I can start again.

• Provenance: required_inference
• Access state: Anonymous/public access.
• Trigger or input: The user selects the clear control.
• Required behavior:
  • The system shall remove the active calculation state.
  • The system shall reset any selected arithmetic operator.
  • The system shall return the display to its initial calculator state.
  • The system shall remove any active decimal indicator associated with the cleared value.
• Observable result: The calculator visibly returns to a ready-to-enter state.
• Failure and recovery: If clearing cannot immediately complete, the system shall preserve the last known state until reset is complete and allow the user to retry the clear action.
• Continuation: The user may enter a new numeric value.

FR-07 — Correct the Active Entry

As a Calculator User, I should be able to correct the active entry so that I can recover from an input mistake without restarting the entire calculation.

• Provenance: required_inference
• Access state: Anonymous/public access.
• Trigger or input: The user selects the correction control while an editable numeric entry exists.
• Required behavior:
  • The system shall remove or amend the active input according to the correction control’s defined calculator behavior.
  • The system shall update the display immediately after the correction.
  • The system shall retain valid portions of the current calculation where correction permits.
• Observable result: The display reflects the corrected active entry.
• Failure and recovery: If there is no editable input to correct, the system shall retain the current valid calculator state and keep clear and valid input controls available.
• Continuation: The user may enter replacement digits, choose an operator, complete the calculation, or clear the calculator.

FR-08 — Provide Immediate Interaction Feedback

As a Calculator User, I should receive immediate visual feedback when I select a calculator control so that I can confirm my input.

• Provenance: explicit
• Access state: Anonymous/public access.
• Trigger or input: The user presses a numeric key, operator key, equals key, clear control, or correction control.
• Required behavior:
  • The system shall provide instant key-depression feedback.
  • The system shall invert a pressed key from warm paper to graphite rather than using a lifting effect or soft shadow.
  • The system shall run a 100ms red rule sweep when an operator is selected.
  • The system shall use a precise digit replacement in the display when calculator input changes.
• Observable result: The user sees a direct response corresponding to the selected control.
• Failure and recovery: Interaction feedback shall not imply a successful state change when the input is invalid; the interface shall retain the last valid state and support correction or clearing.
• Continuation: The user continues the active calculator task.

4. User Personas

Calculator User

• Product context: The Calculator User needs immediate, legible arithmetic without distractions.
• Primary goal: Enter a calculation, select an arithmetic operation, and read an accurate displayed result.
• Distinct responsibilities:
  • Enter numeric values using the on-screen keypad.
  • Select an arithmetic operator.
  • Identify the active operation state.
  • Complete a valid calculation using equals.
  • Correct an input mistake or clear the active calculation.
• Relevant inputs and decisions:
  • The numeric digits to enter.
  • Whether decimal input is required.
  • The arithmetic operation to apply.
  • Whether to evaluate, correct, or clear the active calculation.
• Interactions with other accepted participants: None. The calculator is an individual, self-contained tool with no recipient, counterparty, approver, or external participant.
• Observable success: The Calculator User sees the intended numeric result in the display or successfully resets/corrects the calculation and continues.

5. Core User Flows

Flow 1 — Begin and Enter a Number

1. The Calculator User opens the application.
2. The application presents the Calculator page in its initial ready state.
3. The Calculator User selects one or more numeric keypad controls.
4. The Calculator page updates the oversized display with the active numeric value.
5. Each selected key provides an instant pressed-state response by inverting from warm paper to graphite.
6. The Calculator User may continue entering digits, activate decimal input, choose an arithmetic operator, correct the entry, or clear the calculation.

Flow 2 — Calculate an Arithmetic Result

1. The Calculator User enters a first numeric value on the Calculator page.
2. The Calculator User selects an arithmetic operator.
3. The Calculator page marks the selected operator with signal-red emphasis.
4. The Calculator page updates the operation rail and yellow circular operation index.
5. A 100ms red rule sweep confirms the operator selection.
6. The Calculator User enters the next numeric value.
7. The Calculator User selects the vertical signal-red equals control.
8. The application evaluates the active arithmetic expression.
9. The Calculator page replaces the active display value with the calculated result.
10. The Calculator User reads the result and may start another calculation, apply another valid operation, correct the entry where applicable, or clear the calculator.

Flow 3 — Enter a Decimal Value

1. The Calculator User begins entering a numeric value on the Calculator page.
2. The Calculator User activates decimal input.
3. The Calculator page displays the active decimal state using the small yellow registration dot.
4. The Calculator User enters additional digits.
5. The Calculator page updates the display precisely after each accepted digit.
6. The Calculator User continues by selecting an operation, completing the calculation, correcting the entry, or clearing the calculator.
7. If the decimal input is invalid in the active state, the application retains the last valid input and the user can correct or clear the calculation.

Flow 4 — Correct an Entry

1. The Calculator User enters one or more digits and identifies an input mistake.
2. The Calculator User selects the correction control on the Calculator page.
3. The Calculator page updates the active numeric entry to reflect the correction.
4. The Calculator User verifies the corrected value in the display.
5. The Calculator User enters replacement digits, selects an operator, evaluates the calculation, or clears the calculator.
6. If there is no editable entry to correct, the Calculator page retains the valid visible state and keeps calculator controls available.

Flow 5 — Clear a Calculation

1. The Calculator User has an active numeric value, expression, result, or selected operation.
2. The Calculator User selects the clear control.
3. The Calculator page removes the active calculation and operation state.
4. The display returns to its initial ready state.
5. The yellow decimal registration indicator is removed if it was active.
6. The Calculator User begins a new calculation.

Flow 6 — Recover from an Invalid Expression

1. The Calculator User creates or attempts to complete an expression that cannot be evaluated.
2. The application does not present an invalid result as a valid numeric answer.
3. The Calculator page retains the last valid display state or active expression state needed for recovery.
4. The Calculator User selects the correction control to amend the input or selects clear to reset the calculation.
5. The Calculator User continues with a valid entry and may complete the calculation.

6. Visuals Colors and Theme

Muse: Josef Müller-Brockmann
Headline: Swiss arithmetic, made monumental

icy-simple shall present the calculator as a precise graphic instrument: bold, mechanical, legible, and disciplined. The interface itself is the visual composition. Photography, illustration, decorative 3D, soft dashboard modules, and generic SaaS visual conventions are excluded.

Color Tokens

Theme Mode

• Primary mode: Dark graphite environment with a warm-paper calculator slab.
• Background: #161616.
• Calculator slab: #F1EDE3.
• Numerals and rules: #161616.
• Active calculation emphasis: #E63918.
• Operation and decimal marker emphasis: #F6C90E.
• Muted informational detail: #A9A39A.

Typography

• Heading and display family: Archivo, with Archivo Black for monumental numeric display treatment.
• Body and interface family: Space Grotesk.
• Numeral treatment: Tabular figures, tight tracking, high contrast, and stable alignment.
• Type scale: 72px, 48px, 32px, 20px, 16px, 12px.
• Labels: Compact uppercase labels with disciplined spacing.
• Display: A viewport-wide 72px tabular result treatment, clipped at the display edge in the manner of a Swiss concert-poster headline.

Shape and Surface Language

• Hard-edged rectangles only.
• Exact square calculator keys.
• Visible 1px black grid rules around every key.
• Circular operation markers.
• No soft cards.
• No rounded glass surfaces.
• No decorative blobs.
• No blurred surfaces.
• No heavy soft shadows.
• Pressed keys invert from warm paper to graphite rather than lifting from the interface.

Layout

• The Calculator page uses a centered calculator slab on a strict six-column poster grid.
• The graphite field fills the viewport.
• The warm-paper slab occupies approximately 82% of the viewport width.
• A narrow metadata rail sits at the left of the calculator composition.
• The oversized display spans the upper section of the slab.
• The keypad occupies the lower section with a rigid, asymmetric four-column composition.
• Key spans may vary intentionally while preserving visible grid discipline.
• The far-right equals key is a continuous vertical signal-red bar spanning two keypad rows.
• The active operation rail uses an OP / 03-style label with a matching yellow circular index.

Visual Avoidance Rules

The interface shall not use:

• White-background blue SaaS styling.
• Generic indigo or blue-on-white application templates.
• Rounded glass cards.
• Blur effects.
• Floating dashboard tiles.
• Gradient blobs.
• Decorative 3D objects.
• Soft shadow-heavy keypad buttons.
• Friendly cartoon illustration.
• Photography.
• Secondary navigation.

7. Signature Design Concept

The Calculator page opens as a monumental arithmetic poster: a graphite viewport frames one warm-paper calculator slab, while the current result dominates the upper field in oversized black Archivo Black tabular numerals. The result is deliberately clipped against the display grid edge, making the calculator feel like a precise printed composition rather than a conventional utility widget.

Below the display, the keypad forms a strict asymmetric grid of square warm-paper keys with visible black rules. The far-right equals control becomes a single uninterrupted signal-red vertical bar spanning two rows. A thin left metadata rail carries the active-operation label and its yellow circular index. The concept uses only accepted calculator content: display, input keys, operators, decimal state, correction, clearing, and equals.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

The focal subject is the calculator itself: a warm-paper slab on a graphite field, dominated by oversized tabular numerals, black grid rules, a yellow operation index, and a vertical signal-red equals key.

• Input: The Calculator User selects a numeric key, operator, decimal input, correction control, clear control, or equals control.
• Transformation: The selected key depresses instantly by inverting from warm paper to graphite. When an operator is selected, a red rule sweeps across the relevant calculator grid line over 100ms. When a digit or result changes, the display performs a precise replacement rather than a floating, elastic, or theatrical animation.
• Outcome: The calculator display visibly reflects the active numeric entry, selected operation, corrected value, cleared state, or resulting calculation value.
• First frame: The viewport begins with the complete graphite field, warm-paper slab, large clipped result display, left operation rail, yellow marker, rigid keypad grid, and red equals bar already composed in place.
• Reduced-motion state: All calculator content remains fully visible and usable. Key, rule-sweep, and digit-replacement animations are removed or reduced to immediate state changes without transitional movement.

9. Non-Functional Requirements

NFR-01 — Single Contracted Page

• Provenance: explicit
• The delivered custom interface shall contain the contracted Calculator page and shall not introduce additional custom pages, secondary navigation destinations, or multi-page calculator workflows.
• Rationale: The supplied versioned page contract fixes the current page inventory to one Calculator page.

NFR-02 — Anonymous Access

• Provenance: required_inference
• The Calculator page shall be usable without account creation, authentication, identity verification, profile management, or role assignment.
• Rationale: The accepted calculator lifecycle is ephemeral and has no user-specific durable state, entitlement, commitment, or history requirement.

NFR-03 — Immediate Input Feedback

• Provenance: explicit
• Calculator key feedback shall be immediate.
• Operator selection shall use a 100ms red rule sweep.
• Display changes shall use precise digit replacement.
• The interface shall not use floating, elastic, or theatrical motion effects.
• Rationale: The supplied motion direction requires restrained, mechanical feedback.

NFR-04 — Visual Legibility

• Provenance: explicit
• The interface shall use high-contrast graphite, warm paper, black numeral, red emphasis, yellow marker, and muted neutral color roles as specified.
• The calculator shall use Archivo and Archivo Black for headings and large numerals, and Space Grotesk for body and interface text.
• Numeric display styling shall use tabular figures.
• Rationale: The product is intended to support immediate, legible arithmetic.

NFR-05 — Grid Integrity

• Provenance: explicit
• The calculator layout shall use a strict six-column poster grid, a narrow left metadata rail, an oversized display, and a four-column keypad beneath.
• Every key shall have a visible 1px black grid boundary.
• Keys shall be hard-edged and square.
• Rationale: The visual direction requires Müller-Brockmann-inspired grid discipline.

NFR-06 — Accessible Reduced Motion

• Provenance: required_inference
• The calculator shall remain fully usable when motion reduction is requested by the user agent or platform.
• Reduced-motion behavior shall preserve immediate state visibility without requiring animated cues to understand calculator state.
• Rationale: Motion is decorative feedback and cannot be required to operate the calculator.

10. Tech Stack

No implementation technology was specified by the user.

• Client application: React. [Default — not specified by user]
• Styling: CSS with custom design tokens for the supplied palette, grid, typography, motion, and calculator state styling. [Default — not specified by user]
• Calculation logic: Local client-side arithmetic evaluation. [Default — not specified by user]
• Storage: No persistent storage is required for the current accepted scope.
• Backend: No backend service is required for the current accepted calculator functionality.
• Deployment packaging: Docker may be used for consistent static application delivery if deployment packaging is needed. [Default — not specified by user]
• Kubernetes: Not required unless the deployment environment specifically requires it. [Default — not specified by user]

11. Assumptions and Constraints

Assumptions

• [Required inference] Calculator state is ephemeral for the active session and is not required to persist across browser reloads, device changes, or future visits.
• [Required inference] Arithmetic evaluation occurs within the application runtime because no external computation provider is specified or necessary for accepted calculator behavior.
• [Required inference] The Calculator User is the sole participant in each calculation; no recipient, approver, counterparty, or shared outcome is involved.

Constraints

• [Explicit] The final custom page contract contains exactly one page named Calculator.
• [Explicit] The Calculator page must preserve the Swiss arithmetic visual direction: graphite ground, warm-paper slab, black numerals, signal-red calculation