System Requirements Document for philippines-america

1. Introduction

philippines-america is a browser game built around a single, loud premise: a country-versus-country contest between the Philippines and America. The player opens the game, takes a side, and plays the matchup through to a result that names which country won.

The product intent is deliberately narrow and complete: a head-to-head country matchup that a casual player can start and finish in one sitting. There is no account, no roster of nations beyond the two named combatants, no campaign, and no persistent progression. The game is the contest.

The audience is casual players with an appetite for loud, argumentative, flag-waving contest culture. The register is partisan, high-energy and poster-like — a fight bill pasted on a wall, not a dashboard. The experience is designed to feel like a printed matchup poster that you can play.

2. System Overview

philippines-america is delivered as a first-party browser application with custom UI. It consists of four ordered, anonymously reachable pages that carry the player from first impression to final verdict:

1. Landing — the printed fight bill that introduces the Philippines versus America matchup.
2. Game Setup — the two-sided country selection where the player picks a side.
3. Game — the country-versus-country matchup itself, with a live scoreboard.
4. Results — the completed matchup outcome naming which country won.

Actors. The only supported human actor is the Player. There are no other accepted human roles, no administrators, no spectators, and no second-player role. The application itself is the only system actor of consequence; there is no external provider, no third-party service, and no outbound recipient in the accepted scope.

Accepted behavior. The player chooses the Philippines or America, plays the matchup to a result, and sees which country won. The matchup is a single contest with a live scoreboard, a play area, and a terminal verdict.

Ownership. All four pages are owned by the application. No page is owned by a provider or an external destination. No capability in the accepted scope is owned solely by a background system process, because every accepted capability is initiated, controlled, and completed by the Player through first-party UI.

Narrow exclusions. This document does not specify accounts, login, profiles, leaderboards, matchmaking, multiplayer networking, chat, monetization, tournaments, additional countries, or saved match history. None of these were requested, and none are required to complete the accepted lifecycle.

2a. Product Interpretation and Delivery Boundary

Delivery. philippines-america is a first-party web application. The player reaches it in a browser, and every accepted interaction happens inside the application's own pages. There is no provider-owned surface and no external destination in the current scope.

Access. All four pages are anonymously reachable. The accepted journeys require no identity: a player can open the Landing page, pick a side, play the matchup, and see the result without ever establishing an account. Because no accepted capability creates a durable, resumable, actor-specific obligation — a match is played to completion in one sitting and its result is shown immediately — application-owned identity is not indispensable, and no identity establishment or verification lifecycle is specified. This is a deliberate boundary, not an omission.

Current versus future. Everything in this document is current. There is no accepted future horizon, no deferred phase, and no roadmap item carried forward from the requirement thread. Anything not described here is out of scope rather than scheduled.

2c. Page Content and Component Coverage

Landing

• Information and state. The public entry surface. It presents the matchup as a printed fight bill: the headline PHILIPPINES VERSUS AMERICA set in three stacked Anton lines at clamp(44px, 11vw, 192px), each line flush to a different edge so the type block spans the full viewport. The word PHILIPPINES is set in #E23A1F; the word AMERICA is set in #1C2B4A; both sit on the warm newsprint ground #F2EFE6. A thick diagonal wedge of #E23A1F cuts in from the top-left and a wedge of #1C2B4A from the bottom-right, meeting behind the type but never crossing it. A small caps stamp in the top-right corner reads the project name. Nothing is centred; nothing floats.
• Primary action. A single #F2C300 slab button, CHOOSE YOUR COUNTRY, pinned under the third headline line, flush left, with a 4px black offset outline. It advances the player to Game Setup.
• Supporting actions. None. The Landing page has exactly one call to action.
• Domain entities. The matchup (Philippines versus America) and the two combatant countries as named, coloured sides.
• Component responsibilities. HeroHeadline renders the three-line Anton type mass and owns the per-line edge alignment and per-country colouring. DiagonalWedge renders the two opposing colour wedges behind the type. WordmarkStamp renders the small caps project-name stamp. ChooseCountryButton renders the single yellow slab and owns its press offset. HalftoneTexture renders the flag-derived halftone dot texture at 20% opacity behind the colour blocks.
• States. Loading: the page is static content and renders immediately; no loading state is required. Empty: not applicable — the page has no collection. Success: the headline, wedges, stamp, and button are all fully visible and the button is operable. Error: not applicable — no data fetch, no failure path. Recovery: not applicable.

