From 387df91a471e7fe8497876bdfde2460da598dcec Mon Sep 17 00:00:00 2001 From: Victor Giers Date: Tue, 14 Apr 2026 01:21:41 +0200 Subject: [PATCH] Update AGENTS.md and CHAT_CONTEXT.md with new scheduling guidelines --- AGENTS.md | 6 ++++++ CHAT_CONTEXT.md | 3 +++ 2 files changed, 9 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 01b77cee..0fd5f911 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -99,6 +99,12 @@ This is not: - persistent/cycle flags - scene/location context - Prefer deterministic resolution over fully simulating unloaded scenes. +- The scheduler/notebook should be the default authoring surface for time-based orchestration. +- Do not keep adding one-off per-entity or per-system time fields once a scheduler/control-surface path exists. +- When a new typed runtime/editor capability is added and it is meaningfully time-steerable, extend the control surface and make it schedulable in the same direction of work or document clearly why it is intentionally deferred. +- Treat this as a product rule, not a nice-to-have: + - new schedulable capability -> control-surface support + - control-surface support -> scheduler/notebook availability - 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. diff --git a/CHAT_CONTEXT.md b/CHAT_CONTEXT.md index 01005839..7d750e24 100644 --- a/CHAT_CONTEXT.md +++ b/CHAT_CONTEXT.md @@ -78,6 +78,8 @@ Treat current box-brush structures as the starting point for whitebox solids unl - 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 +- 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 Imported model collision: @@ -139,6 +141,7 @@ The next large topics are more likely to be things like: - richer runtime systems - authored day/night refinement on top of project-global time - later deterministic schedule/routine/event systems driven by global time + flags + scene context +- 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