---
id: M06-L03
title: Add input handling and reporting
module: M06
chapters: "13"
checkpoint: CP05
---

# M06-L03 — Add input handling and reporting

Run synthetic samples through shared normal/fault policy, then make one bounded reporting change. Start with CP05 in a fresh folder. Alerts, hysteresis, and threshold commands are not implemented at this stage; they belong to the capstone.

From the project root in PowerShell, establish a baseline:

```powershell
.\scripts\replay.cmd fixtures/normal.csv
$baselineExit = $LASTEXITCODE
.\scripts\build-firmware.cmd
$buildExit = $LASTEXITCODE
```

The normal fixture's expected CP05 states are FAULT, NORMAL, NORMAL, NORMAL, NORMAL, FAULT, FAULT, NORMAL. A successful replay exits zero even when the intentionally nonfinite input produces FAULT. Preserve the actual firmware result separately; the verified final CP09 Windows cross-build does not substitute for this CP05 stage or your reporting edit.

Trace `host/replay.cpp` into `monitor_policy.cpp` and `output_format.cpp` under the sketch directory. The adapter supplies timestamped values, the policy decides meaning, and the formatter renders JSON. The native and firmware builds use the same shared source files. The sketch itself supplies synthetic values and has no physical sensor driver.

The policy starts FAULT/missing and needs two consecutive valid readings to recover. A recovering sample can contain current numeric data while remaining in FAULT. Missing, nonfinite, or stale input has no current temperature. This distinction makes a useful reporting exercise: expose the existing `Snapshot.current` flag as a JSON Boolean without changing policy.

Ask for a change only to the status formatter and its reporting description. Add `,"current":%s` to the JSON format and the matching `v.current ? "true" : "false"` argument. Review the complete formatting call and retain its bounds/completion check. Boolean true/false values are unquoted JSON literals; quoted words would be strings.

Run the stale-recovery fixture after the change. At 4000, the reading is still current; at 4001 it is stale. At 5000 and 7000, recovery is incomplete but the new sample is current. Mapping the field to `state != FAULT` would therefore be wrong.

```powershell
$lines = .\scripts\replay.cmd fixtures/stale-recovery.csv
$runExit = $LASTEXITCODE
if ($runExit -ne 0) { throw "Replay failed with exit $runExit; inspect its output before parsing records." }
$records = $lines | ForEach-Object { $_ | ConvertFrom-Json }
$records | Where-Object { $_.type -eq 'sample' } |
  Format-Table uptime_ms, state, error, current
```

Expected current flags are true, true, true, false, true, false, true, true. Check that JSON parsing succeeds and the field is a Boolean. The existing state/error sequence must remain unchanged. Cross-compile the shared-source edit with the same target and retain the actual receipt or precise open dependency.

Inspect the final diff for scope. A changed scheduler, recovery counter, board target, or dependency is unrelated to exposing an existing field. Update the local exercise's output contract because adding a field can affect strict consumers. Subsequent lessons start from their own checkpoints; this optional reporting extension is not silently required by CP06 or CP09.

## Resources and completion

Use Chapter 13, CP05 README, shared formatter/policy, and the normal/stale fixtures. Figure references: SS13-01–05. Complete [the exercise](exercise.md), then use [the key](answer-key.md). Host replay is synthetic software evidence; compilation and optional physical validation remain distinct.