System Requirements Document for small-town-cult

1. Introduction

small-town-cult is a browser-based narrative management game set in a small town in the middle of nowhere America. The player is a stranded traveller whose car breaks down on the edge of town and who is rescued by girls in a horse and buggy. The town turns out to be mostly a cult; its very old leader hands the keys to his throne to the player, recognizing that the population needs fresh DNA. From that point the player inherits leadership of an isolated commune and must keep it alive and its many members happy.

The game follows the structure of narrative management games such as Secretary and Apocalyptic World: a persistent status rail carrying the game's state (day, meters, counters, action log) beside a narrative passage area where the player makes choices that change the world. All content is original to this project; the reference sites are used only as structural and feature-format inspiration and contribute no names, copy, facts, or capabilities.

The audience is adult narrative-fiction players who enjoy slow-burn, morally uneasy power fantasies: rural dread, claustrophobia, dark humour, and charismatic authority. The game is deliberately non-explicit: relationships between characters can produce offspring and grow the population, but no overt sexual acts are depicted and no pornographic media is used.

This document is the System Requirements Document requested by Brandon for the project small-town-cult.

Success Criteria

• A new player can land on the game, understand the premise (stranded traveller, rescue, inheritance of leadership), enroll, and begin a commune save.
• A returning player can verify identity and resume their exact commune state — day, morale, belief, population, food, and action log.
• Each day the player can commit exactly one daily action: personally perform one commune activity, or delegate work to cult members.
• Weekly rituals are available and materially affect member happiness and belief in the player's "chosen one" status.
• The player can issue childrearing instructions, train defenders, and develop relationships that grow the population — all without any explicit sexual content.
• The commune's morale, belief, population, and food remain legible at a glance in the persistent status rail on desktop, tablet, and mobile.

2. System Overview

small-town-cult is delivered as a web game with three provisioned services: a React frontend, a shared FastAPI backend that hosts all application APIs and domain modules, and a MariaDB database holding application-owned persistent data. The backend is the single process for game state, identity, and all domain logic; no separate services are introduced.

The game is played by the Cult Leader (Player), who holds application-owned identity and durable commune state. The Cult Member and Cult Defender are accepted active human personas whose work is represented inside the leader's management surfaces: members carry out delegated tasks, participate in rituals, form relationships, and raise children per the leader's instructions; defenders are trained and hold the encampment's readiness. Their responses are surfaced to the leader as observable outcomes (task completion, morale shifts, belief changes, relationship and offspring events, defense readiness) within the leader's pages.

Current behavior covers: the anonymous landing premise, self-service enrollment and returning verification, the day-by-day commune hub, personal daily action, task delegation across farming, machine maintenance, animal husbandry, cooking, cleaning, and hunting, morale and belief management, weekly rituals, childrearing instructions, defender training, and non-explicit relationships that produce offspring and grow the population.

2a. Product Interpretation and Delivery Boundary

The game is a first-party web application. The anonymous Landing page presents the premise and routes a visitor to Sign Up or Login. Identity is application-owned: a player enrolls once, and their commune save — day, meters, counters, relationships, children, defenders, and action log — is bound to that identity and resumed on return. Only the Landing, Sign Up, and Login surfaces are reachable without identity; every gameplay surface requires login.

All gameplay is rendered and controlled in the first-party React application, with the FastAPI backend as the authority for game state and MariaDB as the durable store. There are no provider-owned gameplay surfaces, no external destinations for play, and no headless delivery. The reference sites inform only the narrative-management format (persistent status rail, passage-and-choice reading, meters and counters, action log); they supply no product content.

