docs: UI-driven local setup sprints + module dossier sync

Add SPRINT_20260413_004 (platform UI-only setup bootstrap closure)
with BOOTSTRAP-001..006 delivery tracker, and update sprint 003 and
sprint 20260410-001 execution logs to reflect the completed
persistence / orchestrator / secret-authority work.

Sync module dossiers and operator guides with the new reality: setup
wizard UX, platform-service architecture, CLI setup guide, integrations
architecture + local services, release-orchestrator architecture,
install guide, and compose README.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docs/implplan/SPRINT_20260410_001_Web_runtime_no_mocks_real_backend.md

@@ -89,26 +89,73 @@ Completion criteria:
 - [x] Script create/update paths persist declared variables through the owning backend.
 - [x] Targeted backend tests cover the compatibility evaluator, variable persistence, and Platform alias mapping.
 
+### NOMOCK-006 - Remove the remaining no-Postgres Platform script in-memory fallback
+Status: DONE
+Dependency: NOMOCK-005
+Owners: Developer
+Task description:
+- Replace the last runtime `InMemoryScriptService` registration in Platform with a real HTTP bridge to the owning Release Orchestrator `/api/v2/scripts` API so local/browser flows still hit the real scripts backend even when Platform itself is not wired directly to the scripts PostgreSQL schema.
+- Expand the owning Release Orchestrator scripts HTTP surface so the proxy path can remain contract-complete: expose entry-point/dependency/version metadata, publish total-count headers, and accept the dedicated `script:read` / `script:write` scopes that Platform already enforces.
+
+Completion criteria:
+- [x] Platform no longer registers `InMemoryScriptService` in its runtime path when PostgreSQL is absent.
+- [x] Release Orchestrator `/api/v2/scripts` returns the metadata needed to preserve the Platform scripts contract over HTTP.
+- [x] Targeted tests cover the remote Platform scripts client and serial backend builds/tests pass.
+
+### NOMOCK-007 - Replace Platform release-environment in-memory compatibility stores and dead frontend jobengine path
+Status: DONE
+Dependency: NOMOCK-001
+Owners: Developer
+Task description:
+- Remove the runtime `InMemoryEnvironmentStore`, `InMemoryTargetStore`, and `InMemoryFreezeWindowStore` compatibility branch from Platform so release-environment flows hit either the PostgreSQL-backed Release Orchestrator environment services or the owning Release Orchestrator WebApi over HTTP.
+- Correct the Angular release-environment HTTP client to target the real `/api/v1/release-orchestrator` path, map real environment/target/freeze payloads, and send truthful target connection configuration instead of the retired `release-jobengine` path and partial target DTOs.
+
+Completion criteria:
+- [x] Platform no longer registers runtime in-memory release-environment stores when PostgreSQL is absent.
+- [x] Release Orchestrator WebApi owns `/api/v1/release-orchestrator/environments`, `/targets`, and `/freeze-windows` with startup migrations wired for the `release` schema.
+- [x] The Angular release-environment client targets `/api/v1/release-orchestrator`, translates real payloads, and submits type-specific target connection config.
+- [x] Serial backend/frontend verification passes with concrete evidence.
+
 ## Execution Log
 | Date (UTC) | Update | Owner |
 | --- | --- | --- |
 | 2026-04-10 | Sprint created to remove live production-path stubs, mock providers, and in-memory runtime bindings starting with the active Angular app configuration and Concelier feed-mirror surfaces. | Developer |
 | 2026-04-13 | Inventory extended beyond the initial Concelier slice. Confirmed `/ops/operations/feeds/mirror/*` now runs on persisted Concelier state, but found two still-live script-path fictions: Platform still registers `IScriptService` to `InMemoryScriptService` in `src/Platform/StellaOps.Platform.WebService/Program.cs`, and the owning Release Orchestrator `/api/v2/scripts/{id}/check-compatibility` endpoint still returns an unconditional stub success from `src/ReleaseOrchestrator/__Apps/StellaOps.ReleaseOrchestrator.WebApi/Endpoints/ScriptsEndpoints.cs`. Next implementation slice expands to `src/ReleaseOrchestrator/**` for script compatibility truthfulness and to the Platform alias only if still needed after the owning-service fix. | Developer |
 | 2026-04-13 | Completed the scripts runtime slice. Release Orchestrator now evaluates `/api/v2/scripts/{id}/check-compatibility` against persisted script language, variables, dependencies, target metadata, and available secrets; create/update requests now persist declared variables instead of dropping them; and Platform now binds `IScriptService` to the real Release Orchestrator scripts registry when PostgreSQL is configured. Targeted tests passed: `StellaOps.ReleaseOrchestrator.Integration.Tests` `20/20`, `StellaOps.Platform.WebService.Tests` class-targeted `ReleaseOrchestratorScriptServiceTests` `2/2`, and `ReleaseOrchestrator.WebApi` rebuilt cleanly. Live frontdoor verification was blocked in this shell because the local stack was not running (`docker ps` empty, `curl.exe -k https://stella-ops.local/` connection failure). | Developer |
