System Requirements Document for halo-ce-psp

1. Introduction

This document specifies the system requirements for halo-ce-psp, a fan-built remake of Halo: Combat Evolved that is designed from the ground up to be portable to the PlayStation Portable (PSP). The product intent is twofold and inseparable: recreate the Halo: Combat Evolved campaign experience, and do so within a form that can be hand-ported to run on 333MHz handheld hardware with a 480×272 render target and a 32MB memory budget.

The audience is the Player — someone who knows the original 2001 campaign and wants to experience a handheld-scale recreation of it, progressing through missions and combat encounters to completion. The requester, Arjun Pai, is also the builder who must ship the remake inside the PSP's memory budget; that builder role is a development-time concern rather than an in-product workflow role, and is therefore not modeled as a product persona.

The remake's low-poly, flat-shaded aesthetic is not a compromise to be hidden. It is the honest register of a PSP-bound recreation, and the product presents it plainly.

2. System Overview

halo-ce-psp is a playable, low-poly recreation of the Halo: Combat Evolved campaign, built to ship on the PlayStation Portable. The current delivery is a custom first-party experience with two surfaces:

• Landing — an anonymous public entry surface that presents the remake, its intended player, and its PSP portability before gameplay.
• Campaign — the surface that owns starting and playing the recreated campaign experience on PSP-compatible hardware.

The sole active human actor is the Player. There is no differentiated permission model, no role-based visibility, and no account requirement: both surfaces are reachable without identity establishment, and no durable actor-specific state must be privately owned or resumed across sessions. The remake's defining constraint — that it must fit and run on a PSP — is expressed directly in the interface rather than described in prose.

2a. Product Interpretation and Delivery Boundary

The product is a game remake, not a service. Its delivery boundary is the playable campaign itself, presented through a first-party custom interface that is honest about the hardware it targets. The Landing surface is anonymous and public: it exists to establish what the remake is, who it is for, and that it is built for the PSP, before the Player commits to play. The Campaign surface is likewise reachable without identity; the Player selects a mission and plays it.

Everything the Player needs to complete the accepted goal — experiencing the recreated campaign on handheld-scale hardware — is inside these two surfaces. There is no account system, no social layer, no storefront, no multiplayer, no level editor, and no analytics dashboard. The PSP port itself is a build and deployment concern owned by the builder, not an in-product workflow; the product's responsibility toward it is to present the portability constraint truthfully and to keep the experience within the handheld's rendering and memory envelope.

No future-horizon requirements have been accepted. Anything not stated in this document is out of current scope.

2c. Page Content and Component Coverage

Landing

• Information and state: The remake's identity as a Halo: Combat Evolved recreation; the intended audience (the Player); the PSP portability facts (480×272 render target, 32MB memory budget); the entry point into the campaign. No identity, session, or persisted state is required or displayed.
• Primary action: Enter the campaign.
• Supporting actions: Read the portability facts; observe the live low-poly ring scene; hover and move the pointer to influence the camera.
• Domain entities: The Halo ring (the hero scene subject); the Master Chief silhouette; the Warthog; the Covenant Elite; the plasma pistol; the PSP render-target outline; the port-spec figures.
• Component responsibilities:
  • Hero scene — a full-bleed near-black void containing a real-time low-poly Halo ring rendered in Three.js, tilted at a three-quarter angle and bleeding off the right and bottom edges so roughly two-thirds of the ring is visible, inner curve facing the viewer, each facet catching a coral rim light against a mint-cool shadow side. The ring's mass sits right-of-centre; the left third is empty void.
  • Headline block — an oversized Fredoka headline in pale #E8F1F5, clamp(40px, 9vw, 120px), set flush-left in three tight lines ("HALO / COMBAT / EVOLVED"), with a small coral "REMAKE" tag rotated -6° overlapping the first line's baseline.
  • Entry CTA — a single coral capsule ("ENTER THE CAMPAIGN") with a 3px bottom lip, routing to Campaign.
  • Port micro-label — a mint micro-label beside the CTA reading "PSP BUILD — 480×272 — 32MB".
  • HUD strip — a bottom-left strip of three tiny faceted icons (shield, ammo, motion tracker) at 40% opacity.
  • Wireframe overlay — 1px coral lines tracing triangulation, used as section dividers and around the hero ring.
  • Port-spec band — a full-width colour-block band carrying the portability facts as diagrammatic 2D imagery: a PSP outline showing the 480×272 render target, poly-count bars, and a top-down level map drawn in 1px coral line.
