Architecture is an input.
Generate inside an understood system.
An architecture contract describes the decisions a generated patch must preserve. It is a short, repository-specific record of ownership and constraints. Establish it through source inspection; a diagram or an outdated overview is useful context, but it is not sufficient evidence of current behavior.
Identify the owner of each decision
Trace a representative request from entry point to persistence. Record where authorization, validation, business rules, and transport adaptation belong. Ask the assistant to cite the relevant modules. If two layers appear to own the same rule, resolve that uncertainty before letting a new implementation make it harder to untangle.
State what the patch must preserve
Name the allowed dependency direction and an existing implementation worth following. Include observable invariants such as stable identifiers or transaction boundaries. Keep the contract small enough to read beside the diff. Update it when inspection disproves an assumption, and distinguish a deliberate architecture change from routine feature work.
- OWNER
- Application service owns business decisions.
- BOUNDARY
- HTTP adapter translates requests and responses.
- INVARIANT
- Existing callers retain their response contract.
WORKING REQUEST / SPEC 01
Inspect the existing request path without editing. Identify the owner of validation and persistence. Cite one implementation to follow. List constraints the proposed change must preserve.
Do not accept a new layer solely because the generated code looks organized.