M08-L02 — Implement and review the capstone
Implement the feature in small slices and explain the resulting diff. Begin from the reviewed CP08 baseline and the plan from M08-L01. Use CP09 as the instructor reference after your attempt or for a specific diagnosed uncertainty.
Add ALERT and threshold configuration to shared policy. Preserve validity checks and the two-sample recovery gate before alert classification. From NORMAL use inclusive entry; from ALERT use inclusive clearing one degree below the threshold. Recovery classifies fresh input rather than retaining old state.
Add a validated setter that leaves the prior threshold intact after nonfinite or out-of-range values. Apply accepted changes only to current non-faulted state. The command collector must be bounded, drain oversized input to LF, and reset for the next command. Check the complete decimal grammar before conversion; a numeric prefix from 28junk is not acceptable.
Validate the wider converted number before narrowing to float so a slightly out-of-range value cannot round into range. Handle CRLF, repeated commands, and EOF truncation. Firmware waits for LF without blocking its loop; host command mode ends at EOF. Do not invent a timeout or persistence feature.
Integrate the parser into the shared build lists, host adapter, and firmware loop. Keep work per loop bounded. Add threshold startup/configuration output and ALERT formatting while preserving synthetic labels and null unavailable temperature. A recovering sample can have a current numeric value while remaining FAULT.
Run appropriate checks after each slice. Review both source and test diffs; expected values must come from requirements. Reject unrelated redesign. Record failed attempts and their causes rather than replacing them with a final successful story.
Reading the recorded demonstration
Some punctuation in the recorded terminal output renders incorrectly, and a few long source lines extend beyond the editor viewport. Use the supplied UTF-8 source files to read those lines in full. The displayed test results and policy decisions remain the evidence being discussed; a terminal display artifact does not establish a behavioral failure.
Resources and completion
Read Chapter 17 and the matching Sensor Monitor checkpoint README, requirements, and evidence notes. Project paths are relative to its root. Figures: SS17-02. Attempt the exercise, preserve actual results, then use the separate instructor answer key.
Source resources: Chapter 17; checkpoint and recovery map. Use the README and requirements inside your named checkpoint; the repository's final CP09 files include features absent from earlier stages. The capstone rubric defines scoring and mandatory evidence gates.
Recording transcript
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.
Download transcript
