Add the consumed-file carve-out plan for archetypes#21 #27
No reviewers
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
allod/strategy!27
Loading…
Reference in a new issue
No description provided.
Delete branch "agent/consumed-file-carve-out-plan"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Adds the dev plan for carving each consumed secret file out of the secrets input, so a dev machine's runtime closure holds the files it uses instead of every ciphertext in the deployment, plus the review prompt that drove it. Plan text only — no framework code changes here. Three review passes have run and the plan text has converged; the implementation PR against
allod/archetypesfollows and carries the closing keyword.The plan resolves the two questions
allod/archetypes#21left open — carve in the consuming modules rather than adding an identity-template export, and leave theallod-toolsinput out — and corrects one claim in that issue that would have broken the build: the issue's validation sayscredential-profilesalready accepts a carved path, which is true of the Forgejo matcher and false of the GitHub matcher that guards the very module being changed.Review
Three passes, rotated models, per
dev-plans.md:claude-opus-5gpt-5.6-solclaude-fable-5gpt-5.6-solStopped on the first condition in the review prompt: review-introduced findings outnumbered original-plan findings for two consecutive passes. The second condition is not met, because pass 3 still found blockers — all of them in the acceptance-test shell script the reviews themselves wrote. Scope, interface contracts and risk have been stable since pass 1.
Two findings reversed the author's claims and were each re-verified empirically on Nix 2.31.5 rather than accepted on assertion.
./secrets + "/<name>.age"is a path value that interpolates to an individual store file, so the two token-file sites the original plan added to scope were never uncarved. Anddev-home-shared.nix:25pads only the build closure, not the runtime closure the plan measures — pass 1 cut theallod-toolsscope for a reason that was itself a build/runtime conflation, which pass 2 corrected while leaving the cut standing on its other ground.Risk
R0. Plan and review-prompt text; no runtime, generated, or operational behavior changes. The residual risk of the work it describes is assessed in the plan as R3, with the argument against R4 recorded and attacked across two passes.
Validation
Acceptance-test block parses (
bash -n) and its fail-open paths were probed. Full Nix execution belongs to implementation, which the plan gates on a disposable machine before any machine the owner works from.Refs allod/archetypes#21
toString on the token files' path values names the child inside the source root: run verbatim against the composed allod-dev, test 6 reports /nix/store/<hash>-source/secrets/agent-pr-token.age and .../forgejo-https-token-allod-dev.age, hits the /nix/store/*/* case, and exits 1 on the happy path — while the plan simultaneously forbids wrapping those sites in a second builtins.path. Interpolation is the coercion agenix performs when it embeds the file in the activation script: verified on Nix 2.31.5, it materialises the token path values as store-root files while an uncarved "${secrets}/..." string keeps its in-root spelling, so the projection keeps its discriminating power and stops contradicting the out-of-scope contract. Record the toString-performs-no-copy caveat in the token-file contract. Model: claude-fable-5The cut stands, but its stated reason conflated the two closures this plan is otherwise careful to separate. dev-home-shared.nix:25 embeds ${allod-tools}/pm inside a runCommandLocal builder and the readFile consumers carry root context into derivation inputs — build-closure retention only, which never lands on a machine. In the realised-output closure the plan measures, the tools root is held solely by agent-hooks.nix:11: home-manager's insertFileEntry symlinks a home.file source whose executable bit matches (verified in files.nix at the locked rev 079a3b5, with the tracked hook executable), and the symlink target names the root. So carving that one site would remove the root from the runtime closure; the true reason it stays out of scope is that the tools input holds no ciphertext. Stating the wrong mechanics would send the future tools change chasing a directory consumer that only pads the build closure. Model: claude-fable-5bdb1835ae2to912ae70e1d