System Requirements Document for incremental-idle

1. Introduction

incremental-idle is an incremental idle pixel game set in a steampunk world. The player tends a growing city that begins as a single small workshop, accumulating Steam as the main currency and progressing toward Aetherite Cores as the prestige currency. The first generator the player acquires is a simple steam machine placed beside the starting workshop.

The product intent is a patient, system-minded idle experience: numbers grow while the player is away, and a pixel-art visual overview of the city assembles itself one generator at a time. The audience is players who return daily to watch a hand-built pixel city grow, and who value legibility, mechanical satisfaction, and affectionate nostalgia over glossy presentation.

The visual and interaction language is authoritative: a Susan Kare–inspired, hand-built pixel aesthetic — aged-paper cream ground, soot-ink text, burnt copper actions, brass gold reserved for Aetherite Cores, chunky 2px ink outlines, Silkscreen headings, IBM Plex Mono data, and frame-by-frame sprite animation.

2. System Overview

The current product is a browser-delivered incremental idle game with application-owned player identity and durable per-player progress. It consists of four first-party pages:

• Landing — anonymous public entry that introduces the steampunk pixel city, Steam, and Aetherite Cores, and offers the path into play.
• Sign Up — self-service enrollment so a new player can begin and persist their own city.
• Login — returning verification for an existing player's durable city progress, Steam, and Aetherite Cores.
• City — the core play surface: a pixel-art visual overview of the growing city with the starting workshop, the first steam machine beside it, idle Steam accumulation, and the Aetherite Cores prestige currency.

Actors. The single active human persona is the Idle City Builder Player. The application backend is a non-persona system actor that persists progress and computes idle Steam accumulation.

Accepted behavior. Steam accumulates from owned generators (beginning with the first steam machine beside the workshop); the player purchases generators that stamp into the city canvas on a fixed grid; the Steam balance ticks up in discrete odometer steps; Aetherite Cores are the prestige currency and receive the only brass-gold treatment in the UI.

Narrow exclusions. No photography, gradients, glassmorphism, blur panels, glossy 3D, or blue/indigo-on-white SaaS styling. No anti-aliased or non-integer-scaled sprites. No additional product capabilities beyond those stated in the authoritative requirement thread and the indispensable identity/persistence mechanics described below.

2a. Product Interpretation and Delivery Boundary

The game is delivered as a first-party web application. Because a player's city, Steam, and Aetherite Cores must survive between sessions and idle accumulation must continue while the player is away, the application owns player identity and durable progress. This is a required inference: without it, the accepted "growing city" and idle-currency lifecycle cannot be resumed by the same player.

Access is therefore split into an anonymous public boundary (Landing, Sign Up, Login) and a protected play boundary (City). The anonymous entry explains the game and its currencies before play begins; enrollment and returning verification establish the identity that binds progress to the correct player. The protected City surface cannot own the interaction that establishes access to itself, so enrollment and verification live on their own access surfaces.

Current scope is the four pages above and the accepted play loop. Future ideas not accepted in the authoritative thread (additional generator types beyond the first steam machine, prestige reset mechanics, offline-progress summaries, social features) are out of current scope and are not represented as pages or requirements.

2b. Source Content Inventory

Not applicable — no reference directive declares a content_source.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Presents the steampunk incremental idle pixel game, its Steam main currency, its Aetherite Cores prestige currency, and the growing-city premise starting from a small workshop with the first steam machine beside it.
• Primary actions: Begin the works (proceed to enrollment); proceed to returning verification.
• Supporting actions: Read the hero vignette and currency chips.
• Domain entities: Steam (puff-cloud icon), Aetherite Cores (faceted brass-ringed crystal icon), workshop sprite, steam-machine sprite.
• Component responsibilities:
  • Hero headline STOKE THE BOILER in Silkscreen caps, flush left in a 9-column measure, soot ink, clamp(40px, 8vw, 96px).
  • Subline A city grows one piston at a time. in IBM Plex Mono beneath the headline.
  • Copper extruded button BEGIN THE WORKS directly under the headline, left-aligned (not centred), with a small brass AETHERITE CORES 0 chip to its right.
  • A single wide pixel-art vignette occupying the lower two-thirds: workshop at left, first steam machine bolted beside it with piston mid-stroke, a thin rail line running off the right edge, a soot-grey sky band with two drifting airship sprites.
  • A secondary text link to returning verification (Login).