• States:
  • Loading: the hero scene initialises; the void ground and headline block render first so the page is readable before geometry appears.
  • Empty: not applicable — the Landing surface has no user-owned collection to be empty.
  • Success: the ring renders and rotates; the headline, CTA, and port micro-label are fully visible and legible; the CTA routes to Campaign.
  • Error / recovery: if the WebGL scene cannot initialise, the void ground, headline block, CTA, port micro-label, and port-spec band remain fully rendered and usable, and the hero area holds a static three-quarter ring view as a flat fallback. The Player can still enter the campaign.
  • Reduced motion: the ring holds one static three-quarter view; the camera no longer springs toward the cursor; scroll-linked camera work becomes ordinary page scroll.

Campaign

• Information and state: The set of campaign missions available to play; the currently previewed mission; the Player's position in the campaign; the PSP viewport framing that contextualises the whole board.
• Primary action: Start a mission.
• Supporting actions: Browse and preview missions; hover a mission tile to tilt it toward the pointer; select a mission to begin play; return to the mission board after a mission.
• Domain entities: Mission (number, name, tile); mission preview; the PSP-shaped viewport frame; the current-mission indicator; the persistent HUD navigation bar.
• Component responsibilities:
  • PSP-shaped HUD frame — a 480×272-proportioned viewport outline drawn in 1px coral, inside which the current mission previews. The portability constraint is the interface itself.
  • Mission-select board — a 3-across grid of faceted mission tiles on desktop, 1-across at 375px, each tile 4:3 with the mission number oversized in its top-left corner at clamp(48px, 8vw, 96px) Fredoka.
  • Mission tile — a 20px-radius rounded block with a 1px inner highlight along the top edge so it reads as a lit poly face; tilts in 3D toward the pointer with spring overshoot; plays a 180ms squash-and-stretch on click.
  • Mission preview — the selected mission's preview rendered inside the PSP frame.
  • HUD navigation — a persistent bottom HUD bar at 375px (thumb-reachable, PSP-D-pad-like, four faceted icon buttons) that migrates to a top-left corner cluster at 1280px. Never a centred navbar.
  • Wireframe overlay — 1px coral triangulation lines on section dividers and card top edges.
• States:
  • Loading: the mission board renders its tiles; the PSP frame renders before preview content.
  • Empty: if no mission is currently previewed, the PSP frame holds an empty coral-outlined viewport with the mission board fully browsable beneath it.
  • Success: a mission tile is selected, its preview appears inside the PSP frame, and the mission starts.
  • Error / recovery: if a mission fails to start, the mission board remains fully browsable and the Player can select another mission or retry the same one; the PSP frame returns to its empty state rather than holding a broken preview.
  • Reduced motion: tiles lose their 3D tilt and use a 120ms opacity change on hover; the squash-and-stretch on click is removed; scroll-linked camera work becomes ordinary page scroll.

3. Functional Requirements

FR-1 — Recreate the Halo: Combat Evolved campaign. As a Player, I should be able to play a recreation of the Halo: Combat Evolved campaign, so that I can experience the original campaign in a rebuilt form.

• Provenance: explicit.
• Trigger/input: the Player enters the campaign from the Landing surface.
• Observable result: the recreated campaign is playable, with missions the Player can start and progress through.
• Access state: no identity required; the Campaign surface is reachable anonymously.
• Failure/recovery: if a mission fails to start, the mission board remains browsable and the Player can retry or choose another mission.
• Continuation: after a mission, the Player returns to the mission board and can start the next mission.
• Owner: Campaign.

