@ngocsangairvds/vsaf 3.2.16 → 4.0.1

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

@@ -1,111 +0,0 @@
----
-name: vsaf-sprint
-description: Sprint management — break PRD into epics/stories, create sprint plan, track progress. Use when managing multiple features simultaneously.
----
-
-# VSAF Sprint
-
-## Goal
-Manage backlog and sprints for the project — break PRD/SRS into stories, create plans, track progress, surface risks.
-
-## Input
-`$ARGUMENTS` — action to perform:
-- `plan` — create a new sprint plan from PRD/epics
-- `status` — view current sprint status
-- `story <id>` — create a detailed story file for a single story
-
-## When to use
-- After `/vsaf-discover` when a PRD is available
-- When the project has multiple features that need prioritization
-- When visibility into overall progress is needed
-
-## Steps
-
-### Mode: `plan` — Create a new sprint plan
-
-#### Step 1 — Break into Epics + Stories
-- Use skill `bmad-create-epics-and-stories` with PRD/SRS as input
-- Output: list of epics, each epic containing user stories
-- Each story has: description, acceptance criteria, estimated complexity (S/M/L/XL)
-
-#### Step 2 — Sprint Planning
-- Use skill `bmad-sprint-planning` to:
-  - Prioritize stories (MoSCoW or WSJF)
-  - Assign stories to sprint based on capacity
-  - Identify dependencies between stories
-- Save sprint plan to `.vsaf/docs/planning-artifacts/sprint-plan.md`
-
-#### Step 3 — Output
-```
-## Sprint Plan: [sprint name/number]
-
-### Capacity: [X story points / N stories]
-
-### Stories in sprint
-| # | Story | Epic | Size | Priority | Depends on |
-|---|-------|------|------|----------|------------|
-| 1 | ...   | ...  | M    | MUST     | -          |
-| 2 | ...   | ...  | L    | MUST     | #1         |
-
-### Deferred to next sprint
-| Story | Reason |
-|-------|--------|
-
-### Next step
-Run /vsaf-sprint story <id> to create a detailed story file
-Or: /vsaf-plan <story description> to start the first feature
-```
-
----
-
-### Mode: `status` — View sprint status
-
-#### Step 1 — Collect status
-- Use skill `bmad-sprint-status` to:
-  - Scan sprint plan file
-  - Check git log for completed stories
-  - Surface: blocked items, risks, velocity trend
-
-#### Step 2 — Output
-```
-## Sprint Status: [sprint name]
-
-### Progress: [X/Y stories done] ([Z%])
-### Burndown: [on track / behind / ahead]
-
-### Completed
-- [x] Story #1: ...
-- [x] Story #2: ...
-
-### In Progress
-- [ ] Story #3: ... (blocked by: ...)
-
-### Risks
-- [risk description + mitigation]
-
-### Recommendation
-[Continue / adjust scope / escalate]
-```
-
----
-
-### Mode: `story <id>` — Create a detailed story file
-
-#### Step 1 — Create story file
-- Use skill `bmad-create-story` with story ID from the sprint plan
-- Story file includes: full context, acceptance criteria, technical notes, dependencies
-- Save to `.vsaf/docs/planning-artifacts/stories/story-[id].md`
-
-#### Step 2 — Output
-```
-## Story Created: [story title]
-- File: .vsaf/docs/planning-artifacts/stories/story-[id].md
-
-### Next step
-Run /vsaf-plan <story description> to plan implementation
-```
-
-## Notes
-- Sprint plan is a living document — update when changes occur
-- Re-run `/vsaf-sprint status` daily or after each `/vsaf-ship`
-- If sprint is delayed >20%: use `bmad-correct-course` to adjust scope

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

