Runtime Boundary
This is one of the most important pages in the whole architecture section.
If the runtime boundary is unclear, the framework will keep expanding until it becomes unmaintainable.
What the runtime owns
Ansiq runtime currently owns:
- app lifecycle
- reactive flush scheduling
- dirty scope collection
- subtree rerender and replacement
- focus and input routing
- partial relayout
- invalidated region tracking
- terminal session and viewport management
- framebuffer diff and terminal patch emission
These responsibilities already have implementations today, though not all with the same maturity level.
What the runtime does not own
Ansiq runtime does not own:
- business state modeling
- network protocols
- high-level agent orchestration
- rich markdown or advanced text semantics
- persistence and storage strategy
Those concerns would make the runtime boundary collapse.
Why the boundary matters
The runtime should be strong at:
- coordination
- scheduling
- updating
- patch emission
It should not become the place where domain behavior quietly accumulates.
Boundaries that have already been hardened
Recent work has already pushed several responsibilities back into clearer layers:
- reactive graph and UI tree stay separate
- continuity moved toward a clearer contract instead of scattered runtime hacks
- pure layout and render math moved out of runtime-heavy modules
- part of viewport/history behavior now depends on pure calculation instead of fragile terminal queries
These are architecture decisions, not just refactors.
A useful design question
When evaluating a feature, ask:
Is this deciding what became dirty and how to update the terminal, or is it actually business logic?
If the answer leans toward business logic, it likely does not belong in the runtime.