review

# Review

## Required Skills

Load/apply skills based on scope (see Step 2 for conditional loading):

1. `framework:knowledge-priming` -- Load project context (tech stack, architecture, conventions) to evaluate against real standards (always loaded)
2. `framework:learning-harvest` -- Load prior operational learnings inform review; harvest new patterns at session end (always)
3. `framework:collaborative-judgment` -- Surface borderline findings with both interpretations instead of silently classifying (always loaded)
4. `framework:clean-code` -- Code craft: SRP, naming, complexity, error handling (always loaded)
5. `framework:architecture` -- Structural: layer rules, dependency direction, architectural flows (conditional)
6. `framework:domain-driven-design` -- Domain modeling: aggregates, entities, value objects (conditional)
7. `framework:secure-coding` -- Security: trust boundaries, injection, secrets, input handling (conditional)
8. `framework:test-quality` -- Test: AAA structure, isolation, assertions, naming (conditional)

## Config Resolution

Review molecule supports optional config thru review-standards doc from review-refiner (or hand-written). Configures review *process* — not what atoms check (that's atom-level config via atom refiners).

**Resolution steps:**

1. Look for `.lattice/config.yaml` in repo root.
2. Check for config key `paths.review_standards`.
3. If doc exists at path, read & check YAML frontmatter for `mode`:
   - **`mode: overlay`**: Read embedded defaults first, then apply doc's sections on top. Sections matched by heading — custom replaces matching defaults, new appended.
   - **`mode: override`** (or no mode): Custom doc full precedence. Must be comprehensive.
4. If no config or no review-standards doc found, use embedded defaults thruout workflow (full backward compat — identical to review with no config).

Review-standards doc has 7 sections map to workflow steps:

| Section | Affects step |
|---------|-------------|
| §1 Atom Loading Policy | Step 2 (Load Relevant Atoms) |
| §2 Severity Classification | Step 4 (Produce Report) |
| §3 Report Preferences | Step 4 (Produce Report) |
| §4 Scope Rules | Step 1 (Identify the Delta) |
| §5 Insight Capture Preferences | Step 5 (Harvest Learnings and Log Review) |
| §6 Health Log Preferences | Step 5 (Harvest Learnings and Log Review) |
| §7 Custom Review Dimensions | Step 3 (Run Targeted Validation) |

Each step notes where config applies with "**Config override**" callouts. When no review-standards doc exists, ignore callouts & use defaults.

## Workflow

### Step 1: Identify the Delta

Use `framework:learning-harvest` Load behavior. Focus hint: "review session — focus: all categories". Prior learnings across all categories inform review — recurring patterns are more likely to be flagged, known fragile areas get extra attention.

Determine what code reviewing & establish scope.

- **PR or commit**: Use `git diff` for changed files/lines. Delta is changes, not entire codebase.
- **Set of files**: User specifies files. Delta is those files.
- **Feature or module**: User points to feature. Identify relevant files from codebase.

Classify delta:

1. **Which architectural layers touched?** (per loaded architecture rules) -- determines if `architecture` loads.
2. **Is domain code included?** (files in configured `domain_folder` or containing aggregates, entities, value objects) -- determines if `domain-driven-design` loads.
3. **Security-sensitive areas touched?** (auth, authz, input handling, DB queries, external API calls, file I/O, config, secrets) -- determines if `secure-coding` loads.
4. **Test files included?** -- determines if `test-quality` loads.

**Config override (§4 Scope Rules):** If review-standards doc defines scope rules, apply after identifying delta:
- **Directory exclusions**: Remove files matching exclusion patterns from delta before classification.
- **Directory inclusions (always-full-scan)**: When delta touches file in always-full-scan dir, expand delta to include all files in that dir.
- **Surrounding-code policy**: Use configured policy (strict/default/expansive) instead of default.
- **Dependency expansion**: If enabled, also include files that directly import from changed files.

### Step 2: Load Relevant Atoms

**Always load**: `framework:clean-code` -- applies to all code regardless of layer/purpose.

**Conditionally load** based on delta classification:

| Condition | Load | Why |
|-----------|------|-----|
| Delta touches multiple layers, adds new files, or changes file locations | `framework:architecture` | Structural changes can break dependency direction or layer responsibilities |
| Delta includes files in domain folder or modifies domain objects | `framework:domain-driven-design` | Domain changes can break aggregate boundaries, anemic models, or invariant enforcement |
| Delta touches trust boundaries (HTTP handlers, auth, DB queries, external APIs, secrets, config) | `framework:secure-coding` | Security-sensitive code needs injection, validation, and secrets checks |
| Delta includes test files | `framework:test-quality` | Test code has own quality standards (AAA, isolation, naming) |

When multiple atoms load, run independently -- each atom's checklist applied to parts of delta relevant to it. Findings from different atoms merged Step 4.

**Config override (§1 Atom Loading Policy):** If review-standards doc defines atom loading rules, apply instead of (override) or on top of (overlay) table above:
- **Always-load overrides**: Additional atoms moved to always-load (e.g., `secure-coding` every review). `clean-code` and `knowledge-priming` must remain always-loaded regardless of config.
- **Suppressed atoms**: Atoms listed as suppressed never loaded, even if delta matches trigger condition.
- **Custom path-based triggers**: If delta includes files matching custom path pattern, load associated atom regardless of standard conditions.
- **Modified conditions**: Replacement trigger condi