We have a capstone contract that can be checked. Now we will implement it in small slices and review the resulting changes. Start from your preserved checkpoint-eight baseline and the plan from the previous lesson. The final checkpoint-nine solution is available for reference, but your task is to understand and verify the change rather than simply copy a finished directory.

Begin with shared policy. Add the alert state, default threshold, and hysteresis constant where the policy owns configuration. Preserve the existing missing, nonfinite, and stale checks before accepting a sample. Preserve the two-sample recovery gate. New functionality should fit around those established rules instead of replacing them with one broad temperature comparison.

Read the three state paths separately. In fault, a first fresh valid sample stays in fault with a recovering error, while the second permits classification against the entry threshold. In alert, compare against the lower clearing boundary. In normal, compare against the entry threshold. The ordering carries the history that makes hysteresis meaningful. Flattening the branches can accidentally erase that behavior.

Implement the demonstrated equality case first. Establish normal with two fresh readings below the threshold, then supply exactly twenty-eight degrees. The expected state is alert. Add a companion case just below the boundary. Review the source and assertion together, but derive the expected outcome from the written requirement rather than copying the implementation's operator.

Now complete clearing equality and band retention. From alert, twenty-seven clears; twenty-seven point five retains alert. From normal, twenty-seven point five retains normal. Include boundary jitter and recovery after a fault. The recovered state should use the fresh entry threshold, not the alert state remembered before the fault. Keep injected timestamps ordered so the test asks the intended question.

Add a validated threshold setter. It must reject nonfinite and out-of-range values before changing stored configuration. A valid value re-evaluates a current non-faulted reading, but it cannot clear fault or count toward recovery. Inspect the callers to ensure time is polled before the setting uses a cached reading. Local correctness is not enough if integration ignores freshness.

Next, build the command collector. It stores a bounded line until line feed. The optional final carriage return belongs to the allowed byte count. Once the line exceeds the limit, drain input to the next line feed and report too long. Do not reinterpret the remaining tail as a second command. Reset the collector at the boundary so the next valid line can be processed.

Validate the entire number grammar before conversion. The command threshold twenty-eight followed by junk must be rejected, even if a standard conversion routine returns twenty-eight from its prefix. Check the optional sign, required integer digits, optional fraction, and end of token. If a decimal point is present, at least one fractional digit must follow it. Reject extra whitespace, exponents, nonfinite words, and trailing characters according to the contract.

Validate the wider numeric value before narrowing to float. A value just above the maximum must not round into the permitted range during conversion. This is a useful example of why parsing and policy checks need to agree. Test range endpoints and values outside them, and verify that every rejected command leaves the previous threshold intact.

Handle partial lines deliberately. At host end-of-input, a partial command returns truncated and changes nothing. Firmware waits for line feed without blocking its loop. The project does not invent a serial timeout or a persistence feature. Keep work per loop bounded so command processing does not consume the whole iteration before acquisition can be considered.

Integrate the parser into both build paths. The host and firmware must compile the same shared policy, parser, and output files. Update the maintained source lists and adapters rather than creating a test-only parser. Add alert formatting and threshold configuration output while preserving the synthetic label. Unavailable temperatures remain JSON null, and recovering values retain their distinct current-but-fault meaning.

Run appropriate checks after each slice. A small policy change needs its relevant assertions; adapter integration needs replay and firmware compilation. If a command fails, preserve the result and investigate the demonstrated cause. Do not continue stacking new features on a baseline whose state you no longer understand. The final integrated run comes after the last relevant change.

Review the diff with the bounded firmware-review procedure. Findings should name a trigger, consequence, and supporting evidence. Reject unrelated redesign that makes the capstone harder to inspect. A clean slice does not need invented defects, but missing verification should remain visible. Keep review and repair as distinct actions when the task requested inspection only.

Review output-buffer handling during integration. The formatter reports whether a complete record fits; callers must not present an incomplete JSON fragment as a valid record. Existing small-buffer tests provide a useful regression case. Keep the stable field meanings and unavailable-value representation intact while adding the new alert and configuration output, so consumers can distinguish data state from formatting failure.

Your exercise is to complete the four planned slices with coherent commits or reviewed diffs. Submit the requirement-to-change map, source, tests, and actual receipts. Demonstrate inclusive entry first, then finish clearing, parser, integration, and regression checks. If a generated patch expands beyond the request, preserve useful work and narrow the change before proceeding.

Pause here to implement and inspect your own version. Use the reference solution to answer a specific uncertainty after attempting the task, and compare behavior rather than formatting. If your implementation takes a different clear approach while meeting the same contract and evidence requirements, that can be a valid result. Explain the choices so a reviewer can assess them.

The outcome of this lesson is a reviewable implementation, not yet a finished release. In the next lesson, we will exercise the complete behavior, prove meaningful defect rejection, and reproduce the candidate from a fresh checkout. Keeping that boundary visible prevents a convincing patch from being mistaken for verified delivery before the required evidence exists.