Platinum Platform Guide

Platinum is the shared browser-arcade platform that now hosts Aurora Galactica and is being prepared to host future sibling games such as Galaxy Guardians.

This is the canonical platform document.

Use it when the question is about:

• what Platinum is for
• what Platinum owns
• how games plug into it
• what still belongs to applications rather than the platform
• where the current seams are still imperfect
• what should improve as the second game firms up

Purpose

Platinum exists to separate the reusable arcade host from the specific games it runs.

That means Platinum should own the things that ought to be consistent across multiple games:

• shell framing and cabinet presentation
• hosted lane model and release identity
• platform contract versioning and compatibility policy
• pack selection and boot path
• common runtime, input, and session surfaces
• shared services such as auth, leaderboard transport, and feedback transport
• optional shell-owned media ambience such as Arcade Music
• shared documentation and release discipline
• platform-only harnesses and publish checks
• a stable control contract that lets players move between hosted games with

the same core input model

At the same time, Platinum should stay out of application-specific rules.

It should not own:

• Aurora scoring rules
• Aurora capture and rescue behavior
• Aurora challenge-stage structure
• Aurora-specific copy, stage identity, or boss personality
• game-specific semantic version increments or conformance claims except as

displayed metadata sourced from the owning application

Architectural Invariant: No Direct Game-To-Game Sharing

Games on Platinum should not share game-specific code, rule tables, state, assets, mechanics, or capabilities directly with each other.

If a behavior is common to more than one game, that commonality belongs in Platinum as a named API, interface, service, capability flag, harness substrate, or versioned contract. Applications may depend on Platinum contracts; they should not depend on another application's implementation.

In practical terms:

• Aurora changes must not affect Galaxy Guardians except through intentional

Platinum contract changes

• Galaxy Guardians changes must not affect Aurora except through intentional

Platinum contract changes

• future games must receive reusable behavior through Platinum extension points,

not sideways imports from Aurora or Galaxy Guardians

• game-owned mechanics such as capture/rescue, dual-fighter mode, challenge

stages, flagship escorts, alien movement, scoring, visual identity, sound cues, and event vocabulary stay inside the owning game pack

The current audit for this boundary is:

• /Users/steven/Documents/Codex-Test1/PLATINUM_GAME_BOUNDARY_AUDIT.md

What Platinum Is Today

Today Platinum is a real shipped platform, not a speculative refactor.

Current proof points:

• Aurora Galactica ships as the first playable Platinum application on hosted /production
• hosted lanes now exist for:
  • local localhost
  • hosted /dev
  • hosted /beta
  • hosted /production
• the shell supports pack selection and pack-owned framing accents
• Galaxy Guardians exists as a preview-first second-game slice on top of the

same platform, with the next post-production branch now targeting a minimally complete one-level playable game

• the second-game preview content is now pack-owned instead of hardcoded into

the shell surface

• platform-only harnesses exist alongside Aurora gameplay harnesses
• the build pipeline now generates hosted documentation pages as first-class release artifacts
• the settings/configuration panel exposes the bundled read-only conformance

dashboard in hosted dev, beta, and production lanes while raw ingestion workspaces remain engineering-owned

Platform Structure

Shell and presentation

Platinum owns the outer cabinet treatment:

• marquee housing
• left and right rails
• lower status band
• popup framing
• shell frame themes
• platform identity marks
• platform-owned startup and wait-mode shell copy
• release-cycle shell messaging that can span more than one application

This is implemented primarily through:

• /Users/steven/Documents/Codex-Test1/src/index.template.html
• /Users/steven/Documents/Codex-Test1/src/styles.css
• /Users/steven/Documents/Codex-Test1/src/js/19-render-shell.js
• /Users/steven/Documents/Codex-Test1/src/js/00-boot.js

Runtime and pack hosting

Platinum owns the pack selection and boot contract:

• active pack selection
• preview-only pack behavior
• start behavior from the shell
• wait-mode hosting rules
• fullscreen and scaling shell behavior

This is implemented primarily through:

• /Users/steven/Documents/Codex-Test1/src/js/00-boot.js
• /Users/steven/Documents/Codex-Test1/src/js/01-runtime-shell.js
• /Users/steven/Documents/Codex-Test1/src/js/15-game-picker.js

Shared services

Platinum owns shared service boundaries that should not be rewritten for each pack:

• auth and pilot-session adapters
• leaderboard fetch and submit policy
• feedback transport policy
• replay/session plumbing
• opt-in Arcade Music playback policy
• shared replay/video-capture/export path as it matures

This is implemented primarily through:

• /Users/steven/Documents/Codex-Test1/src/js/03-platform-services.js
• /Users/steven/Documents/Codex-Test1/src/js/04-leaderboard-ui.js
• /Users/steven/Documents/Codex-Test1/src/js/11-leaderboard-service.js
• /Users/steven/Documents/Codex-Test1/src/js/12-auth-session.js
• /Users/steven/Documents/Codex-Test1/src/js/02-replay-telemetry.js

Shared contracts

Platinum currently depends on a shared application contract that is real in practice even though it still needs further formalization.

The main contract areas are:

• game-pack identity
• game-pack version and platform-compatibility fields
• shell theme selection
• supported capabilities
• entity model compatibility
• stage and scoring hooks
• application-owned front-door identity surfaces shown by the shell
• platform-owned startup, wait-mode, and release-cycle shell copy
• application-aware use of pilot sign-in, scores, replay/video capture,

bug-report transport, and music controls inside the shared frame

See also:

• /Users/steven/Documents/Codex-Test1/src/js/13-aurora-game-pack.js
• /Users/steven/Documents/Codex-Test1/src/js/14-entity-model.js
• /Users/steven/Documents/Codex-Test1/PLATINUM_INTERFACE_REVIEW.md

Applications On Platinum

Platinum should be thought of as the host layer.

Applications on Platinum are the games.

Current application set:

• Aurora Galactica
  • first shipped playable application
  • owns game rules, scoring, challenge cadence, capture and rescue, stage flow, and Aurora-branded content
• Galaxy Guardians
  • current preview-first application shell on the shipped line
  • next branch target: a minimally complete one-level playable game with its

own score identity, ending flow, and platform-validation value

The application-side separation is documented in:

• /Users/steven/Documents/Codex-Test1/APPLICATIONS_ON_PLATINUM.md

As the second game firms up, Platinum should prove not only that it can host a different ruleset, but that it can host that game through the same class of platform-owned frame capabilities Aurora already uses:

• pilot sign-in and pilot-card surfaces
• high scores, leaderboard, trophy, and pilot-record surfaces
• replay and future video-capture/export surfaces
• bug-report and feedback transport surfaces
• Arcade Music, SFX, and volume/mute controls

These should feel like platform capabilities with game-aware rendering, not Aurora-only conveniences.

Platform Is Host, Not Prison

Platinum is the current host and public release shell.

It should not become the only imaginable way a game can exist.

The design goal is:

• a game should be ingestible into Platinum through a strong pack contract
• the game's own runtime, rules, identity, evidence, and versioning should stay

game-owned

• those game-owned artifacts should be understandable and reusable outside the

Platinum shell if we later want a thinner host or standalone launch surface

• Platinum should be the host layer that makes this easier, not a conceptual

trap that forces every game to be defined only in platform terms

How To Use Platinum In Practice

When we work on the repo, the right question is usually:

• is this platform work
• or application work

Treat a change as Platinum work when it affects:

• more than one pack
• the hosted lane model
• shell framing
• shared services
• release tooling
• shared docs and project pages
• pack-loading or pack-contract behavior
• same-control compliance across multiple hosted games
• persona-vs-player orchestration that should work for more than one pack

Treat a change as application work when it affects:

• Aurora rules and scoring
• Aurora enemy behavior
• Aurora stage flow
• Aurora presentation that is not part of the shared shell
• future Galaxy Guardians rules and content

Remaining Platform And Application Boundary Issues

The separation is real, but not perfect yet.

Current remaining seams to keep visible:

• some storage and compatibility names are still Aurora-shaped even when they are effectively platform-owned
• some debug globals and legacy naming still reflect the older single-game architecture
• the game-pack contract is practical but not yet strongly versioned
• the current second-game preview still borrows Aurora-owned rule and theme

tables while it is non-playable; those must become Galaxy Guardians-owned or Platinum-owned before a playable second-game preview

• some shell copy and application copy still need stronger structural validation so release-time regressions are caught automatically
• the second application is still preview-only, so the contract is proven with one real game and one shell-only preview rather than two full implementations

These are not reasons to collapse the separation again.

They are reasons to keep the seam explicit while we strengthen it.

Platform Future Areas Of Improvement And Notes

As the second game firms up, Platinum should improve in these areas:

1. Formal pack schema

We should move from an implicit pack shape to a more explicit, versionable contract.

Desired outcome:

• clearer required fields
• clearer optional capability flags
• explicit platform-compatibility and game-version fields
• forward-compatible pack evolution
• earlier validation failures during boot

1b. Multi-game ingestion workflow

We should get better at ingesting a second classic game lineage by turning preserved footage, manuals, timing libraries, and comparison artifacts into a repeatable pack-construction workflow. This workflow is part of the conformance project, not a separate research sidecar.

Desired outcome:

• a new game can be analyzed in all major aspects with minimal user

intervention once the reference corpus exists

• the ingestion flow yields game-owned manifests, conformance artifacts, and

versioned runtime packages rather than only platform-specific glue

• the first playable phases are derived from external artifacts, semantic event

logs, and correspondence targets before subjective design tuning

• Platinum can propose its own extension points where needed instead of

forcing every new mechanic into Aurora-shaped structures

• the second game grows from a durable reference program rather than from

ad hoc interpretation

• a game can launch through Platinum now while remaining portable to a thinner

host later if we choose

2. Storage and migration policy

We should decide more intentionally what is:

• permanently aliased
• migrated once
• never migrated
• clearly platform-owned versus application-owned data

3. Shared control compliance

As additional games come online, Platinum should protect a common player-input contract:

• same basic move / fire semantics
• pack-specific variation only where it is intentional and documented
• harness coverage for any platform-level input differences