+| 2026-04-13 | Removed the last Platform scripts in-memory runtime branch. When Platform lacks direct scripts PostgreSQL access it now calls the owning Release Orchestrator `/api/v2/scripts` API through a tenant/auth-aware HTTP client instead of falling back to `InMemoryScriptService`. Release Orchestrator scripts endpoints were expanded to expose entry point, dependency, version, and total-count metadata and to accept `script:read` / `script:write` in addition to the older orchestrator scopes. Serial verification passed: `dotnet build src/Platform/StellaOps.Platform.WebService/StellaOps.Platform.WebService.csproj` `0 errors`, `dotnet test src/Platform/__Tests/StellaOps.Platform.WebService.Tests/StellaOps.Platform.WebService.Tests.csproj -- --filter-class StellaOps.Platform.WebService.Tests.RemoteReleaseOrchestratorScriptServiceTests` `3/3`, `dotnet build src/ReleaseOrchestrator/__Apps/StellaOps.ReleaseOrchestrator.WebApi/StellaOps.ReleaseOrchestrator.WebApi.csproj` `0 errors`, `dotnet test src/ReleaseOrchestrator/__Tests/StellaOps.ReleaseOrchestrator.Integration.Tests/StellaOps.ReleaseOrchestrator.Integration.Tests.csproj` `20/20`. | Developer |
+| 2026-04-13 | Post-change live sanity check: the local stack is back up (`platform`, `authority`, and `concelier` healthy; frontdoor `GET /` returned `200`), but `stellaops-router-gateway` still reports `unhealthy` and this sprint slice still lacks an authenticated live `/api/v2/scripts` proof after the remote-path change. | Developer |
+| 2026-04-13 | Completed the release-environment runtime slice. Platform now binds release-environment flows to the PostgreSQL-backed Release Orchestrator services when configured and otherwise proxies the owning `/api/v1/release-orchestrator` API over HTTP instead of registering runtime in-memory environment/target/freeze stores. The Angular release-environment client now targets `/api/v1/release-orchestrator`, maps real environment/target/freeze payloads, enriches environment summaries from live targets/freeze windows, and submits type-specific target connection configuration for Docker, Compose, ECS, Nomad, SSH, and WinRM targets. Serial verification passed: `dotnet build src/Platform/StellaOps.Platform.WebService/StellaOps.Platform.WebService.csproj` `0 errors`, `dotnet test src/Platform/__Tests/StellaOps.Platform.WebService.Tests/StellaOps.Platform.WebService.Tests.csproj -- --filter-class StellaOps.Platform.WebService.Tests.RemoteReleaseOrchestratorEnvironmentClientTests` `3/3`, `dotnet test src/Platform/__Tests/StellaOps.Platform.WebService.Tests/StellaOps.Platform.WebService.Tests.csproj -- --filter-class StellaOps.Platform.WebService.Tests.ReleaseOrchestratorEnvironmentEndpointsTests` `2/2`, `dotnet test src/ReleaseOrchestrator/__Tests/StellaOps.ReleaseOrchestrator.Integration.Tests/StellaOps.ReleaseOrchestrator.Integration.Tests.csproj` `22/22`, `npm run build` in `src/Web/StellaOps.Web` succeeded, and a live authenticated browser probe confirmed the UI now issues `/api/v1/release-orchestrator/*` requests rather than `/api/v1/release-jobengine/*`. | Developer |
+| 2026-04-13 | Finished the live release-environment backend convergence. The browser-facing local slice had omitted `release-orchestrator`, so `/api/v1/release-orchestrator/environments` returned `503`; after rebuilding and starting the real service, authenticated UI traffic still failed with `400` because the environment PostgreSQL stores could not resolve `Func<Guid>` for tenant scope. `StellaOps.ReleaseOrchestrator.WebApi` now registers the tenant GUID provider from `ReleaseEnvironmentIdentityAccessor`, and the infrastructure registration test now resolves the environment stores from DI instead of only checking descriptor presence. Serial verification passed: `dotnet test src/ReleaseOrchestrator/__Tests/StellaOps.ReleaseOrchestrator.Integration.Tests/StellaOps.ReleaseOrchestrator.Integration.Tests.csproj -- --filter-class StellaOps.ReleaseOrchestrator.Integration.Tests.ReleaseEnvironmentInfrastructureRegistrationTests`, `docker compose -f devops/compose/docker-compose.stella-ops.yml up -d release-orchestrator`, `curl.exe -k -i https://stella-ops.local/api/v1/release-orchestrator/environments` (`401` through frontdoor), and an authenticated Playwright probe of `/releases/environments?tenant=demo-prod&regions=apac,eu-west,us-east,us-west` that now reaches the real backend path and renders the truthful empty-state instead of a transport error. | Developer |
+| 2026-04-13 | Extended the live browser proof from read-only recovery to a real mutation round-trip. The authenticated UI created environment `e2e-238131` (`201`, backend id `08d0d89d-964e-4f84-90e8-04cad6f2a0ff`) through `/releases/environments`, rendered the new card from the persisted backend response, then deleted it through the same UI path (`204`) and returned to the truthful empty-state. | Developer |
+| 2026-04-13 | Fixed the remaining release-environment detail-flow contract drift. The owning Release Orchestrator environment/target/freeze models now serialize enum-backed target, health, known-hosts, and WinRM transport values with the Web JSON string-enum contract, and the Angular release-environment client now accepts PascalCase and numeric enum variants from the owning API while still emitting the canonical request shape. The freeze-window editor no longer toggles a dead `showAddDialog` flag; clicking `Add Freeze Window` now opens the real form path. Serial verification passed: `dotnet test src/ReleaseOrchestrator/__Tests/StellaOps.ReleaseOrchestrator.Environment.Tests/StellaOps.ReleaseOrchestrator.Environment.Tests.csproj` `158/158`, `npx vitest run src/tests/environments/release-environment.client.contract.spec.ts src/tests/environments/freeze-window-editor.component.spec.ts --config vitest.codex.config.ts` `3/3`, and `npm run build` in `src/Web/StellaOps.Web` succeeded after the UI changes. | Developer |
+| 2026-04-13 | Completed live authenticated end-to-end proof for the persisted release-environment detail surface. Through `https://stella-ops.local/releases/environments` the browser created environment `e2e-728048` (`201`, id `0d1a9597-c30c-4a17-891a-9dcdfe1ccffa`), updated settings (`200`), created a target (`201`, id `2ab5b680-1c09-4149-b160-af08a614b19c`), deleted that target (`204`), created a freeze window (`201`, id `2377401c-425d-4277-a02b-ec5605cccf1a`), deleted that freeze window (`204`), and deleted the environment (`204`). The two leftover trial environments from earlier failed runs, `E2E e2e-792313` and `E2E e2e-543565`, were then cleaned up through the same authenticated backend path with `204` responses so the local stack did not retain stale verification data. | Developer |
+| 2026-04-14 | Closed an unrelated live frontdoor blocker uncovered during the authenticated dashboard rerun: `/api/v1/vulnerabilities/status` returned `503` because `scanner-web` was missing from the local compose runtime even though the gateway route still pointed at `scanner.stella-ops.local`. Built `stellaops/scanner-web:dev`, started `stellaops-scanner-web`, and verified the path now returns `401` unauthenticated through `https://stella-ops.local/api/v1/vulnerabilities/status`, proving the route is back on the real scanner service instead of failing as an unavailable target. | Developer |
+| 2026-04-14 | Replaced the live Release Control deployment seed path with persisted runtime state. `StellaOps.ReleaseOrchestrator.WebApi` now binds `IDeploymentCompatibilityStore` to a PostgreSQL-backed store, startup auto-migrates `release_orchestrator.deployments`, and the store no longer seeds fake `dep-001`..`dep-004` rows on first access. Serial verification passed: `dotnet test src/ReleaseOrchestrator/__Tests/StellaOps.ReleaseOrchestrator.Integration.Tests/StellaOps.ReleaseOrchestrator.Integration.Tests.csproj` `24/24`, `npm run build` in `src/Web/StellaOps.Web`, live API proof that the deployments list starts empty (`200`, `totalCount=0`), `POST /api/v1/release-orchestrator/deployments` creates `dep-4536d81685ac` (`201`), the same deployment survives a `release-orchestrator` container recreate, and the live browser route `/releases/deployments` now mounts the real Angular deployment feature and renders the persisted `checkout-api` deployment card and detail view instead of the old hardcoded `DEP-2026-*` screens. | Developer |
 
 ## Decisions & Risks
 - Decision: this sprint prioritizes live runtime paths the browser can currently reach over test-only mock helpers.
 - Decision: unsupported operations must return truthful empty/problem responses rather than seeded demo success/error payloads.
 - Decision: after the feed-mirror cleanup, the next highest-value runtime slice is the scripts compatibility path because the browser uses the real `/api/v2/scripts` backend and its compatibility action still reports fabricated success.
 - Decision: the Platform direct scripts alias now reuses the Release Orchestrator scripts library and schema instead of keeping a separate in-memory implementation when PostgreSQL is configured.
