Code Review Checklist

Standard Operating Procedure: Engineering Code Review Protocol (ECRP-09)

1. Document Control Block

• Document ID: SOP-ENG-CR-09-REV4
• Effective Date: October 26, 2023
• Version: 4.2.0
• Review Cadence: Quarterly (Q1, Q2, Q3, Q4)
• Target Audience: Software Engineering Division, DevOps, Quality Assurance, Security Architecture

2. Executive Summary & Scope

This procedure establishes the mandatory technical requirements and behavioral standards for the peer review of source code at Template Registry. The scope encompasses all modifications to the production repository, including patches, feature branch merges, and infrastructure-as-code (IaC) updates. Compliance is mandatory to ensure operational stability, regulatory alignment with SOC2/ISO27001 standards, and mitigation of technical debt.

3. Prerequisites & Tool Requirements

• Access: Active GitHub Enterprise seat with Write or Maintain permissions.
• Software: Integrated Development Environment (IDE) with linting plugins (ESLint/Prettier/Checkstyle) configured to repository standards.
• Credentials: Validated MFA-protected SSO credentials.
• Infrastructure: Access to the staging CI/CD pipeline environment.
• Training: Completion of "Secure Coding Principles: OWASP Top 10" certification.

4. Roles & Responsibilities (RACI Matrix)

5. Step-by-Step Operational Procedure

Phase 1: Pre-Submission Readiness

• Verify unit test coverage exceeds the 85% threshold.
• Execute local linting and static analysis (SAST) to identify potential injection vulnerabilities.
• Confirm no hardcoded secrets, API keys, or sensitive credentials exist in the commit history.
• Ensure documentation updates reflect the functional changes in the code.

Phase 2: Peer Evaluation & Commentary

• Review for business logic accuracy against the JIRA ticket requirements.
• Evaluate code complexity; verify cyclomatic complexity is within established boundaries.
• Validate adherence to internal naming conventions and modular design patterns.
• Ensure non-functional requirements (latency, memory overhead) are met.

Phase 3: Final Verification & Merge

• Obtain at least one "Approved" status from a peer with write-access.
• Confirm all requested changes from the review cycle have been addressed and validated.
• Verify the pipeline build status is "Green" (Successful) on the feature branch.
• Perform a final squash-and-merge to maintain a clean linear commit history.

6. Quality Assurance & Verification Criteria

• Audit Checklist: All code changes must be mapped to a verifiable JIRA ID or equivalent tracking item.
• Tolerance Thresholds: Zero "Critical" or "High" severity vulnerabilities identified by automated scanners.
• Acceptance Benchmarks: A minimum of 2 reviewers for changes touching sensitive core modules (auth, payment gateways, data privacy layers).

7. Practical Troubleshooting Scenarios

Scenario A: CI Pipeline Failure on Merge Request

• Failure: Build fails due to environmental drift between developer machine and CI agent.
• Corrective Action: Do not force-push. Execute git fetch origin and git rebase to bring the branch up to date with main. If build failures persist, trigger a fresh dependency reinstall via the specific CI config tool (e.g., npm ci or pipenv sync).

Scenario B: Reviewer Deadlock

• Failure: Conflicting feedback between two senior reviewers preventing merge approval.
• Corrective Action: Reviewer deadlock must be escalated to the Engineering Manager within 4 hours. The Engineering Manager serves as the final arbiter and shall conduct a sync meeting to document the decision in the PR comments for audit purposes.

Scenario C: Detected Credential Exposure

• Failure: Sensitive PII or hardcoded credentials detected in commit history.
• Corrective Action: Immediate halt of the PR. Rotate the exposed credential immediately. Scrub the history using git filter-repo or BFG Repo-Cleaner before updating the remote, ensuring the vulnerability is permanently excised from all logs.

Authorized by: Julian Vance Chief Operations Architect, Template Registry