> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_23/session_04_store_persistence_boundaries.md).

# Session 04: Store Persistence Boundaries

**Session ID**: `phase23-session04-store-persistence-boundaries` **Package**: apps/web **Status**: Not Started **Estimated Tasks**: \~14 **Estimated Duration**: 2-4 hours

***

## Objective

Verify camp state uses the existing browser-local projection persistence path without adding storage authority, hosted state, or new trusted-erasure claims.

***

## Scope

### In Scope (MVP)

* Extend `apps/web/tests/gameProjectionStore.test.ts` around camp reconciliation through normal store event application.
* Preserve the `localStorage["factionos-game-v1"]` projection key.
* Preserve replay and mock-mode persistence guards.
* Preserve reset and browser-local erasure behavior.
* Add minimal store wiring only if needed to keep existing persistence semantics for camp fields.

### Out of Scope

* Public-demo synthetic fronts.
* Hosted state.
* Cross-device erasure.
* Unified trusted erasure claims.
* Protocol changes.

***

## Detailed Requirements

* Continue to rely on existing local projection persistence and browser-local erasure.
* This phase must not add a new storage key.
* Real scanner camp aggregates may persist through `localStorage["factionos-game-v1"]`.
* Persisted projection is not written while replaying.
* Persisted projection is not written while mock mode is enabled.
* Reset and local erasure still clear the same projection key.
* Normal server hydration snapshots after boot may reconcile through the non-replay path.
* Mock or synthetic data may show a drill version of camps for demo spectacle only when the existing mock setting is active.
* Drill camps must be bannered or otherwise distinguishable as non-progress state when rendered by later sessions.
* Drill camps must not persist into the projection key.
* Drill camps must not satisfy exit criteria for real scanner snapshots.
* This phase does not implement a public-demo synthetic front.
* This phase only preserves the progress-inert boundary needed by that future surface.
* The implementation must not change trusted-erasure claims.
* Do not claim hosted, cross-device, or unified trusted erasure for camp state.

***

## Required Tests

* `apps/web/tests/gameProjectionStore.test.ts`
  * store applies camp reconciliation through the normal event path
  * persisted projection is not written while replaying
  * persisted projection is not written while mock mode is enabled
  * reset and local erasure still clear the same projection key
  * no new storage key is introduced
  * server hydration snapshots after boot can reconcile through the non-replay path

***

## Prerequisites

* [ ] Session 03 reducer folding is implemented.

***

## Deliverables

1. Store-level regression tests for camp persistence, replay, mock mode, reset, and local erasure.
2. Any minimal store integration needed for camp fields to follow existing projection persistence behavior.

***

## Dependencies / Notes

* Depends on Session 03 reducer folding.
* Public-demo synthetic fronts, hosted state, cross-device erasure, unified trusted erasure, and protocol changes are out of scope.

***

## Success Criteria

* [ ] Real scanner snapshots persist camp aggregates through the existing projection key.
* [ ] Replay and mock-mode paths do not persist synthetic or replayed camp state.
* [ ] Local erasure behavior and trusted-erasure claims remain unchanged.
* [ ] No new storage key, hosted dependency, or hosted-state claim exists.


---

# 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://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_23/session_04_store_persistence_boundaries.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.