M08-L01 — Plan the capstone feature

Recording transcript

The capstone adds configurable alerts to the normal and fault monitor you already understand. In this lesson, we will turn that feature into a plan with observable checks. Start from checkpoint eight and preserve its working baseline. Checkpoint nine is the final reference solution, but the goal is to carry the change through your own requirements, implementation, review, and evidence.

Begin by naming what stays important. Missing, nonfinite, and stale input must still enter fault. Recovery still requires two consecutive fresh valid samples. An invalid sample or a stale gap resets that count. Startup follows the same rule, so the first valid reading can be current while the state remains fault during recovery. New alert logic must not bypass this existing contract.

The default threshold is twenty-eight degrees Celsius. From normal, a valid reading at or above the threshold enters alert. From alert, a reading at or below one degree beneath the threshold clears to normal. Between those boundaries, retain the prior non-fault state. These are teaching values, not sensor calibration limits or a safety-control specification.

Write an example with twenty-seven point five degrees. Starting from normal, that value remains normal because it is below the entry threshold. Starting from alert, the same value remains alert because it is above the clearing boundary. This history dependence is hysteresis. A test that supplies the value without identifying the starting state cannot determine the expected answer.

Add equality cases explicitly. At twenty-eight, normal enters alert. At twenty-seven, alert clears to normal. Also include jitter near the entry boundary and both directions through the band. Write the expected sequence before reading the implementation's comparisons. The requirement must provide the independent reason for the expectation.

Now consider recovery from fault. After the two required fresh valid samples, classify the latest temperature using the entry threshold. Do not restore an old alert simply because the monitor was alert before the fault. The new reading and current configuration determine the recovered state. Include an interrupted-recovery sequence so the implementation cannot accidentally count invalid or stale input as progress.

The command interface needs an equally explicit contract. The command begins with the lowercase word threshold, followed by one space and a decimal number, and ends with line feed. An optional final carriage return supports the usual Windows line ending. The maximum line length is sixty-four bytes before line feed, including that optional carriage return. These details define the collector's bounds.

Accept threshold values from zero through fifty degrees inclusive. The setting is stored in RAM only. Reset or a new process restores the default threshold and fault with missing input. Do not promise persistence that the project does not implement. A configuration acknowledgement says the command was accepted; it does not establish that a valid sensor sample exists.

Define the number grammar before choosing a conversion helper. The reference accepts an optional sign, integer digits, and an optional decimal fraction with digits after the point. It rejects exponents, extra whitespace, nonfinite words, and trailing text. A command containing twenty-eight followed by junk is malformed even if a library can extract a numeric prefix from it.

Invalid commands must leave the prior configuration unchanged. Cover malformed text, out-of-range values, oversized lines, and a partial line at host end-of-input. An oversized collector must drain to the line boundary so the remaining bytes cannot become an unintended second command. Repeated valid commands should still work after a rejected line.

A valid threshold update immediately re-evaluates a current non-faulted reading against the new entry threshold. It cannot clear fault or advance recovery. Poll the injected time before applying the setting so an old cached value is not treated as current. This connection between command handling and freshness belongs in the plan because separate locally correct functions can still interact incorrectly.

Split the implementation into four slices. First add alert state and validated configuration to shared policy. Second add the bounded complete-line parser. Third integrate the parser and output into the host and firmware adapters. Fourth complete verification, documentation, and release reproduction. Keep each slice small enough to inspect before moving to the next.

Preserve shared source between host and firmware. The policy, parser, and output implementation should have one maintained copy used by both build paths. A host-only substitute would weaken the connection between tests and the embedded source. At the same time, host checks still do not establish electrical behavior or physical device timing, so keep those evidence limits in the plan.

Keep fixture grammar separate from command grammar. The replay file has timestamp, event, and value fields, while the command collector has its own byte limit and line boundary. A valid command embedded in a malformed fixture can still be rejected by the fixture parser before policy sees it. Your test plan should identify which layer each invalid case is intended to exercise.

Run the existing checkpoint-eight tests and replay before editing. Record their actual results and remember that this stage has no alert or command behavior. The same normal fixture will have different state expectations after the capstone. A result needs its checkpoint identity so an earlier normal-state sequence is not accidentally judged against the later solution.

Your exercise is to write the brief, the requirement-to-check table, and the four-slice plan. Include starting state, equality, faults, recovery, parser grammar and bounds, reset, and evidence limits. Identify which command or review will check each slice. Do not mark planned behavior implemented merely because the acceptance table is complete.

Pause here to finish the plan before beginning code. A good plan is not a promise that no problem will occur. It gives you a way to recognize the important problems and keep corrections bounded. In the next lesson, we will implement one requirement at a time and inspect whether each source change preserves the contract you have now made explicit.

Download transcript