This matters both for human players and for future persona-driven play.

4. Persona and simulated opponents

Platinum should eventually support more than passive replay personas.

Desired outcome:

• personas are generic platform-level skill profiles that can play multiple

games through game-owned adapters and scenario definitions

• repeated seeded persona runs produce distribution evidence for score, stage

depth, time alive, losses, and challenge/reward performance

• game packs can expose enough action/state annotation for richer personas
• a player can compete against curated persona styles as a Player 2-like

experience

• future learn-by-playing personas can train through simulation while still

respecting platform contracts and pack-specific rules

3. Platform-first documentation discipline

Every meaningful x.y release should have:

• refreshed release notes
• refreshed roadmap and readiness docs
• refreshed hosted project guide
• refreshed hosted Platinum guide
• clear testing and gating status
• explicit notes on any remaining platform/application coupling

4. Cleaner multi-application proof

The best next platform proof is not a huge second-game launch.

The current first step is a pack-owned Galaxy Guardians sneak peek that proves:

• the picker can expose a second application
• preview content can live in the pack contract
• the shell can show alternate identity and status without persisting a

preview-only trap state

• launch fallback can return players to the playable Aurora cabinet

The next step is a small but playable second application slice that proves:

• the pack contract is real
• platform services stay shared
• application rules remain application-owned
• platform docs still describe reality after a second game exists

Hosted Documentation Surfaces

The main hosted documentation surfaces are now:

• hosted /production project guide:
  • https://sgwoods.github.io/Aurora-Galactica/project-guide.html
• hosted /production Platinum guide:
  • https://sgwoods.github.io/Aurora-Galactica/platinum-guide.html
• hosted /production player guide:
  • https://sgwoods.github.io/Aurora-Galactica/player-guide.html
• hosted /production release dashboard:
  • https://sgwoods.github.io/Aurora-Galactica/release-dashboard.html

Equivalent hosted docs should exist on hosted /dev and hosted /beta as part of the normal release flow.

Related Docs

• maintained platform overview and diagrams:
  • /Users/steven/Documents/Codex-Test1/PLATINUM_ARCHITECTURE_OVERVIEW.md
• application-side separation and usage:
  • /Users/steven/Documents/Codex-Test1/APPLICATIONS_ON_PLATINUM.md
• game boundary audit:
  • /Users/steven/Documents/Codex-Test1/PLATINUM_GAME_BOUNDARY_AUDIT.md
• repo technical map:
  • /Users/steven/Documents/Codex-Test1/ARCHITECTURE.md
• release and testing gate discipline:
  • /Users/steven/Documents/Codex-Test1/TESTING_AND_RELEASE_GATES.md
• launch art direction:
  • /Users/steven/Documents/Codex-Test1/PLATINUM_LAUNCH_ART_DIRECTION.md
• forward-looking architecture review:
  • /Users/steven/Documents/Codex-Test1/PLATINUM_LUECK_REVIEW.md

This document is the maintained short visual overview of how Platinum relates to the applications it hosts.

Use it for the fast answer to:

• what Platinum is
• what Platinum owns
• what applications own
• where the current migration stands

For the canonical full platform guide, use:

• /Users/steven/Documents/Codex-Test1/PLATINUM.md

Diagram

flowchart TB
    subgraph "Platinum Platform"
        P1["Cabinet Shell and Layout\n- marquee\n- side rails\n- build stamp\n- popup framing"]
        P2["Runtime and Input\n- boot path\n- active pack selection\n- pause and wait mode\n- fullscreen and scaling"]
        P3["Shared Services\n- auth and session adapters\n- leaderboard policy\n- feedback transport\n- replay plumbing"]
        P4["Platform Harnesses\n- pack boot proof\n- shell and popup checks\n- dock button checks\n- lane and publish checks"]
        P5["Shared Contracts\n- gamePack\n- shell themes\n- entity contract\n- content surfaces"]
    end

    subgraph "Aurora Galactica Application"
        A1["Application Identity\n- title\n- front-door copy\n- shell accents\n- stage branding"]
        A2["Gameplay Rules\n- formations\n- stage flow\n- challenge cadence\n- scoring"]
        A3["Aurora Mechanics\n- capture and rescue\n- dual fighter\n- boss and escort behavior\n- challenge-stage motion"]
        A4["Aurora Assets and Content\n- sprites\n- audio identity\n- stage text\n- game-owned polish"]
        A5["Aurora Harnesses\n- challenge profile\n- capture lifecycle\n- scoring and outcome checks"]
    end

    subgraph "Future Applications"
        G1["Galaxy Guardians\n- future sibling title\n- currently preview only"]
        G2["Other Future Packs\n- their own rules\n- their own content\n- their own harnesses"]
    end

    P5 --> A1
    P5 --> A2
    P5 --> A3
    P5 --> A4
    P5 --> G1
    P5 --> G2

    P1 --> A1
    P2 --> A2
    P3 --> A5
    P4 --> A5

    G1 -. hosted by .-> P2
    G2 -. hosted by .-> P2

Current Read

Today the architecture is in this state:

• Platinum is real and visible in the shipped product
• Aurora Galactica is the first playable application on Platinum
• Galaxy Guardians exists as a preview-only sibling application shell
• hosted docs now need to describe the platform separately from the applications it hosts

Boundary Principle

Applications do not share game-specific implementation directly. If Aurora, Galaxy Guardians, or a future pack needs common behavior, that behavior should move into Platinum as an explicit API, interface, capability, service, contract, or harness helper. Game-owned rules, scoring, movement, visual identity, sound cues, and event vocabulary stay with the owning application.

Related Docs

• canonical platform guide:
  • /Users/steven/Documents/Codex-Test1/PLATINUM.md
• application-layer guide:
  • /Users/steven/Documents/Codex-Test1/APPLICATIONS_ON_PLATINUM.md
• game boundary audit:
  • /Users/steven/Documents/Codex-Test1/PLATINUM_GAME_BOUNDARY_AUDIT.md
• repo technical map:
  • /Users/steven/Documents/Codex-Test1/ARCHITECTURE.md
• release and testing discipline:
  • /Users/steven/Documents/Codex-Test1/TESTING_AND_RELEASE_GATES.md
• launch art direction:
  • /Users/steven/Documents/Codex-Test1/PLATINUM_LAUNCH_ART_DIRECTION.md
• forward-looking review:
  • /Users/steven/Documents/Codex-Test1/PLATINUM_LUECK_REVIEW.md

This document describes the application layer that sits on top of the Platinum platform.

Use it when the question is not "what does the platform own" but instead:

• which games currently exist on Platinum
• what a game application is responsible for
• where platform and application boundaries are still imperfect
• how future applications should use the platform without re-entangling it

Current Applications

Aurora Galactica

Aurora Galactica is the first real application on Platinum.

Aurora owns:

• player rules and scoring
• stage progression and challenge cadence
• capture and rescue logic
• dual-fighter behavior
• enemy behavior and boss identity
• Aurora-specific copy, stage mood, and content
• Aurora gameplay harnesses

Aurora should remain the reference application when we ask:

• does the platform still host a real shipped game cleanly
• can application-specific rules evolve without breaking the shell or release lanes

Galaxy Guardians

Galaxy Guardians is currently a preview-first second-game application and sneak peek on the shipped line, while the active post-production iMac branch now targets it as both a minimally complete one-level playable game and a first-class conformance target.

Right now it proves:

• application selection
• preview-only behavior inside the platform
• alternate identity and framing
• future second-game positioning
• pack-owned preview content for the picker and preview modal
• pack-owned placeholder timing, audio, visual, cadence, layout, and scoring

tables that do not directly borrow Aurora tables

• a disabled, evidence-gated gameplay adapter skeleton with its own initial

state shape

• a visible preview board renderer that drives the Guardians-owned scout-wave

runtime, visual catalog, and audio cue catalog without registering a public playable adapter

• a hosted-lane playable-preview adapter that routes keyboard movement,

single-shot fire, life loss, reset, and game-over flow into the Guardians-owned runtime on development, beta, and production lanes while keeping the public playable adapter disabled

• a source-manifested Galaxian reference profile with three local source videos,

contact sheets, and waveforms

• safe public-pack behavior because Galaxy Guardians still has no public

registered gameplay adapter

It does not yet prove:

• a second full gameplay ruleset
• a second complete scoring and stage-flow implementation
• a second complete application harness family
• a public registered gameplay adapter
• release-ready public playability

That is intentional.

Current branch-level next step:

• GALAXY_GUARDIANS_PLAYABLE_0_1_BRANCH_PLAN.md
• GALAXY_GUARDIANS_FIRST_CLASS_CONFORMANCE_PLAN.md
• GALAXY_GUARDIANS_LONG_SURFACE_AND_PERSONA_PLAN.md
• own scores and pilot/replay identity
• proper one-level completion and game-over endings
• platform-frame parity for sign-in, high scores, pilot card, replay/video

capture, bug reports, and Arcade Music/SFX controls

• enough completeness to validate Platinum changes against two real games
• keep the aggregate first-class conformance gate green:

npm run harness:check:galaxy-guardians-first-class-conformance

Application Responsibilities

A Platinum application should own:

• gameplay rules
• scoring and stage progression
• game-specific presentation and content
• alien/enemy catalog entries, audio cue catalog entries, stage summaries, and

game-owned persona expectations in GAME_CONFORMANCE_CATALOG.md

• application identity on the front door such as title and feature line
• its own version line and changelog
• its own conformance artifacts and readiness gates
• its own harnesses for game behavior
• its own longer-surface review logic when the game grows beyond a single

playable slice

• its own clean mapping into shared platform surfaces such as high scores,

pilot records, replay/video capture, bug reports, and music controls

• optional shell preferences that remain within the platform shell contract

A Platinum application should not own:

• the shared hosted release ladder or authority mechanism
• the shared hosted docs system
• shared auth or score transport policy
• shell layout regions
• lane publishing rules
• platform-only boot and pack-selection behavior
• startup and wait-mode shell copy that promotes the platform or other applications

Application Release Identity

Each application should be tracked as its own release surface even when it is currently shipped inside one Platinum bundle.

