> For the complete documentation index, see [llms.txt](https://ai-os-and-trend-finder.gitbook.io/ai-os-and-trend-finder-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ai-os-and-trend-finder.gitbook.io/ai-os-and-trend-finder-docs/.spec_system/archive/phases/phase_39/session_08_validation_and_documentation_hardening.md). # Session 08: Validation And Documentation Hardening **Session ID**: `phase39-session08-validation-and-documentation-hardening` **Status**: Not Started **Estimated Tasks**: \~12-25 **Estimated Duration**: 2-4 hours *** ## Objective Make the final workflow repeatable by tightening commands, documentation, migration rules, and release evidence. *** ## Scope ### In Scope (MVP) * Run and document the validation gates for typecheck, focused Vitest suites, asset-size checks, save-schema tests, boss/render/audio/combat tests, and build/budget checks where import shape changed. * Run relevant Playwright AI Rogue desktop and mobile checks when rendering, controls, audio unlock, or route-visible UI changed. * Update authoring documentation so existing-media and real-content level checklists match the implemented registry, validation, save, asset, and audio workflow. * Confirm save and migration rules: do not persist whole level specs, keep old IDs loadable when retired, and bump `AI_ROGUE_SAVE_SCHEMA_VERSION` only for real migrations. * Re-check privacy and non-goal boundaries for content, saves, tests, docs, and provenance. ### Out of Scope * Adding more gameplay content. * Introducing remote content loading, mod systems, telemetry dependencies, broad inventory rewrites, worker migrations, or map-editor dependencies. *** ## Detailed Plan Notes * Documentation must describe current shipped behavior before planned behavior. * Authoring docs should include both existing-media and real-content level checklists matching the implemented registry, validation, save, asset, and audio workflow. * Save rules to confirm: persist level IDs, depth, runtime state, entity IDs, and small state only; do not persist whole level specs; add IDs to Zod enums deliberately when new saved IDs exist; keep old IDs loadable as hidden compatibility entries if content is retired; bump `AI_ROGUE_SAVE_SCHEMA_VERSION` only for real migrations. * Maintain current private-looking text rejection rules for labels, warnings, provenance, route-visible copy, tests, and docs. * Re-check that no non-goals were introduced: remote content loading, dynamic plugins, user-authored mod system, collectors, hosted writes, analytics, telemetry dependency, raw prompts, transcripts, local file paths, logs, command bodies, credentials, private telemetry, broad inventory rewrite, worker simulation migration without profiling, Tiled or map-editor dependency, or a new boss before Kernel Sentinel is represented by a reusable boss spec. * No authoring path should require hunting through eight depth resolvers and hoping rotation math lands on the intended content. *** ## Validation Gates Every phase: ```bash bun run typecheck bunx vitest run src/extensions/ai-rogue/runtime/__tests__/assets.test.ts bunx vitest run src/extensions/ai-rogue/runtime/__tests__/world.test.ts \ src/extensions/ai-rogue/runtime/__tests__/simulation.test.ts bash scripts/check-asset-sizes.sh ``` Registry and resolver phases: ```bash bunx vitest run src/extensions/ai-rogue/runtime/__tests__/floor-arc.test.ts \ src/extensions/ai-rogue/runtime/__tests__/themes.test.ts \ src/extensions/ai-rogue/runtime/__tests__/prefabs.test.ts \ src/extensions/ai-rogue/runtime/__tests__/protocols.test.ts \ src/extensions/ai-rogue/runtime/__tests__/terminals.test.ts \ src/extensions/ai-rogue/runtime/__tests__/audio.test.ts ``` Save, boss, render, or route-visible phases: ```bash bunx vitest run src/extensions/ai-rogue/__tests__/save-schema.test.ts bunx vitest run src/extensions/ai-rogue/runtime/__tests__/boss-presentation.test.ts \ src/extensions/ai-rogue/runtime/__tests__/render-model.test.ts \ src/extensions/ai-rogue/runtime/__tests__/renderer-audio-adapter.test.ts \ src/extensions/ai-rogue/runtime/__tests__/combat.test.ts ``` Run relevant Playwright AI Rogue desktop/mobile checks whenever a change touches runtime rendering, controls, audio unlock behavior, or route-visible UI. Run `bun run build` and `bun run budget:check` on milestones that touch route code or import shape. *** ## Prerequisites * [ ] Runtime, content, rendering, audio, save, or route import changes from prior sessions are complete. * [ ] The full validation command set is known and runnable or exact blockers are documented. *** ## Deliverables 1. Final validation evidence for the implemented level-authoring infrastructure. 2. Updated docs and checklists that match shipped behavior. 3. Confirmed save, privacy, asset, audio, and bundle-budget posture. *** ## Success Criteria * [ ] Required local validation commands pass or failures are documented with exact blockers. * [ ] Documentation describes current shipped behavior before planned behavior. * [ ] The level-authoring workflow is ready for future sessions without relying on the old depth-resolver checklist. --- # 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://ai-os-and-trend-finder.gitbook.io/ai-os-and-trend-finder-docs/.spec_system/archive/phases/phase_39/session_08_validation_and_documentation_hardening.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.