giers10/webeditor3d
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update AGENTS.md and CHAT_CONTEXT.md with new scheduling guidelines

Browse Source
This commit is contained in:
Victor Giers
2026-04-14 01:21:41 +02:00
parent d6be1c5562
commit 387df91a47
2 changed files with 9 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
AGENTS.md
View File

@@ -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.

3
CHAT_CONTEXT.md
View File

@@ -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