We are ready to run a small firmware behavior and make one reviewable reporting change. Open checkpoint five in a new exercise folder. This version has synthetic input and normal or fault policy. It does not yet have configurable alerts, hysteresis, or threshold commands. A high temperature can remain normal at this stage because those later capstone requirements are deliberately absent.

Begin with the baseline, before editing source. From the project root in PowerShell, run the replay command with the normal fixture. Save the actual exit value immediately after the command. The supplied wrapper compiles the host executable and then runs it. If compilation fails or the executable cannot start, diagnose that condition before interpreting a policy result that has not actually been produced.

The normal fixture contains eight events. The expected states begin fault, then normal for the following valid readings. An intentionally nonfinite input later produces fault, and two fresh valid readings complete recovery. This is a successful replay when the process exits zero and the expected sequence occurs. A fault state can be correct application behavior; it does not automatically mean the runner failed.

Read the source path with me. The host adapter interprets fixture rows and supplies timestamps and readings. The shared policy decides whether input is current and whether recovery is complete. The output formatter writes a JSON object for the resulting snapshot. These policy and output source files live inside the sketch directory and are also compiled directly into the host executable.

The Arduino sketch provides a different surrounding environment. It uses the platform clock, generates a short synthetic sequence, and sends formatted output through the serial interface. It does not read a physical BME280. Compiling that sketch is useful evidence for the selected target, but it does not turn replay into an electrical simulation or establish that a board has been uploaded successfully.

Attempt the baseline firmware build with the recorded target and retain its actual result. The final release has a separate verified Windows build, but another checkpoint or an edited source needs its own receipt. Keep the native result and firmware result distinct. A successful host run cannot substitute for a cross-build, and neither result establishes sensor accuracy, wiring, USB operation, or measured device timing.

Now choose one reporting requirement. The snapshot already contains a current-data flag, but the sample JSON does not expose that flag directly. We will add a Boolean field named current. The request is limited to the status formatter and its reporting description. Acquisition, policy, timing, dependencies, and the board target should remain unchanged. This gives us a clear basis for reviewing an assistant's patch.

Notice why the field has a useful meaning. The policy starts in fault with missing input. A first valid sample is fresh, but the two-sample recovery rule keeps the state in fault. That record should therefore have current true and state fault. Availability of data and completion of recovery are different properties. Deriving the new field from whether the state is normal would lose that distinction.

Inspect the complete bounded formatting call. Add a placeholder for the current field before the closing brace, then add the matching argument based on the existing snapshot flag. The strings true and false are used as unquoted JSON literals. If the output places quotation marks around them, the consumer receives strings instead of Boolean values. Keep the existing buffer-completion check after the change.

Review the diff before running it. The new placeholder needs its corresponding argument in the right position. The policy does not need a new global variable, and the synthetic sequence does not need new values to accommodate this report. If the assistant also changes recovery or adds a driver, return to the bounded task. Those edits make the result harder to assess and are unnecessary here.

Run the stale-recovery fixture after rebuilding. Its sample at timestamp one thousand is still current at four thousand because the age is exactly three thousand milliseconds. At four thousand and one, it becomes stale. A valid sample at five thousand starts recovery, a missing event at six thousand interrupts it, and valid samples at seven and eight thousand complete a fresh recovery sequence.

The expected current flags are true, true, true, false, true, false, true, true. Look particularly at five and seven thousand. Those records remain in fault while containing fresh input. They distinguish the correct snapshot mapping from the tempting state-based shortcut. The state and error sequence should be the same as before the reporting change, because the policy was not part of the task.

Use PowerShell's JSON parser to inspect the output rather than relying only on visual alignment. Preserve the replay exit before passing lines through the parser. Convert each line into a record, select sample records, and display timestamp, state, error, and current. A parsing failure matters. Confirm that current is a Boolean value, not merely text that looks like the word true or false.

Adding a field changes the local output contract. Update the exercise documentation so a consumer knows what to expect. A strict parser may reject unknown fields, so do not promise compatibility without checking it. This lesson uses a disposable extension; the next published checkpoint remains its own starting state. You are not required to carry this extra field into every later exercise or alter the capstone acceptance tests.

Cross-compile the edited shared source using the unchanged manifest target and save the actual result. If a required tool is unavailable, identify that missing dependency and leave the check open. Do not replace it with an old binary or an agent assurance. The instructor host check establishes this reporting behavior for synthetic fixtures; a learner run and a firmware build are separate receipts.

Finish by inspecting the final diff and writing a brief evidence note. Name the starting checkpoint, changed files, fixtures, command exits, and any remaining limitation. A successful solution exposes the existing flag accurately while leaving the previous behavior intact. We now have a small change that can be explained from requirement to source to output. The next lesson uses the same discipline when the starting output reveals a failure.