@ngocsangairvds/vsaf 5.4.7 → 5.5.1

package/workflows/sdlc/master-sdlc-headless.yaml

@@ -1,73 +1,29 @@
 name: master-sdlc-headless
-description: Full SDLC pipeline (headless implement) — Discovery → PRD → Architecture → SRS → Test Design → Implement (headless) → Review → Feature Complete → Ship
+description: Full SDLC pipeline (headless implement, single-workspace) — Discovery → PRD → Architecture → SRS → Test Design → Implement (headless) → Review → Feature Complete → Ship
 nodes:
   - id: discovery
-    description: Phase — Discovery
-    bash: |
-      vsaf run sdlc/sdlc-discovery --args $ARGUMENTS
-    workspace: false
-    timeout: 5400000
+    workflow: sdlc/sdlc-discovery
   - id: prd
-    description: Phase — PRD
-    bash: |
-      vsaf run sdlc/sdlc-prd --args $ARGUMENTS
-    workspace: false
-    timeout: 5400000
-    depends_on:
-      - discovery
+    workflow: sdlc/sdlc-prd
+    depends_on: [discovery]
   - id: architecture
-    description: Phase — Architecture
-    bash: |
-      vsaf run sdlc/sdlc-architecture --args $ARGUMENTS
-    workspace: false
-    timeout: 5400000
-    depends_on:
-      - prd
+    workflow: sdlc/sdlc-architecture
+    depends_on: [prd]
   - id: srs
-    description: Phase — SRS
-    bash: |
-      vsaf run sdlc/sdlc-srs --args $ARGUMENTS
-    workspace: false
-    timeout: 5400000
-    depends_on:
-      - architecture
+    workflow: sdlc/sdlc-srs
+    depends_on: [architecture]
   - id: test-design
-    description: Phase — Test Design
-    bash: |
-      vsaf run sdlc/sdlc-test-design --args $ARGUMENTS
-    workspace: false
-    timeout: 5400000
-    depends_on:
-      - srs
+    workflow: sdlc/sdlc-test-design
+    depends_on: [srs]
   - id: implement
-    description: Phase — Implement (headless, engine-driven)
-    bash: |
-      vsaf run sdlc/sdlc-build-headless --args $ARGUMENTS
-    workspace: false
-    timeout: 5400000
-    depends_on:
-      - test-design
+    workflow: sdlc/sdlc-build-headless
+    depends_on: [test-design]
   - id: review
-    description: Phase — Review
-    bash: |
-      vsaf run sdlc/sdlc-review --args $ARGUMENTS
-    workspace: false
-    timeout: 5400000
-    depends_on:
-      - implement
+    workflow: sdlc/sdlc-review
+    depends_on: [implement]
   - id: complete
-    description: Phase — Feature Complete
-    bash: |
-      vsaf run sdlc/sdlc-feature-complete --args $ARGUMENTS
-    workspace: false
-    timeout: 5400000
-    depends_on:
-      - review
+    workflow: sdlc/sdlc-feature-complete
+    depends_on: [review]
   - id: ship
-    description: Phase — Ship
-    bash: |
-      vsaf run sdlc/sdlc-ship --args $ARGUMENTS
-    workspace: false
-    timeout: 5400000
-    depends_on:
-      - complete
+    workflow: sdlc/sdlc-ship
+    depends_on: [complete]

package/workflows/sdlc/onboard-code.yaml