At minimum, that means each application should eventually carry:

• an application version
• a declared compatibility target for the Platinum contract version
• game-owned release notes or change history
• game-owned conformance artifacts and scorecards where relevant
• game-owned alien, audio, stage, and persona catalog rows
• game-owned candidate and regression harness definitions

The integrated bundle should then record which exact application versions it contains, rather than pretending the bundle version alone explains everything.

Game-To-Game Isolation Rule

Applications must not depend on each other's game-specific implementation.

Aurora Galactica may not be the hidden source of Galaxy Guardians mechanics, scoring, aliens, sound cues, visual identity, event vocabulary, or gameplay harness behavior. Galaxy Guardians should likewise never become a source of Aurora behavior. If both applications need the same thing, we should raise that thing into Platinum and expose it through a deliberate platform contract.

Allowed reuse:

• Platinum shell APIs
• Platinum input contracts
• Platinum audio engine capabilities
• Platinum event/replay/session substrate
• Platinum service adapters
• Platinum pack schema and capability flags
• documented platform harness helpers

Disallowed reuse:

• one game's scoring table inside another game
• one game's enemy movement model inside another game
• one game's capture, rescue, dual-fighter, challenge, flagship, escort, or

stage progression logic inside another game

• one game's visual or sound identity catalog as another game's default
• one game's application harnesses as proof of another game's behavior

See also:

• /Users/steven/Documents/Codex-Test1/PLATINUM_GAME_BOUNDARY_AUDIT.md

Current Boundary Notes

The boundary is real, but these coupling areas still deserve attention:

Direct game-to-game sharing risk

The current second-game preview is safe because it is not playable, and its preview pack now owns placeholder data instead of borrowing Aurora-owned tables. It also has no public gameplay adapter, so it cannot start through Aurora's gameplay implementation by accident. Its disabled adapter skeleton now cites the first source-manifested Galaxian profile and a promoted reviewed event log for the future scout-wave slice, but a playable Galaxy Guardians slice still needs frame-level timing, measured game-specific pack data, and its own registered adapter, with any true common behavior promoted into Platinum.

Preview pack persistence

Preview-first applications must not become a durable trap state. During development or beta a preview application may also expose an explicit non-production playable adapter so we can test the runtime slice before public production playability.

Current expected behavior:

• preview application can be opened
• shell can show its promo surface
• Enter should fall back to a playable application when preview-only content

cannot start gameplay

• Enter may start a non-production preview only when the development or beta

build exposes an explicit preview adapter and the pack still remains publicly non-playable

Front-door copy ownership

The shell front door now needs a firmer split than it had during the single-game era.

The direction is:

• platform copy explains the host, hosted lanes, docs, and cross-application surfaces
• application copy explains gameplay, identity, and game-specific flavor
• preview-only applications may override platform copy only when the override is still about preview status rather than gameplay rules

Shared frame parity

The shell should not make Aurora feel first-class while other games feel like guests.

For Guardians to count as a serious second application, the shared frame should support it across the same families of platform capability Aurora already uses:

• pilot sign-in and pilot-card framing
• high-score, leaderboard, trophy, and pilot-record surfaces
• replay and future video-capture/export surfaces
• bug-report and feedback transport surfaces
• Arcade Music, SFX, and mute/volume controls

Those surfaces remain platform-owned, but they must become application-aware and game-key-clean instead of implicitly assuming Aurora.

Shared naming residue

Some older names remain Aurora-shaped even when they are now functionally part of the platform.

These should be treated as transitional, not as permission to blur the boundary again.

The current code-review snapshot for this seam is also captured in:

• /Users/steven/Documents/Codex-Test1/PLATINUM_INTERFACE_REVIEW.md

How Future Applications Should Arrive

A new Platinum application should ideally arrive in stages:

1. reference-ingestion package

• source gameplay videos
• manuals or descriptive artifacts where available
• game-owned manifests, contact sheets, timing windows, waveforms, and other

conformance evidence

• reference-side event logs, semantic profiles, confidence notes, and initial

scorer targets

• a clear statement of which behaviors are evidence-backed, low-confidence, or

intentionally deferred

1. shell preview

• name
• framing
• coming-soon or preview status

1. minimal playable slice

• enough real rules to prove the platform seam
• not a rushed full public release
• implementation choices traceable back to the ingestion package rather than

copied from Aurora or invented as user design

1. application-owned harnesses

• rules and scoring checks
• outcome/distribution checks if difficulty matters

1. independent application candidate path

• explicit game version
• explicit platform compatibility target
• game-owned readiness and conformance evidence

1. polished public release path

• only after the application is truly ready

Current Application Outlook

Aurora next application work

Near-term Aurora application work should now focus on:

• movement fidelity
• audio identity polish
• gameplay trust fixes such as boss/capture/carry edge cases
• replay and pilot-surface improvements
• shell and overlay polish that remains application-owned

Galaxy Guardians next proof

The current shipped sneak peek is intentionally still production-framed as a preview. On the new iMac post-production branch, the next proof is no longer "keep it preview-only." The next proof is to make it honestly playable as a minimal one-level game while still keeping the public maturity claim modest.

The first non-production runtime slice is now underway as an application-owned model, not a public adapter. It creates a Galaxian-inspired scout-wave rack, enforces single-shot firing, emits promoted event names, scores against a Guardians-owned alien catalog, and keeps Aurora capture, challenge, dual-fighter, and scoring state out of the model.

Galaxy Guardians also now owns its first identity catalogs rather than borrowing Aurora's look or sound names. The visual catalog names the Signal Flagship, Signal Escort, Signal Scout, and Guardian Interceptor silhouettes. The audio cue catalog names the start chirp, formation pulse, single-shot player fire, enemy shot, scout/flagship dive pressure, escort join, hit cues, wrap/return cue, and future player-loss cue. These are still synthesized starting points, but they give the 0.1 slice separate application-owned contracts before any public playability.

The runtime model now has a visible preview renderer. It draws the Guardians scout-wave board, single player shot, alien silhouettes, and preview HUD from Guardians-owned runtime state and catalog IDs while keeping the pack publicly non-playable. The compact cabinet harness verifies the renderer by checking the preview mode, registered renderer key, visual IDs, audio cue IDs, and distinct signal palette. The renderer is now registered through a Platinum game-board renderer registry, so the top-level render loop no longer branches on a specific game by name.

The next application proof is maturing the first playable slice into a minimally complete game loop. That means the existing lifecycle path should now grow beyond preview-only framing and earn:

• own score identity
• proper completion ending
• proper loss ending
• clean restart and result behavior
• platform validation value as a second real game
• a readable first-class conformance target and review story rather than only a

scattered preview harness set

• a readable game arc and stage-band progression that can later support

source-grounded homage variants without losing the original flavor, as now described in GALAXY_GUARDIANS_STAGE_ARC_AND_HOMAGE_PLAN.md

The first aggregate 0.1 candidate gate is already source-controlled, so future playable claims can cite one durable artifact instead of reassembling the visual, audio, movement, threat, and boundary evidence from memory.

That candidate gate is now paired with a first-class conformance target and aggregate parity check:

• GALAXY_GUARDIANS_FIRST_CLASS_CONFORMANCE_PLAN.md
• npm run harness:check:galaxy-guardians-first-class-conformance

• formation rack
• dives
• flagship and escort behavior
• scoring
• single-shot constraint
• wrap-around threat
• life loss and game over flow

Current hosted-lane playable-preview coverage:

• src/js/13-galaxy-guardians-gameplay-adapter.js owns the hosted-preview

start and update adapter for Galaxy Guardians

• src/js/13-galaxy-guardians-runtime.js owns the runtime state, events, player

shot, life-loss, reset, and game-over mechanics

• src/js/13-gameplay-adapter-registry.js keeps public playable adapters and

hosted preview adapters in separate registries

• reference-artifacts/analyses/galaxy-guardians-identity/audio-character-0.1.json

persists the first cue-shape and runtime-audio coverage contract for the Guardians signal theme

• tools/harness/check-galaxy-guardians-audio-character.js proves the required

cue names, cue IDs, cue-shape metrics, role-hit separation, and runtime cue coverage for the first playable-preview slice

• reference-artifacts/analyses/galaxy-guardians-identity/identity-baseline-0.1.json

persists the first 0.1 visual/audio identity contract so future sprite, movement, and cue edits have a durable artifact trail

• reference-artifacts/analyses/galaxy-guardians-identity/formation-entry-0.1.json

persists the first runtime entry/settle contract for promoted Galaxian entry events, including start, settle, rack-complete, and first-dive-after-rack bands

• tools/harness/check-galaxy-guardians-formation-entry.js proves the runtime

starts aliens off-rack, settles them into the scout-wave rack, and prevents the first dive from starting before rack completion

• reference-artifacts/analyses/galaxy-guardians-identity/movement-pacing-0.1.json

persists the first movement and pressure pacing contract for solo dives, flagship/escort attacks, and bottom wrap/return cycles

• reference-artifacts/analyses/galaxy-guardians-identity/threat-scoring-0.1.json

persists the first lower-field threat and application-owned scoring contract for enemy shots, player loss, and formation/dive hit values

• reference-artifacts/analyses/galaxy-guardians-identity/visual-readability-0.1.json

persists the first gameplay-scale readability contract for the flagship, escort, scout, player, and role-specific hit flashes

• tools/harness/check-galaxy-guardians-visual-readability.js proves the

Guardians visual rows stay distinct, use enough palette channels, appear during entry/formation/dive snapshots, and create owned hit flashes

• reference-artifacts/analyses/galaxy-guardians-identity/candidate-0.1.json

persists the first aggregate 0.1 candidate gate for owned visual IDs, runtime cue IDs, promoted event names, public-playable boundaries, and forbidden Aurora capabilities

• tools/harness/check-galaxy-guardians-0-1-candidate.js proves the aggregate

0.1 gate without launching a browser by deterministically forcing scout, escort, flagship, enemy-shot, wrap-return, player-loss, and game-over runtime evidence

• tools/harness/check-galaxy-guardians-identity-baseline.js proves the

identity artifact matches the pack-owned sprite rows, audio cue catalog, audio theme cues, runtime cue map, and preview audio history