FR-2 — Present the remake and its PSP portability before gameplay. As a Player, I should see what the remake is, who it is for, and that it is built for the PSP, so that I understand what I am about to play before I commit to it.

• Provenance: required_inference.
• Trigger/input: the Player arrives at the Landing surface.
• Observable result: the remake's identity, its intended player, and the PSP portability facts (480×272 render target, 32MB memory budget) are visible, alongside a live low-poly Halo ring scene and an entry CTA.
• Access state: anonymous; no identity required.
• Failure/recovery: if the WebGL scene cannot initialise, the headline, CTA, port micro-label, and port-spec band remain fully rendered and usable, and the hero holds a static three-quarter ring view.
• Continuation: the Player activates "ENTER THE CAMPAIGN" and arrives at the Campaign surface.
• Owner: Landing.

FR-3 — Start and play a campaign mission. As a Player, I should be able to select a mission from the campaign board and start playing it, so that I can progress through the recreated campaign.

• Provenance: required_inference.
• Trigger/input: the Player selects a mission tile on the Campaign surface.
• Observable result: the selected mission previews inside the PSP-shaped frame and the mission starts.
• Access state: no identity required.
• Failure/recovery: if the mission fails to start, the board stays browsable and the PSP frame returns to its empty state; the Player can retry or pick another mission.
• Continuation: the Player returns to the mission board after the mission and can start the next one.
• Owner: Campaign.

FR-4 — Browse and preview the campaign mission set. As a Player, I should be able to browse the campaign's missions and preview one before starting it, so that I can choose what to play next.

• Provenance: required_inference.
• Trigger/input: the Player hovers or selects a mission tile on the Campaign surface.
• Observable result: the tile tilts toward the pointer with spring overshoot and the mission previews inside the PSP-shaped frame.
• Access state: no identity required.
• Failure/recovery: if no mission is previewed, the PSP frame holds an empty coral-outlined viewport and the board remains fully browsable.
• Continuation: the Player starts the previewed mission or continues browsing.
• Owner: Campaign.

FR-5 — Express the PSP portability constraint in the interface. As a Player, I should see the PSP's 480×272 render target and 32MB memory budget reflected in the interface itself, so that the remake's handheld constraint is stated plainly rather than apologised for.

• Provenance: explicit (the remake must be portable to the PSP) + required_inference (its presentation).
• Trigger/input: the Player views the Landing port micro-label and port-spec band, or the Campaign PSP-shaped frame.
• Observable result: the 480×272 render target and 32MB budget are visible as interface chrome and diagrammatic imagery.
• Access state: anonymous; no identity required.
• Failure/recovery: these elements are static and remain rendered if the WebGL scene fails.
• Continuation: the Player proceeds to enter or play the campaign.
• Owner: Landing and Campaign.

FR-6 — Navigate between the remake's surfaces. As a Player, I should be able to move between the Landing surface and the Campaign surface, so that I can reach the campaign and return to the entry point.

• Provenance: required_inference.
• Trigger/input: the Player activates the entry CTA on Landing or the HUD navigation on Campaign.
• Observable result: the Player arrives at the intended surface.
• Access state: no identity required on either surface.
• Failure/recovery: if a navigation target fails to load, the current surface remains usable and the Player can retry.
• Continuation: the Player continues on the destination surface.
• Owner: Landing and Campaign.

4. User Personas

Player

Product context. The Player knows the original Halo: Combat Evolved campaign and wants to see it recreated at handheld scale. They arrive at the remake expecting a fan-built recreation, not a fidelity showcase, and they are the sole active human role the accepted premise supports.

Primary goal. To experience the recreated campaign gameplay on PSP-compatible hardware, progressing through the game's missions and combat encounters to completion.

Distinct accepted responsibilities. The Player is the only actor who initiates play. They read what the remake is and confirm its PSP portability on the Landing surface, then commit to the campaign by activating the entry CTA. On the Campaign surface they browse the mission set, preview a mission inside the PSP-shaped frame, select and start it, and return to the board to continue.

