Engineering Quality Gate — focused policy

By

Policy for using the Engineering Quality Gate as a focused architecture plus standards-backed implementation review gate.

Scope and review order

Use this policy when the review scope is intentionally limited to architecture boundaries and standards-backed implementation correctness.

Architecture + implementation only
This policy routes the review to Architecture Boundary Review, Standards-Backed Implementation Review, or both in sequence.
Not the full code-review hub
Use the full code-review policy when the task includes test coverage, regression risk, refactor planning, general code quality, or code generation.
Architecture first when both are needed
If both focused reviews are required, run Architecture Boundary Review first, then Standards-Backed Implementation Review.

Policy rules

These rules define the focused gate before a concrete review procedure runs.

Rule 1
Use this gate only for focused engineering review
The gate is valid only when the task is about architecture boundaries, layering, ownership, dependency direction, standards-backed implementation correctness, or both.
Rule 2
Select one dominant review path first
Choose Architecture Boundary Review when the dominant issue is structural. Choose Standards-Backed Implementation Review when the dominant issue is correctness against authoritative guidance.
Rule 3
Do not merge review contracts
Architecture findings and standards-backed implementation findings must remain separate. If both reviews are needed, run them as two passes.
Rule 4
Require the right evidence for each path
Architecture review requires structural evidence. Standards-Backed Implementation Review requires code or configuration plus authoritative guidance or a clearly supplied source boundary.

Choose the active review policy

The Engineering Quality Gate policy routes the review. The selected child policy controls the concrete review run.

Option 1 · Architecture
Architecture Boundary Review
Use this when the primary issue is module boundaries, layering, dependency direction, ownership, coupling, state boundaries, interface contracts, or boundary leakage.
Open Architecture Boundary Review policy
Option 2 · Implementation
Standards-Backed Implementation Review
Use this when the primary issue is whether code or configuration follows official framework, runtime, API, platform, standard, or other authoritative guidance.
Open Standards-Backed Implementation Review policy

Use a different policy when the scope is broader

This focused gate must not absorb adjacent engineering workflows.

Full code-review policy
Use when the task includes test coverage, regression risk, refactor planning, code quality, code generation, or broader review routing.
Open policy
Test coverage and regression risk
Use when the task is about missing tests, weak assertions, fixture or mock drift, test setup gaps, or regression-sensitive behavior.
Open workflow
Code quality and best practices
Use when the task is readability, maintainability, naming, modularity, error handling, framework conventions, or general implementation quality.
Open prompt

Verification checklist

Use this checklist before accepting that the focused gate was applied correctly.

Scope stayed focused
The run did not expand into testing, regression risk, refactor planning, general code quality, or code generation.
Path matched the dominant issue
Architecture review was used for structure and boundaries. Standards-backed implementation review was used for authoritative-guidance correctness.
Evidence was sufficient
Architecture findings were supported by structural evidence, and implementation findings were supported by code/configuration plus authoritative guidance or supplied source material.
Findings stayed separated
Architecture findings, implementation findings, missing evidence, and next actions were not merged into one undifferentiated review output.