• States:
  • Loading: static parchment field with the vignette's resting frame; no spinner theatrics.
  • Empty: not applicable (static public entry).
  • Success: vignette sprite loops run on the 4-frame 480ms cycle; airships drift.

• Error: not applicable to static content; navigation failures surface as a plain inline message with a retry link.
• Recovery: reduced-motion freezes sprite loops to a single resting frame; all text and controls remain whole and readable at 375px, 768px, and 1280px.

Sign Up

• Information/state: Self-service enrollment for a new player so they can begin and persist their own city progress. Anonymous access.
• Primary actions: Create the player's identity and enter the City with a fresh city (small workshop plus the first steam machine beside it).
• Supporting actions: Return to Landing; switch to Login for an existing player.
• Domain entities: Player identity; initial city state (workshop, first steam machine, Steam balance, Aetherite Cores balance).
• Component responsibilities:
  • Micro-label in 12px uppercase Silkscreen with 0.08em tracking above the form panel, paired with a 1px dotted rule.
  • Enrollment form fields with 2px ink outlines, hard 0–4px corners, IBM Plex Mono labels.
  • Extruded 3px press-down submit button in burnt copper.
  • Link to Login.
• States:
  • Loading: submit button shows a pressed/stamped state; form fields disabled.
  • Empty: blank form with labels and helper text.
  • Success: player is taken to the City with a freshly initialized city.
  • Error: inline field-level and form-level messages in soot ink on parchment; the form retains entered values.
  • Recovery: the player can correct and resubmit, or switch to Login.

Login

• Information/state: Returning verification for an existing player's durable city progress, Steam, and Aetherite Cores. Anonymous access.
• Primary actions: Verify the returning player and resume their City.
• Supporting actions: Return to Landing; switch to Sign Up for a new player.
• Domain entities: Player identity; persisted city state.
• Component responsibilities:
  • Micro-label and dotted rule above the verification panel.
  • Verification fields with 2px ink outlines.
  • Extruded 3px press-down submit button in burnt copper.
  • Link to Sign Up.
• States:
  • Loading: submit button pressed/stamped; fields disabled.
  • Empty: blank form.
  • Success: player is taken to the City with their persisted progress restored.
  • Error: inline message that verification did not succeed; entered values retained.
  • Recovery: retry, or switch to Sign Up.

City

• Information/state: The core play surface. A pixel-art visual overview of the growing city with the starting workshop and the first steam machine beside it, the Steam balance, Steam/sec, and the Aetherite Cores balance. Protected — requires login.
• Primary actions: Purchase generators (starting with the first steam machine) that stamp into the city canvas on a fixed grid slot with a 2-frame brass flash.
• Supporting actions: Read Steam balance and Steam/sec; read Aetherite Cores; observe sprite loops.
• Domain entities: City (grid of placed sprites), Workshop (starting structure), Steam Machine (first generator), Steam (main currency), Steam/sec (rate), Aetherite Cores (prestige currency), generator tiles (parts-catalogue entries with name, owned count, Steam/sec, cost).
• Component responsibilities:
  • City canvas panel (wide left column at 1280px, first at 375px): fixed-aspect pixel overview, scrollable at small sizes, sprites on a strict 16px grid upscaled with image-rendering: pixelated; workshop and steam machine loop on a 4-frame 480ms piston cycle.
  • Steam balance: Silkscreen, largest type on the screen, clamp(28px, 6vw, 56px), burnt copper, tabular figures, odometer-style discrete tick.
  • Aetherite Cores chip: the only brass-gold treatment in the UI, with the faceted brass-ringed crystal icon.
  • Generator rail (360px right rail at 1280px; horizontally scrollable strip with snap points at 375px): tiles styled as a parts catalogue — 2px ink outline, dotted leader rule between name and cost, tabular Steam/sec numerals, extruded 3px press-down purchase button.
  • Sticky bottom command rail at 375px: Steam total, Steam/sec, and the cheapest affordable generator as a single pressable strip.

• Micro-label system: 12px uppercase Silkscreen with 0.08em tracking above every panel, paired with a 1px dotted rule.
• States:
  • Loading: parchment surface with the city canvas at its resting frame and the Steam balance showing the last known value; generator tiles in a skeleton outline.
  • Empty: not applicable — the city always begins with the workshop and the first steam machine.
  • Success: Steam ticks up in discrete steps; purchases stamp in with a 2-frame brass flash; sprite loops run.
  • Error: if a purchase or progress sync fails, an inline message appears in soot ink with a retry control; the Steam balance and city state remain at their last confirmed values.
  • Recovery: retry the failed action; reduced-motion freezes sprite loops to a single resting frame and lets counters update without the flash; all counters and buttons wrap inside their tiles at 375px, 768px, and 1280px.