@@ -1,207 +0,0 @@
----
-name: vsaf-test
-description: "Two modes: (1) generate testcases from SRS — used after /vsaf-doc-srs and before /vsaf-build; (2) 'run' — execute tests, verify coverage, write results. Test cases are based on spec, not on code."
----
-
-# 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 |
-|---------|------|------|
-| `/vsaf-test <path/to/srs>` | **generate** | Generate testcase docs from SRS |
-| `/vsaf-test run <path/to/testcases>` | **run** | Execute tests, verify coverage, write results file |
-
----
-
-# Mode 1: Generate — Generate testcases from SRS
-
-## Goal
-Create comprehensive testcase coverage documentation from SRS to serve as a contract for implementation.
-
-## Prerequisites
-- Already ran `/vsaf-doc-prd` and `/vsaf-doc-srs`
-- SRS file exists in `.vsaf/docs/srs/`
-
-## Steps
-
-### Step 0 — Find existing test patterns (GitNexus)
-- Use `gitnexus_query({query: "test patterns for <feature domain>"})` to see how the project currently tests
-- Reference existing patterns to generate testcases consistent with the codebase
-
-### Step 1 — Generate test cases from SRS (BMAD qa)
-- Use skill `bmad-qa-generate-e2e-tests` with the SRS file in `.vsaf/docs/srs/` as input
-- Test cases must cover: happy path, edge cases, error cases, NFRs
-- Source: from FRs/NFRs in SRS — NOT based on implementation
-
-### Step 2 — Hunt edge cases (BMAD edge case hunter)
-- Use skill `bmad-review-edge-case-hunter` with SRS + generated testcases
-- Look for: boundary conditions, race conditions, empty/null inputs, overflow, concurrent access
-- Add test cases for all uncovered edge cases
-- Goal: no unhandled edge case slips through
-
-### Step 3 — Cross-check coverage
-- Compare test cases against FR/NFR in SRS
-- Each FR/NFR must have at least 1 corresponding test case
-- Document gaps if any
-
-### Step 4 — Export traceability matrix
-- Create a mapping table `FR/NFR -> Testcase ID`
-- Each testcase has: input, expected output, pass/fail criteria
-
-### Step 5 — Save testcase document
-- Save testcases to `.vsaf/docs/testcases/[feature].md`
-- Format:
-
-```markdown
-## Testcases: [feature]
-
-### Traceability Matrix
-| FR/NFR ID | Testcase IDs | Coverage |
-|-----------|-------------|----------|
-| FR-001    | TC-001, TC-002 | ✓     |
-
-### Unit Tests
-| Test case | FR/NFR | Input | Expected | Status |
-|-----------|--------|-------|----------|--------|
-| TC-001    | FR-001 | ...   | ...      | [ ]    |
-
-### Integration Tests
-| ...       | ...    | ...   | ...      | [ ]    |
-
-### Edge Cases
-| ...       | ...    | ...   | ...      | [ ]    |
-```
-
-### Step 6 — Implementation readiness gate (BMAD)
-- Use skill `bmad-check-implementation-readiness` to validate all artifacts
-- Check: SRS complete? Testcases cover all FRs/NFRs? Architecture aligned?
-- If **PASS**: display `✓ Implementation ready — proceed to /vsaf-build`
-- If **FAIL**: list gaps that need fixing before build, DO NOT proceed
-
-### Step 7 — Output to user
-```
-## Testcase Summary: [feature]
-
-- Total test cases: [N]
-- FR/NFR coverage: [X/Y] ([%])
-- Edge cases found by hunter: [N]
-- Implementation readiness: [PASS / FAIL]
-
-Files:
-- .vsaf/docs/testcases/[feature].md
-
-## Next step
-[If PASS]: Run /vsaf-build <path/to/prd> <path/to/srs> <path/to/testcases>
-[If FAIL]: Fix gaps listed above, then re-run /vsaf-test
-```
-
----
-
-# Mode 2: Run — Execute tests + write results
-
-## Goal
-Execute the full test suite, verify coverage matches changed code, write a structured results file. The results file is a required input for `/vsaf-ship`.
-
-## Prerequisites
-- Already ran `/vsaf-build` — code implementation is complete
-- Testcase file exists at `.vsaf/docs/testcases/[feature].md`
-
-## Steps
-
-### Step 1 — Re-read testcase file
-- Re-read the testcase file, confirm all tests are present
-- Cross-check with traceability matrix: each FR/NFR must have at least 1 test
-
-### Step 2 — Execute test suite
-- Run all tests: unit + integration + e2e
-- Use the project test runner (Maven/Gradle/npm/etc.)
-- Record output for each test case
-
-### Step 3 — Map results back to FR/NFR
-- Record pass/fail for each testcase
-- Map results back to the traceability matrix: which FR/NFR passed, which have not
-
-### Step 4 — Verify coverage matches changed code (GitNexus)
-- Run `gitnexus_detect_changes({scope: "compare", base_ref: "main"})`
-- Compare the list of changed files/symbols with the list of tested files/symbols
-- Flag any changed file/symbol that does NOT have test coverage
-
-### Step 5 — Architectural constraint check (GitNexus, optional)
-- Run `gitnexus_shape_check` to validate no architectural constraints are violated
-- Record constraint compliance results in the results file
-
-### Step 6 — Write results file
-- Save results to `.vsaf/docs/testcases/[feature]-results.md`
-- Format:
-
-```markdown
-## Test Results: [feature]
-Date: [YYYY-MM-DD]
-
-### Summary
-| Metric | Value |
-|--------|-------|
-| Total tests | [N] |
-| Passed | [N] |
-| Failed | [N] |
-| Pass rate | [%] |
-| FR/NFR coverage | [X/Y] ([%]) |
-| Untested changes | [N files/symbols] |
-| Shape check | [PASS / SKIP / FAIL] |
-
-### Results by FR/NFR
-| FR/NFR ID | Tests | Passed | Failed | Status |
-|-----------|-------|--------|--------|--------|
-| FR-001    | 3     | 3      | 0      | ✓      |
-| FR-002    | 2     | 1      | 1      | ✗      |
-
-### Failed Tests
-| Test case | FR/NFR | Expected | Actual | Notes |
-|-----------|--------|----------|--------|-------|
-
-### Untested Changes (from detect_changes)
-| File/Symbol | Change type | Test coverage |
-|-------------|------------|---------------|
-
-### Shape Check Results
-[Output from gitnexus_shape_check, or "Skipped"]
-```
-
-### Step 7 — Ship gate
-- **PASS** if:
-  - All FR/NFR have at least 1 test PASS
-  - No untested changes (or reason has been explained)
-  - Shape check has no violations
-- **FAIL** if:
-  - Any FR/NFR has 0 passing tests -> **blocks ship**
-  - Untested changes detected without justification -> **blocks ship**
-  - Shape check violations -> **blocks ship**
-- Display:
-
-```
-## Test Run Results: [feature]
-
-- Pass rate: [X/Y] ([%])
-- FR/NFR coverage: [X/Y] ([%])
-- Untested changes: [N] — [CLEAR / BLOCKED]
-- Shape check: [PASS / SKIP / FAIL]
-- Ship gate: [PASS ✓ / FAIL ✗]
-
-Results file: .vsaf/docs/testcases/[feature]-results.md
-
-## Next step
-[If PASS]: Run /vsaf-ship
-[If FAIL]: Fix failures above, then re-run /vsaf-test run
-```
-
-## Notes
-- Results file is a required input for `/vsaf-ship` — no results = no ship

