docs: pre-load meta-flake design

scratchpad in claude.md and an in-flight callout at the top of
docs/approvals.md describe the upcoming overhaul so subsequent
commits can cite the design. covers: module-only agent flake
shape, /var/lib/hyperhive/meta/ as a hive-c0re-owned single
repo, applied remote pre-wired in proposed for manager git
plumbing, /meta RO bind for the system-wide deploy log,
auto-migration on hive-c0re startup with HIVE_SKIP_META_MIGRATION
kill-switch.

CLAUDE.md

@@ -114,29 +114,51 @@ read them à la carte.
 In-flight or recent context that hasn't earned a section yet.
 Prune freely.
 
-- **Just landed:** tag-driven config-apply overhaul. Two-repo
-  split kept (proposed = manager RW, applied = core-only) for
-  safety. New flow: at `request_apply_commit` time hive-c0re
-  fetches the manager's commit into applied and pins it as
-  `proposal/<id>`; the manager-side repo is then irrelevant
-  for that approval. Approve / deny / build walk through more
-  tags (`approved/`, `building/`, `deployed/`, `failed/`,
-  `denied/`) on the same commit; `applied/main` only
-  fast-forwards on `deployed/`. `failed/` and `denied/` are
-  annotated — body is the build error or the operator's deny
-  note respectively. Manager has `/applied` bind-mounted RO
-  (whole tree) so `git fetch /applied/<n>/.git
-  'refs/tags/*:refs/tags/applied/*'` mirrors every relevant
-  tag into its proposed clone. `agent.nix` stays the entry
-  point; the whole tracked tree is now preserved
-  through apply (arbitrary files supported). The wrapper
-  `flake.nix` is regenerated by hive-c0re every
-  spawn/rebuild but never tracked, so the applied log is
-  exactly the manager's commits in deploy order. Migration:
-  no in-place — pre-overhaul applied dirs are detected via
-  the missing `deployed/0` tag and `setup_applied` bails
-  with `destroy --purge` instructions. See
-  `docs/approvals.md`.
+- **In flight:** meta-flake overhaul. Each agent's applied
+  repo becomes a tiny module-only flake (`nixosModules.default
+  = import ./agent.nix`); `agent.nix` is just a NixOS module
+  function `{ config, pkgs, lib, ... }: { ... }` — no
+  extendModules, no hyperhive input visible to the manager.
+  A single hive-c0re-owned repo at `/var/lib/hyperhive/meta/`
+  declares one input per agent (pointing at that agent's
+  applied repo via `git+file://`) and one
+  `nixosConfigurations.<n>` output per agent, wrapping
+  `inputs.agent-<n>.nixosModules.default` with the identity
+  + `HIVE_PORT` / `HIVE_LABEL` / `HIVE_DASHBOARD_PORT`
+  injection that today's per-agent `setup_applied` does
+  inline. Containers run against `meta#<n>` instead of
+  `applied/<n>#default`. Every approval that lands does
+  `nix flake lock --update-input agent-<n>` in meta and
+  commits the lock — meta's git log is the system-wide
+  deploy audit trail; per-agent tags stay as before for
+  inside-baseball state.
+- **Companion change:** the manager's `/agents/<n>/config/`
+  (proposed) gets `applied` pre-configured as a git remote
+  pointing at `/applied/<n>/.git` (the RO bind already
+  there). `git fetch applied` / `git show
+  applied/refs/tags/deployed/<id>` / `git rebase
+  applied/main` etc. all just work from inside the
+  manager. The manager additionally gets `/meta` RO-bound,
+  so `git -C /meta log --oneline` and
+  `cat /meta/flake.lock` answer "what's actually deployed
+  across the swarm right now."
+- **Auto-migration on startup:** new phase before
+  `auto_update::run` rewrites each existing
+  `applied/<n>/flake.nix` to the module-only shape +
+  relocates `deployed/0`, adds the `applied` remote to each
+  proposed repo, bootstraps the meta repo from the agent
+  list if missing, and `nixos-container update`s every
+  container to point at `meta#<n>` (no fs wipe, no
+  re-login). Idempotent; `HIVE_SKIP_META_MIGRATION=1`
+  defers it.
+- **Just landed (prior overhaul still in place):** tag-driven
+  config-apply. Two-repo split (proposed = manager RW,
+  applied = core-only); `request_apply_commit` fetches the
+  manager's commit into applied and pins it as
+  `proposal/<id>`; approve / deny / build walk through tags
+  on the same commit; `applied/main` only fast-forwards on
+  `deployed/`. `failed/` + `denied/` are annotated. See
+  `docs/approvals.md` for the state machine.
 - **Recent (since last compaction):** inline +/- diffs on
   Write/Edit, send full body via collapsed details, operator
   cancel + ttl on questions, deny-with-reason, dashboard

docs/approvals.md

@@ -37,6 +37,27 @@ step — the operator just sees the name. On approve, hive-c0re
 creates the container in a background task while the dashboard
 shows a spinner.
 
+## Meta flake (in flight)
+
+> The next overhaul (currently being implemented) introduces a
+> single hive-c0re-owned meta repo at
+> `/var/lib/hyperhive/meta/` that consumes every agent's
+> applied repo as a flake input and owns the wrapper
+> nixosConfiguration. Each agent's `applied/<n>/flake.nix`
+> shrinks to `nixosModules.default = import ./agent.nix` —
+> `agent.nix` becomes a plain NixOS module function (no
+> extendModules / hyperhive input). Containers will run
+> against `--flake /var/lib/hyperhive/meta#<n>`. Every
+> approval that builds does
+> `nix flake lock --update-input agent-<n>` in meta and
+> commits the lock; meta's git log is the system-wide deploy
+> trail. Manager additionally gets `/applied/<n>/.git`
+> pre-registered as the `applied` remote inside its proposed
+> repo, and `/meta` RO-bound for browsing the deploy log.
+> Auto-migrates on startup. Sections below describe the
+> current (still-deployed) tag-driven shape that the meta
+> flake builds on top of.
+
 ## Two repos per agent
 
 ```