architecture-review-full

Imported from duc01226/easy-claude (.agents/skills/architecture-review-full/SKILL.md). Install upstream with npx skills add duc01226/easy-claude --skill architecture-review-full. Copyright stays with the author.

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, and production readiness in ONE pass: orchestrate three deliberately non-overlapping sibling reviewers, dedup intentional cross-references, and synthesize ONE consolidated Architecture Health Report with one combined verdict — this is a THIN orchestrator; NEVER re-implement child reviews.

Summary:

• Testability contract: resolve Unit/Integration/System/E2E applicability from runner/config evidence; record owner/root/data, copy-ready full + focused commands, zero-match behavior, CI/simple-Windows entry, unique run/data identity, and repeat proof; unresolved applicable fields block handoff, while non-applicable tiers require evidence-backed N/A.

• 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)
• Testability & Verification Contract: TVC: PASS | PARTIAL | BLOCKED or N/A — evidence, copied from the child contract result; this is non-scoring and not a fourth review face.
• 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):

Merged Testability & Verification Contract (non-scoring): Copy the TVC status and evidence from the architecture-scalability-review child into the consolidated report, then retain the architecture-design/scaffold/harness owner links rather than re-deriving the contract. Use UNVERIFIED — child result absent when the child did not emit it; never infer PASS, especially for E2E.

This roll-up is a status/evidence section only: it is not a fourth sub-score and never changes the three child scores or the combined-verdict calculation. A blocked contract remains an explicit setup follow-up.

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 non-scoring TVC status is copied (or explicitly marked UNVERIFIED), 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 non-scoring TVC status/source, 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	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 review must catch:

• Cross-cutting concerns missed in the prior round
• Interaction bugs between changed files
• Convention drift (new code vs existing patterns)
• Missing pieces that should exist but don't
• Subtle edge cases the prior round rationalized away
• Regressions introduced by the fixes themselves

Loop termination: After each full re-review, repeat the same decision against that round's exit bar: bar cleared → END; blocking findings remain → validate findings → fix → restart from the first review phase. Rounds 1-2 clear on zero findings at any severity; from round 3 the bar is zero CRITICAL/HIGH/MEDIUM, so a LOW-only round ENDS the loop (deferred LOWs go in the report). Capped at 3 rounds. Escalate by asking the user directly at whichever comes first: the same validated finding repeats for 2 full invocations with no progress · a fix requires product/owner input · round 3 completes with CRITICAL/HIGH/MEDIUM still open. NEVER loop past 3 rounds, and NEVER convert cap exhaustion into a PASS.

Rules:

• A clean Round 1 ENDS the review — no mandatory Round 2
• From round 3 on, a round whose validated findings are ALL LOW ENDS the loop — never open round N+1 to fix LOW alone; list those LOWs as deferred instead
• NEVER re-tier a CRITICAL/HIGH/MEDIUM down to LOW to reach the round-3 exit — severity is assigned by consequence before the bar is applied
• NEVER fix unvalidated findings; validate first using the caller's validation gate
• Every surviving finding must additionally clear the finding-survival bar defined in why-review's Findings Validation Routine (a deliberately higher bar than the generic act-gate — "keep this finding?" is a stricter question than "act on this evidence?"); a finding below the bar is demoted or dropped, not kept
• NEVER skip the full re-review after a fix cycle (every fix invalidates the prior verdict)
• NEVER reuse a sub-agent across rounds — every iteration that uses sub-agents spawns NEW Agent calls
• Main agent READS sub-agent reports but MUST NOT filter, reinterpret, or override findings
• The 3-round cap NEVER replaces the clean-review requirement — it bounds runaway looping, it does not authorize shipping an un-clean review; a clean pass ends the loop early at any round, and cap exhaustion escalates rather than passes
• Enforce the round cap of 3 alongside the 2 repeated-no-progress blocker rule; both are escalation triggers, neither is a completion criterion
• Track recursive invocation count and repeated blockers in conversation context (session-scoped)
• Final verdict must incorporate ALL rounds executed

Report must include ## Round N Findings (Fresh Sub-Agent) for every round N≥2 that was executed, plus ## Deferred LOW Findings (severity floor, round ≥3) whenever the loop ended on the round-3+ bar with LOWs still open.

Fresh Context Re-Review — Eliminate orchestrator confirmation bias after fixes by restarting the full review with isolated sub-agents where applicable.