package/tools/vds-scripts/.claude/phase7-CLOSURE.md

@@ -1,100 +0,0 @@
-# Phase 7 Lane Closure Notes
-
-## Lane G3 — materials_cli Triage (2026-04-19)
-
-**Scope**: `audit_orchestrator/tests/test_cli/test_materials_cli.py`
-**Method**: Ran 4 tests on both phase7/composition and master (450f6e3). All 4 fail identically on both branches.
-**Conclusion**: All 4 are pre-existing failures — unrelated to Phase 7 changes.
-
----
-
-### Test: test_list_materials_resolves_project_storage_key_directory
-- **Status**: pre-existing
-- **Failure**: `assert "2" in result.stdout` — attachment count displays "0" instead of "2"
-- **Root cause**: Test sets up top-level `attachments: [{"attachment_id": "a-1"}, ...]` on the mock state, but `misc_cmds.py` reads attachment count from `linked_page_resolution.attachment_total`, not the top-level `attachments` list. Test expectation-vs-implementation mismatch that predates Phase 7.
-- **Evidence**: Same `AssertionError` on master (450f6e3). `misc_cmds.py` was touched in Phase 7 (commit 13f6454, SecretStr sweep) but only changed `api_key.get_secret_value()` → `resolve_secret()` at line ~197; the `linked_page_resolution.attachment_total` read path was not modified.
-- **Action**: none (pre-existing, defer to a follow-up issue)
-
----
-
-### Test: test_extract_docs_refresh_snapshot_prefers_native_repo_identity_for_head_baseline
-- **Status**: pre-existing
-- **Failure**: Assertion on repo identity/head-baseline snapshot path
-- **Evidence**: Fails identically on master (450f6e3) with no diff in the test code vs master. `extract_cmds.py` was modified in Phase 7 (commits a4ffaba + 13f6454) to remove legacy telemetry fields and use `resolve_secret()`, but neither change touches the snapshot identity path exercised by this test.
-- **Action**: none (pre-existing, defer)
-
----
-
-### Test: test_extract_docs_no_change_fast_path_skips_repo_chunk_build_and_repo_refresh
-- **Status**: pre-existing
-- **Failure**: `exit_code == 1`, error: `"Material extraction failed: repo chunk build should be skipped"`. Stderr shows: `"error": "State API missing required function. Tried: list_retrieval_snapshots"` — the mock state in the test doesn't implement `list_retrieval_snapshots`, so the lookup fails and code falls through to chunk building, which then hits the assertion error.
-- **Evidence**: Same failure on master (450f6e3). The `list_retrieval_snapshots` call predates Phase 7; Phase 7 extract_cmds.py diff only removed telemetry fields (retry_events, p95_page_latency_ms, latency_ms, recent_retry_events).
-- **Action**: none (pre-existing, defer — test mock needs `list_retrieval_snapshots` stub)
-
----
-
-### Test: test_extract_docs_linked_page_fast_path_skips_no_change_runs
-- **Status**: pre-existing
-- **Failure**: `assert ['88710001', '1001', '2002'] == ['88710001', '1001']` — page '2002' is downloaded (cache_hit) but test expects it to be skipped by the linked-page fast path. Log shows `extract_docs_linked_page_fast_path_bypassed_no_prior_linked_pages` — fast path is bypassed because there are no prior linked pages in the corpus, so the full download runs instead of the expected no-op.
-- **Evidence**: Same `AssertionError` on master (450f6e3). Phase 7 extract_cmds.py diff is purely telemetry field removal; the linked-page fast path logic is untouched.
-- **Action**: none (pre-existing, defer — test setup needs a corpus with prior linked pages to trigger the fast path)
-
----
-
-### Summary
-- Pre-existing defers: **4**
-- Regressions fixed: **0**
-- Production code changes: **none**
-- Master evidence SHA: `450f6e387acdb86cd8651244eaa612c1fbd5db9b`
-- Verification run: `uv run --project audit_orchestrator pytest <4 tests> -q --tb=short --timeout=60` on master stash → 4 failed, 0 passed (identical failure modes)
-
----
-
-## Lane D — dispatch-status CLI Triage (2026-04-19)
-
-**Scope**: `audit_orchestrator/tests/test_cli/test_doctor_dispatch_status_cli.py`
-**Baseline**: All 5 tests were previously hidden by fixture setup error (AttributeError on `runtime_profiles.load_shared_env`). G1's try/except fix made them runnable, exposing 3 distinct pre-existing isolation/assertion gaps.
-
----
-
-### Test: test_dispatch_status_no_dsn_fails
-- **Status**: fixed
-- **Root cause**: `apply_runtime_profile` (called from `@app.callback()`) invokes `vds_agent_core.profiles.load_shared_env` — a reference not covered by the existing `_isolate_env` patches. This re-loaded `~/.vds/.env` and restored `VDS_AUDIT_STATE_DSN` into `os.environ` even after `monkeypatch.delenv`, causing the command to connect to a real database and return exit 0 instead of failing.
-- **Action**: Added `monkeypatch.setattr("vds_agent_core.profiles.load_shared_env", _noop_env)` to the `_isolate_env` autouse fixture. Test now exits 1 as expected.
-
----
-
-### Test: test_dispatch_status_table_output
-- **Status**: fixed
-- **Root cause**: Rich table column truncation. In an 80-char terminal (CliRunner default), "run-001" → "run-…" and "88727304" → "8872…". Test asserted `"run-0" in result.output` which doesn't match the ellipsis form.
-- **Action**: Updated assertions to `"run-" in result.output` and `"8872" in result.output` — 4-char prefixes present in both truncated and non-truncated forms.
-
----
-
-### Test: test_repair_dispatch_no_stuck_runs_json
-- **Status**: fixed
-- **Root cause**: TSK-170.13 added `store._schema_compat_result` access in `doctor_repair_dispatch` before any repair operations. `FakeStore` lacked this attribute, causing `AttributeError` → caught by `except Exception` → `Exit(1)`.
-- **Action**: Added nested `_Compat` class with `status="compliant", violations=[]` to `FakeStore`.
-
----
-
-### Test: test_repair_dispatch_force_json
-- **Status**: fixed
-- **Root cause**: Same as above — `FakeStore._schema_compat_result` missing.
-- **Action**: Same fix applied to this test's `FakeStore`.
-
----
-
-### Test: test_repair_dispatch_stale_hours_param
-- **Status**: fixed
-- **Root cause**: Same as above — `FakeStore._schema_compat_result` missing.
-- **Action**: Same fix applied to this test's `FakeStore`.
-
----
-
-### Summary
-- Fixes applied: **5** (all 5 tests now pass)
-- Pre-existing defers: **0**
-- Regressions escalated: **0**
-- Classification: All were pre-existing isolation/assertion gaps hidden by the fixture setup error that G1 resolved. No phase 7 production code changes required.
-- Verification: `13 passed in 3.34s` (all 13 tests in the file pass).