• Viewport behavior. At 375px, 768px, and 1280px the headline, wordmark stamp, and button remain entirely inside the viewport and their containers, wrapping or scaling via clamp(...) to fit. The diagonal wedges and halftone texture may bleed off the edge; they never cover the headline, the stamp, or the button.

Game Setup

• Information and state. Two full-height halves side by side at 1280px, stacked at 768px and 375px. Each half is a flat colour block — Philippines in #E23A1F, America in #1C2B4A — with the country name set in Anton at viewport-filling size and a single PICK THIS SIDE slab per half. The page communicates that exactly one side will be chosen and that choosing a side is the only decision here.
• Primary action. PICK THIS SIDE on either half. Selecting a side records the player's country and advances to the Game page.
• Supporting actions. None beyond the two side selections. There is no back-out control specified, no randomize control, and no third option.
• Domain entities. The two selectable countries (Philippines, America) and the player's chosen side.
• Component responsibilities. SideHalf renders one country's full-height colour block, its Anton country name, and its pick slab; it owns the selected state for its side. PickSideButton renders the flat colour slab with a 4px black offset outline that shifts on press. SideNameType renders the country name at viewport-filling Anton scale.
• States. Loading: static content; renders immediately. Empty: not applicable. Success: the chosen half visibly registers selection and the player is taken to the Game page with that side active. Error: if a side selection does not register, the half remains in its unselected state and the pick slab stays operable so the player can press again. Recovery: re-pressing PICK THIS SIDE on either half is the recovery path; the player may change sides before the matchup begins.
• Viewport behavior. At 1280px the halves sit side by side; at 768px and 375px they stack. Country names, pick slabs, and labels stay entirely inside their half and the viewport at all three widths.

Game

• Information and state. The matchup surface. A scoreboard strip is pinned at the top: tabular cells with hairline dividers, black on paper, where the live cell flips to signal yellow #F2C300. Below it, the play area sits on the paper ground with the two sides' colours entering as opposing diagonal bands. A running marquee ticker of matchup slogans runs along the top of the screen in place of a conventional header. The player's chosen side is the active player token, marked in #F2C300.
• Primary action. Play the matchup. The player acts within the play area to advance the contest toward a result.
• Supporting actions. None specified beyond play itself. There is no pause, no settings, and no in-match side switching.
• Domain entities. The active matchup, the two combatant sides, the live score, and the player's chosen side as the active token.
• Component responsibilities. ScoreboardStrip renders the tabular cells, hairline rules, and the yellow live cell; it owns cell-by-cell numeral changes. PlayArea renders the contest surface and the opposing diagonal colour bands. SloganTicker renders the marquee of matchup slogans along the top. ActivePlayerToken renders the player's chosen side marker in #F2C300.
• States. Loading: the scoreboard strip and play area render with the matchup's starting values; the ticker begins running. Empty: not applicable — a matchup always has two sides and a starting score. Success: the matchup reaches a terminal result and the player is taken to the Results page. Error: if the matchup cannot reach a result, the play area remains in its current state with the scoreboard showing the last committed values, and play remains available so the player can continue. Recovery: the player continues playing from the last committed scoreboard state; no match state is silently discarded.

• Viewport behavior. The scoreboard strip, play area, and ticker stay inside the viewport at 375px, 768px, and 1280px. The ticker is a moving marquee and may cross the viewport edge by design; every slogan becomes fully readable as it passes. Under prefers-reduced-motion the ticker becomes a horizontally scrollable row in which each slogan can be brought fully into view.

