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.