The current delivery horizon covers the full accepted loop described above. Nothing beyond that loop — no additional modules, marketplaces, or account-management features — is part of this release.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Full-bleed ink-black field with the stacked Anton headline "THEY FOUND YOU ON THE ROAD"; a bone-cream subline about the town; a thin mustard rule across the top holding the town name in 11px tracked caps; a duotone barn-wood crop tucked into the lower-right corner under a 30%-opacity Anton overprint.
• Primary actions: Enter the sign-in slab (rising diagonal red band) to go to Sign Up; a secondary link to Login for returning players.
• Supporting actions: None beyond navigation to the two identity surfaces.
• Domain entities: None persisted; premise copy only.
• Component responsibilities: Hero headline block (three stacked lines, middle line outline and rotated -4deg, bleeding past the right edge as decoration only); sign-in slab; subline; top rule with town name; corner duotone crop.
• States: Loading (static hero, no data dependency); empty (n/a); success (navigation to Sign Up or Login); error (n/a); recovery (n/a). Reduced motion: headline appears instantly, no word-by-word stagger.

Sign Up

• Information/state: Self-service enrollment form for a player starting a new commune save. Fields for identity credentials; a short confirmation of what enrollment creates (a new commune save).
• Primary actions: Submit enrollment; on success, proceed to the new commune save.
• Supporting actions: Link to Login for players who already have a save.
• Domain entities: Player identity; new commune save record.
• Component responsibilities: Enrollment form; validation messaging; submit slab; link to Login.
• States: Loading (submit in progress); empty (blank form); success (save created, route to Commune); error (invalid or taken credentials, with inline recovery); recovery (retry without losing entered fields where possible).

Login

• Information/state: Returning verification form for a player resuming durable commune state.
• Primary actions: Submit credentials; on success, resume the player's commune save.
• Supporting actions: Link to Sign Up for new players.
• Domain entities: Player identity; existing commune save.
• Component responsibilities: Verification form; error messaging; submit slab; link to Sign Up.
• States: Loading (verification in progress); empty (blank form); success (route to Commune with restored state); error (invalid credentials, with recovery); recovery (retry).

Commune

• Information/state: Day-by-day hub. Persistent left poster-rail (280px desktop; top strip at 768px; bottom tab bar at 375px) showing day/season stamp, belief and morale meters as filled bars with tabular numerals, population and food counters, and the ruled action log. Main area: narrative passage in an 8-column measure, a slow marquee ticker of town gossip along the top, and the day's committed action summary.
• Primary actions: Advance the day by committing the day's action (routing to Daily Action or Tasks); open any tab (Daily Action, Tasks, Morale, Rituals, Childrearing, Defense, Lineage).
• Supporting actions: Read the action log; read the gossip ticker.
• Domain entities: Commune save; day/season; belief; morale; population; food; action log entries.
• Component responsibilities: Poster-rail (day stamp, meters, counters, ledger); narrative passage; gossip ticker; day-advance control; tab navigation.
• States: Loading (rail skeleton, passage placeholder); empty (first day of a new save with no log entries); success (day committed, rail and passage update); error (day commit failed, with retry); recovery (retry preserves the pending choice). Reduced motion: ticker becomes a static wrapped line.

Daily Action

• Information/state: Focused owner for the leader personally performing one commune activity for the current day. Lists the six activities — farming, machine maintenance, animal husbandry, cooking, cleaning, hunting — with the personal cost and consequence of each, and a clear note that most tasks are better left to members.
• Primary actions: Select one activity and commit it as the day's personal action.
• Supporting actions: Return to Commune without committing; open Tasks to delegate instead.
• Domain entities: Activity; day; personal action record; resulting meter and counter changes.
• Component responsibilities: Activity slabs (verb in Anton caps, consequence in Archivo); commit control; delegation nudge.
• States: Loading (activity list); empty (no activities available this day, with explanation); success (action committed, consequence shown, return to Commune); error (commit failed, with retry); recovery (retry preserves selection).

Tasks

• Information/state: Delegation owner for farming, machine maintenance, animal husbandry, cooking, cleaning, and hunting. Shows each task, which member is assigned, and the expected outcome; reflects the leader's encouragement to leave most work to members.
• Primary actions: Assign a task to a cult member for the day.
• Supporting actions: Reassign before the day is committed; return to Commune.
• Domain entities: Task; cult member; assignment; expected yield or upkeep effect.
• Component responsibilities: Task list; member assignment control; expected-outcome display; delegation summary.
• States: Loading (task and member lists); empty (no members available to assign, with explanation); success (assignment recorded, member response shown); error (assignment failed, with retry); recovery (retry preserves assignment).

