Reconsider the fork witness as a second composition #94

New issue

Open

opened 2026-09-21 22:59:55 +01:00 by allod-agent · 0 comments

allod-agent commented

2026-09-21 22:59:55 +01:00

Member

Decide whether the fork-safety witness should become a Nix output built from a second composition, rather than a shell runner driving --override-input, once the checks are files that can be called twice.

Primary goals:

One fewer moving part, if it pays — a second composition would retire fork-safety.sh (228 lines) and the three fixture flake.nix wrappers, leaving only the synthetic data those wrappers carry.
The witness becomes an ordinary output — checks and a fork-data equivalent built by the same per-check machinery check.sh already has, instead of a second script with its own accounting.
Decided on measurement, not preference — the current route works and is not to be replaced on aesthetics.

Current state and specifics

fork-safety.sh runs the suite a second time with --override-input pointed at checks/fork-fixture/{secrets,profiles,inventory}, one nix process per check. That route was chosen in allod/archetypes#88 deliberately: the alternative required factoring the whole composition into a function of its three data inputs, which at the time meant restructuring a 3000-line let, and the override route has the incidental virtue of exercising the same redirect mechanism a real deployment fork uses.

Both halves of that reasoning change once allod/archetypes#93 lands. The composition shrinks to something that can plausibly take its data inputs as parameters, and the checks become functions that can be applied to a second composition as easily as to the first. The redirect mechanism is separately witnessed by the deploy template's composed-layer check, so little is lost there.

The decision criterion, to be answered by measurement rather than specified here: adopt the second composition if it retires the runner and the three wrappers without raising peak evaluation memory, and if a fork-data check can still be built one at a time — the suite already peaks near the memory ceiling on a 7 GiB box, which is why nothing evaluates the whole flake at once. If instantiating the composition twice costs more memory than the override route, the runner stays and this issue closes with that recorded.

Note that a second composition alone does not settle how the witness is run on a host whose system the checks are not keyed on; that accounting is allod/archetypes#90.

Scope

In scope: the shape of the fork witness and whatever composition parameterization it needs. The synthetic data under checks/fork-fixture/ stays either way; only its flake wrappers are in question.

Blocked until: allod/archetypes#93 has moved the checks out of flake.nix. Evaluating this before then re-opens the restructuring that issue does properly.

Refs allod/archetypes#88, allod/archetypes#90, allod/archetypes#93

Decide whether the fork-safety witness should become a Nix output built from a second composition, rather than a shell runner driving `--override-input`, once the checks are files that can be called twice. Primary goals: - **One fewer moving part, if it pays** — a second composition would retire `fork-safety.sh` (228 lines) and the three fixture `flake.nix` wrappers, leaving only the synthetic data those wrappers carry. - **The witness becomes an ordinary output** — `checks` and a fork-data equivalent built by the same per-check machinery `check.sh` already has, instead of a second script with its own accounting. - **Decided on measurement, not preference** — the current route works and is not to be replaced on aesthetics. ### Current state and specifics `fork-safety.sh` runs the suite a second time with `--override-input` pointed at `checks/fork-fixture/{secrets,profiles,inventory}`, one `nix` process per check. That route was chosen in allod/archetypes#88 deliberately: the alternative required factoring the whole composition into a function of its three data inputs, which at the time meant restructuring a 3000-line `let`, and the override route has the incidental virtue of exercising the same redirect mechanism a real deployment fork uses. Both halves of that reasoning change once allod/archetypes#93 lands. The composition shrinks to something that can plausibly take its data inputs as parameters, and the checks become functions that can be applied to a second composition as easily as to the first. The redirect mechanism is separately witnessed by the deploy template's `composed-layer` check, so little is lost there. The decision criterion, to be answered by measurement rather than specified here: adopt the second composition if it retires the runner and the three wrappers without raising peak evaluation memory, and if a fork-data check can still be built one at a time — the suite already peaks near the memory ceiling on a 7 GiB box, which is why nothing evaluates the whole flake at once. If instantiating the composition twice costs more memory than the override route, the runner stays and this issue closes with that recorded. Note that a second composition alone does not settle how the witness is run on a host whose system the checks are not keyed on; that accounting is allod/archetypes#90. ### Scope In scope: the shape of the fork witness and whatever composition parameterization it needs. The synthetic data under `checks/fork-fixture/` stays either way; only its flake wrappers are in question. Blocked until: allod/archetypes#93 has moved the checks out of `flake.nix`. Evaluating this before then re-opens the restructuring that issue does properly. Refs allod/archetypes#88, allod/archetypes#90, allod/archetypes#93

allod-agent referenced this issue

2026-09-22 01:01:04 +01:00

Move the check suite out of flake.nix into checks/ #96