@@ -0,0 +1,104 @@
+name: onboard-code
+description: |
+  Onboard Code — GitNexus index + verify + environment setup + cross-domain verify (mirrors the
+  sdlc-onboard-code skill, one node per phase). Detect structure -> GitNexus index -> verify index ->
+  env/Docker -> cross-domain verify (reads graphify-out/graph.json from onboard-docs) -> summary.
+  GitNexus is the SINGLE SOURCE OF TRUTH for code; graphify/graph.json is docs-only and READ-ONLY here.
+provider: claude
+model: sonnet
+nodes:
+  - id: detect-structure
+    description: Code 1/6 — detect project structure (single / multi-repo / non-git)
+    permission_mode: bypassPermissions
+    workspace: false
+    timeout: 900000
+    prompt: |
+      You are a Senior DevOps + Code Architect onboarding a codebase. Project path: $ARGUMENTS (or current dir).
+      Print `[ONBOARD-CODE] [1/6] Detect project structure... ⏳/✅`.
+
+      Determine structure: root `.git`? → single repo. No root `.git` → scan 1–2 levels for `.git/`:
+      found N → multi-repo/microservice (list {path, remote, branch}); none → non-git project.
+      Record the result under `## Project Structure` in `.vsaf/docs/onboarding/env-setup.md`.
+      Artifact boundary: write only at project root or under root `.vsaf/`. ⛔ Do NOT modify `graphify-out/` or `.gitnexus/`.
+
+  - id: gitnexus-index
+    description: Code 2/6 — build the GitNexus code index (single unified index at project root)
+    workspace: false
+    timeout: 3600000
+    depends_on:
+      - detect-structure
+    bash: |
+      set -e
+      echo "[ONBOARD-CODE] [2/6] GitNexus index... ⏳"
+      # Use the LOCAL binary — do NOT use `npx -y gitnexus@latest` (native-module crash on Node 24+).
+      if [ -d .git ]; then
+        echo "[ONBOARD-CODE] git repo at root → npx gitnexus analyze ."
+        npx gitnexus analyze .
+      else
+        echo "[ONBOARD-CODE] no root .git → npx gitnexus analyze . --skip-git (covers sub-repos too)"
+        npx gitnexus analyze . --skip-git
+      fi
+      echo "[ONBOARD-CODE] [2/6] GitNexus index... ✅ (single .gitnexus/ at project root)"
+
+  - id: verify-index
+    description: Code 3/6 — map + verify the GitNexus index via MCP (do NOT trust blindly)
+    permission_mode: bypassPermissions
+    workspace: false
+    timeout: 1800000
+    depends_on:
+      - gitnexus-index
+    prompt: |
+      Print `[ONBOARD-CODE] [3/6] Verify GitNexus index... ⏳/✅`.
+
+      Claude MUST review the index — do not assume it is correct. Using the GitNexus MCP tools:
+      - `group_sync` if the index needs (re)syncing; `list_repos` — confirm the project root is indexed (one unified index).
+      - `route_map` — confirm API routes from ALL repos are mapped; `tool_map` + `context` on 3–5 key entry points per repo.
+      Check: main entry points indexed? inter-module dependencies correct? for multi-repo, cross-service calls
+      (HTTP/gRPC/event) captured? If something is missing, re-run `group_sync` or record
+      "{module/route} not indexed — needs manual review" in `.vsaf/docs/onboarding/env-setup.md`.
+      ⛔ Only GitNexus writes `.gitnexus/`; do not edit it directly.
+
+  - id: env-docker
+    description: Code 4/6 — environment check + Docker setup suggestion
+    permission_mode: bypassPermissions
+    workspace: false
+    timeout: 1800000
+    depends_on:
+      - verify-index
+    prompt: |
+      Print `[ONBOARD-CODE] [4/6] Environment check + Docker setup... ⏳/✅`.
+
+      Detect the tech stack (read package.json, pom.xml, build.gradle, requirements.txt, Dockerfile, docker-compose.yml).
+      Check the current env (`java -version`, `node -v`, `docker -v`, `python3 --version`, …); compare required vs present
+      and suggest installs. Docker: if no Dockerfile/docker-compose.yml, suggest creating them (app + DB/cache/broker as needed);
+      if present, sanity-check the config. Record everything under `.vsaf/docs/onboarding/env-setup.md`
+      (this is the only md file this phase creates — no project-overview/codebase-map).
+
+  - id: cross-domain
+    description: Code 5/6 — cross-domain verify (GitNexus code ↔ docs graph.json) + technical terms
+    permission_mode: bypassPermissions
+    workspace: false
+    timeout: 1800000
+    depends_on:
+      - env-docker
+    prompt: |
+      Print `[ONBOARD-CODE] [5/6] Cross-domain verify... ⏳/✅`.
+
+      Read `graphify-out/graph.json` (the docs graph from onboard-docs — READ ONLY) and query the code via GitNexus (`query`, `context`). Cross-reference:
+      - business concept (graph.json) → is there a matching code module? YES → record `{concept} ↔ {module/class}`; NO → "{concept} not yet implemented".
+      - code module (GitNexus) → matching business concept? YES → mapping; NO → technical module (infra/utils), record as such.
+      Append a "## Technical Terms" table to `CONTEXT.md` (| Term | Definition | Maps to Business Concept |).
+      Flag any cross-database access. If `graphify-out/graph.json` is absent, note that onboard-docs must run first.
+
+  - id: summary
+    description: Code 6/6 — onboarding summary report
+    model: haiku
+    workspace: false
+    timeout: 600000
+    depends_on:
+      - cross-domain
+    prompt: |
+      Print `[ONBOARD-CODE] [6/6] Create summary report... ⏳/✅` then the report table:
+      Project structure / GitNexus index (N repos) / Index verification / Tech stack / Environment (ready or missing) /
+      Docker (exists or suggested) / Cross-domain mapping (N mapped, M gaps) / CONTEXT.md updated.
+      End with: "Artifacts saved. If interrupted, re-run the next phase — data is safe."