Results

• Information and state. The completed matchup outcome. One giant verdict word — VICTORY or DEFEAT — in Anton spanning the full width, with the winning country's colour flooding the background. A ruled stat table sits beneath the verdict, presenting the matchup's figures in tabular cells with hairline dividers. The page names which country won.
• Primary action. Read the outcome. The verdict word and the winning country's colour are the primary content.
• Supporting actions. A control to play again, returning the player to Game Setup to pick a side for a new matchup.
• Domain entities. The completed matchup, the winning country, the losing country, and the matchup's recorded figures.
• Component responsibilities. VerdictWord renders the full-width Anton verdict and owns the winning-country background flood. StatTable renders the ruled tabular figures with hairline dividers. PlayAgainControl renders the return-to-setup slab.
• States. Loading: the verdict and stat table render from the completed matchup's values. Empty: not applicable — Results is only reached from a completed matchup. Success: the verdict word, the winning country's colour, and the stat table are all fully visible and the play-again control is operable. Error: if the outcome cannot be presented, the page shows the last committed matchup state rather than a blank verdict. Recovery: the play-again control returns the player to Game Setup, where a fresh matchup can be started.
• Viewport behavior. The verdict word, stat table, and play-again control stay entirely inside the viewport and their containers at 375px, 768px, and 1280px, scaling via clamp(...) where needed.

3. Functional Requirements

FR-1 — Open the country-versus-country game. (explicit) As a Player, I should be able to open the Philippines versus America game and immediately understand that it is a country-versus-country contest, so that I know what I am about to play.

• Trigger/input: the player navigates to the application.
• Observable result: the Landing page renders the headline PHILIPPINES VERSUS AMERICA as a three-line Anton type mass spanning the viewport, with PHILIPPINES in #E23A1F and AMERICA in #1C2B4A on the #F2EFE6 ground, the two diagonal wedges meeting behind the type, the small caps wordmark stamp in the top-right, and the CHOOSE YOUR COUNTRY slab pinned flush left beneath the third line.
• Access state: anonymous; no identity required.
• Failure/recovery: not applicable — the page is static and has no failure path.
• Continuation: the player presses CHOOSE YOUR COUNTRY to proceed to Game Setup.

FR-2 — Choose a side. (explicit) As a Player, I should be able to choose the Philippines or America as my side, so that the matchup is played as my country against the other.

• Trigger/input: the player presses PICK THIS SIDE on one of the two full-height colour halves on Game Setup.
• Observable result: the chosen half registers selection, the player's side is recorded as the active side, and the player advances to the Game page with that side active.
• Access state: anonymous; no identity required.
• Failure/recovery: if a selection does not register, the half remains unselected and its pick slab stays operable; the player presses again. The player may change sides before the matchup begins.
• Continuation: the player enters the Game page with the chosen side as the active player token.

FR-3 — Play the matchup to a result. (explicit) As a Player, I should be able to play the country-versus-country matchup through to a result, so that the contest between the two countries is actually decided.

• Trigger/input: the player acts within the play area on the Game page.
• Observable result: the scoreboard strip updates cell-by-cell as the matchup progresses, the live cell flips to #F2C300, and the matchup reaches a terminal result.
• Access state: anonymous; no identity required.
• Failure/recovery: if the matchup cannot reach a result, the play area holds its current state and the scoreboard shows the last committed values; play remains available so the player can continue from that state.
• Continuation: on reaching a terminal result, the player is taken to the Results page.

FR-4 — See which country won. (explicit) As a Player, I should be able to see the completed matchup outcome and which country won, so that the contest has a clear verdict.

• Trigger/input: the matchup reaches a terminal result.
• Observable result: the Results page renders one giant verdict word — VICTORY or DEFEAT — in Anton spanning the full width, with the winning country's colour flooding the background, and a ruled stat table beneath it presenting the matchup's figures.
• Access state: anonymous; no identity required.
• Failure/recovery: if the outcome cannot be presented, the page shows the last committed matchup state rather than a blank verdict.
• Continuation: the player may use the play-again control to return to Game Setup and start a fresh matchup.

