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>
This commit is contained in:
@@ -4,7 +4,7 @@
|
||||
|
||||
**Status:** Active Development (backend substantially implemented; API surface layer in progress)
|
||||
|
||||
> **Implementation reality (updated 2026-04-13):** The backend is substantially complete with 140,000+ lines of production code across 49 projects. Core libraries (Release, Promotion, Deployment, Workflow, Evidence, PolicyGate, Progressive, Federation, Compliance) are implemented with comprehensive tests (283 test files, 37K lines). Six agent types are operational (Compose, Docker, SSH, WinRM, ECS, Nomad). Compatibility HTTP surfaces now exist across Platform, JobEngine, and Scanner for environment management, deployment monitoring, evidence inspection, dashboard promotion decisions, and registry search. The standalone WebApi owns and auto-migrates the `scripts` PostgreSQL schema used by `/api/v2/scripts`, and the scripts compatibility endpoint now evaluates persisted script metadata, declared variables, dependency inventory, target metadata, and available secrets instead of returning a fabricated success response. **Remaining gaps:** the dedicated Release Orchestrator WebApi host is still incomplete, and many compatibility surfaces still rely on in-memory storage outside the scripts catalog and audit/first-signal persistence.
|
||||
> **Implementation reality (updated 2026-04-14):** The backend is substantially complete with 140,000+ lines of production code across 49 projects. Core libraries (Release, Promotion, Deployment, Workflow, Evidence, PolicyGate, Progressive, Federation, Compliance) are implemented with comprehensive tests (283 test files, 37K lines). Six agent types are operational (Compose, Docker, SSH, WinRM, ECS, Nomad). Compatibility HTTP surfaces now exist across Platform, JobEngine, and Scanner for environment management, deployment monitoring, evidence inspection, dashboard promotion decisions, and registry search. The standalone WebApi now owns `/api/v1/release-orchestrator/environments`, `/targets`, and `/freeze-windows` for the environment-management slice, with startup migrations wired into the `release` schema; Platform's no-PostgreSQL runtime now proxies this owning API instead of falling back to local in-memory environment stores. The standalone WebApi also owns and auto-migrates the `scripts` PostgreSQL schema used by `/api/v2/scripts`; that surface now exposes full entry-point/dependency/version metadata, emits `X-Total-Count` for list parity, accepts `script:read` / `script:write` alongside the older orchestrator scopes, and evaluates compatibility against persisted script metadata, declared variables, dependency inventory, target metadata, and available secrets instead of returning a fabricated success response. Platform's no-PostgreSQL scripts path now proxies this owning API instead of falling back to a local in-memory catalog. The real environment-management UI is now reachable at `/releases/environments`, with live authenticated detail/settings/targets/freeze-window flows backed by the owning persisted API; the older legacy release-management entry points redirect into that screen. The live `/releases/deployments` route now reads persisted state from the owning `release_orchestrator.deployments` table and survives service restarts instead of seeding fake compatibility rows on first access. **Remaining gaps:** the dedicated Release Orchestrator WebApi host is still incomplete, and some legacy compatibility surfaces still need full execution-engine backing rather than compatibility projections.
|
||||
|
||||
## Overview
|
||||
|
||||
|
||||
Reference in New Issue
Block a user