+- Decision: Platform now uses the owning Release Orchestrator scripts backend on both runtime branches: direct library binding when PostgreSQL is configured locally, HTTP proxying to the Release Orchestrator WebApi when it is not.
+- Decision: Release Orchestrator scripts endpoints now accept the dedicated `script:read` / `script:write` scopes in addition to the older orchestrator scopes so the Platform proxy path does not need a privileged bypass.
+- Decision: Platform release-environment runtime branches now follow the same pattern as scripts: direct PostgreSQL-backed Release Orchestrator services when configured locally, otherwise tenant/auth-aware HTTP proxying to the owning Release Orchestrator WebApi.
+- Decision: the Angular release-environment client now treats `/api/v1/release-orchestrator` as the sole production backend path and maps the owning environment/target/freeze schema instead of relying on retired `release-jobengine` aliases or partial target DTOs.
+- Decision: the Release Orchestrator host now provides the environment stores with the same tenant GUID resolver used by the higher-level environment services, so authenticated browser traffic activates the real persisted backend instead of faulting during DI.
+- Decision: the owning Release Orchestrator environment surface now emits the environment-management enums with the standard Web JSON string-enum contract, and the Angular client accepts the owning API's PascalCase and numeric variants so detail/settings/targets/freeze-window flows remain compatible during rollout.
+- Decision: live deployment monitoring state now starts empty and becomes real only after `/api/v1/release-orchestrator/deployments` mutations persist to PostgreSQL; seeded compatibility rows are no longer acceptable on the browser path.
+- Decision: `/releases/deployments` now reuses the existing Release Orchestrator deployment store/components that call the real deployments API instead of the older standalone Angular stub pages with hardcoded `DEP-2026-*` payloads.
 - Risk: several modules outside the initial slice still boot with runtime in-memory stores (`Notify`, `Graph`, `Policy`, `Platform`, `Scheduler`, `Scanner`, `BinaryIndex`, `Signals`, `SbomService`, `Signer`, `PacksRegistry`, `AdvisoryAI`). They will need follow-on slices unless a real persistence path already exists and can be wired safely.
