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:

Each step notes where config applies with "Config override" callouts.

Workflow

Step 1: Identify the Delta

Use framework:learning-harvest Load behavior. Focus hint: "review session — focus: all categories".

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:

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 conditions for conditional atoms.

Step 3: Run Targeted Validation

For each loaded atom, apply two passes against delta:

Pass 1 -- Self-Validation Checklist: Walk thru atom's Self-Validation Checklist (numbered items in atom's SKILL.md). For each check, examine if any code in delta violates. Record violations with:

• Specific check that failed
• Exact file & line(s)
• Concrete suggested fix

Pass 2 -- Anti-Pattern Scan: Walk thru atom's Active Anti-Pattern Scan (checkbox items in atom's SKILL.md). For each anti-pattern, check if delta exhibits symptom. Record matches with:

• Anti-pattern name
• Symptom observed in delta
• Fix, adapted to specific code

Scope rule: Focus on delta. Don't review unchanged code unless change in delta creates new violation in surrounding code (e.g., new dependency breaks dependency rule for existing file). When reviewing surrounding code, note finding originates from delta's impact, not pre-existing issues.

Config override (§7 Custom Review Dimensions): If review-standards doc defines custom review dimensions, run after atom validation passes:

• For each custom dimension, check if delta matches trigger condition.
• For matching dimensions, apply dimension's checklist against delta using same two-pass approach: check each criterion, record findings with dimension's default severity (or classified severity), file location, suggested fix.
• Custom dimension findings merged with atom findings Step 4.