The seed docs describe a bootstrap secret the code does not have

[onel]

Size

S

Area

backend

Depends on

none

Summary

ENVIRONMENT.md still describes the hosted first admin as gated by a one-time admin_bootstrap_secret carried in the seed. That mechanism no longer exists. grep -rn "admin_bootstrap_secret\|BootstrapSecret" --include=*.go returns nothing: the secret was replaced by assertion_verification_key, and a hosted box now creates its first admin through the portal-to-box SSO handshake (internal/api/sso.go), with /setup disabled on hosted altogether (internal/api/auth.go).

So the doc describes a login path that cannot happen, on the page that is the single home for hosted design. Anyone reading it to answer "how does someone get into a hosted box" gets a confident, detailed, wrong answer — and the same page is what malmoos/cloud is told to read before building against the seed.

This is the same failure that produced #404 → #407: a spec section that was accurate when written, never updated when the code moved, and trusted later because it reads as current. Fixing it is cheap; leaving it is how the next wrong issue gets written.

Spec / source of truth

docs/specs/ENVIRONMENT.md # Provisioning & first-boot, and its "Admin bootstrap — as built" subsection. Cross-check against internal/profile/seed.go (the real seed shape), internal/api/sso.go (how the first admin is really created) and internal/api/auth.go (what /setup does on hosted).

Do

1. Read the code first, then write. profile.Seed is {box_id, assertion_verification_key, enrollment, update_target_url}. There is no bootstrap secret, no stored hash, and no bootstrap_secret body field.
2. Fix the seed-file bullet (ENVIRONMENT.md # Admin bootstrap — as built): the field list is wrong.
3. Fix the rest of that subsection, which is wrong beyond one line — it describes ingesting and hashing the secret, a /setup gate that compares it, a 401 on a wrong secret, a 503 before ingestion, and an operator handing the secret over out of band. Replace it with what actually happens: the box verifies a short-lived portal assertion against the seeded key and creates the first admin from it; /setup is not the hosted path.
4. Rename the subsection if "Admin bootstrap" no longer fits what it describes.
5. Fix docs/dev/hosted-boot-proof.md (line ~9), which repeats the same wrong field list.
6. grep -rn "admin_bootstrap_secret" docs/ and fix every remaining hit except docs/progress/ — progress entries are frozen snapshots and stay as they were written.
7. While you are in there: check the surrounding bullets for anything else that no longer matches the code, and say in the PR what you checked, not just what you changed.

Touch

docs/specs/ENVIRONMENT.md, docs/dev/hosted-boot-proof.md

Done when

• No doc outside docs/progress/ claims the seed carries an admin bootstrap secret.
• The hosted first-admin path in ENVIRONMENT.md matches internal/api/sso.go, and someone can follow it without reading the code.
• The PR says which surrounding claims were checked against the code and found correct — a stale section is rarely stale in only one place.