FR-5 — Read the live scoreboard during play. (required_inference) As a Player, I should be able to read the live score of the matchup while I am playing it, so that I can tell where the contest stands at any moment.

• Trigger/input: the player is on the Game page and the matchup is in progress.
• Observable result: the scoreboard strip is pinned at the top of the Game page as tabular cells with hairline dividers, black on paper, with the live cell in #F2C300 and numerals changing cell-by-cell rather than counting smoothly.
• Access state: anonymous; no identity required.
• Failure/recovery: if a scoreboard update does not commit, the strip continues to show the last committed values rather than a blank or partial cell.
• Continuation: the player continues playing with the scoreboard visible.
• Rationale: a contest played to a result is not usable without an observable standing; the scoreboard is the minimum state display that makes FR-3's progress legible.

FR-6 — Start a fresh matchup after a result. (required_inference) As a Player, I should be able to start a new matchup after seeing a result, so that a completed contest is not a dead end.

• Trigger/input: the player presses the play-again control on the Results page.
• Observable result: the player returns to Game Setup, where both sides are available to pick again.
• Access state: anonymous; no identity required.
• Failure/recovery: if the return does not occur, the Results page remains intact with its verdict and stat table, and the control stays operable.
• Continuation: the player picks a side and plays a new matchup.
• Rationale: the accepted lifecycle ends at a result; without a return path the product terminates after one play, which the accepted "plays the matchup to a result" responsibility does not support as a one-shot-only experience.

4. User Personas

Player

Product context. The Player is the only supported human role in philippines-america. They arrive at a browser game that presents a single country-versus-country contest between the Philippines and America, framed as a printed fight bill rather than a utility screen. They are a casual player with an appetite for loud, partisan, flag-waving contest culture, and they are not asked to learn a system, configure anything, or manage an account.

Primary goal. To pick a side — the Philippines or America — and play the matchup through to a result that names which country won.

Distinct accepted responsibilities. The Player's work is a short, complete arc with three distinct responsibilities that no other role shares:

1. Choosing a side. On Game Setup, the Player makes the one decision the product asks of them: which of the two countries they fight as. This is a commitment, not a preference — the chosen side becomes the active player token for the whole matchup.
2. Playing the contest. On the Game page, the Player acts within the play area to advance the matchup, reading the live scoreboard as it changes cell-by-cell to know where the contest stands.
3. Reading the verdict. On Results, the Player receives the outcome: a single giant verdict word and the winning country's colour flooding the background, with the matchup's figures ruled beneath it.

Relevant inputs and decisions. The Player's only input decision is the side selection. Everything else is play within the matchup. The Player does not configure difficulty, choose a duration, name a match, or set any option — none of these were requested.

Interactions with other accepted participants. There are none. The Player is the sole human actor. The opposing country is a side in the contest, not a second human participant; there is no opponent player, no spectator, and no administrator. The application is the only other actor, and it serves the Player's actions rather than negotiating with them.

Observable success. The Player has completed a match and can see which country won: the verdict word is on screen, the winning country's colour fills the background, and the stat table shows the matchup's figures. The Player can then start a fresh matchup if they choose.

Constraints carried from source. The Player is anonymous throughout. No account, profile, or saved history is required or offered. The Player's experience is bounded by the four accepted pages and by the poster-like visual and motion direction — loud, hard-edged, and typographic — rather than a quiet, dashboard-like register.

5. Core User Flows

Flow 1 — Player opens the game and understands the matchup