3. Functional Requirements

FR-1 — Steampunk incremental idle pixel game (explicit) As an Idle City Builder Player, I should play an incremental idle pixel game set in a steampunk world, so that I can watch a pixel city grow over time.

• Lifecycle: Initiator: player. Trigger: opening the game. Observable result: a pixel-art steampunk city surface with idle accumulation. Failure/recovery: if the surface fails to load, an inline message with retry. Continuation: the player returns to the City to keep playing.
• Acceptance: The game presents a pixel-art steampunk setting and idle accumulation as its core loop.

FR-2 — Steam as main currency (explicit) As an Idle City Builder Player, I should accumulate Steam as the main currency, so that I can spend it on generators.

• Lifecycle: Initiator: player (by owning generators). Trigger: idle time and generator ownership. Observable result: the Steam balance increases in discrete odometer steps. Failure/recovery: if progress sync fails, the balance holds at its last confirmed value with a retry. Continuation: the player spends Steam on generators.
• Acceptance: Steam is displayed as the largest type on the City screen and increases over time from owned generators.

FR-3 — Aetherite Cores as prestige currency (explicit) As an Idle City Builder Player, I should see Aetherite Cores as the prestige currency, so that I understand the long-term progression target.

• Lifecycle: Initiator: player. Trigger: viewing the City. Observable result: an Aetherite Cores balance rendered with the only brass-gold treatment in the UI and the faceted brass-ringed crystal icon. Failure/recovery: if the balance cannot be loaded, the chip shows its last confirmed value with a retry. Continuation: the player continues building toward prestige.
• Acceptance: Aetherite Cores are visibly distinct from Steam and labelled as the prestige currency.

FR-4 — Visual overview of the growing city (explicit) As an Idle City Builder Player, I should see a visual overview of my growing city, so that I can watch it assemble itself.

• Lifecycle: Initiator: player. Trigger: opening the City. Observable result: a pixel-art city canvas showing placed structures on a fixed grid. Failure/recovery: if the canvas fails to load, an inline message with retry. Continuation: the player purchases generators that stamp into the canvas.
• Acceptance: The City screen presents a pixel-art visual overview of the city that reflects owned structures.

FR-5 — City starts with a small workshop (explicit) As an Idle City Builder Player, I should start with a small workshop in my city, so that I have a visible home base from the first moment.

• Lifecycle: Initiator: system on first entry to the City. Trigger: a new player's city initialization. Observable result: a workshop sprite (squat brick shed with a crooked chimney) placed on the city canvas. Failure/recovery: if initialization fails, the player is returned to the entry with a retry. Continuation: the player acquires the first steam machine beside it.
• Acceptance: Every new city contains exactly one starting workshop.

FR-6 — First generator is a simple steam machine beside the workshop (explicit) As an Idle City Builder Player, I should acquire a simple steam machine as my first generator, placed beside my workshop, so that Steam begins to accumulate.

• Lifecycle: Initiator: player. Trigger: purchasing the first steam machine from the generator rail. Observable result: a riveted copper boiler sprite with a visible piston stamps into the canvas beside the workshop with a 2-frame brass flash; Steam/sec increases. Failure/recovery: if the purchase fails, an inline message with retry and the Steam balance unchanged. Continuation: the player watches Steam accumulate and may purchase further generators.
• Acceptance: The first generator is a steam machine, it is placed beside the workshop, and owning it increases Steam/sec.

FR-7 — Self-service enrollment for a new player (required_inference) As an Idle City Builder Player, I should be able to enroll myself on Sign Up, so that I can begin and persist my own city progress.

• Lifecycle: Initiator: player. Trigger: choosing to begin the works from Landing. Observable result: a player identity is established and a fresh city (workshop plus first steam machine) is created and bound to that identity. Failure/recovery: inline field and form errors; the player corrects and resubmits or switches to Login. Continuation: the player enters the City.
• Acceptance: A new player can complete enrollment and arrive at the City with a fresh city bound to their identity.

FR-8 — Returning verification for an existing player (required_inference) As an Idle City Builder Player, I should be able to verify myself on Login, so that I can resume my durable city progress, Steam, and Aetherite Cores.