package/workflows/sdlc/onboard-docs.yaml

@@ -0,0 +1,93 @@
+name: onboard-docs
+description: |
+  Onboard Docs — build & verify the documentation knowledge graph (mirrors the sdlc-onboard-docs
+  skill, one node per phase). Scan/import docs -> graphify build -> Claude verify & supplement ->
+  extract domain terms. Graphify runs ONLY on docs (never source code — that is onboard-code/GitNexus).
+provider: claude
+model: sonnet
+nodes:
+  - id: scan-import
+    description: Docs 1/4 — scan & import documents (markitdown conversion + tier fallbacks)
+    permission_mode: bypassPermissions
+    workspace: false
+    timeout: 1800000
+    prompt: |
+      You are a Knowledge Engineer onboarding project documents. Project path: $ARGUMENTS (or current dir).
+      Print progress as `[ONBOARD-DOCS] [1/4] Scan & import documents... ⏳/✅`.
+
+      1. Scan ALL documents: README, docs/, wiki/, specs/, *.md, *.txt (+ complex binaries). List them.
+      2. Resolve markitdown python:
+           VENVS=$(pipx environment --value PIPX_LOCAL_VENVS 2>/dev/null)
+           MARKITDOWN_PYTHON="${VENVS}/markitdown/bin/python"  (fallback ~/.local/pipx/venvs/markitdown/bin/python)
+         If markitdown is missing, skip conversion and route ALL complex files through fallbacks (step 4).
+      3. Classify each complex file into a tier:
+           - Tier 1 (graphify-native): PDF, DOCX, XLSX, PNG, JPG, GIF, WEBP
+           - Tier 2 (graphify-blind): HTML, PPTX, EPUB, ZIP
+           - .md/.txt are NOT complex (read directly).
+      4. For each complex file: attempt `"$MARKITDOWN_PYTHON" "<this-skill-dir>/convert.py" --input {file} --output .vsaf/docs/onboarding/doc-imports/{name}.md`.
+         Verify the output has real content (not just headers, not an LLM refusal, not hallucinated). On success use it.
+         On failure/verify-fail: Tier 1 -> append original path to `.vsaf/docs/onboarding/graphify-direct-read.txt`;
+         Tier 2 HTML -> Read the file + write clean markdown to doc-imports/{name}.md; Tier 2 PPTX/EPUB/ZIP -> skip.
+      5. Print a conversion summary (markitdown OK / graphify-direct / Claude-Read / skipped counts).
+
+      Artifact boundary: write generated artifacts ONLY at project root or under root `.vsaf/`. ⛔ Do NOT modify `graphify-out/` or `.gitnexus/`.
+
+  - id: graphify-build
+    description: Docs 2/4 — graphify build over a docs-only staging dir -> graph.json
+    permission_mode: bypassPermissions
+    workspace: false
+    timeout: 3600000
+    depends_on:
+      - scan-import
+    prompt: |
+      Print progress `[ONBOARD-DOCS] [2/4] Graphify build for docs... ⏳/✅`.
+
+      1. Create `.vsaf/docs/onboarding/graphify-staging/` and populate it with ALL doc inputs:
+         original text docs (.md/.txt/README), converted .md from `.vsaf/docs/onboarding/doc-imports/`,
+         and the original binaries listed in `.vsaf/docs/onboarding/graphify-direct-read.txt`.
+         This staging dir is the SINGLE input to graphify — it guarantees graphify sees docs only, never code.
+      2. Run `/graphify .vsaf/docs/onboarding/graphify-staging/`.
+      3. Output: `graphify-out/graph.json`.
+
+      ⛔ CRITICAL: graphify is ONLY for docs — DO NOT run graphify on source code (code = GitNexus, in onboard-code).
+      Only graphify may write `graphify-out/`.
+
+  - id: verify-fix
+    description: Docs 3/4 — Claude verifies graph vs docs and supplements missing nodes/edges
+    permission_mode: bypassPermissions
+    workspace: false
+    timeout: 3600000
+    depends_on:
+      - graphify-build
+    prompt: |
+      Print progress `[ONBOARD-DOCS] [3/4] Verify & fix graph... ⏳/✅`.
+
+      Do NOT trust the graph blindly. For EACH original doc:
+      1. Re-read it — extract concepts, relationships, business rules, constraints.
+      2. Read `graphify-out/graph.json` — find the corresponding nodes/edges.
+      3. Compare: concept/relationship/rule present in the doc but missing in the graph = MISSING.
+      4. Supplement any MISSING nodes/edges DIRECTLY into `graph.json` (this Phase-3 supplementation is the
+         ONLY permitted direct write to graph.json). Report per doc: "{doc}: +N nodes, +M edges".
+
+      Every missing concept/relationship MUST be supplemented, not skipped.
+
+  - id: extract-terms
+    description: Docs 4/4 — extract domain terms from the graph into CONTEXT.md (Shared Language)
+    model: haiku
+    permission_mode: bypassPermissions
+    workspace: false
+    timeout: 900000
+    depends_on:
+      - verify-fix
+    prompt: |
+      Print progress `[ONBOARD-DOCS] [4/4] Extract domain terms → CONTEXT.md... ⏳/✅`.
+
+      From the completed `graph.json`, extract DOMAIN terms (business vocabulary, not technical/code terms —
+      those are added later by onboard-code). Append/update a "## Shared Language" table in `CONTEXT.md` at the project root:
+
+      | Term | Definition | Example |
+      |------|-----------|---------|
+      | {term} | {1-line definition} | {concrete example} |
+
+      The graph is the single source of truth — do NOT create redundant overview/summary md files.
+      Then print: "Artifacts saved. If interrupted, re-run the next phase — data is safe."