Relevant inputs and decisions. The Player decides whether the remake is what they came for, based on the headline, the port micro-label, and the port-spec band. They decide which mission to play next, based on the mission tiles and the preview inside the PSP frame.

Interactions with other accepted participants. There are none. The Player is the only active human role; the builder role belongs to development time and does not appear in-product. No other participant awaits, receives, or is affected by the Player's actions inside the product.

Observable success. The Player reaches the Campaign surface from the Landing CTA, selects a mission, sees it preview inside the PSP frame, starts it, and returns to the board to continue through the campaign.

5. Core User Flows

Flow 1 — Arriving and entering the campaign (Player)

1. The Player arrives at the Landing surface anonymously. No identity is requested or required.
2. The void ground and the headline block render first: "HALO / COMBAT / EVOLVED" in pale #E8F1F5 Fredoka, flush-left in three tight lines, with the coral "REMAKE" tag rotated -6° overlapping the first line's baseline.
3. The low-poly Halo ring renders in the hero, tilted at a three-quarter angle, bleeding off the right and bottom edges, its mass right-of-centre and the left third empty void. The ring rotates continuously.
4. The Player moves the pointer. The camera springs toward the cursor (stiffness 120, damping 18), and the ring's facets shift their coral rim light against the mint-cool shadow side.
5. The Player reads the port micro-label beside the CTA: "PSP BUILD — 480×272 — 32MB", and the port-spec band below with the PSP outline, poly-count bars, and top-down level map.
6. The Player activates the coral capsule CTA "ENTER THE CAMPAIGN" (3px bottom lip). The button plays its press response and the Player arrives at the Campaign surface.
7. Failure/recovery: if the WebGL scene cannot initialise, the headline, CTA, port micro-label, and port-spec band remain fully rendered and usable, and the hero holds a static three-quarter ring view. The Player can still complete step 6.
8. Continuation: the Player is now on the Campaign mission board.

Flow 2 — Browsing and previewing a mission (Player)

1. The Player is on the Campaign surface. The mission board renders as a 3-across grid of faceted mission tiles on desktop, 1-across at 375px, each tile 4:3 with its mission number oversized in the top-left corner at clamp(48px, 8vw, 96px) Fredoka.
2. The PSP-shaped HUD frame — a 480×272-proportioned viewport outline drawn in 1px coral — sits on the board. With no mission previewed, it holds an empty coral-outlined viewport.
3. The Player hovers a mission tile. The tile tilts in 3D toward the pointer with spring overshoot, and the mission previews inside the PSP frame.
4. The Player moves to another tile. The preview updates to that mission.
5. Failure/recovery: if a preview cannot be produced, the PSP frame returns to its empty coral-outlined state and the board remains fully browsable.
6. Continuation: the Player either starts the previewed mission (Flow 3) or keeps browsing.

Flow 3 — Starting and completing a mission (Player)

1. The Player is on the Campaign surface with a mission previewed inside the PSP frame.
2. The Player selects the mission tile. The tile plays its 180ms squash-and-stretch, and the mission starts.
3. The Player plays the recreated mission, progressing through its combat encounters.
4. The Player completes the mission and returns to the mission board. The board reflects their position in the campaign.
5. Failure/recovery: if the mission fails to start, the board stays browsable and the PSP frame returns to its empty state. The Player can retry the same mission or select another.
6. Continuation: the Player browses the board again (Flow 2) and starts the next mission.

Flow 4 — Navigating between surfaces (Player)

1. From the Landing surface, the Player activates the entry CTA and arrives at Campaign (Flow 1, step 6).
2. From the Campaign surface, the Player uses the HUD navigation — a persistent bottom HUD bar at 375px with four faceted icon buttons, migrating to a top-left corner cluster at 1280px — to return to Landing.
3. Failure/recovery: if a navigation target fails to load, the current surface remains usable and the Player can retry.
4. Continuation: the Player continues on the destination surface.

