@ngocsangairvds/vsaf 3.1.26 → 3.2.1

package/tools/skills/vds-scripts-skill/references/validation-commands.md

@@ -0,0 +1,15 @@
+# Validation Commands
+
+Representative WHO validation and docs command families:
+
+- `vds-cli openapi ...`
+- `vds-cli links ...`
+- `vds-cli structure ...`
+- `vds-cli schema ...`
+- `vds-cli pdf ...`
+- `vds-cli diagrams ...`
+- `vds-cli excel ...`
+- `vds-cli google-sheets ...`
+- `vds-markdown ...`
+
+Use specialist docs or package READMEs for deeper command coverage.

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

@@ -5,6 +5,16 @@ description: Implement code following existing PRD + SRS + testcases. Use after
 
 # VSAF Build
 
+## Applied Rules
+
+> These rules apply to all code implemented through this flow. Read the full rule before proceeding.
+
+| Rule | File | Applies to |
+|------|------|------------|
+| Run Verification After Coding | `.vsaf/rules/dev/java/run_verification_after_coding.md` | Every task implementation |
+| SonarQube Coding Standard | `.vsaf/rules/dev/java/sonarqube_coding_standard.md` | Java projects only |
+| Java Project Development Rules | `.vsaf/rules/dev/java/java_Project_Development_Rules.md` | Java projects only |
+
 ## Objective
 Implement code strictly following PRD, SRS, and testcases, one task at a time, with TDD — ensuring each commit has tests passing AND is verified against spec.
 
@@ -57,6 +67,21 @@ Implement code strictly following PRD, SRS, and testcases, one task at a time, w
   - Have a clear verification step
   - Be small enough for 1 commit
 
+### Step 2.5 — Code Quality Gate (mandatory for Java projects)
+
+Before writing any code, confirm the quality baseline:
+
+- Read `.vsaf/rules/dev/java/sonarqube_coding_standard.md` — internalize all rules (zero Critical/Blocker, ≥80% new-code coverage, no `System.out`, no hardcoded credentials, etc.)
+- Read `.vsaf/rules/dev/java/java_Project_Development_Rules.md` — enforce: methods ≤40 lines, nesting ≤3 levels, `@Transactional` at service layer only, coverage ≥70%
+- During every task implementation, actively prevent violations:
+  - Use SLF4J logger — never `System.out.println` / `e.printStackTrace()`
+  - Use try-with-resources for all closeable resources
+  - Null-check before dereferencing, use `Optional.orElseThrow()` not `.get()`
+  - Extract constants for string literals repeated ≥3 times
+  - Keep cognitive complexity ≤15 and cyclomatic complexity ≤10 per method
+- After each task commit: mentally verify no SonarQube Blocker/Critical rules were introduced
+- If the project is **not Java**: skip this step
+
 ### Step 2b — Subagent dispatch (large plans, optional)
 - If plan has ≥ 20 tasks AND HAS_SUPERPOWERS: use `superpowers:subagent-driven-development`
   - Dispatch tasks to sub-agents with a two-phase review pipeline
@@ -73,9 +98,14 @@ Implement code strictly following PRD, SRS, and testcases, one task at a time, w
 
 - After each task, run sequentially:
   1. `mcp__gitnexus__detect_changes` — verify only the expected files changed
-  2. **Verification against spec** (mandatory):
-     - **If HAS_SUPERPOWERS**: use `superpowers:verification-before-completion` — confirm outcome matches SRS intent, not just "tests pass"
+  2. **Verification against spec** (mandatory) — follow `.vsaf/rules/dev/java/run_verification_after_coding.md`:
+     - Compile with zero errors (`mvn clean compile` for Maven, equivalent for other build tools)
+     - Run all tests — all must pass (`mvn test`)
+     - Start the application — confirm it boots with no errors
+     - Trigger the changed endpoint/logic with a real request and confirm the response
+     - **If HAS_SUPERPOWERS**: additionally use `superpowers:verification-before-completion` — confirm outcome matches SRS intent
      - **If not**: self-verify: re-read the corresponding FR/NFR in SRS, confirm behavior is correct, record verification result
+     - If full environment is unavailable: use Docker Compose / Testcontainers / mock boundary — do NOT skip verification
   3. Commit: `git commit -m "<type>: <task description>"`
 
 ### Step 3.5 — Checkpoint review (every 3-5 tasks)

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

@@ -9,7 +9,7 @@ description: Push PRD document to Confluence. Use after /vsaf-doc-prd or /vsaf-d
 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 (defaults to scanning `.vsaf/docs/planning-artifacts/prd-*.md`)
+- `[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
@@ -18,11 +18,12 @@ Publish the current PRD to Confluence — create a new page if it doesn't exist,
 
 ## Steps
 
-### Step 1 — Find PRD file
-- If a file path was given as argument, 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
+### 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
@@ -35,16 +36,23 @@ If either field is missing or empty:
 - 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
+### 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
 
-### Step 4 — Convert markdown → Confluence storage format (HTML)
+**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.
 
-**CRITICAL: Never send raw markdown or CDATA-wrapped content to Confluence.**
-**CRITICAL: Do NOT wrap the entire page body in `<![CDATA[...]]>`. CDATA is only valid inside `<ac:plain-text-body>` for code blocks.**
+### Step 4 — Convert markdown → Confluence storage format
 
-Convert the full file content to Confluence storage format using these rules:
+**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:**
 ```
