@ngocsangairvds/vsaf 5.1.4 → 5.1.6

package/skills/sdlc/feature-complete/SKILL.md

@@ -1,159 +0,0 @@
----
-name: sdlc-feature-complete
-description: Phase 8 — Feature Completion — update CONTEXT, KNOWLEDGE, GitNexus re-index, Graphify rebuild + verify
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Phase 8: Feature Complete
-
-You are Knowledge Engineer + DevOps. Mission: update all project knowledge after review is APPROVED — BEFORE shipping.
-
-**Why this phase comes BEFORE ship:** Ensures shared knowledge (CONTEXT.md, KNOWLEDGE.md) is updated and committed with the PR, so team members can understand the feature as soon as they pull code.
-
-## Progress Protocol
-
-Print progress at each step in this format:
-```
-[FEATURE-COMPLETE] [step/5] description... ⏳
-[FEATURE-COMPLETE] [step/5] description... ✅
-```
-
-## 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
-
-```
-[FEATURE-COMPLETE] [1/5] Checking prerequisites... ⏳
-```
-
-1. Input: Feature name `$ARGUMENTS`
-2. Check that `.vsaf/docs/features/{feature-name}/08-review.md` exists
-3. Check for **Gate: APPROVED** in `08-review.md`
-   - No Gate APPROVED → Stop: "Review has not been approved. Run `/sdlc-review` first."
-4. Read `.vsaf/docs/STATUS.md`
-5. Read `CONTEXT.md`
-
-```
-[FEATURE-COMPLETE] [1/5] Checking prerequisites... ✅
-```
-
-## Tasks
-
-### Step 2: Update CONTEXT.md
-
-```
-[FEATURE-COMPLETE] [2/5] Updating CONTEXT.md — extracting new terminology... ⏳
-```
-
-Read all artifacts in `.vsaf/docs/features/{feature-name}/`:
-- Extract new terminology that emerged during the development process
-- Append to `CONTEXT.md` §Shared Language table
-- Only add terminology that is TRULY new — no duplicates
-
-```
-[FEATURE-COMPLETE] [2/5] Updating CONTEXT.md... ✅
-```
-
-### Step 3: Update KNOWLEDGE.md
-
-```
-[FEATURE-COMPLETE] [3/5] Updating KNOWLEDGE.md — patterns, decisions, gotchas... ⏳
-```
-
-Append to `.vsaf/docs/KNOWLEDGE.md`:
-- Lessons learned (patterns, anti-patterns)
-- Noteworthy decisions (from ADR)
-- Gotchas discovered during implementation
-
-Format:
-```markdown
-## {feature-name} ({date})
-- **Pattern**: {pattern learned}
-- **Decision**: {key decision and rationale}
-- **Gotcha**: {unexpected issue and solution}
-```
-
-```
-[FEATURE-COMPLETE] [3/5] Updating KNOWLEDGE.md... ✅
-```
-
-### Step 4: Re-index GitNexus
-
-```
-[FEATURE-COMPLETE] [4/5] Re-index GitNexus + Rebuild Graphify graph... ⏳
-```
-
-1. Run GitNexus `group_sync` — re-index the latest code structure
-   - MUST run BEFORE Graphify (Graphify needs the latest code structure)
-
-2. Run `/graphify` — rebuild graph with **docs only** (DO NOT rebuild code graph)
-   - Target: `.vsaf/docs/` folder — documents, artifacts, CONTEXT.md, KNOWLEDGE.md only
-   - Output: `graphify-out/graph.json` updated
-
-3. Claude verifies graph:
-   - Do new domain terms from CONTEXT.md have nodes in the graph?
-   - Do new patterns from KNOWLEDGE.md have nodes/edges?
-   - Are feature artifacts linked correctly?
-   - If missing → add to `graph.json`
-
-**This is the ONLY phase (besides onboard) allowed to modify `graphify-out/` and `.gitnexus/`.**
-
-```
-[FEATURE-COMPLETE] [4/5] Re-index GitNexus + Rebuild Graphify graph... ✅
-```
-
-### Step 5: Update STATUS.md
-
-```
-[FEATURE-COMPLETE] [5/5] Updating STATUS.md... ⏳
-```
-
-Update `.vsaf/docs/STATUS.md`:
-- Move feature to "Knowledge Updated" status
-- Record completion timestamp
-
-```
-[FEATURE-COMPLETE] [5/5] Updating STATUS.md... ✅
-```
-
-## Output
-
-Print FEATURE COMPLETE REPORT:
-
-```
-═══════════════════════════════════════════
-  FEATURE COMPLETE: {feature-name}
-═══════════════════════════════════════════
-  Phase: 8 (Feature Complete — before ship)
-  
-  Knowledge updates:
-    - CONTEXT.md: +{N} domain terms
-    - KNOWLEDGE.md: +{N} patterns, +{M} decisions, +{K} gotchas
-    - GitNexus: re-indexed
-    - graph.json: +{N} nodes, +{M} edges (docs only)
-    
-  STATUS: Knowledge Updated — ready to ship
-  
-  Next: `/sdlc-ship` to create PR and ship
-═══════════════════════════════════════════
-```
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-- Output: CONTEXT.md, KNOWLEDGE.md, graph.json, GitNexus index updated
-- Suggestion: `/sdlc-ship` to commit + create PR
-
-Update `.vsaf/docs/STATUS.md`.
-
-## Rules
-
-- KNOWLEDGE.md is append-only — DO NOT edit old entries
-- GitNexus re-index BEFORE Graphify rebuild
-- Graph verification MUST run — do not skip
-- Graphify rebuild is docs only — DO NOT rebuild code graph in this phase
-- **This is the ONLY phase (besides onboard) allowed to modify `graphify-out/` and `.gitnexus/`**
-- This phase MUST run BEFORE ship — so knowledge is committed with the PR

