Skip to content

TDD Pipeline

Version: 1.0 Status: ACTIVE (2026-01-27) Maintained by: Shared Services (Specification Agents)

The Test-Driven Development (TDD) Pipeline is GE's automated workflow for transforming requirements into verified code through rigorous specification and test generation.

Overview

The TDD Pipeline ensures that every piece of code is: 1. Specified precisely before implementation 2. Tested comprehensively with generated tests 3. Validated against formal specifications 4. Traceable from requirement to implementation

Core Principle: "Spec first, test generated, code verified."

Pipeline Stages

Stage 1: Functional Specification (Aimée)

Input: Requirements from project scope, user stories, or technical designs Agent: Aimée (Scope Architect) Output: Functional specification (human-readable Markdown)

What happens: - Aimée analyzes requirements and technical constraints - Writes functional specification describing WHAT needs to be built - Includes behavioral expectations, constraints, and success criteria - Reviews with human for approval - Publishes functional spec to Annegreet for storage

Artifacts: - Functional specification document (Markdown) - Approval record

Stage 2: Functional Spec Storage (Annegreet)

Input: Functional specification from Aimée Agent: Annegreet (Knowledge Curator) Output: Stored functional spec + notification to Anna

What happens: - Annegreet receives functional spec - Stores in wiki at /specs/functional/{project}/{spec-id}.md - Creates index entry in registry - Publishes notification to Redis channel functional.spec.stored - Anna receives notification and begins transformation

Artifacts: - Indexed functional specification - Registry entry - Redis notification

Stage 3: Formal Specification (Anna)

Input: Functional specification (via Annegreet notification) Agent: Anna (Formal Specification Agent) Output: Formal specification (YAML with invariants, edge cases)

What happens: - Anna reads functional specification - Reads GE Agent Constitution for compliance - Extracts behavioral requirements and constraints - Transforms to formal YAML specification: - Function signatures - Pre-conditions and post-conditions - Invariants (minimum 3 per function) - Edge cases with expected behaviors - Examples for clarity - Verifies constitution compliance - Checks token budget (≤15,000 per spec) - Auto-publishes if valid + compliant, escalates if ambiguous - Publishes to Redis channel formal.spec.created

Artifacts: - Formal specification (YAML) - Constitution compliance verification - Redis notification

Stage 4: Formal Spec Storage (Annegreet)

Input: Formal specification from Anna Agent: Annegreet (Knowledge Curator) Output: Stored formal spec + notifications to consumers

What happens: - Annegreet receives formal spec from Anna - Stores in registry at /specs/formal/{project}/{spec-id}.yaml - Creates index entry linking to parent functional spec - Publishes notifications to downstream consumers: - Aydan (validation) - Antje (test generation) - Ashley (code understanding)

Artifacts: - Indexed formal specification - Registry entry with lineage - Redis notifications to consumers

Stage 5: Test Generation (Antje)

Input: Formal specification (via Annegreet notification) Agent: Antje (Test Generation Agent) Output: Generated test suite

What happens: - Antje reads formal specification - Generates comprehensive test cases: - Tests for each invariant - Tests for all edge cases - Tests for pre-condition violations - Tests for post-condition verification - Writes tests in appropriate framework (Jest, pytest, etc.) - Validates tests can run (syntax check) - Publishes generated tests

Artifacts: - Generated test files - Test execution plan

Stage 6: Validation (Aydan)

Input: Formal specification (via Annegreet notification) Agent: Aydan (Validation Agent) Output: Validation report or revision request

What happens: - Aydan reads formal specification - Validates spec against existing codebase: - Function signatures match - Behaviors align - Edge cases handled - Invariants satisfied - If issues found: - Publishes formal.spec.revision_request to Anna - Anna revises and republishes - If validation passes: - Approves spec for use - Notifies that tests can run

Artifacts: - Validation report - Revision requests (if needed) - Approval record

Stage 7: Code Understanding (Ashley)

Input: Formal specification (via Annegreet notification) Agent: Ashley (Code Understanding Agent) Output: Code analysis and alignment verification

What happens: - Ashley reads formal specification - Analyzes implementation code - Verifies alignment: - Code satisfies invariants - Edge cases handled correctly - Pre/post-conditions met - Provides feedback to developers - Updates knowledge base with patterns

Artifacts: - Code analysis report - Pattern documentation - Alignment verification

Complete Flow Diagram

Requirements/User Stories
         |
         v
    [1. Aimée]
    Functional Specification
    (Markdown, human-readable)
         |
         v
    [2. Annegreet]
    Store functional spec
    Publish: functional.spec.stored
         |
         v
    [3. Anna]
    Formal Specification
    (YAML, mathematical rigor)
         |
         v
    [4. Annegreet]
    Store formal spec
    Publish: formal.spec.created
         |
         +----------------+----------------+
         |                |                |
         v                v                v
    [5. Antje]      [6. Aydan]       [7. Ashley]
    Generate        Validate         Understand
    Tests           Spec             Code
         |                |                |
         |                |                |
         +-------+--------+                |
                 |                         |
                 v                         v
            Run Tests                Code Review
            against Code            & Feedback
                 |
                 v
            Verified
            Implementation

