Architecture

Architecture

Config Resolution

Step 1 — Determine mode:

1. Read .lattice/config.yaml in repo root
2. Check architecture_mode key
   • If architecture_mode: custom → custom mode
   • If absent, or other value → clean architecture mode (default)

Step 2 — Load enforce rule:

• Clean architecture mode → Read ./references/clean-architecture.md for enforce instruction (Self-Validation Checklist, Anti-Pattern Scan, Ambiguity Signals, structural principles)
• Custom mode → Read ./references/custom-architecture.md for enforce instruction

Step 3 — Load architecture content:

• Clean architecture mode:

  1. Check paths.architecture in .lattice/config.yaml for a custom document path.
  2. If a document exists at that path → read it and check its YAML frontmatter for mode:
     • mode: overlay (or no mode field): read ./references/clean-architecture-defaults.md first, then apply the custom document's sections on top. Sections match by exact heading — a custom section replaces the matching default; new sections append after the defaults.
     • mode: override: the custom document takes full precedence. It must be comprehensive.
  3. If the path is configured but no document exists at it → tell the user which configured path is missing, then read ./references/clean-architecture-defaults.md.
  4. If there is no configured path → read ./references/clean-architecture-defaults.md.

• Custom mode:

  1. Check paths.architecture in .lattice/config.yaml for team architecture doc
  2. If found → read it. Sole reference — no default.
  3. If not found → surface: "No architecture document found. Run /architecture-refiner and select your architecture style to define your team's standards."

Step 4 — Language adaptation:

If paths.language_idioms is set in the config and the document exists, read its "Dependency Management" section and adapt dependency direction enforcement to language idioms (e.g., Go interface-at-consumer, Java DI containers, Rust trait bounds). Language idioms take precedence over pseudocode defaults.

Enforcement

STOP after generating each component. Read the Self-Validation Checklist and Anti-Pattern Scan from the loaded enforce rule (clean-architecture.md or custom-architecture.md) and apply them.

Project-specific checks: If architecture content doc (loaded in Step 3) contains a Validation Checklist section (§6), apply those checks as additional project-specific validation after the enforce rule checklist.

Design Mode

When invoked during design — no code is being written; a planning molecule is validating a proposed design artifact — apply the same enforce rule as a forward-looking check:

1. Take the proposed artifact (component list, layer assignment, data flow, or contract set) as the unit of validation.
2. Evaluate it against the Self-Validation Checklist and Anti-Pattern Scan from the loaded enforce rule, plus the project-specific Validation Checklist if present — before the artifact is presented for user approval.
3. Report violations as concrete findings on the artifact ("Component X reaches from layer A to layer C, skipping B"), not generic advice. Resolve them through the design.
4. STOP: do not skip checklist evaluation on the grounds that no code exists yet — the proposed structure is what gets validated.