• tools/harness/check-galaxy-guardians-movement-pacing.js proves the runtime

rules match the persistent movement artifact and that flagship dives attach real escort craft in sampled runtime state

• tools/harness/check-galaxy-guardians-threat-scoring.js proves the runtime

rules match the persistent threat/scoring artifact and that enemy-shot pressure, player loss, and owned point values are active

• tools/harness/check-galaxy-guardians-playable-preview.js proves keyboard

fire, life loss, reset, game over, owned audio cue IDs, and public-adapter isolation

That is enough to test the platform without prematurely shipping a second game.

Before the slice becomes playable, refine the existing Galaxian evidence into runtime-ready rules:

• frame-level formation-entry and dive timing bands
• flagship and escort behavior windows
• scoring table and single-shot constraints
• an application-owned harness plan for the first scout-wave slice
• visual/audio identity notes that are distinct from Aurora, with the current

catalog entries refined by frame-level and waveform evidence before public playability

Use the reusable ingestion process in:

• CLASSIC_ARCADE_INGESTION_FRAMEWORK.md
• GAME_CONFORMANCE_CATALOG.md

That means the first scout-wave slice should be traceable through source manifest, clipped window, event log, semantic model, correspondence target, and harness evidence. The point is to learn Galaxy Guardians and also prove the method we will reuse for later games.

Longer-term, that same game-owned evidence chain should support a world where a game can launch through Platinum or through a thinner dedicated host without rewriting the underlying conformance package.

Related Docs

• platform overview and ownership:
  • /Users/steven/Documents/Codex-Test1/PLATINUM.md
• platform diagrams:
  • /Users/steven/Documents/Codex-Test1/PLATINUM_ARCHITECTURE_OVERVIEW.md
• repo technical map:
  • /Users/steven/Documents/Codex-Test1/ARCHITECTURE.md
• release and testing discipline:
  • /Users/steven/Documents/Codex-Test1/TESTING_AND_RELEASE_GATES.md

This document is the repo-level technical map.

Use it when the question is:

• where in the codebase does something live
• what is platform-owned versus application-owned in implementation terms
• how do builds, hosted docs, and lane promotion work
• where do harnesses and review tools fit into the system

For the canonical platform document, start with:

• /Users/steven/Documents/Codex-Test1/PLATINUM.md

For the application-layer view, use:

• /Users/steven/Documents/Codex-Test1/APPLICATIONS_ON_PLATINUM.md

Current State

This repo is now post-1.2.0, not pre-launch.

What is already true:

• Platinum is a real shipped host platform
• Aurora Galactica is the first shipped playable application on Platinum
• hosted lanes exist for local localhost, hosted /dev, hosted /beta, and hosted /production
• the hosted documentation set is now part of the intended release surface

What is still transitional:

• some naming and compatibility residue is still Aurora-shaped
• the game-pack contract is still practical rather than strongly versioned
• the second application is still public-preview-only rather than fully

shipped; it now has a hosted-lane playable-preview adapter for release-lane runtime proof

• the second-game preview now owns placeholder pack data, but playable

second-game work still needs measured game data and a gameplay adapter rather than Aurora gameplay reuse

Runtime Layout

Platform-oriented files

• shell, metadata, build identity, shared UI state:
  • /Users/steven/Documents/Codex-Test1/src/js/00-boot.js
• runtime shell helpers:
  • /Users/steven/Documents/Codex-Test1/src/js/01-runtime-shell.js
• replay and session plumbing:
  • /Users/steven/Documents/Codex-Test1/src/js/02-replay-telemetry.js
• shared service policy:
  • /Users/steven/Documents/Codex-Test1/src/js/03-platform-services.js
• shared leaderboard and account UI helpers:
  • /Users/steven/Documents/Codex-Test1/src/js/04-leaderboard-ui.js
• shared auth/session helpers:
  • /Users/steven/Documents/Codex-Test1/src/js/12-auth-session.js
• shared pack selection:
  • /Users/steven/Documents/Codex-Test1/src/js/15-game-picker.js
• shared pack registry and active-pack helpers:
  • /Users/steven/Documents/Codex-Test1/src/js/13-game-pack-registry.js
• shared gameplay adapter registry:
  • /Users/steven/Documents/Codex-Test1/src/js/13-gameplay-adapter-registry.js
• shared shell rendering:
  • /Users/steven/Documents/Codex-Test1/src/js/19-render-shell.js
• shared game-board renderer registry and dispatch:
  • /Users/steven/Documents/Codex-Test1/src/js/20-render.js
• harness hooks and deterministic controls:
  • /Users/steven/Documents/Codex-Test1/src/js/90-harness.js

Aurora application files

• Aurora player flow and lifecycle:
  • /Users/steven/Documents/Codex-Test1/src/js/05-player-flow.js
• Aurora combat and bullet behavior:
  • /Users/steven/Documents/Codex-Test1/src/js/05-player-combat.js
• Aurora enemy behavior:
  • /Users/steven/Documents/Codex-Test1/src/js/06-enemy-behavior.js
• Aurora capture and rescue:
  • /Users/steven/Documents/Codex-Test1/src/js/07-capture-rescue.js
• Aurora scoring and bonus helpers:
  • /Users/steven/Documents/Codex-Test1/src/js/08-score-awards.js
• Aurora stage flow:
  • /Users/steven/Documents/Codex-Test1/src/js/09-stage-flow.js
• Aurora gameplay orchestration:
  • /Users/steven/Documents/Codex-Test1/src/js/10-gameplay.js
• Aurora pack metadata:
  • /Users/steven/Documents/Codex-Test1/src/js/13-aurora-game-pack.js
• Galaxy Guardians preview pack metadata:
  • /Users/steven/Documents/Codex-Test1/src/js/13-galaxy-guardians-game-pack.js
• Galaxy Guardians disabled gameplay adapter skeleton:
  • /Users/steven/Documents/Codex-Test1/src/js/13-galaxy-guardians-gameplay-adapter.js
• Galaxy Guardians dev-only scout-wave runtime:
  • /Users/steven/Documents/Codex-Test1/src/js/13-galaxy-guardians-runtime.js
• shared entity model used by packs:
  • /Users/steven/Documents/Codex-Test1/src/js/14-entity-model.js
• Aurora board and sprite rendering:
  • /Users/steven/Documents/Codex-Test1/src/js/21-render-board.js
• Galaxy Guardians dev-only preview board rendering:
  • /Users/steven/Documents/Codex-Test1/src/js/22-galaxy-guardians-preview-renderer.js

Build And Hosted Docs Flow

Build script:

• /Users/steven/Documents/Codex-Test1/tools/build/build-index.js

Generated local localhost artifacts:

• /Users/steven/Documents/Codex-Test1/dist/dev/index.html
• /Users/steven/Documents/Codex-Test1/dist/dev/project-guide.html
• /Users/steven/Documents/Codex-Test1/dist/dev/platinum-guide.html
• /Users/steven/Documents/Codex-Test1/dist/dev/player-guide.html
• /Users/steven/Documents/Codex-Test1/dist/dev/release-dashboard.html
• /Users/steven/Documents/Codex-Test1/dist/dev/build-info.json
• /Users/steven/Documents/Codex-Test1/dist/dev/release-notes.json

Promotion scripts:

• promote hosted /beta candidate:
  • /Users/steven/Documents/Codex-Test1/tools/build/promote-beta.js
• promote hosted /production candidate:
  • /Users/steven/Documents/Codex-Test1/tools/build/promote-production.js

Publish and verification scripts:

• publish lane:
  • /Users/steven/Documents/Codex-Test1/tools/build/publish-lane.js
• lane preflight:
  • /Users/steven/Documents/Codex-Test1/tools/build/check-publish-ready.js
• live lane verification:
  • /Users/steven/Documents/Codex-Test1/tools/build/verify-live-lane.js

Hosted Lane Contract

The intended hosted lane contract is:

• hosted /dev
  • current integrated candidate
• hosted /beta
  • release candidate under review
• hosted /production
  • approved public build

The hosted documentation set should exist on each lane as part of that contract.

Harness And Evidence Flow

Core harness tools:

• scenario runner:
  • /Users/steven/Documents/Codex-Test1/tools/harness/run-gameplay.js
• batch runner:
  • /Users/steven/Documents/Codex-Test1/tools/harness/run-batch.js
• run analysis:
  • /Users/steven/Documents/Codex-Test1/tools/harness/analyze-run.js

Harness families should now be thought of in categories:

• platform-only harnesses
• application/gameplay harnesses
• seam and contract harnesses
• migration and compatibility harnesses

Pack-boundary harness:

• tools/harness/check-pack-registry-boundaries.js

verifies that the Galaxy Guardians preview pack owns separate placeholder tables, stays non-playable, and does not inherit Aurora challenge cadence, challenge layout, or reference timings.

• tools/harness/check-gameplay-adapter-boundaries.js

verifies that Aurora is the only registered public gameplay adapter, Galaxy Guardians remains blocked from public playability, and the explicit development-only preview adapter starts only the Guardians-owned runtime slice.

• tools/harness/check-guardians-adapter-skeleton.js

verifies that the Galaxy Guardians skeleton exists, stays disabled, exposes a single-shot scout-wave state shape, cites the promoted event log, and fails closed until measured runtime implementation exists.

• tools/harness/build-galaxian-reference-profile.js

probes the local Galaxian videos and generates source manifests, contact sheets, waveforms, the initial measured profile, and the promoted reviewed event log used by the disabled Galaxy Guardians skeleton.

• tools/harness/check-galaxian-reference-profile.js

verifies that the generated Galaxian profile has the expected source roles, artifacts, promoted event targets, and first-slice scout-wave baseline.

• tools/harness/check-galaxy-guardians-runtime-slice.js

verifies the dev-only Galaxy Guardians scout-wave runtime model: 38-slot rack, flagship/escort/scout roles, single-shot firing, promoted event emission, Guardians-owned scoring, Guardians-owned visual/audio catalog bindings, and no Aurora capture/challenge/dual-fighter state.

• tools/harness/check-galaxy-guardians-identity-baseline.js

