@ngocsangairvds/vsaf 5.1.4 → 5.1.6

package/skills/sdlc/implement/SKILL.md

@@ -1,264 +0,0 @@
----
-name: sdlc-implement
-description: Phase 6 — TDD Implementation via subagent-driven development + SonarQube-during-code + GitNexus impact verification
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Phase 6: Implementation (TDD + Subagent-Driven + SonarQube-In-Loop)
-
-You are a Senior Software Engineer. Your mission: implement code following TDD — RED → GREEN → REFACTOR. Do not write code without a failing test first.
-
-**TWO important changes compared to the old process:**
-1. **MANDATORY use of subagent-driven development** — dispatch parallel subagents for stories/epics
-2. **Apply SonarQube rules DURING coding** — do not wait for review phase to check
-
-## Index Protection
-
-⛔ **DO NOT modify** `graphify-out/` or `.gitnexus/` — READ only, never WRITE.
-
-## Phase Entry Protocol
-
-```
-[IMPLEMENT] [1/8] Checking input artifacts... ⏳
-```
-
-1. Input:
-   - `.vsaf/docs/features/{feature-name}/06-testcases.md`
-   - `.vsaf/docs/features/{feature-name}/03-adr.md`
-   - `.vsaf/docs/features/{feature-name}/04-epics.md`
-2. Verify ALL 3 files exist:
-   - Any file missing → Ask: "File not found. Have you pulled it yet?"
-3. Read `.vsaf/docs/STATUS.md`
-4. Read `CONTEXT.md`
-5. Query `graph.json` for code structure
-
-```
-[IMPLEMENT] [1/8] Checking input artifacts... ✅
-```
-
-**Note:** This phase MUST run via `/superpowers:subagent-driven-development` — dispatch parallel subagents for each epic according to the Conflict Map in `04-epics.md`.
-
-## Subagent-Driven Development Protocol
-
-```
-[IMPLEMENT] [2/8] Initializing subagent-driven development... ⏳
-```
-
-**MANDATORY** — Check and activate `/superpowers:subagent-driven-development`:
-1. If not already in subagent mode → **switch immediately**
-2. Analyze `04-epics.md` → identify Conflict Map
-3. Dispatch each epic/story as a separate subagent running in parallel
-4. Each subagent follows the Conflict Map — only modify files assigned to its epic
-
-```
-[IMPLEMENT] [2/8] Initializing subagent-driven development... ✅
-```
-
-## SonarQube Quality Gate — Apply DURING Coding
-
-⚠️ **DO NOT wait for review phase.** Each subagent MUST self-check the `sonar-viettel` gate WHILE writing code.
-
-> **Standard (single source of truth):** **`.claude/skills/_shared/sdlc/sonar-viettel/quality-gate.md`** — full New Code + Overall Code tables, the 357-rule parameters, and the importable `sonar-viettel-profile.xml` / `sonar-viettel-gate.json`. **Read it.** Phase 7 (`/sdlc-review`) re-checks the **same** file — anything that passes here must pass there. Do NOT invent stricter or looser values.
-
-**Hard fails to self-check (summary — see the shared doc for the full gate):**
-- New Code: Issues / Blocker / Critical / Major / Vulnerabilities = **0**; Code Smells **≤ 20**; Security Hotspots Reviewed = **100%**; Duplicated **≤ 45%**; Maintainability / Reliability / Security Rating **≥ A**.
-- Overall Code: Bugs = **0**; Code Smells **≤ 50**; same Blocker/Critical/Major/Vuln/Duplication/rating rules.
-- Honour the parametrised rules — S107 (params), S3776 (complexity), S110 (inheritance), S1479 (switch), S1192 (literals), S2068/S2077 (secrets/injection), S100/S101/S115 (naming). **Thresholds live authoritatively in the profile XML** — derive them via the snippet in the shared `quality-gate.md`, do not memorise numbers.
-
-**How to apply during coding:**
-- **After each function** → self-review: security vulnerabilities? code smells? duplication?
-- **After each class** → check SOLID violations, naming conventions, interface segregation
-- **Before each commit** → scan changed files for: SQL injection, XSS, command injection, hardcoded secrets, null dereference, resource leaks, concurrency issues, duplicated blocks
-- **Auto-detect SonarQube:** check whether `sonar-scanner` is on PATH.
-  - Present → import the profile + gate from the shared folder, then run `sonar-scanner` incremental.
-  - Absent → print `Sonar not found → self-checklist mode` and self-review against the shared `quality-gate.md`. This is a fully supported path, not a fallback to apologise for — SonarQube is OPTIONAL.
-
-**Goal:** Review phase should only need to RE-CHECK, not find bugs for the first time.
-
-## Tasks
-
-### Step 3: Task Planning
-
-```
-[IMPLEMENT] [3/8] Task planning from testcases + ADR... ⏳
-```
-
-Use `/superpowers:writing-plans` — create granular task plan from testcases + ADR.
-Each task maps to ≥1 FR/NFR.
-Write to `07-impl-plan.md`.
-
-```
-[IMPLEMENT] [3/8] Task planning from testcases + ADR... ✅
-```
-
-### Step 3.5: Checkpoint Review (every 3-5 tasks)
-
-```
-[IMPLEMENT] [3.5/8] Checkpoint review... ⏳
-```
-
-After every 3-5 completed tasks: invoke `/bmad-checkpoint-preview` (human-in-the-loop walkthrough).
-
-Purpose: pause and let the user review progress before continuing.
-
-The checkpoint will:
-- Summarize: what was done, which files changed, current tests status
-- Highlight: points of concern, potential issues
-- Ask user: continue / adjust / stop?
-
-**Skip checkpoint if** the total plan has fewer than 5 tasks — checkpoint only at the end in that case.
-
-```
-[IMPLEMENT] [3.5/8] Checkpoint review... ✅
-```
-
-### Step 4: TDD Cycle (per subagent)
-
-```
-[IMPLEMENT] [4/8] TDD cycle — RED → GREEN → REFACTOR... ⏳
-```
-
-Use `/superpowers:test-driven-development`:
-
-For each test case in `06-testcases.md`:
-1. **RED**: Write test → run → MUST FAIL
-2. **GREEN**: Write minimal code → run → MUST PASS
-   - ⚠️ **While writing GREEN code** → apply SonarQube rules immediately:
-     - Do not create security vulnerabilities
-     - No code smells (long method, deep nesting)
-     - No duplicated code
-     - Null-safe, proper error handling
-3. **REFACTOR**: Clean code, do not change behavior
-   - Refactor MUST improve SonarQube metrics, not degrade them
-
-Use `/superpowers:executing-plans` — execute plan in order.
-
-```
-[IMPLEMENT] [4/8] TDD cycle — RED → GREEN → REFACTOR... ✅
-```
-
-### Step 5: Debug (if needed)
-
-```
-[IMPLEMENT] [5/8] Debug (if there are test failures)... ⏳
-```
-
-Use `/superpowers:systematic-debugging` — when a test does not turn GREEN:
-- Hypothesis → Experiment → Conclusion
-- If it fails 3 times → STOP, escalate
-
-**Scope-drift detection:**
-
-If during implementation you detect the feature requires CHANGES NOT IN THE SRS:
-1. Invoke `/bmad-correct-course` — assess impact + propose adjustments
-2. If requirements have genuinely changed:
-   - STOP implementation
-   - Update SRS first via `/sdlc-srs` EDIT mode
-   - Re-run `/sdlc-test-design` to generate new test cases
-   - Restart Phase 6 from Step 3
-3. If only minor adjustments needed: document the adjustment in `07-impl-plan.md` §Scope Adjustments and continue
-4. If unclear whether scope changed: STOP and present to user — let them decide
-
-```
-[IMPLEMENT] [5/8] Debug (if there are test failures)... ✅
-```
-
-### Step 6: Impact Verification
-
-```
-[IMPLEMENT] [6/8] Impact verification via GitNexus... ⏳
-```
-
-Use GitNexus `impact` — verify no other code is broken.
-Use GitNexus `rename` — safe multi-file refactoring if needed.
-
-```
-[IMPLEMENT] [6/8] Impact verification via GitNexus... ✅
-```
-
-### Step 7: Build & Run Verification
-
-```
-[IMPLEMENT] [7/8] Build & run verification... ⏳
-```
-
-**MANDATORY** — code MUST compile and run successfully before exiting the phase.
-
-1. **Compile check**: Build the entire project → MUST have 0 errors
-   - Java: `mvn compile` or `gradle build`
-   - Node: `npm run build` / `tsc --noEmit`
-   - Angular: `ng build`
-   - Go: `go build ./...`
-   - If FAIL → fix immediately, DO NOT skip
-
-2. **Run verification**: Start application → MUST start successfully
-   - If the project has `docker-compose.yml` → `docker compose up`
-   - If not → use native run command
-   - Check health endpoint / startup log OK
-
-3. **Environment check**:
-   - Detect required runtime (JDK, Node, Python, Go, etc.)
-   - If runtime missing → ⚠️ **WARNING**: "Missing {runtime}. Cannot verify build."
-   - **Recommend Docker**: "Recommend using Docker to ensure a consistent environment. Create a Dockerfile if one does not exist."
-   - If Docker available → prefer building in container
-
-4. **Test suite run**: `npm test` / `mvn test` / equivalent → All tests PASS
-
-5. **Final SonarQube sweep**: Scan all new code one last time before exiting
-   - Confirm both New Code and Overall Code conditions are green per the shared `quality-gate.md` (single source of truth)
-   - If FAIL → fix immediately, this is a hard gate
-
-⚠️ **DO NOT exit the phase if code does not compile.** This is a hard gate — no exceptions.
-
-```
-[IMPLEMENT] [7/8] Build & run verification... ✅
-```
-
-## Multi-machine Branching
-
-```
-Single repo:
-  main → feat/{feature} → feat/{feature}/epic-1 (Subagent A)
-                         → feat/{feature}/epic-2 (Subagent B)
-
-Multi-repo:
-  Subagent A: cd user-service && git checkout -b feat/{feature}
-  Subagent B: cd payment-service && git checkout -b feat/{feature}
-```
-
-## Output
-
-- `.vsaf/docs/features/{feature-name}/07-impl-plan.md` — task plan + TDD log
-- Code changes on feature branch
-- All tests GREEN
-- SonarQube metrics PASS (verified during coding)
-
-## Phase Exit Protocol
-
-In PHASE REPORT:
-- Done: N tasks completed, M tests written, K subagents dispatched
-- Result: all tests PASS/FAIL
-- SonarQube (New Code): {PASS/FAIL vs shared gate} — Issues={N}, Blocker={N}, Critical={N}, Major={N}, Code Smells={N}, Vulns={N}, Hotspots Reviewed={N}%, Duplication={N}%
-- SonarQube (Overall): {PASS/FAIL vs shared gate} — Bugs={N}, Code Smells={N}, Duplication={N}%, ratings={A..E}
-- Output files: `07-impl-plan.md`
-- Code changes: {list files changed}
-- Suggestions: [1] Phase 7 Review (`/sdlc-review`) [2] Save artifacts
-
-Update `.vsaf/docs/STATUS.md`.
-
-**Notify the user:**
-> Artifacts have been saved. If the session is interrupted, open a new session and run the next phase — data is safe.
-
-## Rules
-
-- DO NOT write code without a failing test first (#2 TDD)
-- **MANDATORY** use `/superpowers:subagent-driven-development` — do not run sequential
-- **SonarQube rules apply DURING coding** — do not wait for review
-- Follow the Conflict Map — only modify files assigned to your epic
-- 3-strike rule: task fails 3 times → STOP, escalate
-- Impact analysis MUST run before each commit
-- Smart Zone: clear context every 5 tasks (#4)
-- **Code MUST compile successfully** — hard gate, no exceptions
-- **Recommend Docker** if runtime is missing or containerization is not set up
-- ⛔ DO NOT modify `graphify-out/` or `.gitnexus/`

package/skills/sdlc/prd/SKILL.md

@@ -1,182 +0,0 @@
----
-name: sdlc-prd
-description: Phase 2 — PRD via BMAD elicitation + create + validate + adversarial review + GitNexus impact
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Phase 2: PRD (Product Requirements Document)
-
-You are a Principal Product Owner. Mission: write a clear PRD that is validated and has blast radius assessment.
-
-## Language Rule
-
-All output documents (02-prd.md) MUST be written in Vietnamese. Section headers, user stories, requirements, analysis — all in Vietnamese. Only keep English for: IDs (FR-001, NFR-001, US-001), technical terms (API, database, endpoint), and code references.
-
-## Progress Protocol
-
-Print progress at each step in this format:
-```
-[PRD] [step/5] description... ⏳
-[PRD] [step/5] description... ✅
-```
-
-## Index Protection
-
-⛔ Do NOT modify `graphify-out/` or `.gitnexus/` in this phase.
-
-## Phase Entry Protocol
-
-```
-[PRD] [1/5] Checking prerequisites... ⏳
-```
-
-1. Input: `.vsaf/docs/features/{feature-name}/01-discovery.md`
-2. Check if file exists:
-   - Does not exist → Ask: "File not found. Have you run Phase 1 Discovery?"
-3. Read `.vsaf/docs/STATUS.md`
-4. Read `CONTEXT.md`
-5. Query `graph.json` for business domain context
-
-```
-[PRD] [1/5] Checking prerequisites... ✅
-```
-
-## Tasks
-
-### Step 2: Elicitation (Grill Session)
-
-```
-[PRD] [2/5] Grill session — elicitation probing edge cases... ⏳
-```
-
-Use `/bmad-advanced-elicitation` — grill 40-100 questions probing edge cases.
-Record results in `02-prd.md` §Grill Log.
-
-```
-[PRD] [2/5] Grill session — elicitation probing edge cases... ✅
-```
-
-### Step 3: Create PRD
-
-```
-[PRD] [3/5] Creating PRD from grill results... ⏳
-```
-
-Use `/bmad-create-prd` — create structured PRD from grill results (Step 2).
-
-Ensure the output covers:
-
-1. **Goals** — business goals + success metrics
-2. **User Stories** — each MUST have acceptance criteria (Given/When/Then)
-3. **Functional Requirements** — unique ID per requirement (FR-001, FR-002...)
-4. **Non-Functional Requirements** — unique ID (NFR-001, NFR-002...) — performance, security, scalability
-5. **Success Metrics** — measurable KPIs tied to goals
-
-Write to `02-prd.md` §Requirements.
-
-```
-[PRD] [3/5] Creating PRD from grill results... ✅
-```
-
-### Step 4: Validate + Adversarial Review
-
-```
-[PRD] [4/5] Validate + adversarial review... ⏳
-```
-
-**4a — Validate PRD:**
-
-Use `/bmad-validate-prd` — validate the PRD against BMAD standards:
-- Completeness — all user stories covered by FRs? All FRs traceable to a user story?
-- Clarity — any ambiguous requirements? Can each FR be implemented without guessing?
-- Testability — can each FR be verified with a test case?
-- Consistency — any FRs that contradict each other?
-
-Write to `02-prd.md` §Validation. If FAIL → fix inline, re-validate.
-
-**4b — Adversarial review:**
-
-Use `/bmad-review-adversarial-general` — cynical review to find gaps.
-Write to `02-prd.md` §Adversarial.
-
-```
-[PRD] [4/5] Validate + adversarial review... ✅
-```
-
-### Step 5: Blast Radius
-
-```
-[PRD] [5/5] Assessing blast radius via GitNexus... ⏳
-```
-
-Use GitNexus `impact` — assess scope of feature impact.
-Write to `02-prd.md` §Blast Radius.
-
-```
-[PRD] [5/5] Assessing blast radius via GitNexus... ✅
-```
-
-## Gate
-
-Human must approve the PRD. Write `## Gate: APPROVED` at the end of the file.
-Do NOT proceed to Phase 3 without the Gate marker.
-
-**Automated mode (opt-in):** when the environment has `VSAF_CI=1` or `VSAF_AUTO_APPROVE=1`, write the Gate yourself as `## Gate: APPROVED (auto · VSAF_CI · rationale: <one line>)` and proceed — the one-line rationale is REQUIRED for audit. Without the env flag, a human must approve (default).
-
-## Output
-
-Write file: `.vsaf/docs/features/{feature-name}/02-prd.md`
-
-```markdown
-# PRD: {feature-name}
-
-## Grill Log
-{elicitation Q&A}
-
-## Requirements
-### User Stories
-{with acceptance criteria}
-### Functional Requirements
-{FR-001, FR-002...}
-### Non-Functional Requirements
-{NFR-001, NFR-002...}
-
-## Validation
-{validate-prd result}
-
-## Adversarial
-{adversarial findings}
-
-## Blast Radius
-{GitNexus impact result}
-
-## Gate: {PENDING / APPROVED by {name} on {date}}
-```
-
-## Artifact Auto-Save
-
-After writing the file, print the message:
-
-> Artifacts saved. If the session is interrupted, open a new session and run the next phase — data is safe.
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-- Feature: {feature-name}
-- Status: COMPLETED
-- Completed: elicitation, create PRD, validate, adversarial review, blast radius
-- Output files: `.vsaf/docs/features/{feature-name}/02-prd.md`
-- Suggested next steps:
-  [1] Phase 3 Architecture → `/sdlc-architecture`
-  [2] Save artifacts
-
-Update `.vsaf/docs/STATUS.md`.
-
-## Rules
-
-- ⛔ Do NOT skip elicitation — Shared Understanding is mandatory
-- ⛔ Do NOT modify `graphify-out/` or `.gitnexus/`
-- Every user story MUST have acceptance criteria
-- Every FR/NFR MUST have a unique ID
-- Do NOT proceed if blast radius = HIGH without human approval

package/skills/sdlc/review/SKILL.md

@@ -1,210 +0,0 @@
----
-name: sdlc-review
-description: Phase 7 — Review via Superpowers verification + BMAD code review + SonarQube re-check + GitNexus impact + debate
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Phase 7: Review
-
-You are Tech Lead + QA Lead. Mission: verify code against SRS, adversarial review, impact assessment.
-
-## Progress Protocol
-
-Print progress at each step in this format:
-```
-[REVIEW] [step/5] description... ⏳
-[REVIEW] [step/5] description... ✅
-```
-
-## Index Protection
-
-⛔ DO NOT modify `graphify-out/` or `.gitnexus/` in this phase.
-
-## Artifact Auto-save
-
-All artifacts are automatically saved to `.vsaf/docs/features/{feature-name}/` to ensure session continuity. If the session is interrupted, you can resume from the last artifact.
-
-## Phase Entry Protocol
-
-```
-[REVIEW] [1/5] Checking prerequisites... ⏳
-```
-
-1. Input:
-   - `.vsaf/docs/features/{feature-name}/05-srs.md`
-   - Code diff on feature branch
-2. Check that SRS file exists
-3. Check that feature branch exists
-4. Read `.vsaf/docs/STATUS.md`
-5. Read `CONTEXT.md`
-6. Query `graph.json` for impact verification
-
-```
-[REVIEW] [1/5] Checking prerequisites... ✅
-```
-
-## Tasks
-
-### Step 2: System Verification
-
-```
-[REVIEW] [2/5] System verification — build, tests, scope... ⏳
-```
-
-Use `/superpowers:verification-before-completion`:
-- Build passes
-- All tests GREEN
-- No uncommitted files
-- Scope matches SRS
-Write to `08-review.md` §Verification.
-
-```
-[REVIEW] [2/5] System verification... ✅
-```
-
-### Step 3: Code Review
-
-```
-[REVIEW] [3/5] Adversarial code review... ⏳
-```
-
-Use `/bmad-code-review` — adversarial code review on the feature branch diff with parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor).
-
-Ensure the review covers:
-
-1. **Security scan** — SQL injection, XSS, command injection, hardcoded secrets, insecure deserialization
-2. **Data integrity** — null dereference, resource leaks, race conditions, missing transactions
-3. **SOLID violations** — god classes, leaky abstractions, interface segregation
-4. **Naming consistency** — verify against CONTEXT.md terminology
-5. **SRS compliance** — every FR/NFR implemented? Any extra scope not in SRS?
-
-Classify each finding: MUST FIX / SHOULD FIX / NOTED.
-Write to `08-review.md` §Code Review.
-
-#### Quality Gate Re-check (SonarQube)
-
-**IMPORTANT:** SonarQube rules were already applied in Phase 6 (Implementation). The Review phase only RE-CHECKS — confirming that code still meets standards after all changes.
-
-Verify that code meets the `sonar-viettel` Quality Gate.
-
-> **Standard (single source of truth):** **`.claude/skills/_shared/sdlc/sonar-viettel/quality-gate.md`** — the full New Code + Overall Code tables, the 357-rule parameters, and the importable `sonar-viettel-profile.xml` / `sonar-viettel-gate.json`. This is the **same** file Phase 6 (`/sdlc-implement`) coded against — review only confirms compliance, do not change the numbers.
-
-**Hard fails to confirm (summary — see the shared doc for the full gate):**
-- New Code: Issues / Blocker / Critical / Major / Vulnerabilities = **0**; Code Smells **≤ 20**; Security Hotspots Reviewed = **100%**; Duplicated **≤ 45%**; Maintainability / Reliability / Security Rating **≥ A**.
-- Overall Code: Bugs = **0**; Code Smells **≤ 50**; same Blocker/Critical/Major/Vuln/Duplication/rating rules.
-
-**How to execute (auto-detect — check whether `sonar-scanner` is on PATH):**
-- SonarQube present → ensure it uses the `sonar-viettel` Profile + Gate (import from the shared folder if missing), run `sonar-scanner`, and check the report
-- SonarQube absent → print `Sonar not found → self-checklist mode` and perform a manual re-check against the shared `quality-gate.md` (a fully supported path — SonarQube is OPTIONAL):
-  - Scan for security vulnerabilities (SQL injection, XSS, command injection, hardcoded secrets)
-  - Scan for bugs (null dereference, resource leaks, concurrency issues)
-  - Scan for code smells (long methods, deep nesting, duplicated blocks)
-  - Verify naming conventions, SOLID principles, duplicated blocks
-- Write results to `08-review.md` §Quality Gate
-
-**Quality Gate FAIL** → classify each issue as MUST FIX / SHOULD FIX / NOTED per the triage rules below.
-
-```
-[REVIEW] [3/5] Adversarial code review + Quality Gate re-check... ✅
-```
-
-### Step 4: Impact Assessment
-
-```
-[REVIEW] [4/5] Impact assessment via GitNexus... ⏳
-```
-
-Use GitNexus `detect_changes` + `impact`:
-- Confirm only expected files changed
-- Blast radius confidence scoring
-Write to `08-review.md` §Impact.
-
-```
-[REVIEW] [4/5] Impact assessment... ✅
-```
-
-### Step 5: Debate (complex features only)
-
-```
-[REVIEW] [5/5] Multi-agent debate (if needed)... ⏳
-```
-
-Use `/bmad-party-mode` — multi-agent debate:
-- Security vs Performance vs Maintainability
-Write to `08-review.md` §Debate.
-
-```
-[REVIEW] [5/5] Multi-agent debate... ✅
-```
-
-## Gate
-
-MUST FIX = 0, Human approve.
-
-**Automated mode (opt-in):** when `VSAF_CI=1` or `VSAF_AUTO_APPROVE=1` is set AND MUST FIX = 0, write `## Gate: APPROVED (auto · VSAF_CI · rationale: <one line>)` and proceed. If MUST FIX > 0, NEVER auto-approve — return to Phase 6 (Implement) regardless of the flag. Without the env flag, a human must approve (default).
-
-Triage:
-- **MUST FIX**: Security, data loss, SRS FR/NFR not satisfied, crash → Blocks ship
-- **SHOULD FIX**: Performance, maintainability → Fix if time allows
-- **NOTED**: Style, minor naming → Log only
-
-If MUST FIX > 0 → return to Phase 6 (Implementation) with specific issues.
-
-## Output
-
-Write file: `.vsaf/docs/features/{feature-name}/08-review.md`
-
-```markdown
-# Review: {feature-name}
-
-## Verification
-- Build: PASS/FAIL
-- Tests: {X}/{Y} passed
-- Uncommitted files: none
-- Scope: matches SRS ✓
-
-## Code Review
-### MUST FIX
-- (none)
-### SHOULD FIX
-- {issue description}
-### NOTED
-- {minor items}
-
-## Quality Gate (Re-check)
-- SonarQube: {available / manual re-check}
-- New Code: {PASS/FAIL} — Issues={N}, Blocker={N}, Critical={N}, Major={N}, Smells={N}, Vulns={N}, Duplication={N}%
-- Overall: {PASS/FAIL} — Bugs={N}, Blocker={N}, Critical={N}, Major={N}, Smells={N}, Vulns={N}, Duplication={N}%
-- Compile: PASS/FAIL
-- Runtime: PASS/FAIL
-
-## Impact
-- Files changed: {N}
-- Blast radius: {low/medium/high}
-- Confidence: {%}
-
-## Debate (if applicable)
-{party-mode findings}
-
-## Gate: {PENDING / APPROVED by {name} on {date}}
-```
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-- Results: MUST FIX = {N}, SHOULD FIX = {N}, NOTED = {N}
-- Output files: `08-review.md`
-- Suggestion: [1] `/sdlc-feature-complete` (if APPROVED) [2] Return to Phase 6 (if MUST FIX > 0)
-
-Update `.vsaf/docs/STATUS.md`.
-
-## Rules
-
-- Review against SRS (spec), NOT against code implementation
-- Max 2 review rounds — if still failing → escalate to human
-- MUST FIX items MUST be resolved before feature-complete
-- **Quality Gate FAIL = MUST FIX** — Blocker, Critical, Vulnerability all block ship
-- **Code does not compile = MUST FIX** — hard gate, no exceptions
-- If there is no SonarQube, Claude performs a manual quality gate re-check
-- **SonarQube only RE-CHECKS** — rules were applied in Phase 6, review only confirms compliance