-- Risk: Platform still falls back to `InMemoryScriptService` when no PostgreSQL connection string is configured. That preserves non-database test/dev paths, but it means the cleanup is not repo-wide complete yet.
-- Risk: the live browser path for this slice could not be reverified from the shell because the local stack was down during close-out (`docker ps` returned no running containers). The code-level and project-level checks are green, but live redeploy verification still needs a running stack.
+- Risk: the code-level and project-level checks are green and the frontdoor is back up, but this sprint slice still lacks an authenticated live `/api/v2/scripts` verification after the remote-path change. `stellaops-router-gateway` remains `unhealthy`, so browser-level proof should wait for the router health follow-up.
 - Risk: some feed-mirror sub-features appear to have no real persisted backend contract yet, so removing fake data may temporarily surface explicit `501`/empty-state behavior in the UI until the owning backend is implemented.
+- Risk: the global Angular `ng test --watch=false --include ...` path is still blocked by unrelated compile failures outside this slice, so focused frontend verification for the release-environment detail flow currently depends on direct Vitest execution instead of the repo-wide Angular test target.
+- Risk: after recreating `release-orchestrator`, the router can transiently serve `503 No instances available` until the new instance state converges; one live verification pass required a router restart before the frontdoor resumed routing the environment-management path.
+- Risk: the deployment monitoring route is now truthful and persistent, but it is still a compatibility projection over deployment state rather than the full deployment engine and artifact/evidence pipeline. The browser no longer sees fake rows, but deeper deployment execution slices still need follow-on work.
 
 ## Next Checkpoints
 - Remove the active Angular VEX Hub mock provider.
 - Convert the Concelier feed-mirror endpoints from seeded data to real source/read-model state.
-- Replace the Release Orchestrator script compatibility stub with persisted script-aware evaluation.
+- Replace the remaining on-disk stub deployment pages under `src/Web/StellaOps.Web/src/app/features/deployments/` with thin wrappers or remove them once no legacy references remain.
+- Decide whether the real release-environment management feature should replace the current `/environments/overview` redirect path or continue to coexist with the topology inventory surface.
 - Re-run the live scripts UI and compatibility panel once the local stack is back up.
 - Re-test the live feed pages and record the next runtime cleanup slice.

