Record the fork-safe check rule and its witness #61

Merged

vnprc merged 2 commits from agent/fork-safe-check-rule into master

2026-09-23 17:19:02 +01:00

allod-agent commented

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

Member

Records the check rule that allod/archetypes#88 enforces, so the next session writing a framework check meets it before it writes one that only works on the template.

Three things go into testing.md, beside the narrower "do not name a real machine in a fixture" rule it already carries:

The rule and its reason. A check reads the composed machines or its own fixtures, never a data input's contents by name. Names in the data layer are what a deployment fork replaces, so a check that names one passes here and fails there, and the fork's only recourse is to exclude it.
The distinction that keeps the rule usable. A data repo's file layout is contract — production itself reads ${secrets}/git/protected-branches — while its names are not. Without that line the rule reads as condemning working production paths.
The seam hazard. machineConfigurations merges profileData into builder arguments, so a parameter added so a check can drive a builder is also a key the profiles layer can set. That cost was found by review, not by design, which is why it is worth writing down.

Plus a pointer to the standing witness, and the one thing that makes such a witness stop working: tuning the fixture data until a check passes.

No line is proposed for memory.md; this belongs to the topic file that owns check policy, and the index takes a line only on two sightings.

Refs allod/archetypes#88

Records the check rule that allod/archetypes#88 enforces, so the next session writing a framework check meets it before it writes one that only works on the template. Three things go into `testing.md`, beside the narrower "do not name a real machine in a fixture" rule it already carries: - **The rule and its reason.** A check reads the composed machines or its own fixtures, never a data input's contents by name. Names in the data layer are what a deployment fork replaces, so a check that names one passes here and fails there, and the fork's only recourse is to exclude it. - **The distinction that keeps the rule usable.** A data repo's file layout is contract — production itself reads `${secrets}/git/protected-branches` — while its names are not. Without that line the rule reads as condemning working production paths. - **The seam hazard.** `machineConfigurations` merges `profileData` into builder arguments, so a parameter added so a check can drive a builder is also a key the profiles layer can set. That cost was found by review, not by design, which is why it is worth writing down. Plus a pointer to the standing witness, and the one thing that makes such a witness stop working: tuning the fixture data until a check passes. No line is proposed for `memory.md`; this belongs to the topic file that owns check policy, and the index takes a line only on two sightings. Refs allod/archetypes#88

allod-agent added 1 commit

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

Record the fork-safe check rule and its witness e6d8b10cde

A framework check that names a data input's contents passes on the
template and fails on every deployment fork. The rule, the file-layout
versus names distinction that keeps it usable, the witness that enforces
it, and the seam hazard that widening a builder for fixtures also widens
what the profiles layer can set.

Refs allod/archetypes#88

allod-agent commented

2026-09-23 16:59:06 +01:00

Author

Member

Corrected one sentence: the fork-safety cadence no longer claims a memory reason that has since been measured away.

The paragraph said the witness runs on the lock-bump path because a second pass would double a run already peaking near the memory ceiling. That was true of the whole-flake gate this repo used to describe. allod/archetypes#31 has since split the gate to one process per step and measured it — about 80 s, largest single process 1.7 GiB — and allod/memory#65 already corrected nix.md to match. The sentence now states the cadence and stops arguing for it.

Worth flagging for whoever reads this: the same measurement weakens the original case for the witness being lock-bump-only at all. A second full pass now costs roughly another 80 s with no memory risk, since only one process runs at a time. Whether it should become a per-commit gate is a real question that measurement reopened, and it belongs in an archetypes issue rather than in this paragraph.

Corrected one sentence: the fork-safety cadence no longer claims a memory reason that has since been measured away. The paragraph said the witness runs on the lock-bump path because a second pass would double a run already peaking near the memory ceiling. That was true of the whole-flake gate this repo used to describe. allod/archetypes#31 has since split the gate to one process per step and measured it — about 80 s, largest single process 1.7 GiB — and allod/memory#65 already corrected nix.md to match. The sentence now states the cadence and stops arguing for it. Worth flagging for whoever reads this: the same measurement weakens the original case for the witness being lock-bump-only at all. A second full pass now costs roughly another 80 s with no memory risk, since only one process runs at a time. Whether it should become a per-commit gate is a real question that measurement reopened, and it belongs in an archetypes issue rather than in this paragraph.

allod-agent added 1 commit

2026-09-23 16:59:07 +01:00

Drop a justification that measurement has since removed 111dbaf01d

The fork-safety paragraph explained the lock-bump cadence by saying a
second pass would double a run already near the memory ceiling. The
archetypes gate is now one process per step, measured at about 80 s with
a largest single process of 1.7 GiB, so that reason no longer holds and
nix.md records the new numbers. The cadence is stated as a fact instead.

Refs allod/archetypes#31

vnprc force-pushed agent/fork-safe-check-rule from 111dbaf01d to f11e98ab9d

2026-09-23 17:01:54 +01:00

Compare

vnprc force-pushed agent/fork-safe-check-rule from f11e98ab9d to abe375bc32

2026-09-23 17:18:49 +01:00

Compare