step5-review-gate

Step 5: Review & Audit Gate

Pipeline: Step 5 of 5 (Session 3 — Review & Audit)
When: After completeness sweep passes (Step 4), in a fresh agent session
Model suggestion: Claude or Gemini — best at independent critical analysis and drift detection
Verdict: PASS (ship it) or FAIL (lockout — fix and re-review)

Replace <YOUR-HARDENED-PLAN> with your hardened plan filename.

---

Read these files first:

1. docs/plans/AI-Plan-Hardening-Runbook.md (Section 6.2 + Drift Detection Prompt)
2. docs/plans/.md
3. .github/copilot-instructions.md
4. .github/instructions/ (relevant guardrail files for this phase)
5. docs/plans/DEPLOYMENT-ROADMAP.md

Now act as a REVIEWER GATE + DRIFT DETECTION AGENT.

You are an independent quality gate. You should be a different session from the one that wrote the code.

Pre-review context check:

• Check OpenBrain (if configured): search_thoughts("<plan topic> review", project: "<YOUR PROJECT NAME>") — load prior review findings, recurring issues, and known patterns
• Check LiveGuard memories: Read .forge/liveguard-memories.jsonl if present — recent drift violations and incidents may flag known problem areas

--- PART A: CODE REVIEW ---

Review checklist:

1. SCOPE COMPLIANCE — All changes within the Scope Contract?
2. FORBIDDEN ACTIONS — Off-limits files/folders touched?
3. ARCHITECTURE — Code follows layer separation?
4. ERROR HANDLING — Proper error types, no empty catch blocks?
5. NAMING — Follows project naming conventions?
6. PATTERNS — Follows existing patterns from .github/instructions/?
7. TESTING — New features covered by tests?
8. SECURITY — Input validation? No secrets in code?
9. SHARED CONTRACT — If the plan has a "## Shared Contract" section: does the code use exactly the types, names, signatures, routes and conventions it pins? Two slices defining the same thing differently is 🔴 Critical, even if each slice's own gate passed.
10. DESIGN CONTEXT — Verify affected slices' Contract Refs, Decision Refs and Language Ref, exact revisions and approval evidence. Flag missing or stale consequential approval; neither an agent proposal nor a provenance tag counts as acceptance.
11. DOMAIN LANGUAGE — Check the Domain Language meanings, bounded contexts, invariants and allowed aliases across specification, APIs, code and tests. Do not globally rename unrelated contexts or infer new business meanings.
12. DEEP MODULES — Deep modules hide coherent complexity behind a usable interface. Check what callers no longer need to know; preserve legitimate thin adapters, single responsibility and module-size gates. More files, wrappers, or lower LOC alone are not design improvement.

These are agent-side checks, not runtime enforcement. Current execution and lock-hash coverage are unchanged. For unchanged legacy boundaries, inspect existing approved sources rather than invent IDs or approvals.

Missing or stale approval for a consequential change is a blocking verification gap: withhold PASS until resolved, without inventing a technical defect to represent missing evidence.

For each finding, assign: 🔴 Critical / 🟡 Warning / 🔵 Info

Output Part A:

#	File	Finding	Severity	Rule Violated

--- PART B: DRIFT DETECTION ---

Compare Scope Contract against actual changes:

1. SCOPE CREEP — Work not in Scope Contract?
2. UNPLANNED FILES — Files not in any Execution Slice?
3. NON-GOAL VIOLATIONS — Work contradicting Out of Scope?
4. FORBIDDEN ACTIONS — Off-limits touched?
5. ARCHITECTURAL DRIFT — Patterns conflicting with instructions?

Output Part B:

File	Issue	Violated Section