Skip to content
nautilus nautilus nautilus

Verified: Program history

Each claim the Program history page makes, with the tests that prove it in the last green CI run: 3 of 16 verified, 1 with no test yet. The claims live in docs/claims/program-history.yaml.

Last green CI run 16 Oct 2026, 14:48 UTC on c7618d3 · all runtime claims

PH-001 partly verified

GET /api/program/history serves every commit that touched the project (author, date, subject and the full diff) from the controller itself, with the built sha the deployed baseline corresponds to.

where the docs say so · The commit date is asserted nowhere, and no test commits outside the project's subtree to show only commits that touched the project are served. Author, subject, diff, sha and built are asserted (capture in TestCapture, serving in TestProgramHistoryEndpoint).

PH-002 partly verified

The response's programs list is the live layer per task (task, pou, hash, dirty), so one read shows whether online edits have drifted from what CI shipped.

where the docs say so · Only the presence and POU of the programs layer is asserted, not the dirty flag after an edit.

  • pass TestProgramHistoryEndpoint in server

PH-003 partly verified

A build from an uncommitted tree is flagged builtDirty: true rather than passed off as clean lineage.

where the docs say so · Asserts the captured BuiltDirty flag; the JSON field name on the endpoint is not asserted.

PH-004 partly verified

naut build snapshots the project's git history into the emitted binary, and the deployed controller serves it with no git binary, no .git directory and no network.

where the docs say so · The distroless / no-git environment is not reproduced; the round trip through the archive is.

  • pass TestBuildEmbedsHistory in cmd/naut

PH-005 no test yet

naut run in a checkout captures history live from the repo on first request.

where the docs say so · Gap. Capture is tested directly, but the lazy capture on first request in naut run is not.

PH-006 verified

The endpoint never fails for lack of provenance: outside a repo it serves an empty history.

where the docs say so

PH-007 verified

Snapshots are stored git-style, so files dedupe on git's blob ids (an unchanged file costs one blob across commits).

where the docs say so

PH-008 verified

POST /api/program/activate {sha} rebuilds every task's program source as it was at that commit, with libraries composed ahead as boot composes them, and warm-swaps each one.

where the docs say so · TestActivateEveryTask swaps both tasks of a two-task controller warm. TestBuiltControllerActivatesWarm activates an older commit on a real built controller over HTTP: both tasks, each using a library FUNCTION_BLOCK, run that commit and keep their timers and FB state.

  • pass TestActivate in server
  • pass TestSnapshotComposesSources in internal/vcs
  • pass TestActivateImplicitTags in server
  • pass TestActivateEveryTask in server
  • pass TestBuiltControllerActivatesWarm in cmd/naut

PH-009 partly verified

Activation is gated like any online edit: it needs online-edits: true and the write token if one is set.

where the docs say so · Refusal with online edits off is asserted; the token requirement is not.

  • pass TestActivateRejections in server

PH-010 partly verified

Retained state survives an activation (migrated by name and type) and what cannot carry over is reported per task in resets.

where the docs say so · The swap mechanism is tested; the activate endpoint's per-task resets report is not asserted.

  • pass TestSwapWarmCarriesRetainedState in runtime

PH-011 partly verified

Activation is all or nothing: every source compiles before any swap, so a controller is never left running half of two revisions, and a commit that no longer compiles is rejected whole.

where the docs say so · Asserted with a single task; the multi-task never-half-swapped case is not.

  • pass TestActivateRejections in server

PH-012 partly verified

Each program keeps its one-step rollback after an activation, and activating built returns to exactly what CI shipped.

where the docs say so · Rollback is asserted; activating the built sha as the way back to the shipped baseline is not.

PH-013 partly verified

An activation follows the online-edit restart rule: without a retain store a restart boots the binary's embedded programs; with one, a restart of the same build keeps the activated programs and a deploy of a different build replaces them.

where the docs say so · The tests restart after a warm swap (SwapWarm), the operation an activation performs on each task's program; no test restarts after a POST /api/program/activate itself.

  • pass TestOnlineEditDoesNotSurviveARestart in internal/project
  • pass TestOnlineEditSurvivesARestartOfTheSameBuild in runtime
  • pass TestNewDeployReplacesARetainedOnlineEdit in runtime

PH-014 partly verified

After an activation the history reports active: <sha>, and a hand edit or rollback clears that claim.

where the docs say so · Clearing on rollback is asserted; clearing on a hand edit is not.

PH-015 partly verified

A commit that changed topology (added a task, renamed one) is refused with a 409 naming the difference.

where the docs say so · The 409 for an added and for a missing task is asserted, and the added case's error says "topology"; that the error names the differing task is not asserted.

  • pass TestActivateRejections in server

PH-016 partly verified

Activation covers logic only: the cold plane (tasks, tags, drivers, retain and redundancy wiring) stays as the running manifest booted it.

where the docs say so · Only the topology refusal is asserted; a tag or driver change in the old commit being ignored is not.

  • pass TestActivateRejections in server