> 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/sessions/phase32-session01-baseline-validation/spec.md). # Session Specification **Session ID**: `phase32-session01-baseline-validation` **Phase**: 32 - AI Rogue Mobile Input Auto-Detect **Status**: Not Started **Created**: 2026-06-24 *** ## 1. Session Overview This session confirms the AI Rogue first-run mobile input failure before any implementation changes. The reported path is a fresh mobile session with no saved `ai-os.ai-rogue.preferences.v1` record: Start works, but movement is not usable because the current durable preference default is `keyboard`. The work is next because Phase 32 depends on a validated capability heuristic before adding a durable `auto` preference. Session 01 turns the current research and route/test evidence into a formal capability matrix that Session 02 can use without guessing. The session is validation and documentation only. Runtime source changes, preference schema changes, Settings copy updates, and new automated gameplay coverage are intentionally deferred to later phase-32 sessions. *** ## 2. Objectives 1. Reproduce the fresh no-preferences mobile path on the current local or static public-demo build. 2. Capture pointer, hover, viewport, and touch capability values for fresh mobile and desktop contexts. 3. Verify explicit `compact` remains playable and explicit `keyboard` remains keyboard-first on mobile. 4. Record whether the observed public-demo hydration warning is independent of the movement failure. *** ## 3. Prerequisites ### Required Sessions * [x] `phase31-session07-release-polish-and-documentation` - Provides the completed static public-demo baseline and no-bridge smoke posture. ### Required Tools Or Knowledge * Bun 1.3.14 project scripts from `package.json`. * Playwright mobile and desktop contexts from `playwright.config.ts`. * Current AI Rogue preference, runtime canvas, renderer, and mobile smoke paths. ### Environment Requirements * Local dependency install is available for `bun run` commands. * A local dev server or static Pages demo preview can serve `/extensions/ai-rogue/play`. * Real mobile browser validation is optional; if unavailable, the implementation notes must record the emulator limitation. *** ## 4. Scope ### In Scope (MVP) * Operator validates fresh mobile gameplay - Reproduce Start plus movement behavior with no saved AI Rogue preferences. * Operator captures capability signals - Record `pointer: coarse`, `hover: hover`, viewport size, and `navigator.maxTouchPoints`. * Operator validates explicit overrides - Prove `compact` is playable and `keyboard` remains keyboard-first on mobile. * Operator compares desktop behavior - Confirm fresh desktop remains keyboard-first under current defaults. * Operator classifies public-demo warning - Determine whether the minified hydration warning affects input validation. * Operator records implementation recommendation - Update the research note with a capability matrix and Session 02 heuristic recommendation. ### Out Of Scope (Deferred) * Preference schema changes - Reason: Session 02 owns the durable `auto` contract. * Runtime Canvas effective-mode wiring - Reason: Session 03 owns runtime and canvas plumbing. * Settings, Loadout, Play, and HUD copy changes - Reason: Session 04 owns product copy alignment. * New or modified automated gameplay tests - Reason: Session 05 owns coverage after the implementation path exists. * AI Rogue default extension enablement - Reason: Phase 32 fixes enabled AI Rogue input defaults only. *** ## 5. Technical Approach ### Architecture Use the existing AI Rogue route and public-demo surfaces as the source of truth. The validation probes should clear or seed only browser-local AI Rogue preferences, then observe the current Play route behavior without patching source files. Runtime evidence should be tied back to the current boundaries: `save-schema.ts` owns durable defaults, `runtime-canvas.tsx` owns compact control enablement, and `renderer.ts` gates canvas pointer input behind compact mode. The capability check should be gathered at the mounted browser edge, matching the planned architecture for later sessions. The output should decide whether pointer/hover media queries are sufficient for the Session 02 pure resolver and mounted hook. ### Design Patterns * Documentation-first validation: The implementation session records current behavior before changing it. * Browser-local isolation: Use localStorage and context setup instead of app source edits. * Static-demo privacy posture: Public-demo probing must preserve no `/__*` local bridge requests. * Capability injection by observation: Capture browser capability values now so later resolver tests can use explicit inputs. *** ## 6. Deliverables ### Files To Create | File | Purpose | Est. Lines | | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ---------- | | `.spec_system/specs/phase32-session01-baseline-validation/implementation-notes.md` | Probe commands, scenario outcomes, capability matrix, and Session 02 recommendation | \~120 | ### Files To Modify | File | Changes | Est. Lines | | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ---------- | | `docs/ongoing-projects/ai-rogue-mobile-input-research-2026-06-24.md` | Add formal Session 01 validation results, capability matrix, hydration warning note, and residual real-device risk if any | \~80 | *** ## 7. Success Criteria ### Functional Requirements * [ ] Fresh mobile with no `ai-os.ai-rogue.preferences.v1` record starts the runtime but cannot complete movement under the current keyboard default. * [ ] Explicit `compact` mode can Start and move on mobile through compact controls or canvas pointer input. * [ ] Explicit `keyboard` mode stays keyboard-first on mobile and does not enable compact controls. * [ ] Fresh desktop/fine-pointer behavior remains keyboard-first. * [ ] The selected auto signal maps mobile or mobile-emulated contexts to compact and desktop/fine-pointer contexts to keyboard. ### Testing Requirements * [ ] Focused Playwright or browser probes completed for fresh mobile, explicit compact, explicit keyboard, and fresh desktop. * [ ] Existing relevant AI Rogue and public-demo smoke commands are run or documented with a concrete reason if not run. * [ ] Public-demo probing records whether any `/__*` local bridge requests occurred. ### Non-Functional Requirements * [ ] No runtime, schema, route, Settings, or test implementation files are changed in this validation-only session. * [ ] Hydration warning is classified as independent, implementation risk, or separate follow-up with evidence. * [ ] Real-device limitation is documented when validation uses emulation only. ### Quality Gates * [ ] All files ASCII-encoded. * [ ] Unix LF line endings. * [ ] Code follows project conventions. * [ ] Documentation distinguishes observed behavior from planned Phase 32 implementation. *** ## 8. Implementation Notes ### Working Assumptions * Session 01 is validation-only: The phase stub explicitly puts source-code, preference default, Settings UI, and public-demo deployment changes out of scope, and the research note says the initial pass made no runtime/source changes. Planning can proceed because the deliverable is a documented baseline, not a fix. * Playwright mobile emulation is acceptable when a real device is unavailable: The research note asks for a real mobile browser if available, otherwise to document the emulator limitation. Planning can proceed because the phase can still validate the capability heuristic with explicit residual risk. * The public-demo path is relevant to the bug: Phase 32 states the user report came through `demo-website`, and Phase 31 established `/extensions/ai-rogue/play` as a static public-demo route. Planning should include both app route behavior and static-demo no-bridge posture. ### Key Considerations * Current `aiRoguePreferencesSchema.inputMode` defaults to `keyboard` in `src/extensions/ai-rogue/save-schema.ts`. * Current compact controls enable only when `preferences.inputMode === "compact"` in `src/extensions/ai-rogue/views/runtime-canvas.tsx`. * Current renderer pointer movement returns unless `state.inputMode === "compact"` in `src/extensions/ai-rogue/runtime/renderer.ts`. * Existing mobile Playwright coverage seeds compact preferences before testing, so it does not cover the fresh no-preferences failure path. * Existing public-demo mobile coverage checks rendering, no-bridge requests, and overflow, but not Start plus first move. ### Potential Challenges * Real mobile hardware may be unavailable: Record emulator coverage and residual risk rather than stopping the session. * Static demo preview can be slow to build: Prefer focused app-route probes first, then static-demo confirmation for no-bridge and warning classification. * Pixel-only movement evidence can be misleading: Prefer runtime event text, turn value, or compact control command evidence where available. ### Relevant Considerations * \[P30] **AI Rogue default enablement deferred**: This session validates enabled AI Rogue behavior only and must not widen extension visibility. * \[P30] **Route-lazy runtime ownership scales**: Keep Pixi behind the Play route/local facade; validation should not move capability detection into runtime. * \[P30] **Schema-backed browser-local state works**: Later preference changes should remain additive and migration-backed; this session records current defaults. * \[P30] **PixiJS v8 route tests**: Use strict runtime verification patterns and avoid pixel-only conclusions when proving gameplay input. * \[P31] **Pages demo stays static-only**: Public-demo validation must not introduce bridge calls, Functions, collectors, hosted writes, or analytics. * \[P31] **Route smoke is a privacy gate**: Preserve no `/__*` request assertions while extending validation notes toward gameplay input. *** ## 9. Testing Strategy ### Unit Tests * No unit tests are added in this validation-only session. * Review existing preference defaults in `src/extensions/ai-rogue/__tests__/save-schema.test.ts` to identify Session 02 update points. ### Integration Tests * Run or reference focused existing browser coverage from `tests/e2e/ai-rogue-mobile.spec.ts`, `tests/e2e/ai-rogue-runtime.spec.ts`, and `tests/e2e/pages-demo-mobile.spec.ts`. * Use the results to document current coverage gaps, not to modify test files in this session. ### Runtime Verification * Probe `/extensions/ai-rogue/play` with no saved AI Rogue preferences in a mobile/touch context. * Probe `/extensions/ai-rogue/play` with explicit compact preferences in a mobile/touch context. * Probe `/extensions/ai-rogue/play` with explicit keyboard preferences in a mobile/touch context. * Probe `/extensions/ai-rogue/play` with no saved AI Rogue preferences in a desktop/fine-pointer context. * Probe the static public-demo build or preview for route behavior and no `/__*` request leakage. ### Edge Cases * Missing browser media query APIs should be recorded as a desktop-safe fallback concern for Session 02. * Hybrid touch-plus-keyboard signals should be called out if observed. * Hydration warnings should be separated from input behavior unless evidence links them. *** ## 10. Dependencies ### Other Sessions * Depends on: Phase 31 complete. * Depended by: `phase32-session02-preference-contract`, `phase32-session03-effective-mode-wiring`, `phase32-session04-settings-and-copy`, `phase32-session05-gameplay-test-coverage`. *** ## Next Steps Run the `implement` workflow step to begin implementation. --- # 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/sessions/phase32-session01-baseline-validation/spec.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.