# Site Profile and Instance State Decoupling: Step 1 Solution Assessment

## Problem statement

Selecting the Chouse site profile currently switches local repositories, approval state, and read-model databases even though presentation choices should not determine an instance's canonical data.

## Option A — Share all default state

### Pros

- Makes site profile selection purely presentational.
- Gives every local theme the same identities, approvals, posts, database, and generated artifacts.
- Requires the fewest configuration concepts.

### Cons

- Theme-dependent generated HTML may be stale after changing profiles unless it is rebuilt.
- Developers wanting isolated local instances must provide explicit paths.

## Option B — Share data, separate presentation cache

### Pros

- Gives one canonical repository and one read-model database per instance.
- Keeps identities, approvals, and content stable when presentation changes.
- Prevents generated HTML for one site profile from being reused under another profile.
- Preserves explicit paths for genuinely separate instances.

### Cons

- Retains separate derived static-cache locations.
- Requires clear documentation that static caches are disposable presentation artifacts, not instance data.

## Option C — Require explicit instance paths

### Pros

- Makes instance boundaries fully explicit and difficult to confuse with themes.
- Avoids implicit path selection in production-like environments.

### Cons

- Adds setup friction for ordinary local development.
- Requires more environment configuration and creates more opportunities for incomplete startup commands.

## Recommendation

Choose **Option B**: use one canonical repository and read-model database per instance regardless of site profile, while allowing profile-specific static caches. Treat the existing default repository as authoritative, preserve the small Chouse sandbox as a recoverable backup, and do not merge its duplicate identity/bootstrap records.