A release candidate is useful when another checkout can reproduce its result. In this lesson, we will verify the complete capstone, package its evidence, and test the written setup in a fresh copy. Start with your reviewed implementation from the previous lesson. The target is a complete private candidate; public publication and physical upload are not required for the core course.

Begin with source identity. Record the current commit or hashes and inspect the working tree. Confirm that the requirements, tests, fixtures, and build inputs describe the same candidate. A result from an earlier source can remain useful history, but it does not automatically certify the current edit. The evidence must name what was actually checked.

Run the full host-test wrapper from the project root. Read the process result and relevant assertions. The suite needs entry equality, clearing equality, both hysteresis directions, jitter, invalid and stale input, interrupted recovery, rollover, command validation, bounds, and reset behavior. A large assertion count cannot substitute for those specific requirements.

Now run the normal fixture with the replay wrapper. In the final capstone, the expected state sequence begins fault, normal, alert, alert, normal, fault, fault, normal. The initial and later recovering samples are fresh but remain fault until recovery completes. Save the actual output from your run. The expected sequence in the lesson is a criterion, not an execution record.

Run the commands fixture next. It exercises accepted settings, malformed text, an out-of-range value, truncation, and reset. Inspect both command acknowledgements and subsequent state. A valid threshold command changes configuration, but it cannot clear fault or supply a missing sample. Rejected input must leave the previous setting intact. Reset returns to the documented defaults.

Continue with stale-recovery and rollover fixtures. The injected times test software logic under controlled conditions. They do not measure real microcontroller scheduling or USB latency. A stale gap between otherwise valid samples must reset recovery, and age exactly three thousand milliseconds remains current. Preserve the source and fixture identities with the result so a reviewer can reproduce the sequence.

Interpret process results carefully. A valid synthetic fixture can intentionally produce fault and still complete with exit zero. A malformed fixture is rejected with a diagnostic and exit two. Failed native assertions use exit one. These are different meanings. Do not edit an intentionally invalid sample out of a valid fixture merely to make every displayed state normal.

Run the firmware cross-build after the reviewed shared-source changes. The maintained wrapper preserves the selected target configuration from the dependency record. Save the actual command result and build evidence. This supports compilation for those inputs. It does not establish that a board was connected, that an upload worked, or that a sensor measured anything.

Next, challenge the suite with the isolated hysteresis and command fault copies. The hysteresis defect misses inclusive clearing at twenty-seven degrees. The command defect accepts trailing numeric text that should be malformed. Both wrong versions must compile before their failed assertions establish useful behavioral rejection. A syntax error would answer a different question.

Keep the good solution separate and show that it still passes. Preserve the bad source diff, the relevant failed check, and the good result. A final passing screen alone does not show that the tests can reject the meaningful defects. The point is to connect requirements, implementation changes, and observations in a record another engineer can inspect.

Update the candidate documentation. The README should explain setup and commands. Requirements and formats should match the implemented behavior. Decisions should explain material choices such as RAM-only settings. The evidence summary should link to actual receipts, and the handoff should name the current source and remaining work. Release notes should describe the final behavior without exaggerating its validation.

Review the package contents for its intended audience. Include source, permitted fixtures, dependency information, setup, and relevant evidence. Keep private authoring credentials, unrelated history, service administration, and personal captures outside the learner package. A useful private release is complete and reviewable; it does not need public visibility to demonstrate the engineering outcome.

Create a fresh second checkout from the intended release source. Follow the written setup without silently supplying missing files from the original folder. Run the required tests, replay, and firmware build there. This is the check that exposes dependence on untracked files or incidental environment state. A clean working tree without actual execution is not reproduction.

The reference also supplies independent JSON replay checks in its Python host appendix. When you use that route, record the actual platform and commands separately from the Windows wrapper receipts. Parsing the emitted JSON and comparing event sequences adds another perspective beyond C++ assertions. It still evaluates software output, so it does not expand the result into a physical validation claim.

Record the second-copy result separately. Name its source identity, setup route, commands, outcomes, and limitations. If a dependency is missing, improve the setup or resolve the documented environment and repeat the affected check. Preserve failures that explain the repair. Do not label the original checkout's passing result as evidence that the second copy ran successfully.

Your exercise is to submit the candidate, requirement-to-test map, actual software receipts, meaningful defect-rejection records, fresh-checkout result, and current handoff. Apply the capstone rubric. The suggested score target is eighty out of one hundred, but mandatory behavior, reproducible build, host and replay checks, and honest evidence labels must all be satisfied.

Pause here to complete the verification and packaging. When you finish, state the strongest claim the evidence supports: this recorded software candidate met its specified checks and reproduced through the written path, if those results actually passed. Physical behavior remains a separate optional task. A precise private candidate is the intended core outcome, and its value comes from the work another person can inspect and repeat.