review-arch-consistency

<when_to_use> The change affects module boundaries, contracts, or integrations It is necessary to assess whether the solution violates established architecture rules </when_to_use>

<input_requirements> Description of the architectural decision or ADR List of affected components and contracts Project architectural principles and constraints </input_requirements>

<core_checks> The solution is compatible with existing layers and responsibility boundaries New dependencies are justified and do not create hidden coupling The change does not conflict with previously accepted architectural decisions Deviations from principles are documented and explained Existing mechanisms are reused rather than duplicated </core_checks>

<quality_rules> Each deviation from architecture rules has an explicit rationale and owner Conclusions are backed by links to artifacts: ADRs, diagrams, contracts The review records consequences for neighboring teams and modules </quality_rules>

<do_not> Do not accept architectural changes based only on a local team benefit Do not ignore the accumulation of inconsistent exceptions </do_not>

<output_requirements> Short verdict: consistent or inconsistent List of conflicts/deviations and acceptance conditions </output_requirements>