• Lifecycle: Initiator: player. Trigger: choosing returning verification from Landing. Observable result: the player's persisted city, Steam, and Aetherite Cores are restored on the City. Failure/recovery: inline message that verification did not succeed; retry or switch to Sign Up. Continuation: the player resumes play.
• Acceptance: A returning player can verify and see their previously persisted progress restored.

FR-9 — Durable persistence of city progress, Steam, and Aetherite Cores (required_inference) As an Idle City Builder Player, I should have my city progress, Steam, and Aetherite Cores persisted, so that my progress survives between sessions and idle time.

• Lifecycle: Initiator: system on behalf of the player. Trigger: state changes (purchases, idle accumulation) and session boundaries. Observable result: the player's city, Steam, and Aetherite Cores are restored on return. Failure/recovery: if a sync fails, the UI holds the last confirmed values and offers retry. Continuation: the player continues from their persisted state.
• Acceptance: Progress made in one session is present in the next session for the same player.

4. User Personas

Idle City Builder Player

Product context. A patient, system-minded player who returns daily to an incremental idle pixel game. They are drawn to the mechanical satisfaction of watching numbers grow and a pixel city assemble itself, and to the affectionate nostalgia of a hand-built pixel aesthetic. They play in short, frequent sessions and expect the game to keep working while they are away.

Primary goal. Grow a steampunk pixel city from a small workshop into something larger, accumulating Steam and progressing toward Aetherite Cores.

Distinct accepted responsibilities.

• Entering the game through the anonymous Landing and choosing to begin the works or to verify as a returning player.
• Enrolling on Sign Up to establish their own persistent city.
• Verifying on Login to resume their durable progress.
• On the City, reading the Steam balance and Steam/sec, purchasing generators beginning with the first steam machine beside the workshop, and watching the city canvas grow.
• Reading the Aetherite Cores prestige balance.

Relevant inputs or decisions. Whether to begin the works or verify as returning; enrollment and verification details; which generator to purchase and when it is affordable.

Interactions with other accepted participants. The player is the only active human participant. The application backend persists their progress and computes idle Steam accumulation on their behalf; the player observes the results on the City.

Observable success. The Steam balance ticks upward in discrete steps, the first steam machine appears beside the workshop with a brass flash, and on return the player's city, Steam, and Aetherite Cores are exactly as they left them.

What makes this role distinct. The player's work is one of patient observation and periodic commitment — reading a growing number and deciding when to spend it — rather than of administration, configuration, or multi-role collaboration. Their success is measured in the visible growth of a single city they privately own.

5. Core User Flows

Flow A — A new player begins the works

1. The player arrives at the anonymous Landing page. They see the Silkscreen headline STOKE THE BOILER, the subline A city grows one piston at a time., the copper BEGIN THE WORKS button, the brass AETHERITE CORES 0 chip, and the pixel vignette of the workshop and steam machine with drifting airships.
2. The player selects BEGIN THE WORKS and is taken to Sign Up.
3. On Sign Up, the player completes the enrollment form and submits. The submit button shows its pressed/stamped state while the request is in flight.
4. On success, the application establishes the player's identity and initializes a fresh city: one small workshop and the first steam machine beside it, with a Steam balance and an Aetherite Cores balance of 0.
5. The player arrives at the protected City page. The city canvas shows the workshop and the steam machine on the fixed grid; the Steam balance is the largest type on the screen; the Aetherite Cores chip shows 0 in brass gold.
6. Failure/recovery: if enrollment fails, inline messages appear in soot ink on parchment and the entered values are retained; the player corrects and resubmits, or follows the link to Login.
7. Continuation: the player proceeds to Flow C.

Flow B — A returning player resumes their city

1. The player arrives at the anonymous Landing page and follows the returning-verification link to Login.
2. On Login, the player enters their verification details and submits. The submit button shows its pressed/stamped state while the request is in flight.
3. On success, the application restores the player's persisted city, Steam, and Aetherite Cores and takes them to the City.
4. The player sees their city canvas as they left it, their Steam balance, and their Aetherite Cores balance.
5. Failure/recovery: if verification does not succeed, an inline message appears and the entered values are retained; the player retries, or follows the link to Sign Up.
6. Continuation: the player proceeds to Flow C.

Flow C — The player grows the city and accumulates Steam

