eron1703 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
- No code without specs — specs must be written and approved first
- TDD mandatory — write tests before implementation
- No mocks in integration/E2E tests — unit tests may use mocks where necessary
- 80% coverage threshold — for all new code
- E2E verification required — test as a real user before marking untested
- 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.