# Night Ash Run Developer Playbook

This playbook turns the Night Ash Run production fantasy into a source-bound implementation map: gameplay events, player identity, typed intent, sponsored relay, Xai record language, owned inventory, reward surfaces, history-to-build acceptance, build verification, and evidence boundaries. It is a design and documentation layer, not a claim that every integration is already live.

## Canonical URLs

- Developer Playbook: https://webgamegame.win/developer-playbook.html
- Developer Playbook Markdown: https://webgamegame.win/developer-playbook.md
- Technology Dossier: https://webgamegame.win/technology.html
- Runtime Architecture Console: https://webgamegame.win/technology.html#architecture-console
- Cast System Contract: https://webgamegame.win/developer-playbook.html#cast-system-contract
- Action Payload Envelope: https://webgamegame.win/developer-playbook.html#action-payload-envelope
- Setpiece Trace Contract: https://webgamegame.win/developer-playbook.html#setpiece-trace-contract
- Session Trace Ledger: https://webgamegame.win/developer-playbook.html#session-trace-ledger
- Build Verification Deck: https://webgamegame.win/developer-playbook.html#build-verification-deck
- Integration Handoff Packet: https://webgamegame.win/developer-playbook.html#integration-handoff-packet
- History-to-Build Gate: https://webgamegame.win/developer-playbook.html#history-build-gate
- Release Evidence Packet: https://webgamegame.win/developer-playbook.html#release-evidence-packet
- Integration Matrix: https://webgamegame.win/technology.html#integration-matrix
- Integration Readiness Matrix: https://webgamegame.win/developer-playbook.html#integration-readiness
- Runtime Blueprint JSON: https://webgamegame.win/runtime-blueprint.json
- History Runtime Map JSON: https://webgamegame.win/history-runtime-map.json
- Claim Matrix: https://webgamegame.win/technology.html#claim-matrix
- Xai Glossary: https://webgamegame.win/glossary.html
- Historical Production Layer: https://webgamegame.win/history.html#history-production-layer
- Historical Boundary Layer: https://webgamegame.win/history.html#history-boundary-layer
- Recursive Evidence Map: https://webgamegame.win/source-index.html#recursive-map
- Citation Readiness Ledger: https://webgamegame.win/source-index.html#citation-readiness
- Evidence JSON: https://webgamegame.win/evidence.json

## Runtime Modules

- Browser action shell: runs, bond scenes, garage loadouts, risk meters, item reveals, and route reputation stay inside a game-first client surface.
- Xai Connect adapter: email-linked ecosystem wallet language becomes a driver profile, crew identity, saved garage, and normal account flow.
- EIP-712 action router: route clears, garage upgrades, item claims, and reward actions can be described as typed gameplay intents.
- ERC-2771 sponsored path: gas subsidy and relayer patterns support low-friction inventory and reward actions that stay off camera during play.
- Xai Orbit vocabulary: Orbit, Nitro, AnyTrust, RPC, and explorer references give the game a source-backed record and inspection layer.
- Owned garage objects: vehicle parts, jackets, cards, charms, trophies, and route badges are written as player identity first.
- Proof-of-Skill surface: achievements, leaderboards, automatic wallet creation, contracts, and XAI reward concepts support route reputation.
- Source-bound observability: Claim Matrix, Source Index, Evidence JSON, and LLM files keep the implementation story readable and bounded.

Runtime Blueprint JSON:

https://webgamegame.win/runtime-blueprint.json is the machine-readable companion to this playbook. It publishes runtime modules, event contract fields, allowed readiness states, a sample trace, evidence routes, and not-claimed boundaries for LLMs, crawlers, and builders.

History Runtime Map JSON:

https://webgamegame.win/history-runtime-map.json connects Xai historical lanes to those runtime modules and event contracts, keeping the development-history layer tied to implementable design surfaces and publication boundaries.

## Player Action Pipeline

1. Input: player clears a route, tunes the garage, triggers a bond scene, or claims a reward.
2. Profile: account shell maps the player to a driver identity.
3. Intent: gameplay event becomes typed action language.
4. Relay: sponsored path keeps transaction friction off screen.
5. Record: Xai record vocabulary supports inspection and ownership language.
6. Reward: owned inventory, reputation, and Proof-of-Skill style rewards surface to the player.

## Cast System Contract

The Cast System Contract turns character pressure into production data. Adult cast roles, mission triggers, payload fields, Proof-of-Skill style reputation, garage memory, and evidence gates are handled as one design contract rather than loose story flavor.