package/tools/vds-scripts/.dockerignore

@@ -1,62 +0,0 @@
-.git
-**/.git
-**/.venv
-**/.venv.nosync
-**/__pycache__
-**/.pytest_cache
-**/.mypy_cache
-**/.ruff_cache
-**/.DS_Store
-**/node_modules
-**/dist
-**/build
-**/.cache
-**/.idea
-**/.vscode
-**/.cursor
-**/.zed
-**/.claude
-**/.gemini
-**/.qwen
-**/.lingma
-**/.tox
-**/.coverage
-**/*.pyc
-**/*.pyo
-**/*.pyd
-**/*.log
-# Auto-generated report output dirs (matches .gitignore intent)
-**/reports
-**/output
-# Source-tree exception: audit_orchestrator's `reports/` Python subpackage
-# is real source code, not generated output. Without this un-ignore,
-# hatchling's wheel build excludes it and audit imports fail at runtime.
-!audit_orchestrator/src/vds_audit_orchestrator/reports/
-!audit_orchestrator/src/vds_audit_orchestrator/reports/**
-# Source-tree exception: vds_agent_core's `output/` Python subpackage
-# (added 2026-04-30 via audit-scheduler-event-bus-decoupling v0.2.0).
-# Without this un-ignore, vds_agent_core/__init__.py imports
-# `from vds_agent_core.output import ...` fail at container runtime.
-!vds_agent_core/src/vds_agent_core/output/
-!vds_agent_core/src/vds_agent_core/output/**
-# Large binary files
-**/*.pdf
-**/*.zip
-**/*.tar.gz
-**/*.rar
-# Test files (not needed in container images)
-**/tests/
-# Documentation
-**/docs/
-# Data directories (mounted at runtime, not baked in)
-**/data/
-**/logs/
-# Temporary and backup files
-**/*.tmp
-**/*.bak
-**/*.backup
-**/*.swp
-**/*.swo
-*~
-# Graphify output
-**/graphify-out/

