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, then use the instructor rubric (supplied separately). The required outcome is a bounded correction with actual evidence, not a larger code change.
Recording transcript
This challenge brings together exact context, small changes, and evidence-based debugging. You will start with a preserved failure, correct it, and explain why the result is supported. Use the separate fault-fixture checkpoint in a new exercise folder. It is based on checkpoint six and contains one deliberate input error. Do not begin from a previously repaired copy or from the final capstone project.
Establish the starting state before touching the file. Read the checkpoint note, the project README, and the dependency manifest. The input is synthetic, and the policy at this stage handles normal and fault states. Configurable alerts and commands arrive later. The optional interface plan is documentary context; it does not mean that a board or sensor is connected to this run.
Record the source identity and command you are about to execute. Run the normal fixture through the supplied replay wrapper and save the actual exit value. Preserve the full diagnostic along with any output printed before the error. The seeded token is twenty-six C at the second data event, which appears on the third file line. The format expects a numeric token without that suffix.
Write the symptom in a form another engineer could reproduce. The replay rejects the named file at the named line with an invalid-number diagnostic and exit two. Avoid calling it a sensor failure, because no physical sensor supplied this value. Also avoid describing the cause as established until you have compared the input, format requirement, and relevant adapter behavior.
Propose at least two candidate failure locations. The fixture might violate the grammar, or the parser might reject a number the contract permits. Consider what observation would distinguish those explanations. The previous lesson demonstrated one useful pattern, but your report should still explain why that pattern applies here. Repeating a command without a prediction is less informative than a controlled experiment tied to a specific question.
Inspect the intended format. Temperature units are defined by the field, and arbitrary letter suffixes are not accepted inside the numeric token. Preserve the timestamp and event type. Correct only the malformed temperature token to twenty-six in your disposable exercise copy. There is no reason to change the board target, parser, policy, or sensor acquisition to address this input-format problem.
Run the same fixture again after the correction. The expected checkpoint-six sequence is fault, normal, normal, normal, normal, fault, fault, normal. The initial valid reading begins recovery; the second completes it. A later deliberately nonfinite input starts another fault, followed by two valid recovery readings. Keep that modeled failure in the sequence instead of removing it to make every line look normal.
A successful process exit and a fault state are compatible. The adapter can successfully interpret a fixture event that intentionally supplies invalid sensor data. The policy then reports the required fault. A malformed token is different: the adapter cannot interpret it under the contract and rejects the row. Your explanation should keep those two meanings of failure separate because their corrections belong in different places.
Use the stale-recovery fixture for a nearby regression check. The last reading is still current at timestamp four thousand, where its age is exactly three thousand milliseconds. At four thousand and one, the value is stale and unavailable. These are injected timestamps. They test the software rule, not measured MCU or USB latency. State the boundary explicitly in your evidence note.
Follow the recovery events as well. The valid reading at five thousand begins recovery, but missing input at six thousand resets that progress. One valid reading at seven thousand is insufficient, and the next at eight thousand allows normal. Checking only that the first corrected number appears would leave these nearby behaviors unexplained. A useful regression check protects meaning beyond the single visible symptom.
Attempt the documented firmware build using the same selected target. The functional correction is in a host fixture, but the challenge also asks you to demonstrate the recorded project build path when the toolchain is available. Save the actual result separately from replay. A verified final-release build is useful reference evidence, but it does not replace the receipt for your own checkout and environment.
If the build cannot run, identify the exact missing dependency or command failure and preserve the completed investigation. Do not substitute an old binary, a reference log, or a reassuring agent summary. The correction can be ready for review while a required execution gate remains open. The practical challenge is fully verified only when its required checks have actual supporting evidence.
Inspect the final diff. The intended functional change is one fixture token. Your report can add the cause, receipts, recovery route, and limitations. A broad cleanup that changes accepted syntax or alters policy makes the result harder to defend. If an assistant introduces those edits, compare them with the brief and remove unrelated work before presenting the correction as the challenge result.
Add one sourced hardware fact and one unperformed physical claim to the handoff. For example, the exact example variant can be supported by its manufacturer product reference. That does not establish the revision of an unseen assembly, successful wiring, serial enumeration, or measurement accuracy. The exercise is complete without physical hardware, while those optional claims remain outside the software evidence.
Assemble the evidence bundle so another engineer can follow it. Include checkpoint and source identity, the original diagnostic and exit, the small diff, corrected replay, regression output, build record, and a concise handoff. Describe expected output separately from observed output. If an assistant drafts the report, verify every claim against the preserved files rather than accepting a fluent reconstruction of events.
Finish with the module quiz and read the explanations for any missed questions. The recommended score is four out of five with unlimited retry. Quiz progress records your learning interaction; it is not proof that a compiler or replay ran. The practical result is the bounded correction and its defensible evidence. You now have a method for moving from exact context through one useful test to a result another engineer can reproduce and assess.
Download transcript
