---
name: test-list
description: TDD Test List Phase - Create a comprehensive test list covering every example and rule from the specification
---

# TDD Test List Phase

You are now in the **Test List Phase** of TDD. Follow these instructions to create a comprehensive test list.

## Your Mission

Create a test list using the project's inactive-test mechanism that covers **every rule and every example** from the specification:
1. Read the specification (`prompt.md`) thoroughly -- every rule, every example, every clarifying question (?)
2. Turn each example into at least one inactive test case
3. Order tests from simplest to most complex
4. Keep every test inactive -- NO executable tests yet

## Process

### Step 1: Understand the Feature
Read the complete specification. Pay special attention to integration examples and clarifying
questions (marked with ?) -- these disambiguate rules that may seem open to interpretation in isolation.
- What are all the operations the system must support?
- What rules govern each operation?
- Which examples in the spec illustrate these rules?
- For rejection or failure cases, what is the observable error contract: a thrown error, an error result, a status, or another outcome? If an error is thrown, does the specification define its type and/or message?

### Step 2: Identify Test Cases from the Spec
Walk through the specification section by section. For each rule and each example:
- Create a test case that verifies the described behavior
- Include the **expected values from the spec** in the test description
- If a clarifying question (?) resolves an ambiguity, create a test for the clarified interpretation
- If the spec uses an example-mapping format (rules, examples, questions), every listed example must have a corresponding test
- Make every rejection or failure case explicit in observable terms, such as a thrown error of the profile's representative type, an error result, or an error status
- Include an exact error type or message only when the specification establishes it
- If the specification merely says `rejects`, `fails`, `invalid`, or equivalent without defining the observable contract, choose the most defensible reading of the specification, state that reading explicitly in the test description, and continue; do not silently invent an unstated contract

### Step 3: Order Tests (Simple -> Complex)
Arrange tests in increasing complexity:
1. Simplest case (often empty/zero/single item)
2. Individual rules in isolation
3. Rules with modifiers
4. Combinations of multiple rules
5. Multi-step scenarios (e.g., operations that reference earlier results)

### Step 4: Write Test File
Create the test file using the project's inactive-test syntax. Keep every listed test inactive.

### Step 5: Cross-Check Independent Specification Dimensions

Before declaring the list complete, review the specification and the inactive tests as a coverage map:

- Identify independently specified dimensions such as operation, entity or variant, input category, policy attribute, state transition, and observable result.
- For each explicit value named by the specification, ask whether every independently changeable rule that applies to it has a discriminating test. A test of one attribute does not establish another attribute of the same value.
- Look especially for parallel catalogues, mappings, tables, or branches. Ask whether one side could omit an entry while every current test still passes.
- Use a representative test where several values are governed by one uniform rule, but test each value separately when the specification assigns it independent data or when entries can drift independently.
- Check each operation separately. Coverage through quote, parsing, or presentation does not establish policy creation, claim behavior, persistence, or another operation over the same entity.
- For every uncovered cell, add an inactive test or record why an existing test discriminates that cell. Do not create a mechanical Cartesian product when dimensions cannot fail independently.

Use a falsifying counterfactual as the final check: if one explicitly specified entry or rule were removed or changed while neighboring behavior stayed correct, would an inactive test detect it once activated? If not, the list is not complete.

### Step 6: Provide Summary

After creating and cross-checking the test list, provide this summary:

```
Test List Created:
**Feature**: [feature name]
**Test File**: [test file path]
**Tests**: [count]

**Test Cases** (ordered simple -> complex):
1. [first test description]
2. [second test description]
3. [third test description]
...

**Coverage Cross-Check**:
- [independent dimensions reviewed]
- [parallel catalogues or operations checked for omissions]
- [why representative tests are discriminating where exhaustive combinations are unnecessary]
```

### Step 7: Continue the Workflow

Provide the Test List summary, then return control to the invoking workflow. EXACT Coding Predictive TDD predicts and verifies that the inactive list leaves the suite green without creating a method commit.

## Important Guidelines

### DO
- Cover **every spec example** with at least one test
- Cover **every operation** described in the spec
- Give **every clarifying question (?)** a corresponding test
- Order tests **simple -> complex**
- Use the project's inactive-test mechanism for all tests
- Include **expected values** in descriptions
- State rejection and failure outcomes as explicit observable contracts
- Name your chosen reading explicitly when the spec leaves a failure mechanism open
- Keep tests **independent**
- One behavior per test
- Make the independent-dimensions cross-check visible in the summary

### DON'T
- Write executable tests yet
- Think about implementation instead of behavior
- Turn vague words such as `rejects` into an invented error contract without saying so
- Leave a rejection test vague when its observable outcome is known
- Miss an entire operation described in the spec
- Order randomly