Drop the forge SSH block; silence the neovim provider default warnings #10
No reviewers
Labels
No labels
blocked
bug
decision
duplicate
enhancement
help wanted
invalid
landed?
question
ready-to-merge
stale
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/profiles!10
Loading…
Reference in a new issue
No description provided.
Delete branch "agent/drop-forge-ssh-copy"
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?
The
allod-devprofile stops defining its own copy of the forge SSH host block, because the framework now renders that block for every dev VM from the VM's own identity record (allod/archetypes#81). Separately, neovim no longer bundles its Ruby and Python providers, which is the Home Manager 26.05 default and which nothing in this profile uses; the two warnings about that default stop. With the framework change in place the rendered~/.ssh/configonallod-devis byte-identical with and without this deletion. Landing order for a deploy lock: take the framework change first or together with this; a lock that takes this deletion while its archetypes pin still predates the framework change leavesallod-devwith the address book's forge block, keyed to the hypervisor's key it does not hold, until the archetypes pin catches up. The deploy repo's evaluation does not fail in that state, so the order is a human check. If it is wrong, revert this PR. This replaces the closed allod/profiles#9.What changes
hosts/dev/allod-dev/home.nix: theprograms.ssh.matchBlocksforge block is deleted and the now-unusedidentityandruntimeIdentityarguments dropped.modules/preferences.nix:programs.neovim.withRuby = falseandwithPython3 = false, set explicitly becausehome.stateVersionpredates the new default.home.stateVersionis unchanged.Risk
R2: two files, render pinned byte-for-byte below; the integration uncertainty is the lock ordering above, which evaluates cleanly in both orders and only bites functionally in one. Rollback is a revert.
Validation
Run by the integrator at
fa37849:nix flake checkin this repo passes (worker run).--override-input archetypes <allod/archetypes#81 branch> --override-input profiles <this branch>:allod-dev's rendered~/.ssh/configis byte-identical to the render with the framework branch alone (the single forge block,IdentityFile ~/.ssh/allod_vm), and the neovim default warnings and thematchBlockswarning attributed to this file are gone;allod-dev,nexusandprivacy-1evaluate to their toplevel derivations with no evaluation warnings.Cold cross-family review:
gpt-5.6-solviacodex exec, reasoning effortxhigh, read this diff together with the allod/archetypes#81 and allod/secrets#33 diffs for allod/strategy#56 (Claude-family workers authored all three). One finding touched this change, marked blocker: the framework's claim that the two changes may enter a deploy lock in either order is true of evaluation only, and the profiles-first order leaves a dev VM with the hypervisor's forge key. Confirmed by tracing; it is the landing-order constraint at the top of this body and a corrected comment in the framework module, not a code change here.Refs allod/strategy#56