1. The Player navigates to philippines-america in a browser. No sign-in is presented, because none is required.
2. The Landing page renders as a printed fight bill: the headline PHILIPPINES VERSUS AMERICA is set in three stacked Anton lines at clamp(44px, 11vw, 192px), each line flush to a different edge so the type block spans the viewport. PHILIPPINES is in #E23A1F, AMERICA is in #1C2B4A, both on the #F2EFE6 newsprint ground.
3. A thick diagonal wedge of #E23A1F cuts in from the top-left and a wedge of #1C2B4A from the bottom-right; they meet behind the type but never cross it. A small caps stamp in the top-right corner reads the project name.
4. The Player reads the matchup from the type mass alone — the headline is the image, and it is the largest element on the screen.
5. A single #F2C300 slab button, CHOOSE YOUR COUNTRY, sits pinned under the third line, flush left, with a 4px black offset outline.
6. Observable result: the Player understands that this is a Philippines versus America contest and that the next step is to choose a country.
7. Next step: the Player presses CHOOSE YOUR COUNTRY and moves to Game Setup.

Flow 2 — Player picks a side

1. The Player arrives on Game Setup from the Landing page.
2. At 1280px the page presents two full-height halves side by side; at 768px and 375px the halves stack. Each half is a flat colour block — Philippines in #E23A1F, America in #1C2B4A — with the country name set in Anton at viewport-filling size and a single PICK THIS SIDE slab.
3. The Player considers the two sides. This is the one decision the product asks of them.
4. The Player presses PICK THIS SIDE on one half. The slab is a flat colour block with a 4px black offset outline that shifts on press.
5. Observable result: the chosen half registers selection and the Player's side is recorded as the active side.
6. Failure/recovery: if the press does not register, the half remains unselected and its slab stays operable; the Player presses again. The Player may also change sides by pressing the other half before the matchup begins.
7. Next step: the Player advances to the Game page with the chosen side as the active player token.

Flow 3 — Player plays the matchup to a result

1. The Player arrives on the Game page with a chosen side.
2. A running marquee ticker of matchup slogans moves along the top of the screen in place of a conventional header. Under prefers-reduced-motion the ticker becomes a horizontally scrollable row in which each slogan can be brought fully into view.
3. A scoreboard strip is pinned at the top: tabular cells with hairline dividers, black on paper, with the live cell flipped to signal yellow #F2C300. The Player's chosen side is marked as the active player token in #F2C300.
4. Below the strip, the play area sits on the paper ground with the two sides' colours entering as opposing diagonal bands.
5. The Player acts within the play area to advance the contest. As the matchup progresses, the scoreboard numerals change cell-by-cell rather than counting smoothly, and the live cell stays yellow.
6. Observable result: the Player can read the standing of the contest at any moment from the scoreboard strip.
7. Failure/recovery: if the matchup cannot reach a result, the play area holds its current state and the scoreboard shows the last committed values; play remains available and the Player continues from that state rather than losing progress.
8. Next step: when the matchup reaches a terminal result, the Player is taken to the Results page.

Flow 4 — Player sees which country won

1. The Player arrives on Results from a completed matchup.
2. One giant verdict word — VICTORY or DEFEAT — is set in Anton spanning the full width of the page.
3. The winning country's colour floods the background, so the outcome is legible from the colour field alone.
4. A ruled stat table sits beneath the verdict, presenting the matchup's figures in tabular cells with hairline dividers.
5. Observable result: the Player can see which country won and read the matchup's figures.
6. Failure/recovery: if the outcome cannot be presented, the page shows the last committed matchup state rather than a blank verdict.
7. Next step: the Player may use the play-again control to return to Game Setup.

Flow 5 — Player starts a fresh matchup

1. From the Results page, the Player presses the play-again control.
2. Observable result: the Player returns to Game Setup, where both sides are available to pick again.
3. Failure/recovery: if the return does not occur, the Results page remains intact with its verdict and stat table, and the control stays operable.
4. Next step: the Player picks a side (Flow 2) and plays a new matchup (Flow 3).

6. Visuals, Colors and Theme