Morale

• Information/state: Overview of cult morale and belief in the leader's authority. Shows current morale and belief values, recent shifts with causes, and member sentiment.
• Primary actions: Review morale and belief; identify what is dragging them down.
• Supporting actions: Navigate to Rituals or Tasks to address causes.
• Domain entities: Morale; belief; sentiment events.
• Component responsibilities: Meter displays with tabular numerals; shift history; cause annotations.
• States: Loading (meters and history); empty (no shifts recorded yet); success (current values and history); error (load failed, with retry); recovery (retry).

Rituals

• Information/state: Weekly ritual owner. Shows the weekly ritual countdown in mustard, the ritual due this week, and the effect of performing it on member happiness and belief in the "chosen one" status.
• Primary actions: Perform the week's ritual.
• Supporting actions: Review the ritual's expected effect before performing; return to Commune.
• Domain entities: Ritual; week; happiness effect; belief effect; ritual record.
• Component responsibilities: Countdown; ritual description; perform control; effect preview; result display.
• States: Loading (ritual state); empty (no ritual due this week, with explanation); success (ritual performed, effects applied and shown); error (ritual failed, with retry); recovery (retry preserves the pending ritual).

Childrearing

• Information/state: Owner for issuing instructions to cult members on raising the commune's children. Lists the commune's children and the current instruction set applied to their upbringing.
• Primary actions: Issue or change childrearing instructions for members.
• Supporting actions: Review the effect of instructions on morale and belief; return to Commune.
• Domain entities: Child; childrearing instruction; member; effect on morale and belief.
• Component responsibilities: Child list; instruction editor; effect preview; confirmation.
• States: Loading (children and instructions); empty (no children in the commune yet, with explanation); success (instructions recorded, member acknowledgement shown); error (save failed, with retry); recovery (retry preserves edits).

Defense

• Information/state: Owner for training cult defenders and tracking readiness against strangers. Shows defender roster, training state, and encampment readiness.
• Primary actions: Train a cult defender; review readiness.
• Supporting actions: Return to Commune.
• Domain entities: Cult defender; training; readiness.
• Component responsibilities: Defender roster; training control; readiness display; training result.
• States: Loading (roster and readiness); empty (no defenders yet, with explanation); success (training recorded, readiness updated); error (training failed, with retry); recovery (retry preserves selection).

Relationships

• Information/state: Owner for character relationships that develop and produce offspring, growing the population non-explicitly. Shows relationship pairs, their state, and offspring outcomes. Presented under the Lineage tab with dusty violet-grey category coding.
• Primary actions: Encourage or develop a relationship between characters.
• Supporting actions: Review lineage and offspring; return to Commune.
• Domain entities: Relationship; character pair; offspring; population change.
• Component responsibilities: Relationship list; pair detail; offspring record; population counter link.
• States: Loading (relationships and lineage); empty (no relationships formed yet, with explanation); success (relationship advanced, offspring recorded, population updated); error (action failed, with retry); recovery (retry preserves selection). All content is non-explicit; no sexual acts are depicted.

3. Functional Requirements

FR-1 — Web narrative management game. As a Cult Leader (Player), I should play a web-based small-town cult-management simulation structured like narrative management games (persistent status rail beside a passage-and-choice area), so that I can manage the commune through readable narrative choices. Provenance: explicit. Lifecycle: trigger — player opens the game; result — the game renders with the status rail and passage area; failure — load error with retry; continuation — play proceeds.

FR-2 — Stranded-traveller opening. As a Cult Leader (Player), I should experience the opening where my car breaks down on the edge of town and I am rescued by girls in a horse and buggy, so that the premise establishes how I arrived. Provenance: explicit. Lifecycle: trigger — new save begins; result — opening passage presented; continuation — the town and cult are revealed.

