> 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/phase35-session01-rebaseline-audit-evidence/spec.md). # Session Specification **Session ID**: `phase35-session01-rebaseline-audit-evidence` **Phase**: 35 - AI Rogue Audit Hardening And Refactor **Status**: Not Started **Created**: 2026-06-26 *** ## 1. Session Overview This session rebaselines the folded AI Rogue audit findings against the current Phase 34 closeout evidence before any Phase 35 implementation work starts. It turns the historical audit register into a current finding-status ledger so the remaining sessions can distinguish fixed blockers, live follow-up work, historical findings, caveats, and deferred capability work. The work is documentation and evidence focused. It verifies current default enablement, the explicit `none` opt-out, no-new-D3 privacy and capability boundaries, Phase 34 gate evidence, and stale coverage-gap language. Runtime fixes, broad refactors, and feature changes stay out of this session unless a narrow evidence correction is required to keep the phase plan accurate. *** ## 2. Objectives 1. Produce an unambiguous current status for every AR-D1 through AR-D9 finding. 2. Verify AI Rogue default enablement and explicit `none` opt-out evidence against current source and tests. 3. Reconfirm the D3 privacy and capability boundary from current source, docs, tests, and available built artifacts. 4. Update Phase 35 evidence notes so later sessions know which coverage gaps are already satisfied and which remain live. *** ## 3. Prerequisites ### Required Sessions * [x] `phase34-session08-default-enablement-evidence-closeout` - Provides the validated Phase 34 closeout gate matrix, Production Go posture, and final finding-status evidence. ### Required Tools Or Knowledge * Bun 1.3.14 project scripts from `package.json`. * `rg`, `find`, `wc`, `jq`, and standard shell tools for evidence scans. * Knowledge of AI Rogue source, tests, docs, and Pages demo safety boundaries. ### Environment Requirements * Run from the repository root. * Preserve the existing dirty worktree and do not revert unrelated Phase 34 or Phase 35 spec-system changes. * Keep all generated session artifacts ASCII-only with Unix LF line endings. *** ## 4. Scope ### In Scope (MVP) * Maintainers can compare Phase 34 closeout status, historical No-Go text, the folded finding register, follow-up backlog, and completion criteria - record the current interpretation in a Phase 35 rebaseline ledger. * Maintainers can verify browser extension enablement behavior for unset, blank, valid-list, `all`, and `none` values - document the source and test evidence. * Maintainers can confirm AI Rogue still has no collector, hosted write path, analytics, Functions, remote game-content loading, raw private telemetry export, WebGPU-only path, worker runtime, or public-demo bridge dependency - record source, docs, test, and scan evidence. * Maintainers can identify stale coverage-gap and docs language that is already satisfied by Phase 34 versus live work for Sessions 02-10 - update the Phase 35 PRD and session implementation notes. ### Out Of Scope (Deferred) * Runtime fixes for accessibility, renderer scheduling, persistence, or simulation behavior - Reason: Sessions 02-08 own implementation and refactor work after this status reconciliation. * Broad documentation rewrite across AI Rogue docs - Reason: Session 09 owns documentation and media policy sync after implementation sessions settle. * New AI Rogue capabilities such as collectors, WebGPU-only behavior, worker protocols, hosted writes, remote loading, or expanded content - Reason: the phase explicitly preserves current browser-local and static-demo boundaries. *** ## 5. Technical Approach ### Architecture Use the Phase 35 PRD and Session 01 stub as the planning contract, the analysis script as workflow state authority, and Phase 34 closeout artifacts as the latest validated evidence. The implementation should produce one durable evidence ledger in this session directory and a concise rebaseline section in `.spec_system/PRD/phase_35/PRD_phase_35.md`. The evidence ledger should classify every finding as Fixed, Live, Historical, Caveat, or Deferred. Each row should include the current interpretation, the supporting source or validation artifact, the default-enable impact, and the next Phase 35 owner when follow-up remains. ### Design Patterns * Evidence ledger: Keeps audit findings traceable without scattering status notes across unrelated docs. * Docs-first phase coordination: Updates the PRD with current source-backed facts before downstream implementation sessions consume the audit plan. * Narrow correction: Changes only spec-system or evidence docs unless a command reveals a concrete current blocker that must be recorded. *** ## 6. Deliverables ### Files To Create | File | Purpose | Est. Lines | | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ---------- | | `.spec_system/specs/phase35-session01-rebaseline-audit-evidence/implementation-notes.md` | Current AR-D1 through AR-D9 status ledger, enablement evidence, D3 boundary evidence, stale coverage-gap list, and command evidence. | \~350 | ### Files To Modify | File | Changes | Est. Lines | | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | ---------- | | `.spec_system/PRD/phase_35/PRD_phase_35.md` | Add Session 01 rebaseline results, finding-status summary, evidence notes, and downstream session routing for still-live work. | \~120 | | `.spec_system/specs/phase35-session01-rebaseline-audit-evidence/tasks.md` | Mark tasks complete during implementation and keep final checklist evidence current. | \~20 | *** ## 7. Success Criteria ### Functional Requirements * [ ] Every AR-D1 through AR-D9 register item has a current status and evidence source. * [ ] Production default enablement and explicit `none` opt-out are verified against current source and tests. * [ ] No new D3 privacy or hosted-capability finding is promoted. * [ ] Stale audit language is either marked historical or assigned to a later Phase 35 session. ### Testing Requirements * [ ] Focused enablement tests run and pass, or any failure is recorded with a concrete blocker. * [ ] Targeted AI Rogue privacy and capability scans run and produce exact evidence. * [ ] Verification scenarios for source, docs, and available built artifacts are completed. ### Non-Functional Requirements * [ ] The evidence ledger is specific enough for Sessions 02-10 to avoid duplicate or stale work. * [ ] The phase plan continues to preserve browser-local AI Rogue state and static Pages demo no-bridge boundaries. * [ ] Tight bundle-budget headroom and active-at-cap playthrough caveats remain visible when interpreting release evidence. ### Quality Gates * [ ] All files ASCII-encoded * [ ] Unix LF line endings * [ ] Code follows project conventions * [ ] Documentation describes current behavior and separates historical evidence from current contracts. *** ## 8. Implementation Notes ### Working Assumptions * Phase 34 closeout is the latest validated baseline: the analysis script lists `phase34-session08-default-enablement-evidence-closeout` as completed, and its validation report records passing gate, privacy, browser, Pages, and playthrough evidence. It is safe to plan from that baseline because Session 01 is explicitly a recheck before implementation. * Session 01 should not add broad runtime fixes: the stub says runtime fixes are out of scope beyond narrow documentation/evidence correction, and Sessions 02-08 own coverage, accessibility, renderer, persistence, simulation, renderer bridge, world, and type work. ### Conflict Resolutions * The historical 2026-06-25 No-Go conflicts with the Phase 34 Production Go. The chosen interpretation is to preserve the No-Go as historical and treat the Phase 34 closeout as the current baseline, because the Phase 35 PRD, security posture, current docs, registry tests, and Phase 34 validation all record default enablement with `none` as the explicit opt-out. * Some Phase 34 closeout wording still refers to explicit opt-in posture while current Phase 35 artifacts and source-backed docs state default enablement. Treat that wording as stale evidence to classify during this session rather than as a blocker, because current source and tests are the deciding runtime contract. ### Key Considerations * The current worktree already contains uncommitted Phase 34 and Phase 35 spec-system changes; implementation must preserve them. * Phase 35 depends on correct status routing because Session 02 should not add redundant tests for already-covered contracts. * D3 evidence must distinguish product-local DOM data attributes from actual local bridge requests, hosted writes, collectors, analytics, or raw telemetry paths. ### Potential Challenges * Built artifacts may be absent or stale: Record source/docs/test evidence and scan available built artifacts only when they exist. * Large prior closeout artifacts are verbose: Summarize exact evidence in the new implementation notes while linking to the source artifacts by path. * Historical docs may intentionally preserve old findings: Mark them as historical or queue them for Session 09 instead of rewriting them here. ### Relevant Considerations * \[P34] **AI Rogue is production default-enabled**: Preserve the default and explicit `none` disable path while rebaselining the audit. * \[P31-P34] **Pages and AI Rogue CI guards deferred**: Keep Pages build/scan, no-bridge, budget, route smoke, and AI Rogue gameplay evidence bundled in the release-gate story. * \[P31-P34] **Public-demo and AI Rogue gates stay bundled**: Treat privacy, budget, Pages, and playthrough checks as a connected release posture. * \[P30/P32/P34] **Route-lazy runtime ownership scales**: Do not widen AI Rogue runtime or route capability while planning evidence work. * \[P30/P32/P34] **Schema-backed browser-local state works**: Preserve local state boundaries when interpreting persistence findings. * \[P34] **Do not expose deterministic fixtures through product routes**: Fixture evidence belongs in tests and local hooks, not product routes. * \[P30/P32/P34] **Do not widen AI Rogue capabilities without review**: Collectors, WebGPU, workers, remote loading, hosted writes, or expanded content remain deferred. *** ## 9. Testing Strategy ### Unit Tests * Run focused host extension enablement tests that cover default AI Rogue enablement and explicit `none` disable behavior. * Run any focused AI Rogue tests needed to confirm existing coverage anchors cited in the status ledger. ### Integration Tests * Inspect existing AI Rogue e2e and Pages route smoke coverage for no-bridge assertions, route availability, and public-demo behavior. * Run lightweight e2e only if source/test evidence is insufficient for a status row. ### Runtime Verification * Verify `src/extensions/registry.ts`, `src/lib/__tests__/extension-registry.test.ts`, and `src/lib/setup-config.ts` agree on enablement semantics. * Run targeted `rg` scans over `src/extensions/ai-rogue`, AI Rogue docs, Pages route tests, and available build outputs for D3 boundary indicators. ### Edge Cases * `VITE_CLAUDE_OS_ENABLED_EXTENSIONS` unset, blank, `trend-finder`, `ai-rogue`, `all`, and `none`. * Historical No-Go text that must remain preserved but not treated as current. * Active-at-cap deterministic playthrough evidence that stays a non-blocking caveat unless new soft-lock evidence appears. * Product-local test IDs containing "bridge" that are not actual `/__*` local bridge requests. *** ## 10. Dependencies ### Other Sessions * Depends on: `phase34-session08-default-enablement-evidence-closeout` * Depended by: `phase35-session02-fixed-blocker-regression-coverage`, `phase35-session03-runtime-accessibility-controls`, `phase35-session05-persistence-schema-contracts`, `phase35-session09-documentation-and-media-policy-sync`, and `phase35-session10-final-release-gate` *** ## 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/phase35-session01-rebaseline-audit-evidence/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.