@ngocsangairvds/vsaf 3.2.16 → 4.0.1

package/tools/skills/vsaf-plan/SKILL.md

@@ -1,101 +0,0 @@
----
-name: vsaf-plan
-description: "Plan a new feature/task. Use when receiving a requirement that needs scope analysis, impact assessment, and approach strategy. Dual brainstorm (Superpowers + BMAD). Example: /vsaf-plan create user management module"
----
-
-# VSAF Plan
-
-## Objective
-Fully understand the requirement, analyze impact, and determine the implementation strategy before writing any line of code.
-
-## Input
-`$ARGUMENTS` — description of the feature/task to be done (e.g.: "create dashboard management module")
-
-## Execution Steps
-
-### Step 1 — Clarify scope (BMAD analyst)
-- Use skill `bmad-agent-analyst` to analyze the requirement
-- Identify: FRs, NFRs, edge cases, assumptions, out-of-scope
-- STOP and ask the user if there are any unclear points
-
-### Step 2 — Impact analysis (GitNexus)
-- Use `gitnexus_impact` with the target being the related module/symbol
-- Use `gitnexus_query` to find related code
-- Report blast radius: how many modules are affected, risk level
-- If risk is HIGH/CRITICAL: STOP, notify the user before continuing
-
-### Step 2b — Module boundary analysis (GitNexus)
-- Use `gitnexus_group_query` to view module boundaries
-- Identify: which groups are affected, interface contracts between groups
-- Understand module boundaries clearly before proposing architecture
-
-### Step 3 — Architecture decision (BMAD architect)
-- Use skill `bmad-agent-architect` to propose an architecture approach
-- Compare alternatives, choose the most suitable approach
-- **If risk is HIGH or > 3 modules**: use skill `bmad-create-architecture` to create a formal ADR (Architecture Decision Record)
-  - Save to `.vsaf/docs/planning-artifacts/adr-[feature].md`
-
-### Step 4 — Dual Brainstorm
-
-#### 4a — Structured brainstorm (Superpowers)
-- Use `superpowers:brainstorming` — structured exploration:
-  - Trade-offs, constraints, 2-3 viable options
-  - Evaluate risks for each option
-
-#### 4b — Creative brainstorm (BMAD)
-- Use skill `bmad-brainstorming` to explore alternatives and uncover hidden risks
-- Facilitator leads the session with diverse creative techniques
-- Goal: at least 20 ideas/alternatives before reorganizing
-
-#### 4c — Parallel deep-dive (Superpowers, if >2 approaches)
-- Use `superpowers:dispatching-parallel-agents` to research candidate approaches in parallel
-- Each agent deep-dives into 1 approach: feasibility, risks, effort
-- Synthesize results to choose the best approach
-
-### Step 5 — Challenge approach (BMAD Advanced Elicitation)
-- Use skill `bmad-advanced-elicitation` to challenge the chosen approach
-- Run **pre-mortem**: "Assume this approach fails after 3 months — why?"
-- Run **red team**: find weaknesses, attack vectors, failure modes
-- If serious risks are discovered: go back to Step 3 to adjust the approach
-
-### Step 6 — Output to user
-Present results in the following format:
-
-```
-## Feature: [feature name]
-
-## Scope
-- In: [what will be done]
-- Out: [what will not be done]
-
-## Impact Analysis
-- Affected modules: [list]
-- Module boundaries: [from group_query]
-- Risk level: [LOW/MEDIUM/HIGH]
-- Breaking changes: [yes/no, details]
-
-## Chosen Approach
-[Architecture approach description]
-
-## Brainstorm Summary
-- Superpowers: [N approaches explored, chosen: X]
-- BMAD: [N ideas generated, top insights]
-- Parallel agents: [used / not needed]
-
-## Pre-mortem findings
-[Identified risks and mitigation plan]
-
-## Alternatives considered
-[Why they were not chosen]
-
-## ADR
-[Created / Not needed (risk LOW)]
-
-## Next step
-Run /vsaf-doc-prd to write the PRD document
-```
-
-## Notes
-- If Impact > 3 modules: warn the user, suggest splitting into multiple PRs
-- If risk level is HIGH/CRITICAL: STOP, notify the user before continuing
-- Dual brainstorm is mandatory: both Superpowers (structured) and BMAD (creative)