Flow 5 — Reduced-motion play (Player)

1. The Player arrives at Landing with prefers-reduced-motion active. The ring holds one static three-quarter view; the camera no longer springs toward the cursor; scroll-linked camera work becomes ordinary page scroll.
2. The Player reads the headline, port micro-label, and port-spec band, and activates the CTA.
3. On Campaign, mission tiles lose their 3D tilt and use a 120ms opacity change on hover; the squash-and-stretch on click is removed.
4. The Player browses, previews, and starts missions exactly as in Flows 2 and 3, with all content fully readable and every control fully operable.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. Muse: Bruno Simon — playable low-poly worlds, a 3D scene as the page itself, toy-box colour, chunky rounded type, physics you can feel. Headline: A playable low-poly Halo ring you drive across, built to ship on a PSP.

Colour tokens (dark mode).

Proportion: 70% void navy, 20% slate panels, 8% coral, 2% mint. No blue-indigo anywhere; every value is drawn from the ring's night-side palette.

Typography. Headings: Fredoka at 600–700 weight for all display type — wide, rounded, toy-box letterforms that read as chunky low-poly geometry. Headlines set in sentence case with very tight leading (0.92) and -0.01em tracking so multi-line stacks feel like stacked blocks. Uppercase micro-labels ("MISSION 03 — TRUTH AND RECONCILIATION") in Fredoka 500 at 12px with 0.14em tracking, used as HUD chrome. Body: Nunito Sans 400/600 at generous 1.65 line-height — rounded terminals keep the reading voice friendly next to Fredoka.

Type scale (1.25 modular): 12 / 14 / 16 / 20 / 25 / 31 / 39 / 49 / 61 / 76 / 96 / 120. Display headline clamp(40px, 9vw, 120px); section heads clamp(28px, 4.5vw, 49px); body 16–20px; HUD labels 12px.

Shape language. Low-poly geometry as the whole shape vocabulary: faceted planes, hard 120° edges, gem-cut corners. Cards are 20px-radius rounded blocks with a 1px inner highlight along the top edge so they read as lit poly faces. Buttons are 14px-radius capsules with a 3px bottom lip — a physical key you press. No gradient meshes; flat fills with a single lighter facet per surface. A recurring wireframe-overlay motif: thin 1px coral lines tracing a shape's triangulation, used as section dividers and around the hero ring.

Layout. Full-bleed scene-first: the WebGL ring occupies the top 78vh of the landing page, with UI floating over it as HUD chrome in the corners rather than sitting on a document. Below, sections alternate between a 12-column grid (mission cards, port-spec tables) and single full-width colour-block bands. The Campaign page is a mission-select board: 3-across on desktop, 1-across at 375px, each tile 4:3 with the mission number oversized in its top-left corner. Navigation is a persistent bottom HUD bar on mobile (thumb-reachable, PSP-like) that becomes a top-left corner cluster on desktop — never a centred navbar.

Imagery. Low-poly 3D as the only imagery: a faceted Halo ring with visible triangulation, a flat-shaded Master Chief silhouette (helmet, shoulder pauldrons, no face), a Warthog built from ~40 quads, a Covenant Elite in flat purple, a plasma pistol as a glowing faceted wedge. All rendered in-scene in Three.js with flat materials, no textures beyond a subtle vertex-colour variation. Supporting 2D imagery is diagrammatic: top-down level maps drawn in 1px coral line, poly-count bars, a PSP outline showing the 480×272 render target.

