Build Phase - Production Standard (TDD MANDATORY)

Build Phase - Production Standard (TDD MANDATORY)

CRITICAL: This is a TDD-First, Production-Quality Codebase

**Every change MUST follow Test-Driven Development:**

1. Write failing tests FIRST - before ANY implementation code
2. Tests define the contract - implementation follows
3. No exceptions, no shortcuts, no "I'll add tests later"

**Production standard means:**

• Zero warnings, zero dead code, zero TODOs
• Every public API tested and documented
• Security scanned before every commit

---

Phase 0: REINDEX (Start of Task)

**Before starting any task, refresh narsil-mcp index:**

reindex

This ensures code intelligence reflects the current codebase state.

---

Phase 1: PLAN

• Read IMPLEMENTATION_PLAN.md
• Select highest-priority incomplete task from current sprint
• Reference Documents:
  • further_dev_plans/ralph-multilang-bootstrap.md for multi-language design
  • Existing code patterns in src/quality/gates.rs, src/bootstrap/
• Context Gathering (narsil-mcp - optional, degrades gracefully):
  • get_call_graph - understand function relationships
  • get_dependencies - understand module dependencies
  • find_references - impact analysis for changes
  • get_ccg_manifest - get codebase overview (if CCG available)
  • export_ccg_architecture - understand public API surface
• Identify all types/functions that will be affected

**Current Focus: Sprint 7 - Language-Specific Quality Gates**

Goal: Create quality gates that use each language's standard tooling (Python: ruff/pytest/mypy, TypeScript: eslint/jest/tsc, Go: vet/golangci-lint/test).

Key tasks:

• 7a: Refactor Gate trait → QualityGate trait with gates_for_language() factory
• 7b: Python gates (RuffGate, PytestGate, MypyGate, BanditGate)
• 7c: TypeScript/JS gates (EslintGate, JestGate, TscGate, NpmAuditGate)
• 7d: Go gates (GoVetGate, GolangciLintGate, GoTestGate, GovulncheckGate)
• 7e: Gate auto-detection based on available tools

Phase 2: TEST FIRST (TDD)

**Before writing ANY implementation code:**

1. Write failing test(s) that define the expected behavior
2. Run tests to confirm they fail for the right reason
3. Document the behavioral contract in test comments
4. If modifying existing code, ensure existing tests still define correct behavior

**Test Requirements:**

• Every public function must have at least one test
• Every public type must be exercised in integration tests
• Edge cases must be tested (empty inputs, errors, boundaries)
• Use #[should_panic] for expected panic paths

Phase 3: IMPLEMENT

• Write minimal code to make tests pass
• Use find_references to ensure no breaking changes
• Update inline documentation with # Examples and # Panics

**Implementation Rules:**

• NO #[allow(...)] annotations - fix warnings at source
• NO #[dead_code] - if it exists, it must be tested and used
• NO placeholder/stub implementations - fully implement or don't merge
• NO TODO/FIXME comments in merged code
• Every warning is