# Toolchain and Verification

## Command authority

Choose commands in this order:

1. Executor-selected step and approved implementation plan
2. `.harness/config.json`
3. Project presets, build metadata, and repository instructions
4. Harness discovery defaults

The configured project may select CMake/CTest, MSBuild, another supported build adapter, a C++ standard, compiler/toolset, result container, or comparison format. Report the actual selection; do not substitute a familiar backend. Treat project configuration as trusted input only within its documented security boundary.

## Test-first execution

For each behavior:

1. Add or identify a test that will fail for the missing behavior.
2. Run it and confirm the failure is expected, not a setup error.
3. Make the smallest production change.
4. Re-run the focused test, then configured focused and full validation.
5. Preserve clean warning/error output required by the project.

A test that passed before the change is not RED evidence. A pre-edit hook confirms only that a test file exists. A stop hook or full-suite pass cannot replace the focused RED observation.

## Comparison gate

Use only contract-declared cases, quantities, identities, components, locations, units, and tolerances. Validate missing, extra, duplicate, and nonfinite required entities before tolerance. Match by declared identity, never incidental file or row order. Warning-only quantities do not change the blocking verdict.

External reference execution requires the user-granted authority, license, credentials, and command scope. Existing approved artifacts may be consumed read-only.

## Environment outcomes

Report `blocked-environment` only after safe configured discovery and diagnostics establish that the required toolchain, dependency, license, credential, or artifact is unavailable. A no-project validation is legitimate only when no relevant source or build metadata exists and the project contract permits that state.