> Each business domain is divided into a fixed set of layers, with strictly validated dependency directions and a limited set of permissible edges. These constraints are enforced mechanically via custom linters (Codex-generated, of course!) and structural tests.
> The diagram below shows the rule: within each business domain (e.g. App Settings), code can only depend “forward” through a fixed set of layers (Types → Config → Repo → Service → Runtime → UI). Cross-cutting concerns (auth, connectors, telemetry, feature flags) enter through a single explicit interface: Providers.
This sounds so much like CQRS/hexagonal/DDD/other stuff. This is like the stuff that real world software teams actually struggle to execute on. This is the stuff people want solved. I don't think anyone doubts that if you can nail some sort of rigid, well-defined architecture and tooling workflow, agents can fly on filling in implementation. But it's the first part that needs solving.
> The diagram below shows the rule: within each business domain (e.g. App Settings), code can only depend “forward” through a fixed set of layers (Types → Config → Repo → Service → Runtime → UI). Cross-cutting concerns (auth, connectors, telemetry, feature flags) enter through a single explicit interface: Providers.
This sounds so much like CQRS/hexagonal/DDD/other stuff. This is like the stuff that real world software teams actually struggle to execute on. This is the stuff people want solved. I don't think anyone doubts that if you can nail some sort of rigid, well-defined architecture and tooling workflow, agents can fly on filling in implementation. But it's the first part that needs solving.