> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_24/session_08_generated_asset_implementation_handoff.md). # Session 08: Generated Asset Implementation Handoff **Session ID**: `phase24-session08-generated-asset-implementation-handoff` **Package**: apps/web **Status**: Not Started **Estimated Tasks**: \~18 **Estimated Duration**: 2-4 hours *** ## Objective Promote the Phase 3 generated visual sheets from manifest-only availability into direct implementation references for the web game layer: live enemy effects, strike vocabulary, and reduced-motion static badges must have typed asset records, runtime or catalog integration points, fallback labels, and tests so future agents do not miss that the assets already exist. *** ## Scope ### In Scope (MVP) * Directly reference these Phase 3 assets in the app implementation path, not only in docs: * `assets/generated/game-design/phase03/live-enemies/live-enemy-effects-sheet.png` * `assets/generated/game-design/phase03/strike-vocabulary/strike-vocabulary-effects-sheet.png` * `assets/generated/game-design/phase03/reduced-motion/reduced-motion-static-badges-sheet.png` * Add typed asset ids, source paths, dimensions, intended usage, fallback text, reduced-motion pairing, and runtime-readiness posture to the existing app media/catalog pattern or a dedicated `apps/web` game-design asset map. * Wire Phase 24 battlefield presentation helpers and components to consume those typed references for live enemy markers, strike effects, combo/stage treatments, and static badge equivalents where the owning session surfaces exist. * Preserve the current DOM/CSS-first behavior when a sheet is not sliced or app-served yet, but make that a typed fallback state instead of an implicit omission. * If app-serving is required, promote through app-owned paths and document mirror/cache/fallback/accessibility posture; do not make runtime code discover files directly from `assets/generated/game-design/`. * Add focused tests proving every Phase 3 visual state has either a direct asset mapping or an explicit typed fallback, and that no referenced asset path is missing. * Update relevant docs so `docs/game-design/manifest.md`, media docs, and the Phase 24 closeout all point at the same asset ids and implementation posture. ### Out of Scope * Generating replacement art or new art. * XP, loot, banners, titles, Battle Report, War Council, War Tide, seasons, public-demo synthetic front behavior, or reward logic. * Broad public-demo mirroring unless the selected app-serving path requires it and can pass the existing media gate. * New protocol events, server routes, storage keys, hosted dependencies, or trusted-erasure claims. *** ## Prerequisites * [ ] Session 03 complete (live enemy presentation targets exist). * [ ] Session 04 complete (combat playback effect states exist). * [ ] Session 05 complete (scrying and alert-focus static twins exist). * [ ] `docs/game-design/manifest.md` lists the three Phase 3 generated assets. *** ## Deliverables 1. Typed Phase 3 generated-asset references in the `apps/web` implementation or media catalog path, with ids, paths, dimensions, fallback labels, and runtime posture. 2. Battlefield/live-legion/effects/reduced-motion code consuming those references where Phase 24 surfaces exist, with typed fallback behavior where runtime slicing is deferred. 3. Focused tests covering asset-reference completeness, missing-path guards, fallback labels, reduced-motion pairing, and no direct runtime discovery from `assets/generated/game-design/`. 4. Updated docs/handoff notes linking the manifest asset ids to the actual app references and any app-served promotion paths. *** ## Success Criteria * [ ] The three Phase 3 generated asset paths are referenced by app source or app catalog code, not only by Markdown. * [ ] Every live enemy, strike, combo/stage, scrying/alert, and static-badge visual state shipped by Phase 24 has a direct asset id or a typed fallback label. * [ ] Runtime code does not discover or load from `assets/generated/` paths directly; any browser-served files are promoted through app-owned paths. * [ ] Tests fail if a Phase 3 generated asset path is removed, misspelled, or left without an implementation/fallback mapping. * [ ] Web typecheck, focused tests, and relevant media/catalog checks pass. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_24/session_08_generated_asset_implementation_handoff.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.