@@ -72,19 +80,20 @@ paragraph text → <p>paragraph text</p>
 
 **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>
+| 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 place CDATA is correct:**
-````
-```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>
-````
+**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:**
 ```
@@ -102,33 +111,27 @@ code here              <ac:parameter ac:name="language">lang</ac:parameter>
 > text            → <blockquote><p>text</p></blockquote>
 ```
 
-When calling the Confluence MCP create/update tool, set the content representation to **`storage`**.
-
 ### Step 5 — Check if page exists
-Use the `confluence` MCP to search for a page with that exact title in the configured space:
-```
-CQL: title = "{page_title}" AND space = "{space_key}"
-```
+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 the `confluence` MCP update tool with:
-- Page ID from search result
-- Content: the **converted wiki markup** from Step 4
-- Representation: `wiki`
+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 the `confluence` MCP create tool with:
-- Space key from config
-- Parent page title from config (find its ID first if needed)
-- Title: determined in Step 3
-- Content: the **converted wiki markup** from Step 4
-- Representation: `wiki`
-- Version comment: the `[comment]` argument (or "Created via vsaf-push-prd" if blank)
+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
 ```
@@ -148,4 +151,4 @@ Run /vsaf-push-srs to also publish the SRS, or continue with /vsaf-build
 - 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, not just files under `.vsaf/`
+- The file argument accepts any markdown file path or directory, not just files under `.vsaf/`

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

@@ -9,7 +9,7 @@ description: Push SRS document to Confluence. Use after /vsaf-doc-srs or SRS edi
 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 (defaults to scanning `.vsaf/docs/srs/*.md`)
+- `[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
@@ -18,11 +18,12 @@ Publish the current SRS to Confluence — create a new page if it doesn't exist,
 
 ## Steps
 
-### Step 1 — Find SRS file
-- If a file path was given as argument, 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
+### 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
@@ -35,16 +36,23 @@ If either field is missing or empty:
 - 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
+### 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
 
-### Step 4 — Convert markdown → Confluence storage format (HTML)
+**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.
 
-**CRITICAL: Never send raw markdown or CDATA-wrapped content to Confluence.**
-**CRITICAL: Do NOT wrap the entire page body in `<![CDATA[...]]>`. CDATA is only valid inside `<ac:plain-text-body>` for code blocks.**
+### Step 4 — Convert markdown → Confluence storage format
 
-Convert the full file content to Confluence storage format using these rules:
+**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:**
 ```
@@ -72,19 +80,20 @@ paragraph text → <p>paragraph text</p>
 
 **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>
+| 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 place CDATA is correct:**
-````
-```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>
-````
+**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:**
 ```