1. On the City, the player reads the Steam balance (Silkscreen, largest type, burnt copper, tabular figures) and the Steam/sec rate. The balance ticks up in discrete odometer steps as idle accumulation proceeds.
2. The player reads the generator rail — tiles styled as a parts catalogue with a 2px ink outline, a dotted leader rule between name and cost, tabular Steam/sec numerals, and an extruded 3px press-down purchase button.
3. When the first steam machine is affordable, the player presses its purchase button. The button presses down 3px; on success the steam-machine sprite stamps into the city canvas on its fixed grid slot beside the workshop with a 2-frame brass flash, and the Steam/sec rate increases.
4. The player watches the workshop and steam machine sprites loop on the 4-frame 480ms piston cycle, and the Steam balance continue its discrete tick.
5. Failure/recovery: if the purchase fails, an inline message appears in soot ink with a retry control, and the Steam balance remains at its last confirmed value. If progress sync fails, the UI holds the last confirmed values and offers retry.
6. Continuation: the player may purchase further generators as they become affordable, and returns later to find their progress persisted.

Flow D — The player plays one-thumbed at 375px

1. On a narrow viewport, the City stacks: the city canvas first, then a horizontally scrollable generator strip with snap points, then the Steam total pinned as a sticky bar.
2. The sticky bottom command rail shows the Steam total, Steam/sec, and the cheapest affordable generator as a single pressable strip.
3. The player presses the strip to purchase the cheapest affordable generator; the purchase stamps into the canvas with the 2-frame brass flash.
4. Failure/recovery: if the purchase fails, an inline message appears with retry; the strip remains pressable.
5. Continuation: the player continues idle play one-thumbed.

Flow E — The player uses reduced motion

1. With prefers-reduced-motion active, the City freezes all sprite loops to a single resting frame and lets counters update without the brass flash.
2. The player still reads the Steam balance, Steam/sec, Aetherite Cores, and the generator rail, and can still purchase generators.
3. Continuation: the player continues play with a usable static arrangement.

6. Visuals Colors and Theme

Muse and headline. Susan Kare for a steampunk idle city — Charming clarity, one pixel at a time.

Mode. Light mode only.

Palette (exact hex by role).

• Background — aged-paper cream #F2E7D0 (~60% of the screen).
• Surface — lighter parchment #FBF4E4 for panels and tiles (~25%).
• Text — soot ink #241C14 for all copy.
• Primary — burnt copper #B4531E for primary actions and the Steam-number colour.
• Accent — brass gold #E8B23A, the single hot accent reserved for Aetherite Cores, prestige glows, and the active generator's pulse.
• Muted — umber #7A6A55 for labels, rules, and secondary metadata.
• Sprite-only support — verdigris #4E7C6A and deep iron #3A3F45.

Never blue-on-white; the generic indigo/blue-on-white SaaS template is forbidden.

Typography.

• Headings: Silkscreen at 700 for wordmark, section titles, and big Steam numerals; bitmap-locked, all-caps for labels, wide 0.08em tracking on micro-labels.
• Body and data: IBM Plex Mono 400/600 at generous 1.65 line-height so dense idle stats stay calm.
• Numbers use tabular figures; the Steam counter is the largest type on the City screen.
• Scale: 1.25 modular — 12 / 15 / 19 / 24 / 32 / 44 / 64; display clamp(40px, 8vw, 96px) for the landing headline; Steam balance clamp(28px, 6vw, 56px); labels fixed 12px uppercase.

Shape language. Chunky 2px ink outlines on every panel and tile; hard 0px-to-4px corners (pixel-honest, no soft radii above 4px); 1px dotted rules between data rows; a visible 8px baseline grid implied by tile gutters. Buttons are extruded 3px down-right in a darker shade of their fill so they look physically pressed — the only "3D" in the system. Sprites are drawn on a strict 16px grid, upscaled with image-rendering: pixelated.

Layout. Two-column play layout at 1280px: a wide left city-canvas panel (fixed aspect, scrollable at small sizes) and a 360px right rail of generator tiles stacked like a parts catalogue, each tile a label/value pair (name, owned count, Steam/sec, cost) in Kare-tidy rows. Landing is a single centred column of 9 columns max with the workshop-and-steam-machine sprite pair as the hero artefact. At 375px everything stacks: city canvas first, then a horizontally scrollable generator strip with snap points, then the Steam total pinned as a sticky bar. Nothing overlaps; all counters and buttons wrap inside their tiles.

