When something fails, start with a reproducible observation rather than a diagnosis. In this lesson, the program rejects a synthetic input file. We will locate the failure layer, propose competing explanations, and make one small change that distinguishes them. Open checkpoint six in a new folder and preserve its original files. The physical sensor is not part of this exercise.

Write the command and expected behavior before running it. We are using the replay wrapper with the invalid fixture. Save the actual process exit immediately afterward, and preserve both ordinary output and the error diagnostic. A useful symptom record names the checkpoint, input file, exact command, expectation, and observed result. Another engineer should be able to repeat it without guessing which version you used.

The supplied fixture contains a token with a letter suffix: twenty-eight C. The adapter expects a number without that suffix. The intended failing run exits two and identifies the third file line as an invalid sample number. A startup record and an earlier valid sample may appear first. Partial output does not mean that the rejected token became a valid temperature or that the complete scenario succeeded.

Locate the failure layer before asking for a patch. A compiler failure prevents a successful build. A linker problem prevents the required pieces from combining. A missing runtime dependency can prevent an executable from starting. Here, a line-number diagnostic appears from the running adapter, which tells us execution reached input parsing. That is evidence about where to inspect next, not a physical sensor observation.

Write at least two explanations. Perhaps the fixture violates the supported format. Perhaps the parser wrongly rejects an allowed numeric token. A third possibility is that policy fails after receiving a valid sample. These explanations are not equally supported once we read the diagnostic and code, but stating them helps us choose an experiment instead of jumping directly to a broad rewrite.

Open the format description and the relevant host adapter source. The small fixture language gives temperature a documented unit and requires the complete numeric token to be accepted. It does not support arbitrary unit suffixes on each value. Explicit missing and nonfinite tokens represent modeled input failures. Those valid event descriptions are different from a malformed row that the adapter cannot interpret.

Ask the assistant for a discriminating test before permitting an edit. Supply the exact symptom, small fixture, format requirement, and relevant code. Request a predicted observation for each explanation. A suggestion such as try another input is incomplete unless it names the input change, the command, and how the outcome would affect the diagnosis. The explanation should lead to an executable check.

Choose the smallest useful change: make a copied fixture and remove only the C suffix from the numeric token. Keep the original invalid file. Run the copied file through the same source and executable path. This holds the toolchain, adapter, and policy constant while changing the suspected malformed input. Successful acceptance supports the input-format explanation without inventing a new parser contract.

Do not weaken the parser to ignore every suffix. That could make this one line pass while accepting malformed input that should remain rejected. It would also change the question being tested. You would no longer be checking whether the original token satisfied the existing language; you would be designing a different language. Such a change needs a separate requirement and its own acceptance cases.

Do not replace the failed token with zero simply to remove the error. Zero is a numeric reading with its own meaning. It is not a neutral substitute for an unknown value. If a scenario intends missing input, use the documented missing representation. If it intends a particular temperature, supply that temperature correctly. A plausible invented reading can hide the very failure the program is meant to expose.

After the corrected copy runs, execute the original invalid fixture again. It should still be rejected. This paired result matters: the intended numeric event is accepted while malformed syntax remains outside the contract. Save both observations. A lone passing screenshot would not tell a reviewer whether the parser had been weakened or whether the original reproducer was ever exercised.

Now update the diagnosis using the evidence. The supported cause is a token outside the documented fixture grammar. The correction changes that token, and the unchanged original still reproduces rejection. This conclusion is narrower and more useful than saying the sensor problem is fixed. No sensor was read, no wiring was inspected, and no calibration or physical timing was measured in this run.

If the corrected file still fails, preserve that contradiction. Check whether the command used the copied filename, whether the working directory is correct, and whether the intended executable was rebuilt. Do not repeat the same edit elsewhere and call it a new experiment. The test may reveal that your first explanation was incomplete, which is valuable information when it is recorded accurately.

The chapter also includes a stale-policy fault. That failure occurs after valid input has reached the policy, and it can produce perfectly valid JSON with the wrong meaning. Its useful observations include timestamp, state, error, and temperature availability. Changing only the printed label could hide the symptom while leaving recovery state incorrect. The same investigation method applies, but the discriminating test must match that different failure layer.

Write a concise report from the raw evidence. Include the starting state, original reproducer, competing explanations, chosen test, actual result, bounded correction, regression observation, and limits. An assistant can organize these pieces, but review each sentence against the receipts. Replace unsupported claims of proof with the precise behavior you observed, and keep an unexecuted test labeled as a proposal.

Your exercise is complete when another reader can reproduce the failure, understand why the chosen test distinguishes its cause, and assess the correction without recovering your conversation. Preserve the original invalid input and the corrected copy. In the module challenge, you will apply this method independently to another seeded fixture failure and defend a small fix with a complete evidence handoff.