Redis Channels

The TDD Pipeline uses Redis pub/sub for agent coordination:

Channel Publisher Subscribers Message Content
functional.spec.stored Annegreet Anna {spec_id, spec_path, created_by, timestamp}
formal.spec.created Anna Annegreet {formal_spec_id, spec_path, functional_spec_id, timestamp}
formal.spec.updated Anna Annegreet {formal_spec_id, spec_path, version, revision_reason, timestamp}
formal.spec.revision_request Aydan Anna {formal_spec_id, issues: [], requested_by, timestamp}
test.suite.generated Antje Delivery agents {test_suite_id, formal_spec_id, test_paths: [], timestamp}
validation.completed Aydan Delivery agents {formal_spec_id, validation_status, issues: [], timestamp}

Specification Registry

All specifications are stored and indexed by Annegreet:

Directory Structure: 

/specs/
  functional/
    {project}/
      {spec-id}.md          # Functional specifications
  formal/
    {project}/
      {spec-id}.yaml        # Formal specifications
  registry/
    functional-index.yaml   # Index of all functional specs
    formal-index.yaml       # Index of all formal specs
    lineage.yaml           # Parent-child relationships

Registry Entry Example: 

spec_id: "FS-ecommerce-cart-addItem-20260127-001"
type: "formal"
created_by: "anna"
created_at: "2026-01-27T10:30:00Z"
parent_spec_id: "FUNC-ecommerce-cart-20260127-001"
project: "ecommerce"
domain: "cart"
function: "addItem"
status: "active"
consumers:
  - aydan
  - antje
  - ashley
validation_status: "passed"
test_coverage: "100%"

Specification Lineage

Every formal spec traces back to its parent functional spec:

Functional Spec: FUNC-ecommerce-cart-20260127-001
  "User can add items to shopping cart"
         |
         | (Anna transforms)
         |
         v
Formal Spec: FS-ecommerce-cart-addItem-20260127-001
  Pre-conditions: [cart exists, item valid, quantity > 0]
  Post-conditions: [item in cart, quantity updated, cart total recalculated]
  Invariants: [cart.total = sum(item.price * item.quantity), ...]
  Edge cases: [empty cart, duplicate item, out of stock, ...]
         |
         | (Antje generates)
         |
         v
Test Suite: TS-ecommerce-cart-addItem-20260127-001
  - test_addItem_to_empty_cart()
  - test_addItem_duplicate_increments_quantity()
  - test_addItem_out_of_stock_throws_error()
  - test_cart_total_recalculated()
  - ...

Success Criteria

The TDD Pipeline is successful when:

Metric Target Measured By
Functional specs approved 100% Aimée + human review
Formal specs valid 100% Anna auto-validation
Constitution compliance 100% Anna verification
Specs validated 100% Aydan validation
Tests generated 100% Antje generation rate
Test coverage ≥90% Test execution results
Revision rate <10% Anna/Aydan feedback loop

Quality Gates

Each stage has mandatory quality checks:

Functional Spec (Aimée): - [ ] Human-readable and unambiguous - [ ] All behavioral requirements documented - [ ] Success criteria defined - [ ] Human approved

Formal Spec (Anna): - [ ] Valid YAML syntax - [ ] ≥3 invariants per function - [ ] Complete edge case coverage - [ ] Constitution compliance verified - [ ] Token budget ≤15,000 per spec - [ ] Lineage tracking complete

Test Generation (Antje): - [ ] All invariants tested - [ ] All edge cases covered - [ ] Pre-condition violation tests - [ ] Post-condition verification tests - [ ] Tests executable (syntax valid)

Validation (Aydan): - [ ] Spec aligns with codebase - [ ] Function signatures match - [ ] Behaviors implemented correctly - [ ] Edge cases handled

Escalation Paths

Issue Escalate To Action
Ambiguous functional spec Aimée + Human Clarify requirements
Contradictory requirements Aimée + Human Resolve conflicts
Unclear constitution compliance Anna + Human Interpret constitution
Spec doesn't match code Aydan → Anna Request revision
Tests fail Antje → Delivery agents Fix implementation
Token budget exceeded Anna Split specification

Best Practices

  1. Write functional specs first - Never start coding without a functional spec
  2. Review specs with humans - Aimée always gets human approval before Anna transforms
  3. Split large specs proactively - Anna creates one formal spec per function/feature
  4. Preserve lineage - Every formal spec links to its parent functional spec
  5. Validate early - Aydan validates specs before tests run
  6. Generate tests before coding - Antje generates tests from formal specs, then developers implement
  7. Keep specs up-to-date - When code changes, update specs first

The TDD Pipeline: From requirements to verified code with mathematical precision.