ss-tools/.opencode/command/speckit.test.md

description

description
Execute semantic audit and native testing for the active ss-tools feature batch (pytest + vitest).

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Goal

Run the verification loop for the touched ss-tools scope: semantic audit, decision-memory audit, executable tests, logic review, and documentation of coverage/results.

Operating Constraints

1. NEVER delete existing tests unless the user explicitly requests removal.
2. NEVER duplicate tests when existing test coverage already validates the same contract.
3. Decision-memory regression guard: tests and audits must not silently normalize any path documented as rejected.
4. Project-native structure: prefer existing test organization — backend/tests/ for Python, frontend/src/lib/**/__tests__/ for Svelte.

Execution Steps

1. Analyze Context

Run .specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks and determine:

• FEATURE_DIR
• touched implementation tasks from tasks.md
• affected .py and .svelte files
• relevant ADRs, @RATIONALE, and @REJECTED guardrails

All test documentation emitted by this workflow belongs under FEATURE_DIR/tests/ or other files inside specs/<feature>/..., never under .kilo/plans/.

2. Load Relevant Artifacts

Load only the necessary portions of:

• tasks.md
• plan.md
• contracts/modules.md when present
• quickstart.md when present
• .specify/memory/constitution.md
• README.md
• relevant docs/adr/*.md

3. Coverage Matrix

Build a compact matrix:

Module / Flow	File	Existing Tests	Complexity	Guardrails	Needed Verification

4. Semantic Audit and Logic Review

Before writing or executing tests, perform a semantic audit of the touched scope:

1. Reject malformed or pseudo-semantic markup.
2. Verify contract density matches effective complexity.
3. Verify C4/C5 Python flows account for belief runtime markers (reason, reflect, explore with JSON structured logging).
4. Verify C4/C5 Svelte components account for console markers ([ComponentID][MARKER]).
5. Verify no touched code silently restores an ADR- or contract-rejected path.
6. Emulate the algorithm mentally to ensure @PRE, @POST, @INVARIANT, and declared side effects remain coherent.

If audit fails, emit [AUDIT_FAIL: semantic_noncompliance | contract_mismatch | logic_mismatch | rejected_path_regression] with concrete file-based reasons.

5. Test Writing / Updating

When test additions are needed:

• Python: prefer backend/tests/test_*.py with pytest
• Svelte: prefer __tests__/*.test.js with vitest + @testing-library/svelte
• use deterministic fixtures rather than logic mirrors
• trace tests back to semantic contracts and ADR guardrails
• add explicit rejected-path regression coverage when the touched scope has a forbidden alternative

For non-UI backend features, UX verification means validating API envelopes, error responses, and recovery messaging promised by ux_reference.md. For UI features, use browser validation via chrome-devtools MCP.

6. Execute Verifiers

Run the smallest truthful verifier set for the touched scope:

# Backend
cd backend && source .venv/bin/activate && python -m pytest -v
python -m ruff check backend/src/ backend/tests/

# Frontend
cd frontend && npm run test
npm run build

Use narrower test runs when sufficient, then widen verification when finalizing.

7. Test Documentation

Create or update specs/<feature>/tests/ documentation using .specify/templates/test-docs-template.md.

Document:

• coverage summary
• semantic audit verdict
• commands run
• failing or waived cases
• decision-memory regression coverage

8. Update Tasks

Mark test tasks complete only after semantic audit and executable verification succeed.

Output

Produce a Markdown test report containing:

• coverage summary
• commands executed
• semantic audit verdict
• ADR / rejected-path coverage status
• issues found and resolutions
• remaining risk or debt