minimal-test-gate

name	minimal-test-gate
description	Use only after the main path exists to choose and implement 1-3 critical-path tests that prove the MVP closes the loop. Not for broad coverage goals, full E2E suites, or testing every edge case.
origin	ECC-derived

Minimal Test Gate

Source Lineage

Primary inherited sources:

• legacy/ecc-source/agents/tdd-guide.md
• legacy/ecc-source/skills/tdd-workflow/SKILL.md
• legacy/ecc-source/skills/verification-loop/SKILL.md
• legacy/ecc-source/skills/ai-regression-testing/SKILL.md
• legacy/ecc-source/skills/eval-harness/SKILL.md
• legacy/ecc-source/agents/code-reviewer.md
• legacy/ecc-source/commands/tdd.md

Inherited methods:

• preserve RED -> GREEN -> REFACTOR reasoning even under time pressure
• start from user journeys and stable behavior, not implementation trivia
• define the proof target before implementation whenever possible
• write a regression test for a reproduced bug before fixing it
• verify the smallest set of checks that proves readiness
• report what remains risky instead of pretending coverage is complete

When To Use

Use this after the core path is implemented and before final handoff. If you are still before implementation, use it briefly to define the minimum proof target first, then come back after the main path exists.

Expected Outputs

• a tiny test plan
• a one-line verification standard or acceptance target
• 1-3 tests that prove the MVP works
• one short note about what is intentionally untested

Default Test Selection

Pick only the highest-signal cases:

1. happy path
2. one key validation or failure path
3. one archetype-specific check if it proves real value

Examples:

• gateway/proxy: valid route, invalid request, upstream failure normalization
• tool agent: tool selection, invalid tool args
• retrieval: retrieval hit, empty or no-match response
• workflow: successful step sequence, early failure reporting

Test Workflow

1. Write down the user journey or system journey you must prove before implementation.
2. Prefer the smallest failing test that demonstrates the missing behavior.
3. For a bug fix, reproduce the bug with a regression test first.
4. Implement or adjust only enough code to pass that test.
5. Rerun the smallest meaningful check after each fix.
6. Stop once the main loop is credibly proven.

Verification First

Before writing code, define one of these:

• a minimal automated acceptance test
• a minimal regression test for the known bug
• a minimal manual verification method if the stack or timebox blocks automation

If you cannot automate first, still write down the exact proof you will use. Do not start implementation with no test target at all.

Reporting Format

• Tests selected:
• Verification standard:
• Why these tests matter:
• What remains intentionally untested:

Test Standard

• make tests small
• assert stable behavior, not implementation trivia
• prefer regression-proof tests for bugs that were actually observed
• stop once the main loop is credibly proven

What Not To Do

• do not chase coverage numbers
• do not build a full browser suite unless the prompt depends on UI behavior
• do not add tests that duplicate the contract without adding confidence
• do not spend the final 20 minutes converting a working MVP into a full pyramid