finn.markwitz/nixos
1
1
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: correct plan's sops build-check assumption

Browse Source 
Task 1's implementer found sops.validateSopsFiles makes secret-key
existence a build-time check (via manifest.json.drv), not an
activation-time one as the plan assumed. Corrects Step 10 to reflect
reality rather than leave future readers misled.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Vbvwg3Qt2u9nbkEA3wL17S
This commit is contained in:
finn.markwitz
2026-09-08 17:22:09 +02:00
co-authored by Claude Sonnet 5
parent 731678ecac
commit ac32aca351
1 changed files with 7 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/superpowers/plans/2026-09-08-hermes-agent-mibook.md
+7 -3
View File
@@ -178,11 +178,15 @@ This removes the `placeholder` secret declared here — it was an explicit throw
Run: `nixfmt-rfc-style modules/environments/hermes-agent/default.nix machines/configuration.nix machines/mibook/secrets.nix machines/mibook/environments.nix flake.nix`
- [ ] **Step 10: Build-check (this is the "test")**
- [ ] **Step 10: Build-check (this is the "test", with a known-expected failure until Task 3)**
Run: `nix build '.#nixosConfigurations.mibook.config.system.build.toplevel'`
Expected: builds successfully. This succeeds even though `secrets/mibook.yaml` doesn't yet contain a `hermes-env` key — `sops.validateSopsFiles` only checks the file is valid sops-encrypted YAML, not that every declared secret name exists inside it; that check happens at activation (Task 4), not build.
If it fails on an unknown `services.hermes-agent.*` option, reconcile against the actual module: `nix eval --raw '.#nixosConfigurations.mibook.config.system.build.toplevel'` errors will name the bad option; cross-check against `website/docs/getting-started/nix-setup.md` in the `NousResearch/hermes-agent` repo at the locked revision.
**Correction (found during Task 1 implementation, 2026-09-08):** this does **not** build cleanly yet, and that's expected — `sops.validateSopsFiles = true` (set repo-wide in `machines/core/sops.nix`) makes secret-key existence a **build-time** dependency of `config.system.build.toplevel` (via a `manifest.json.drv` step), not an activation-time check as originally assumed here. Since `secrets/mibook.yaml` still only has the `placeholder` key at this point in the plan (Task 3 adds `hermes-env`), the build correctly fails with:
```
> .../sops-install-secrets: manifest is not valid: secret hermes-env in .../mibook.yaml is not valid: the key 'hermes-env' cannot be found
```
Do **not** treat this as a wiring defect, and do not weaken `sops.validateSopsFiles` to work around it — that's a repo-wide safety invariant, not this task's to change. Instead, confirm the wiring is correct by two other means: `nix build ... --dry-run` (should complete with no eval errors and the full derivation list) and Step 11 below. A fully green (non-dry-run) `nix build` of the toplevel is only reachable after Task 3 populates the real secret — treat that as the actual end-to-end checkpoint, revisited in Task 4 Step 1.
If `--dry-run` itself fails on an unknown `services.hermes-agent.*` option, reconcile against the actual module: the error will name the bad option; cross-check against `website/docs/getting-started/nix-setup.md` in the `NousResearch/hermes-agent` repo at the locked revision.
- [ ] **Step 11: Confirm the option evaluates on**