Integrity Review

Post-implementation audit that verifies both technical quality and behavioral integrity of code changes. Triggered manually.

Process

Step 1: Determine Scope

Identify what changed:

• git diff for uncommitted modifications
• git diff HEAD~N for recent commits (choose N based on session scope)
• If the user specifies files or a commit range, use that

Include all changes in scope — not just the last commit. A session may span multiple commits.

Step 2: Integrity Audit

For each modified file, evaluate against five failure patterns:

2.1 Reasoning-Action Coherence

• Does the implementation match what was discussed and planned in conversation?
• Were concerns raised during analysis actually addressed in code?
• Example violation: discussion identified "needs pagination" but the query fetches all rows

2.2 Fabrication

• Tests with hardcoded expected values that cannot fail
• Stub functions returning fixed success responses without logic
• Claims of "verified" without evidence of execution
• Example violation: expect(validate(input)).toBe(true) where validate always returns true

2.3 Omissions

• Unhandled edge cases (empty arrays, null values, concurrent access)
• Silenced errors: empty catch {}, swallowed promise rejections
• Linter or compiler warnings present but unaddressed
• Example violation: catch (e) { /* TODO */ } in production code

2.4 Convention Compliance

• Code follows project lint rules, style, and architecture patterns
• Any convention cited during implementation is applied correctly
• Example violation: code uses var when project ESLint enforces const/let

2.5 Shortcut Detection

• "Temporary" solutions with no tracking issue or expiration
• Workarounds that avoid the real problem
• Example violation: disabling a test instead of fixing the underlying failure

Step 3: Technical Quality Audit

For each modified file:

• Defects: Logic errors, off-by-one, unhandled null/undefined, race conditions, incorrect boundary handling
• Security: Injection vectors (SQL, XSS, command), exposed credentials, missing input validation at trust boundaries
• Efficiency: N+1 queries, unnecessary iterations, avoidable quadratic operations, missing indices on queried fields
• Clarity: Naming precision, function length, cognitive complexity, self-documenting structure

Step 4: Report

Present findings in this format:

## Review Result

### Integrity
- [PASS/FAIL] Reasoning-action coherence: <specific finding>
- [PASS/FAIL] No fabrication: <specific finding>
- [PASS/FAIL] Transparency: <specific finding>
- [PASS/FAIL] Convention compliance: <specific finding>
- [PASS/FAIL] No shortcuts: <specific finding>

### Technical Quality
- [PASS/FAIL] Defects: <specific finding>
- [PASS/FAIL] Security: <specific finding>
- [PASS/FAIL] Efficiency: <specific finding>
- [PASS/FAIL] Clarity: <specific finding>

### Required Actions
1. [concrete action item — if any]

### Verdict: APPROVED / APPROVED WITH CAVEATS / REJECTED

Every PASS requires a specific justification — what was checked and why it is satisfactory. "Looks fine" is not a valid PASS reason.

If REJECTED, offer to apply fixes automatically.

Structured Output Schema

For programmatic invocation (e.g., Agent SDK), return results conforming to:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["integrity", "technical_quality", "verdict"],
  "properties": {
    "integrity": {
      "type": "object",
      "required": ["reasoning_action_coherence", "no_fabrication", "transparency", "convention_compliance", "no_shortcuts"],
      "properties": {
        "reasoning_action_coherence": { "$ref": "#/$defs/check" },
        "no_fabrication": { "$ref": "#/$defs/check" },
        "transparency": { "$ref": "#/$defs/check" },
        "convention_compliance": { "$ref": "#/$defs/check" },
        "no_shortcuts": { "$ref": "#/$defs/check" }
      }
    },
    "technical_quality": {
      "type": "object",
      "required": ["defects", "security", "efficiency", "clarity"],
      "properties": {
        "defects": { "$ref": "#/$defs/check" },
        "security": { "$ref": "#/$defs/check" },
        "efficiency": { "$ref": "#/$defs/check" },
        "clarity": { "$ref": "#/$defs/check" }
      }
    },
    "required_actions": {
      "type": "array",
      "items": { "type": "string" }
    },
    "verdict": {
      "type": "string",
      "enum": ["APPROVED", "APPROVED_WITH_CAVEATS", "REJECTED"]
    }
  },
  "$defs": {
    "check": {
      "type": "object",
      "required": ["status", "detail"],
      "properties": {
        "status": { "type": "string", "enum": ["PASS", "FAIL"] },
        "detail": { "type": "string" }
      }
    }
  }
}

Gotchas

• Last-commit-only scope — Always check the full range of changes, not just the most recent commit. Multi-commit sessions are common.
• "Looks fine" justifications — Every PASS needs a concrete explanation of what was verified. Vague approval is a rubber stamp.
• Test quality blindness — Tests with hardcoded expectations, zero assertions, or trivially passing logic are fabrication. Review test code with the same rigor as production code.
• Missing conversation context — Re-read earlier discussion in the session. A review that ignores constraints or decisions the user already communicated is incomplete.
• Diff-size bias — Small diffs can carry outsized impact: security boundary changes, default value modifications, config flag flips. Review depth must not scale linearly with diff size.
• Convention drift — Checking code against remembered conventions rather than re-reading the actual config files. Conventions change; verify from source.
• Workaround acceptance — A workaround that passes tests may still violate the "no shortcuts" criterion if it avoids the root problem. Flag workarounds even when they function correctly.
• APPROVED inertia — Tendency to approve when no glaring issues are found. Absence of obvious problems is not the same as verification. Actively probe each criterion.