Review scope
Architecture, layering, and boundaries
Use this path for architecture classification, layering and dependency direction, boundary leakage, interface ownership, state ownership, and minimal structural remediation.
Run the architecture boundary review — procedure
Procedure for architecture classification, layering and boundary analysis, and minimal structural remediation from inspected materials.
Use this procedure for architecture and boundary review
Choose this procedure when the task is about the shape and boundaries of the system and the answer must stay grounded in inspected materials.
Typical use
Decide whether the current system shape is defensible
Use it when you need evidence-based architecture classification from repo or design materials and a minimal structural changeset rather than a broad rewrite.
Fail-closed rule
Missing core inputs stop the run
Required inputs are goal, materials, and constraints.
Canonical links
Open the linked policy and prompt files that implement this architecture review workflow.
Related
Policy and prompt files for this guide
Open the policy linked to this guide and any prompt files used with it.
What to load
Load the review stack in this order before you run the workflow.
Optional for smaller but dense files
Optional for repo snapshots, ZIPs, or many files
Optional evidence/conflict pass
Optional scoring and verification add-ons
Inputs required
Provide these inputs before the run can produce an evidence-based structural answer.
Required
Goal or intent of the review
State what you want evaluated and what architectural concern matters.
Required
Materials to inspect
Provide files, snippets, file trees, or design excerpts that support architecture inference.
Required
Constraints
Include language, framework, runtime, and any relevant non-functional limits.
Optional: intended architecture or boundary rules
Useful when you want the review to compare the observed system against an intended design.
Optional: ownership expectations
Useful when interfaces or modules have expected ownership boundaries.
Run the procedure
Follow these steps in order.
Step 1
State the review target
Say what should be evaluated: observed architecture, boundary correctness, dependency direction, state ownership, or a specific structural concern.
Step 2
Load the artifacts-only boundary
Paste
facts-only-artifacts-only.system.txt so the run stays grounded in inspected materials by default.Step 3
Load the architecture review contract
Paste
architecture-boundary-review.system.txt.Step 4
Load the runner
Paste
architecture-boundary-review.user.txt and append the goal, materials, constraints, and any optional boundary rules.Step 5
Add deep-scan only when the input is broad
If the materials are a repo snapshot, ZIP, or many files, prepend
deep-scan.user.txt.Step 6
Run the review
The output must follow this exact section order:
Step 7
Check the boundary of the result
Confirm that the output cites only inspected materials for architecture evidence, does not invent a hidden architecture, keeps findings inside architecture and boundary scope, and proposes minimal structural changes.
Verify the setup
Use these smoke tests to confirm that the procedure is behaving correctly.
Smoke test 1
Provide a goal, a small file tree, 1–2 relevant files, and constraints.
Smoke test 2
Omit one required input, such as constraints.
Smoke test 3
Provide materials that are too thin to classify the architecture.
Common failure modes
These are the main failure modes this procedure is intended to block.
Using it as a generic best-practice audit
This procedure is not a broad framework-guidance or generic best-practice sweep.
Mixing in security or performance review
Do not ask for secure code review or performance tuning inside the same run.
Treating guessed architecture as evidence
Do not infer a hidden architecture and present it as if the materials proved it.
Escalating to a whole-system rewrite
Prefer minimal structural remediation instead of broad rewrites.