Make local UI setup truthful and rerunnable
This commit is contained in:
master
@@ -161,6 +161,11 @@ Canonical policy for upgradeable on-prem installs:
|
||||
Notes:
|
||||
|
||||
- Compose PostgreSQL bootstrap scripts in `devops/compose/postgres-init` run only on first database initialization.
|
||||
- `devops/compose/postgres-init/14-platform-environment-settings.sql` now
|
||||
leaves `platform.environment_settings` empty on fresh local databases so the
|
||||
setup wizard owns first-run completion truth. Older local volumes with the
|
||||
legacy `(tenant_id, key)` table shape are converged by Platform release
|
||||
migration `064_EnvironmentSettingsInstallationScopeConvergence.sql`.
|
||||
- Startup-hosted migrations are currently wired only for selected modules; CLI coverage is also module-limited.
|
||||
- For the authoritative current-state module matrix, use `docs/db/MIGRATION_INVENTORY.md`.
|
||||
|
||||
@@ -210,6 +215,10 @@ Verified current UI boundary on `2026-04-14`:
|
||||
`platform.setup_sessions` and owns only the five control-plane steps the
|
||||
running control plane can truthfully converge: PostgreSQL, Valkey, schema
|
||||
migrations, admin bootstrap, and crypto profile.
|
||||
- The Admin step depends on Platform reaching Authority's internal bootstrap
|
||||
endpoint with the shared bootstrap API key. In local compose, this is wired
|
||||
by forwarding `AUTHORITY_BOOTSTRAP_APIKEY` into Platform as
|
||||
`STELLAOPS_BOOTSTRAP_KEY`.
|
||||
- Tenant-scoped onboarding stays on `/setup/*` and other authenticated module
|
||||
surfaces instead of being duplicated inside the bootstrap wizard.
|
||||
- The inline GitLab path still needs real credential input from the operator.
|
||||
|
||||
@@ -114,6 +114,8 @@ Completion criteria:
|
||||
| 2026-04-14 | Rebuilt the Angular workspace after the secret-authority UI cutover and fixed downstream specs that still assumed the pre-cutover raw `CreateIntegrationRequest` wizard output. | Developer |
|
||||
| 2026-04-14 | Ran the live GitLab UI bootstrap proof with inline secret staging against the local stack after refreshing `secret/gitlab` in dev Vault. The resulting Playwright artifact `src/Web/StellaOps.Web/output/playwright/live-integrations-ui-bootstrap.json` recorded `16/16` healthy integrations, `16` successful test probes, and `0` failed integrations. | Developer |
|
||||
| 2026-04-14 | Closed the remaining web-suite caveat by synchronizing stale security/audit/settings/setup-wizard specs with the current shipped contracts and rerunning the deterministic web batches through the previously failing tail. Batch `27/33` passed with `79/79` tests, batch `28/33` passed with `65/65`, and batches `29-33/33` passed cleanly, leaving the default web batch lane green. | Developer |
|
||||
| 2026-04-14 | Fixed the last local setup-finalize blocker by converging `platform.environment_settings` from the legacy tenant-scoped bootstrap shape to the installation-scoped schema expected by the truthful setup flow, updating the compose fallback, and adding regression coverage around the migration/runtime compatibility path. | Developer |
|
||||
| 2026-04-14 | Re-ran the full setup wizard from scratch through `src/Web/StellaOps.Web/scripts/live-setup-wizard-full-bootstrap.mjs`. The refreshed artifact `src/Web/StellaOps.Web/output/playwright/live-setup-wizard-full-bootstrap.json` recorded `failedActionCount=0`, `runtimeIssueCount=0`, and final completion through `crypto-finalize-completed`, while `https://stella-ops.local/healthz` stayed `ready=true`. | Developer |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: a truthful UI setup starts only after the control plane is already reachable in the browser. Docker/host/runtime bring-up remains a machine bootstrap concern, not a browser concern.
|
||||
@@ -121,6 +123,7 @@ Completion criteria:
|
||||
- Decision: secret material belongs in a secret authority, not in the integration catalog and not in frontend-only state. The UI must talk to a backend secret-staging contract that returns an authref binding.
|
||||
- Decision: the first shipped Secret Authority writer targets Vault KV v2 only. Other secrets-manager providers fail explicitly with `501 not_implemented` instead of pretending write support exists.
|
||||
- Decision: installation-scoped wizard progress is now persisted in `platform.setup_sessions`, and only non-sensitive draft values are stored there.
|
||||
- Decision: `platform.environment_settings` is installation-scoped in both startup migrations and compose bootstrap fallbacks; local bootstrap must not preseed `SetupComplete` or carry tenant-scoped keys forward.
|
||||
- Decision: the live UI bootstrap artifact is considered green when the integration catalog converges to `16/16` healthy entries and the per-integration create/test/health checks succeed, even if background assistant/context requests are aborted during route transitions.
|
||||
- Risk: if the setup wizard continues to mix installation-scoped and tenant-scoped concerns, it will keep drifting into a misleading all-in-one setup surface that cannot be made truthful.
|
||||
- Risk: adding a secret staging API without strong audit and scope controls would weaken the platform security posture.
|
||||
|
||||
@@ -105,6 +105,10 @@ node src/Web/StellaOps.Web/scripts/live-integrations-ui-bootstrap.mjs
|
||||
- The separate first-run setup wizard (`/setup-wizard/wizard`) now reaches the
|
||||
Platform setup API through the frontdoor and uses persisted,
|
||||
installation-scoped setup sessions for the five truthful control-plane steps.
|
||||
- The wizard's Admin step uses Authority's internal bootstrap API, so the local
|
||||
Platform container must receive the same bootstrap key via
|
||||
`STELLAOPS_BOOTSTRAP_KEY` that Authority exposes through
|
||||
`AUTHORITY_BOOTSTRAP_APIKEY`.
|
||||
|
||||
Scripted convergence path:
|
||||
|
||||
|
||||
@@ -263,6 +263,11 @@ reconfiguration checks.
|
||||
Current runtime behavior:
|
||||
- Authoritative wizard state is persisted in `platform.setup_sessions` via
|
||||
migration `063_PlatformSetupSessions.sql`.
|
||||
- Installation-scoped environment settings and the `SetupComplete` marker now
|
||||
converge through `platform.environment_settings` keyed only by `key`.
|
||||
Migration `064_EnvironmentSettingsInstallationScopeConvergence.sql` upgrades
|
||||
older compose-created tables that still used the legacy `(tenant_id, key)`
|
||||
primary key.
|
||||
- The persisted store keeps only non-sensitive draft configuration plus step
|
||||
state, timestamps, and check results. Secret material is still expected to be
|
||||
staged through a secret authority rather than stored in wizard session state.
|
||||
|
||||
@@ -28,9 +28,17 @@ design material later in this document.
|
||||
|
||||
- The implemented UI bootstrap flow persists authoritative installation-scoped
|
||||
state in `platform.setup_sessions`.
|
||||
- Fresh compose bootstrap no longer pre-seeds `SetupComplete=true`; a clean
|
||||
local database now lands in the setup wizard until the control-plane steps
|
||||
are actually finalized. Legacy local volumes are auto-converged by Platform
|
||||
release migration `064_EnvironmentSettingsInstallationScopeConvergence.sql`.
|
||||
- The current live step inventory is limited to the five control-plane steps
|
||||
the running platform can truthfully validate and converge:
|
||||
`database`, `cache`, `migrations`, `admin`, and `crypto`.
|
||||
- The `admin` step now seeds the same local standard-provider and superuser
|
||||
defaults into wizard draft state that it renders in the visible form, so an
|
||||
operator can accept the prefilled values without retyping them and still get
|
||||
a truthful backend apply.
|
||||
- `probe` and `apply` are now distinct backend operations. Successful probes do
|
||||
not complete steps.
|
||||
- `stella setup` is a backend-authoritative client for the same
|
||||
|
||||
Reference in New Issue
Block a user