History

25 September 2026 - Reference & Outline Update

Wrote four reference pages documenting the systems built earlier today: reference/rokojori-base (Unique, EventSlot, Locale, RJLog, extensions), reference/game-state, reference/dialog, and reference/simulation. Linked all four from reference/index.page under a new "By System" section.

Each page leads with the non-obvious part rather than restating the code: for Game State, the asset/runtime-value split and why key exists separately from the inherited name; for Dialog, the per-block-type behaviour table and the DialogList flow assumption; for Simulation, that playerCount and the renderer are placeholders with nothing wired up yet.

Ran the Update Outline action: outline/index.page's "Current State" and "What's next" sections had been stale since project creation ("It just started, only the first initial files exist") - replaced with the actual state (three singletons implemented, not yet Editor-verified, no real UI) and a concrete next-steps list. No code changed in this entry - documentation only.

25 September 2026 - Implementation Session

Took over the "Session Hand-Over: Tech Outline Normalization" task, confirmed the Dialog Manager section of outline/tech/index.page read correctly, then implemented all three Tech Areas from that outline: Game State Management, Dialog Management, and Simulation Management. Code lives under Assets/Scripts/Rokojori/GameState/, Dialog/, and Simulation/ (about 28 files). Removed the stale "Get Initial Picture" board task (its description no longer matched what had actually happened) and closed out the hand-over task.

Compile Toolchain

Set up a way to verify C# compiles without opening the Unity Editor - see guides/compiling-without-unity/index.page. Two things were needed: a global.json pinning the SDK to 8.0.417 (the default .NET 10.0.401 SDK crashes compiling Unity's generated csproj on this machine - a Windows/CET incompatibility, not a project issue), and a hand-written CompileCheck.csproj that globs Assets/Scripts/Rokojori and Assets/Scripts/Project directly, since Unity's own generated Assembly-CSharp.csproj only lists files present at its last sync and won't pick up files written outside the Editor. All new code compiles clean against this (2 pre-existing, harmless serialization-analyzer warnings on EventSlot fields, unrelated to this session's code). This has only been compile-checked, never run in Unity - see the new "Verify in Unity Editor" board task.

Coding Convention Correction

Wrote the first pass without noticing guides/Writing-C#/index.page - it exists but wasn't linked from guides/index.page (now fixed, and linked here alongside the new compiling guide). Had to go back and fix: no bare private fields (use public with an underscore prefix, or protected), no parameterized constructors (DialogProcessor changed to a static Create() factory), switch statements replaced with if/else-if chains (CompareInt, ListCondition), and explicit initial values added to all fields that lacked them.

Decisions

Kept GameStateManager's per-type value dictionaries as the runtime source of truth (marked [NonSerialized]), with GameStateVariable ScriptableObjects only holding the initial value and a stable key field for JSON save/load - editor-facing "name" (inherited from UnityEngine.Object) stays separate from save identity.

DialogManager.Show() throws NotImplementedException rather than faking a response - there is no UI to wire it to yet (Assets/UI is empty). SimulationRenderer.Enqueue() is a similar placeholder that completes instantly. Both are flagged as open To Do items rather than silently pretending to work.

Assumptions Needing Sign-off

The tech outline left several implementation details unspecified. Filled them in with the simplest defensible choice and flagged all five in outline/tech/index.page under "Implementation Status" rather than guessing silently: DialogList's flow semantics (flat sequence, ignores children's own "next"), PlayerChoice options gaining an optional GameStateAction, HasObject modelled as a bool flag (no inventory system exists), SimulationManager.playerCount as a plain int (no Player type is defined anywhere), and GameStateVariable.key replacing the outline's literal (but already-inherited) "name" field. See the new "Sign Off Implementation Assumptions" board task.

Not Done

SimulateWorld and ShowTurnStartConditions (the example GamePhase subclasses) were described only narratively in the outline with no code contract, so they weren't written - see the "Example Simulation Phases" board task. DialogPhase was written since GamePhase now exists, closing a gap from last session.

25 September 2026

Project created.

25 September 2026 - Tech Outline Session

Rewrote outline/tech/index.page. It previously held roughly 92KB of copy-pasted ChatGPT export markup (wrapper divs around a 15-section simulation brainstorm) plus an unedited Roject placeholder block. Replaced with a normalized design across three tech areas: Game State Manager, Simulation Manager, Dialog Manager.

Decisions

GameStateManager is the single shared state layer - Simulation Manager and Dialog Manager both read/write through it instead of keeping separate state.

Simulation Manager is built around GamePhase ScriptableObjects run asynchronously across five ordered lists (intro, preTurn, playerTurn, postTurn, outro). Any phase can flag the game finished, which jumps straight to outro. Phases only talk to Unity through SimulationRenderer (command in, "done" callback out). The earlier standalone systems architecture (ProductionSystem, PollutionSystem, spatial fields, deltas) was folded into one example phase, SimulateWorld, instead of being its own top-level section - it was more detail than a portfolio-sized prototype needs.

Dialog Manager went through two passes. The first coupled dialog execution directly into DialogPhase. The user corrected this: dialog needed to work standalone, not just inside the simulation loop. Settled on three layers - DialogProcessor (standalone cursor engine, depends only on an IDialogDisplay interface, no knowledge of UI or the simulation loop), DialogManager (singleton, owns UI wiring, sole entry point via StartDialog(), implements IDialogDisplay), and DialogPhase (thin GamePhase wrapper calling DialogManager.instance.StartDialog()). The IDialogDisplay seam also covers a future debug/headless display for testing, mentioned but not built.

Not Done

No code was written - this was entirely the design pass in the tech outline. The To Do board items (Game State Management, Dialog Management) still need actual implementation. Final sign-off on the Dialog Manager section of the tech outline was still pending when the session was handed over.