Muse and headline. Typography as territory after Paula Scher — country versus country as poster war. The visual language is Scher's: words as the image, colour blocks colliding, energy over polish, typography big enough to be a flag. The duel structure — two sides, two colour fields, two type masses — is native to the matchup and puts the head-to-head tension on the first screen.

Mode. Light mode only. There is no dark mode in the accepted scope.

Colour tokens by role.

Colour discipline. Navy #1C2B4A is a flag block, never a SaaS accent, and it never sits on a white ground as a button colour. Signal yellow #F2C300 is reserved for the live scoreboard, the active player token, and hover wipes, and covers under 8% of any screen. The approximate screen balance is 55% paper, 20% each combatant block, 5% yellow. Muted #6E675B handles metadata and rules only.

Typography. Headings are Anton, all caps, condensed and packed tight (letter-spacing −0.01em to 0em, line-height 0.86), stacked into two- and three-line masses that read as a single slab of ink. Headlines are the largest element on every screen and are set to bleed to the viewport edge rather than sit inside a margin. Oswald at 500/600 weight in caps with wide tracking (0.08em) handles labels, scoreboard numerals, and buttons. Oswald regular/lowercase at 400 handles any running sentence at 16–18px. Body is Oswald.

Type scale. 1.5 modular, mobile-first: display steps 44 / 72 / 108 / 144 / 192; body 16 / 18 / 22; labels 12 / 13 caps tracked. Display uses clamp(44px, 11vw, 192px); section headlines use clamp(32px, 7vw, 96px).

Shape language. Hard edges only — zero border radius, zero soft shadows. Everything is a rectangle of ink or colour: full-bleed type bands, diagonal colour wedges, thick 4px and 8px rules, tabular scoreboard cells with hairline dividers. Buttons are flat colour slabs with a 4px black offset outline that shifts on press. No pills, no blobs, no glass.

Spacing rhythm. Strict columns, flush-left ragged-right type, rules instead of cards. Thick 4px and 8px rules separate bands; hairline dividers separate tabular cells. No card grid, no hover-lift, no uniform panel spacing.

Imagery style. Typography is the imagery. The only non-type visuals are flat colour fields, diagonal bands, thick rules, halftone-dotted flag-derived textures at 20% opacity behind the colour blocks, and high-contrast two-tone cut-out treatments of flag elements (three stars, a sun, stripes) used as oversized graphic marks that can bleed off the edge. No stock photography, no 3D, no illustration of people.

Forbidden. The generic indigo/blue-on-white SaaS template is forbidden for this project. Also avoided: blue or indigo primary accents on a white or near-white ground; rounded corners, pill buttons, soft drop shadows and glass panels; centred headline + subtext + button hero compositions; gradient blobs, glowing 3D orbs and particle fields; cards in a uniform grid with hover-lift; photography of people or stock lifestyle imagery; thin, elegant or light-weight display type; neutral greys used as the dominant surface.

7. Signature Design Concept

The printed fight bill. The Landing page is not a hero section; it is a poster pasted on a wall. A single Anton headline — PHILIPPINES VERSUS AMERICA — is set in three stacked lines at clamp(44px, 11vw, 192px), each line flush to a different edge so the block spans the full viewport. The word PHILIPPINES is #E23A1F; the word AMERICA is #1C2B4A; both sit on the warm paper ground #F2EFE6. A thick diagonal wedge of #E23A1F cuts in from the top-left and a wedge of #1C2B4A from the bottom-right, meeting behind the type but never crossing it. The dominant element is the type mass, roughly 60% of the viewport height. A single #F2C300 slab button, CHOOSE YOUR COUNTRY, sits pinned under the third line, flush left, with a 4px black offset outline. A small caps stamp in the top-right corner reads the project name. Nothing is centred; nothing floats.

