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

description

description
Execute semantic audit and Python/Svelte-native testing for the active feature batch.

User Input

$ARGUMENTS

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

Goal

Run the verification loop for the touched Python/Svelte scope: semantic audit, decision-memory audit, executable tests (pytest + vitest), 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 backend/tests/ or frontend/tests/ coverage already validates the same contract.
3. Decision-memory regression guard: tests and audits must not silently normalize any path documented as rejected.
4. Python/Svelte-native structure: prefer existing test organization:
   • Backend: backend/tests/ with pytest
   • Frontend: frontend/tests/ or co-located __tests__/ with vitest + @testing-library/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
• docs/SEMANTIC_PROTOCOL_COMPLIANCE.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. Use the AXIOM semantic validation path where available.
2. Reject malformed or pseudo-semantic markup.
3. Verify contract density matches effective complexity.
4. For C4/C5 Python flows: verify belief runtime markers (belief_scope, reason, reflect, explore).
5. For C4/C5 Svelte components: verify @UX_STATE, @UX_FEEDBACK, @UX_RECOVERY, @UX_REACTIVITY coverage.
6. Verify no touched code silently restores an ADR- or contract-rejected path.
7. 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:

• Backend: prefer backend/tests/ with pytest fixtures, use unittest.mock / pytest-mock for external dependencies
• Frontend: prefer vitest with @testing-library/svelte for component testing, jsdom environment
• 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 Svelte UX contracts, validate @UX_STATE transitions, @UX_FEEDBACK messages, and @UX_RECOVERY paths

6. Execute Verifiers

Run the smallest truthful verifier set for the touched scope, typically chosen from:

# Backend tests
cd backend && pytest

# Backend lint
ruff check backend/

# Frontend tests
cd frontend && npm run test

# Frontend build check (catches Svelte compilation errors)
cd frontend && npm run build

# Semantic static verification (when available)
python3 scripts/static_verify.py

Use narrower test runs when they are sufficient (e.g., pytest backend/tests/test_auth.py) and then widen verification when finalizing the feature batch.

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