- Fixer route: the worn-down fixer drives high-risk delivery flags, favor debt, route danger, and garage recovery state before any reward thesis is surfaced.
- Operator route: the night-shift operator turns bond scenes into route modifiers, unlock hints, trust deltas, and dialogue pressure without exposing wallet or relay mechanics.
- Garage route: the engineer binds loadout, part damage, trophy state, and item reveal to a driver profile so inventory reads like story memory first.
- Intel route: the broker marks which clues are canon, rumor, source-backed, context-only, or claim-boundary material before they become public copy.
- Rival route: the rival converts leaderboard heat, clean-run streaks, route mastery, and duel conditions into Proof-of-Skill style reputation language.
- Crew route: the route crew assigns crew id, repair window, exit lane, inventory custody, and relay expectation to the session trace ledger.
- Payload fields: every cast-triggered event carries cast role, route id, scene id, bond delta, risk band, inventory route, reward status, and evidence route.
- Release gate: character drama can explain gameplay pressure, but it cannot imply a live integration, payout, partnership, or deployed contract without a durable public route.

## Session Trace Ledger

The Session Trace Ledger is a source-bound trace for one route session. It gives builders and language models a concrete engineering path without turning design vocabulary into a live deployment claim.

- Trace id: start with route id, session id, build channel, and evidence route so later claims can be inspected and corrected.
- Actor state: bind driver, crew, garage, and loadout state before any route clear, item claim, or reward thesis is described.
- Intent state: route clear, garage upgrade, bond choice, or reward claim becomes typed intent with nonce, risk band, item route, and source boundary.
- Relay state: mark whether a sponsored relay is intended, optional, unavailable, or unverified; player-facing copy does not imply invisible live support without proof.
- Record state: separate item identity, route trophy, leaderboard echo, and inspection language from undeployed contract-address claims.
- Reward state: use Proof-of-Skill vocabulary for achievement and leaderboard thesis, while marking reward availability as design, operations model, or proven implementation.
- Source state: attach the exact public source route: Technology Dossier, Claim Matrix, Source Index, Proof-of-Skill PDF, or a site-owned implementation note.
- Boundary state: before release copy, record whether the statement is source-proven, context-only, design-map, design-stage, or not ready to claim.

## Action Payload Envelope

The Action Payload Envelope is a compact runtime contract for documenting how one player action travels from game input to identity, typed intent, sponsored relay, record route, reward route, and evidence boundary.

- Profile binding: connect the player-facing driver profile to an abstracted account identity before any route, item, or reward action is described.
- Typed intent: describe the gameplay event as route id, action kind, nonce, risk score, item route, and evidence route.
- Sponsor context: document whether the action is expected to use a sponsored path, relayer route, or player-paid path before any live-status claim.
- Outcome route: separate game outcome from proof route: inventory record, leaderboard echo, reward thesis, and citation boundary remain explicit.
- Minimum fields: player profile id, session id, route id, event kind, action nonce, source route, and integration boundary.
- Evidence route: attach Claim Matrix, Source Index, Developer Playbook, or future implementation note before stronger claims are published.
- Reward guardrail: reward language stays thesis or operations model unless a durable public implementation route proves a live reward.
- Deployment guardrail: design contract names, schemas, and event ids do not imply deployed smart-contract addresses or completed integrations.

## Setpiece Trace Contract

The Setpiece Trace Contract at https://webgamegame.win/developer-playbook.html#setpiece-trace-contract is the technical companion to the homepage Setpiece Gameplay Deck. It turns Loading Bay Blues into a traceable mission packet without claiming a public demo, deployed contracts, live rewards, or partner integrations.

- Cold open: backdoor smoke, debt pressure, cast role, and dialogue fork are recorded as a named scene packet before gameplay or reward language appears.
- Loadout lock: driver profile, crew id, garage id, vehicle id, loadout id, and account boundary must be present before route pressure becomes a traceable event.
- Rain chase: route id, risk band, pursuit window, finish state, relay expectation, and evidence route travel into the Action Payload Envelope.
- Bond fork: character pressure becomes bond delta, route modifier, unlock hint, and claim boundary instead of loose story flavor.
- Garage claim: item route, record output hint, and inspection route separate player-visible item memory from deployed-contract claims.
- Proof echo: Proof-of-Skill language is tagged as achievement identity, leaderboard heat, reward thesis, or operations model before stronger reward wording ships.
- Machine mirror: the packet must appear in runtime-blueprint.json, evidence.json, docs, facts, llms.txt, and media kit routes before it is treated as official canon.
- Boundary receipt: the trace contract documents design, testing, and publication readiness; it does not claim a public demo, deployed contracts, live rewards, or partner integrations.

## Skill Signal Packet

The Skill Signal Packet at https://webgamegame.win/developer-playbook.html#skill-signal-packet is the upstream packet for Proof-of-Skill reward language. It turns route mastery, clean-run streaks, leaderboard heat, achievement evidence, and garage proof into bounded design data before any reward wording is promoted.

