architecture-review

An architectural review assesses technical feasibility, complexity, and alignment before coding. It prevents technical debt by catching infeasibility, drift, and domain violations early through a structured evaluation of your technical intent and prerequisites.

An Architecture Decision Record (ADR) is a document that captures significant technical decisions made during an architectural review. You need an approved ADR to proceed with any architectural change, ensuring that stack compatibility and integration risks are formally addressed.

To assess technical feasibility and domain integrity, you review the PRD against documented architecture, checking stack compatibility, boundaries, and domain modeling principles. This pre-implementation check identifies potential risks and ensures the design aligns with established patterns.

Yes, architecture review explicitly identifies and verifies technical claims and assumptions found in your PRDs and technical intent. It validates these claims against prerequisites and documented architecture to ensure the proposed integration surface is viable.

The best way to document architectural risks is to generate a Risk Register during the design review, outlining potential risks alongside their mitigation strategies, which then feeds into the final review summary and verdict before any coding begins.

Yes, a Product Requirements Document (PRD) or equivalent technical intent is required for a technical feasibility assessment. The review process relies on these documents to evaluate stack compatibility, complexity, and architectural alignment.