---
id: M06-L05
title: "Challenge: fix and document a failure"
module: M06
chapters: "12–14"
checkpoint: FAULT-fixture
---

# M06-L05 — Challenge: fix and document a failure

Complete a small engineering investigation from a preserved failure to a documented correction. Use the separate `FAULT-fixture` ZIP in a new exercise folder. It is based on CP06 and intentionally changes one token in the otherwise normal synthetic sequence. Do not begin from a previously repaired folder or the final capstone.

Establish the context before execution. The example target is recorded in the dependency manifest, input is synthetic, and this stage has normal/fault behavior only. The documentary interface plan does not mean hardware is connected. Capture source/checkpoint identity and inspect the relevant fixture without silently fixing it first.

Run `.\scripts\replay.cmd fixtures/normal.csv` and preserve the actual exit and diagnostic. The seeded row contains `26C`; the format expects a number without that suffix. Write at least two candidate failure locations and choose a test that can distinguish them. Your report should make the investigation understandable to someone who did not watch the screen.

Correct only the malformed token to its intended numeric value in the disposable exercise. Do not modify the parser, add a sensor driver, change the board target, or introduce capstone alerts. Run the same fixture again. Its expected CP06 states are FAULT, NORMAL, NORMAL, NORMAL, NORMAL, FAULT, FAULT, NORMAL. The deliberately nonfinite input later in the sequence must still produce FAULT.

Use `fixtures/stale-recovery.csv` as a nearby regression check. The reading is current at timestamp 4000 and stale at 4001. The missing event at 6000 interrupts recovery; one valid sample at 7000 remains in FAULT, and the next at 8000 allows NORMAL. These observations protect behavior beyond the corrected token.

Attempt the recorded firmware build and save the actual receipt or precise open dependency. A fixture-only change does not alter the sketch source, but the challenge still asks you to demonstrate the documented build path when available. Do not present an older pilot artifact as a build of your current checkout. Physical operation remains unperformed in this core challenge.

Review the final diff. The intended functional correction is one fixture token. Your accompanying report can explain the cause, evidence, recovery route, and limitations. A broad “cleanup” that changes the parser or policy makes the result harder to defend and may invalidate the original test.

Finish with an evidence-based handoff: exact starting/final state, changed files, commands/results, source identity, and any remaining gate. Take the five-question module quiz after the practical task. A quiz pass checks understanding; browser progress is a self-reported learning record and does not prove that a build or replay happened.

## Resources and completion

Use Chapters 12–14, FAULT-fixture/CP06, and the format and hardware references. Figure references: SS12-04, SS13-03–05, and SS14-01–04. Complete [the challenge](exercise.md), then use [the instructor rubric](answer-key.md). The required outcome is a bounded correction with actual evidence, not a larger code change.