In-app /install configurator and /admin/diagnostics for Azure/Entra deployments
Altien adds a backend-side install wizard that walks an operator through Azure Key Vault secrets, Entra app registration, and readiness checks - all served from the running container. The manifest in `lib/install/manifest.ts` doubles as a live inventory of every config item the app expects.
Commit c94bf9f1 is the backend half of an operator setup UI. It's structured around a config manifest - a TypeScript file listing every expected secret (KV secret names, env-only items, readiness probes) with human-readable labels and check logic. The manifest serves as both the wizard's data model and the source for /admin/diagnostics, which runs those same checks on demand.
Auth for /install is a two-phase flow. A bootstrap token (set at deploy time) gates the first sign-in; on successful Entra admin login the token burns. After that, the session is maintained with HMAC-signed short-lived cookies issued by lib/install/sessionTokens.ts. The bootstrap-burn mechanism means the install surface can't be re-entered by anyone who only knows the original deploy token.
lib/install/checks/ holds individual readiness probes. installerAccess.ts makes a real ARM call - it lists role assignments on the Key Vault scope filtered to the installer's principal ID, then reports pass when the Key Vault Secrets Officer assignment is gone. Three things gate that check: SUBSCRIPTION_ID in env, installer-principal-id in Key Vault, and UAMI Reader permission on the KV scope. Each missing prerequisite fails soft to status: "info" with a remediation hint rather than a misleading green tick.
The whole thing is tightly coupled to Azure/Entra/Key Vault. Routes under /install and /admin/diagnostics don't exist in the upstream codebase.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?