package/tools/skills/vsaf-push-prd/SKILL.md

@@ -1,154 +0,0 @@
----
-name: vsaf-push-prd
-description: Push PRD document to Confluence. Use after /vsaf-doc-prd or /vsaf-doc-prd (edit) to publish or update the PRD page on Confluence. Accepts an optional comment as version note.
----
-
-# VSAF Push PRD
-
-## Objective
-Publish the current PRD to Confluence — create a new page if it doesn't exist, or update the existing one. The comment becomes the Confluence version note.
-
-## Input
-- `[file]` — optional path to a specific markdown file or directory (defaults to scanning `.vsaf/docs/planning-artifacts/prd-*.md`)
-- `[comment]` — optional version note (e.g. "Initial draft", "Updated scope after stakeholder review")
-
-## Prerequisites
-- Confluence MCP must be configured (`vsaf init` sets this up)
-- A PRD markdown file must exist
-
-## Steps
-
-### Step 1 — Find PRD file(s)
-- If a **directory path** was given (e.g. `@docs/architecture/`): read all `*.md` files in that directory and combine them into a single page body, separated by `<hr/>`. Use the directory name as the page title base.
-- If a **specific file path** was given: use that file directly.
-- Otherwise: list files in `.vsaf/docs/planning-artifacts/` matching `prd-*.md`
-  - If multiple found: ask user which one to push
-  - If none found: STOP — tell user to run `/vsaf-doc-prd` first
-- Read full file content
-
-### Step 2 — Load Confluence config
-Read `.vsaf/_bmad/bmm/config.yaml` and extract:
-- `confluence_space_key` — Confluence space (e.g. `PROJ`)
-- `confluence_parent_page` — parent page title (e.g. `Project Documentation`)
-
-If either field is missing or empty:
-- Ask user: "Enter Confluence space key (e.g. PROJ):"
-- Ask user: "Enter parent page title in Confluence (blank = root of space):"
-- Save answers back to config so the user is not asked again
-
-### Step 3 — Determine page title and parent page ID
-- If file is from `prd-*.md`: title = `[PRD] {Feature Name}` (derive from filename: `prd-user-management.md` → `[PRD] User Management`)
-- If input was a directory: title = the numbered section label provided by the user (e.g. `3.4.2.12 VRoute — Architecture Design`)
-- Otherwise: use the first `# Heading` in the file as the page title, or the filename stem if no heading found
-
-**Resolve parent page ID:**
-Use `confluence_search_pages` to search for the parent page title in the configured space. Extract the `id` field from the result — this is the `parentId` needed for page creation. Do NOT skip this step.
-
-### Step 4 — Convert markdown → Confluence storage format
-
-**CRITICAL RULES — read before writing a single tag:**
-
-1. **Never send raw markdown.** All content must be converted to Confluence Storage Format (XHTML).
-2. **Never wrap the entire body in `<![CDATA[...]]>`.** CDATA is ONLY valid inside `<ac:plain-text-body>` within code macros.
-3. **All Confluence macro attributes MUST use the `ac:` namespace prefix.** The tag is `<ac:parameter ac:name="...">`, never `<parameter name="...">`. Wrong namespace = XML parse error.
-4. **Escape HTML entities in regular text:** `&` → `&amp;`, `<` → `&lt;`, `>` → `&gt;`.
-5. **Every opened tag must be closed.** Confluence's XML parser is strict — an unclosed tag aborts the entire page push.
-
-**Block elements:**
-```
-# Heading      → <h1>Heading</h1>
-## Heading     → <h2>Heading</h2>
-### Heading    → <h3>Heading</h3>
-#### Heading   → <h4>Heading</h4>
-paragraph text → <p>paragraph text</p>
----            → <hr/>
-```
-
-**Inline elements:**
-```
-**bold**       → <strong>bold</strong>
-*italic*       → <em>italic</em>
-`inline code`  → <code>inline code</code>
-[text](url)    → <a href="url">text</a>
-```
-
-**Lists:**
-```
-- item         → <ul><li>item</li></ul>
-1. item        → <ol><li>item</li></ol>
-```
-
-**Tables:**
-```
-| H1 | H2 |   →  <table><tbody>
-|----|----| →       <tr><th>H1</th><th>H2</th></tr>
-| a  | b  |          <tr><td>a</td><td>b</td></tr>
-               </tbody></table>
-```
-
-**Code blocks — the ONLY correct place for CDATA:**
-```
-```lang                →  <ac:structured-macro ac:name="code">
-code here                   <ac:parameter ac:name="language">lang</ac:parameter>
-```                          <ac:plain-text-body><![CDATA[code here]]></ac:plain-text-body>
-                           </ac:structured-macro>
-```
-⚠️ The attribute is `ac:name` not `name`. Using `<ac:parameter name="language">` will cause an XML parse error.
-
-**Info/warning/tip boxes:**
-```
-> [!NOTE] title   →  <ac:structured-macro ac:name="info">
-> body                  <ac:parameter ac:name="title">title</ac:parameter>
-                        <ac:rich-text-body><p>body</p></ac:rich-text-body>
-                      </ac:structured-macro>
-
-> [!WARNING]      →  ac:name="warning"
-> [!TIP]          →  ac:name="tip"
-```
-
-**Blockquote:**
-```
-> text            → <blockquote><p>text</p></blockquote>
-```
-
-### Step 5 — Check if page exists
-Use `confluence_search_pages` to search for a page with that exact title in the configured space.
-- **Found** → proceed to Step 6 (update)
-- **Not found** → proceed to Step 7 (create)
-
-### Step 6 — Update existing page
-Call `confluence_update_page` with:
-- `pageId`: the ID from the search result
-- `bodyStorageValue`: the **storage format HTML** converted in Step 4
-- Version comment: the `[comment]` argument (or "Updated via vsaf-push-prd" if blank)
-
-Confirm the two-stage update prompt if the MCP requires it.
-
-### Step 7 — Create new page
-Call `confluence_create_page` with:
-- `spaceKey`: the space key from config
-- `parentId`: the parent page ID resolved in Step 3
-- `title`: the page title determined in Step 3
-- `bodyStorageValue`: the **storage format HTML** converted in Step 4
-
-> The `bodyStorageValue` parameter takes Confluence Storage Format (XHTML) directly — do not add a separate `representation` field.
-
-### Step 8 — Output to user
-```
-## PRD pushed to Confluence
-
-- Page:    {page_title}
-- Action:  [Created / Updated]
-- Space:   {space_key}
-- Comment: {comment}
-- URL:     {confluence_page_url}
-
-## Next step
-Run /vsaf-push-srs to also publish the SRS, or continue with /vsaf-build
-```
-
-## Notes
-- Never push a PRD that has failed `/vsaf-validate-prd` validation
-- If the Confluence MCP is not configured, tell the user to run `vsaf init` and enter their token
-- Do not modify the local file during this step
-- The file argument accepts any markdown file path or directory, not just files under `.vsaf/`