docs/implplan/SPRINT_20260413_003_Web_ui_driven_local_setup_rerun.md

@@ -21,7 +21,7 @@
 ## Delivery Tracker
 
 ### UISETUP-001 - Reset the local Stella runtime to zero state
-Status: DOING
+Status: DONE
 Dependency: none
 Owners: Developer / QA
 Task description:
@@ -29,12 +29,12 @@ Task description:
 - Re-run the documented setup entrypoint needed to bring the platform back to a reachable browser state.
 
 Completion criteria:
-- [ ] Stella-owned containers, volumes, and networks are removed before the rerun.
-- [ ] The documented local setup entrypoint is executed successfully after the wipe.
-- [ ] `https://stella-ops.local` becomes reachable again for browser-driven setup.
+- [x] Stella-owned containers, volumes, and networks are removed before the rerun.
+- [x] The documented local setup entrypoint is executed successfully after the wipe.
+- [x] `https://stella-ops.local` becomes reachable again for browser-driven setup.
 
 ### UISETUP-002 - Drive the operator setup through the browser UI
-Status: DOING
+Status: DONE
 Dependency: UISETUP-001
 Owners: Developer / QA
 Task description:
@@ -42,12 +42,12 @@ Task description:
 - Record which configuration steps are truly persisted/provisioned by the UI versus which ones are session-only or still backend-limited.
 
 Completion criteria:
-- [ ] The setup wizard is exercised through the live browser against the rebuilt stack.
-- [ ] The integrations UI is used for the available local integration onboarding flows.
-- [ ] Any step that is not truly UI-provisioned is captured explicitly with supporting evidence.
+- [x] The setup wizard is exercised through the live browser against the rebuilt stack.
+- [x] The integrations UI is used for the available local integration onboarding flows.
+- [x] Any step that is not truly UI-provisioned is captured explicitly with supporting evidence.
 
 ### UISETUP-003 - Close documentation and evidence gaps for the UI path
-Status: TODO
+Status: DONE
 Dependency: UISETUP-002
 Owners: Developer / Documentation
 Task description:
@@ -55,9 +55,9 @@ Task description:
 - Record the final verified state, remaining non-UI gaps, and any follow-up implementation needs in the sprint log and linked docs.
 
 Completion criteria:
-- [ ] Docs reflect the verified UI-driven setup reality.
-- [ ] Final health and integration results are logged in the execution log.
-- [ ] Remaining non-UI blockers are called out explicitly rather than glossed over.
+- [x] Docs reflect the verified UI-driven setup reality.
+- [x] Final health and integration results are logged in the execution log.
+- [x] Remaining non-UI blockers are called out explicitly rather than glossed over.
 
 ## Execution Log
 | Date (UTC) | Update | Owner |
@@ -69,13 +69,19 @@ Completion criteria:
 | 2026-04-13 | The initial `scripts/setup.ps1 -QaIntegrationFixtures` run failed in the repo-wide `.sln` preflight with `MSB4166` child-node exits on `src/Tools/StellaOps.Tools.sln`, `src/VexHub/StellaOps.VexHub.sln`, and `src/Zastava/StellaOps.Zastava.sln`; reran the documented setup entrypoint with `-SkipBuild` to continue the actual local stack bring-up. | Developer |
 | 2026-04-13 | Patched the Integrations Hub UI to expose the missing local onboarding categories (`Secrets`, `Feed Mirrors`, `Object Storage`) and aligned wizard validation with the backend contract so optional-auth / optional-scope local connectors can be created from the browser instead of being blocked by frontend-only rules. | Developer |
 | 2026-04-13 | Angular compile validation for the changed UI surfaces completed without new errors from the modified files; the remaining `ng test` failures are pre-existing audit-log and scheduler test breakages outside the Integrations working slice. | Developer |