Avoid. Any blue-indigo primary or accent (#0057FF, #2563EB, #6366F1, #7C3AED and neighbours) on a white ground; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins or system-ui for headings or body; a centred headline + subtext + button + gradient-blob hero; photorealistic Halo renders, texture-mapped Master Chief, or anything implying fidelity the PSP build cannot deliver; gradient-mesh surfaces, glassmorphism panels, or frosted blur cards; a grid of identical hover-lift cards with the same shadow; marquee tickers or auto-rotating carousels that move content the user needs to read; copy that apologises for the low-poly look — the constraint is the aesthetic, stated plainly.

7. Signature Design Concept

The public entry is a scene with type carved into its void.

A full-bleed near-black void (#0B1014) holds a low-poly Halo ring rendered in Three.js, tilted at a three-quarter angle and bleeding off the right and bottom edges — roughly two-thirds of the ring is visible, its inner curve facing the viewer, each facet catching a coral rim light against a mint-cool shadow side. The ring is not centred: its mass sits right-of-centre, and the left third is empty void.

Into that void, flush-left, the headline stacks in three tight lines — "HALO / COMBAT / EVOLVED" — in pale #E8F1F5 Fredoka at clamp(40px, 9vw, 120px), leading 0.92, tracking -0.01em. A small coral "REMAKE" tag rotated -6° overlaps the first line's baseline. Beneath the headline sits a single coral capsule CTA, "ENTER THE CAMPAIGN", with a 3px bottom lip, and beside it a mint micro-label reading "PSP BUILD — 480×272 — 32MB". A bottom-left HUD strip shows three tiny faceted icons — shield, ammo, motion tracker — at 40% opacity. A 1px coral wireframe overlay traces the ring's triangulation.

There is no centred stack, no subtext paragraph, and no gradient blob. The ring rotates continuously and the camera springs toward the cursor, so the first frame the Player sees is a world they are standing on rather than a product shot — and the PSP's numbers are already on screen, stated plainly.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: webgl

Landing Hero Motion Brief

Focal subject. The low-poly Halo ring, tilted at a three-quarter angle, cropped off the right and bottom edges so it reads as a world you are standing on rather than a product shot.

Input → transformation → outcome thesis. The Player's pointer position is the input; the camera springs toward the cursor (stiffness 120, damping 18) while the ring rotates continuously on its own axis; the outcome is a hero that feels physically present and hand-built, with the ring's facets shifting their coral rim light against the mint-cool shadow side as the Player moves.

Motion vocabulary. Playable physics tempo. Continuous slow ring rotation. Spring-driven camera nudge toward the cursor. Scroll drives the camera down the ring's curve rather than translating the page. Hovering a mission tile tilts it in 3D toward the pointer with slight overshoot; clicking plays a 180ms squash-and-stretch. 1px coral wireframe lines trace the geometry throughout.

Composed first frame. Void #0B1014 fills the viewport. The ring's mass sits right-of-centre, bleeding off the right and bottom edges, inner curve facing the viewer. The left third is empty void holding the flush-left three-line Fredoka headline in #E8F1F5, the coral "REMAKE" tag rotated -6° on the first line's baseline, the coral capsule CTA with its 3px bottom lip, the mint "PSP BUILD — 480×272 — 32MB" micro-label, and the bottom-left HUD strip of three faceted icons at 40% opacity.

Reduced-motion state. The ring holds one static three-quarter view. The camera no longer springs toward the cursor. Tiles lose their 3D tilt and use a 120ms opacity change. All scroll-linked camera work becomes ordinary page scroll. Every headline, label, number, card, and control remains whole and fully readable at 375px, 768px, and 1280px.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

A single crafted real-time object: the Halo ring, built from flat-shaded faceted geometry with visible triangulation and no textures beyond subtle vertex-colour variation. It rotates slowly and continuously on its own axis. The camera springs toward the cursor with stiffness 120 and damping 18, and scroll drives the camera down the ring's curve. A 1px coral wireframe overlay traces the ring's triangulation. The ring is deliberately cropped off the right and bottom edges. Under prefers-reduced-motion, the scene holds one static three-quarter view and all camera motion stops.

9. Non-Functional Requirements

NFR-1 — PSP portability. The remake must be portable to the PlayStation Portable. Provenance: explicit. Rationale: this is the defining hard constraint of the project; the remake is built to be hand-ported to the PSP.

NFR-2 — PSP render target and memory budget. The remake targets a 480×272 render target and a 32MB memory budget. Provenance: explicit (the PSP portability constraint) + required_inference (the concrete figures the direction states). Rationale: these are the handheld's rendering and memory envelope, and the product presents them truthfully in the interface.

NFR-3 — Low-poly, flat-shaded rendering. All imagery is low-poly 3D rendered in-scene with flat materials and no textures beyond subtle vertex-colour variation. Provenance: explicit (creative direction). Rationale: the poly counts and flat-shaded geometry are the aesthetic, not a compromise to hide.

NFR-4 — Readable text and controls 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. Provenance: explicit (creative direction). Rationale: legibility and operability are non-negotiable even where imagery, decoration, and motion are cropped, bled, rotated, or overlapped by design.

NFR-5 — Reduced-motion support. Under prefers-reduced-motion, the ring holds one static three-quarter view, tiles lose tilt and use a 120ms opacity change, and all scroll-linked camera work becomes ordinary page scroll. Provenance: explicit (creative direction). Rationale: the experience must remain usable and fully readable without motion.

NFR-6 — Anonymous access. Neither the Landing nor the Campaign surface requires identity establishment. Provenance: required_inference. Rationale: no accepted behavior creates a durable actor-specific state, commitment, entitlement, or value transfer that must remain bound to a particular participant, so no application-owned identity is needed.

NFR-7 — No differentiated permissions. There is no RBAC, role-based visibility, or permission control over shared product state. Provenance: required_inference. Rationale: the source establishes no differentiated control or visibility, and the sole active human role is the Player.

10. Tech Stack

• Three.js (with React Three Fiber) for the real-time low-poly hero scene and in-scene imagery. Source: creative direction.
• React for the first-party custom interface. Source: delivery shape (custom_ui: true).
• Fredoka (headings, 600–700; HUD micro-labels, 500) and Nunito Sans (body, 400/600). Source: creative direction.
• PSP build target: 480×272 render target, 32MB memory budget. Source: explicit constraint.

11. Assumptions and Constraints

• A-1. The PSP port itself is a build and deployment concern owned by the builder, not an in-product workflow. The product's responsibility toward it is to present the portability constraint truthfully and to keep the experience within the handheld's rendering and memory envelope. (Assumption — narrow, consistent with the accepted premise.)
• A-2. The remake is a fan-built recreation of the Halo: Combat Evolved campaign. No multiplayer, storefront, social layer, level editor, or analytics capability is in current scope. (Assumption — narrow, consistent with the accepted premise.)
• A-3. No future-horizon requirements have been accepted; anything not stated in this document is out of current scope. (Assumption — narrow.)
• C-1. The remake must be portable to the PlayStation Portable. (Explicit hard constraint.)
• C-2. The remake targets a 480×272 render target and a 32MB memory budget. (Explicit constraint, concretised by the creative direction.)
• C-3. The generic indigo/blue-on-white SaaS template is forbidden for this project. (Explicit constraint.)
• C-4. Readable text and controls stay whole at every viewport; where a direction, requirement, or brief asks readable text or a control to be cropped, clipped, covered, or run off an edge, keep it whole and carry the gesture with imagery or decoration instead. (Explicit constraint.)

12. Glossary

• PSP — PlayStation Portable; the 333MHz handheld the remake is built to be ported to, with a 480×272 render target and a 32MB memory budget.
• Halo ring — the low-poly faceted ring that is the hero scene subject on the Landing surface.
• Mission tile — a faceted 4:3 card on the Campaign board carrying an oversized mission number in its top-left corner.
• PSP-shaped HUD frame — the 480×272-proportioned viewport outline drawn in 1px coral on the Campaign surface, inside which the current mission previews.
• HUD navigation — the persistent bottom HUD bar at 375px (four faceted icon buttons) that migrates to a top-left corner cluster at 1280px.
• Wireframe overlay — the recurring 1px coral lines tracing a shape's triangulation, used as section dividers and around the hero ring.
• Player — the sole active human role; the person who plays the remake on PSP-compatible hardware.
• Porter / Builder — the requester who ports the remake to PSP; a development-time role, not an in-product persona.