FR-3 — Inheritance of leadership. As a Cult Leader (Player), I should have the very old cult leader hand me the keys to his throne, recognizing the population needs fresh DNA, so that I inherit leadership of the commune. Provenance: explicit. Lifecycle: trigger — opening continues; result — leadership transferred to the player; continuation — management surfaces become the player's responsibility.

FR-4 — Keep the commune alive and members happy. As a Cult Leader (Player), I should keep the isolated commune alive and its many members happy, so that the community survives and stays loyal. Provenance: explicit. Lifecycle: trigger — each day; result — morale, belief, population, and food reflect the player's management; failure — decline in morale or food with visible causes; recovery — corrective actions.

FR-5 — Daily action choice. As a Cult Leader (Player), I should choose what my character does each day to maintain the cult and keep members happy, so that each day has a committed decision. Provenance: explicit. Lifecycle: trigger — a new day; input — one daily action; result — the day advances with consequences; failure — commit error with retry; continuation — next day.

FR-6 — Personal participation in commune activities. As a Cult Leader (Player), I should be able to personally participate in farming, machine maintenance, animal husbandry, cooking, cleaning, and hunting, so that I can contribute labor when I choose. Provenance: explicit. Lifecycle: trigger — open Daily Action; input — select one of the six activities; result — personal action committed with cost and consequence; failure — commit error with retry; continuation — return to Commune.

FR-7 — Encouraged delegation. As a Cult Leader (Player), I should be encouraged to leave most of those tasks to other cult members rather than doing them myself, so that delegation is the natural path. Provenance: explicit. Lifecycle: trigger — viewing Daily Action or Tasks; result — delegation is presented as the encouraged option; continuation — assign tasks to members.

FR-8 — Weekly rituals. As a Cult Leader (Player), I should perform rituals each week to keep cult members happy and believing in my "chosen one" status, so that belief and happiness are maintained. Provenance: explicit. Lifecycle: trigger — weekly ritual due; input — perform the ritual; result — happiness and belief effects applied; failure — ritual error with retry; continuation — next week.

FR-9 — Childrearing instructions. As a Cult Leader (Player), I should give instructions to other cult members on how they should raise the children, so that upbringing follows my direction. Provenance: explicit. Lifecycle: trigger — open Childrearing; input — issue or change instructions; result — instructions recorded and acknowledged by members; failure — save error with retry; continuation — effects on morale and belief.

FR-10 — Defender training. As a Cult Leader (Player), I should train cult members to defend the encampment from strangers, so that the commune is protected. Provenance: explicit. Lifecycle: trigger — open Defense; input — train a defender; result — training recorded and readiness updated; failure — training error with retry; continuation — readiness tracked.

FR-11 — Morale and belief management. As a Cult Leader (Player), I should manage morale and belief in my authority as leader, so that the commune remains loyal. Provenance: explicit. Lifecycle: trigger — review Morale; result — current values and causes shown; continuation — corrective actions via Rituals or Tasks.

FR-12 — Non-explicit offspring relationships. As a Cult Leader (Player), I should see relationships between characters develop and produce offspring, presented without overt sexual acts, so that the population grows non-explicitly. Provenance: explicit. Lifecycle: trigger — open Relationships; input — encourage or develop a relationship; result — offspring recorded and population updated; failure — action error with retry; continuation — lineage grows.

FR-13 — Population growth. As a Cult Leader (Player), I should see the population grow, so that the commune's future is secured. Provenance: explicit. Lifecycle: trigger — offspring recorded; result — population counter increases; continuation — reflected in Commune rail.

FR-14 — Self-service enrollment. As a Cult Leader (Player), I should be able to enroll before starting a new commune save, so that my save is bound to my identity. Provenance: required_inference. Lifecycle: trigger — choose Sign Up from Landing; input — credentials; result — new save created and routed to Commune; failure — validation error with recovery; continuation — play begins.

