hermetic init walkthrough

CLI:

hermetic init                 # auto: attaches if a `hermetic` foundation stack exists, else creates one
hermetic init --create        # force create, fail if one already exists
hermetic init --attach        # force attach, fail if none exists

You’ll be asked for a profile (or pass --profile), then a region (defaults to the profile’s own). init resolves your identity via STS, best-effort reads your account alias and org id, and — before doing anything mutating — shows you the twelve-digit account id and asks you to type it back as a confirmation. Then it pushes the Tailscale OAuth secret to SSM, creates the foundation, and — last of all, once the fleet row is written and your config is frozen, and if the client carries policy_file — writes hermetic’s ssh and acls entries into your tailnet policy file, between // hermetic:managed markers, with the rest of the file untouched. The policy is last on purpose: if init fails after the policy phase, hermetic policy shows the blocks it wrote and hermetic teardown removes them, which is only true because your config is already frozen by then. Without the scope it prints the snippet instead; paste it before creating any agents, or create will succeed but nothing will be reachable. --skip-policy turns the write off for a policy deployed from git. init also points you at the DNS page to turn on HTTPS Certificates, without which the last provisioning step on every agent fails.

App: launched against a home that has never run init, the app opens the same flow as a wizard instead of the dashboard: step 1 profile pick, step 2 connection check (an sts get-caller-identity spinner that resolves to the identity card or an error+retry), step 3 foundation (tailnet, OAuth secret, network, ACL snippet, HTTPS Certificates check — skipped when attaching), step 4 op progress that swaps in place to the dashboard on success. Step 2 replaces the CLI’s typed-twelve-digits gate with an explicit “I verified this is the account I intend to operate” checkbox next to the account id the same STS call resolved — the value it sends back to core (account_id_typed) is that same identity.account_id, and core still independently re-verifies it, so the safety property is the same even though the app’s ceremony is a toggle, not a typed number.

Re-targeting an already-initialized home to a different account or fleet is hermetic init --reset --yes and nothing else — no flag combination bypasses the typed confirmation.