TheLastGarden/.planning/phases/01-foundations-and-doctrine/01-DISCUSSION-LOG.md

Phase 1: Foundations & Doctrine - Discussion Log

Audit trail only. Do not use as input to planning, research, or execution agents. Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.

Date: 2026-05-08 Phase: 1-foundations-and-doctrine Areas discussed: AI asset pipeline depth, Save schema v1 scope, Doctrine docs concreteness, Project scaffold layout

---

AI Asset Pipeline Depth

Sub-question A: north-star reference set state at end of Phase 1

Option	Description	Selected
Hand-painted by a real artist	Commission a watercolor artist (or paint them yourself) to produce 10–20 hand-painted reference images now. AI pipeline (vendor TBD in Phase 5) later trains/conditions against them. Highest fidelity, real budget commitment.
Hand-curated AI generations	Generate dozens of candidates in a chosen tool, hand-pick 10–20 that nail the watercolor target, commit them with full provenance.	✓
Placeholder refs + sealed slot	Phase 1 ships schema + gate + a marked 'north-star slot' with placeholders; real north-stars commissioned in early Phase 5.
Public-domain watercolor refs	Curate 10–20 from public-domain or Creative Commons watercolor art. Zero budget; provenance is licensing, not generation.

User's choice: Hand-curated AI generations.

Sub-question B: which generation tool for the Phase 1 north-stars

Option	Description	Selected
Local Stable Diffusion + watercolor LoRA	Local SD via ComfyUI/Automatic1111 with a watercolor-specialized LoRA. Full provenance natively (model checksum, exact sampler, seed, full params).
Scenario (game-art-focused)	Purpose-built generative platform with custom-trained generators. Subscription-based ($29–$199/mo). Designed for reproducibility, style consistency.
Midjourney with licensed plan	Best-in-class watercolor output, lowest skill floor. Provenance is messier (no checkpoint hash exposed).
Defer tool choice, lock the discipline	Phase 1 commits to schema + gate; the model_id/checkpoint_hash fields are filled honestly per generation. Tool consolidation in Phase 5.	✓

User's choice: Defer tool choice, lock the discipline.

Sub-question C: how the curation gate refuses unreviewed assets

Option	Description	Selected
Sidecar JSON + CI validator	Each asset requires a sibling name.provenance.json carrying all 6 provenance fields plus reviewed:true and reviewedBy. CI walks the tree, fails build on any missing/invalid sidecar.	(locked at minimum-viable level after pushback)
Curated-pending two-stage	Generated assets land in /assets-pending/; curator script promotes to /assets/ while writing a CURATION-LOG.md entry.
Manifest-as-source-of-truth	Single /assets/manifest.json lists every shipped asset with full provenance + reviewer.
Pre-commit hook + manifest	Combines manifest with a Git pre-commit hook that refuses to add files under /assets/ without manifest entries.

User's choice: (rejected the framing) "We are vastly overcomplicating this. When I said I wanted AI generated assets I figured that would be just something Claude could spit out. It isn't overly important and I don't really care all this much."

Notes: Locked the minimum viable shape from option 1 (sidecar + CI validator) without the reviewed ceremony — just the 6 provenance fields + a sample refused asset proving the gate works. No curator workflow, no two-stage, no pre-commit hook, no CURATION-LOG.md. Saved a feedback memory ("avoid overengineering foundations") to recalibrate the rest of the discussion.

---

Save Schema v1 Scope

Option	Description	Selected
Minimal: just what Phase 2 needs	v1 carries only Season 1 fields. Real v1→v2 migration in Phase 4. Honest minimum, exercises the migration framework on real player data.	✓
Structural: full 7-Season shape with empty defaults	v1 already has slots for Roothold, currentSeason, storyFlags, knownFragments, all defaulting to zero/null. Less migration churn, but designing for code that doesn't exist yet.
Hybrid: Phase 2 fields + a _extensions bucket	Typed _extensions: Record<string, unknown> for forward writes. Pragmatic but invites schema drift.

User's choice: Minimal: just what Phase 2 needs.

Notes: Round-trip migration test in Phase 1 will use a synthetic v0 → v1 demo migration to prove the chain works end-to-end. First real migration ships in Phase 4.

---

Doctrine Docs Concreteness

Option	Description	Selected
Principle-level: the rest-state contract	Doc answers what 'rest state' means, what the finite Roothold ceiling is tied to, what tonal register the coda lives in. No final scene text.	✓
Treatment-level: with the binary-choice scene	Principle-level + actual final scene treatment: binary-choice prompt text, both ending paragraphs, Lura's final line, credits/coda screen. Eliminates 7 phases of drift risk at the cost of authoring the climax in Phase 1.
Principle + 'do not violate' list	Principle-level plus an explicit list of patterns Phase 2–7 must NOT introduce. Cheaper than full treatment but still gives later phases a hard wall.

User's choice: Principle-level: the rest-state contract.

Notes: Anti-FOMO doctrine was not put to choice — it's a consolidation of constraints already scattered across PROJECT.md / REQUIREMENTS.md / CLAUDE.md / SUMMARY.md banner concerns; Claude can write that without further input. Both doctrine docs land in .planning/. No CI/lint enforcement — doctrine is referenced at design reviews, not enforced by code.

---

Project Scaffold Layout

Option	Description	Selected
BigQty wrapper around break_eternity.js	Build the typed wrapper in Phase 1 so Phase 2 starts using it immediately.
Empty Zustand store skeleton	A src/store/ with the bridge pattern stubbed (selectors, no state).
Tick scheduler / monotonic clock	The pure simulation tick loop with monotonic-only time injection. Phase 2's CORE-11 anchors on this.
None — stop at success criteria	Phase 1 ships exactly what the 5 success criteria demand and nothing more. Phase 2 builds BigQty, the store, the tick loop as its first tasks.	✓

User's choice: None — stop at success criteria.

Notes: Cleanest scope — Phase 1 stays honest as "land retrofit-hostile decisions only." Phase 2 owns BigQty, Zustand store contents, tick scheduler. The boundary directories (src/sim/, src/render/, src/ui/) still need to exist in Phase 1 so the ESLint boundary rule has clean targets to enforce.

---

Claude's Discretion

• ESLint boundary plugin choice (eslint-plugin-boundaries vs eslint-plugin-import's no-restricted-paths).
• Save checksum algorithm (CRC32, simple hash, SHA-1) — any deterministic, fast hash.
• Migration registry shape (chain of named functions, registry object).
• idb wrapper API surface inside src/save/.
• Vitest + Playwright config.
• Where Zod content schemas live and how the build step is invoked (Vite plugin vs separate npm script).
• Specific images / prompts / seeds for the 10–20 north-star generations (user accepts/rejects).

---

Deferred Ideas

• AI vendor lock-in / model pinning → early Phase 5.
• BigQty wrapper around break_eternity.js → Phase 2 first task.
• Empty Zustand store skeleton → Phase 2.
• Tick scheduler / monotonic clock → Phase 2 (CORE-11).
• Season 7 treatment-level details (binary-choice scene text, Lura's final line, coda screen) → Phase 7.
• Anti-FOMO lint rule on UX strings → explicitly rejected.
• Curator workflow / two-stage asset promotion / pre-commit hook on assets → explicitly rejected.
• Visual regression testing across asset library → PIPE-04, Phase 8.