[clhodapp]

A configuration's manifest now carries history, as the root lib's manifest already does. design section 5 describes the history as the flat list of events on the way to a manifest's value, derived from the tree. topside's history and modules verbs read it.

• The history of a childless manifest is the history of its parent, then the events the evaluation records. An integration's evaluate returns those as events, each with operation, key and origin. caisson-core stamps each event with the manifest's name path, its type, and its index within its operation.
• The history of a full manifest is the history of the childless manifest, then what each configuration beneath adds after the history it began with. A system node adds what its evaluations add. So a child's history always begins with its parent's childless history, the prefix rule of section 5.
• The name path is the { type, name } of each manifest beneath the top, which is the address under children of the top's manifest. The top, including a top evaluated per system, has the empty path.
• An integration's record may not name history.

Test. lifecycleEveryConfigurationHasAHistory builds a structural top, with a per-system machine inside it and a configuration inside that, each recording declaration events through the stub integration. It checks that each childless and full history follows the prefix rule, with the right name paths, types and indices. The hermetic suite passes, 128 tests, and so does nix flake check.

nix-caisson/caisson#126 fills the events in from what each evaluator receives.

🤖 Generated with Claude Code