+| 2026-04-13 | Rebuilt the Angular frontend, started the minimal browser-facing Stella slice (`console-builder`, `router-gateway`, `platform`, `authority`, `concelier`, `integrations-web`) plus the real-provider compose lane (`gitea`, `jenkins`, `nexus`, `vault`, `docker-registry`, `minio`, `consul`, `gitlab`) and the integration fixtures. | Developer |
+| 2026-04-13 | Live browser verification confirmed the first-run setup wizard shell loads at `/setup-wizard/wizard`, but the bootstrap POST to `/api/v1/setup/sessions` returns `503`, so the wizard is not yet a complete scratch local setup path in the minimal UI slice. | Developer |
+| 2026-04-13 | Added `src/Web/StellaOps.Web/scripts/live-integrations-ui-bootstrap.mjs` as a reusable browser-driven harness that authenticates through frontdoor, creates integrations through the live onboarding UI routes, and persists evidence to `src/Web/StellaOps.Web/output/playwright/live-integrations-ui-bootstrap.json`. | Developer |
+| 2026-04-13 | The browser-driven onboarding run created all 16 local catalog entries through the UI. 13 providers converged healthy immediately; `Local GitLab Server`, `Local GitLab CI`, and `Local GitLab Container Registry` remained unhealthy because `authref://vault/gitlab#access-token` and `authref://vault/gitlab#registry-basic` were not present in Vault. | Developer |
+| 2026-04-13 | Updated `docs/INSTALL_GUIDE.md`, `docs/integrations/LOCAL_SERVICES.md`, and `devops/compose/README.md` to document the verified UI-driven path, the reusable Playwright harness, and the remaining product boundaries. | Developer |
 
 ## Decisions & Risks
 - Decision: this rerun uses the real browser UI as the operator surface and treats CLI/bootstrap helpers only as fallback evidence if the product lacks a true UI path.
 - Risk: the setup wizard backend may still persist parts of the flow only in-memory/session scope, which would make a strict UI-only bootstrap impossible without follow-on implementation work.
 - Risk: some local integrations may still require credentials to exist before the UI can complete onboarding, especially GitLab and Vault-backed secrets.
+- Decision: the reusable UI evidence path is `node src/Web/StellaOps.Web/scripts/live-integrations-ui-bootstrap.mjs`; it uses the same browser onboarding routes as an operator and keeps API usage limited to idempotent lookup plus post-create verification.
+- Risk: the current product boundary for a full UI-only local convergence is explicit, not inferred. GitLab-backed integrations still need out-of-band Vault secret seeding, and `/setup-wizard/wizard` still depends on a backend setup-session endpoint that returns `503` in the minimal local slice.
 
 ## Next Checkpoints
-- Complete the zero-state wipe and restore the platform to a reachable browser state.
-- Drive the setup wizard and integrations flows through the UI.
-- Record the exact boundary between UI-complete setup and script/API-only gaps.
+- Follow-up product work should move GitLab authref seeding into a supported UI flow.
+- Follow-up product work should make `/api/v1/setup/sessions` reliable enough for the setup wizard to become the authoritative scratch-bootstrap path.

docs/implplan/SPRINT_20260413_004_Platform_ui_only_setup_bootstrap_closure.md

