Architecture¶
This section is for maintainers and contributors.
It explains how envctl is structured internally and which boundaries matter if you want the codebase to keep matching the product model.
When to use this section¶
Use these pages when your question sounds like:
- what belongs in each implementation layer
- which boundaries are architectural, not accidental
- where compatibility rules still shape the codebase
If you are learning the product itself, go back to Concepts or Guides.
-
Layers
Understand the main layers of the codebase and what belongs in each one.
-
Boundaries
See why explicit boundaries protect clarity and long-term maintainability.
-
Internal architecture
A maintainer-facing view of how the current repository is organized.
-
Compatibility
Legacy behaviors and migration notes that still shape the codebase and docs.
Why this matters¶
envctl only stays clean if it keeps strong lines between:
- CLI orchestration
- service-level workflows
- domain rules
- repository logic
- adapters and platform concerns
Related pages¶
Internal architecture¶
Move to the maintainer-facing repository view when you need current ownership details.