Update documentation for AGENTS.md, CHAT_CONTEXT.md, architecture.md, roadmap.md, testing.md

AGENTS.md

@@ -94,6 +94,7 @@ This is not:
   - night/dawn/dusk appearance
   - scene-level lighting opt-in/out
 - Do not build a large generic schedule editor before the runtime hooks it would drive are real.
+- The shared control surface and scheduler/notebook foundations now exist; extend them instead of adding new parallel time-orchestration paths.
 - Long-term world logic should resolve deterministically from:
   - global time
   - persistent/cycle flags
@@ -108,6 +109,12 @@ This is not:
 - NPC presence, routines, dialogue variants, interaction availability, and path progress should eventually be reconstructible from authored rules plus global state.
 - If loop/reset mechanics are added later, they should reset/re-resolve cycle-scoped state rather than trying to rewind arbitrary runtime simulation.
 
+### Dialogue direction
+
+- Dialogue content should remain authored data, not ad hoc runtime-only strings.
+- New dialogue work should prefer reusable authored resources and references over NPC-only bespoke fields.
+- NPCs, interactions, triggers, scheduler/sequencer layers, and later event-driven systems should be able to consume the same dialogue foundations where appropriate.
+
 ### Imported model collision
 
 - Collision authoring for imported models belongs on `modelInstances`, not assets.

CHAT_CONTEXT.md

@@ -31,6 +31,10 @@ Broadly implemented already:
 - transform foundations
 - project-wide time foundation with a running global clock
 - first day/night lighting override tied to project time
+- typed control-surface foundation for steerable runtime capabilities
+- scheduler/notebook foundation with authored routines over global time
+- scheduler-driven NPC presence, path-following, and animation triggering
+- first dialogue foundations with runtime dialogue overlay and dialogue-start interaction links
 
 Important consequence:
 
@@ -77,9 +81,10 @@ Treat current box-brush structures as the starting point for whitebox solids unl
 - local authored lights stay in typed entities
 - project save/load and runner export are separate concerns
 - project time is global, not per scene
-- current day/night logic exists, but it is still a small dedicated driver rather than a generic schedule system
+- project-global day/night, control-surface, and scheduler/notebook foundations already exist and should be extended rather than reinvented
 - scheduler/notebook work should sit on top of a shared control surface, not a growing pile of one-off scheduler-only effect types
 - when a new capability is added that is meaningfully steerable over time, prefer making it control-surface-addressable and scheduler-available instead of adding isolated time fields
+- dialogue foundations already exist, but branching choices, outcomes, robust trigger/NPC sources, and scheduler-driven availability/variants are still incomplete
 
 Imported model collision:
 
@@ -138,9 +143,11 @@ The next large topics are more likely to be things like:
 
 - whitebox-solid editing model
 - multi-scene / project structure
-- richer runtime systems
+- richer runtime systems and dialogue behavior
 - authored day/night refinement on top of project-global time
-- later deterministic schedule/routine/event systems driven by global time + flags + scene context
+- scheduler conditions / overrides / scene-global rows and later deterministic schedule/routine/event systems driven by global time + flags + scene context
+- event/reaction sources that reuse the same control surface as scheduler and interactions
+- dialogue variants / outcomes on top of the existing dialogue foundation
 - scheduler/control-surface convergence so newly steerable runtime features are naturally available in the notebook
 - remaining packaging / portability work
 - future primitives and topology tools after the whitebox direction is coherent

architecture.md

@@ -379,6 +379,8 @@ interface ProjectDocument {
   version: number;
   name: string;
   time: ProjectTimeSettings;
+  scheduler: ProjectScheduler;
+  sequences: ProjectSequenceLibrary;
   activeSceneId: string;
   scenes: Record<string, ProjectScene>;
   materials: Record<string, MaterialDef>;
@@ -390,8 +392,10 @@ interface ProjectScene {
   id: string;
   name: string;
   loadingScreen: SceneLoadingScreenSettings;
+  editorPreferences: SceneEditorPreferences;
   world: WorldSettings;
   brushes: Record<string, Brush>;
+  paths: Record<string, ScenePath>;
   modelInstances: Record<string, ModelInstance>;
   entities: Record<string, EntityInstance>;
   interactionLinks: Record<string, InteractionLink>;
@@ -419,7 +423,9 @@ Time architecture direction:
   - authored day/night settings
   - scene world settings
 - do not hide time semantics only inside renderer-side constants; keep reusable pure resolution logic where practical
-- generic schedules, NPC routines, dialogue variants, and interaction availability should eventually resolve from:
+- shared control-surface and scheduler/notebook foundations exist and should remain the default path for new time-steerable behavior
+- current routine/control work already covers authored actor presence, actor animation, actor path-following, light/audio/interaction control, and scene lighting overrides
+- richer schedule conditions, dialogue variants, interaction availability, and later event-driven reactions should continue to resolve from:
   - global time
   - world/quest flags
   - scene/location context
@@ -1006,6 +1012,9 @@ Recommended separation:
 - trigger occupancy
 - animation playback state
 - project clock state
+- active dialogue overlay state
+- resolved scheduler/control state
+- transient sequence/scheduler impulse state
 
 Keep ephemeral rendering and interaction state out of the serialized document.
 

roadmap.md

@@ -628,18 +628,20 @@ The time/living-world direction should stay closer to Majora's Mask than to a fu
 - one global project clock
 - deterministic resolution from time + flags + scene context
 - unloaded scenes reconstructed on demand instead of fully simulated all the time
-- authored day/night comes before a large generic scheduling UI
+- authored day/night came before the current scheduler/notebook foundation; next work should build on that shared time/control path rather than add one-off per-system timers
 
 ### Candidate slices
 
-- authored day/night refinement on top of project-global time
-- small reusable time-query/day-phase foundation
-- typed NPC/runtime actor foundation
-- spline/path authoring for camera/object/NPC motion
+- dialogue robustness, variants, and outcomes on top of the current dialogue foundation
+- scheduler conditions / overrides / scene-global rows on top of the current scheduler/notebook
+- event/reaction sources that reuse the same control surface as scheduler and interaction links
 - deterministic schedules/routines driven by time windows and flags
+- cross-scene resolution for actors and dialogue state from time + flags + scene context
 - cycle/reset mechanics if loop gameplay becomes a core pillar
+- curve/track authoring for interpolatable control-surface channels
 - advanced UV tools
 - nav waypoints authoring
+- later route-finding / A* only after authored-path and scene-connection semantics are clear
 - ambient zones and audio buses
 - lightweight scripting
 - plugin/tool API

testing.md

@@ -48,7 +48,9 @@ Highest-priority confidence areas:
 10. spatial audio and interaction basics
 11. critical regressions caught in CI
 12. project-time/day-phase determinism where time-driven runtime systems exist
-13. later schedule/routine resolution from time + flags + scene context
+13. control-surface effect resolution and execution across actor/entity/interaction/scene targets
+14. scheduler/routine resolution from time + authored rules, and later from time + flags + scene context
+15. dialogue library, dialogue start sources, and runtime dialogue overlay correctness
 
 ---
 
@@ -478,6 +480,9 @@ The following invariants are important enough to deserve repeated coverage:
 - interactions target the correct entities or model instances
 - project-global time survives scene transitions where intended
 - time-driven scene state resolves deterministically from canonical/authored inputs
+- control effects resolve to the intended runtime targets and do not silently noop
+- scheduler/routine resolution is deterministic for the same authored inputs and project time
+- dialogue start from supported sources resolves through one coherent runtime dialogue path
 
 ---