FR-15 — Returning verification. As a Cult Leader (Player), I should verify my identity before resuming durable commune state, so that my save is restored correctly. Provenance: required_inference. Lifecycle: trigger — choose Login from Landing; input — credentials; result — save restored and routed to Commune; failure — invalid credentials with recovery; continuation — play resumes.

FR-16 — Cult Member carries out assignments. As a Cult Member, I should carry out the leader's daily assignments across farming, machine maintenance, animal husbandry, cooking, cleaning, and hunting, so that the commune keeps running. Provenance: required_inference. Lifecycle: trigger — leader assigns a task; result — assignment recorded and member response shown to the leader; failure — assignment error with retry; continuation — task outcome reflected in counters.

FR-17 — Cult Member participates in rituals. As a Cult Member, I should participate in weekly rituals, so that my happiness and belief in the leader's authority are maintained. Provenance: required_inference. Lifecycle: trigger — leader performs the weekly ritual; result — member happiness and belief effects applied and shown; continuation — next week.

FR-18 — Cult Member raises children per instructions. As a Cult Member, I should raise the commune's children according to the leader's instructions, so that upbringing follows the leader's direction. Provenance: required_inference. Lifecycle: trigger — leader issues childrearing instructions; result — member acknowledgement shown; continuation — effects on morale and belief.

FR-19 — Cult Defender defends the encampment. As a Cult Defender, I should be trained by the leader and defend the encampment from strangers, so that the community keeps operating safely. Provenance: required_inference. Lifecycle: trigger — leader trains a defender; result — readiness updated and shown; continuation — readiness tracked against strangers.

4. User Personas

Cult Leader (Player)

The Cult Leader is the player: a stranded traveller rescued on the edge of an isolated American town and handed leadership of its cult by its very old leader. Their product context is the day-by-day management of the commune through the persistent status rail and narrative passage area. Their primary goal is to keep the community alive, growing, and loyal. Their distinct accepted responsibilities are: choosing each day's action (personal labor or delegation), personally performing farming, machine maintenance, animal husbandry, cooking, cleaning, or hunting when they choose, delegating most tasks to members, performing weekly rituals to sustain happiness and belief in their "chosen one" status, issuing childrearing instructions, training defenders, managing morale and belief, and developing relationships that produce offspring non-explicitly. Their relevant inputs and decisions are which activity to commit each day, which tasks to delegate, when to perform the weekly ritual, what childrearing instructions to issue, whom to train, and which relationships to encourage. They interact with Cult Members (who carry out assignments, participate in rituals, raise children, and form relationships) and Cult Defenders (who are trained and hold readiness). Their observable success is a commune with stable or rising morale and belief, growing population, adequate food, and defenders ready against strangers.

Cult Member

The Cult Member is an accepted active human persona inside the commune. Their product context is the leader's management surfaces, where their work is assigned and their responses are surfaced as observable outcomes. Their primary goal is to carry out the leader's daily assignments and participate in the commune's life. Their distinct accepted responsibilities are: performing delegated farming, machine maintenance, animal husbandry, cooking, cleaning, and hunting; participating in weekly rituals; raising the commune's children per the leader's instructions; and forming relationships that produce offspring. Their relevant inputs and decisions are which assignment they receive, how they respond to ritual participation, and how they follow childrearing instructions. They interact with the Cult Leader (who assigns, instructs, and leads rituals) and with other members through relationships. Their observable success is completed assignments reflected in commune counters, maintained happiness and belief, and acknowledged childrearing instructions.

Cult Defender

The Cult Defender is an accepted active human persona trained by the leader. Their product context is the Defense surface, where their training and readiness are tracked. Their primary goal is to defend the encampment from strangers so the community keeps operating. Their distinct accepted responsibilities are: receiving training from the leader and holding the encampment's readiness against strangers. Their relevant inputs and decisions are which training they receive and how readiness is maintained. They interact with the Cult Leader (who trains them). Their observable success is a defended settlement with tracked readiness that lets the community keep operating.

5. Core User Flows

