Run the architecture boundary review — procedure

Review software layers, module boundaries, ownership, dependency direction, interfaces, and coupling using evidence from inspected files and diagrams.

Purpose

Use this procedure when the review question is whether the architecture structure, layers, boundaries, ownership, dependencies, interfaces, or state flow are supported by the inspected materials. The procedure prevents unsupported architecture claims and keeps recommendations limited to the available evidence.

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 main question is architectural structure
    Use this when the task is about architecture structure, layers, module boundaries, ownership, dependency direction, interface contracts, coupling, or state ownership.
  • Use case
    Architecture claims must be evidence-based
    Use this when architecture findings must be supported by supplied files, file trees, diagrams, snippets, or design excerpts.
  • Use case
    The output should propose a minimal change set
    Use this when the answer should identify boundary issues and recommend the smallest defensible architecture change set.

Step-by-step implementation procedure

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

  1. Step 1 · State the review target

    Say what should be evaluated: architecture structure, boundary correctness, dependency direction, state ownership, interface boundaries, or another specific architecture concern.
    Provide the review goal, inspected materials, constraints, and optional intended boundary rules.
    Check: The target is architectural, not a general implementation, security, or performance review.

  2. Step 2 · Load the provided-material evidence boundary

    Apply the facts-only artifacts-only system prompt so the review stays grounded in inspected materials by default.
    Check: The run does not use external or memory-based architecture claims unless explicitly allowed.

  3. Step 3 · Load the architecture review scope

    Apply the architecture boundary review system prompt.
    Check: The review scope is limited to architecture structure, layering, boundaries, ownership, dependency direction, interfaces, state ownership, and coupling.

  4. Step 4 · Load the runner

    Apply the architecture boundary review user prompt and append the goal, materials, constraints, and optional boundary rules.
    Check: Goal, materials, and constraints are present before the run starts.

  5. Step 5 · Add coverage controls only when needed

    Use exhaustive scanning for repository snapshots, ZIPs, or many files. Use read-all handling when the input is smaller but must be inspected completely.
    Add only the input-coverage component that matches the material size.
    Check: The run declares what was inspected and does not imply complete coverage without a coverage control.

  6. Step 6 · Run the review in the required output order

    The output must include context snapshot, evidence-based architecture classification, boundary findings, change set plan, and confidence.
    Keep output sections separated and evidence-bound.
    Check: Architecture classification is marked NOT VERIFIED when supplied material is insufficient.

  7. Step 7 · Check the boundary of the result

    Confirm that the output uses only inspected materials for architecture evidence, does not invent hidden architecture, stays inside architecture scope, and proposes minimal changes.
    Revise or stop when the result exceeds the selected evidence boundary.
    Check: Findings are scoped, supported, and minimal.

Verification checklist

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

  • Inputs
    Goal, materials, and constraints are present
    If any required input is missing, the review reports insufficient evidence instead of continuing.
  • Evidence
    Architecture claims are supported by inspected materials
    The review does not invent architecture intent, module ownership, hidden dependencies, or missing file content.
  • Scope
    Findings stay within architecture review scope
    The review does not drift into framework guidance, security review, performance tuning, or broad rewrite planning.
  • Output
    The output follows the required section order
    The answer separates context snapshot, architecture classification, boundary findings, change set plan, and confidence.
  • Recommendation
    The change set is minimal and architecture-focused
    Recommendations propose the smallest defensible architecture change set for the observed boundary issue.

Next steps