verifies that the persistent 0.1 identity artifact in reference-artifacts/analyses/galaxy-guardians-identity/ matches the pack-owned sprite glyphs, audio cue catalog, theme cues, runtime cue map, and dev-preview audio history.

• tools/harness/check-galaxy-guardians-movement-pacing.js

verifies that the persistent movement/pacing artifact matches runtime rules and that sampled scout/flagship/escort dive behavior exposes real linked escort craft and wrap/return pressure.

• tools/harness/check-galaxy-guardians-threat-scoring.js

verifies that the persistent lower-field threat/scoring artifact matches runtime rules and that enemy shots, player loss, and owned point values stay in the Galaxy Guardians application layer.

• tools/harness/check-galaxy-guardians-playable-preview.js

verifies the development-lane Galaxy Guardians playable-preview adapter: keyboard fire routing, life loss, reset, game over, owned audio cue IDs, and isolation from the public playable adapter registry.

• tools/harness/check-galaxy-guardians-first-class-conformance.js

verifies that the Galaxy Guardians evidence stack, core docs, and harness family still support the maintained first-class conformance target instead of drifting back into a loose preview-only state.

• tools/harness/check-galaxy-guardians-long-surface-conformance.js

verifies that the committed later-stage pressure bands, staged shell presentation, and deterministic persona review runs stay aligned with the current Guardians source instead of drifting back to one-level-only review.

• tools/harness/check-compact-cabinet-rails.js

verifies that both side-frame icon rails remain visible and inside the cabinet frame at the compact in-app browser scale, and that the Galaxy Guardians preview modal stays readable in that compact layout. It also verifies the hosted-preview Guardians renderer by checking its render mode, registered renderer key, visual catalog IDs, audio cue IDs, signal palette, Platinum harness alias, and non-playable public adapter state.

• tools/harness/check-framed-popout-bounds.js

verifies that frame-owned popouts stay inside the gameplay frame, that platform messages, high scores, and pilot/account popouts share the same framed footprint, and that opening another dock popout closes the current one before showing the next surface.

• tools/harness/check-platinum-renderer-boundaries.js

verifies statically that platform render orchestration is game-agnostic, board renderers register themselves through the Platinum renderer registry, and the Galaxy Guardians renderer remains preview-only and adapter-gated.

Application/gameplay harnesses must stay game-owned. A harness that proves Aurora capture/rescue, challenge-stage cadence, or dual-fighter behavior does not prove Galaxy Guardians behavior. Shared harness helpers belong in Platinum; game behavior assertions belong to the owning game.

The intended release rule is automation-first:

• automate when the behavior is stable enough to measure
• use manual review mainly for feel and visual quality

Related Docs

• platform guide:
  • /Users/steven/Documents/Codex-Test1/PLATINUM.md
• application guide:
  • /Users/steven/Documents/Codex-Test1/APPLICATIONS_ON_PLATINUM.md
• game boundary audit:
  • /Users/steven/Documents/Codex-Test1/PLATINUM_GAME_BOUNDARY_AUDIT.md
• platform diagrams:
  • /Users/steven/Documents/Codex-Test1/PLATINUM_ARCHITECTURE_OVERVIEW.md
• testing and release discipline:
  • /Users/steven/Documents/Codex-Test1/TESTING_AND_RELEASE_GATES.md

This document describes the expected release discipline for Platinum and the applications it hosts.

The rule is simple:

• automate the gate whenever we reasonably can
• use manual review for feel and presentation only where automation is weak

Machine And Authority Gate

Aurora now assumes:

• main is the only integration branch
• one machine holds release authority at a time
• hosted /beta and hosted /production may only be published from that

authority machine

The practical startup and readiness commands are now:

• npm run machine:bootstrap
• npm run machine:ensure-browser
• npm run machine:doctor
• npm run machine:status
• npm run release:show-authority

This means machine readiness and release authority are now part of release discipline, not just local convention.

Browser-backed gates use Playwright-managed Chromium. They must not launch the user's installed Google Chrome by default. In Codex Desktop on macOS, run these browser-backed commands with escalated sandbox permissions; the harness launcher will refuse sandboxed browser starts to avoid macOS Chromium/Chrome SIGABRT crash dialogs.

Repo Browser Runtime Rule

Project browser checks must use the repo harness launcher:

• npm run machine:ensure-browser
• tools/harness/browser-launch.js
• npm harness scripts that depend on local playwright-core

Do not use Codex's bundled Node/Playwright runtime directly for project release checks. That runtime can have a different expected browser cache and fail with missing chromium_headless_shell-* paths even when the repo-managed Chromium is correctly installed.

Hosted public lanes also intentionally do not expose private gameplay harness APIs. Use the hosted DOM account smoke for sign-in field reachability:

• npm run harness:check:live-account-input:dev
• npm run harness:check:live-account-input:beta
• npm run harness:check:live-account-input:production

After each hosted lane publish, run the matching hosted smoke against the live URL:

• npm run harness:check:hosted-smoke:dev
• npm run harness:check:hosted-smoke:beta
• npm run harness:check:hosted-smoke:production

The publish scripts invoke these automatically after hosted build verification:

• npm run publish:dev
• npm run publish:beta
• npm run publish:production

This check opens the live hosted URL in the repo-managed browser, verifies lane/build identity, confirms pilot sign-in fields are visible and fillable, checks Settings/theme/audio defaults and public-safe private-audio blocking, starts a short player-like session, and records a small JSON report plus screenshot under harness-artifacts/hosted-lane-smoke/.

Keep the older harness:check:live-input:* checks for lanes/artifacts where the gameplay harness is intentionally present.

Before a hosted /dev publish, use the dry release-preflight wrapper:

• npm run release:preflight:dev

This command does not deploy. It checks whether the code-review packet and release conformance/documentation artifacts are current, refreshes the stale piece only when needed, stops for a commit if refresh output changed tracked files, then performs a clean rebuild and publish:check:dev. It exists to catch the common freshness/build blockers before npm run publish:dev reaches the hosted push step.

Bug-Fix Discipline

We should not address a bug without also deciding how the fix is protected in the appropriate staging harness.

Default rule:

1. identify the bug family:

• platform
• application
• boundary
• release / pipeline

1. add or update a targeted automated check when the behavior is stable enough

to measure

1. if automation is not yet practical, record the manual gate explicitly and

leave a clear follow-up path toward automation

This is how we stay agile without relying on memory-only fixes.

See also:

• DEVELOPMENT_PRINCIPLES.md

Lane Model

The expected lane model is:

1. local localhost

• active engineering lane
• source of the current local candidate

1. hosted /dev

• shared integration preview
• hosted mirror of the current stable local candidate
• should only be replaced when the new candidate is intentionally better than

the currently published hosted /dev

1. hosted /beta

• reviewed release-candidate lane
• should be more disciplined than hosted /dev

1. hosted /production

• official public promise
• should only move from an approved hosted /beta candidate

See also:

• MULTI_MACHINE_WORKFLOW.md
• release-authority.json

Release Scope Model

We now need to think about release work in three scopes, not one:

1. platform candidate

• shared Platinum shell, services, pack contract, tooling, and publish logic
• should be able to move with platform-owned tests plus hosted-game boot/smoke

containment

1. application candidate

• one game's rules, assets, conformance evidence, and release notes
• should be able to move with game-owned tests plus boundary checks, without

forcing unrelated game behavior to churn

1. integrated bundle candidate

• the specific overall combination promoted to hosted /dev, hosted /beta,

or hosted /production

• should record which platform version and application versions are inside the

bundle

Current public hosting still ships an integrated bundle on each lane.

The discipline should still preserve these scopes independently so future release paths do not require a full-platform move every time one game changes.

Documentation Gate For Major x.y Releases

For every meaningful x.y release, we should complete a full documentation pass between hosted /beta and hosted /production.

That pass should refresh:

• release-notes.json
• release-dashboard.json
• detailed release note for the candidate family
• README.md
• PLAN.md
• PRODUCT_ROADMAP.md
• PROJECT_STATE_AND_CONFORMANCE_PROGRAM.md
• CONFORMANCE_METRICS_OVERVIEW.md
• RELEASE_CONFORMANCE_DASHBOARD.md
• CONFORMANCE_ECONOMICS.md
• RELEASE_POLICY.md
• RELEASE_READINESS_REVIEW.md
• ARCHITECTURE.md
• PLATINUM.md
• APPLICATIONS_ON_PLATINUM.md
• this testing and release gate document
• hosted project-guide.html
• hosted platinum-guide.html
• hosted player-guide.html

This was not enforced strongly enough before 1.2.0 reached hosted /production.

From now on, it should be treated as part of the release contract.

Release Conformance Documentation Freshness

Release-facing conformance surfaces now have a stricter rule:

• if hosted docs or dashboards claim a current conformance read, the underlying

release-owned analysis artifacts must be intentionally refreshed as part of release prep

• specifically:
  • reference-artifacts/analyses/conformance-economics/latest.json
  • reference-artifacts/analyses/release-conformance-dashboard/latest.json
  • reference-artifacts/analyses/application-artifact-conformance/latest.json

The practical refresh path is:

• npm run harness:refresh:release-conformance-docs
• npm run build

Then commit the refreshed artifacts before any serious /dev, /beta, or /production publish attempt.

The publish preflight and documentation-freshness checks should now fail if those release-owned conformance artifacts are obviously stale against the current release-prep head.

Hosted Pages Workflow Self-Heal

The hosted Aurora Pages repo currently runs in GitHub Pages workflow mode rather than direct branch-serving mode.

That means a lane publish can be correct in the hosted repo itself while the live sgwoods.github.io lane stays stale if GitHub misses the expected Deploy Pages workflow trigger.

The release-authority verification path now treats that as a recoverable host issue instead of only as a generic timeout:

• node tools/build/verify-live-lane.js --lane dev
• node tools/build/verify-live-lane.js --lane beta
• node tools/build/verify-live-lane.js --lane production

If live lane build info does not match the expected local artifact, the verifier now checks whether:

• the hosted repo's raw lane build-info already matches the expected artifact
• the Pages site is configured with build_type: workflow
• a Deploy Pages run exists for the current hosted repo head