Flow 1 — First visit and enrollment (Cult Leader)

1. The visitor opens the game and lands on Landing (anonymous). The hero headline "THEY FOUND YOU ON THE ROAD" fills the viewport; the sign-in slab rises on the diagonal red band.
2. The visitor chooses the sign-in slab and goes to Sign Up.
3. On Sign Up, the visitor enters credentials and submits. The form shows a loading state.
4. On success, a new commune save is created and the player is routed to Commune with the opening passage (car breakdown, rescue by girls in a horse and buggy, the old leader handing over the throne). On validation error, inline recovery lets the player correct and resubmit.

Flow 2 — Returning player resumes (Cult Leader)

1. The returning player opens Landing and chooses Login.
2. On Login, the player enters credentials and submits; a loading state shows.
3. On success, the player's commune save is restored — day, morale, belief, population, food, relationships, children, defenders, and action log — and the player is routed to Commune. On invalid credentials, recovery lets the player retry.

Flow 3 — Committing a day personally (Cult Leader)

1. From Commune, the player reviews the poster-rail (day stamp, belief and morale meters, population and food counters, action log) and the gossip ticker.
2. The player opens Daily Action and reviews the six activities with their costs and consequences, alongside the note that most tasks are better left to members.
3. The player selects one activity and commits it as the day's personal action.
4. The consequence is applied and shown; the player returns to Commune, where the rail and passage update and the day advances. On commit error, retry preserves the selection.

Flow 4 — Delegating the day's work (Cult Leader and Cult Member)

1. From Commune, the player opens Tasks.
2. The player reviews the six task categories and the available members, then assigns a task to a member.
3. The assignment is recorded and the member's response is shown to the player; the expected outcome is displayed.
4. The player returns to Commune and commits the day; the outcome is reflected in the counters and action log. On assignment error, retry preserves the assignment.

Flow 5 — Weekly ritual (Cult Leader and Cult Member)

1. When the weekly ritual is due, the mustard countdown on Rituals signals it.
2. The player reviews the ritual and its expected effect on happiness and belief, then performs it.
3. The ritual is recorded; member happiness and belief in the "chosen one" status are updated and shown. On ritual error, retry preserves the pending ritual.
4. The player returns to Commune, where the meters reflect the result and the countdown resets for the next week.

Flow 6 — Reviewing and correcting morale (Cult Leader)

1. The player opens Morale and reviews current morale and belief values, recent shifts, and their causes.
2. The player identifies a cause and navigates to Rituals or Tasks to address it.
3. After the corrective action, the player returns to Morale and sees the updated values and history.

Flow 7 — Issuing childrearing instructions (Cult Leader and Cult Member)

1. The player opens Childrearing and reviews the commune's children and current instructions.
2. The player issues or changes instructions for how members should raise the children, previewing the effect on morale and belief.
3. The instructions are recorded and the member acknowledgement is shown. On save error, retry preserves the edits.
4. The player returns to Commune; the effects are reflected in the rail.

Flow 8 — Training a defender (Cult Leader and Cult Defender)

1. The player opens Defense and reviews the defender roster and encampment readiness.
2. The player trains a defender; the training is recorded and readiness is updated and shown. On training error, retry preserves the selection.
3. The player returns to Commune; readiness is tracked against strangers.

Flow 9 — Developing a relationship and growing the population (Cult Leader and Cult Member)

1. The player opens Relationships (Lineage tab) and reviews relationship pairs and their state.
2. The player encourages or develops a relationship between characters.
3. The relationship advances; offspring are recorded and the population counter increases. All content is non-explicit — no sexual acts are depicted. On action error, retry preserves the selection.
4. The player returns to Commune, where the population counter reflects the growth.

6. Visuals Colors and Theme

The visual language is Typography as architecture: a cult town painted in poster ink, after the muse Paula Scher. The headline is "They found you on the road" — the interface itself looks like the town's signage: loud, blunt, a little unhinged, and unmistakably authored.

Palette (dark mode, flat — never gradient):