The concept is implementable with the accepted content alone: the headline text, the two country names and their colours, the two wedges, the wordmark stamp, and the one button. It recomposes accepted content and states — it introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject. The three-line Anton headline PHILIPPINES VERSUS AMERICA, with PHILIPPINES in #E23A1F and AMERICA in #1C2B4A, and the two diagonal colour wedges that meet behind it.
• Input → transformation → outcome thesis. As the Landing page loads, each headline line slams in from its own side — Philippines lines from the left, America lines from the right — with a 60–90ms stagger, while the two diagonal wedges cut in from the top-left and bottom-right and settle behind the type. The outcome is a composed first frame in which the full type mass spans the viewport, the wedges meet behind it without crossing it, and the single #F2C300 CHOOSE YOUR COUNTRY slab is already in place, flush left, ready to press.
• Motion vocabulary. Staggered word reveals with hard slams; colour-block wipes that sweep across a button on hover; a marquee ticker of matchup slogans running along the top of the Game screen; scoreboard numerals that flip cell-by-cell rather than counting smoothly. No easing theatrics, no bounce, no particles.
• Composed first frame. The headline occupies roughly 60% of the viewport height, each line flush to a different edge. The #E23A1F wedge holds the top-left, the #1C2B4A wedge holds the bottom-right, and they meet behind the type. The small caps wordmark stamp sits in the top-right corner. The yellow slab sits under the third line, flush left, with its 4px black offset outline. Nothing is centred.
• Reduced-motion state. Under prefers-reduced-motion, all slams and wipes become instant state changes and nothing moves on its own. The headline, wedges, stamp, and button appear in their final composed positions immediately. The Game screen's slogan ticker becomes a horizontally scrollable row in which each slogan can be brought fully into view.

9. Non-Functional Requirements

NFR-1 — Readable text and controls stay whole at every viewport. (explicit) Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the creative direction asks, as long as they cover no readable text or control. Where a direction or brief asks readable text or a control to be cropped, clipped, covered, or run off an edge, the text or control is kept whole and the gesture is carried with imagery or decoration instead.

• Rationale: the poster direction deliberately bleeds type and colour to the viewport edge; this constraint keeps that gesture from destroying legibility.

NFR-2 — Moving and scrollable content remains fully readable. (explicit) Moving and scrollable content — the Game screen's marquee ticker and any horizontally scrollable row — may cross the viewport or container edge by design. It is judged by whether it actually moves or scrolls and whether every item becomes fully readable as it passes, never by the item cut at the edge in a still frame. A scrollable row need not show every item fully at once. Source-backed overflow-x: auto or scroll, with items that fit the container when brought into view, is valid scrolling; a visible scrollbar is not required.

• Rationale: the slogan ticker is a signature move and is intentionally edge-crossing.

NFR-3 — Reduced-motion support. (explicit) Under prefers-reduced-motion, all slams and wipes become instant state changes, the ticker becomes a horizontally scrollable row where each slogan can be brought fully into view, and nothing moves on its own. A usable static arrangement is provided: items wrap into rows or allow horizontal scrolling so each item can be brought fully into view.

• Rationale: the motion direction is expressive; reduced-motion users must still reach every piece of content.

NFR-4 — Anonymous access with no identity lifecycle. (required_inference) All four pages are reachable without establishing an account. No accepted capability creates a durable, resumable, actor-specific obligation, so no identity establishment, verification, or account-management surface is specified.

• Rationale: the accepted lifecycle is a single-sitting matchup played to a result; identity is not indispensable to it.

NFR-5 — No differentiated permissions. (required_inference) There is exactly one human role, and no accepted behavior establishes differentiated control or visibility over shared product state. No role-based access control, role-based visibility, or permission control is specified.

• Rationale: the closed persona catalog contains only the Player, and no source requirement grants one participant authority over another's state.

NFR-6 — Hard-edged visual system. (explicit) Zero border radius and zero soft shadows across the product. Buttons are flat colour slabs with a 4px black offset outline that shifts on press. No pills, no blobs, no glass panels, no gradient blobs, no glowing 3D orbs, no particle fields.

• Rationale: the poster language depends on rectangles of ink and colour; softness would dissolve it.

