methodology

name	methodology
description	Unified development methodology - IV&V, pipeline, quality gates
disable-model-invocation	true

Development Methodology

6-Phase Pipeline

Every piece of work follows this pipeline in order:

Phase	Name	What Happens
1	KICK	Work item created, assigned, context gathered
2	COLLECT	Requirements collected, existing code analyzed
3	SPEC	Specifications written (acceptance criteria, edge cases)
4	CHECK	Specs reviewed, approved before any code
5	BUILD	Code written following TDD (specs → tests → code → refactor)
6	MERGE	PR created, reviewed, E2E tested, merged

Key rule: No code before specs are approved (Phase 4 → Phase 5).

Independent Verification & Validation (IV&V)

The 18-stage pipeline orchestrator (dev-02:30092) enforces context isolation between builder and tester:

Builder Context (BUILD phase)

• Sees: work items + approved specs
• Does NOT see: test scenarios
• Builds to spec, not to tests

Tester Context (after BUILD)

• Sees: ONLY test scenarios (generated from specs independently)
• Does NOT see: implementation details
• Tests blind — verifies behavior matches scenarios

Why IV&V Matters

• Prevents "teaching to the test" — builder can't optimize for specific test cases
• Catches spec-vs-implementation mismatches — if the spec is ambiguous, builder and tester will interpret it differently, surfacing the gap
• Higher confidence — passing blind tests means the feature actually works as specified

Work Item Status System

All work items (FIX-, CR-, FB-, WI-) use EXACTLY these 4 statuses:

Status	Meaning	Who Sets It
pending	Not started	Default
started	Work in progress	Agent/supervisor when work begins
untested	Code deployed, awaiting user verification	Agent/supervisor after deploy
accepted	Formally accepted by user	USER ONLY — NEVER set by agent

This is NOT the same as session reporting. When a worker reports to a supervisor about their session, they use DONE/PARTIAL/BLOCKED. Those are session report statuses, not work item statuses.

Quality Gates

1. No code without specs — specs must be written and approved first
2. TDD mandatory — write tests before implementation
3. No mocks in integration/E2E tests — unit tests may use mocks where necessary
4. 80% coverage threshold — for all new code
5. E2E verification required — test as a real user before marking untested
6. User acceptance required — only the user can mark work as accepted

Tracker

Work items are tracked in TRACKER.md in the project's run directory. Update status there when it changes.

Pipeline Orchestrator

For the full 18-stage automated pipeline, use the orchestrator at dev-02:30092. For manual work, follow the 6-phase pipeline above.