package/workflows/sdlc/onboarding.yaml

@@ -1,11 +1,28 @@
 name: onboarding
-description: "Utility — Onboarding: docs graph + code graph + env setup (not part of main flow)"
+description: |
+  Phase 0 — Onboarding orchestrator (utility; NOT part of the master SDLC flow). Runs the two
+  step-level phase workflows in ONE run/workspace via sub-workflow includes:
+  init artifact structure -> onboard-docs (docs knowledge graph) -> onboard-code (GitNexus index +
+  env/Docker + cross-domain verify). Ordering matters: onboard-code reads graphify-out/graph.json
+  produced by onboard-docs, so docs MUST run before code.
+  Prerequisite (one-time, per machine): run `/sdlc-setup` to install tooling (GitNexus, markitdown).
 nodes:
-  - id: docs
-    description: "Onboard Docs: build documentation knowledge graph"
-    command: sdlc-onboard-docs
+  - id: init
+    description: Phase 0.1 — initialize .vsaf artifact structure (.vsaf/docs, CONTEXT.md, .gitignore)
+    model: haiku
+    permission_mode: bypassPermissions
     workspace: false
+    timeout: 600000
+    command: sdlc-init
+
+  - id: docs
+    description: Phase 0.2 — onboard-docs (build + verify docs knowledge graph)
+    depends_on:
+      - init
+    workflow: sdlc/onboard-docs
+
   - id: code
-    description: "Onboard Code: analyze codebase structure and conventions"
-    command: sdlc-onboard-code
-    workspace: false
+    description: Phase 0.3 — onboard-code (index code + env/Docker + cross-domain verify)
+    depends_on:
+      - docs
+    workflow: sdlc/onboard-code

package/workflows/sdlc/sdlc-build-headless.yaml

@@ -60,9 +60,15 @@ nodes:
       4. Write the chosen command to `$ARTIFACTS_DIR/run-tests.sh` — a POSIX sh script that runs the
          FULL test suite from the project root and exits with the test runner's exit code. Make it
          self-contained and re-runnable, then `chmod +x` it.