Imagery. Hand-drawn pixel sprites on a 16px grid: the starting workshop (a squat brick shed with a crooked chimney), the first steam machine (a riveted copper boiler with a visible piston), then gears, pipes, airships, aetherite crystal clusters. Environment drawn as a flat isometric-ish ground band of cobbles and rails with a soot-grey sky strip. Icon set for Steam (a puff cloud), Aetherite Cores (a faceted brass-ringed crystal), and each generator, all in the same chunky-outline style. No photography, no gradients, no glossy 3D.

Readability rule. Readable text and controls stay whole at every viewport: headlines, wordmarks, labels, numbers, cards' text and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, as long as it covers no readable text or control. Moving and scrollable content (marquees, tickers, carousels, horizontally scrollable rows) may cross the viewport or container edge by design; every item becomes fully readable as it passes. With prefers-reduced-motion, provide a usable static arrangement: wrap items into rows or allow horizontal scrolling so each item can be brought fully into view.

7. Signature Design Concept

The live pixel city canvas as the hero artefact.

The Landing first screen is a cream parchment field with a single wide pixel-art vignette occupying the lower two-thirds: the small workshop at left, the first steam machine bolted beside it with its piston mid-stroke, a thin rail line running off the right edge, and a soot-grey sky band with two drifting airship sprites. Above it, flush left in a 9-column measure, Silkscreen caps read STOKE THE BOILER at clamp(40px, 8vw, 96px) in soot ink, with the line A city grows one piston at a time. in IBM Plex Mono beneath. A copper extruded button BEGIN THE WORKS sits directly under the headline, not centred, with a small brass AETHERITE CORES 0 chip to its right.

The signature moves carry through the product:

• Live pixel city canvas: workshop and steam machine sprites loop on a 4-frame piston cycle, and each purchased generator stamps into the canvas on a fixed grid slot with a 2-frame brass flash.
• Generator tiles as a parts catalogue: 2px ink outline, dotted leader rule between name and cost, tabular Steam/sec numerals, and an extruded 3px press-down purchase button.
• Steam balance in Silkscreen as the largest type on the City screen with an odometer-style discrete tick, while Aetherite Cores get the only brass-gold treatment in the entire UI.
• Sticky bottom command rail at 375px showing Steam total, Steam/sec, and the cheapest affordable generator as a single pressable strip, so idle play works one-thumbed.
• Micro-label system in 12px uppercase Silkscreen with 0.08em tracking above every panel, paired with a 1px dotted rule — the Kare system-UI cue applied to steampunk instrumentation.

No gradient blobs, no centred stack, no blue.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject: the workshop-and-steam-machine sprite pair in the lower two-thirds vignette, with the piston mid-stroke and two airship sprites drifting in the soot-grey sky band.
• Input → transformation → outcome thesis: the player's arrival (input) meets a city already breathing — the piston cycles, the airships drift (transformation) — and the copper BEGIN THE WORKS button invites them to set the first machine in motion (outcome), without any motion that implies behavior the game does not have.
• Motion vocabulary: frame-by-frame, no easing theatrics; sprites animate on a 4-frame, 480ms loop (piston up/down, gear turn, steam puff drifting); numbers tick up in discrete steps rather than smooth interpolation, like an odometer; purchases stamp in with a 2-frame flash of brass gold; hover states are instant colour inversions, not lifts.
• Composed first frame: cream parchment field; flush-left Silkscreen headline STOKE THE BOILER; IBM Plex Mono subline; copper extruded BEGIN THE WORKS button with the brass AETHERITE CORES 0 chip to its right; the vignette below with the workshop at left, the steam machine beside it, the rail line running off the right edge, and the soot-grey sky band with two airships.
• Reduced-motion state: all sprite loops freeze to a single resting frame; counters update without the brass flash; the vignette remains fully composed and readable.

9. Non-Functional Requirements