- Source event: start from a visible game action such as redline clear, clean route, duel win, bond rescue, garage mastery, or route trophy.
- Driver state: bind driver profile, session id, route id, loadout id, crew id, and account boundary before the signal can affect reputation.
- Mastery vector: normalize risk band, finish state, damage window, retry count, route modifier, and cast pressure so skill is not just a raw number.
- Achievement echo: map the signal to achievement id, leaderboard band, garage badge, route charm, or owned memory without implying a live reward.
- Reward bridge: translate the signal into reward thesis, operations model, unavailable, or proven-by-public-route before reward copy gets stronger.
- Source route: attach the Reward Console, Source Index, Proof-of-Skill PDF route, Claim Matrix, and evidence JSON entry before publication.
- Machine mirror: the packet must appear in runtime-blueprint.json, facts, llms.txt, evidence JSON, and the knowledge graph before it is treated as official canon.
- Boundary receipt: the packet supports achievements, reputation, eligibility review, and reward thesis; it does not claim live rewards, payout availability, financial return, or deployed contracts.

## Build Verification Deck

The Build Verification Deck is a release-facing acceptance ledger for the technical story. It tells builders, editors, search crawlers, and language models what must be proven before stronger public copy moves beyond design-map status.

- Schema lock: route id, player profile id, event kind, action nonce, risk band, item route, and evidence route must be present before a gameplay event is described as an integration unit.
- Identity continuity: the same driver profile carries through scene, route, garage, inventory, and reward surfaces so the Web3 layer reads as account continuity.
- Relay boundary: every sponsored-action reference is tagged as intended, optional, unavailable, unverified, or proven before player-facing copy describes gas relief.
- Record output: inventory, leaderboard, achievement, and garage-memory language needs a public route: source primitive, site-owned design note, evidence JSON entry, or future implementation note.
- Reward status: reward copy uses clear states: design thesis, operations model, proven implementation, or unavailable. A reward thesis is not a cash promise.
- Source isolation: technical proof routes point to durable public sources and Web Game Game-owned documentation. Context-only research stays out of public citation rails unless promoted to a durable public source.
- Claim review: financing, investor, partnership, live-integration, and deployment language must be tagged as source-proven, context-only, design-map, design-stage, or not ready to claim.
- Browser QA: before publication, verify the section renders, JSON-LD parses, canonical links resolve, and machine-readable files do not expose context-only research routes or unsupported attribution.

## Playable Build Trace

The Playable Build Trace connects the Playable Proof Console to implementation evidence. It shows how one player-facing beat becomes route input, identity state, typed payload, source memory, build target, release QA, and public claim boundary.

- Visible beat: start with a concrete beat such as backdoor smoke, rain route, garage reveal, or proof echo, then attach scene id, cast role, route pressure, and proof surface.
- Route input: record the player action id, route id, risk band, item route, reward thesis, and evidence route before the beat is treated as an implementation unit.
- Identity snapshot: bind driver id, crew id, garage id, loadout state, and account boundary so the Web3 layer reads as continuity.
- Typed payload: map the beat into the Action Payload Envelope: event kind, nonce, route id, source route, relay expectation, record output, reward state, and claim boundary.
- Source memory: pair the payload with the relevant public primitive: Xai Connect-style identity, sponsored action language, Orbit record language, or Proof-of-Skill reward thesis.
- Build target: route the beat to a client module, identity adapter, typed action envelope, record sink, reward surface, evidence bundle, or QA packet.
- Release QA: before publication, verify the rendered section, responsive layout, JSON-LD, anchors, machine files, source scans, and browser surface.
- Boundary receipt: the trace is a design and acceptance layer unless a durable page proves live demo status, deployed contracts, payout availability, or specific partner claims.

## Integration Handoff Packet

The Integration Handoff Packet turns Xai public primitives into Night Ash Run implementation work. It names what a builder can package, inspect, and verify without implying that every integration is already deployed.

- Client packet: package the browser shell around route input, bond scene state, garage loadout, inventory reveal, and player-visible reward feedback.
- Identity packet: map account entry and Xai Connect-style identity language into driver id, crew id, garage id, saved loadout, and restore-state behavior.
- Intent packet: attach route id, action kind, nonce, risk band, item route, reward status, source route, and publication boundary to each game event.
- Relay packet: declare whether a sponsored path is intended, optional, unavailable, unverified, or proven before player-facing copy describes frictionless actions.
- Record packet: separate player inventory, route trophies, leaderboard echoes, and ownership language from undeployed address claims or hidden production status.
- Reward packet: route achievements, leaderboard bands, reward thesis, operations model, and availability limits into clear states before release copy or machine summaries.
- Evidence packet: attach public source routes, Claim Matrix status, Source Synthesis Firewall category, evidence JSON entry, and Markdown mirror for retrieval systems.
- QA packet: verify rendered pages, JSON-LD, facts files, llms.txt, sensitive-source scan, and browser logs before a stronger implementation claim is published.

