design-project-architecturelisted

# Design Project Architecture 1. Establish the system scope, users, business capabilities, constraints, deployment environment, team ownership, expected change, and measurable quality-attribute scenarios. Read [architecture principles](references/architecture-principles.md). 2. For an existing project, map entry points, modules, runtime and data flows, public contracts, ownership, dependency direction, cycles, build units, deployment units, tests, and operational boundaries before proposing a target. For a new project, identify the minimum capabilities and irreversible decisions first. 3. Partition by cohesive responsibility and information hidden from other modules. Give mutable state, business rules, external integrations, and operational concerns explicit owners. Define narrow contracts and permitted dependency directions; prevent cycles, cross-module internals access, shared mutable state, and unowned `common`, `shared`, or `utils` dumping grounds. 4. Choose the simplest topology that satisfies the drivers. Prefer in-process modules until independent deployment, scaling, isolation, availability, data ownership, regulatory, or team-autonomy requirements justify a distributed boundary. Introduce layers, ports, events, repositories, services, or patterns only for a named force and verified trade-off. 5. For new systems, follow [new-project design](references/new-projects.md). For legacy or structurally weak systems, follow [existing-project evolution](references/existing-pr