counterfact-runtime-architecture

To modify server runtime internals safely, isolate changes to module-loader boundaries and orchestration logic in src/app.ts and src/server/**. This preserves hot reload semantics so updates apply without restart and context survives reloads.

Hot reload module loading in a TypeScript server applies code updates without restarting the process. It coordinates runtime orchestration through explicit interfaces and documented conventions to ensure context survives reloads without cross-cutting regressions.

Update runtime architecture by enforcing explicit interfaces and documented conventions across src/api-runner.ts and related utilities. Run lint, build, and runtime tests locally to validate changes and prevent coupling between server components.

Yes, you can change the module loader in src/app.ts without losing server context by following conventions that preserve hot-reload semantics. Context survives reloads when changes are isolated to runtime orchestration boundaries.

The best way to validate runtime server changes is running lint, build, and runtime tests locally after modifying src/app.ts, src/api-runner.ts, or src/server/**/*.ts. This minimizes risk when evolving internal server components.

Hot reload updates fail after changing server orchestration code when changes introduce module coupling or violate boundary conventions. Isolate changes to runtime orchestration and module-loader boundaries to prevent cross-cutting regressions that break reload behavior.