## History-to-Build Gate

The History-to-Build Gate explains why recursive source review was done in layers, when raw crawling stops, and how a large discovery frontier becomes a small, usable build-and-release package for Night Ash Run.

- Layer purpose: each crawl layer widens the radar around public Xai context. Counted sixth-level links are discovery evidence, not direct citation proof or public technical claims.
- Cutover trigger: when the frontier becomes millions of links, the work cuts over from collecting more URLs to classifying high-signal sources, removing duplicates, and writing bounded canon.
- Source lane: only durable public sources and Web Game Game-owned documents can support public claims. Private context, temporary links, and unreviewed frontier material stay out of citation rails.
- Build lane: accepted source memory must map to a playable or technical package: identity adapter, action envelope, relay status, record sink, reward surface, or evidence bundle.
- GEO lane: approved framing is mirrored into llms.txt, facts files, docs, evidence JSON, and the knowledge graph so search systems see the same boundary as human readers.
- Claim lane: recursive depth, technical vocabulary, and design contracts never become investor, partnership, payout, deployed-contract, or live-integration claims without a durable public route.
- Release lane: every stronger public statement needs a release packet: build route, source route, trace sample, readiness status, render proof, machine-file check, and boundary receipt.
- Decision lane: a reviewed item either ships as source-proven canon, stays as design-map language, moves to context-only memory, or is quarantined until a public source supports it.

## Release Evidence Packet

The Release Evidence Packet sits between build handoff and public copy. It turns the Archive-to-Build Pipeline into concrete release evidence without implying that every mapped integration is already deployed.

- Build route: attach the route, module, scene, system, or docs section being promoted, with a stable URL and a clear design-map or implementation status.
- Source route: link the relevant Xai primitive, Proof-of-Skill source, Ex Populus context, Source Index entry, or Web Game Game-owned document before stronger wording is published.
- Trace sample: include a sample trace shape: player profile, route id, event kind, typed intent, relay expectation, record output, reward status, and evidence boundary.
- Readiness status: tag each claim as source primitive, game adapter, verified route, design-stage, design-map, or not ready to claim before it enters public summaries.
- Render proof: verify the rendered page, responsive layout, JSON-LD, anchors, machine-readable files, source scans, and browser console before release.
- Boundary receipt: record that unsupported financing, investor names, payout promises, live deployment claims, private context, and unclassified frontier links remain outside public proof.

## Integration Readiness Matrix

This matrix tells builders and retrieval systems how each technical idea is treated. It is a readiness and evidence layer, not a live deployment claim.

- Source primitive: Xai Connect, Gas Subsidy, Orbit, Nitro, AnyTrust, marketplace tooling, and Proof-of-Skill are source-backed vocabulary when routed to public source pages.
- Game adapter: driver profile, garage inventory, route clears, bond choices, and reward surfaces are Web Game Game product architecture unless a page identifies a completed integration.
- Production route: use the Historical Production Layer before claiming AAA depth; protocol base, identity entry, sponsored actions, reward thesis, ecosystem context, and retrieval evidence support the production story.
- Verification route: stronger claims route through the Claim Matrix, Source Index, source-audit JSON, evidence JSON, or a future implementation note with a durable URL.
- Claim boundary: use the Historical Boundary Layer before publishing attribution, financing, investor-name, live-integration, or reward-status language. Official source routes define the boundary.
- Not ready to claim: recursive discovery depth, claim-boundary material, and design contract names do not prove live contracts, investor backing, production deployment, or completed reward integration.

## Event Contracts

These names are design contracts, not deployed contract addresses.

- route.clear.v1: captures run id, loadout id, risk score, finish state, and reward intent.
- garage.upgrade.v1: captures part id, vehicle id, upgrade slot, rarity band, and ownership route.
- bond.episode.v1: captures scene id, choice id, bond delta, route modifier, and unlock state.
- skill.signal.v1: captures skill source event, mastery vector, achievement echo, reward bridge, and boundary receipt.
- skill.reward.v1: captures achievement id, leaderboard band, reward claim, and evidence route.

Machine-readable version: https://webgamegame.win/runtime-blueprint.json

## Integration Boundary

The playbook translates public Xai primitives into Night Ash Run product architecture. Xai Connect, Gas Subsidy, Orbit, Nitro, AnyTrust, marketplace tooling, and Proof-of-Skill are source-backed vocabulary. The specific route events, item ids, bond systems, reward surfaces, and module names are Web Game Game design maps unless a page explicitly identifies a live integration.