NFR-7 — Signal yellow is rationed. (explicit) #F2C300 is reserved for the live scoreboard cell, the active player token, and hover wipes, and covers under 8% of any screen.

• Rationale: the yellow only reads as a signal if it stays scarce.

10. Tech Stack

• Frontend: React, delivered as a browser application with custom UI. (Default — not specified by user)
• Backend: Python with FastAPI, serving the application's routes and matchup logic from a single shared backend process. (Default — not specified by user)
• Storage: not required for the accepted scope. The matchup is played to completion in one sitting and its result is shown immediately; no durable match history, profile, or leaderboard is accepted, so no database is specified. (Default — not specified by user)
• Containerization: Docker with docker-compose, running the frontend and the single backend service. (Default — not specified by user)
• Kubernetes: not required. The accepted scope is a single-player browser game with no scaling or orchestration requirement. (Default — not specified by user)

No source-specified technology choices were given in the requirement thread; the above are labeled defaults and do not alter product behavior.

11. Assumptions and Constraints

Assumptions.

1. Single-player contest. The matchup is played by one human Player against the opposing country as a side in the contest, not against a second human opponent. No multiplayer, matchmaking, or networking is assumed. (Assumption — not specified by user)
2. One sitting. A matchup is started and completed within a single session; no save, resume, or match history is assumed. (Assumption — not specified by user)
3. Two countries only. The combatants are exactly the Philippines and America. No additional countries, factions, or rosters are assumed. (Assumption — not specified by user)
4. Anonymous play. No account, login, or profile is assumed, consistent with NFR-4. (Assumption — not specified by user)
5. Light mode only. The palette is specified for light mode; no dark mode is assumed. (Assumption — not specified by user)

Constraints.

1. The product is a country-versus-country game themed on a Philippines versus America matchup. (explicit)
2. The player takes a side and plays the matchup to a result. (explicit)
3. The four pages — Landing, Game Setup, Game, Results — are the complete information architecture, in that order, all anonymously reachable. (explicit, from the page contract)
4. The Player is the only supported human role. (explicit, from the persona contract)
5. The visual and motion direction in sections 6–8 is authoritative for presentation: Paula Scher poster language, the specified palette, Anton and Oswald typography, hard edges, and expressive hard-edged motion. (explicit)
6. The generic indigo/blue-on-white SaaS template is forbidden for this project. (explicit)
7. Readable text and controls stay whole at 375px, 768px, and 1280px; imagery and decoration may bleed. (explicit)

Out of scope. Accounts, login, profiles, leaderboards, matchmaking, multiplayer networking, chat, monetization, tournaments, additional countries, saved match history, difficulty settings, and match configuration options. None were requested and none are required by the accepted lifecycle.

12. Glossary

• Matchup — a single Philippines versus America contest, from side selection through to a terminal result.
• Side — one of the two combatants in a matchup: the Philippines (#E23A1F) or America (#1C2B4A). The Player picks exactly one side per matchup.
• Active player token — the marker in #F2C300 identifying the Player's chosen side during the matchup.
• Scoreboard strip — the pinned tabular band at the top of the Game page, with hairline-divided cells, black on paper, whose live cell flips to #F2C300 and whose numerals change cell-by-cell.
• Play area — the contest surface on the Game page, on the paper ground, with the two sides' colours entering as opposing diagonal bands.
• Slogan ticker — the running marquee of matchup slogans along the top of the Game screen, replacing a conventional header.
• Verdict word — the single giant Anton word on the Results page, VICTORY or DEFEAT, spanning the full width with the winning country's colour flooding the background.
• Stat table — the ruled tabular presentation of the completed matchup's figures beneath the verdict word.
• Poster language — the visual system derived from Paula Scher: words as the image, colliding flat colour blocks, full-bleed type bands, thick rules, and hard edges with no radius or soft shadow.
• Signal yellow — #F2C300, rationed to the live scoreboard cell, the active player token, and hover wipes, covering under 8% of any screen.