• Pixel-art visual style (explicit). All sprites are drawn on a strict 16px grid and upscaled with image-rendering: pixelated; no anti-aliased or non-integer-scaled sprites. Rationale: the authoritative thread requires a pixel game, and the creative direction forbids blurred pixel grids.
• Steampunk setting (explicit). The visual and copy language is steampunk — brass, soot, copper, riveted boilers, airships, aetherite crystals. Rationale: explicit hard constraint.
• Incremental idle game genre (explicit). Steam accumulates over time from owned generators, including while the player is away, and the player returns to find progress persisted. Rationale: explicit hard constraint plus the durable-persistence requirement.
• Durable persistence (required_inference). City progress, Steam, and Aetherite Cores are persisted per player and restored on return. Rationale: the accepted growing-city and idle-currency lifecycle cannot be resumed otherwise.
• Application-owned identity (required_inference). Enrollment and returning verification bind progress to the correct player; the City is protected and the access surfaces are anonymous. Rationale: progress must remain bound to the correct participant.
• Readable text and controls at every viewport (explicit). Headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px; no other element covers any part of them. Rationale: explicit readability rule in the creative direction.
• Reduced-motion support (explicit). With prefers-reduced-motion, sprite loops freeze to a single resting frame, counters update without the flash, and scrollable rows remain usable. Rationale: explicit motion rule in the creative direction.

• No forbidden visual treatments (explicit). No blue/indigo-on-white SaaS styling, no smooth gradients, glassmorphism, blur panels, glossy 3D, soft rounded cards with hover-lift shadows, photographic or stock imagery, Inter/Roboto/Poppins/system-ui for headings or body, or pixel type for long body copy or dense stat tables. Rationale: explicit "Avoid" list in the creative direction.

10. Tech Stack

• Frontend: React (web) with a pixel-art rendering approach that preserves the 16px grid and image-rendering: pixelated upscaling. [Default — not specified by user]
• Backend: Python / FastAPI, extending a single shared backend process for identity, progress persistence, and idle Steam accumulation. [Default — not specified by user]
• Storage: A relational database for player identity and durable city progress (city grid, owned generators, Steam, Aetherite Cores). [Default — not specified by user]
• Deployment: Docker / docker-compose with the frontend and backend as the runnable services. [Default — not specified by user]
• Fonts: Silkscreen (headings) and IBM Plex Mono (body and data), as specified by the creative direction.

11. Assumptions and Constraints

• Assumption — single active persona. The only active human role is the Idle City Builder Player; the application backend is a non-persona system actor. (required_inference)
• Assumption — application-owned identity. Because progress must survive between sessions and idle time, the application owns player identity and durable progress; enrollment and returning verification are journey prerequisites, not adjacent account-management capabilities. (required_inference)
• Assumption — protected City. The City is protected and the access surfaces (Landing, Sign Up, Login) are anonymous; the protected destination does not own the interaction that establishes access to itself. (required_inference)
• Assumption — first generator only. The authoritative thread names only the first steam machine as a generator; additional generator types are not current scope. (explicit boundary)
• Assumption — prestige currency display only. Aetherite Cores are the prestige currency and are displayed with the brass-gold treatment; no prestige reset mechanic is specified in the authoritative thread and none is added. (explicit boundary)
• Constraint — pixel art, steampunk, incremental idle. These are hard constraints from the authoritative thread and are not negotiable. (explicit)
• Constraint — creative direction is authoritative for palette, typography, shape language, layout, motion, imagery, and the signature concept. (explicit)
• Constraint — no blue/indigo-on-white SaaS template. Forbidden for this project. (explicit)

12. Glossary

• Steam — the main currency of the game, accumulated over time from owned generators and spent on generators.
• Aetherite Cores — the prestige currency of the game, rendered with the only brass-gold treatment in the UI.
• City — the player's growing pixel-art settlement, shown as a visual overview on the City page.
• Workshop — the starting structure of every city: a squat brick shed with a crooked chimney.
• Steam Machine — the first generator: a riveted copper boiler with a visible piston, placed beside the workshop.
• Generator — a purchasable structure that increases Steam/sec and stamps into the city canvas on a fixed grid slot.
• Steam/sec — the rate at which Steam accumulates from owned generators.
• Idle accumulation — Steam accruing over time, including while the player is away, and persisted between sessions.
• Parts catalogue — the generator rail's tile styling: 2px ink outline, dotted leader rule between name and cost, tabular Steam/sec numerals, extruded 3px press-down purchase button.
• Odometer tick — the discrete, non-interpolated step by which the Steam balance increases.
• Brass flash — the 2-frame brass-gold flash with which a purchased generator stamps into the city canvas.
• Micro-label — the 12px uppercase Silkscreen label with 0.08em tracking above every panel, paired with a 1px dotted rule.
• Sticky command rail — the 375px bottom strip showing Steam total, Steam/sec, and the cheapest affordable generator as a single pressable strip.