G. Versions and checkpoint map
The project reference version is 1.0.0. A content tag, installed tool version, and accepted release status are separate facts. Use the final release manifest for distributed file hashes and the verification report for actual platform results. This table records the edition's source and pilot configuration; it is not a promise that every future product update behaves identically.
| Component | Recorded value | Interpretation |
|---|---|---|
| Primary learner OS | Windows 11 ARM64 | Standard-user demonstration path |
| Editor | VS Code 1.137.0 ARM64 | Recorded installed editor |
| Codex extension | 26.908.40401 | Installed interface; actual task evidence is separate |
| Bounded CLI pilot | Codex 0.154.0-alpha.6.2 | CLI correction evidence does not imply an IDE capture |
| Arduino CLI | 1.5.1 | Portable Windows x86_64 binary used in ARM guest |
| ESP32 platform | esp32:esp32@3.3.11 | Cross-compiler and board platform dependency |
| Native Windows compiler | LLVM-MinGW 20260908, Clang 23.1.1, aarch64 UCRT | Host replay/test compiler and runtime distribution |
| C++ mode | C++17 | Shared host policy/parser/output compilation |
| Separate macOS host path | Apple Clang 21.0.0; Python 3.13.12 | Distinct software evidence path |
| Required physical sensor libraries | None | Required firmware uses synthetic acquisition |
The dependency manifest contains archive URLs and hashes, architecture, versions, and the complete FQBN. Do not abbreviate the target to a family name when reproducing a build. The selected options include CDC on boot, enabled QSPI PSRAM, 4 MB flash, 240 MHz CPU, QIO flash mode, and TinyUF2 no-OTA partition scheme. Those options belong to the documented example target, not every ESP32-S3 board.
Use the right stage
| Stage | Chapters / course | Contents and applicable check |
|---|---|---|
| CP00 | CH01–04 / M01 and setup inspection | Original excerpts/log; annotate; no build required |
| CP01 | CH05–07 / M02–03 | Fixed synthetic host sample and minimal firmware; replay/build |
| CP02 | CH08–09 / M04 | Project/hardware records; content/link checks plus baseline |
| CP03 | CH10 / M05 | Agent instructions; fresh-session replay/build behavior |
| CP04 | CH11–12 / M05–06 | Constraints skill/interface plan; source and activation tests |
| CP05 | CH13 / M06 | Normal/fault shared policy and synthetic adapter; replay/build |
| CP06 | CH14 / M06 | Reproducer and fault exercises; diagnosis/replay/build |
| CP07 | CH15 / M07 | Basic normal/fault assertions; test/replay/build |
| CP08 | CH16 / M07 | Review skill and handoff; fresh-session behavior |
| CP09 | CH17–18 / M08 | Threshold/hysteresis/commands and complete verification |
Each ZIP has a sensor-monitor top folder and a checkpoint note. Extract to a new exercise folder. A ZIP contains files, not a Git graph. The separate sensor-monitor-history.bundle provides generic manufactured history, content tags, conflict branches, and isolated fault tags. Preserve the release identifier with the bundle you use.
The current project README defines the exact available commands. Early CP01 replay prints a fixed synthetic JSON line; a fixture file present there is reserved for later use and does not mean the early program parses it. CP07 introduces assertions. CP09 introduces configurable threshold, hysteresis, and command behavior. A later source file appearing in an early exercise is a checkpoint mismatch to investigate.
Fault and recovery map
FAULT-fixture belongs to CP06 and contains a malformed numeric token. FAULT-stale derives from the basic test stage and disables expiration. FAULT-hysteresis and FAULT-command derive from the final project and alter clear equality and complete-token validation respectively. Their exact start and recovery instructions live in the checkpoint guide.
Chapter 7 uses the prepared later FAULT-hysteresis only to teach reverting an isolated commit with supplied tests. That does not advance the learner's main project to capstone completion. Keep the recovery clone separate and resume the intended earlier checkpoint afterward.
Recheck unstable account eligibility, download links, extension discovery, and installation screens when producing a new edition. Preserve old results with their versions rather than relabel them as fresh evidence. A maintained workflow has a dated supported path and a small set of regression checks, not an unqualified promise of permanent compatibility.