@@ -0,0 +1,132 @@
+# Sprint 20260413-004 -- UI-Only Setup Bootstrap Closure
+
+## Topic & Scope
+- Close the gap between the current browser-driven onboarding demo path and a production-grade UI bootstrap flow.
+- Split machine/bootstrap concerns from tenant/onboarding concerns so the UI owns only the parts that can be truthfully provisioned from a running control plane.
+- Fix the current gateway and setup-backend defects that make `/setup-wizard/wizard` fail even though the Platform setup endpoints themselves are implemented.
+- Introduce a proper secrets staging and authref-binding flow so GitLab-class integrations can be completed from the UI without out-of-band Vault seeding.
+- Working directory: `.`.
+- Cross-module edits are expected in `devops/compose/`, `src/Platform/`, `src/Integrations/`, `src/Cli/`, and `src/Web/`.
+- Expected evidence: live frontdoor probes, targeted backend/frontend tests, Playwright evidence, and updated operator docs.
+
+## Dependencies & Concurrency
+- Required docs: `docs/setup/setup-wizard-ux.md`, `docs/INSTALL_GUIDE.md`, `docs/integrations/LOCAL_SERVICES.md`, `docs/modules/platform/architecture-overview.md`, `src/Web/StellaOps.Web/AGENTS.md`.
+- Builds on [SPRINT_20260413_003_Web_ui_driven_local_setup_rerun.md](/C:/dev/New%20folder/git.stella-ops.org/docs/implplan/SPRINT_20260413_003_Web_ui_driven_local_setup_rerun.md), which established the current UI boundary with live evidence.
+- Safe parallelism:
+  - Gateway routing and smoke coverage can proceed independently first.
+  - Setup backend persistence/provisioning can proceed in parallel with UI state cleanup only after the route defect is fixed.
+  - Secret staging/authref work must align Platform and Integrations contracts before FE wiring goes DOING.
+
+## Documentation Prerequisites
+- `docs/setup/setup-wizard-ux.md`
+- `docs/INSTALL_GUIDE.md`
+- `docs/integrations/LOCAL_SERVICES.md`
+- `docs/modules/platform/architecture-overview.md`
+- `src/Web/StellaOps.Web/AGENTS.md`
+
+## Delivery Tracker
+
+### BOOTSTRAP-001 - Fix frontdoor dispatch for setup endpoints
+Status: DONE
+Dependency: none
+Owners: Developer / QA
+Task description:
+- The current gateway route for `/api/v1/setup` matches only the exact path, so `/api/v1/setup/sessions` falls through to the generic `^/api/v1/([^/]+)(.*)` route and the gateway tries to dispatch to a non-existent `setup` microservice.
+- Replace the current exact-path rule with a prefix-aware route that sends `/api/v1/setup*` to `platform`, and add a smoke check that proves the frontdoor path reaches the Platform setup endpoints.
+
+Completion criteria:
+- [x] `https://stella-ops.local/api/v1/setup/sessions` is routed to `platform` instead of a synthetic `setup` microservice.
+- [x] A live smoke test covers both `GET /api/v1/setup/sessions` and `POST /api/v1/setup/sessions` through the frontdoor.
+- [x] Docs and sprint evidence record the routing fix and the previous failure mode.
+
+### BOOTSTRAP-002 - Turn setup sessions into real provisioning state, not optimistic UI/session state
+Status: DONE
+Dependency: BOOTSTRAP-001
+Owners: Developer
+Task description:
+- The current `PlatformSetupService` kept setup sessions in an in-memory store and returned placeholder pass results. The wizard therefore tracked progress, but it did not act as the authority for real system configuration.
+- Replace the ephemeral session model with persisted setup state and explicit per-step draft/provision/apply semantics. Required steps must reflect real subsystem state, not optimistic client-side transitions.
+- `test-connection` must stay a probe. It must never be treated as step completion. Completion must happen only after an explicit backend apply/provision operation and a follow-up validation result.
+
+Completion criteria:
+- [x] Setup session state survives service restarts and can be resumed truthfully.
+- [x] Step execution uses real validations and real persisted changes rather than placeholder pass results.
+- [x] `Finalize` marks setup complete only after required steps have actually converged.
+- [x] Targeted backend tests cover resume, restart persistence, failed apply, and finalize semantics.
+
+### BOOTSTRAP-003 - Separate control-plane bootstrap from tenant onboarding
+Status: DONE
+Dependency: BOOTSTRAP-002
+Owners: Product Manager / Developer / Documentation
+Task description:
+- In real deployments, setup from scratch has two different scopes:
+  1. control-plane bootstrap: database, cache, migrations, authority reachability, admin bootstrap, crypto primitives
+  2. tenant onboarding: integrations, feeds, environments, agents, branding, notifications
+- The wizard mixed these concerns into one linear flow. The correct implementation keeps infrastructure/bootstrap verification in the setup wizard and moves repeatable tenant-scoped operations into tenant onboarding surfaces backed by normal authenticated APIs.
+
+Completion criteria:
+- [x] The product flow distinguishes one-time platform bootstrap from repeatable tenant onboarding.
+- [x] Required bootstrap steps are only the steps that can be truthfully owned by a running control plane.
+- [x] Tenant-scoped setup work reuses the existing Integration Hub / platform setup surfaces instead of duplicating logic in the bootstrap wizard.
+- [x] Operator docs describe the boundary explicitly.
+
+### BOOTSTRAP-004 - Add UI-managed secret staging and authref binding
+Status: DONE
+Dependency: BOOTSTRAP-002
+Owners: Developer / Security / Documentation
+Task description:
+- The integrations UI stored only `authRefUri` on the connector, while the Integrations service only resolved authrefs; it did not provide a contract for creating secret material. This is why GitLab worked only after out-of-band Vault writes.
+- Add a backend contract that lets the UI submit secret material to the configured secret authority, receive or confirm the resulting authref path, and bind that authref to the integration without ever persisting the raw secret in the integration catalog.
+- The local dev implementation can target dev Vault first, but the contract remains provider-agnostic so production secret authorities fit the same UX.
+
+Completion criteria:
+- [x] The UI can create and bind GitLab-class credentials without a separate script or manual Vault write.
+- [x] The integration catalog continues to store only `authref://...` references, never raw secrets.
+- [x] Secret staging has audit events, least-privilege policies, and clear failure messages.
+- [x] Playwright evidence path now supports GitLab SCM + CI + registry convergence through inline secret staging when operator-supplied credentials are available.
+
+### BOOTSTRAP-005 - Remove optimistic FE completion semantics from the setup wizard
+Status: DONE
+Dependency: BOOTSTRAP-002
+Owners: Developer / QA
+Task description:
+- The Angular wizard marked steps completed locally after `testConnection()` and could also skip pending optional steps on navigation without a server-authoritative step transition.
+- Rework the frontend so the step UI is a projection of backend state. Local draft edits can exist client-side, but progress, completion, skip state, and next-step availability must come from backend transitions.
+
+Completion criteria:
+- [x] `Test Connection` updates only probe state, not completion state.
+- [x] Step completion and skip state are reloaded from backend session state after every mutation.
+- [x] Frontend tests cover the probe-succeeds-but-step-is-not-yet-applied case.
+- [x] Playwright flow proves refresh/reload does not lose truthful wizard state.
+
+## Execution Log
+| Date (UTC) | Update | Owner |
+| --- | --- | --- |
+| 2026-04-13 | Sprint created after the UI-driven local rerun proved that the Integrations Hub can create connectors through the browser, but the setup wizard and GitLab-backed flows still stop short of a true UI-only bootstrap. | Planning |
+| 2026-04-13 | Verified that `POST /api/v1/setup/sessions` succeeds directly against `http://platform.stella-ops.local/api/v1/setup/sessions`, while the same path through `https://stella-ops.local/api/v1/setup/sessions` returned `503 Target microservice unavailable` because the gateway dispatched to synthetic microservice `setup` instead of `platform`. | Developer |
+| 2026-04-13 | Code inspection confirmed three architectural gaps to close in order: exact-path gateway routing for `/api/v1/setup`, in-memory/mock provisioning semantics in `PlatformSetupService`, and missing UI-to-secret-authority write flow for authref-backed integrations. | Developer |
+| 2026-04-13 | Fixed `devops/compose/router-gateway-local.json` so `/api/v1/setup*` routes to `platform` as a regex prefix instead of falling through to the generic `^/api/v1/([^/]+)(.*)` microservice matcher. Added the route to `devops/compose/openapi_routeprefix_smoke.csv` for regression coverage. | Developer |
+| 2026-04-13 | After moving the setup route above the generic API catch-all and restarting `stellaops-router-gateway`, live frontdoor probes returned `200 GET /api/v1/setup/sessions` and `201 POST /api/v1/setup/sessions`, closing the routing defect. | Developer |
+| 2026-04-14 | Completed BOOTSTRAP-002 with persisted installation-scoped setup state in `platform.setup_sessions`, structured non-500 error handling for expected setup failures, and backend coverage for restart persistence, failed apply, and finalize convergence semantics. | Developer |
+| 2026-04-14 | Completed BOOTSTRAP-003/005 by constraining the live wizard to the five control-plane steps (`Database`, `Cache`, `Migrations`, `Admin`, `Crypto`), documenting tenant onboarding on `/setup/*`, and adding `src/Web/StellaOps.Web/scripts/live-setup-wizard-state-truth-check.mjs` to prove forced restart, probe-without-completion, apply advancement, and reload persistence through the authenticated frontdoor. | Developer |
+| 2026-04-14 | Added the Secret Authority API boundary on Integrations, CLI support for listing targets and staging bundles, and UI wiring that stages GitLab-class credentials inline before the integration create call binds the returned `authref://...` URI. | Developer |
+| 2026-04-14 | Updated `src/Web/StellaOps.Web/scripts/live-integrations-ui-bootstrap.mjs` so the GitLab lane can exercise inline secret staging through the browser when `STELLAOPS_UI_BOOTSTRAP_GITLAB_ACCESS_TOKEN` and `STELLAOPS_UI_BOOTSTRAP_GITLAB_REGISTRY_BASIC` are supplied. | Developer |
+| 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 |
+
+## 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.
+- Decision: `Test Connection` is a diagnostic probe, not a provisioning action. The product should never let successful probes masquerade as completed setup.
+- 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: 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.
+- Risk: if the gateway route fix is not covered by frontdoor smoke tests, the same bug can regress silently because direct service probes still pass.
+- Risk: local frontend changes do not become live until the rebuilt Angular bundle is copied into `compose_console-dist` or the dev-ui override is active; otherwise browser verification can observe stale UI behavior.
+- Risk: the live browser GitLab proof now runs green, but reruns still depend on real operator-supplied secret values; the Playwright harness expects those values through environment variables rather than minting them itself.
+
+## Next Checkpoints
+- Triage the remaining optional `stella-assistant` tips `503` on `/setup-wizard/wizard` separately from the now-green bootstrap flow.