Why: The main agent knows what it (or $feature-implement) just fixed and rationalizes findings accordingly. A fresh sub-agent has ZERO memory, re-reads from scratch, and catches what the main agent dismissed. Sub-agent bias is mitigated by (1) fresh context, (2) verbatim protocol injection, (3) main agent not filtering the report.

When: ONLY after a validated-finding fix cycle. A review round that finds zero issues ENDS the loop — do NOT spawn a confirmation sub-agent. A review round that finds issues triggers: validate findings → fix → full review restart from the first phase.

How:

1. Start a NEW full review invocation/task breakdown; when that protocol calls for agents, spawn NEW spawn_agent tool calls — use code-reviewer agent_type for code reviews, general-purpose for plan/doc/artifact reviews
2. Inject ALL required review protocols VERBATIM into the prompt — see SYNC:review-protocol-injection for the full list and template. Never reference protocols by file path; AI compliance drops behind file-read indirection (see SYNC:shared-protocol-duplication-policy)
3. Sub-agent re-reads ALL target files from scratch via its own tool calls — never pass file contents inline in the prompt
4. Sub-agent writes structured report to plans/reports/{review-type}-round{N}-{date}.md
5. Main agent reads the report, integrates findings into its own report, DOES NOT override or filter

Rules:

• SKIP fresh sub-agent when the prior full review found zero issues (no fixes = nothing new to verify)
• NEVER skip the full review restart after a fix cycle — every fix invalidates the prior verdict
• NEVER reuse a sub-agent across rounds — every fresh round spawns a NEW spawn_agent call
• Continue until a complete full review pass clears that round's exit bar per SYNC:double-round-trip-review: rounds 1-2 → zero findings at any severity; round 3+ → zero CRITICAL/HIGH/MEDIUM, so a round whose validated findings are ALL LOW ENDS the loop (list those LOWs as deferred instead of spawning another round). If the same blocker repeats 3 times with no progress, escalate by asking the user directly
• Track iteration count and repeated blockers in conversation context (session-scoped, no persistent files)

Review Protocol Injection — Every fresh sub-agent review prompt MUST embed 11 protocol blocks VERBATIM. The template below has ALL 11 bodies already expanded inline. Copy the template wholesale into the Agent call's prompt field at runtime, replacing only the {placeholders} in Task / Round / Reference Docs / Target Files / Output sections with context-specific values. Do NOT touch the embedded protocol sections.

Why inline expansion: Placeholder markers would force file-read indirection at runtime. AI compliance drops significantly behind indirection (see SYNC:shared-protocol-duplication-policy). Therefore the template carries all 11 protocol bodies pre-embedded.

Subagent Type Selection

• code-reviewer — for code reviews (reviewing source files, git diffs, implementation)
• general-purpose — for plan / doc / artifact reviews (reviewing markdown plans, docs, specs)

Canonical Agent Call Template (Copy Verbatim)