If the repo is already correct but no current Pages deploy run exists, the verifier dispatches Deploy Pages automatically and keeps polling the live site.

This should reduce manual release-authority rescue work when a publish push lands in sgwoods/Aurora-Galactica but GitHub Pages does not start the deploy workflow on its own.

Release Pipeline Friction Log

The 1.4.1 beta path exposed several process issues that should be smoothed before the next production move:

• public hosted lanes intentionally strip gameplay harness APIs, so hosted

account/sign-in checks need DOM-only probes rather than private harness probes

• release evidence generation can make the next publish preflight look stale;

refresh release conformance docs before the final publish check, then commit that evidence once

• beta security review should run after promote:beta, and production security

review should run last when preparing production-facing documentation

• GitHub Pages deploy latency is recoverable, but it still lengthens lane

movement; keep verifier self-heal, and prefer a single release-preflight command once the current process stabilizes

• evidence-only commits should be treated deliberately: publish them to hosted

lanes when docs/dashboards need to be visible, but do not confuse them with gameplay/runtime keepers

Recommended simplification backlog:

• add one patch-release preflight bundle that sequences machine readiness,

browser readiness, conformance refresh, security review, code review, build, and lane publish checks in the current best order

• keep live DOM smoke, local gameplay harness smoke, and public artifact-boundary

checks as separate named gates

• make the final dev -> beta -> production handoff print the exact artifact SHA,

version label, evidence commit, and remaining manual gates before each publish

Front-Door Copy Gate

Startup, initiation, and wait-mode copy is part of the release surface.

For any candidate where front-door copy changes, we should verify:

• platform-owned shell copy still appears on the front door
• stale release placeholders are gone
• application-owned identity copy still appears correctly
• platform splash copy remains aligned with the current Platinum docs

The current automated front-door copy gate is:

• node tools/harness/check-front-door-copy-surface.js

Harness Classification

To keep development fluid while still protecting release quality, harnesses should be thought of in three buckets:

1. platform

• protects Platinum shell behavior
• protects hosted lane surfaces and release framing
• should not require deep application gameplay validation unless the platform

change could affect gameplay hosting

Typical examples:

• node tools/harness/check-popup-surfaces.js
• node tools/harness/check-framed-popout-bounds.js
• node tools/harness/check-dock-button-actions.js
• node tools/harness/check-front-door-copy-surface.js
• node tools/harness/check-platinum-pack-boot.js

1. application

• protects game-specific rules and progression
• should stay contained to the application layer whenever possible

Typical examples:

• node tools/harness/check-dual-final-life-survivor.js
• node tools/harness/check-challenge-bonus-stage-numbering.js
• node tools/harness/check-extra-ship-awards.js
• node tools/harness/check-late-run-ship-loss-soak.js

1. boundary

• protects the seam between platform and applications
• answers:
  • did a game change leak into platform behavior?
  • did a platform change alter game behavior unintentionally?
• future fidelity/trueness work should deepen game-owned state and cue models

without moving game-specific rules, audiovisual mapping, or reference logic into Platinum

Typical examples:

• node tools/harness/check-platinum-pack-boot.js
• node tools/harness/check-game-picker-shell.js
• node tools/harness/check-front-door-copy-surface.js

The release process should prefer running the smallest relevant set of checks that covers the actual risk, rather than running every check for every change.

Harness work should also follow the project reference program:

• bug fixes should gain coverage in the right harness family
• fidelity changes should use measured reference artifacts where possible
• when committed reference artifacts can settle a question, prefer that over

human-only evaluation

• platform/application seam changes should prove that the boundary still holds

For long-cycle fidelity work, use LONG_CYCLE_KEEPER_PROCESS.md to decide whether a measured candidate is only a measurement win or is ready to become a player-facing runtime keeper. Documentation/evidence-only improvements can move hosted /dev, but they should not justify hosted /beta by themselves.

Galaxy first-class parity

Galaxy Guardians now has enough harness surface that we should treat it as a first-class parity program, not only as a preview experiment.

That means every serious Galaxy review should preserve all three layers:

1. ingestion and scored evidence

• npm run harness:check:galaxian-reference-profile
• npm run harness:check:galaxy-guardians-reference-conformance
• npm run harness:check:galaxy-guardians-playtest-conformance-review

1. gameplay/runtime completeness

• npm run harness:check:galaxy-guardians-runtime-slice
• npm run harness:check:galaxy-guardians-score-progression
• npm run harness:check:galaxy-guardians-threat-scoring
• npm run harness:check:galaxy-guardians-playable-preview
• npm run harness:check:galaxy-guardians-long-surface-conformance

1. audiovisual and boundary review

• npm run harness:check:galaxy-guardians-visual-readability
• npm run harness:check:galaxy-guardians-audio-character
• npm run harness:check:gameplay-adapter-boundaries
• npm run harness:check:platinum-pack-boot

The standing aggregate process gate is:

• npm run harness:check:galaxy-guardians-first-class-conformance

That gate is intentionally broader than one gameplay check. It verifies that the Galaxy evidence stack, core docs, and harness family remain in sync with the maintained plan in GALAXY_GUARDIANS_FIRST_CLASS_CONFORMANCE_PLAN.md.

Ingestion And Conformance Rule

For new-game work, the first serious gate should be game-owned reference evidence, not platform improvisation.

Ingestion is now a formal subsystem of the conformance project. It should be treated as the evidence-producing phase that makes later gameplay, harness, and release claims possible.

Default direction:

• ingest user gameplay videos and other primary source artifacts into

game-owned manifests

• extract contact sheets, waveforms, timing windows, motion traces, and other

conformance evidence from those sources

• preserve manuals, flyers, or descriptive rule artifacts where they help

explain mechanics the footage alone does not settle cleanly

• keep the resulting analysis and conformance package tied to the owning game,

not buried only in Platinum-specific release logic

• use Platinum as the host contract and tooling surface for launch, not as a

substitute for game-owned reference truth

• treat human observation as fallback confirmation when the evidence package

still cannot encode the question, not as the default baseline

For a new game, the first playable slice should cite:

• source manifest
• selected reference windows
• event log or semantic profile
• initial conformance targets
• candidate harness plan
• explicit confidence and known gaps

If a release candidate includes a new or materially changed game behavior, its release notes and dashboard should identify which ingestion package or correspondence artifact grounds the claim.

For Galaxy specifically, first-class application review should also preserve:

• a playtest-weighted review that can remain stricter than the evidence score
• game-owned score/progression/result contracts
• browser/manual review notes for sound, motion feel, and sprite readability

Dashboard And Ingestion Release Boundary

The shipped Platinum platform should include the read-only conformance dashboard as a release surface.

That means each /dev, /beta, and /production lane should carry:

• conformance-dashboard.html
• conformance-dashboard-data.json
• assets/conformance-dashboard.html
• assets/conformance-dashboard-data.json
• a release-dashboard link to the conformance dashboard
• a settings/configuration-panel launcher that opens the bundled read-only

dashboard for the active lane

The release dashboard may link to the assets/ copy, but the top-level dashboard files must also be published because the game settings/configuration launcher opens conformance-dashboard.html beside the active game lane.

The dashboard is platform-owned presentation of release evidence. It is allowed to summarize application-owned game conformance, ingestion state, confidence, measurement debt, and compute/resource spend.

The ingestion framework itself remains engineering-owned unless we explicitly promote a separate Root-gated or public evidence browser. Raw source media, reference extraction workspaces, candidate clips, unreviewed traces, and in-progress annotation notebooks should not automatically become player-facing Platinum assets just because the dashboard summarizes them.

This gives us the right separation:

• Platinum publishes the release evidence surface.
• Aurora or another game owns its reference truth, metric definitions, and

ingestion artifacts.

• The integrated release bundle records enough conformance and ingestion

summary data to explain the release without exposing the whole engineering workspace.

Supabase Data API Access Gate

Platinum's auth, profile, and leaderboard paths use Supabase through the Data API. The maintained access contract is:

• SUPABASE_DATA_API_ACCESS.md
• supabase/data-api-access-contract.sql

This is now a release-hardening gate because Supabase public-schema tables need explicit grants for new projects beginning May 30, 2026 and for existing projects by October 30, 2026.

The source-level gate is:

• npm run harness:check:supabase-data-api-contract

The publish preflight runs this check. If runtime code adds a new supabase.from('table') surface, the release path should fail until that table has an explicit Data API contract, RLS posture, and policy explanation. This is especially important for upcoming top-10 YouTube posting, replay metadata, and expanded pilot-record features.

Gate Profiles By Change Type

We want:

• fast iteration on main
• meaningful integration confidence on hosted /dev
• disciplined promotion into hosted /beta
• cautious promotion into hosted /production

The way to do that is to choose a gate profile based on the type of change.

Profile A: Application-only change

Use this when the change is primarily inside a hosted game such as Aurora and should not alter Platinum platform behavior.

Examples:

• scoring changes
• life and death rules
• stage sequencing
• capture/carry gameplay fixes
• enemy behavior tuning

Required:

• targeted application harnesses for the changed behavior
• one adjacent regression check for the same gameplay family
• at least one boundary check proving the application change did not leak into

the platform

• for fidelity work, prefer expanding application-owned state/cue granularity

instead of adding platform-owned exceptions for one game

Typical boundary checks:

• node tools/harness/check-platinum-pack-boot.js
• node tools/harness/check-game-picker-shell.js

Profile B: Platform-only change

Use this when the change is primarily in Platinum hosting behavior and should not alter application gameplay rules.

Examples:

• shell layout
• popup framework
• dock behavior
• front-door platform surfaces
• hosted docs and lane surfaces

Required:

• platform harnesses for the changed area
• one quick application smoke or boot check proving the platform still hosts

games correctly

Typical application containment checks:

• node tools/harness/check-platinum-pack-boot.js
• node tools/harness/check-new-game-reset.js
• node tools/harness/check-galaxy-guardians-0-1-candidate.js when the changed

surface touches the Galaxy Guardians dev-preview identity, runtime events, cue IDs, scoring, or preview/public boundary.