package/skills/sdlc/hotfix-analyze/SKILL.md

@@ -1,198 +0,0 @@
----
-name: sdlc-hotfix-analyze
-description: "Hotfix Phase 1 — Analyze bug report via GitNexus impact + context, identify root cause and blast radius"
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Hotfix Phase 1: Analyze Bug Report
-
-You are a Senior Bug Analyst. Mission: read the tester's bug report, trace root cause via GitNexus, and produce a clear analysis for the fix team.
-
-## Language Rule
-
-Output documents (01-analysis.md) MUST be written in Vietnamese. Only keep English for: IDs, technical terms, code references. The template below shows structure only — write actual content in Vietnamese.
-
-## Progress Protocol
-
-Print progress at each step:
-```
-[HOTFIX-ANALYZE] [step/6] description... ⏳
-[HOTFIX-ANALYZE] [step/6] description... ✅
-```
-
-## Index Protection
-
-⛔ Do NOT modify `graphify-out/` or `.gitnexus/` — READ only.
-
-## Phase Entry Protocol
-
-```
-[HOTFIX-ANALYZE] [1/6] Reading bug report... ⏳
-```
-
-1. Input: `$ARGUMENTS` — path to bug report file from tester
-2. Read the bug report file
-3. Read `CONTEXT.md` for domain context
-4. Read `.vsaf/docs/STATUS.md`
-5. Extract a short `{bug-id}` from the report filename or title (e.g., `fix-null-rating`, `fix-auth-timeout`)
-
-```
-[HOTFIX-ANALYZE] [1/6] Reading bug report... ✅
-```
-
-## Tasks
-
-### Step 2: Grill Session — Clarify Bug Context
-
-```
-[HOTFIX-ANALYZE] [2/6] Grill session — interviewing user about bug... ⏳
-```
-
-Use `/grill-me` to interview the user about the bug. Walk down each branch of the problem tree:
-- What exactly was observed? Under what conditions?
-- Can it be reproduced consistently? What are the exact steps?
-- When did it start? What changed recently?
-- What is the expected behavior vs actual behavior?
-- Which users/environments are affected?
-- Any workarounds discovered?
-
-Continue grilling until you have a complete understanding. Then extract:
-- **Symptoms** — what the tester/user observed
-- **Reproduction steps** — exact steps to trigger the bug
-- **Expected vs actual behavior**
-- **Affected area** — which feature/module/endpoint
-
-```
-[HOTFIX-ANALYZE] [2/6] Grill session complete ✅
-```
-
-### Step 3: Root Cause via GitNexus
-
-```
-[HOTFIX-ANALYZE] [3/6] Mapping code structure via GitNexus... ⏳
-```
-
-1. Use GitNexus `context` — understand the affected module's structure and dependencies
-2. Use GitNexus `impact` — trace which files and symbols are in the blast radius
-3. Use GitNexus `route_map` — map the call chain from entry point to suspected buggy code
-4. Collect:
-   - **Affected files** — files that contain or touch the suspected area
-   - **Call chain** — entry point → intermediate → suspected defect
-   - **Blast radius** — what else could break if this area is changed
-
-```
-[HOTFIX-ANALYZE] [3/6] Mapping code structure via GitNexus... ✅
-```
-
-### Step 4: Deep Thinking — Root Cause Reasoning
-
-```
-[HOTFIX-ANALYZE] [4/6] Deep thinking — reasoning about root cause... ⏳
-```
-
-**Two approaches available — choose based on complexity:**
-
-**Option A: Full approach** — Use `/superpowers:systematic-debugging` for complex, multi-layered bugs where you need structured hypothesis testing with instrumentation.
-
-**Option B: Lean approach (mattpocock)** — Use `/diagnose` for focused bugs where the feedback loop is clear. `/diagnose` provides a disciplined 6-phase loop: build feedback loop → reproduce → hypothesise → instrument → fix → regression-test. Also use `/zoom-out` if the affected code area is unfamiliar.
-
-Regardless of approach:
-
-1. **Read the actual source code** — do NOT rely only on GitNexus metadata. Open and read every file in the call chain identified in Step 3.
-2. **Form hypotheses** — based on symptoms + code reading, list 2-3 possible root causes
-3. **Evaluate each hypothesis:**
-   - Does it explain ALL symptoms from the bug report?
-   - Does it match the reproduction steps?
-   - Is it consistent with the code structure from GitNexus?
-4. **Eliminate** — rule out hypotheses that don't explain all symptoms
-5. **Conclude** — select the most likely root cause with specific file:line reference
-6. **Propose fix strategy** — minimal approach to fix the confirmed root cause
-
-If no hypothesis explains all symptoms → the bug report may be incomplete. List what information is missing.
-
-```
-[HOTFIX-ANALYZE] [4/6] Deep thinking — reasoning about root cause... ✅
-```
-
-### Step 5: Grill Fix Strategy
-
-```
-[HOTFIX-ANALYZE] [5/6] Grill session — stress-testing fix strategy... ⏳
-```
-
-Use `/grill-me` again to stress-test the proposed fix strategy with the user:
-- Does the fix address the root cause, not just the symptom?
-- Are there edge cases the fix could miss?
-- Could the fix introduce regressions in related areas?
-- Is the fix scope appropriate for a hotfix (minimal)?
-
-```
-[HOTFIX-ANALYZE] [5/6] Fix strategy validated ✅
-```
-
-### Step 6: Write Analysis
-
-```
-[HOTFIX-ANALYZE] [6/6] Writing analysis document... ⏳
-```
-
-Create directory `.vsaf/docs/hotfixes/{bug-id}/` if it doesn't exist.
-
-Write file: `.vsaf/docs/hotfixes/{bug-id}/01-analysis.md`
-
-```markdown
-# Bug Analysis: {bug-id}
-
-## Tester Report
-{summary of bug report}
-
-## Symptoms
-{symptoms observed}
-
-## Reproduction Steps
-{reproduction steps}
-
-## Hypotheses
-| # | Hypothesis | Explains all symptoms? | Verdict |
-|---|-----------|----------------------|---------|
-| 1 | {hypothesis} | {yes/no + why} | Eliminated / Selected |
-
-## Root Cause
-{confirmed root cause — specific code defect with file:line references}
-
-## Affected Files
-| File | Role | Severity |
-|------|------|----------|
-| {file} | {role in the bug} | Direct / Indirect |
-
-## Blast Radius
-{what else could break}
-
-## Fix Strategy
-{minimal fix approach — what to change and why}
-```
-
-```
-[HOTFIX-ANALYZE] [6/6] Writing analysis document... ✅
-```
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-- Bug: {bug-id}
-- Status: ANALYSIS COMPLETED
-- Root cause: {one-line summary}
-- Affected files: {count} files
-- Output: `.vsaf/docs/hotfixes/{bug-id}/01-analysis.md`
-- Next step: `/sdlc-hotfix-prd`
-
-Update `.vsaf/docs/STATUS.md`.
-
-## Rules
-
-- ⛔ Do NOT modify code — analysis only
-- ⛔ Do NOT modify `graphify-out/` or `.gitnexus/`
-- GitNexus impact analysis is MANDATORY — never skip it
-- Root cause must reference specific file:line, not vague descriptions
-- `/grill-me` is MANDATORY — used in Step 2 (clarify bug) and Step 5 (validate fix strategy)