spawn_agent({
  description: "Fresh Round {N} review",
  agent_type: "code-reviewer",
  prompt: `
## Task
{review-specific task — e.g., "Review all uncommitted changes for code quality" | "Review plan files under {plan-dir}" | "Review integration tests in {path}"}

## Round
Round {N}. You have ZERO memory of prior rounds. Re-read all target files from scratch via your own tool calls. Do NOT trust anything from the main agent beyond this prompt.

## Protocols (follow VERBATIM — these are non-negotiable)

### Spec ↔ Tests ↔ Code Triangulation
DO THIS FIRST — before any per-protocol check below. The review target is the WHOLE PACKAGE, not the diff alone: load the behavior's spec (§3 ACs / §4 BRs / §8 TCs), its tests, and the changed code TOGETHER, and reason about their mutual consistency BEFORE judging any one in isolation.
1. Locate all three faces: the Feature Spec section(s) governing the changed behavior, the tests that guard it, and the production code that implements it. A missing face is itself a finding (SPEC-GAP / TEST-GAP / DEAD-SPEC).
2. Triangulate pairwise — every disagreement is a finding; classify which face is wrong:
   - code vs spec: behavior the code does that no §3/§4/§8 rule describes → CODE-EXTRA or SPEC-STALE; a [HARD] §4 rule or §5 invariant with no enforcing code path → CODE-WRONG.
   - tests vs spec: a §8 TC with no test, or a test asserting behavior no TC/rule names → TEST-GAP or SPEC-SILENT.
   - tests vs code: a changed code path with no covering test → TEST-GAP; a test that still passes against a deliberately broken invariant → WEAK-TEST (apply the mutation thinking in Bug Detection).
3. Hidden-rule capture: any invariant the code enforces but the spec never states (SPEC-SILENT) MUST be surfaced as a finding to add into §3/§4/§8 AND guarded with a test — the enrichment loop, never a silent pass.
4. Only after the three faces agree — or every disagreement is logged as a finding — proceed to the per-protocol checks below; when enrichment adds spec/test content, re-review the package against the enriched spec.
NEVER mark review PASS while any spec/test/code face disagrees without a logged finding. The diff is the entry point; the package is the unit of judgment.

### 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) provided; 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: [...]."

### Bug Detection
MUST check categories 1-4 for EVERY review. Never skip.
1. Null Safety: Can params/returns be null? Are they guarded? Optional chaining gaps? .find() returns checked?
2. Boundary Conditions: Off-by-one (< vs <=)? Empty collections handled? Zero/negative values? Max limits?
3. Error Handling: Try-catch scope correct? Silent swallowed exceptions? Error types specific? Cleanup in finally?
4. Resource Management: Connections/streams closed? Subscriptions unsubscribed on destroy? Timers cleared? Memory bounded?
5. Concurrency (if async): Missing await? Race conditions on shared state? Stale closures? Retry storms?
6. Stack-Specific: Check the configured language/runtime pitfalls and framework-specific failure modes discovered from local code.
Classify: CRITICAL (crash/corrupt) → FAIL | HIGH (incorrect behavior) → FAIL | MEDIUM (edge case) → WARN | LOW (defensive) → INFO.

### Design Patterns Quality
Priority checks for every code change:
1. DRY via OOP: Same-suffix classes (*Entity, *Dto, *Service) MUST share base class. 3+ similar patterns → extract to shared abstraction.
2. Right Responsibility: Logic in LOWEST layer (Entity > Domain Service > Application Service > Controller). Never business logic in controllers.
3. SOLID: Single responsibility (one reason to change). Open-closed (extend, don't modify). Liskov (subtypes substitutable). Interface segregation (small interfaces). Dependency inversion (depend on abstractions).
4. After extraction/move/rename: Grep ENTIRE scope for dangling references. Zero tolerance.
5. YAGNI gate: Recommend extraction when 3+ similar patterns exist OR an evidenced consumer boundary/substitution need justifies it; do not create patterns for hypothetical future use.
6. Purpose-oriented naming: Name public or cross-layer abstractions by the capability, domain purpose, or contract consumers rely on—not the current provider, SDK, framework, database, or transport. `IStorage`/`Storage` → `AzureBlobStorage`; use `IAzureStorage` only when Azure-specific semantics are intentionally part of the contract.
7. Contract-fit check: Read callers and every implementation before judging a name; narrow an over-broad abstraction (`IObjectStore`, `DocumentStore`) instead of rewarding a generic name that lies about behavior.
8. Mechanism/generic-name smell: Treat `Manager`, `Helper`, `Utils`, `Data`, `Thing`, `Service`, `Interface`, type decorations, and unexplained abbreviations as review signals—not automatic defects; flag them only when they hide purpose, scope, or responsibility.
9. Concrete implementation names: Provider, strategy, transport, or test-double names are valid on concrete types when they distinguish real behavior (`AzureBlobStorage`, `InMemoryStorage`, `RetryingStorage`); keep those details out of the caller-facing contract unless the contract promises them.
10. Language convention: Preserve local interface syntax and naming style; `.NET` `I` prefixes and Google TypeScript's unmarked interfaces are both valid local conventions.
Anti-patterns to flag: God Object, Copy-Paste inheritance, Circular Dependency, Leaky Abstraction.

### Logic & Intention Review
Verify WHAT code does matches WHY it was changed.
1. Change Intention Check: Every changed file MUST serve the stated purpose. Flag unrelated changes as scope creep.
2. Happy Path Trace: Walk through one complete success scenario through changed code.
3. Error Path Trace: Walk through one failure/edge case scenario through changed code.
4. Acceptance Mapping: If plan context available, map every acceptance criterion to a code change.
5. Tests Verify Intent: For test/spec changes, verify tests name the protected business rule or invariant and would fail if that intent breaks.
6. Migration Test Exclusion: Do not write tests for migration code. Schema/data migrations are one-time execution paths, not core application logic.
NEVER mark review PASS without completing both traces (happy + error path).

### Test Spec Verification
Map changed code to test specifications.
1. Identify the project's test/spec format from existing docs, test-case files, BDD feature files, or spec folders.
2. Every changed code path MUST map to a corresponding test case/spec (or flag as "needs test case").
3. New functions/endpoints/handlers → flag for test spec creation.
4. Migration files are excluded from test/spec creation; schema/data migrations are one-time execution paths, not core application logic.
5. If spec evidence fields exist, verify they point to actual code (file:line, not stale references).
6. Verify each meaningful test case names the business intent/invariant; flag behavior-only cases that only mirror implementation details.
7. Auth/data changes → verify corresponding authorization and data-state test cases exist.
8. If no specs exist for a changed path → log the gap and recommend the project's test-spec workflow.
NEVER skip test mapping. Untested code paths are the #1 source of production bugs.

### Behavioral Delta Matrix
MANDATORY for any bugfix review. Produce input-state × pre-fix × post-fix × delta table BEFORE writing verdict.
- Minimum 3 rows; include at least one row OUTSIDE the original bug report.
- Any "REGRESSION" delta → review returns FAIL until a preservation test is added.
- Narrative descriptions do NOT substitute for the matrix.
Example rows (external-record sync fix):
| Input                 | Pre-fix | Post-fix                  | Delta      |
| --------------------- | ------- | ------------------------- | ---------- |
| Record exists (valid) | Reused  | Always recreated → orphan | REGRESSION |
| Record missing (404)  | Error   | Recreated                 | Fixed      |

### Fix-Layer Accountability
NEVER fix at the crash site. Trace the full flow, fix at the owning layer. The crash site is a SYMPTOM, not the cause.
MANDATORY before ANY fix:
1. Trace full data flow — Map the complete path from data origin to crash site across ALL layers (storage → backend → API → frontend → UI). Identify where bad state ENTERS, not where it CRASHES.
2. Identify the invariant owner — Which layer's contract guarantees this value is valid? Fix at the LOWEST layer that owns the invariant, not the highest layer that consumes it.
3. One fix, maximum protection — If fix requires touching 3+ files with defensive checks, you are at the wrong layer — go lower.
4. Verify no bypass paths — Confirm all data flows through the fix point. Check for direct construction skipping factories, clone/spread without re-validation, raw data not wrapped in domain models, mutations outside the model layer.
BLOCKED until: Full data flow traced (origin → crash); Invariant owner identified with file:line evidence; All access sites audited (grep count); Fix layer justified (lowest layer that protects most consumers).
Anti-patterns (REJECT): "Fix it where it crashes" (crash site ≠ cause site, trace upstream); "Add defensive checks at every consumer" (scattered defense = wrong layer); "Both fix is safer" (pick ONE authoritative layer).

### Rationalization Prevention
AI skips steps via these evasions. Recognize and reject:
- "Too simple for a plan" → Simple + wrong assumptions = wasted time. Plan anyway.
- "I'll test after" → RED before GREEN. Write/verify test first.
- "Already searched" → Show grep evidence with file:line. No proof = no search.
- "Just do it" → Still need task tracking. Skip depth, never skip tracking.
- "Just a small fix" → Small fix in wrong location cascades. Verify file:line first.
- "Code is self-explanatory" → Future readers need evidence trail. Document anyway.
- "Combine steps to save time" → Combined steps dilute focus. Each step has distinct purpose.

### Graph-Assisted Investigation
MANDATORY when .code-graph/graph.db exists.
HARD-GATE: MUST 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.
- Investigation: 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.

### Understand Code First
HARD-GATE: Do NOT write, plan, or fix until you READ existing code.
1. Search 3+ similar patterns (grep/glob) — cite file:line evidence.
2. Read existing files in target area — understand structure, base classes, conventions.
3. Run python .claude/scripts/code_graph trace <file> --direction both --json when .code-graph/graph.db exists.
4. Map dependencies via connections or callers_of — know what depends on you

*Truncated - read the full file at https://github.com/duc01226/easy-claude/blob/e46c5f1a56e43f9a04e7704ede06824623450bf6/.agents/skills/architecture-review-full/SKIL