harness-architect

Failing Rust test harnesses are generated by converting work item acceptance criteria into parameterized test scenarios and production stubs. These harnesses compile successfully via cargo check but fail during cargo test with an expected unimplemented marker until the feature is implemented.

A red phase test harness is a compilable Rust test suite that intentionally fails with an unimplemented marker. It translates acceptance criteria into named test scenarios, establishing executable boundaries that verify target behavior before production logic is implemented.

Use a two-step verification gate: run cargo check --all-targets to ensure compilation, then run cargo test to confirm all scenarios fail with the expected unimplemented marker. This guarantees the harness is executable and correctly red before implementation begins.

Yes, test scaffolding applies to new, modified, migrated, and exploratory Rust tasks. It converts acceptance criteria into parameterized test scenarios and production stubs, placing unit, integration, and contract harnesses into the appropriate module directories with companion production stubs.

The best way to trace Rust test scenarios back to backlog tasks is to translate each work item's acceptance criteria into named test scenarios that preserve mapping back to the correct backlog item. This ensures executable contracts remain linked to their originating feature or chore ID.

Rust test harnesses need an unimplemented marker during scaffolding to enforce a strict red-phase gate where all tests fail predictably. This ensures downstream work starts from an executable contract that only passes when the actual target behavior is implemented.