Code Review Backlog Cost Warning

Code-Review-Backlog Cost Warning

✅ PROMOTED — TDD Cycle 1 PASS (moderate value-add). RED subagent: correctly refused the push based on the CLAUDE.md maxim, but unstructured and without concrete cost-quantification. GREEN subagent: delivered a structured mandatory output block with concrete cost table (45 commits / 6,200 LoC / 13d → table row 4), explicit Option A vs. Option B, "Which option?"-stop per Step 4. Value-add: quantification + trajectory hint (cycle repeats vs earlier instances). Polish items in the Cycle-2-Backlog at the end.

Overview

Code-review backlogs are superlinearly more expensive than daily review — not linear. With 5x as many commits without review, the cleanup cost is not 5x but 20-50x higher, because:

• Re-review cycles accumulate (Fix-1 produces Fix-2-bug, Fix-2 produces Fix-3-bug)
• Schema-drifts cumulate in multiple paths simultaneously
• Pre-push suite cycle-time × #push-cycles becomes the dominant wallclock position
• Domain decisions must be made retroactively for 4 weeks of work

This maxim is the cost-warning variant of the maxim "code review must become standard". It prevents another large backlog from forming next time because the pre-push-hook warnings are "only a warning".

When to use

Trigger thresholds (≥1 sufficient):

• ≥7 days since last code review on this repo
• ≥30 atomic commits since last review (git log <last-review-sha>..HEAD --oneline | wc -l)
• ≥5000 LoC diff (git diff <last-review-sha> HEAD --stat | tail -1)
• ≥2 consecutive pre-push code-review hook bypasses (bypass multiplication)

Trigger phrases (user or you):

• "we haven't done a review in weeks"
• "just push this"
• "the hook is only a warning, can be ignored"
• "it's just a small fix on top"
• "we'll do an aggregate review later"
• "let's first finish the feature"

High-risk markers (additional amplifiers):

• Multiple critical paths / DB migrations / ML models touched simultaneously
• Multiple domain decisions flowed in without test-backing
• Pre-push-hook has fired ≥3x since last review (accumulated risk)

When NOT to use

• Fresh branch (≤3 commits, ≤500 LoC, ≤2 days) — backlog not yet built up
• Explicit WIP push from user ("just push, I'll review later at merge")
• During a requesting-code-review call — you're reviewing right now, would warn yourself
• One-line typo fixes / pure documentation commits
• Hotfix pressure (live outage, trade-stop) — then "push first, review after" is the correct reflex, but document that a follow-up review is required

The 4-Step Warning Flow

Step 1 — Measure backlog size (don't guess)

# When was the last code-review push?
git log --grep="code-review\|code review\|CR-[A-Z][0-9]" --oneline -5
# Or: last PR-merge after review
git log --first-parent main --oneline -10

# Backlog size from that point
LAST=<sha-of-last-reviewed-commit>
git log $LAST..HEAD --oneline | wc -l         # #commits
git diff $LAST HEAD --shortstat               # LoC + files
git log $LAST..HEAD --since="7 days ago" --oneline | wc -l  # 7d rate

Write the 3 numbers explicitly: commits / LoC / days.

Step 2 — Cost-estimation against threshold table

Step 3 — Warn user explicitly (don't silently work)

Mandatory output before any code is written:

⚠️ Code-Review Backlog Warning

Status: <N> commits since <SHA-short> (<K> days ago)
        <M> LoC diff, <T> files touched
        Pre-push hook bypassed X times since <date>

Expected cleanup cost (see `code-review-backlog-cost-warning`):
- Wallclock: ~<hours>
- Token budget: ~$<estimate>
- Re-review cycles likely (bug-finding rate at 4-week backlog: ~3 of 6 phases)

Proposal:
  Option A — `code-review-chunk-dispatch` (N parallel subagents, ~1-2h)
  Option B — Continue push + pain later ($50+, 5h+, 2 sessions)

Maxim: "Code review must become standard"
Maxim: "...$50 burned..."

Step 4 — Wait for user decision

Do not simply push. Do not simply start chunk review. The user chooses — they have budget awareness, you have only the cost estimate.

If the user chooses Option B: document the choice in Daily Note ("User read warning + consciously pushed, follow-up review scheduled for …").

Quick Reference

Anti-Patterns (what happens when you ignore this)

Cost of Skipping (real)

User quote:

"The 'cleanup work' this morning consumed the complete token-limit of two sessions plus additional tokens for $50. That's what happens when you leave things sitting too long."

Concrete:

• 74 commits over 4 weeks → 5h wallclock + $50 tokens + 21 repair commits + 3 re-review cycles
• 8 push cycles × 9min pre-push suite = 72min just for push wallclock
• 5 Critical findings + 25 Important findings all live-relevant
• 6 implementation phases because thematically not separable after the 4-week mix

With daily review (maxim): ~10min × 28 days = 4.5h total instead of 5h-in-one-session + $50.

Red Flags — STOP and warn

• "just a small change on top"
• "the hook is only a warning"
• "we'll do it next week in a block"
• "I'll just push, review at merge"
• "4 weeks isn't that long"

All mean: issue user warning, show cost estimate, propose chunked dispatch as default.

Cross-References

• REQUIRED COMPLEMENT: superpowers:requesting-code-review (the review action itself)
• REQUIRED COMPLEMENT: code-review-chunk-dispatch (for >30-commit backlogs)
• Maxim: pre-push-bypass-audit-trail (for hook-bypass logging)
• Source lesson: .remember/core-memories.md § "Code-review backlog becomes more expensive than daily review"

Background: TDD progression (Bulletproofing log)

Cycle 1 — PASS, moderate value-add

• RED subagent (without skill, scenario "45 commits since recent date, 6,200 LoC, user wants to push with --no-verify"): reacted surprisingly well — refused the push, cited CLAUDE.md maxim ("Code review must become standard") + similar existing skills (code-review-chunk-dispatch, pre-push-bypass-audit-trail). But: unstructured, no concrete cost table, no quantitative bug-cost estimate. Self-critique listed 6 missing points (no quantification, no audit-trail mechanic, "tonight feature" not addressed emotionally, no Option B, counter-thesis check skipped).

• GREEN subagent (with skill): structured output with threshold table (3 of 4 thresholds simultaneously exceeded), mandatory-output block 1:1 from skill template, cost estimation wallclock+token+re-review cycles, explicit Option A (chunk-dispatch now, ~1.5-2h) vs Option B (push + audit-trail-doc + follow-up appointment), clear "Which option?"-stop per Step 4 — no preemptive action.

• Anti-pattern avoided: GREEN explicitly noted that without skill the response would have been "OK, I'll push with --no-verify and you'll review tomorrow" → bypass-multiplication that led to the painful cleanup session.

• R0 (no refactor applied): skill delivered all core steps correctly. Polish items documented as Cycle-2-Backlog (see below).

Cycle-2-Backlog (Polish, non-blocking)

1. Bypass multiplication: differentiate levels: 1st bypass = warning enough; 2nd bypass = escalation. Currently the skill reads as if multiplication is already underway at the 1st bypass case.
2. "Feature-start pressure" as an explicit When-NOT clause or its own sub-trigger alongside hotfix pressure. Currently you have to categorize it as a variant of "first finish feature" — the subagent did that, but an explicit line would be more robust.
3. Chunk-axis mini-hint for Step-4 transition ("typical chunk axes: thematic / per-dir / per-file-type / per-domain") — even though the real chunk skill is linked, an inline hint simplifies the transition.
4. Daily-note template for Option-B doc: currently only "document the choice", no concrete format. A 2-line template would standardize the audit trail.