> 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/phase30-session01-direction-and-asset-readiness/spec.md).

# Session Specification

**Session ID**: `phase30-session01-direction-and-asset-readiness` **Phase**: 30 - AI Rogue Game Extension **Status**: Not Started **Created**: 2026-06-22

***

## 1. Session Overview

This session locks the implementation inputs for AI Rogue before route, renderer, economy, persistence, and simulation work begins. It converts the existing phase plan, session stub, package state, and committed art assets into a concise baseline that later sessions can follow without re-deciding product naming, currency behavior, renderer posture, privacy boundaries, or asset constraints.

The next executable session is `phase30-session01-direction-and-asset-readiness` because phase 30 has no active session, phase 29 is complete, and every later AI Rogue session depends on these baseline decisions. The work is documentation and verification only; runtime, renderer, economy, and simulation code remain out of scope.

***

## 2. Objectives

1. Ratify `AI Rogue`, `ai-rogue`, `Insight Shards`, manual claims, and locked economy source weights as the implementation baseline.
2. Verify and record that `pixi.js@8.19.0` is installed, `@pixi/react` is not installed, and PixiJS remains a lazy runtime import for later sessions.
3. Verify and record the committed first-batch art assets, atlas paths, file sizes, tile scale, palette semantics, frame budget, and acceptance checklist.
4. Preserve extension boundary, privacy, media policy, and non-goal decisions in a durable handoff for Sessions 02 through 10.

***

## 3. Prerequisites

### Required Sessions

* [x] `phase29-session18-documentation-validation-and-release` - Completed Phase 29 closeout and moved the project into Phase 30.
* [x] `phase29-session17-podcast-themes-enrichment` - Explicitly deferred in Phase 29 state history so Phase 30 can start without podcast/audio scope.

### Required Tools Or Knowledge

* `jq` for dependency and atlas JSON inspection.
* `rg` for source and documentation verification.
* AI Rogue phase plan: `docs/extensions/ai-rogue/plan-2026-06-21.md`.
* AI Rogue asset plan: `docs/extensions/ai-rogue/visual-assets.md`.
* Phase 30 PRD and session stubs under `.spec_system/PRD/phase_30/`.

### Environment Requirements

* Run from the repository root.
* Use existing Bun/Vite/React/TanStack conventions.
* Do not start a dev server; this session does not implement or preview UI.

***

## 4. Scope

### In Scope (MVP)

* AI Rogue implementers need stable product naming, extension ID, primary route, support surfaces, and capability posture - record them in a baseline document.
* AI Rogue implementers need stable economy inputs - record manual claims, daily caps, idempotence expectations, source weights, and privacy-safe provenance language.
* AI Rogue implementers need stable renderer and asset inputs - record PixiJS dependency status, lazy import rule, committed atlas paths, tile scale, palette semantics, frame budget, source provenance, and acceptance checks.
* AI Rogue implementers need explicit non-goals - record deferred audio, worker simulation, gamepad, pointer lock, collectors, generated content packs, remote loading, large assets, and raw private telemetry exposure.

### Out Of Scope (Deferred)

* Runtime, renderer, route, economy, persistence, simulation, and game UI code - Reason: these belong to Sessions 02 through 07.
* New art generation or atlas repacking - Reason: the first batch is already generated, packed, and committed.
* Audio, worker simulation, gamepad, pointer lock, collectors, and generated content packs - Reason: the phase plan explicitly defers them.
* Any new backend, database, hosted storage, auth service, realtime service, remote package loading, or dynamic plugin system - Reason: Phase 30 keeps the existing local-first static extension architecture.

***

## 5. Technical Approach

### Architecture

Create a documentation-first implementation baseline under `docs/extensions/ai-rogue/implementation-baseline.md`. The document should summarize decisions already supported by the phase PRD, AI Rogue plan, visual-assets record, package files, and committed assets. It should not invent gameplay behavior, add source collection, or change app code.

Use deterministic checks to support the baseline: inspect `package.json` and `bun.lock` for PixiJS state, inspect `src/assets/ai-rogue/*.json` and file sizes for the committed atlas inventory, run the media policy script, and record the evidence in implementation notes and validation artifacts.

### Design Patterns

* Static extension registry: AI Rogue remains a compile-time extension with no marketplace, eval, dynamic package loading, or remote game code.
* Disabled-first extension: enablement is deferred until final quality gates.
* Local-first privacy: browser-visible game data uses counts, labels, categories, capped signals, and provenance summaries instead of raw private telemetry.
* Compact atlas handoff: runtime art starts from the two committed TexturePacker style atlases instead of loose or unreviewed media.

***

## 6. Deliverables

### Files To Create

| File                                                                                         | Purpose                                                                                                         | Est. Lines |
| -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ---------- |
| `docs/extensions/ai-rogue/implementation-baseline.md`                                        | Durable Session 01 baseline for naming, scope, economy, renderer, asset, privacy, media, and handoff decisions. | \~170      |
| `.spec_system/specs/phase30-session01-direction-and-asset-readiness/implementation-notes.md` | Task-by-task implementation and verification log.                                                               | \~120      |
| `.spec_system/specs/phase30-session01-direction-and-asset-readiness/security-compliance.md`  | Session privacy, security, media, and no-new-surface review.                                                    | \~90       |
| `.spec_system/specs/phase30-session01-direction-and-asset-readiness/validation.md`           | Final validation report with command evidence and readiness result.                                             | \~120      |

### Files To Modify

