---
id: M08-L03
title: "Verify and package the release candidate"
module: M08
chapters: "17"
checkpoint: "CP09"
---

# M08-L03 — Verify and package the release candidate

Produce a private candidate that another checkout can reproduce. Start with the reviewed capstone implementation. Run host assertions, normal/command/stale/rollover replay, and firmware compilation using the maintained wrappers.

```powershell
.\scripts\test.cmd
.\scripts\replay.cmd fixtures/normal.csv
.\scripts\replay.cmd fixtures/commands.csv
.\scripts\replay.cmd fixtures/stale-recovery.csv
.\scripts\replay.cmd fixtures/rollover.csv
.\scripts\build-firmware.cmd
```

The final normal fixture's expected states are FAULT, NORMAL, ALERT, ALERT, NORMAL, FAULT, FAULT, NORMAL. Its recovering entries retain fresh values but remain FAULT. Save actual output separately. A valid replay with intentional invalid sensor input can exit 0; a malformed fixture exits 2.

Use isolated FAULT-hysteresis and FAULT-command copies to show meaningful behavioral rejection. The faulty versions must compile before their failed tests establish the intended lesson. Keep a good solution that still passes. A large assertion count cannot replace coverage of the important requirements.

Update requirements, formats, README, decisions, evidence, release notes, and handoff. Record source identity, exact dependency/target inputs, actual checks, and limitations. Exclude private authoring materials and unrelated history from the package.

Create a fresh second checkout from the intended release source and follow the written setup. Execute the same required checks there. A clean working tree is not proof of reproduction; untracked dependencies can remain hidden until commands actually run in a second copy.

A private candidate satisfies the exercise. Public publication and physical upload are separate decisions. Cross-build, host tests, and synthetic replay do not establish sensor accuracy, wiring, serial behavior, or physical timing.

## Reading the recorded demonstration

The verification uses `git -C <project-path>` to select the capstone repository. That option changes the directory for the Git command; it does not change the shell prompt's working directory. Use the recorded command's target path and resulting commit identity when tracing the evidence.

## 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-03, SS17-04, SS17-05. Attempt the [exercise](exercise.md), preserve actual results, then use the separate instructor answer key. 

Source resources: [Chapter 17](../../../../book/chapters/ch17/chapter.md); [checkpoint and recovery map](../../../../examples/sensor-monitor/docs/checkpoints.md). Use the README and requirements inside your named checkpoint; the repository's final CP09 files include features absent from earlier stages. The [capstone rubric](../capstone-rubric.md) defines scoring and mandatory evidence gates.