• Background: #16110D (ink-black-brown, tar-paper wall)
• Surface: #221A14
• Text: #F4EBDC (bone-cream, high contrast for long reading)
• Primary: #C8341E (poster red — authority colour: sermon banners, Chosen One seal, ritual day markers, primary buttons)
• Accent: #E8B21C (mustard — belief/morale meters and weekly ritual countdown)
• Muted: #8C7A66 (secondary labels and rules)
• Category codes: teal #2E6E63 for commune tasks; dusty violet-grey #6B5A78 for lineage/relationships

Typography:

• Headings: Anton, all caps, tracking -0.01em, stacked in tight 0.88 line-height so words become slabs; occasional single word rotated -4deg or set in outline (transparent fill, 2px bone stroke).
• Body: Archivo 400/500 at 17–18px with 1.6 line-height.
• UI labels: Archivo 600 uppercase 11px with 0.16em tracking.
• Numerals: tabular for day counters and meters.
• Scale (1.333 modular): display clamp(56px, 11vw, 148px) / section clamp(36px, 6vw, 72px) / subhead 28 / body 17 / label 11. Mobile display floor 56px, never smaller.

Shape language: Hard edges only — 0px radius on cards, buttons, and panels. Diagonal colour bands (clip-path polygons at 6–10 degrees) separate sections. Thick 3px rules and chunky 2px borders in bone or red. Seals/stamps as circles with double rings. Buttons are rectangular slabs of colour with a hard 4px offset shadow in ink, no blur. Nothing soft, nothing glassy.

Layout: Persistent left rail (280px desktop, collapsing to a top strip at 768px and a bottom tab bar at 375px) carrying day/season stamp, belief and morale meters as filled bars with big numerals, population and food counters, and the action log as a ruled ledger. Main content is a 12-column asymmetric grid: narrative passage in an 8-column measure, choices as a stacked column of full-width slabs with the verb in Anton caps on the left and the stat consequence in Archivo on the right. Section headers break the grid with a full-bleed red band. Tabs: Commune, Daily Action, Tasks, Morale, Rituals, Childrearing, Defense, Lineage.

Imagery: Typography is the imagery. Where a picture is needed, high-contrast duotone (bone on ink or red on ink) photographic crops of rural textures — weathered barn wood, a buggy wheel, a hand-painted sign, a field at dusk — cropped hard to the grid and often overprinted with a giant Anton word at 30% opacity. No stock smiling people, no clip art, no gradients, no 3D blobs. Character portraits are square duotone crops with the name set as a red band across the bottom edge.

Readability: Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit; no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled, rotated, or overlapped as the direction asks, as long as they cover no readable text or control. Moving content (the gossip ticker) may cross the viewport edge by design and must become fully readable as it passes; under reduced motion it becomes a static wrapped line.

7. Signature Design Concept

The public entry is a full-bleed ink-black field with a single enormous Anton headline filling the viewport — "THEY FOUND YOU ON THE ROAD" — stacked in three lines, each a different width, the middle line set in outline and rotated -4deg, bleeding past the right edge as decoration only. Behind and below it, a flat red band rises diagonally from the bottom-left carrying the sign-in slab and a bone-cream subline about the town. No centred stack, no gradient, no floating cards: the type IS the hero, with a duotone barn-wood crop tucked into the lower-right corner under a 30%-opacity overprint. A thin mustard rule across the top holds the town name in 11px tracked caps. The concept recomposes only accepted content — the premise headline, the town subline, and the sign-in slab routing to Sign Up and Login.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The stacked Anton headline "THEY FOUND YOU ON THE ROAD" as the hero, with the diagonal red sign-in band and the corner duotone barn-wood crop.
• Input → transformation → outcome thesis: On load, the headline reveals word-by-word in staggered type; the red band wipes in left-to-right (220ms) to carry the sign-in slab; the corner crop settles under its 30%-opacity overprint. The outcome is a composed poster frame with the sign-in slab ready to route to Sign Up or Login.
• Motion vocabulary: Staggered word-by-word type reveal; hard 90ms scale-from-0.96 stamp with no easing bounce; colour-block wipes (red band sweeping left-to-right in 220ms); stepped meter fills (300ms steps, mechanical-counter ticking); slow marquee ticker of town gossip along the top of the Commune screen.
• Composed first frame: Ink-black field; top mustard rule with town name; three stacked headline lines (middle outline, rotated -4deg, bleeding right); diagonal red band rising from bottom-left with the sign-in slab; bone-cream subline; corner duotone crop.
• Reduced-motion state: All motion disabled under prefers-reduced-motion; the headline appears instantly, choices appear instantly, the ticker becomes a static wrapped line, and meters show their final values without stepping.

