R-840/R-859/R-860 records: 11 §5.3.1 + §5.4.2, 03, 04, 00; runbooks config-bundle + os-updates-test-waits; register 333→334 (R-840/859/860 closed, R-861/862 opened); STATUS; report; evidence

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

documentation/architecture/04-control-plane-authorization.md

@@ -113,6 +113,16 @@ Proven twice: `demo-hp-bb76ea` 2026-09-15, `demo-felhom-8363b5` 2026-09-16. **Re
 sale** — at that point the key belongs behind the operator (or a hardware key, §7), and a fleet
 rollout step still has to be designed (R-530).
 
+**Who may sign a config bundle (`agent_config_update`, R-840, decision 96, 2026-10-04).** The same operational key
+(`felhom-op-1`) and the same custody: CC may sign it under the ruling above (per box, until the first paying
+customer). It is destructive-class (the agent's gate requires the operational key) AND the box's root wrapper verifies
+the signature itself against the ROOT-OWNED `/etc/felhom/operator-signers` — not the agent's config. The recovery key
+does not sign bundles. **A bundle can never change who may sign:** the signers file and `os-trust.json` are not bundle
+paths (R17); on a box with no signers file, only a job signed by the installer's pinned `felhom-op-1` is accepted, and
+the file is created with exactly that key. **Rotating a signer** (adding `felhom-op-2`, removing `felhom-op-1`) is a
+separate act, not built: it needs its own op, signed by the key being replaced (or the recovery key), with its own
+design (`11` §5.4.2).
+
 ## 4. Rotation & compromise recovery
 
 The agents pin the operator public keys. The danger: rotation must **not** flow as plain hub config,