| File                                          | Changes                                                                                                       | Est. Lines |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ---------- |
| `docs/extensions/ai-rogue/README.md`          | Add the implementation baseline to the document map and maintenance guidance.                                 | \~8        |
| `docs/extensions/ai-rogue/plan-2026-06-21.md` | Add or refresh a Session 01 ratification pointer so later sessions use the baseline.                          | \~20       |
| `docs/extensions/ai-rogue/visual-assets.md`   | Add or refresh a Session 01 ratification note for asset paths, sizes, frame inventory, and acceptance status. | \~25       |

***

## 7. Success Criteria

### Functional Requirements

* [ ] The baseline document names `AI Rogue`, `ai-rogue`, `Insight Shards`, `/extensions/ai-rogue/play`, and the Play, Ledger, Loadout, and Settings surfaces.
* [ ] The baseline records source weights of 40% completed work, 25% skill diversity, 20% tool-class diversity, 10% capped token or spend signal, and 5% readiness or streak bonuses.
* [ ] The baseline records `pixi.js@8.19.0` as installed, `@pixi/react` as not installed, and PixiJS imports as lazy runtime-only work.
* [ ] The baseline records committed atlas paths, file sizes, tile scale, frame budget, palette semantics, provenance stance, and acceptance gates.
* [ ] Deferred systems and privacy non-goals are explicit and match the phase PRD and AI Rogue plan.

### Testing Requirements

* [ ] `bash scripts/check-asset-sizes.sh` run and recorded.
* [ ] `jq` parsing and frame inventory checks run against both AI Rogue atlas JSON files.
* [ ] Dependency checks against `package.json` and `bun.lock` recorded.
* [ ] Documentation ASCII/LF and whitespace checks completed.

### Non-Functional Requirements

* [ ] No runtime code, route code, generated data, private telemetry, or new assets added by this session.
* [ ] No new dependency, credential flow, hosted storage, database, or remote loading surface introduced.
* [ ] Documentation stays concise, factual, and aligned to existing project conventions.

### Quality Gates

* [ ] All files ASCII-encoded
* [ ] Unix LF line endings
* [ ] Code follows project conventions

***

## 8. Implementation Notes

### Working Assumptions

* Session 01 is documentation and verification only: the session stub says runtime, renderer, economy, and simulation code are out of scope, and the phase plan labels this as Direction Lock. Planning can proceed because the deliverables are documentation artifacts and verification records.
* Phase 29 is complete enough for Phase 30 planning: the analyzer reports `current_phase` 30, Phase 29 status complete, and `phase29-session18-documentation-validation-and-release` in completed sessions. The deferred Phase 29 Session 17 is already recorded as deferred, not an unmet prerequisite.
* Existing art should be ratified, not regenerated: `visual-assets.md` says the first batch is generated, packed, and committed, and the files exist under `src/assets/ai-rogue/`. Planning can proceed by verifying those assets and recording the result.

### Key Considerations

* The session should reduce ambiguity for later implementers without broadening scope.
* The baseline should point to source documents instead of duplicating every long planning detail.
* Any discovered asset, package, or documentation drift should be recorded and resolved within this documentation session when it is small and factual.

### Potential Challenges

* Existing docs already contain many locked decisions: avoid creating a second conflicting source of truth by making the baseline a concise handoff with links to the plan and visual-assets record.
* Asset inventory may drift after later sessions: record the Session 01 check date and the exact committed paths so future sessions can update provenance intentionally.
* Repo-wide formatting drift is known from carryforward: validate scoped files and record any unrelated repo-wide drift rather than expanding this session.

### Relevant Considerations

* \[P00] **Stack conventions**: Bun, Vite 8, TanStack Start, React 19, and Cloudflare Worker compatibility remain baseline constraints.
* \[P02] **Static extension registry requires code changes**: No marketplace, dynamic loading, eval, or remote code belongs in the first AI Rogue slice.
* \[P02] **Disabled-first collector pattern**: The extension remains gated and disabled-first until final quality gates.
* \[P02] **Extension payloads and labels stay bounded**: Future AI Rogue data must preserve explicit state labels and bounded browser-visible payloads.
* \[P27] **Repo-wide formatting drift remains**: Keep validation scoped and record unrelated drift if broad checks fail for old files.
* \[P29] **Closeout cannot change feature posture**: This baseline may consolidate decisions, but new source, schema, runtime, storage, hosted, credential, or admin-write surface requires a later implementation session.

***

## 9. Testing Strategy

### Unit Tests

* No unit tests are required because this session adds no application or script logic.

### Integration Tests

* No browser or integration tests are required because this session adds no routes, runtime code, or UI behavior.

### Runtime Verification

* Verify `package.json` and `bun.lock` agree that `pixi.js@8.19.0` is present.
* Verify `@pixi/react` is absent from `package.json`.
* Verify both AI Rogue atlas JSON files parse and expose the expected frame groups for player, enemies, pickups, tiles, fog, and UI icons.
* Run `bash scripts/check-asset-sizes.sh` and record the result.

### Edge Cases

* Missing or malformed atlas JSON should be recorded as a blocker for later runtime work and fixed in documentation only if the correction is factual.
* Unexpected dependency drift should be recorded in validation and reflected in the baseline.
* Any accidentally added non-ASCII characters should be removed before completion.

***

## 10. Dependencies

### Other Sessions

* Depends on: `phase29-session18-documentation-validation-and-release`.
* Enables: `phase30-session02-extension-shell-and-routes`, `phase30-session03-pixijs-runtime-boundary`, `phase30-session04-economy-and-ledger`, `phase30-session06-dungeon-simulation-core`, `phase30-session07-play-runtime-integration`.

***

## 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/phase30-session01-direction-and-asset-readiness/spec.md?ask=<question>&goal=<endgoal>
```

`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.