> 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/docs/extensions/ai-rogue/run-loop-rebuild-notes.md). # AI Rogue Run Loop Rebuild Notes **Status**: Current **Checked**: 2026-06-26 This note preserves objective implementation facts from the first AI Rogue Play route and the same-day rebuild. It is intentionally limited to verifiable behavior, acceptance criteria, and remaining concrete follow-ups. ## Initial Play Route Baseline The first delivered Play route mounted the PixiJS runtime and persistence plumbing, but the playable route was a fixed smoke-test scenario: * Runtime run creation used `createAiRogueScenarioWorld("movement")` instead of the seeded `createAiRogueWorld()` generator. * The `"movement"` fixture was a five-row map with the player and exit on the same row and one enemy off the direct route. * The browser win path completed by pressing `ArrowRight` repeatedly until the route reached `complete`. * Primary and secondary controls were wired but resolved to no-op events. * Attack and defeat events did not project visible feedback sprites; feedback projection only covered threat and hazard events. * Exit contact ended the run immediately instead of descending to another floor. * `upgrade-relic` existed as a pickup template without an in-run choice. * Runtime and save diagnostics were exposed directly on the player-facing Play screen. Those facts made the first route useful as a technical smoke test but not as a durable roguelike loop. ## Rebuild Acceptance Bar AI Rogue Play route work should not count as product progress unless the Play surface itself demonstrates these properties: * The route uses seed-driven generated content or a deliberately authored room sequence with multiple encounters. * The first minute includes unavoidable, readable combat. * Primary and secondary actions have real gameplay effects. * At least three enemy behaviors are visible and tactically different. * At least one in-run reward choice changes subsequent combat. * A run cannot be completed by walking straight to the exit without a decision. * Attack, damage, defeat, pickups, and threats have visible feedback. * Replay tests assert that different seeds produce meaningfully different maps or encounter sequences. * Developer/runtime diagnostics are hidden by default behind player-facing game UI. * Browser tests include a scripted combat encounter and verify attack or defeat feedback, not only canvas mount and movement pixels. * Clear credit, achievements, and relic-synergy unlocks require surviving real combat or making a genuine decision. * A human playtest note records whether the loop is fun, confusing, boring, or worth replaying. ## Rebuild Status The run loop was rebuilt on 2026-06-22. | Gate | Status | Current Evidence | | ---------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Seed-driven generated maps | PASS | `createRuntimeRun` now uses `createAiRogueWorld`, not the `"movement"` fixture. | | Forced combat | PASS | Generated floors place an exit guard on the required path. | | Real primary/secondary verbs | PASS | Strike attacks the faced tile; Surge spends shards to hit adjacent enemies. | | Three enemy behaviors | PASS | Melee chaser, ranged sentry, and swarm-rusher behavior are distinct. | | In-run reward choice | PASS | A three-relic shrine applies one relic and consumes the other choices. | | No straight exit clear | PASS | Exit guard plus descent loop blocks trivial corridor completion. | | Visible feedback | PASS | Attack, defeat, pickup, and descent events project feedback sprites. | | Seed replay coverage | PASS | Tests assert different seeds produce different maps. | | Player-first Play screen | PASS | Diagnostics are hidden by default and the route leads with player-facing guidance. | | Multi-floor run | PASS | The run descends through three sectors before final completion. | | Browser combat coverage | PASS | The local/test-only runtime scenario hook checks attack feedback and canvas pixel changes; product routes use generated runs. | | Human fun verdict | PENDING | Mechanics are verified, but subjective playtest sign-off still requires a person. | | Audio and deeper art polish | PASS | Current HUD text, FX, motion, run arc, audio, and atlas usage are documented in [Game Feel And Audio Baseline](/ai-os-and-trend-finder-docs/docs/extensions/ai-rogue/game-feel.md). | Phase 34 Session 03 also fixed the AR-D2-001 lethal turn-start status boundary: Movement, Strike, Surge, and Protocol now share the same immediate loss path when burning or leaking defeats the player before action resolution. See [AI Rogue Playtest Notes](/ai-os-and-trend-finder-docs/docs/extensions/ai-rogue/playtest-notes.md) for the browser verification notes and the current playtest follow-ups. --- # 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/docs/extensions/ai-rogue/run-loop-rebuild-notes.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.