max / alloy

Settle how the age identity gopass needs reaches a machine It is placed by hand, and a fresh install does not provision it. The task left this open on the grounds that a fresh install is when doing it by hand is most annoying and alloy setup already owns first-boot enrollment, so the shape would be one screen. Provisioning turns out to mean two different operations and only one is coherent. The identity already exists: reusing the one the sops migration requires is why gopass beat rbw in the first place. So generating a fresh one at install decrypts nothing already owned, and adding each machine's pubkey as a recipient grows a list that never shrinks as machines retire, which is key sprawl on a different axis from the one the pick was made to avoid. That leaves ingest, and ingest has no channel at first boot. The store arrives over the tailnet, tailnet enrollment is itself a row on that screen, and carrying the identity through the same screen collapses the separation the scheme rests on. The two enrollments already there are also a different kind of object: both authenticate a device against a service that can revoke it, where an age identity is a bearer secret with no service and no audit. A third row beside them would imply a property it does not have. The manual half was filed against a manual/recovery.md that does not exist; recovery is split across chapters 3 and 14. Written as both halves instead. Chapter 10 names where the identity lives and points at gopass config as the authority over the page. Chapter 14 gains the entry separating the two secrets that get wanted at the same moment, since the eight-word phrase unlocks the disk and the identity decrypts the store and neither substitutes for the other. The console noticing an absent identity and saying so is GO alloy 9664b160, which is what makes STACK.md's "what the console does instead" true. GO alloy c113feec.