package/tools/skills/vsaf-push-srs/SKILL.md

@@ -1,166 +0,0 @@
----
-name: vsaf-push-srs
-description: Push SRS document to Confluence. Use after /vsaf-doc-srs or SRS edits to publish or update the SRS page on Confluence. Accepts an optional comment as version note.
----
-
-# VSAF Push SRS
-
-## Objective
-Publish the current SRS to Confluence — create a new page if it doesn't exist, or update the existing one. The comment becomes the Confluence version note.
-
-## Input
-- `[file]` — optional path to a specific markdown file or directory (defaults to scanning `.vsaf/docs/srs/*.md`)
-- `[comment]` — optional version note (e.g. "Initial draft", "Revised after tech review")
-
-## Prerequisites
-- Confluence MCP must be configured (`vsaf init` sets this up)
-- An SRS markdown file must exist
-
-## Steps
-
-### Step 1 — Find SRS file(s)
-- If a **directory path** was given (e.g. `@docs/srs/`): read all `*.md` files in that directory (excluding `*-results.md`) and combine them into a single page body, separated by `<hr/>`. Use the directory name as the page title base.
-- If a **specific file path** was given: use that file directly.
-- Otherwise: list files in `.vsaf/docs/srs/` matching `*.md` (exclude `*-results.md`)
-  - If multiple found: ask user which one to push
-  - If none found: STOP — tell user to run `/vsaf-doc-srs` first
-- Read full file content
-
-### Step 2 — Load Confluence config
-Read `.vsaf/_bmad/bmm/config.yaml` and extract:
-- `confluence_space_key` — Confluence space (e.g. `PROJ`)
-- `confluence_parent_page` — parent page title (e.g. `Project Documentation`)
-
-If either field is missing or empty:
-- Ask user: "Enter Confluence space key (e.g. PROJ):"
-- Ask user: "Enter parent page title in Confluence (blank = root of space):"
-- Save answers back to config so the user is not asked again
-
-### Step 3 — Determine page title and parent page ID
-- If file is from `srs-*.md` or `SRS-*.md`: title = `[SRS] {Feature Name}` (derive from filename)
-- If input was a directory: title = the numbered section label provided by the user
-- Otherwise: use the first `# Heading` in the file as the page title, or the filename stem if no heading found
-
-**Resolve parent page ID:**
-Use `confluence_search_pages` to search for the parent page title in the configured space. Extract the `id` field from the result — this is the `parentId` needed for page creation. Do NOT skip this step.
-
-### Step 4 — Convert markdown → Confluence storage format
-
-**CRITICAL RULES — read before writing a single tag:**
-
-1. **Never send raw markdown.** All content must be converted to Confluence Storage Format (XHTML).
-2. **Never wrap the entire body in `<![CDATA[...]]>`.** CDATA is ONLY valid inside `<ac:plain-text-body>` within code macros.
-3. **All Confluence macro attributes MUST use the `ac:` namespace prefix.** The tag is `<ac:parameter ac:name="...">`, never `<parameter name="...">`. Wrong namespace = XML parse error.
-4. **Escape HTML entities in regular text:** `&` → `&amp;`, `<` → `&lt;`, `>` → `&gt;`.
-5. **Every opened tag must be closed.** Confluence's XML parser is strict — an unclosed tag aborts the entire page push.
-
-**Block elements:**
-```
-# Heading      → <h1>Heading</h1>
-## Heading     → <h2>Heading</h2>
-### Heading    → <h3>Heading</h3>
-#### Heading   → <h4>Heading</h4>
-paragraph text → <p>paragraph text</p>
----            → <hr/>
-```
-
-**Inline elements:**
-```
-**bold**       → <strong>bold</strong>
-*italic*       → <em>italic</em>
-`inline code`  → <code>inline code</code>
-[text](url)    → <a href="url">text</a>
-```
-
-**Lists:**
-```
-- item         → <ul><li>item</li></ul>
-1. item        → <ol><li>item</li></ol>
-```
-
-**Tables:**
-```
-| H1 | H2 |   →  <table><tbody>
-|----|----| →       <tr><th>H1</th><th>H2</th></tr>
-| a  | b  |          <tr><td>a</td><td>b</td></tr>
-               </tbody></table>
-```
-
-**Code blocks — the ONLY correct place for CDATA:**
-```
-```lang                →  <ac:structured-macro ac:name="code">
-code here                   <ac:parameter ac:name="language">lang</ac:parameter>
-```                          <ac:plain-text-body><![CDATA[code here]]></ac:plain-text-body>
-                           </ac:structured-macro>
-```
-⚠️ The attribute is `ac:name` not `name`. Using `<ac:parameter name="language">` will cause an XML parse error.
-
-**Info/warning/tip boxes:**
-```
-> [!NOTE] title   →  <ac:structured-macro ac:name="info">
-> body                  <ac:parameter ac:name="title">title</ac:parameter>
-                        <ac:rich-text-body><p>body</p></ac:rich-text-body>
-                      </ac:structured-macro>
-
-> [!WARNING]      →  ac:name="warning"
-> [!TIP]          →  ac:name="tip"
-```
-
-**Blockquote:**
-```
-> text            → <blockquote><p>text</p></blockquote>
-```
-
-### Step 5 — Check if page exists
-Use `confluence_search_pages` to search for a page with that exact title in the configured space.
-- **Found** → proceed to Step 6 (update)
-- **Not found** → proceed to Step 7 (create)
-
-### Step 6 — Update existing page
-Call `confluence_update_page` with:
-- `pageId`: the ID from the search result
-- `bodyStorageValue`: the **storage format HTML** converted in Step 4
-- Version comment: the `[comment]` argument (or "Updated via vsaf-push-srs" if blank)
-
-Confirm the two-stage update prompt if the MCP requires it.
-
-### Step 7 — Create new page
-Call `confluence_create_page` with:
-- `spaceKey`: the space key from config
-- `parentId`: the parent page ID resolved in Step 3
-- `title`: the page title determined in Step 3
-- `bodyStorageValue`: the **storage format HTML** converted in Step 4
-
-> The `bodyStorageValue` parameter takes Confluence Storage Format (XHTML) directly — do not add a separate `representation` field.
-
-### Step 8 — Link SRS page to PRD page (if PRD page exists)
-- Search Confluence for the corresponding `[PRD] {feature-name}` page
-- If found: prepend this block at the top of the SRS content before pushing:
-  ```xml
-  <ac:structured-macro ac:name="info">
-    <ac:parameter ac:name="title">Related Documents</ac:parameter>
-    <ac:rich-text-body><p><a href="{prd_url}">[PRD] {feature-name}</a></p></ac:rich-text-body>
-  </ac:structured-macro>
-  ```
-- This creates traceability in Confluence
-
-### Step 9 — Output to user
-```
-## SRS pushed to Confluence
-
-- Page:     {page_title}
-- Action:   [Created / Updated]
-- Space:    {space_key}
-- Comment:  {comment}
-- URL:      {confluence_page_url}
-- PRD link: [linked / not found]
-
-## Next step
-Run /vsaf-test to generate testcases from this SRS, or /vsaf-build to implement
-```
-
-## Notes
-- If the Confluence MCP is not configured, tell the user to run `vsaf init` and enter their token
-- Do not modify the local file during this step
-- SRS result files (`*-results.md`) are test outputs — push those separately if needed
-- The file argument accepts any markdown file path or directory, not just files under `.vsaf/`

