Skip to main content

Module invariants

Module invariants 

Source
Expand description

The invariants a seeded file still carries.

A seeded file is the target’s to tune — nothing here rewrites one — but the narrow part the invariants own is judged: a target may choose its platforms, its installers, and its install path; it may not choose to ship unattested. The judgment reads the effective configuration, never the text: a commented key, a false value, or an unpaired phase must fail, and whitespace or key order must not matter. The table is keyed by (technology, forge, destination) — the kind table is destination-keyed, and a second pair sharing a destination would otherwise silently inherit the wrong rule.

A second, pair-keyed table judges what a landed file generates and the payload ships no copy of: no digest records such a file, so nothing else sees it drift away from the configuration it was generated from. That judgment reads the generated text, because the generator is not available to re-run and the text is what the forge executes. It reads the grammar the generator writes and reports what it cannot resolve; a workflow hand-authored in some further YAML presentation is beyond a text reader, and the generator’s own check stays the whole-file proof.

Structs§

InvariantFailure
One invariant a landed file’s effective configuration violates: a stable code, the destination, why, and exactly what to write — the operator is told the remediation, never just what was not found.

Functions§

failures
Judge one landed file against the rules its (tech, forge, destination) key owns. A destination no rule owns fails nothing.
target_failures
Judge what a landed file generates, keyed by (technology, forge).