architecture-review · git:20260926.3185b84 · 2026-09-26 · sha256 39b6c25844c91689
architecture-review git:20260926.3185b84A
Immutable. This exact content never changes and is served at /api/v1/blob/39b6c25844c91689.
--- name: architecture-review description: Analyze significant structural changes before implementing them. Use when adding a subsystem, redesigning a major flow, changing authentication architecture, introducing workers/queues/background services, integrating an external provider, creating shared infrastructure, changing module communication, or when the user asks how something should be built. --- # Architecture Review ## Principle Prefer the smallest architecture change that solves the real problem. Do not introduce unnecessary abstraction. ## Inspect - Current architecture and module boundaries. - Affected modules and their responsibilities. - Ownership boundaries: who owns a responsibility, and where it must not leak. - Data flow across the change, including persistence and external calls. - Dependency direction; flag cycles and inverted dependencies. - Failure boundaries: what happens when each dependency fails, times out, or returns partial results. - Lifecycle and process ownership, especially for long-running work such as workers, queues, schedulers, and background services. - Compatibility with existing conventions, patterns, and naming. ## Evaluate - Alternatives with their tradeoffs, including doing nothing. - Migration path from the current structure, and whether it can be incremental. - Rollback and coexistence during rollout. - Operational cost: observability, failure modes, and new failure surfaces. ## Output Present the recommended structure, why it fits this codebase, the rejected alternatives with reasons, the migration steps, and the risks with mitigations. Then ask for approval before implementing a structural change. ## Rules - Do not redesign working code that the request does not touch. - Do not add layers, interfaces, or abstractions without a demonstrated need. - Keep responsibilities where the project already keeps them. - Do not implement structural changes without explicit approval.