package/tools/skills/vsaf-retro/SKILL.md

@@ -1,94 +0,0 @@
----
-name: vsaf-retro
-description: Sprint/epic retrospective — data-backed, not opinion-based. Uses GitNexus metrics + BMAD retrospective. Run at end of sprint or end of epic.
----
-
-# VSAF Retro
-
-## Objective
-Run a retrospective based on real data from GitNexus (changes, health, module status) combined with the BMAD retrospective framework. Output: action items for the next sprint.
-
-## When to run
-- End of each sprint
-- End of each epic
-- **Separate from `/vsaf-ship`** — retro reviews the entire sprint/epic, not a single feature
-
-## Prerequisites
-- Sprint/epic has been completed (all features shipped or deferred)
-- GitNexus index is up to date (`vsaf index`)
-
-## Steps
-
-### Step 1 — Collect sprint changes (GitNexus)
-- Run `gitnexus_detect_changes({scope: "compare", base_ref: "<sprint-start-tag>"})`
-  - If no sprint tag exists: use `base_ref: "main"` or the commit hash from the start of the sprint
-- Collect: total files changed, symbols changed, processes affected
-- Record actual scope vs planned scope
-
-### Step 2 — Codebase health metrics (GitNexus)
-- Read `gitnexus://repo/{name}/context` — get health metrics after the sprint:
-  - Codebase size, complexity trends
-  - Index freshness
-  - Symbol/relationship counts
-- Compare with the start of the sprint if a baseline exists
-
-### Step 3 — Module health check (GitNexus)
-- Run `gitnexus_group_status` — check health of each module
-- Identify: which modules degraded during the sprint? Which modules improved?
-- Flag: modules with increased technical debt, modules needing attention
-
-### Step 4 — Retrospective analysis (BMAD)
-- Use skill `bmad-retrospective` with data from Steps 1-3 as input
-- Framework: What went well / What to improve / Action items
-- Data-backed: each observation must have evidence from GitNexus metrics
-- Do not accept vague statements — must have data support
-
-### Step 5 — Sprint metrics summary (BMAD)
-- Use skill `bmad-sprint-status` to compile final sprint metrics
-- Metrics: velocity, completion rate, scope change ratio
-- Compare with previous sprint if historical data is available
-
-### Step 6 — Output for user
-```
-## Sprint Retrospective: [sprint name/number]
-Date: [YYYY-MM-DD]
-
-### Sprint Scope
-- Planned: [N features/stories]
-- Completed: [N]
-- Deferred: [N]
-- Scope change: [+N/-N]
-
-### Codebase Impact (from GitNexus)
-- Files changed: [N]
-- Symbols changed: [N]
-- Processes affected: [N]
-- Modules touched: [list]
-
-### Module Health
-| Module | Status | Trend | Notes |
-|--------|--------|-------|-------|
-| ...    | ...    | ↑/↓/→ | ...   |
-
-### What Went Well (data-backed)
-- [observation] — evidence: [metric/data]
-
-### What To Improve (data-backed)
-- [observation] — evidence: [metric/data]
-
-### Action Items for Next Sprint
-| # | Action | Owner | Priority |
-|---|--------|-------|----------|
-| 1 | ...    | ...   | ...      |
-
-### Sprint Metrics
-- Velocity: [points/tasks]
-- Completion rate: [%]
-- Avg cycle time: [days]
-```
-
-## Notes
-- Retro must be data-backed — do not accept "I feel like..." without evidence
-- If GitNexus index is stale: run `vsaf index` before the retro
-- Action items must be actionable and have an owner — do not write vague "improve testing"
-- Save retro output to `.vsaf/docs/implementation-artifacts/retro-[sprint].md` to track historical data