9. Non-Functional Requirements

• NFR-1 — Web delivery. The game is delivered as a web game. Provenance: explicit.
• NFR-2 — Non-explicit content. No overt sexual acts are depicted; relationships that produce offspring are kept non-explicit. Provenance: explicit.
• NFR-3 — No pornographic media. No pornographic video clips or explicit sexual media are used. Provenance: explicit.
• NFR-4 — No incest or non-consensual content. No incest content and no non-consensual sexual scenarios; the premise must not center on coerced sexual relationships. Provenance: explicit.
• NFR-5 — Durable state. Commune state (day, morale, belief, population, food, relationships, children, defenders, action log) persists across sessions and is bound to the player's identity. Provenance: required_inference (durable_state_required).
• NFR-6 — Readable at every viewport. Readable text and controls stay whole at 375px, 768px, and 1280px, wrapping or scaling to fit, with no element covering them. Provenance: explicit (creative direction).
• NFR-7 — Reduced motion. All motion is disabled under prefers-reduced-motion, with a usable static arrangement. Provenance: explicit (creative direction).
• NFR-8 — Accessible contrast. Bone-cream text on ink-black ground at high contrast for long reading; flat colour blocks only. Provenance: explicit (creative direction).

10. Tech Stack

• Frontend: React application UI.
• Backend: Shared FastAPI process hosting all application APIs and domain modules (game state, identity, daily actions, tasks, morale, rituals, childrearing, defense, relationships).
• Database: MariaDB for application-owned persistent data.
• Deployment: Docker/docker-compose for the three provisioned services (frontend, backend, database). Kubernetes is not required for this deployment.

11. Assumptions and Constraints

• A-1: The reference sites (Secretary, Apocalyptic World) are used only as structural and feature-format inspiration; no names, copy, facts, or capabilities are taken from them.
• A-2: Identity is application-owned; only Landing, Sign Up, and Login are reachable without identity, and all gameplay surfaces require login.
• A-3: Cult Member and Cult Defender are accepted active human personas whose work is represented inside the leader's management surfaces; their responses are surfaced as observable outcomes to the leader.
• A-4: The six commune activities are farming, machine maintenance, animal husbandry, cooking, cleaning, and hunting.
• A-5: Relationships that produce offspring are presented non-explicitly; no sexual acts are depicted.
• A-6: The current delivery horizon covers the full accepted loop; no additional modules or account-management features are in scope.
• C-1: No incest content and no non-consensual sexual scenarios.
• C-2: No overt sexual acts are depicted.
• C-3: No pornographic video clips or explicit sexual media are used.
• C-4: The game is delivered as a web game.

12. Glossary

• Commune: The isolated small-town cult the player inherits and manages.
• Cult Leader (Player): The stranded traveller who inherits leadership and manages the commune day by day.
• Cult Member: A commune member who carries out delegated tasks, participates in rituals, raises children per instructions, and forms relationships.
• Cult Defender: A member trained by the leader to defend the encampment from strangers.
• Belief: The commune's belief in the leader's "chosen one" status.
• Morale: The commune's overall happiness and loyalty.
• Ritual: The weekly ceremony that sustains happiness and belief.
• Lineage: The record of relationships and offspring that grows the population.
• Poster-rail: The persistent left status rail carrying day, meters, counters, and action log.