adaptive-testinglisted

# Adaptive Testing ## Purpose Produce revision-specific behavioral evidence without mechanically running every test layer for every change. ## Trigger Run for any code change, when a Gate requires test evidence, after integration, after upstream behavior changes, or when prior test evidence becomes stale. ## Inputs - Changed paths/revision, change type, affected Components, and blast radius. - Requirement/acceptance IDs, Contracts, risk, Workflow Level, supported environments, and DoD. - Existing tests, test data, prior failures, and regression history. ## Prerequisites - Expected behavior is sufficiently defined. - Confirm the test environment and exact revision under test. - Distinguish missing product behavior from missing test coverage. ## Procedure 1. Classify the change: Pure Function, Module, API/Contract, Data, Multiple Components, Architecture, Security-sensitive, or Performance-sensitive. 2. Map affected Requirements, Contracts, failure modes, and regression surface. 3. Reuse valid tests and identify genuine coverage gaps. 4. Select the minimum sufficient layers: - Pure Function: unit plus focused regression. - Module: unit, module, and relevant regression. - API: unit, consumer/provider Contract, integration, and regression. - Data/schema/migration: validation, migration/rollback, compatibility, integrity, and regression. - Multiple Components: Component evidence, Contract, integration, and regression. - Architecture: unit, Contract, int