arn-code-review-implementation

Arness Review Implementation

Post-execution quality gate that verifies an implementation matches the project plan and follows the stored code patterns, testing patterns, and architecture documentation. Reports issues classified as ERRORS, WARNINGS, and INFO, with a final verdict.

Pipeline position:

arn-code-init -> arn-code-feature-spec / arn-code-bug-spec -> arn-code-plan -> arn-code-save-plan -> arn-code-review-plan -> arn-code-taskify -> arn-code-execute-plan -> **arn-code-review-implementation**

This is a self-contained review -- it does not invoke sub-agents. The review is a structured, checklist-driven process: read code, compare to patterns, classify findings.

When to Use:

• After arn-code-execute-plan completes
• To verify that implementation matches the plan and follows stored patterns
• Before considering the project done
• Optional -- skip for small/straightforward projects; recommended for 3+ phases, multiple modules, or critical features

Prerequisites

If no ## Arness section exists in the project's CLAUDE.md, inform the user: "Arness is not configured for this project yet. Run /arn-implementing to get started — it will set everything up automatically." Do not proceed without it.

Workflow

Step 1: Load the Project

1. Read the project's CLAUDE.md and extract the ## Arness section to find:
2. Plans directory path
3. Code patterns directory path
4. Ask for PROJECT_NAME if not provided in the trigger message
5. Read all project artifacts:
6. <project-folder>/INTRODUCTION.md -- codebase patterns that should have been followed
7. All reports in <project-folder>/reports/ -- what was implemented, tested, bugs fixed
8. All phase plans in <project-folder>/plans/ -- acceptance criteria, expected files, expected patterns
9. Read stored pattern documentation:
10. <code-patterns-dir>/code-patterns.md
11. <code-patterns-dir>/architecture.md
12. <code-patterns-dir>/testing-patterns.md
13. <code-patterns-dir>/ui-patterns.md (if it exists)
14. <code-patterns-dir>/security-patterns.md (if it exists)
15. Build a review checklist from these sources: files that should exist, patterns that should have been applied, features that were planned, tests that should pass

Step 2: Plan Compliance Review

Compare the plan artifacts (phase plans, INTRODUCTION.md) with the execution reports (implementation reports, testing reports). Run these checks:

| Check | Severity | What | |-------|----------|------| | PC01 | ERROR | Every feature listed in phase plans has a matching entry in implementation reports | | PC02 | ERROR | Every test case listed in phase plans has a matching entry in testing reports | | PC03 | WARNING | All acceptance criteria from phase plans are addressed in reports | | PC04 | WARNING | Files listed in filesCreated/filesModified in reports actually exist on disk | | PC05 | INFO | Features implemented that were NOT in the original plan (scope creep detection) | | PC06 | ERROR | Any bugsFixed entries -- read the changed files to verify the fix was correct | | PC07 | WARNING | Testing pass rate below 100% -- investigate remaining failures |

Step 3: Pattern Compliance Review (Dynamic)

All checks in this step are generated dynamically from stored pattern documentation. This is NOT a hardcoded checklist -- the checks are derived at runtime from whatever patterns are documented for this project.

Code Pattern Compliance:

Read code-patterns.md. For each documented pattern:

1. Identify implementation files where this pattern should apply (from reports + pattern context)
2. Read the relevant files
3. Check whether the implementation follows the documented pattern
4. Generate findings with these severity levels:
5. CP-[PatternName]-CONFLICT (ERROR) -- implementation contradicts the documented pattern
6. CP-[PatternName]-MISSING (WARNING) -- pattern should apply but wasn't followed
7. CP-[PatternName]-APPLY (WARNING) -- general deviation from the pattern

Architecture Compliance:

Read architecture.md. Check that:

• Component boundaries are respected (no cross-boundary violations)
• Integration points match the documented architecture
• Architectural decisions from INTRODUCTION.md are reflected in the implementation

UI Pattern Compliance (if ui-patterns.md exists):

Read ui-patterns.md. For each documented pattern:

1. Identify implementation files where this pattern should apply (frontend components, pages, layouts)
2. Read the relevant files
3. Check whether the implementation follows the documented UI pattern
4. Generate findings:
5. UP-[PatternName]-CONFLICT (ERROR) -- implementation contradicts the documented UI pattern (e.g., wrong component library)
6. UP-[PatternName]-MISSING (WARNING) -- UI pattern should apply but wasn't followed
7. UP-[PatternName]-ACCESSIBILITY (WARNING) -- accessibility requirements documented but not implemented

Testing Pattern Compliance:

Read testing-patterns.md. For each documented pattern:

1. Identify test files from testing reports
2. Read the test files
3. Check correct usage of the documented test framework, markers, fixtures, and helpers
4. Generate findings:
5. TP-[PatternName]-FRAMEWORK (ERROR) -- wrong test framework or runner used
6. TP-[PatternName]-FIXTURES (WARNING) -- should use documented fixtures but doesn't
7. TP-[PatternName]-MARKERS (WARNING) -- should use documented markers but doesn't

Security Pattern Compliance (if security-patterns.md exists):

Read security-patterns.md. For each documented pattern:

1. Identify implementation files where this pattern should apply (auth endpoints, input handlers, data models, API routes)
2. Read the relevant files
3. Check whether the implementation follows the documented security pattern
4. Generate findings:
5. SP-[PatternName]-CONFLICT (ERROR) -- implementation contradicts the documented security pattern (e.g., plaintext passwords when hashing is documented)
6. SP-[PatternName]-MISSING (WARNING) -- security pattern should apply but wasn't followed (e.g., no input validation on a new endpoint)
7. SP-[PatternName]-WEAKNESS (WARNING) -- implementation partially follows the pattern but has gaps (e.g., auth check present but no rate limiting)

Step 3b: Visual Regression Review

This step is conditional. Check if ### Visual Testing is configured in the project's CLAUDE.md ## Arness section.

If not configured: Skip this step silently. Do not add any findings.

If configured: Parse the full ### Visual Testing section:

1. Discover layers:
2. Extract top-level fields as Layer 1 config (always active): capture script, compare script, baseline directory, diff threshold, requires dev server
3. Scan for #### Layer N: subsections. For each, extract: Status, Capture script, Compare script, Baseline directory, Diff threshold, Requires dev server, Environment
4. Build a layer list. Filter to active layers only (Status = active or validated). Skip deferred layers.

1. For each active layer:

a. If the layer requires a dev server and the dev server is not already running: start it (read the start command from INTRODUCTION.md or the project's package.json) b. Run the layer's capture script: `` [layer capture command] ` c. Run the layer's comparison script against its baselines: ` [layer compare command] `` d. Parse the comparison output and generate layer-prefixed findings:

| Check | Severity | What | |-------|----------|------| | VR-L[N]-[ScreenName]-REGRESSION | ERROR | Screen has visual regression above threshold ([X]% pixel difference, threshold: [T]%) | | VR-L[N]-[ScreenName]-MISSING | WARNING | No baseline image exists for this screen | | VR-L[N]-[ScreenName]-MATCH | INFO | Screen matches baseline within threshold |

e. If the layer's capture or comparison script fails to run: add a sing