• node tools/harness/check-galaxy-guardians-audio-character.js when the

changed surface touches Guardians cue definitions, audio theme identity, runtime cue IDs, or role-specific hit/loss/game-over sound behavior.

• node tools/harness/check-galaxy-guardians-reference-conformance.js when the

changed surface touches Guardians reference evidence, 0.1 metric scoring, promoted Galaxian event coverage, or beta-preview readiness language.

• node tools/harness/check-galaxy-guardians-formation-entry.js when the changed

surface touches Guardians stage start, rack-entry, rack-settle, or first-dive timing.

Quality/conformance reporting:

• npm run harness:score:quality-conformance is the current Aurora numeric

roll-up gate.

• The readable current table and next-gap interpretation live in

CONFORMANCE_METRIC_OVERVIEW.md.

• When this roll-up changes materially, update

QUALITY_RELEASE_SCORECARD.md and keep the generated artifact under reference-artifacts/analyses/quality-conformance/.

• node tools/harness/check-galaxy-guardians-visual-readability.js when the

changed surface touches Guardians sprites, role palettes, preview rendering, hit feedback, or gameplay-scale visual identity.

Profile C: Boundary change

Use this when the change explicitly crosses between platform and application responsibility.

Examples:

• startup / wait-mode copy ownership
• game picker launch / preview behavior
• pack contracts
• shell surfaces that combine platform and app-owned data

Required:

• at least one platform check
• at least one application check
• one or more explicit boundary checks

This is the highest-leakage-risk category and should be treated accordingly.

Profile D: Release / pipeline change

Use this when the change affects build, publish, release metadata, hosted docs, or lane verification rather than gameplay or shell behavior directly.

Examples:

• publish tooling
• production metadata rewrite
• asset copy policy
• documentation gate enforcement
• runtime-loaded media under assets/
• top-level public project page sync freshness

Required:

• publish preflight
• live lane verification
• asset and metadata validation
• docs presence checks where relevant

For this profile, asset validation should include runtime-loaded files, not just shell-visible images. If a lane uses files under assets/ at runtime, publish and verify should treat those files as part of the release contract.

For production, the release contract also includes the top-level sgwoods/public Aurora project page. A production release is not complete if the public page still shows stale release/build/focus content after the publish and sync steps.

If public sync must be rerun after production is already live, it should run from current clean main and a current tokenized public template, while also proving that local dist/production still matches the live production lane exactly. That keeps the public page current without silently inventing a new "production" build that has not actually been released.

This profile should not automatically pull in deep gameplay suites unless the change also affects gameplay delivery.

Lane-Specific Rigor

Use the lane purpose to decide how rigorous the gate set must be.

Local localhost

• targeted checks only
• adjacent regression check
• manual inspection where needed

Hosted /dev

• enough confidence to justify replacing the current live hosted /dev
• targeted checks for changed areas
• at least one boundary or containment check
• live verify after publish
• manual comparison against the current published hosted /dev

Hosted /beta

• stronger gate set than hosted /dev
• candidate should be intentionally assembled and stable
• live verify after publish
• review of release-facing deltas
• docs refresh where required for the release family

Hosted /production

• approved hosted /beta only
• full production preflight
• live verify
• top-level public project page sync and verify

Required Automated Gates

Local localhost

Before promotion from local localhost into hosted /dev or hosted /beta, we expect:

• npm run build
• node tools/build/check-publish-ready.js --lane dev
• core gameplay and shell harnesses relevant to the candidate

Typical current examples include:

• node tools/harness/check-input-mapping.js
• node tools/harness/check-new-game-reset.js
• node tools/harness/check-capture-lifecycle.js
• node tools/harness/check-challenge-motion-profile.js
• node tools/harness/check-remote-score-submit.js
• node tools/harness/check-pilot-records-panel.js
• node tools/harness/check-feedback-submit-path.js
• node tools/harness/check-platinum-pack-boot.js
• node tools/harness/check-game-picker-shell.js
• node tools/harness/check-popup-surfaces.js
• node tools/harness/check-framed-popout-bounds.js
• node tools/harness/check-dock-button-actions.js
• node tools/harness/check-persona-repeatability.js
• npm run harness:check:persona-performance-distribution when persona

distribution evidence is part of the release story

• node tools/harness/check-front-door-copy-surface.js
• node tools/harness/check-runtime-loop-crash-capture.js
• node tools/harness/check-late-run-ship-loss-soak.js for any candidate touching player lifecycle, scoring, or other late-run gameplay transitions

Selection rule:

• choose the smallest harness set that matches the active gate profile
• avoid dragging platform-wide or gameplay-wide suites into every change unless

the change actually crosses those boundaries

Hosted /dev

Hosted /dev exists to catch "worked locally but not when hosted" problems.

Before promoting a candidate from hosted /dev to hosted /beta, we should have:

• a clean local check-publish-ready --lane dev
• hosted /dev publish success
• hosted /dev label verification
• a short hosted /dev review for visual and feel checks

Hosted /dev is the preferred place to catch:

• local-versus-hosted differences
• platform/application boundary drift
• shell or copy regressions that are awkward to judge from local-only runs
• missing runtime-loaded assets that do not show up until the hosted lane is

exercised

Hosted /beta

Hosted /beta is the real production gate.

Before moving hosted /beta to hosted /production, we expect:

• node tools/build/check-publish-ready.js --lane beta
• a completed review cycle:
  • npm run review:cycle
  • npm run review:dispositions:check
• every architecture/code-review issue addressed or explicitly dismissed in

review-dispositions.json, with rationale and evidence

• hosted /beta publish success
• hosted /beta live label verification
• hosted /beta live-input verification when input or gameplay start behavior could be affected
• targeted soak coverage for any open freeze or long-session stability risk
• for the current late-run freeze family, that means:
  • node tools/harness/check-late-run-ship-loss-soak.js
• completed documentation refresh for any meaningful x.y release

Hosted /beta should be strict by risk, not strict by volume:

• application-only candidates should primarily run application and boundary

gates

• platform-only candidates should primarily run platform and boundary gates
• boundary candidates should run both
• release/pipeline candidates should emphasize publish and lane verification

Hosted /production

Hosted /production should move only from an approved hosted /beta candidate.

Required path:

1. npm run approve:beta
2. npm run promote:production
3. node tools/build/check-publish-ready.js --lane production
4. hosted /production publish
5. hosted /production label verification
6. npm run sync:public
7. npm run verify:public

The public sgwoods/public sync is part of the production release contract, not a manual follow-up.

Production promotion must also start from a clean tree:

• the local source tree must be clean before promote:production
• the release machine must be on main, and local main must match origin/main
• the approved beta candidate must not have been promoted from a dirty source state
• the public sync step must validate the current src/public/aurora-galactica.template.html template and the production artifact must have been rebuilt from that exact clean checkout
• if either condition fails, production promotion should stop

First-Class Hosted Documentation Requirement

The hosted documentation set is now part of the release surface.

Every hosted lane should carry:

• project-guide.html
• platinum-guide.html
• player-guide.html
• release-dashboard.html
• release-notes.json
• build-info.json

That requirement is now enforced by the publish preflight.

Remaining Improvement Areas

The release gate is stronger than it used to be, but there is still room to improve:

• make more live-lane checks automatic instead of relying on memory
• keep platform-only, application-only, and boundary harnesses clearly separated
• add stronger pack-contract validation as the second application becomes real
• keep docs refresh discipline boring and routine rather than exceptional
• formalize check ownership so every application-level change proves it did not

leak into Platinum, and every platform-level change proves it did not alter hosted game rules unintentionally

Related Docs

• platform guide:
  • PLATINUM.md
• application-layer guide:
  • APPLICATIONS_ON_PLATINUM.md
• release policy:
  • RELEASE_POLICY.md
• release readiness review:
  • RELEASE_READINESS_REVIEW.md

Updated: May 14, 2026

Supabase notified the project that public-schema tables will no longer be implicitly exposed to the Data API.

The dates that matter are:

• May 30, 2026: new projects and new public tables in those projects need

explicit grants before supabase-js, PostgREST, or GraphQL can access them.

• October 30, 2026: existing projects must also rely on explicit grants.

Aurora / Platinum is affected because the browser runtime and release tooling use supabase-js, which talks to the Supabase Data API.

Current Data API Surface

The maintained SQL access contract is:

• supabase/data-api-access-contract.sql

The contract is intentionally not a full database schema. It records the browser-visible tables, required grants, and RLS policies that make the current runtime behavior reproducible.

Release Gate

The automated source gate is:

npm run harness:check:supabase-data-api-contract

The checker verifies:

• every supabase.from('table') runtime/tooling usage is represented in the

SQL contract

• scores and profiles have explicit role grants
• RLS is enabled for both tables
• the expected policy names are present
• the maintained explainer document records the Supabase deadline dates and

links to the SQL contract

Publish preflight also runs this gate, so a future branch that adds a table for features such as YouTube high-score posts, replay video metadata, or richer pilot records must update the Supabase access contract before it can move through the release path.

Current Risk Read

Existing hosted tables are not expected to break immediately from the May 30 change because Supabase says existing grants remain in place. The project risk is reproducibility: without committed grants and RLS policy expectations, a new project, a restored database, or a new feature table can fail even while local code looks correct.

The October 30, 2026 deadline makes this a release-hardening concern rather than a someday cleanup item.

There is a separate score-trust boundary to keep visible: the current browser client writes is_verified as part of signed-in score submission. The access contract preserves today's behavior, but a stronger future verified-score model should set that field through a server-owned path, trigger, or RPC rather than trusting client-supplied metadata.

Future Table Rule

Any new Supabase table used by the browser Data API must land with:

• table purpose and ownership
• explicit grants for anon, authenticated, and/or service_role
• RLS enabled unless there is a documented exception
• policies that express the user-visible product rule
• a harness/preflight update proving the table is present in this contract

For planned top-10 YouTube posting and replay-video metadata, this means no runtime feature work should merge until the data model and access policy are captured here.

Purpose

This document defines the launch visual direction for the Platinum platform shell that hosts Aurora Galactica for the first public Platinum-framed release.