package/tools/skills/vsaf-ship/SKILL.md

@@ -1,142 +0,0 @@
----
-name: vsaf-ship
-description: Multi-layer review + ship code. Used after /vsaf-build and /vsaf-test run when code + tests have passed. The final step of every feature.
----
-
-# VSAF Ship
-
-## Applied Rules
-
-> These rules are enforced as gates before shipping. Code that violates them cannot be merged.
-
-| Rule | File | Gate |
-|------|------|------|
-| Run Verification After Coding | `.vsaf/rules/dev/java/run_verification_after_coding.md` | Step 1 (pre-review) |
-| SonarQube Coding Standard | `.vsaf/rules/dev/java/sonarqube_coding_standard.md` | Step 2 (code review) |
-| Java Project Development Rules | `.vsaf/rules/dev/java/java_Project_Development_Rules.md` | Step 2 (code review) |
-
-## Objective
-Multi-layer review, verify scope, validate architecture, push PR. Ensure code has passed all gates before shipping.
-
-## Prerequisites
-- Have run `/vsaf-build` with PRD + SRS + testcase
-- Have run `/vsaf-test run` — results file exists at `.vsaf/docs/testcases/[feature]-results.md`
-- Ship gate from `/vsaf-test run` = PASS
-- No failing tests
-
-## Steps
-
-### Step 0 — Scope check (GitNexus, mandatory)
-- Run `gitnexus_detect_changes({scope: "compare", base_ref: "main"})`
-- Confirm only the expected files/symbols have changed
-- If unexpected changes are detected: **STOP** — review before proceeding
-
-### Step 1 — Verification gate (mandatory — before any review)
-- Read `.vsaf/rules/dev/java/run_verification_after_coding.md` and confirm all 5 acceptance criteria are met:
-  - [ ] Code compiles with zero errors
-  - [ ] All existing tests pass
-  - [ ] Application starts without errors
-  - [ ] The changed feature/endpoint was manually triggered and returned the expected result
-  - [ ] No new `ERROR` log lines appear on the happy path
-- If any criterion is NOT met: **STOP** — fix before proceeding to review
-
-### Step 2 — Structured review handoff (Superpowers)
-- Use `superpowers:requesting-code-review` to create a structured handoff:
-  - What changed and why
-  - What to watch for (risk areas)
-  - Context for the reviewer
-- This handoff is the input for the subsequent review layers
-
-### Step 3 — Review Layer 1: Code Review + SonarQube Gate
-- **If Superpowers is available**: use `superpowers:code-review`
-- **If not**: use skill `bmad-code-review`
-- Check: code structure, naming, patterns, SOLID principles
-- **SonarQube gate** (mandatory for Java projects — read `.vsaf/rules/dev/java/sonarqube_coding_standard.md`):
-  - Zero Blocker or Critical issues — must fix before merge, no exceptions
-  - Zero bugs (`squid:S2259` null deref, `squid:S2095` unclosed resources, `squid:S3655` Optional.get without check)
-  - Zero vulnerabilities (no hardcoded credentials, no SQL injection, no sensitive data in logs)
-  - No `System.out.println` / `e.printStackTrace()` — use SLF4J
-  - Coverage ≥80% on new code; Technical Debt Ratio ≤5%
-  - Duplications <3% on new code
-  - Run locally: `mvn clean verify sonar:sonar -Dsonar.projectKey=<key> -Dsonar.host.url=http://localhost:9000 -Dsonar.login=<token>`
-- **Java rules gate** (mandatory for Java projects — read `.vsaf/rules/dev/java/java_Project_Development_Rules.md`):
-  - Methods ≤40 lines, nesting ≤3 levels, `@Transactional` only at service layer
-- Fix issues if any, re-commit
-
-#### Step 3b — Handle reviewer feedback (if any)
-- If the review has feedback that needs to be addressed:
-  - Use `superpowers:receiving-code-review` — systematic response, no ad-hoc fixes
-  - Fix → re-commit → re-review if needed
-
-### Step 4 — Review Layer 1.5: Adversarial Review
-- Use skill `bmad-review-adversarial-general` — cynical attack on new code
-  - Look for: logic flaws, security holes, performance traps, silent failures
-- Use skill `bmad-review-edge-case-hunter` — exhaustive boundary analysis
-  - Look for: unhandled null/empty, off-by-one, concurrent access, resource leaks
-- Triage findings:
-  - **MUST FIX**: fix immediately before shipping
-  - **SHOULD FIX**: create a follow-up task
-  - **NOTED**: acknowledged, no action needed
-
-### Step 5 — Architectural constraint check (GitNexus)
-- Run `gitnexus_shape_check` — validate no architectural constraints are violated
-- If there are violations: **STOP** — fix before proceeding
-
-### Step 6 — Review Layer 2: Knowledge graph sync
-- Run `vsaf index` (= `gitnexus analyze`)
-- Update the call graph to reflect the new code
-- This is the final layer — ensure the index accurately reflects the current code state
-
-### Step 7 — Final verification gate (Superpowers)
-- Use `superpowers:verification-before-completion`
-- Confirm all deliverables match the spec — not just "tests pass"
-- This is the final gate before PR
-
-### Step 8 — Pre-PR checklist (Superpowers)
-- **If Superpowers is available**: use `superpowers:finishing-a-development-branch` — automated pre-PR checklist
-- **If not**: check manually:
-  - [ ] Tests pass
-  - [ ] No uncommitted changes
-  - [ ] Branch up-to-date with main
-  - [ ] Test results file exists
-  - [ ] All MUST FIX resolved
-
-### Step 9 — Push PR
-```bash
-git push origin feature/<name>
-```
-PR description must include:
-- Impact summary (from GitNexus detect_changes)
-- Test results file path: `.vsaf/docs/testcases/[feature]-results.md`
-- Adversarial triage: MUST FIX: 0, SHOULD FIX: N, NOTED: N
-- Shape check result
-
-### Step 10 — Output to user
-```
-## Ship Complete: [feature]
-
-### Reviews
-- Scope check (detect_changes):  PASS — [N files, N symbols changed]
-- Verification gate:             PASS [compile ✓, tests ✓, run ✓, endpoint ✓]
-- Layer 1 (Code Review):         PASS [superpowers / bmad-code-review]
-- SonarQube gate:                PASS [Blockers: 0, Criticals: 0, Coverage: X%]
-- Layer 1.5 (Adversarial):       PASS [MUST FIX: 0, SHOULD FIX: N, NOTED: N]
-- Shape check:                   PASS
-- Layer 2 (Graph sync):          PASS
-- Final verification:            PASS
-- Pre-PR checklist:              PASS
-
-### PR
-- Branch: feature/[name]
-- PR: [link]
-- Test results: .vsaf/docs/testcases/[feature]-results.md
-
-## Next step
-- Run /vsaf-retro if this is the end of a sprint/epic
-- Or /vsaf-plan <next-feature> for the next task
-```
-
-## Notes
-- Do not ship if any gate fails or there are remaining MUST FIX items
-- Test results file is a mandatory input — no results = no ship
-- Retrospective is a separate skill (`/vsaf-retro`) — run at the end of a sprint, not at the end of every feature