@@ -102,37 +111,31 @@ code here              <ac:parameter ac:name="language">lang</ac:parameter>
 > text            → <blockquote><p>text</p></blockquote>
 ```
 
-When calling the Confluence MCP create/update tool, set the content representation to **`storage`**.
-
 ### Step 5 — Check if page exists
-Use the `confluence` MCP to search for a page with that exact title in the configured space:
-```
-CQL: title = "{page_title}" AND space = "{space_key}"
-```
+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 the `confluence` MCP update tool with:
-- Page ID from search result
-- Content: the **converted wiki markup** from Step 4
-- Representation: `wiki`
+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 the `confluence` MCP create tool with:
-- Space key from config
-- Parent page title from config (find its ID first if needed)
-- Title: determined in Step 3
-- Content: the **converted wiki markup** from Step 4
-- Representation: `wiki`
-- Version comment: the `[comment]` argument (or "Created via vsaf-push-srs" if blank)
+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 storage-format block at the top of the SRS content before pushing:
+- 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>
@@ -160,4 +163,4 @@ Run /vsaf-test to generate testcases from this SRS, or /vsaf-build to implement
 - 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, not just files under `.vsaf/`
+- The file argument accepts any markdown file path or directory, not just files under `.vsaf/`

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

@@ -5,6 +5,16 @@ description: Multi-layer review + ship code. Used after /vsaf-build and /vsaf-te
 
 # 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.
 
@@ -21,25 +31,44 @@ Multi-layer review, verify scope, validate architecture, push PR. Ensure code ha
 - Confirm only the expected files/symbols have changed
 - If unexpected changes are detected: **STOP** — review before proceeding
 
-### Step 1 — Structured review handoff (Superpowers)
+### 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 2 — Review Layer 1: Code Review
+### 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 2b — Handle reviewer feedback (if any)
+#### 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 3 — Review Layer 1.5: Adversarial Review
+### 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
@@ -49,21 +78,21 @@ Multi-layer review, verify scope, validate architecture, push PR. Ensure code ha
   - **SHOULD FIX**: create a follow-up task
   - **NOTED**: acknowledged, no action needed
 
-### Step 4 — Architectural constraint check (GitNexus)
+### 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 5 — Review Layer 2: Knowledge graph sync
+### 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 6 — Final verification gate (Superpowers)
+### 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 7 — Pre-PR checklist (Superpowers)
+### 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
@@ -72,7 +101,7 @@ Multi-layer review, verify scope, validate architecture, push PR. Ensure code ha
   - [ ] Test results file exists
   - [ ] All MUST FIX resolved
 
-### Step 8 — Push PR
+### Step 9 — Push PR
 ```bash
 git push origin feature/<name>
 ```
@@ -82,13 +111,15 @@ PR description must include:
 - Adversarial triage: MUST FIX: 0, SHOULD FIX: N, NOTED: N
 - Shape check result
 
-### Step 9 — Output to user
+### 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

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

@@ -5,6 +5,14 @@ description: "Two modes: (1) generate testcases from SRS — used after /vsaf-do
 
 # VSAF Test
 
+## Applied Rules
+
+> The run-verification rule applies to **Mode 2 (run)** only. Test generation (Mode 1) is a documentation activity.
+
+| Rule | File | Applies to |
+|------|------|------------|
+| Run Verification After Coding | `.vsaf/rules/dev/java/run_verification_after_coding.md` | Mode 2: Run — executing tests + recording results |
+
 ## Mode distinction
 
 | Command | Mode | Goal |

package/tools/vds-scripts/.mcp.json

@@ -0,0 +1,11 @@
+{
+  "mcpServers": {
+    "code-review-graph": {
+      "command": "uvx",
+      "args": [
+        "code-review-graph",
+        "serve"
+      ]
+    }
+  }
+}

package/tools/vds-scripts/.secrets.baseline

@@ -0,0 +1,133 @@
+{
+  "version": "1.5.0",
+  "plugins_used": [
+    {
+      "name": "ArtifactoryDetector"
+    },
+    {
+      "name": "AWSKeyDetector"
+    },
+    {
+      "name": "AzureStorageKeyDetector"
+    },
+    {
+      "name": "Base64HighEntropyString",
+      "limit": 4.5
+    },
+    {
+      "name": "BasicAuthDetector"
+    },
+    {
+      "name": "CloudantDetector"
+    },
+    {
+      "name": "DiscordBotTokenDetector"
+    },
+    {
+      "name": "GitHubTokenDetector"
+    },
+    {
+      "name": "GitLabTokenDetector"
+    },
+    {
+      "name": "HexHighEntropyString",
+      "limit": 3.0
+    },
+    {
+      "name": "IbmCloudIamDetector"
+    },
+    {
+      "name": "IbmCosHmacDetector"
+    },
+    {
+      "name": "IPPublicDetector"
+    },
+    {
+      "name": "JwtTokenDetector"
+    },
+    {
+      "name": "KeywordDetector",
+      "keyword_exclude": ""
+    },
+    {
+      "name": "MailchimpDetector"
+    },
+    {
+      "name": "NpmDetector"
+    },
+    {
+      "name": "OpenAIDetector"
+    },
+    {
+      "name": "PrivateKeyDetector"
+    },
+    {
+      "name": "PypiTokenDetector"
+    },
+    {
+      "name": "SendGridDetector"
+    },
+    {
+      "name": "SlackDetector"
+    },
+    {
+      "name": "SoftlayerDetector"
+    },
+    {
+      "name": "SquareOAuthDetector"
+    },
+    {
+      "name": "StripeDetector"
+    },
+    {
+      "name": "TelegramBotTokenDetector"
+    },
+    {
+      "name": "TwilioKeyDetector"
+    }
+  ],
+  "filters_used": [
+    {
+      "path": "detect_secrets.filters.allowlist.is_line_allowlisted"
+    },
+    {
+      "path": "detect_secrets.filters.common.is_ignored_due_to_verification_policies",
+      "min_level": 2
+    },
+    {
+      "path": "detect_secrets.filters.heuristic.is_indirect_reference"
+    },
+    {
+      "path": "detect_secrets.filters.heuristic.is_likely_id_string"
+    },
+    {
+      "path": "detect_secrets.filters.heuristic.is_lock_file"
+    },
+    {
+      "path": "detect_secrets.filters.heuristic.is_not_alphanumeric_string"
+    },
+    {
+      "path": "detect_secrets.filters.heuristic.is_potential_uuid"
+    },
+    {
+      "path": "detect_secrets.filters.heuristic.is_prefixed_with_dollar_sign"
+    },
+    {
+      "path": "detect_secrets.filters.heuristic.is_sequential_string"
+    },
+    {
+      "path": "detect_secrets.filters.heuristic.is_swagger_file"
+    },
+    {
+      "path": "detect_secrets.filters.heuristic.is_templated_secret"
+    },
+    {
+      "path": "detect_secrets.filters.regex.should_exclude_file",
+      "pattern": [
+        ".*"
+      ]
+    }
+  ],
+  "results": {},
+  "generated_at": "2026-01-29T05:10:47Z"
+}