Architecture Review Full

Codex compatibility note:

• Invoke repository skills with $skill-name in Codex; this mirrored copy rewrites legacy Claude /skill-name references.
• Task tracker mandate: BEFORE executing any workflow or skill step, create/update task tracking for all steps and keep it synchronized as progress changes.
• User-question prompts mean to ask the user directly in Codex.
• Ignore Claude-specific mode-switch instructions when they appear.
• Strict execution contract: when a user explicitly invokes a skill, execute that skill protocol as written.
• Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required spawn_agent subagent(s) for that task.
• Do not skip, reorder, or merge protocol steps unless the user explicitly approves the deviation first.
• For workflow skills, execute each listed child-skill step explicitly and report step-by-step evidence.
• If a required step/tool cannot run in this environment, stop and ask the user before adapting.

Codex Project-Reference Loading (No Hooks)

Codex uses static project-reference loading instead of runtime-injected project docs. When coding, planning, debugging, testing, or reviewing, open project docs explicitly using this routing.

Always read:

• docs/project-config.json (project-specific paths, commands, modules, and workflow/test settings)
• docs/project-reference/docs-index-reference.md (routes to the full docs/project-reference/* catalog)
• docs/project-reference/lessons.md (always-on guardrails and anti-patterns)

Missing/stale context route: If docs/project-config.json, the docs index, lessons.md, CLAUDE.md, AGENTS.md, or any task-required reference doc is missing or stale, auto-run $project-init or the narrow setup route ($project-config, $docs-init, $scan-all, $scan --target=<key>, $claude-md-init) before ordinary project-specific work. If Codex mirrors or AGENTS.md are missing/stale, ask the user to run $sync-codex; do not auto-run it.

Situation-based docs:

• Project structure/architecture/tech-stack/deployment/setup (any layer — backend, frontend, or infra): project-structure-reference.md
• Backend/CQRS/API/domain/entity changes: backend-patterns-reference.md, domain-entities-reference.md
• Frontend/UI/styling/design-system: frontend-patterns-reference.md, scss-styling-guide.md, design-system/README.md
• Spec authoring, docs/specs/ pathing, or TC format: feature-spec-reference.md, spec-system-reference.md, spec-principles.md
• Behavior/public-contract changes or spec-test-code sync: workflow-spec-test-code-cycle-reference.md plus the spec docs above
• Derived spec indexes/ERDs/reimplementation guides: spec-system-reference.md and source Feature Specs under docs/specs/
• Integration test implementation/review: integration-test-reference.md
• E2E test implementation/review: e2e-test-reference.md
• Code review/audit work: code-review-rules.md plus domain docs above based on changed files

Do not read all docs blindly. Start from docs-index-reference.md, then open only relevant files for the task.

[BLOCKING] Execute skill steps in declared order. NEVER skip, reorder, or merge steps without explicit user approval. [BLOCKING] Before each step or sub-skill call, update task tracking: set in_progress when step starts, set completed when step ends. [BLOCKING] Every completed/skipped step MUST include brief evidence or explicit skip reason. [BLOCKING] If Task tools are unavailable, create and maintain an equivalent step-by-step plan tracker with the same status transitions.

Quick Summary

Goal: Audit the WHOLE project's architecture, scalability posture, and production readiness in ONE pass by orchestrating the three deliberately-non-overlapping sibling reviewers, then de-duplicating their intentional cross-references into ONE consolidated Architecture Health Report — this skill is a THIN orchestrator, it does NOT re-implement any of the three reviews.

Summary:

• Purpose: resolve scope once, fan three reviewers out as parallel read-only sub-agents behind an all-return barrier, PROGRESSIVELY synthesize + dedup each child's findings into ONE report file (status IN PROGRESS → FINISHED), run a $why-review fix gate that walks each review face, then finalize the combined verdict. Read-only until findings are validated — fixes route to a downstream $plan or feature flow.
• The three children — deliberately non-overlapping siblings that cross-reference each other, so their findings MUST be deduped:
  • architecture-scalability-review (subagent architect) — project-grading scorecard /20 + pass/fail gates. ALWAYS grades the project, even under diff scope (project-grader by design, "not the every-change diff reviewer").
  • architecture-review (subagent architect) — diff/scope-scoped 13-category PASS/WARN/BLOCKED compliance. Its Category 11 delegates full scalability/coupling grading to architecture-scalability-review.
  • production-readiness-review (subagent code-reviewer) — service/API SRE /24 + 8-item Extended SRE Readiness gate. architecture-scalability-review routes runtime readiness here.
• This skill runs INLINE in the main session because it spawns sub-agents; the three children are each 25k–34k tokens and CANNOT run inline together — they MUST be sub-agents.
• Dedup is the core value. Because the three siblings intentionally cross-reference each other, the same underlying issue surfaces from multiple angles; record it ONCE citing every source, preserve each child's route-to-sibling pointers. — why: undeduped, three intentionally-cross-referencing reviewers inflate severity counts and bury distinct issues.
• Coverage sweep + self-audit are orchestrator-only duties (Step 4). After Faces merged: 3/3, sweep the merged report against the design-review script (architecture-knowledge.md §20.2) and record every unanswered question as an INFO Coverage gap line; frame remaining risk against the five judgments (§20.4); then run the 11 thinking red flags (§20.3) across the merged findings before Step 5. — why: three correctly-in-lane reviewers cannot see a question that belongs to no lane, and synthesis is where their confirmation biases compound.

Workflow:

1. Step 1: Resolve Scope — $ARGUMENTS or ask the user directly; map the chosen scope to each child's args.
2. Step 2: Load Project Reference Docs Once — warm shared context before fan-out.
3. Step 3: Parallel Fan-Out (all-return barrier) — spawn all three read-only sub-agents in ONE message; advance only after ALL three return.
4. Step 4: Progressive Synthesis (IN PROGRESS) — open the ONE consolidated report at status 🚧 IN PROGRESS when fan-out starts; merge + dedup each child's findings into it AS that child returns — never held in memory to the end; then run the §20.2 coverage sweep and the §20.3 self-audit over the merged set.
5. Step 5: Fix-Report-Per-Review $why-review Gate — ONE merged $why-review pass that walks each of the three review faces + the dedup and fixes the report in place (severities, false positives, dedup-dropped issues).
6. Step 6: Finalize (FINISHED) — lock the combined verdict (worst-case rollup) and flip the report status to ✅ FINISHED.
7. Next Steps — ask the user directly: $plan (fix validated findings) / $code-simplifier / skip.

Key Rules (top 3 critical first):

• MUST ATTENTION this is a THIN orchestrator — NEVER re-implement any of the three reviews inline; fan them out as sub-agents and synthesize.
• MUST ATTENTION dedup the intentional overlaps — one underlying issue = one finding citing every reporting child; NEVER let cross-referencing siblings triple-count it.
• MUST ATTENTION read-only until validated — run the Step 5 $why-review gate before handoff; fixes route to a downstream $plan/feature flow, NEVER applied here.
• Spawn all three sub-agents in ONE message and honor the all-return barrier — advance only after every child returns (SYNC:parallel-phase-advancement discipline).
• Write the consolidated report to plans/reports/architecture-full-review-{YYMMDD}-{HHmm}-{slug}.md.

Your Mission

Review Mindset (NON-NEGOTIABLE)

Skeptical synthesizer. Judge the three children's reports; do not re-derive them.

• Trust each child's file:line evidence, but NEVER inflate severity by counting the same underlying issue three times — dedup first, then rank.
• A finding survives to the report only after the Step 5 $why-review gate; an unvalidated sub-agent claim is a hypothesis, not a finding.
• Preserve every route-to-sibling pointer a child emits — the combined report is the union of owned findings, not a re-review.

Step 1: Resolve Scope (ASK EACH RUN)

Decide audit scope, then map to each child's arguments.

• If $ARGUMENTS names files/dirs, or contains full / whole / diff / changes, use that directly.
• Else ask the user directly:
  • "Whole project (Recommended)" — audit the entire repository.
  • "Current changes (diff)" — audit the uncommitted diff only.
  • "Specific path" — audit a named service/module/directory.

Scope → child args mapping:

MUST ATTENTION — architecture-scalability-review always grades the PROJECT, even under diff scope. A project-grader by design ("do not use as the every-change diff reviewer"). Under diff scope it still emits the /20 scorecard, focused on the services/modules the diff touches — it never degrades into a pure per-line diff reviewer. Document this nuance in the consolidated report so its scorecard is read as a project posture, not a diff verdict.

Step 2: Load Project Reference Docs Once

Warm shared context BEFORE fan-out so synthesis reasons from the same ground truth the children use. Read once here (each child re-reads what it needs via its own tool calls):

• docs/project-config.json
• docs/project-reference/project-structure-reference.md
• docs/project-reference/backend-patterns-reference.md
• docs/project-reference/frontend-patterns-reference.md
• docs/project-reference/code-review-rules.md
• Accepted ADRs under docs/adr/**, when present

Step 3: Parallel Fan-Out (ALL-RETURN BARRIER)

Spawn ALL THREE sub-agents in ONE message. Read-only and independent — no shared mutable state, no ordering dependency. Advance ONLY after EVERY member returns (SYNC:parallel-phase-advancement).

Each sub-agent writes its FULL report to plans/reports/ and returns ONLY the SYNC:subagent-return-contract summary (≤10 finding bullets + report path) — NEVER its full report inline.

Each sub-agent prompt states: READ-ONLY findings/score mode (no fixes); re-read all target files from scratch via its own tool calls; write full report incrementally to plans/reports/; return only the return-contract summary.

Each of the three faces feeds TWO validation gates downstream — state this in each sub-agent's prompt so it knows its findings will be adversarially validated, not trusted as-is: (1) the Step 5 fix-report-per-review $why-review gate that walks its face and fixes its findings in the consolidated report; (2) inside workflow-architecture-audit, the workflow-level FINAL $why-review gate that re-reviews the whole finalized report. A face's findings are hypotheses until they survive both — so every finding it emits MUST carry file:line proof + confidence that can withstand validation.

Step 4: Progressive Synthesis → One Report (status IN PROGRESS)

Exactly ONE report file for the whole audit — created ONCE, grown across Steps 4→6, never re-created per review. Open it when fan-out starts and evolve its status through its lifecycle: 🚧 IN PROGRESS (Step 4) → 🔍 VALIDATING (Step 5) → ✅ FINISHED (Step 6).

Write to plans/reports/architecture-full-review-{YYMMDD}-{HHmm}-{slug}.md.

On fan-out start — create the file with status 🚧 IN PROGRESS and a status line naming which of the three review faces have returned so far (e.g. Faces merged: 0/3). The single source of truth the whole audit synthesizes into — do NOT hold findings in memory until the end.

Header — all three sub-scores + ONE combined verdict (each sub-score is ⏳ pending until its face returns):

• Scalability Scorecard: X/20 + verdict (STRONG / NEEDS WORK / HIGH RISK)
• Architecture Compliance: PASS / WARN / BLOCKED
• SRE Readiness: X/24 + verdict (PASS / NEEDS WORK / NOT READY)
• Combined Verdict: ⏳ pending until FINISHED — computed in Step 6 as the worst-case rollup across the three (any BLOCKED / NOT READY / HIGH RISK dominates). Do NOT assert a combined verdict while status is IN PROGRESS.

Merge each face AS it returns. All three run behind the Step 3 all-return barrier, so all three summaries are in hand before synthesis — but merge them into the file one face at a time (updating Faces merged: N/3 each time) so a mid-synthesis context loss leaves the partial report on disk, not in memory. When ≥2 children report the same underlying issue, record it ONCE, citing every source. Dedup on these KNOWN overlap axes (the siblings cross-reference each other here by design):

For each merged finding: assign ONE severity per SYNC:severity-rubric (do not sum severities across duplicate reports), cite each reporting child's file:line, and PRESERVE each child's route-to-sibling pointers. — why: undeduped, three intentionally-cross-referencing reviewers inflate severity counts and bury distinct issues.

Merged advisory Technique Applicability Matrix (does NOT change the combined verdict): all three children emit a scale-tier Technique Applicability Matrix from SYNC:scale-technique-gate; dedup the three views of the same technique onto ONE advisory matrix in the consolidated report. Pin ONE authoritative scale tier for the merged matrix — architecture-scalability-review's derived tier is canonical (owns scalability grading); if another child's derived tier DIVERGES, record the divergence as a one-line note and key the merged matrix's tier-warranted? column to the pinned tier, rather than merging contradictory warranted-sets. This only SELECTS which already-derived tier the matrix is keyed to — it does NOT re-derive any child's findings (respecting "you do not re-derive them" above). It is advisory/INFO only — a MISSING-WARRANTED technique is guidance, never a severity, and NEVER feeds the worst-case combined-verdict rollup. This orchestrator adds no own gate marker; the matrix is inherited from the children.

Merged advisory Scenario Stress Matrix (does NOT change the combined verdict): the same three children each emit a Scenario Stress Matrix from SYNC:scenario-stress-eval (top-down: big-traffic / big-data / dependency-failure / node-loss / data-corruption / self-heal survival vs. business need). Dedup the three views of the same scenario onto ONE advisory matrix in the consolidated report, exactly as for the technique matrix. Pin ONE authoritative scale tier AND business-criticality read — architecture-scalability-review's derived T-tier + B-tier is canonical (owns scalability grading); if another child's derived tier/criticality DIVERGES, record it as a one-line note and key the merged matrix to the pinned values, rather than merging contradictory in-scope sets. This only SELECTS which already-derived tier/criticality the matrix is keyed to — it does NOT re-derive any child's scenario findings. It is advisory/INFO only — a FAILS-HARD or OVER-HARDENED scenario is guidance, never a severity, and NEVER feeds the worst-case combined-verdict rollup. The criticality-signal floor and anti-over-engineering guard live in the children's matrices; this orchestrator adds no own gate marker and inherits the matrix from the children.

Completeness lens over the merged set (orchestrator-only — the children cannot see across faces). Once Faces merged: 3/3, sweep the merged report against the design-review script in .claude/docs/architecture-knowledge.md §20.2 and record any question NO face answered as an explicit Coverage gap: {question} — not covered by any face line. Frame each remaining risk against the five judgments in §20.4 — when to add complexity · when to split · when consistency can be relaxed · when to buy vs build · when GOOD ENOUGH is correct — so the consolidated report tells the reader which JUDGMENT is at stake, not only which rule was broken. A coverage gap is an INFO note, never a severity, and NEVER feeds the combined-verdict rollup. — why: three scoped reviewers each correctly stay in lane, so a question that belongs to no lane is invisible to every one of them and only this orchestrator can see it.

Self-audit the merged report (MANDATORY before Step 5): run the 11 thinking red flags in §20.3 across the merged findings — especially a recommendation whose SACRIFICE is unnamed, "best practice" with no named forces, and a scale claim with no evidence. Any hit is demoted or removed here, not passed to $why-review as ground truth. — why: the orchestrator's synthesis is where three children's confirmation biases compound into one authoritative-sounding report.

Step 4 ends only when Faces merged: 3/3 — all three sub-scores are populated, the §20.2 coverage sweep is recorded, and every finding is on disk.

Step 5: Fix-Report-Per-Review $why-review Gate (status VALIDATING) — MANDATORY when findings exist

Flip the report status to 🔍 VALIDATING, then run ONE merged $why-review pass that WALKS EACH of the three review faces (one merged pass, NOT three per-face passes — a single invocation is strictly more thorough because it also validates the cross-face dedup separate per-face passes cannot see). The "fix report after each review" gate: every face's findings are validated, the report fixed IN PLACE.

1. Read the consolidated report from plans/reports/architecture-full-review-{date}-{slug}.md.
2. Invoke $why-review with: validate findings in {report-path} — WALK EACH review face (architecture-scalability-review, architecture-review, production-readiness-review) in turn: for each face verify every finding it contributed has file:line proof and a correctly-classified severity, steel-man each rejected interpretation; THEN validate the cross-face dedup did not drop or merge-away a distinct issue.
3. $why-review demotes/removes any finding → FIX the report in place: revise severities, remove false positives, restore any distinct issue the dedup wrongly collapsed, and add a ## Why-Review Fix Notes section listing per-face what changed + why.
4. $why-review confirms all findings → append ## Why-Review Validation stating "All N merged findings re-validated across 3 faces; no severity changes."

Skip ONLY on an unconditional zero-finding PASS across all three children (log the skip reason, then proceed to Step 6 to finalize the clean PASS).

Step 6: Finalize (status FINISHED)

The report is now validated — lock it and hand off a stable artifact.

1. Compute the Combined Verdict as the worst-case rollup across the three now-validated sub-scores (any BLOCKED / NOT READY / HIGH RISK dominates); write it into the header, replacing the ⏳ pending placeholder.
2. Flip the report status from 🔍 VALIDATING to ✅ FINISHED and append a ## Finalization block: the three sub-scores, the combined verdict, the total validated finding count by severity, and the Faces merged: 3/3 confirmation.
3. This finalized report is the single deliverable the downstream workflow-level $why-review step and docs-update consume. Do NOT emit a second report file or re-synthesize — one file, finalized once.

Two-tier validation (why this skill runs $why-review AND the workflow adds a why-review step): Step 5 here is the FINDING-level, per-face fix that also protects standalone use of this skill. The workflow-level why-review step that follows is the REPORT-level final gate over the finalized artifact (verdict-rollup correctness, dedup completeness, cross-review severity consistency) and the machine-visible guarantee in the rendered sequence. Distinct altitudes; do not collapse one into the other.

Next Steps

MANDATORY — NO EXCEPTIONS: After completing, use ask the user directly to present:

• "$plan (fix validated findings)" (Recommended) — plan the fixes for the validated findings (fixes happen in the downstream plan/feature flow, NOT here).
• "$code-simplifier" — simplify and refine implicated code.
• "Skip, continue manually" — user decides.

Read-only until validated. This skill produces findings and a verdict only. Applies NO fixes — every validated finding routes to a downstream $plan or feature-implementation flow that owns the change.

[IMPORTANT] Use task tracking to break ALL work into small tasks BEFORE starting. For simple tasks, ask the user whether to skip.

External Memory: Complex/lengthy work → write intermediate findings + final results to plans/reports/ — prevents context loss, serves as deliverable.

Evidence Gate: MANDATORY — every claim, finding, recommendation requires file:line proof or traced evidence with confidence percentage (>80% to act, <80% verify first).

Graph-Assisted Investigation — MANDATORY when .code-graph/graph.db exists.

HARD-GATE: MUST ATTENTION run at least ONE graph command on key files before concluding any investigation.

Pattern: Grep finds files → trace --direction both reveals full system flow → Grep verifies details

Task	Minimum Graph Action
Investigation/Scout	trace --direction both on 2-3 entry files
Fix/Debug	callers_of on buggy function + tests_for
Feature/Enhancement	connections on files to be modified
Code Review	tests_for on changed functions
Blast Radius	trace --direction downstream

CLI: python .claude/scripts/code_graph {command} --json. Use --node-mode file first (10-30x less noise), then --node-mode function for detail.

Sub-Agent Return Contract — When this skill spawns a sub-agent, the sub-agent MUST return ONLY this structure. Main agent reads only this summary — NEVER requests full sub-agent output inline.

## Sub-Agent Result: [skill-name]

Status: ✅ PASS | ⚠️ PARTIAL | ❌ FAIL
Confidence: [0-100]%

### Findings (Critical/High only — max 10 bullets)

- [severity] [file:line] [finding]

### Actions Taken

- [file changed] [what changed]

### Blockers (if any)

- [blocker description]

Full report: plans/reports/[skill-name]-[date]-[slug].md

Main agent reads Full report file ONLY when: (a) resolving a specific blocker, or (b) building a fix plan. Sub-agent writes full report incrementally (per SYNC:incremental-persistence) — not held in memory.

Context budget — the return payload is a SUMMARY, not a transcript: ≤10 finding bullets, no raw file contents / full diffs / verbatim logs inline, no re-pasted source. Everything beyond the summary lives in the Full report on disk. A sub-agent that would exceed the summary shape MUST write the detail to its report and return only the pointer — the orchestrator's context is the scarce resource the whole map-reduce protects.

Nested Task Expansion Contract — For workflow-step invocation, the [Workflow] ... row is only a parent container; the child skill still creates visible phase tasks.

1. Call the current task list first. If a matching active parent workflow row exists, set nested=true and record parentTaskId; otherwise run standalone.
2. Create one task per declared phase before phase work. When nested, prefix subjects [N.M] $skill-name — phase.
3. When nested, link the parent with TaskUpdate(parentTaskId, addBlockedBy: [childIds]).
4. Orchestrators must pre-expand a child skill's phase list and link the workflow row before invoking that child skill or sub-agent.
5. Mark exactly one child in_progress before work and completed immediately after evidence is written.
6. Complete the parent only after all child tasks are completed or explicitly cancelled with reason.

Blocked until: the current task list done, child phases created, parent linked when nested, first child marked in_progress.

Project Reference Docs Gate — Run after task-tracking bootstrap and before target/source file reads, grep, edits, or analysis. Project docs override generic framework assumptions.

1. Identify scope: file types, domain area, and operation.
2. Read docs/project-config.json first — the project's machine-readable map. It is the single source of truth for THIS repo (modules/paths, framework + search keywords, test/E2E/integration run-commands, design system, architecture rules, workflow patterns); ground exact paths, run-commands, and conventions on it before investigating, planning, or coding — never assume framework defaults (CLAUDE.md + reference docs are derived from it). If it — or the docs index, lessons.md, CLAUDE.md, AGENTS.md, or any required reference doc — is missing or stale, auto-run $project-init or the narrow route ($project-config, $docs-init, $scan-all, $scan --target=<key>, $claude-md-init) first; if Codex mirrors or AGENTS.md are stale, ask the user to run $sync-codex (never auto-run it).
3. Required docs by trigger: always docs/project-reference/lessons.md; doc lookup docs-index-reference.md; review code-review-rules.md; backend/CQRS/API backend-patterns-reference.md; domain/entity domain-entities-reference.md; frontend/UI frontend-patterns-reference.md; styles/design scss-styling-guide.md + design-system/design-system-canonical.md; integration tests integration-test-reference.md; E2E e2e-test-reference.md; feature docs/specs feature-spec-reference.md + spec-system-reference.md + spec-principles.md; behavior/public-contract/spec-test-code sync workflow-spec-test-code-cycle-reference.md; derived spec index/ERD/reimplementation guides spec-system-reference.md + source Feature Specs under docs/specs/; architecture/new area project-structure-reference.md.
4. Read every required doc, then before target work state: Reference docs read: ... | Not applicable: ....

Ready when: scope evaluated, docs/project-config.json consulted, required docs checked/read or setup route completed, lessons.md confirmed, citation emitted.

Task Tracking & External Report Persistence — Bootstrap this before execution; then run project-reference doc prefetch before target/source work.

1. Create a small task breakdown before target file reads, grep, edits, or analysis. On context loss, inspect the current task list first.
2. Mark one task in_progress before work and completed immediately after evidence; never batch transitions.
3. For plan/review work, create plans/reports/{skill}-{YYMMDD}-{HHmm}-{slug}.md before first finding.
4. Append findings after each file/section/decision and synthesize from the report file at the end.
5. Final output cites Full report: plans/reports/{filename}.

Blocked until: task breakdown exists, report path declared for plan/review work, first finding persisted before the next finding.

Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.

Evidence-Based Reasoning — Speculation is FORBIDDEN. Every claim needs proof.

1. Cite file:line, grep results, or framework docs for EVERY claim
2. Declare confidence: >80% act freely, 60-80% verify first, <60% DO NOT recommend
3. Cross-service validation required for architectural changes
4. "I don't have enough evidence" is valid and expected output

BLOCKED until: - [ ] Evidence file path (file:line) - [ ] Grep search performed - [ ] 3+ similar patterns found - [ ] Confidence level stated

Forbidden without proof: "obviously", "I think", "should be", "probably", "this is because" If incomplete → output: "Insufficient evidence. Verified: [...]. Not verified: [...]."

Validated-Finding Fix + Full Re-Review Loop — Re-review is triggered by a validated finding fix cycle, not by a round number. Review purpose: review → validate findings → fix validated findings → full re-review until a complete review pass clears the round's exit bar (see Severity floor below). A clean review ENDS the loop — no further rounds required.

aka Self-Review Convergence Loop. The name is historical — there is NO 2-round cap; "double-round-trip" only means a validated-finding fix cycle forces at least one fresh re-review. It runs until a clean pass, bounded by the 3-round ceiling below.

Round cap — 3 rounds MAX (a ceiling, NEVER a target). A clean pass ENDS the loop immediately at ANY round — round 1 included; the cap never obliges you to keep spinning. Hitting round 3 with blocking findings still open (severity floor applied) → STOP and escalate by asking the user directly with the still-open findings listed; NEVER emit a silent "good enough" PASS on cap exhaustion, and NEVER let the cap substitute for the clean-review requirement. The 2-repeated-no-progress blocker rule stays an EARLIER exit — escalate at whichever trips first.

Severity floor — from round 3, LOW stops blocking. The exit bar tightens by round, so the loop converges on consequence instead of spinning on polish:

Define one predicate everywhere: blocking_findings(round, findings) returns all validated findings in rounds 1–2 and only validated CRITICAL/HIGH/MEDIUM findings in round 3+. A binary gate (test-green, security must-fix, required artifact) is exempt only when its owning invariant explicitly says so.

Round	Exit bar — loop ENDS when the fresh full review has…	Must be fixed to continue
1-2	zero validated findings at ANY severity	CRITICAL · HIGH · MEDIUM · LOW
3+	zero validated CRITICAL / HIGH / MEDIUM findings — LOW-only is a PASS	CRITICAL · HIGH · MEDIUM only

From round 3 onward LOW findings are NOT required to be fixed: a round whose validated findings are ALL LOW ENDS the loop immediately — do not open another round for them. Severity tiers are SYNC:severity-rubric (CRITICAL block-merge · HIGH must-fix · MEDIUM should-fix · LOW nice-to-fix); rounds 1-2 are unchanged, so an easy LOW still gets fixed early when it is cheap.

Severity-floor rules:

• Never silently drop a deferred LOW. Every unfixed LOW is listed in the final report under ## Deferred LOW Findings (severity floor, round ≥3) with file, line, and description, so the owner can schedule it. Dropping it from the report is a protocol violation, not a clean pass.
• Never re-tier a finding to trigger the exit. Downgrading a real CRITICAL/HIGH/MEDIUM to LOW so the loop can end is a FALSE PASS. Severity is set by consequence per SYNC:severity-rubric before the round bar is applied — never after, and never with the exit in view. — why: a floor that can be reached by relabeling is not a floor.
• The floor bounds the loop, not the standard. It ends iteration; it never authorizes shipping a known CRITICAL/HIGH/MEDIUM, and it never lowers the finding-survival bar that admits a finding in the first place.
• The floor never applies to a hard gate. Test-green gates (a suite must actually pass), security must-fix gates, and any gate whose criterion is binary rather than severity-rated are unaffected — a failing test is a failure, not a LOW finding.

Universal scope (any new output/judgment): any newly produced output or judgment gets ≥1 self-review; any new judgment gets ≥1 $why-review --validate-findings pass; anything flagged to re-check is re-checked ≥1 time — before that output is treated as final. This loop is the default convergence contract for ANY work-producing skill, not review skills only.

Routing invariant (author-facing): a skill that validates findings MUST route them through $why-review --validate-findings (the terminal validator) — NEVER fork an inline finding-validation. Routing through why-review is what makes the finding-survival bar and this loop apply; the verify-review-validate-coverage sensor enforces this exact route mechanically.

Round 1: Main-session review. Read target files, build understanding, note issues. Output findings + verdict (PASS / FAIL).

Decision after Round 1:

• No issues found (PASS, zero findings) → review ENDS. Do NOT spawn a fresh sub-agent for confirmation.
• blocking_findings(round, findings) is non-empty → run the active review skill's findings-validation gate first; for review skills the default gate is $why-review --validate-findings <report-path>. Fix only validated findings, then restart the full review protocol from the beginning with a fresh task breakdown.

Fresh full re-review after every fix cycle: Re-run the whole review protocol over the current full target. When sub-agents are part of that protocol, spawn NEW spawn_agent calls — never reuse prior agents. Reviewers re-read ALL files from scratch with ZERO memory of prior rounds. See SYNC:fresh-context-review for the spawn mechanism and SYNC:review-protocol-injection for the canonical Agent prompt template. Each fresh full revi

…(truncated)