Engineering Quality Gate for Architecture and Code Review

Run an engineering quality gate covering architecture boundaries and standards-backed implementation review.

Purpose

This guide defines a focused engineering quality gate for architecture boundary review and standards-backed implementation review. It helps the user decide whether the task needs structure and boundary review, official-guidance implementation review, or both in sequence. It is not the full code-review hub and does not cover test coverage, regression risk, refactor planning, general code-quality review, or code generation.

When to use this

Use this section to decide whether this workflow is the right fit before you configure prompts, policies, or reference material.

  • Use case
    The review is limited to architecture and implementation correctness
    Use this when the approval question is whether design boundaries are correct and whether implementation follows official guidance.
  • Use case
    You need to choose between two focused review paths
    Use this when the task may require Architecture Boundary Review, Standards-Backed Implementation Review, or both in sequence.
  • Use case
    You need a focused gate before broader code-review work
    Use this before opening the full code-review hub when the first decision is whether the issue is structural or standards-backed implementation correctness.

Choose the focused engineering gate path

Use this page only for the architecture plus implementation quality gate. For testing, regression risk, refactor planning, general code quality, or code generation, use the full code review hub.

Option 1 · Architecture boundary review

Run Architecture Boundary Review

Use this path when the primary issue is system structure: boundaries, layering, ownership, dependency direction, state flow, or interface separation.
Evidence boundary: Code, architecture context, dependency information, ownership boundaries, state flow, and interface evidence.
Best for: Module boundaries, dependency direction, layering, ownership, coupling, state boundaries, interface contracts, and boundary leakage.
Use when: The review question is whether the system shape or boundary is correct.
Open guide
Option 2 · Standards-backed implementation review

Run Standards-Backed Implementation Review

Use this path when the primary issue is whether code or configuration follows official framework, runtime, API, platform, or standards guidance.
Evidence boundary: Code or configuration plus official documentation, standards, platform guidance, or other authoritative source material.
Best for: Implementation correctness, API misuse, version-sensitive behavior, configuration correctness, and source-backed remediation.
Use when: The review question is whether the implementation is correct according to authoritative guidance.
Open guide

Step-by-step implementation procedure

Follow the workflow in order. Each step gives one action and one verification check before continuing.

  1. Step 1 · Confirm this is the focused gate

    Check whether the task is limited to architecture boundaries and standards-backed implementation correctness.
    Use the full code review hub instead if testing, regression risk, refactor planning, general code quality, or code generation is part of the task.
    Check: The review scope is architecture and/or implementation correctness only.

  2. Step 2 · Choose the dominant review path

    Select Architecture Boundary Review when the problem is structure. Select Standards-Backed Implementation Review when the problem is correctness against official guidance.
    Choose one path first instead of merging both review contracts into one prompt.
    Check: The selected path matches the dominant engineering question.

  3. Step 3 · Provide the right evidence for the selected path

    Architecture review needs structural evidence. Standards-backed implementation review needs code or configuration plus authoritative guidance or a clear source boundary.
    Attach the relevant code, configuration, architecture context, dependency information, official documentation, or supplied source material.
    Check: The supplied evidence is sufficient for the selected review path.

  4. Step 4 · Run the selected procedure

    Open the selected procedure and run it with the prepared material.
    Use the architecture procedure for structure and boundaries. Use the standards procedure for implementation correctness against guidance.
    Check: The procedure output stays inside the selected review boundary.

  5. Step 5 · Run both only when both are needed

    When both focused reviews are required, run Architecture Boundary Review first, then Standards-Backed Implementation Review.
    Do not combine both contracts into one unstructured review. Use two passes and keep findings separated.
    Check: Architecture findings and implementation findings are separated and supported by the relevant evidence.

Verification checklist

Use this checklist before accepting the output, publishing it, or using it as evidence for a downstream workflow.

  • Scope
    The gate stayed focused
    The review did not expand into test coverage, regression risk, refactor planning, general code-quality review, or code generation.
  • Routing
    The selected path matches the dominant issue
    Architecture review is used for structure and boundaries. Standards-backed implementation review is used for implementation correctness against authoritative guidance.
  • Evidence
    The required material is available
    Architecture findings are supported by structural evidence, and implementation findings are supported by code/configuration plus authoritative guidance or supplied source material.
  • Order
    Dual review runs in the correct order
    When both reviews are needed, architecture runs first, then implementation review.
  • Separation
    Findings are not mixed
    Architecture findings, implementation findings, missing evidence, and next actions are separated.

Next steps