This repository enforces Test-Driven Development with Integrated Security (Secure TDD). You MUST adhere strictly to the 4-phase inner-loop workflow on all feature development, bug fixes, and refactoring tasks:
-
Phase A (Plan, Scope & Threat Model):
- Ingest
CONTEXT.mdto identify existing trust zones, architectural boundaries, and approved helpers. - Decompose feature requirements, user stories, and acceptance criteria.
- Run a STRIDE threat model on the planned change and update
threat_model.mdat the repository root with Functional & Security Acceptance Criteria.
- Ingest
-
Phase B (Functional & Security Test-First - RED):
- Author unit/integration tests that assert functional correctness (happy paths, business logic), edge cases, and security boundary enforcement (e.g. rejecting unauthenticated, unauthorized, or malformed inputs).
- Execute the test suite and confirm that tests FAIL for the expected assertion reason (RED).
-
Phase C (Feature Implementation & Defensive Code - GREEN):
- Write clean, modular production code strictly necessary to satisfy functional requirements and passing tests.
- Adhere to defensive standards: strict input allow-lists (
pydantic), parameterized queries, canonical path checking, and least-privilege responses. - Re-run tests to confirm GREEN.
-
Phase D (Refactor, Quality & Local Scan):
- Clean up code, eliminate duplication, and verify 100% passing test regressions across the suite.
- Perform local deterministic scans on changed files (secrets, dependencies, Semgrep).
- Review code for logic bypasses and keep diffs minimal and surgical.
-
Continuous Evolution (Learn & Update):
- When a bug, convention, or helper is introduced, extract the systemic rule and append it to
CONTEXT.mdunder## 4. Continuous Evolution: Auto-Evolved Conventions.
- When a bug, convention, or helper is introduced, extract the systemic rule and append it to
-
Multi-Finding Remediation Protocol:
- When fixing multiple findings from scans or review, process them sequentially one finding at a time:
- Author one boundary test for the finding (RED).
- Implement the minimal defensive fix (GREEN).
- Verify the local test passes before moving to the next finding.
- Avoid batching multiple unrelated edits in a single unverified change. Verify the full suite once all findings have passed their discrete cycle.
- When fixing multiple findings from scans or review, process them sequentially one finding at a time:
- Database: Parameterized SQL / ORM only (never string formatting or f-strings).
- Paths: Use
utils.security.resolve_safe_path(base_dir, user_filename). - Redirects: Use
utils.security.safe_redirect(url, allowed_hosts). - Commands: List-format
subprocess.run([...], shell=False)only.