package/tools/vds-scripts/.github/ISSUE_TEMPLATE/cli-change.md

@@ -1,92 +0,0 @@
----
-name: CLI Change
-description: Request a change to the vds-cli surface (commands, orchestrators, or documentation)
-title: "[service] "
-labels: ["cli", "standardization"]
-assignees: []
-body:
-  - type: markdown
-    attributes:
-      value: |
-        Use this template when proposing changes to the vds-cli command surface,
-        adding new orchestrators, fixing CLI bugs, or updating CLI documentation.
-
-  - type: input
-    id: service-name
-    attributes:
-      label: Service name
-      description: Which orchestrator service is affected? (e.g. audit, memory, research)
-      placeholder: e.g. memory
-    validations:
-      required: true
-
-  - type: dropdown
-    id: command-type
-    attributes:
-      label: Command type
-      description: What kind of CLI change is this?
-      options:
-        - New subcommand
-        - New orchestrator
-        - Bug fix
-        - Documentation
-        - Breaking change
-    validations:
-      required: true
-
-  - type: checkboxes
-    id: routing-confirmation
-    attributes:
-      label: Routing confirmation
-      description: Confirm the command is exposed through the unified CLI router.
-      options:
-        - label: CLI commands are exposed through `vds-cli <service>` (not direct entry points)
-          required: true
-
-  - type: checkboxes
-    id: alias-check
-    attributes:
-      label: Alias check
-      description: Confirm no direct executables or aliases are added outside the router.
-      options:
-        - label: No new direct executables or aliases added to pyproject.toml `[project.scripts]`
-          required: true
-
-  - type: textarea
-    id: test-coverage
-    attributes:
-      label: Test coverage
-      description: Describe tests added (CliRunner, mocked externals); link to test files.
-      placeholder: |
-        - Added `test_memory_search.py` with `CliRunner` and mocked Postgres
-        - Link: `vds_cli/tests/memory/test_memory_search.py`
-    validations:
-      required: false
-
-  - type: checkboxes
-    id: standards-review
-    attributes:
-      label: Standards review
-      description: Confirm compliance with the CLI development standards.
-      options:
-        - label: Verified against `vds-scripts/docs/agents/reference/cli-development-standards.md`
-          required: true
-
-  - type: textarea
-    id: breaking-changes
-    attributes:
-      label: Breaking changes
-      description: Any changes to command signatures or JSON output shapes?
-      placeholder: |
-        - `--output` flag renamed to `--format`
-        - JSON shape of `vds-cli audit list` changed from `{...}` to `[...]`
-    validations:
-      required: false
-
-  - type: textarea
-    id: additional-context
-    attributes:
-      label: Additional context
-      description: Anything else reviewers should know.
-    validations:
-      required: false

