After every build, a risk-tiered review issues PASS or FAIL — FAIL triggers a tier-ordered fix pass and a mandatory re-review, and the loop exits only when a post-fix review returns PASS.

Pattern

Review Fix Closed Loop

The shape

It's a loop, not a pipeline.

Build

/implement

artifacts in place

→

Review

/code-review

tiered findings

PASS or FAIL

→

PASS→

Exit

/pull_request

FAIL→

Fix

/fix

↺ on FAIL: /fix writes report → /code-review runs again → repeat until PASS

A linear pipeline with an optional review isn't this pattern. The loop's defining property is that FAIL cannot reach /pull_request.

The verdict

Four tiers. Only two of them can fail the build.

BLOCKER

Security vuln, data-loss risk, broken core flow, unmet requirement

structural — by definition

any → FAIL

no exceptions

HIGH

Logic error likely in prod; missing error handling for common cases

2 unack → FAIL

else allowed

MEDIUM

Quality debt; test gaps for important paths

no verdict impact

LOW

Style, naming, nice-to-have

no verdict impact

PASS requires: zero BLOCKERs AND ( zero or acknowledged HIGH). Any BLOCKER means FAIL — /fix is not optional.

Why tier order isn't cosmetic

A MEDIUM fix before the BLOCKER masks what you were supposed to fix.

Arbitrary orderBLOCKER obscured

1LOWrename variable in auth.py

2MEDIUMadd missing test in auth.py

3BLOCKERauth bypass — now in file edited twice

Root cause hidden under churn. Diff against the original review is polluted. Was the bypass resolved, or just moved? Re-review can't tell cleanly.

Tier orderfoundation first

1BLOCKERfix auth bypass · verify

2HIGHadd error handling · verify

3MEDIUMadd test · verify

4LOWrename variable

Each tier verified before the next begins. Foundational issues resolved before style touches the file. Re-review reads cleanly against the build.

Why re-review is mandatory

The PASS you want is on the post-fix artifact — not the pre-fix one.

01 · REGRESSION

A fix can introduce a new bug

The original review didn't see the fix. Only the re-review reads the code as it actually is after /fix touched it.

02 · PARTIAL FIX

"Fixed" in the fix report ≠ fixed in code

The reviewer reads the code, not the fix report. A finding marked resolved can still fail a fresh read.

03 · STALE VERDICT

PASS issued before /fix is invalid

A verdict attaches to a specific artifact state. Once /fix mutates the artifact, the old verdict no longer applies.

Skip re-review and the loop degrades into a pipeline with an unverified final step — the failure mode the pattern exists to prevent.

The audit trail

Timestamped reports. Nothing overwritten.

app_review/ + app_fix_reports/

iteration history

#1review_20260416_0912.mdFAIL

#2fix_20260416_0931.mdFIXED

#3review_20260416_0944.mdFAIL

#4fix_20260416_1002.mdFIXED

#5review_20260416_1017.mdPASS

Timestamps let N cycles coexist. A second review doesn't clobber the first — the loop's iteration history is preserved for post-hoc inspection.

The discipline

A review that can't block the PR is documentation. A fix that isn't re-reviewed is a claim.

The pattern is the closed loop — FAIL structurally triggers /fix, /fix structurally triggers re-review, and /pull_request is only reachable through a PASS verdict on the post-fix artifact. Remove any of those edges and you don't have this pattern; you have a pipeline that hopes.