startup-performance-uses-lazy-loading
IN derived (depth 1)
Both the API and CLI layers defer importing heavy modules (derive, compact, ask, asyncio, Storage) to function bodies rather than module top-level, minimizing import-time overhead for CLI responsiveness.
Summary
The system consistently uses lazy imports across both its API and CLI layers, only loading expensive modules like derive, compact, and asyncio when a specific function actually needs them. This means the CLI stays snappy for simple operations like displaying help text, and callers that only use a subset of the API avoid paying the cost of loading everything upfront.
Justifications
SL — Cross-cutting performance pattern — both user-facing layers share the same lazy-loading strategy independently
Antecedents (all must be IN):
- api-uses-lazy-imports — Heavy modules (`derive`, `compact`, `export_markdown`, `check_stale`, `import_beliefs`, `import_agent`) are imported inside function bodies in `api.py`, not at module level, to keep the module fast to import for callers that only need a subset of operations.
- cli-uses-lazy-imports-for-heavy-modules — `asyncio`, `derive`, `ask`, and `Storage` are imported inside function bodies rather than at module level, keeping `reasons --help` fast.
Dependents
These beliefs depend on this one:
- system-resource-footprint-is-minimal-at-all-phases — The system achieves minimal resource footprint across all lifecycle phases: zero external dependencies at both packaging and implementation levels eliminate installation overhead and version conflicts, while lazy module imports in both API and CLI layers defer heavy computation until actually needed — minimizing deployment complexity, startup time, and memory consumption simultaneously.