Update docs, sprint plans, and compose configuration
Add 12 new sprint files (Integrations, Graph, JobEngine, FE, Router, AdvisoryAI), archive completed scheduler UI sprint, update module architecture docs (router, graph, jobengine, web, integrations), and add Gitea entrypoint script for local dev. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -123,10 +123,16 @@ The `CircuitBreakerService` implements the circuit breaker pattern for downstrea
|
||||
- `GET /api/v1/release-orchestrator/dashboard` — control-plane dashboard payload (pipeline, pending approvals, active deployments, recent releases).
|
||||
- `POST /api/v1/release-orchestrator/promotions/{id}/approve` — approve a pending promotion from dashboard context.
|
||||
- `POST /api/v1/release-orchestrator/promotions/{id}/reject` — reject a pending promotion from dashboard context.
|
||||
- `GET /api/v1/release-orchestrator/deployments` plus detail/log/event/metric endpoints and lifecycle actions (`pause`, `resume`, `cancel`, `rollback`, target `retry`) provide the release deployment monitoring surface used by the Console.
|
||||
- `POST /api/v1/release-orchestrator/deployments` creates a live deployment run for a single target environment using canonical strategies `rolling | blue_green | canary | all_at_once`.
|
||||
- `GET /api/v1/release-orchestrator/deployments` plus detail/log/event/metric endpoints and lifecycle actions (`pause`, `resume`, `cancel`, `rollback`, target `retry`) provide the release deployment monitoring surface used by the Console. The compatibility implementation is backed by persisted state in `orchestrator.compatibility_deployments`, with seed rows inserted per tenant only as bootstrap data.
|
||||
- `GET /api/v1/release-orchestrator/evidence` plus `verify`, `export`, `raw`, and `timeline` routes provide deterministic evidence inspection and export for offline audit flows.
|
||||
- Compatibility aliases are exposed for legacy clients under `/api/release-orchestrator/*`.
|
||||
|
||||
Compatibility deployment persistence notes:
|
||||
- Startup migration `011_compatibility_deployments.sql` creates the compatibility deployment table automatically as part of the normal JobEngine migration host.
|
||||
- The WebService resolves `IDeploymentCompatibilityStore` through DI: PostgreSQL when JobEngine persistence is configured, in-memory fallback otherwise.
|
||||
- Configuration precedence is explicit: `JobEngine:Database:ConnectionString` wins when provided, while legacy `Orchestrator:Database:ConnectionString` remains a fallback for hosts that have not yet moved to the JobEngine section.
|
||||
|
||||
All responses include deterministic timestamps, job digests, and DSSE signature fields for offline reconciliation.
|
||||
|
||||
## 5) Observability
|
||||
|
||||
Reference in New Issue
Block a user