package/skills/sdlc/hotfix-implement/SKILL.md

@@ -1,272 +0,0 @@
----
-name: sdlc-hotfix-implement
-description: "Hotfix Phase 3 — TDD implementation: RED → GREEN → REFACTOR, minimal fix, SonarQube-in-loop"
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Hotfix Phase 3: Implementation (TDD)
-
-You are a Senior Software Engineer performing a surgical fix. Mission: implement the fix using strict TDD — write failing test first, make it pass with minimal code, refactor. No subagents, no parallel epics — hotfixes are focused single-area changes.
-
-## Progress Protocol
-
-Print progress at each step:
-```
-[HOTFIX-IMPL] [step/6] description... ⏳
-[HOTFIX-IMPL] [step/6] description... ✅
-```
-
-## Index Protection
-
-⛔ Do NOT modify `graphify-out/` or `.gitnexus/` — READ only.
-
-## Phase Entry Protocol
-
-```
-[HOTFIX-IMPL] [1/6] Checking input artifacts... ⏳
-```
-
-1. Input:
-   - `.vsaf/docs/hotfixes/{bug-id}/02-prd.md`
-   - `.vsaf/docs/hotfixes/{bug-id}/01-analysis.md`
-2. Verify BOTH files exist:
-   - Missing → Stop: "Run previous phases first."
-3. Check `02-prd.md` has `## Gate: APPROVED`
-   - No Gate → Stop: "PRD not approved. Get approval first."
-4. Extract from PRD: FRs, acceptance criteria, scope boundary
-5. Extract from analysis: root cause (file:line), affected files, fix strategy
-6. Read `CONTEXT.md`
-
-```
-[HOTFIX-IMPL] [1/6] Checking input artifacts... ✅
-```
-
-## Tasks
-
-### Step 2: Branch Setup
-
-```
-[HOTFIX-IMPL] [2/6] Creating hotfix branch... ⏳
-```
-
-```bash
-git checkout -b hotfix/{bug-id}
-```
-
-If branch already exists → switch to it.
-
-```
-[HOTFIX-IMPL] [2/6] Creating hotfix branch... ✅
-```
-
-### Step 3: TDD Cycle — `/tdd` Methodology
-
-```
-[HOTFIX-IMPL] [3/6] TDD cycle — RED → GREEN → REFACTOR... ⏳
-```
-
-Use `/tdd` methodology — behavior-based, vertical slice:
-
-**For each FR in the PRD:**
-
-1. **RED — Write failing test FIRST**
-   - Test the BEHAVIOR described in the acceptance criteria
-   - Test the PUBLIC INTERFACE, not internals
-   - Include the regression test: reproduce the original bug → MUST FAIL before fix
-   - Run test → confirm it FAILS (red)
-   - ⚠️ If test passes without code changes → the test is wrong or the bug is already fixed
-
-2. **GREEN — Write MINIMAL code to pass**
-   - Change ONLY what is needed to make the test pass
-   - Stay within the scope boundary from PRD
-   - Apply SonarQube rules while writing (see below)
-   - Run test → confirm it PASSES (green)
-
-3. **REFACTOR — Clean without changing behavior**
-   - Remove duplication introduced by the fix
-   - Improve naming if needed
-   - Run ALL tests → still green
-
-**Repeat for each FR.** Typically 1-3 cycles for a hotfix.
-
-```
-[HOTFIX-IMPL] [3/6] TDD cycle complete ✅
-```
-
-### Step 4: SonarQube Self-Check
-
-```
-[HOTFIX-IMPL] [4/6] SonarQube quality check... ⏳
-```
-
-Apply DURING Step 3 (not after). After the fix is complete, final sweep.
-
-> **Standard (single source of truth):** **`.claude/skills/_shared/sdlc/sonar-viettel/quality-gate.md`** — full gate, 357-rule parameters, and the importable `sonar-viettel-profile.xml` / `sonar-viettel-gate.json`. Phase 4 (`/sdlc-hotfix-review`) re-checks the same file. A hotfix applies the gate's **New Code** conditions on changed files.
-
-| Metric | Threshold |
-|--------|-----------|
-| Issues / Blocker / Critical / Major | = 0 |
-| Code Smells (new) | = 0 — stricter than the gate's ≤20 **by design**: a surgical 1–3 line fix has no excuse to add a smell, and `/sdlc-hotfix-review` rejects any new smell |
-| Vulnerabilities | = 0 |
-| Security Hotspots Reviewed | = 100% |
-| Duplicated Lines (new) | ≤ 45% |
-| Maintainability / Reliability / Security Rating | ≥ A |
-
-**Honour the `sonar-viettel` parametrised rules in the changed code** — S107 (params), S3776 (complexity), S1192 (literals), S2068/S2077 (secrets/injection), S100/S101/S115 (naming). **Thresholds are authoritative in the profile XML** — derive them via the snippet in the shared `quality-gate.md`, do not hard-code numbers.
-
-- If project has SonarQube → import the profile + gate from the shared folder, then run `sonar-scanner` incremental
-- If not → Claude self-reviews changed files against the shared `quality-gate.md`
-
-```
-[HOTFIX-IMPL] [4/6] SonarQube quality check... ✅
-```
-
-### Step 5: Build & Test Verification
-
-```
-[HOTFIX-IMPL] [5/6] Build & test verification... ⏳
-```
-
-**MANDATORY — hard gate:**
-
-1. **Compile**: Build entire project → 0 errors
-   - Java: `mvn compile` / `gradle build`
-   - Node: `npm run build` / `tsc --noEmit`
-   - Angular: `ng build`
-   - Go: `go build ./...`
-   - FAIL → fix immediately
-
-2. **Full test suite**: Run ALL tests (not just new ones)
-   - `npm test` / `mvn test` / equivalent
-   - ALL tests MUST pass — no regressions
-   - FAIL → use `/diagnose` to find the issue
-
-3. **Regression test confirmation**: The specific test from Step 3 RED phase → now PASSES
-
-⚠️ DO NOT exit if build fails or tests fail. This is a hard gate.
-
-```
-[HOTFIX-IMPL] [5/6] Build & test verification... ✅
-```
-
-### Step 6: Impact Verification
-
-```
-[HOTFIX-IMPL] [6/6] Impact verification via GitNexus... ⏳
-```
-
-Use GitNexus `impact` — verify the fix did not break anything outside blast radius.
-
-If unexpected impact detected → evaluate:
-- Within scope boundary → OK, note in impl log
-- Outside scope boundary → STOP, escalate to user
-
-```
-[HOTFIX-IMPL] [6/6] Impact verification... ✅
-```
-
-## Verification Gate
-
-⛔ **NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.**
-
-Before printing Phase Exit, you MUST pass ALL checks below. For each check: **run the command → read the full output → verify the claim matches the output.** Do NOT trust memory, do NOT trust previous runs, do NOT say "should pass."
-
-| # | Check | Command to Run | Evidence Required | ❌ NOT Acceptable |
-|---|-------|---------------|-------------------|-------------------|
-| 1 | Build compiles | `mvn compile` / `npm run build` / equivalent | `BUILD SUCCESS` or `0 errors` in output | "It compiled earlier" |
-| 2 | All tests pass | `npm test` / `mvn test` / equivalent | `X passed, 0 failed` in output | "Tests should still pass" |
-| 3 | Regression test passes | Run specific test by name | Test name + PASS in output | "I wrote the test so it passes" |
-| 4 | No new SonarQube issues | Check output from Step 4 | 0 blockers, 0 critical, 0 vulns | "Code looks clean" |
-| 5 | GitNexus impact clean | Check output from Step 6 | Blast radius matches analysis | "Fix is minimal so it's fine" |
-| 6 | Scope boundary held | `git diff --stat` | Changed files ⊆ files listed in analysis | "I only changed what was needed" |
-
-**Red flags — if you catch yourself thinking any of these, STOP and run the command:**
-- "It should work" → Run it and prove it
-- "I'm confident" → Confidence ≠ evidence
-- "I already checked" → Check again with fresh output
-- "It's a small change so it's safe" → Small changes break big systems
-- "The test passed during TDD" → TDD was minutes ago; verify NOW
-
-**Procedure:**
-1. Run checks 1-6 sequentially
-2. For each: paste the **actual command output** (or key lines) into `03-impl-log.md` under a `## Verification Evidence` section
-3. If ANY check fails → fix → re-run ALL checks (not just the failed one)
-4. Only after ALL 6 checks show fresh passing evidence → proceed to Phase Exit
-
-## Output
-
-Write file: `.vsaf/docs/hotfixes/{bug-id}/03-impl-log.md`
-
-```markdown
-# Implementation Log: {bug-id}
-
-## Branch
-`hotfix/{bug-id}`
-
-## TDD Cycles
-
-### FR-001: {title}
-- RED: {test file}:{test name} — FAILED ✓
-- GREEN: {changed files} — PASSED ✓
-- REFACTOR: {what was cleaned}
-
-### FR-002: {title} (if applicable)
-...
-
-## Files Changed
-| File | Change type | Lines |
-|------|-------------|-------|
-| {file} | Modified / Added | +{n} -{m} |
-
-## Test Results
-- New tests: {count}
-- Regression test: {test name} — PASS
-- Full suite: {total} tests, all PASS
-
-## SonarQube
-- Issues: 0
-- Vulnerabilities: 0
-- Duplication: {n}%
-
-## Build
-- Compile: PASS
-- Full test suite: PASS
-
-## Verification Evidence
-
-| # | Check | Result | Evidence |
-|---|-------|--------|----------|
-| 1 | Build compiles | ✅ PASS | `{actual build output line}` |
-| 2 | All tests pass | ✅ PASS | `{X} passed, 0 failed` |
-| 3 | Regression test | ✅ PASS | `{test name} — PASSED` |
-| 4 | SonarQube clean | ✅ PASS | 0 blocker, 0 critical, 0 vuln |
-| 5 | Impact clean | ✅ PASS | Blast radius = {files}, matches analysis |
-| 6 | Scope held | ✅ PASS | `git diff --stat`: {n} files changed, all within scope |
-```
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-- Bug: {bug-id}
-- Status: IMPLEMENTATION COMPLETED
-- Branch: `hotfix/{bug-id}`
-- Tests: {new} new, {total} total — all PASS
-- Files changed: {count}
-- Output: `.vsaf/docs/hotfixes/{bug-id}/03-impl-log.md`
-- Next step: `/sdlc-hotfix-ship`
-
-Update `.vsaf/docs/STATUS.md`.
-
-> Artifacts 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 (TDD)
-- ⛔ Do NOT modify `graphify-out/` or `.gitnexus/`
-- ⛔ Do NOT exceed scope boundary defined in PRD
-- ⛔ Do NOT use subagent-driven development — hotfixes are sequential, focused
-- Code MUST compile — hard gate, no exceptions
-- Full test suite MUST pass — no regressions allowed
-- If fix fails 3 times → STOP, escalate to user
-- If scope drift detected → STOP, go back to PRD