Move credential-store-url-parity to allod/tools, the repo that carries the copy #110

New issue

Closed

opened 2026-09-22 20:16:51 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-09-22 20:16:51 +01:00

Move credential-store-url-parity to the repository that carries the copy, so the check stops reading a data input by name and every fork inherits the fix for free.

Primary goals:

The copy's owner proves the copy — allod/tools carries cmd/allod/testdata/credential-store-url.json; its own check suite is where that file's freshness is asserted, not a third repository's.
One less by-name read of a data input — checks/credential-store-url-parity.nix is the remaining framework check that reads a literal filename out of the secrets input, the pattern allod/archetypes#88 exists to remove.
Forks stop inheriting a check that cannot hold — a deployment whose secrets input is its own data repo has no reason to carry a public vector table, and today it must or the check fails.
Archetypes sheds a check it is not party to — delete the file and its index entry once allod/tools carries the assertion.

Current state and specifics

checks/credential-store-url-parity.nix:8-12 builds both sides by name:

toolsCopy = "${allod-tools}/cmd/allod/testdata/credential-store-url.json";
secretsDefinition = "${secrets}/credential-store-url.json";

and cmps them. The invariant is "allod/tools must carry a byte-for-byte copy of the allod/secrets definition" — a statement about two repositories, neither of which is this one. It is wired here (checks/default.nix:64-66) only because archetypes holds both as inputs.

In the template composition secrets is allod/secrets, so the second path resolves and the check means what it says. In a fork composition secrets is the deployment's own data repo, and the check silently changes subject: it now asserts that allod/tools matches the fork's table. A fork that carries no such file fails with cmp: .../credential-store-url.json: No such file or directory; a fork that carries a stale one passes while proving nothing.

checks/fork-fixture/secrets/flake.nix:90-95 documents the current answer — the fixture carries the table as "the one file here that is a copy rather than a rewrite" — which is why the fork-safety witness is green and did not catch this. That is the same by-assumption shape as allod/archetypes#108: the check does not index a data input by a literal name in the fixture's eyes, because the fixture was built to satisfy it.

Fix shape: add allod/secrets as an input to allod/tools' dev flake and assert the parity in a check there. No cycle exists — allod/secrets pins only nixpkgs and allod/inventory. Nothing downstream pays for the new input: allod/tools' flake is development-only and every consumer imports the repository with flake = false (flake.nix:5-8), and that repo already carries sibling checks of this kind (allod-parity). Then delete checks/credential-store-url-parity.nix and its checks/default.nix entry here, and drop the table from checks/fork-fixture/secrets/, which exists only to satisfy this check.

The smaller alternative, if the check should stay in this repo: compare against a value the secrets input exports rather than a filename spelled here — an exported path keeps the comparison byte-for-byte, an exported attrset makes it structural. That closes the fork-safety hole in place but leaves archetypes refereeing an agreement between two other repositories, so it is the fallback, not the default.

Scope

In scope: the allod/tools check, the deletion here, and the fork-fixture table that only this check reads.

Out of scope: the vector table's contents and the grammar predicates in allod/secrets, which no part of this touches. A deployment's own handling until this lands is that deployment's business; one is holding credential-store-url-parity on its exclusion list with a pointer to this issue.

Refs allod/archetypes#88, allod/archetypes#108

Move `credential-store-url-parity` to the repository that carries the copy, so the check stops reading a data input by name and every fork inherits the fix for free. Primary goals: - **The copy's owner proves the copy** — allod/tools carries `cmd/allod/testdata/credential-store-url.json`; its own check suite is where that file's freshness is asserted, not a third repository's. - **One less by-name read of a data input** — `checks/credential-store-url-parity.nix` is the remaining framework check that reads a literal filename out of the `secrets` input, the pattern allod/archetypes#88 exists to remove. - **Forks stop inheriting a check that cannot hold** — a deployment whose `secrets` input is its own data repo has no reason to carry a public vector table, and today it must or the check fails. - **Archetypes sheds a check it is not party to** — delete the file and its index entry once allod/tools carries the assertion. ### Current state and specifics `checks/credential-store-url-parity.nix:8-12` builds both sides by name: toolsCopy = "${allod-tools}/cmd/allod/testdata/credential-store-url.json"; secretsDefinition = "${secrets}/credential-store-url.json"; and `cmp`s them. The invariant is "allod/tools must carry a byte-for-byte copy of the allod/secrets definition" — a statement about two repositories, neither of which is this one. It is wired here (`checks/default.nix:64-66`) only because archetypes holds both as inputs. In the template composition `secrets` is allod/secrets, so the second path resolves and the check means what it says. In a fork composition `secrets` is the deployment's own data repo, and the check silently changes subject: it now asserts that allod/tools matches *the fork's* table. A fork that carries no such file fails with `cmp: .../credential-store-url.json: No such file or directory`; a fork that carries a stale one passes while proving nothing. `checks/fork-fixture/secrets/flake.nix:90-95` documents the current answer — the fixture carries the table as "the one file here that is a copy rather than a rewrite" — which is why the fork-safety witness is green and did not catch this. That is the same by-assumption shape as allod/archetypes#108: the check does not index a data input by a literal name in the fixture's eyes, because the fixture was built to satisfy it. Fix shape: add allod/secrets as an input to allod/tools' dev flake and assert the parity in a check there. No cycle exists — allod/secrets pins only nixpkgs and allod/inventory. Nothing downstream pays for the new input: allod/tools' flake is development-only and every consumer imports the repository with `flake = false` (`flake.nix:5-8`), and that repo already carries sibling checks of this kind (`allod-parity`). Then delete `checks/credential-store-url-parity.nix` and its `checks/default.nix` entry here, and drop the table from `checks/fork-fixture/secrets/`, which exists only to satisfy this check. The smaller alternative, if the check should stay in this repo: compare against a value the `secrets` input exports rather than a filename spelled here — an exported path keeps the comparison byte-for-byte, an exported attrset makes it structural. That closes the fork-safety hole in place but leaves archetypes refereeing an agreement between two other repositories, so it is the fallback, not the default. ### Scope In scope: the allod/tools check, the deletion here, and the fork-fixture table that only this check reads. Out of scope: the vector table's contents and the grammar predicates in allod/secrets, which no part of this touches. A deployment's own handling until this lands is that deployment's business; one is holding `credential-store-url-parity` on its exclusion list with a pointer to this issue. Refs allod/archetypes#88, allod/archetypes#108

vnprc-agent referenced this issue from a commit

2026-09-22 20:19:18 +01:00

Hold credential-store-url-parity on the exclusion list, not in the data repo

vnprc-agent referenced this issue from a commit

2026-09-22 20:20:53 +01:00

Hold credential-store-url-parity on the exclusion list, not in the data repo