package/tools/vds-scripts/.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

@@ -1,48 +0,0 @@
-## Summary
-
-<!-- What does this PR change and why? -->
-
-## Change type
-
-- [ ] Bug fix
-- [ ] New feature
-- [ ] Refactoring / cleanup
-- [ ] Documentation
-- [ ] CI / infrastructure
-
----
-
-## CLI Standards Checklist
-
-> Required for all PRs that touch CLI surfaces (orchestrators, commands, docs, skills).
-
-<!--
-If your PR does NOT touch CLI surfaces, write "N/A" below and skip this section.
--->
-
-- [ ] **N/A** (my PR does not touch CLI surfaces)
-- [ ] New commands exposed through `vds-cli` router (not direct entry points)
-- [ ] `pyproject.toml` does NOT add aliases (`[project.scripts]` has one name per target)
-- [ ] Docs/skills show `vds-cli` only (zero direct executable examples)
-- [ ] Tests use `CliRunner` and mock externals (no real API calls in tests)
-- [ ] Follows `typer.Typer()` pattern (or `make_vds_app()` for new CLIs)
-- [ ] `validate-cli-standardization.sh` passes locally
-- [ ] `_validate_alias_phase2.py` passes locally
-
----
-
-## Testing
-
-- [ ] Unit tests added/updated
-- [ ] Integration tests pass
-- [ ] Or: "No behavior changes — existing test coverage sufficient"
-
-## Verification
-
-```bash
-# Paste command(s) used to verify this PR
-# Example:
-# uv run pytest vds_cli/tests/ -q
-# bash scripts/validate-cli-standardization.sh
-# uv run python scripts/_validate_alias_phase2.py
-```