The goal is not to redesign Aurora itself. The goal is to make the platform frame feel intentional, premium, reusable across future games, and visually calmer than the current busy cabinet treatment.

Recommended Direction

Use Platinum Command as the release frame direction.

Short definition:

• premium sci-fi cabinet host
• deep navy / graphite structure
• cyan / ice-blue technical accents
• restrained metallic highlights
• minimal warm accent usage
• quieter side rails so the game remains primary

Design Principles

1. Platform Supports The Game

The shell should clearly belong to Platinum, but it should not visually compete with the active game.

That means:

• Aurora marquee and playfield remain the primary focal points
• Platinum frame establishes confidence and identity around them
• shell decoration should reinforce structure, not demand attention

2. Calm The Frame

The current frame has too many simultaneous motifs:

• diagonal stripes
• glow blooms
• star points
• high-contrast decorative fields

For launch, reduce that density so the shell feels:

• more premium
• less noisy
• more reusable across different games

3. Make Platinum Read As A Product

The platform should feel like a named host system, not just themed wallpaper.

That means:

• clearer materials and hierarchy
• more consistent cyan/silver host language
• less arbitrary color competition in non-game shell regions

Palette

Core Platform Palette

• Platinum Night: #0a1222
• Deep Graphite Blue: #111c31
• Control Navy: #182743
• Platinum Cyan: #7ad7ff
• Ice Highlight: #d8f2ff
• Soft Steel: #c9d7e6

Restricted Accent Palette

Use sparingly:

• Signal Gold: #ffd86d
• Signal Amber: #d8a542

Reserve warm accents for:

• selected / active buttons
• state emphasis
• occasional trim punctuation

Game-Owned Color Space

Aurora can keep its stronger game colors:

• orange / red marquee lettering
• stage accent shifts
• challenge / boss progression accents

Those belong to the game identity, not the base Platinum frame.

Shell Region Treatments

Top Marquee Housing

Launch direction:

• cleaner panel seams
• fewer decorative textures behind the marquee
• subtle technical glow near housing edges
• marquee housing should feel engineered rather than ornamental

Left Utility Rail

Launch direction:

• simplify the base texture
• reduce large warm glow circles
• reduce loud diagonal repeats
• introduce subtle panel segmentation
• let the dock buttons and Platinum badge become the focal elements

Right Action Rail

Launch direction:

• match the left rail in calmer material language
• reduce background contrast
• keep button affordances strong
• use cyan/silver structural edges instead of layered glow clutter

Bottom Status Band

Launch direction:

• flatter, more deliberate material treatment
• subtle grid / instrument-panel cues
• restrained lighting
• cleaner separation from playfield

Playfield Surround

Launch direction:

• keep clean
• preserve game-stage accenting
• do not overload with Platinum texture

Overlay Style Rules

All major overlays should share one Platinum design language:

• large framed panel
• consistent border treatment
• clean close button placement
• integrated sub-sections
• clear hierarchy for titles, status, and actions

The trophy/high-score screen should behave like:

• one large overlay surface
• not two disconnected cards
• not a floating utility widget

Dock behavior rule:

• selecting one dock overlay closes the others by default

What To Tone Down From The Current Frame

Reduce or simplify:

• large circular glow blooms in the side rails
• repeated diagonal stripe dominance
• mixed warm/cool accents in the base shell
• ornamental brightness behind the marquee

Keep or strengthen:

• structural shell boundaries
• cyan technical line-work
• premium dark base materials
• strong game-button readability
• the Platinum badge as a quiet brand anchor

Recommended Theme Token Model

The platform-owned shell frame theme should continue to expose:

• shell top background
• shell side background
• shell bottom background
• shell panel border
• shell outer line
• shell glow
• marquee housing background
• marquee border
• marquee glow
• left rail background
• right rail background
• rail border
• rail inner border
• rail inner glow

Programmatic Graphics To Generate Later

Once the direction is approved, generate platform-owned visual elements for:

1. Platinum Release marquee housing refinement
2. left utility rail texture
3. right action rail texture
4. bottom command/status band texture
5. updated Platinum badge treatment if needed

These should be:

• platform-owned assets
• not Aurora-owned assets
• reusable by future packs

Immediate Implementation Guidance

For the next refinement pass:

1. reduce side-rail pattern intensity by roughly 30-40%
2. reduce large warm glow blooms in the rails
3. make the bottom band flatter and more command-like
4. make the top housing slightly more premium and less busy
5. preserve the Aurora marquee and game-stage identity inside that calmer host

Release Position

For launch, the shell should communicate:

• Platinum is the platform
• Aurora Galactica is the current flagship hosted game
• future sibling games can live inside the same host shell language

This is a forward-looking architecture review of Platinum after the first real Aurora-on-Platinum migration work.

The point of this review is not just to praise progress. It is to be clear about:

• what is now structurally solid
• what is still transitional
• what should be designed deliberately before future games and future host

surfaces expand the scope

Current Read

Platinum is no longer just an internal cleanup story.

It is now a real host platform with:

• a visible shell identity
• an explicit pack-selection path
• shared service seams
• shared harness categories
• one real playable game pack:
  • Aurora Galactica

That is meaningful progress.

The architecture is now beyond:

• “Aurora with some extracted files”

and into:

• “an early shared platform carrying one real game”

What Looks Covered Well

1. Platform identity is now explicit

This was important.

Platinum is now visible in:

• docs
• shell surfaces
• picker flow
• splash flow
• platform-only harnesses

That gives the project a cleaner mental model:

• platform
• game pack
• future pack

instead of one monolithic product blob.

2. Platform and game responsibilities are separating cleanly

This is one of the strongest areas now.

Platinum owns:

• shell and framing
• runtime and pack boot/install
• service adapters
• publish/readiness checks
• platform-only harnesses

Aurora owns:

• gameplay rules
• stage and challenge design
• scoring
• capture/rescue mechanics
• game-specific content

That is the right direction, and it is now reflected in code, docs, and tests.

3. Harness separation is becoming real

This is a very strong improvement.

We now have clearer categories for:

• platform-only harnesses
• game-pack harnesses
• seam/contract harnesses
• motion/outcome checks

That matters because future games should be able to stress Platinum without dragging all Aurora assumptions along for the ride.

4. Platinum can already host a future title preview safely

The current Galaxy Guardians shell preview is useful.

It proves:

• pack selection
• shell identity swapping
• coming-soon treatment
• future-title framing

without pretending gameplay exists before it does.

That is exactly the kind of staged proof a platform needs.

What Is Still Transitional

1. The pack contract is real, but still not formal enough

We now have a meaningful pack shape in practice, but not yet a strongly versioned, explicit contract that can evolve safely.

What is still missing:

• clearer versioned gamePack schema thinking
• stronger required-vs-optional capability definitions
• more intentional forward-compatibility planning for pack data

This will matter much more once a second playable pack exists.

2. Some compatibility shims are still Aurora-shaped

This is acceptable for now, but it should stay visible.

Examples:

• storage aliases
• some debug globals
• some replay/account naming

These are not blockers, but they are signs that the migration is not fully finished yet.

3. Designer-owned data is still only partially extracted

We have good planning here, but not enough implementation yet.

Especially important future areas:

• stage catalogs
• boss archetype catalogs
• themed challenge definitions
• game text/content surfaces
• audio event mapping
• per-game admin/designer panels

Right now the direction is clear, but the operational designer model is still emerging.

What Needs To Be Considered Soon

1. Versioned pack evolution

As soon as Galaxy Guardians becomes playable, pack evolution becomes a real problem.

We should plan for:

• contract additions without breaking old packs
• deprecating pack fields safely
• validating pack metadata at load time
• keeping harnesses aligned with pack capability changes

This is where Lueck’s migration concern becomes very relevant.

2. Storage and migration safety

The current compatibility approach is pragmatic and appropriate.

But if Platinum becomes the long-term identity, we should eventually decide:

• what remains aliased forever
• what migrates once
• what is intentionally never migrated

That should be treated as product/data migration work, not just rename work.

3. Multi-host future thinking

Even if the immediate plan stays browser-first, Platinum should avoid making that assumption too deeply permanent.

Future host surfaces might include:

• hosted browser production
• local/offline cabinet mode
• desktop wrapper
• curated exhibition or kiosk mode

That does not mean building them now.

It means keeping these seams healthy:

• input abstraction
• file/storage abstraction
• service/network abstraction
• shell/layout abstraction

What We Should Address Later, Not Now

1. True multi-platform runtime support

Do not overreach here yet.

Right now Platinum should stay:

• browser-first
• Pages-friendly
• lightweight

The right move is to preserve the possibility of broader host platforms later, not to build them prematurely.

2. Heavy operator tooling inside Platinum core

Admin, artifact, and designer panels are important.

But they should remain:

• game-owned where appropriate
• or platform-adjacent tools

They should not bloat the core runtime path casually.

Forward-Looking Recommendations

Immediate

1. complete the Aurora-on-Platinum rerelease baseline cleanly
2. keep the shell and platform harnesses green
3. close the most visible Aurora trust/clarity issues after the rerelease pass

Next

1. make the first truly playable Galaxy Guardians slice
2. validate that the pack contract can support a simpler Galaxian-style ruleset
3. keep all new game-specific authoring in game-owned definitions, not

Platinum internals

Soon after

1. add stronger pack-schema validation
2. add more explicit migration/versioning strategy for pack and storage
3. deepen the designer/admin surfaces without mixing them into the core

Platinum runtime

After Aurora is stable again

1. run a brief retrospective on how a materially different Aurora gameplay

shape was able to survive this long while Platinum shell checks still looked healthy

1. document which testing layers were missing or too weak:

• production-vs-dev artifact comparison
• deterministic persona repeatability
• stage carryover parity
• outcome-distribution gating

1. promote the strongest new gates into normal release-readiness, so future

platform or game-pack work cannot drift this far before we notice

Bottom Line

Platinum is in a healthy early-platform state.

It is not “finished,” but it is real.

The right next move is not another abstract refactor. It is:

• stabilize the first shipped pack on the platform
• then prove the platform with a second playable pack
• while protecting the seam between platform and game with stronger contracts,

harnesses, and migration thinking