---
id: M06-L04
title: Diagnose a fault with one useful test
module: M06
chapters: "14"
checkpoint: CP06
---

# M06-L04 — Diagnose a fault with one useful test

Distinguish a malformed fixture from a policy fault using one controlled change. Start with CP06. Write the symptom before asking an assistant to name a cause: exact checkpoint, command, expected behavior, actual output/exit, and the smallest relevant input.

Run the supplied failure:

```powershell
.\scripts\replay.cmd fixtures/invalid.csv
$invalidExit = $LASTEXITCODE
```

The expected result is exit two with a line-three invalid-sample-number diagnostic. The file contains `28C`, which the fixture grammar does not accept. Startup and an earlier valid record may appear before rejection. Preserve stdout and stderr rather than treating partial output as success.

Locate the failure layer. A compiler failure prevents a build; a runtime dependency failure can prevent startup; a parse failure occurs in a running adapter; a policy failure can produce valid JSON with the wrong meaning. Here the line-number diagnostic shows that execution reached fixture parsing. No physical sensor was read.

Name competing explanations: the token violates the format, the parser rejects a supported number, or policy fails after receiving a valid reading. Inspect the format contract and relevant `host/replay.cpp` code. The adapter requires the complete numeric token; unit suffixes are not part of this small fixture language.

Choose one discriminating test. Copy `invalid.csv` to `lab14-valid.csv` and change only `28C` to `28`. Run the copied fixture through the same source/executable path. Successful acceptance supports the malformed-input explanation while holding policy and toolchain constant.

```powershell
Copy-Item .\fixtures\invalid.csv .\fixtures\lab14-valid.csv
# Edit only 28C to 28 in the copied file, then save it.
.\scripts\replay.cmd fixtures/lab14-valid.csv
$correctedExit = $LASTEXITCODE
```

Run the original invalid fixture again. It should still be rejected. The paired result is stronger than a lone pass because it shows that the correction did not weaken the parser. Do not ignore arbitrary suffixes or substitute zero to hide malformed input; both change the meaning of the exercise.

Ask the assistant to explain predicted observations before editing. A useful request supplies the symptom, file, format requirement, and relevant code, then asks for a test that separates explanations. After execution, ask what the result supports and what remains untested. Preserve a contradicted hypothesis rather than rewriting the investigation into an invented straight-line success.

The same approach applies to a stale-policy defect, but the observations differ. At 4001 in `stale-recovery.csv`, current data must expire. A formatter-only patch can hide the state label while leaving availability or recovery incorrect. Chapter 14's second exercise traces the policy transition; the module challenge first asks you to defend a small fixture correction independently.

## Resources and completion

Use CP06, Chapter 14, `fixtures/invalid.csv`, and the host adapter. Figure references: SS14-01–04. Complete [the exercise](exercise.md) and consult [the key](answer-key.md) after recording your own result. A hypothesis is not a root cause until the evidence supports its mechanism.