-      5. Verify once: `sh $ARTIFACTS_DIR/run-tests.sh`. It is FINE if tests fail now (the code isn't
-         written yet) — you are only proving the toolchain runs. Report one line: host or docker,
-         and that run-tests.sh is ready.
+      5. Verify once: `sh $ARTIFACTS_DIR/run-tests.sh 2>&1 | tee $ARTIFACTS_DIR/test-baseline.log`.
+         It is FINE if tests fail now (the code isn't written yet) — you are proving the toolchain
+         runs AND capturing the BASELINE (which tests already fail BEFORE this feature). From that
+         log, write `$ARTIFACTS_DIR/test-baseline.txt` with two lines exactly:
+           `total=<N>` (total tests the runner executed)
+           `failing=<comma-separated fully-qualified failing test names, or empty>`
+         (If the runner produced no test summary at all, write `total=0` and note the runner error —
+         that itself is a toolchain problem to fix here, not later.) Report one line: host or docker,
+         baseline total + failing count, and that run-tests.sh is ready.
 
   - id: impl-loop
     description: Implement 3/4 — TDD one case per turn; run tests IN-LOOP; finish only when GREEN
@@ -84,15 +90,22 @@ nodes:
          `<promise>IMPL_COMPLETE</promise>` and stop.
       3. For that one case: write/adjust its test (RED), implement the minimal code to make it pass
          (GREEN). Keep the change scoped to this case.
-      4. Run `sh $ARTIFACTS_DIR/run-tests.sh 2>&1 | tee $ARTIFACTS_DIR/test-output.log`. If ANY test
-         fails (this case OR a regression in a previously-passing test), FIX it now and re-run until
-         this case passes and nothing else is broken. Never move on with a failing suite.
+      4. Run the COMPLETE suite: `sh $ARTIFACTS_DIR/run-tests.sh 2>&1 | tee $ARTIFACTS_DIR/test-output.log`
+         (never a hand-picked subset). If ANY test fails (this case OR a regression in a
+         previously-passing test), FIX it now and re-run until this case passes and nothing else is
+         broken. Never move on with a failing suite.
       5. Tick the line to `- [x]` in `$ARTIFACTS_DIR/impl-progress.md` and append a one-line note.
 
       Work on the real project files. Match the project's existing structure, language, and test
-      framework. Do only the current case — the loop calls you again for the next. CRITICAL: NEVER
-      emit `<promise>IMPL_COMPLETE</promise>` while any test is failing; the signal means the whole
-      suite is green.
+      framework. Do only the current case — the loop calls you again for the next.
+
+      COMPLETION BAR — the full suite MUST be GREEN (0 failures, 0 errors) before you emit the
+      signal. A test that was ALREADY failing before this feature (see `$ARTIFACTS_DIR/test-baseline.txt`)
+      is NOT an excuse to ship red: either fix it, or — if it is genuinely unrelated and out of scope —
+      record it under a `## Pre-existing failures (quarantined)` section in impl-progress.md with the
+      exact test name + one-line rationale AND exclude it from the run so the suite is green. Do NOT
+      leave the suite red without an explicit quarantine entry. CRITICAL: NEVER emit
+      `<promise>IMPL_COMPLETE</promise>` while any test is failing; the signal means the whole suite is green.
     loop:
       until: IMPL_COMPLETE
       interactive: false
@@ -110,9 +123,20 @@ nodes:
     bash: |
       RT=$ARTIFACTS_DIR/run-tests.sh
       LOG=$ARTIFACTS_DIR/test-output.log
+      BASE=$ARTIFACTS_DIR/test-baseline.txt
       if [ ! -f "$RT" ]; then echo "[vsaf] test-gate: run-tests.sh missing (env-setup did not run)"; exit 1; fi
-      echo "[vsaf] test-gate: final verification via run-tests.sh"
+      echo "[vsaf] test-gate: final verification via run-tests.sh (FULL suite)"
       sh "$RT" > "$LOG" 2>&1; code=$?
       tail -40 "$LOG" 2>/dev/null || true
+      # Print the runner's real execution summary so the report is honest (never a subset count).
+      SUMMARY=$(grep -iE "Tests run: [0-9]+|[0-9]+ (passed|failed)|BUILD (SUCCESS|FAILURE)|failures=|[0-9]+ tests" "$LOG" 2>/dev/null | tail -6)
+      echo "[vsaf] test-gate summary:"; printf '%s\n' "$SUMMARY"
+      if [ -f "$BASE" ]; then echo "[vsaf] baseline (pre-feature): $(tr '\n' ' ' < "$BASE")"; fi
+      # Anti-false-green: refuse a 0 exit that shows NO evidence the suite actually ran
+      # (e.g. a runner that no-op'd or reused stale state). A green must be a proven green.
+      if [ "$code" -eq 0 ] && ! printf '%s' "$SUMMARY" | grep -qiE "Tests run: [0-9]+|[0-9]+ passed|[0-9]+ tests|BUILD SUCCESS"; then
+        echo "[vsaf] test-gate: FAIL — exit 0 but no test-run summary found; cannot confirm the suite executed. Refusing to false-green."
+        exit 1
+      fi
       echo "[vsaf] test-gate exit=$code"
       exit "$code"

package/workflows/sdlc/sdlc-design.yaml

@@ -35,27 +35,10 @@ nodes:
       - architecture-epics
     workspace: false
     command: sdlc-architecture-readiness
-  - id: srs-prereq
-    description: SRS 1/4 — input artifacts
+  - id: srs
+    description: Phase 4 — SRS specification, validation, interface verification (single cohesive skill)
+    model: sonnet
     workspace: false
-    command: sdlc-srs-prereq
+    command: sdlc-srs
     depends_on:
       - architecture-readiness
-  - id: srs-write
-    description: SRS 2/4 — write SRS
-    depends_on:
-      - srs-prereq
-    workspace: false
-    command: sdlc-srs-write
-  - id: srs-validate
-    description: SRS 3/4 — validate SRS
-    depends_on:
-      - srs-write
-    workspace: false
-    command: sdlc-srs-validate
-  - id: srs-interface
-    description: SRS 4/4 — interface verification + gate
-    depends_on:
-      - srs-validate
-    workspace: false
-    command: sdlc-srs-interface

package/workflows/sdlc/sdlc-review.yaml

@@ -28,9 +28,17 @@ nodes:
     workspace: false
     command: sdlc-review-impact
   - id: review-debate
-    description: Review 5/5 — debate + gate
+    description: Review 5/6 — debate + gate
     model: haiku
     depends_on:
       - review-impact
     workspace: false
     command: sdlc-review-debate
+  - id: review-fix
+    description: Review 6/6 — implement MUST-FIX findings, then re-verify the full suite
+    model: sonnet
+    permission_mode: bypassPermissions
+    depends_on:
+      - review-debate
+    workspace: false
+    command: sdlc-review-fix

package/workflows/sdlc/sdlc-srs.yaml

@@ -1,29 +1,8 @@
 name: sdlc-srs
-description: 'Phase workflow: SRS step-level execution'
+description: 'Phase workflow: SRS — single cohesive skill (write + 8-dimension validation + interface verification)'
 nodes:
-  - id: srs-prereq
-    description: SRS 1/4 — input artifacts
+  - id: srs
+    description: Phase 4 — SRS specification, validation, interface verification
     model: sonnet
     workspace: false
-    command: sdlc-srs-prereq
-  - id: srs-write
-    description: SRS 2/4 — write SRS
-    model: haiku
-    depends_on:
-      - srs-prereq
-    workspace: false
-    command: sdlc-srs-write
-  - id: srs-validate
-    description: SRS 3/4 — validate SRS
-    model: haiku
-    depends_on:
-      - srs-write
-    workspace: false
-    command: sdlc-srs-validate
-  - id: srs-interface
-    description: SRS 4/4 — interface verification + gate
-    model: haiku
-    depends_on:
-      - srs-validate
-    workspace: false
-    command: sdlc-srs-interface
+    command: sdlc-srs

package/skills/sdlc/srs/interface/SKILL.md

@@ -1,10 +0,0 @@
----
-name: sdlc-srs-interface
-description: "SRS 4/4 — interface verification + output"
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# SRS 4/4 — interface verification + output
-
-@include(step.md)

package/skills/sdlc/srs/interface/step.md

@@ -1,44 +0,0 @@
-### Step 4: Interface Verification
-
-```
-[SRS] [4/4] Interface verification via GitNexus... ⏳
-```
-
-Use GitNexus `shape_check` — verify code structure matches SRS assumptions.
-Append results to `05-srs.md` §Interface Contracts.
-
-```
-[SRS] [4/4] Interface verification via GitNexus... ✅
-```
-
-## Gate
-
-Human must approve SRS. Write `## Gate: APPROVED` at the end of the file.
-
-**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
-
-- `.vsaf/docs/features/{feature-name}/05-srs.md` — SRS document (v4 template format)
-- `.vsaf/docs/features/{feature-name}/05-srs-validation-report.md` — Validation report with scores
-
-## Phase Exit Protocol
-
-In PHASE REPORT:
-- Output files: `05-srs.md`, `05-srs-validation-report.md`
-- Validation score: {overall_score}% ({GO/CONDITIONAL GO/NO-GO})
-- Suggestions: [1] Phase 5 Test Design (`/sdlc-test-design`) [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
-
-- Every FR/NFR MUST have a unique traceability ID
-- DO NOT use vague language: "should", "might", "optionally" → replace with "MUST", "MUST NOT"
-- All terms MUST exist in CONTEXT.md
-- Every FR MUST be testable (have clear pass/fail criteria)
-- SRS MUST follow the v4 template structure (12 sections)
-- ⛔ DO NOT modify `graphify-out/` or `.gitnexus/`

package/skills/sdlc/srs/prereq/SKILL.md

@@ -1,10 +0,0 @@
----
-name: sdlc-srs-prereq
-description: "SRS 1/4 — input artifacts"
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# SRS 1/4 — input artifacts
-
-@include(step.md)

package/skills/sdlc/srs/prereq/step.md

@@ -1,19 +0,0 @@
-## Phase Entry Protocol
-
-```
-[SRS] [1/4] Checking input artifacts... ⏳
-```
-
-1. Input:
-   - `.vsaf/docs/features/{feature-name}/02-prd.md`
-   - `.vsaf/docs/features/{feature-name}/03-adr.md`
-   - `.vsaf/docs/features/{feature-name}/04-epics.md`
-2. Verify 02-prd.md AND 03-adr.md exist (04-epics.md optional):
-   - Any required file missing → Ask: "File not found. Have you run Phase 2 (PRD) and Phase 3 (Architecture)?"
-3. Read `.vsaf/docs/STATUS.md`
-4. Read `CONTEXT.md`
-5. Query `graph.json` for code structure + business mapping (if exists)
-
-```
-[SRS] [1/4] Checking input artifacts... ✅
-```

package/skills/sdlc/srs/validate/SKILL.md

@@ -1,10 +0,0 @@
----
-name: sdlc-srs-validate
-description: "SRS 3/4 — validate SRS"
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# SRS 3/4 — validate SRS
-
-@include(step.md)

package/skills/sdlc/srs/validate/step.md

@@ -1,23 +0,0 @@
-### Step 3: Validate SRS
-
-```
-[SRS] [3/4] Validating SRS (8 dimensions)... ⏳
-```
-
-Use `/sdlc-validate-srs` — validate SRS across 8 dimensions with weighted scoring.
-
-- Scope: single file (`05-srs.md`)
-- Cross-validate against: `02-prd.md`, `03-adr.md`
-- Output: `.vsaf/docs/features/{feature-name}/05-srs-validation-report.md`
-
-**Decision handling:**
-
-| Validation Result | Action |
-|---|---|
-| **GO** (≥80%, no CRITICAL) | Print score summary, proceed to Step 4 |
-| **CONDITIONAL GO** (60-79% or HIGH findings) | Print warnings + finding summary. Ask user: "Proceed despite warnings? (Y/N)" |
-| **NO-GO** (<60% or CRITICAL findings) | **STOP.** Print CRITICAL findings. Ask user to fix 05-srs.md and re-run `/sdlc-srs` |
-
-```
-[SRS] [3/4] Validating SRS (8 dimensions)... ✅
-```

package/skills/sdlc/srs/write/SKILL.md

@@ -1,10 +0,0 @@
----
-name: sdlc-srs-write
-description: "SRS 2/4 — write SRS"
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# SRS 2/4 — write SRS
-
-@include(step.md)

package/skills/sdlc/srs/write/step.md

@@ -1,19 +0,0 @@
-### Step 2: Write SRS
-
-```
-[SRS] [2/4] Writing SRS from PRD + ADR + Epics... ⏳
-```
-
-Use `/sdlc-write-srs` — write SRS following the v4 template (12 sections) from PRD + Architecture + Epics.
-
-Input:
-- `02-prd.md` as PRD source
-- `03-adr.md` as architecture context
-- `04-epics.md` as epic breakdown (optional)
-- Figma link from `CONTEXT.md` (optional)
-
-Output: `.vsaf/docs/features/{feature-name}/05-srs.md`
-
-```
-[SRS] [2/4] Writing SRS from PRD + ADR + Epics... ✅
-```