consolidation of some of the modules, localization fixes, product advisories work, qa work

This commit is contained in:
master
2026-03-05 03:54:22 +02:00
parent 7bafcc3eef
commit 8e1cb9448d
3878 changed files with 72600 additions and 46861 deletions

View File

@@ -0,0 +1,110 @@
# Consolidation Decision Ledger
> **Last updated:** 2026-03-04
> **Owner:** Sprint 218 (DOCS: Consolidation Decision Finalization)
> **Wave:** Microservices Consolidation Wave 1 (Feb-Mar 2026)
This document records the final outcome of every consolidation sprint in the first consolidation wave. Each sprint was evaluated for source-level consolidation (moving source directories under a parent module) and schema-level consolidation (merging DbContexts). In all cases where consolidation proceeded, only source consolidation was executed; schema merges were rejected to preserve security boundaries and avoid blast-radius expansion.
---
## Outcome Legend
| Outcome | Meaning |
|---------|---------|
| **Proceed (done)** | Source consolidation completed. Code moved under parent module. |
| **Boundary-preserved** | Evaluated and deliberately kept as separate modules. No consolidation. |
| **Deferred** | Consolidation approved in principle but deferred to a future wave. |
| **Canceled** | Consolidation evaluated and rejected. Will not proceed. |
| **No-op** | Not applicable to the consolidation wave. |
| **Completed separately** | Work done outside the consolidation wave. |
---
## Complete Outcome Table
| Sprint | ID | Description | Outcome | Sprint File |
|--------|----|-------------|---------|-------------|
| Gateway deletion | 200 | Delete `src/Gateway/`; Router is canonical | **Proceed (done)** | [`SPRINT_20260225_200_Platform_gateway_deletion.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_200_Platform_gateway_deletion.md) |
| Scanner absorb Cartographer | 201 | Move Cartographer under Scanner | **Proceed (done)** | [`SPRINT_20260225_201_Scanner_absorb_cartographer.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_201_Scanner_absorb_cartographer.md) |
| BinaryIndex absorb Symbols | 202 | Move Symbols under BinaryIndex | **Proceed (done)** | [`SPRINT_20260225_202_BinaryIndex_absorb_symbols.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_202_BinaryIndex_absorb_symbols.md) |
| Concelier absorb Feedser/Excititor | 203 | Move Feedser and Excititor under Concelier | **Proceed (done)** | [`SPRINT_20260225_203_Concelier_absorb_feedser_excititor.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_203_Concelier_absorb_feedser_excititor.md) |
| Attestor absorb Signer/Provenance | 204 | Move Signer and Provenance under Attestor | **Proceed (done)** | [`SPRINT_20260225_204_Attestor_absorb_signer_provenance.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_204_Attestor_absorb_signer_provenance.md) |
| VEX consolidation (VexHub/VexLens) | 205 | Consolidate VexHub and VexLens | **Deferred** -- future wave | _(no sprint file; deferred before sprint creation)_ |
| Policy/Unknowns boundary | 206 | Evaluate Policy absorbing Unknowns | **Boundary-preserved** | [`SPRINT_20260225_206_Policy_absorb_unknowns.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_206_Policy_absorb_unknowns.md) |
| Findings absorb RiskEngine/VulnExplorer | 207 | Move RiskEngine and VulnExplorer under Findings | **Proceed (done)** | [`SPRINT_20260225_207_Findings_absorb_riskengine_vulnexplorer.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_207_Findings_absorb_riskengine_vulnexplorer.md) |
| Orchestrator absorb Scheduler/TaskRunner/PacksRegistry | 208 | Move Scheduler, TaskRunner, PacksRegistry under Orchestrator | **Proceed (done)** | [`SPRINT_20260225_208_Orchestrator_absorb_scheduler_taskrunner_packsregistry.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_208_Orchestrator_absorb_scheduler_taskrunner_packsregistry.md) |
| Notify/Notifier boundary | 209 | Evaluate Notify absorbing Notifier | **Boundary-preserved** | [`SPRINT_20260225_209_Notify_absorb_notifier.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_209_Notify_absorb_notifier.md) |
| Timeline absorb TimelineIndexer | 210 | Move TimelineIndexer under Timeline | **Proceed (done)** | [`SPRINT_20260225_210_Timeline_absorb_timelineindexer.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_210_Timeline_absorb_timelineindexer.md) |
| ExportCenter/AirGap boundary | 211 | Evaluate ExportCenter absorbing Mirror and AirGap | **Boundary-preserved** | [`SPRINT_20260225_211_ExportCenter_absorb_mirror_airgap.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_211_ExportCenter_absorb_mirror_airgap.md) |
| Tools absorb Bench/Verifier/Sdk/DevPortal | 212 | Move Bench, Verifier, Sdk, DevPortal under Tools | **Proceed (done)** | [`SPRINT_20260225_212_Tools_absorb_bench_verifier_sdk_devportal.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_212_Tools_absorb_bench_verifier_sdk_devportal.md) |
| AdvisoryAI absorb OpsMemory | 213 | Move OpsMemory under AdvisoryAI | **Proceed (done)** | [`SPRINT_20260225_213_AdvisoryAI_absorb_opsmemory.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_213_AdvisoryAI_absorb_opsmemory.md) |
| Integrations absorb Extensions | 214 | Move Extensions under Integrations | **Proceed (done)** | [`SPRINT_20260225_214_Integrations_absorb_extensions.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_214_Integrations_absorb_extensions.md) |
| SmRemote standalone | 215 | SmRemote standalone evaluation | **No-op** in consolidation wave | _(no sprint file; SmRemote remains standalone)_ |
| Authority absorb IssuerDirectory | 216 | Move IssuerDirectory under Authority | **Proceed (done)** | [`SPRINT_20260225_216_Authority_absorb_issuerdirectory.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_216_Authority_absorb_issuerdirectory.md) |
| Orphan library cleanup | 217 | Archive AdvisoryLens and Resolver | **Proceed (done)** | [`SPRINT_20260225_217_Platform_orphan_library_cleanup.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_217_Platform_orphan_library_cleanup.md) |
| Consolidation docs finalization | 218 | Final documentation sweep | **Proceed (done)** | [`SPRINT_20260225_218_DOCS_consolidation_final_update.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_218_DOCS_consolidation_final_update.md) |
| EF compiled model generation | 219 | EF compiled model pre-requisite | **Completed separately** | _(completed outside consolidation wave)_ |
| SbomService absorption | 220 | Evaluate SbomService merge | **Canceled** -- decision not to merge | _(canceled before sprint creation)_ |
| Orchestrator domain rename | 221 | Rename Orchestrator to JobEngine | **Proceed (done)** | [`SPRINT_20260225_221_Orchestrator_domain_rename.md`](../../docs-archived/implplan/2026-03-04-completed-sprints/SPRINT_20260225_221_Orchestrator_domain_rename.md) |
---
## Schema Merge Decisions (All Rejected)
Every consolidation sprint evaluated whether DbContexts should be merged in addition to source consolidation. In all cases, schema merges were **rejected**. The common rationale: merging DbContexts widens the blast radius of credential compromise and couples unrelated write patterns.
| Domain | Decision | Rationale |
|--------|----------|-----------|
| Orchestrator + Scheduler | No merge | `OrchestratorDbContext` (39 entities) and `SchedulerDbContext` (11 entities) have `Jobs`/`JobHistory` name collisions with incompatible semantics. |
| Authority + IssuerDirectory | No merge | `AuthorityDbContext` manages passwords, MFA, tokens. Merging would expose authentication internals to issuer metadata code paths. |
| Concelier + Excititor + Feedser | No merge | Three DbContexts (49 entities, 5 schemas) have distinct write lifecycles. Schema isolation is a feature. |
| Attestor + Signer | No merge | Security boundary between key material and attestation evidence is deliberate. |
| Policy + Unknowns | No merge | `UnknownsDbContext` retains independent schema ownership. Boundary preserved. |
| ExportCenter + AirGap | No merge | AirGap has 14+ external consumers vs ExportCenter's 2. Asymmetric coupling makes merge a poor tradeoff. |
| SbomService | Canceled | Decision not to merge SbomService into any other module. |
---
## Post-Consolidation Module Layout
After all consolidation sprints, the canonical module layout is:
| Module | Source Path | Notes |
|--------|------------|-------|
| Authority | `src/Authority/` | Now includes IssuerDirectory (Sprint 216) |
| Scanner | `src/Scanner/` | Now includes Cartographer (Sprint 201) |
| BinaryIndex | `src/BinaryIndex/` | Now includes Symbols (Sprint 202) |
| Concelier | `src/Concelier/` | Now includes Feedser and Excititor (Sprint 203) |
| Attestor | `src/Attestor/` | Now includes Signer and Provenance (Sprint 204) |
| Findings | `src/Findings/` | Now includes RiskEngine and VulnExplorer (Sprint 207) |
| JobEngine | `src/JobEngine/` | Now includes Scheduler, TaskRunner, PacksRegistry (Sprint 208); renamed from Orchestrator (Sprint 221) |
| Timeline | `src/Timeline/` | Now includes TimelineIndexer (Sprint 210) |
| Tools | `src/Tools/` | Now includes Bench, Verifier, Sdk, DevPortal (Sprint 212) |
| AdvisoryAI | `src/AdvisoryAI/` | Now includes OpsMemory (Sprint 213) |
| Integrations | `src/Integrations/` | Now includes Extensions (Sprint 214) |
### Preserved Boundaries (no consolidation)
| Module A | Module B | Sprint | Rationale |
|----------|----------|--------|-----------|
| Policy | Unknowns | 206 | Distinct domain ownership, separate DbContexts |
| Notify | Notifier | 209 | Library vs. host application boundary |
| ExportCenter | AirGap | 211 | Asymmetric coupling, blast radius |
### Deleted / Archived
| Item | Sprint | Action |
|------|--------|--------|
| `src/Gateway/` | 200 | Deleted (Router is canonical) |
| AdvisoryLens library | 217 | Archived |
| Resolver library | 217 | Archived |
### Deferred / Canceled
| Item | Sprint | Status |
|------|--------|--------|
| VexHub/VexLens consolidation | 205 | Deferred to future wave |
| SbomService absorption | 220 | Canceled |
| SmRemote | 215 | No-op (remains standalone) |

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,100 @@
# Consolidation Investigation: WebService Function and Database Matrix (2026-03-05)
## Scope
- Source scan of all `*.WebService.csproj` under `src/`.
- This matrix captures webservice functional surface and the persistence backing currently wired in code.
- Inventory size: **31 webservices** across **23 domains/modules**.
## Domain Summary
| Domain | WebServices | Services | Persistence Modes |
| --- | ---: | --- | --- |
| AdvisoryAI | 2 | AdvisoryAI, OpsMemory | postgres |
| Attestor | 2 | Attestor, Signer | postgres |
| Authority | 1 | IssuerDirectory | postgres |
| BinaryIndex | 1 | BinaryIndex | postgres |
| Concelier | 2 | Concelier, Excititor | postgres |
| Doctor | 1 | Doctor | in-memory |
| EvidenceLocker | 1 | EvidenceLocker | postgres |
| ExportCenter | 1 | ExportCenter | postgres |
| Findings | 2 | Findings.Ledger, RiskEngine | in-memory, postgres |
| Integrations | 1 | Integrations | postgres |
| JobEngine | 4 | JobEngine, PacksRegistry, Scheduler, TaskRunner | file-backed, postgres |
| Notifier | 1 | Notifier | postgres |
| Notify | 1 | Notify | postgres |
| Platform | 1 | Platform | postgres |
| ReachGraph | 1 | ReachGraph | postgres |
| Remediation | 1 | Remediation | postgres |
| Replay | 1 | Replay | in-memory |
| Router | 1 | Gateway | no-persistence |
| Scanner | 1 | Scanner | postgres |
| Timeline | 2 | Timeline, TimelineIndexer | postgres |
| Unknowns | 1 | Unknowns | postgres |
| VexHub | 1 | VexHub | postgres |
| VexLens | 1 | VexLens | postgres |
## WebService Matrix
| Domain | WebService | Functions Served | DB Used | Evidence |
| --- | --- | --- | --- | --- |
| AdvisoryAI | AdvisoryAI | Endpoints: Attestation, Chat, EvidencePack, KnowledgeSearch (+5 more); routes: advisory-ai, chat, runs, search | AdvisoryAiDataSource, AdvisoryAiDbContext | src/AdvisoryAI/StellaOps.AdvisoryAI.WebService/Program.cs; src/AdvisoryAI/StellaOps.AdvisoryAI/Storage/EfCore/Context/AdvisoryAiDbContext.cs |
| AdvisoryAI | OpsMemory | Endpoints: OpsMemory; routes: opsmemory | PostgreSQL via NpgsqlDataSource + PostgresOpsMemoryStore (no EF DbContext) | src/AdvisoryAI/StellaOps.OpsMemory.WebService/Program.cs; src/AdvisoryAI/__Libraries/StellaOps.OpsMemory/Storage/PostgresOpsMemoryStore.cs |
| Attestor | Attestor | Endpoints: Anchors, AttestorWebService, Bundles, Chain (+7 more); routes: attestor, watchlist | ProofChainDbContext | src/Attestor/StellaOps.Attestor/StellaOps.Attestor.WebService/Program.cs; src/Attestor/__Libraries/StellaOps.Attestor.Persistence/ProofChainDbContext.cs |
| Attestor | Signer | Endpoints: Ceremony, KeyRotation, Signer; routes: anchors, ceremonies, signer | KeyManagementDbContext | src/Attestor/StellaOps.Signer/StellaOps.Signer.WebService/Program.cs; src/Attestor/__Libraries/StellaOps.Signer.KeyManagement/EfCore/Context/KeyManagementDbContext.cs |
| Authority | IssuerDirectory | Endpoints: Issuer, IssuerKey, IssuerTrust; routes: issuer-directory | IssuerDirectoryDataSource, IssuerDirectoryDbContext | src/Authority/StellaOps.IssuerDirectory/StellaOps.IssuerDirectory.WebService/Program.cs; src/Authority/__Libraries/StellaOps.IssuerDirectory.Persistence/EfCore/Context/IssuerDirectoryDbContext.cs |
| BinaryIndex | BinaryIndex | Endpoints: BinaryIndexOps, GoldenSet, PatchCoverage, Resolution | BinaryIndexDbContext, BinaryIndexPersistenceDbContext, GoldenSetDbContext | src/BinaryIndex/StellaOps.BinaryIndex.WebService/Program.cs; src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.GoldenSet/EfCore/Context/GoldenSetDbContext.cs |
| Concelier | Concelier | Endpoints: FeedMirrorManagement; routes: advisory-sources, canonical, concelier, federation (+3 more) | ConcelierDataSource, ConcelierDbContext | src/Concelier/StellaOps.Concelier.WebService/Program.cs; src/Concelier/__Libraries/StellaOps.Concelier.Persistence/EfCore/Context/ConcelierDbContext.cs |
| Concelier | Excititor | Endpoints: Attestation, Evidence, Ingest, Linkset (+6 more); routes: airgap, attestations, excititor, risk (+1 more) | ExcititorDataSource, ExcititorDbContext | src/Concelier/StellaOps.Excititor.WebService/Program.cs; src/Concelier/__Libraries/StellaOps.Excititor.Persistence/EfCore/Context/ExcititorDbContext.cs |
| Doctor | Doctor | Endpoints: Doctor, Timestamping; routes: doctor | No service DB; in-memory report storage | src/Doctor/StellaOps.Doctor.WebService/Program.cs |
| EvidenceLocker | EvidenceLocker | Evidence ingest/scoring, snapshots, bundle download/portable package, verify, legal hold, plus export/verdict/evidence-thread adapters | EvidenceLockerDbContext | src/EvidenceLocker/StellaOps.EvidenceLocker/StellaOps.EvidenceLocker.WebService/Program.cs; src/EvidenceLocker/StellaOps.EvidenceLocker/StellaOps.EvidenceLocker.Infrastructure/EfCore/Context/EvidenceLockerDbContext.cs |
| ExportCenter | ExportCenter | Endpoints: Attestation, AuditBundle, ExceptionReport, ExportApi (+6 more); routes: audit-bundles, exports, incidents, lineage (+4 more) | ExportCenterDbContext | src/ExportCenter/StellaOps.ExportCenter/StellaOps.ExportCenter.WebService/Program.cs; src/ExportCenter/StellaOps.ExportCenter/StellaOps.ExportCenter.Infrastructure/EfCore/Context/ExportCenterDbContext.cs |
| Findings | Findings.Ledger | Endpoints: Backport, EvidenceGraph, FindingSummary, ReachabilityMap (+4 more); routes: findings, scoring | FindingsLedgerDbContext | src/Findings/StellaOps.Findings.Ledger.WebService/Program.cs; src/Findings/StellaOps.Findings.Ledger/EfCore/Context/FindingsLedgerDbContext.cs |
| Findings | RiskEngine | Endpoints: ExploitMaturity; routes: exploit-maturity | No service DB; InMemoryRiskScoreResultStore | src/Findings/StellaOps.RiskEngine.WebService/Program.cs; src/Findings/__Libraries/StellaOps.RiskEngine.Infrastructure/Stores/InMemoryRiskScoreResultStore.cs |
| Integrations | Integrations | Endpoints: Integration; routes: integrations | IntegrationDbContext | src/Integrations/StellaOps.Integrations.WebService/Program.cs; src/Integrations/__Libraries/StellaOps.Integrations.Persistence/IntegrationDbContext.cs |
| JobEngine | JobEngine | Endpoints: Approval, Audit, CircuitBreaker, Dag (+21 more); routes: approvals, environments, jobengine, metrics (+2 more) | JobEngineDbContext | src/JobEngine/StellaOps.JobEngine/StellaOps.JobEngine.WebService/Program.cs; src/JobEngine/StellaOps.JobEngine/StellaOps.JobEngine.Infrastructure/EfCore/Context/JobEngineDbContext.cs |
| JobEngine | PacksRegistry | Packs upload/list/content/provenance/manifest/signature, attestations, parity/lifecycle, mirrors sync, compliance summary, offline-seed export | No relational DB; filesystem repositories (packs/parity/lifecycle/audit/attestations/mirrors) | src/JobEngine/StellaOps.PacksRegistry/StellaOps.PacksRegistry.WebService/Program.cs; src/JobEngine/StellaOps.PacksRegistry/StellaOps.PacksRegistry.Infrastructure/FileSystem/FilePackRepository.cs |
| JobEngine | Scheduler | Endpoints: FailureSignature, Run, Schedule; routes: events, graphs, scheduler | SchedulerDataSource, SchedulerDbContext | src/JobEngine/StellaOps.Scheduler.WebService/Program.cs; src/JobEngine/StellaOps.Scheduler.__Libraries/StellaOps.Scheduler.Persistence/EfCore/Context/SchedulerDbContext.cs |
| JobEngine | TaskRunner | Run simulation/execution state/logs/artifacts/approvals/cancel, attestation APIs, incident-mode APIs, SLO breach webhook | No relational DB; filesystem stores for run state/logs/approvals/artifacts | src/JobEngine/StellaOps.TaskRunner/StellaOps.TaskRunner.WebService/Program.cs; src/JobEngine/StellaOps.TaskRunner/StellaOps.TaskRunner.Infrastructure/Execution/FilePackRunStateStore.cs |
| Notifier | Notifier | Endpoints: Escalation, Fallback, Incident, Localization (+10 more); routes: ack, escalation-policies, escalations, fallback (+13 more) | NotifyDataSource, NotifyDbContext | src/Notifier/StellaOps.Notifier/StellaOps.Notifier.WebService/Program.cs; src/Notify/__Libraries/StellaOps.Notify.Persistence/EfCore/Context/NotifyDbContext.cs |
| Notify | Notify | Rules/channels/templates CRUD, deliveries history, digests, audit trail, lock APIs, internal normalize endpoints | NotifyDataSource, NotifyDbContext | src/Notify/StellaOps.Notify.WebService/Program.cs; src/Notify/__Libraries/StellaOps.Notify.Persistence/EfCore/Context/NotifyDbContext.cs |
| Platform | Platform | Endpoints: AdministrationTrustSigningMutation, Analytics, Context, EnvironmentSettings (+19 more); routes: admin, administration, analytics, authority (+26 more) | PlatformDbContext plus read-model access to Authority/Concelier/Excititor/Scheduler/Notify/Policy contexts | src/Platform/StellaOps.Platform.WebService/Program.cs; src/Authority/__Libraries/StellaOps.Authority.Persistence/EfCore/Context/AuthorityDbContext.cs |
| ReachGraph | ReachGraph | Endpoints: CveMapping, Reachability, ReachGraph | ReachGraphDataSource, ReachGraphDbContext | src/ReachGraph/StellaOps.ReachGraph.WebService/Program.cs; src/__Libraries/StellaOps.ReachGraph.Persistence/EfCore/Context/ReachGraphDbContext.cs |
| Remediation | Remediation | Endpoints: RemediationMatch, RemediationRegistry, RemediationSource; routes: remediation | RemediationDataSource, RemediationDbContext | src/Remediation/StellaOps.Remediation.WebService/Program.cs; src/Remediation/StellaOps.Remediation.Persistence/EfCore/Context/RemediationDbContext.cs |
| Replay | Replay | Endpoints: PointInTimeQuery, VerdictReplay; routes: pit, replay | No service DB; in-memory feed snapshot blob/index stores | src/Replay/StellaOps.Replay.WebService/Program.cs; src/Replay/StellaOps.Replay.WebService/FeedSnapshotSupport.cs |
| Router | Gateway | Gateway route dispatch pipeline, authz/header enforcement, transport routing, OpenAPI aggregation | No application DB; gateway routing/middleware service | src/Router/StellaOps.Gateway.WebService/Program.cs |
| Scanner | Scanner | Endpoints: Actionables, Approval, Baseline, BatchTriage (+43 more); routes: drift, epss, github, hot-lookup (+12 more) | ScannerDbContext + ScannerSourcesDataSource + TriageDbContext (+ AuthorityDbContext path) | src/Scanner/StellaOps.Scanner.WebService/Program.cs; src/Authority/__Libraries/StellaOps.Authority.Persistence/EfCore/Context/AuthorityDbContext.cs |
| Timeline | Timeline | Endpoints: Export, Health, Replay, Timeline (+1 more); routes: audit, timeline | EventingDataSource, EventingDbContext, TimelineCoreDataSource, TimelineCoreDbContext | src/Timeline/StellaOps.Timeline.WebService/Program.cs; src/__Libraries/StellaOps.Eventing/EfCore/Context/EventingDbContext.cs |
| Timeline | TimelineIndexer | Timeline indexer API group for index status/control under /api/v1 | TimelineIndexerDataSource, TimelineIndexerDbContext | src/Timeline/StellaOps.TimelineIndexer.WebService/Program.cs; src/Timeline/__Libraries/StellaOps.TimelineIndexer.Infrastructure/EfCore/Context/TimelineIndexerDbContext.cs |
| Unknowns | Unknowns | Endpoints: GreyQueue, Unknowns; routes: grey-queue, unknowns | UnknownsDataSource, UnknownsDbContext | src/Unknowns/StellaOps.Unknowns.WebService/Program.cs; src/Unknowns/__Libraries/StellaOps.Unknowns.Persistence.EfCore/Context/UnknownsDbContext.cs |
| VexHub | VexHub | VEX ingest and distribution endpoints under /api/v1/vex | VexHubDataSource, VexHubDbContext | src/VexHub/StellaOps.VexHub.WebService/Program.cs; src/VexHub/__Libraries/StellaOps.VexHub.Persistence/EfCore/Context/VexHubDbContext.cs |
| VexLens | VexLens | VEX lens APIs for deltas/export/gating/issuer views | VexLensDataSource, VexLensDbContext | src/VexLens/StellaOps.VexLens.WebService/Program.cs; src/VexLens/StellaOps.VexLens.Persistence/EfCore/Context/VexLensDbContext.cs |
## Compose Storage Baseline (Policy Input)
- Main stack defines PostgreSQL as primary platform datastore (`devops/compose/docker-compose.stella-ops.yml` lines 71-127, `x-postgres-connection` at lines 28-30).
- Main stack defines RustFS (SeaweedFS S3 API) as object/blob storage (`devops/compose/docker-compose.stella-ops.yml` lines 162-180).
- Scanner already expresses the intended split: Postgres for metadata/state and RustFS for artifacts (`devops/compose/docker-compose.stella-ops.yml` lines 652-659 and 720-725).
- Testing stack explicitly expects Postgres drivers for PacksRegistry and TaskRunner (`devops/compose/docker-compose.testing.yml` lines 253-254 and 271-272).
## Policy Gaps (Postgres First, RustFS for Blobs)
| Service | Current Runtime Wiring | Compose Signal | Gap | Required Remediation |
| --- | --- | --- | --- | --- |
| PacksRegistry | File repositories (`src/JobEngine/StellaOps.PacksRegistry/StellaOps.PacksRegistry.WebService/Program.cs` lines 29-34) | Main compose provides `ConnectionStrings__Default` (line 1769); testing compose expects `PACKSREGISTRY__STORAGE__DRIVER=postgres` (line 253) | High | Add storage driver contract; move metadata (pack/parity/lifecycle/mirror/audit) to Postgres; keep pack/provenance/attestation payloads in RustFS/seed-fs blob path. |
| TaskRunner | File stores/readers (`src/JobEngine/StellaOps.TaskRunner/StellaOps.TaskRunner.WebService/Program.cs` lines 61,66,71,76) | Main compose provides `ConnectionStrings__Default` (line 1150); testing compose expects `TASKRUNNER__STORAGE__DRIVER=postgres` (line 271) | High | Add Postgres storage driver for run state/logs/approvals; move large artifacts to RustFS/seed-fs blob path; keep deterministic replay semantics. |
| RiskEngine | In-memory result store (`src/Findings/StellaOps.RiskEngine.WebService/Program.cs` line 21) | Main compose provides `ConnectionStrings__Default` (line 1048) | Medium-High | Implement Postgres-backed result store with deterministic ordering/query semantics; keep in-memory only for explicit test profile. |
| Replay | In-memory snapshot blob/index stores (`src/Replay/StellaOps.Replay.WebService/Program.cs` lines 61-62) | Main compose provides `ConnectionStrings__Default` (line 2037) | Medium-High | Persist replay snapshot index/state in Postgres; move snapshot blobs to RustFS/seed-fs object path. |
| OpsMemory | Postgres store exists but connection key is `ConnectionStrings:OpsMemory` with localhost fallback (`src/AdvisoryAI/StellaOps.OpsMemory.WebService/Program.cs` lines 19-20) | Main compose sets only `ConnectionStrings__Default` (line 1537) | Medium | Accept `ConnectionStrings:Default` as primary fallback or map explicit `ConnectionStrings:OpsMemory` in compose; remove localhost fallback in non-dev runtime. |
| Scanner | Postgres + RustFS split already configured (`src/Scanner` + compose lines 652-659/720-725) | Explicitly aligned in compose | None | Use as reference implementation for storage-driver conventions. |
## Sprint 312 remediation status (2026-03-05)
| Service | Implemented end state | Validation evidence |
| --- | --- | --- |
| PacksRegistry | `Storage:Driver=postgres` for metadata/state repositories; `Storage:ObjectStore:Driver=seed-fs` for pack/provenance/attestation payload bytes via `SeedFsPacksRegistryBlobStore`. | `dotnet test src/JobEngine/StellaOps.PacksRegistry.__Tests/StellaOps.PacksRegistry.Persistence.Tests/StellaOps.PacksRegistry.Persistence.Tests.csproj -v minimal` (Passed 7/7, including `PostgresBlobStorageRepositoryTests`). |
| TaskRunner | `Storage:Driver=postgres` for run state/log/approval; `Storage:ObjectStore:Driver=seed-fs` for artifact payload root path. | `dotnet test src/JobEngine/StellaOps.TaskRunner.__Tests/StellaOps.TaskRunner.Persistence.Tests/StellaOps.TaskRunner.Persistence.Tests.csproj -v minimal` (Passed 4/4). |
| RiskEngine | Postgres-backed result store (`PostgresRiskScoreResultStore`) registered as production default; in-memory explicit fallback retained. | Targeted class run: `StellaOps.RiskEngine.Tests.exe -class "StellaOps.RiskEngine.Tests.PostgresRiskScoreResultStoreTests"` (Passed 2/2). Full suite still has unrelated auth harness failures. |
| Replay | Postgres snapshot index store (`PostgresFeedSnapshotIndexStore`) + seed-fs blob store (`SeedFsFeedSnapshotBlobStore`). | Targeted class run: `StellaOps.Replay.Core.Tests.exe -class "...PostgresFeedSnapshotIndexStoreTests" -class "...SeedFsFeedSnapshotBlobStoreTests"` (Passed 3/3). |
| OpsMemory | Connection precedence aligned to `ConnectionStrings:OpsMemory -> ConnectionStrings:Default`, non-development fail-fast retained. | `dotnet build src/AdvisoryAI/StellaOps.OpsMemory.WebService/StellaOps.OpsMemory.WebService.csproj -v minimal` and `dotnet test src/AdvisoryAI/__Tests/StellaOps.OpsMemory.Tests/StellaOps.OpsMemory.Tests.csproj -v minimal` (previously captured in sprint evidence). |
| Compose parity | Main/testing compose now declare explicit storage-driver keys for affected services; main compose validation fixed for `taskrunner-worker` artifact mount conflict. | `docker compose -f devops/compose/docker-compose.stella-ops.yml config` (OK), `docker compose -f devops/compose/docker-compose.testing.yml config` (OK). |
## Notes
- `DB Used` reflects runtime wiring in the current code snapshot; no consolidation merge assumptions are applied.
- Services marked file-backed/in-memory/no-persistence are currently not using EF/PostgreSQL service databases.
- Compose indicates target policy direction: Postgres-first persistence with RustFS object storage for blobs/artifacts.
- Raw extraction artifact: `docs/implplan/CONSOLIDATION_SERVICE_INVENTORY_20260305.raw.json`.

View File

@@ -1,97 +0,0 @@
# Sprint 200 - Platform: Gateway Module Deletion
## Topic & Scope
- Delete the deprecated `src/Gateway/` module — the canonical Gateway WebService already lives in `src/Router/StellaOps.Gateway.WebService/` with comments confirming "now in same module."
- Working directory: `src/Gateway/`, `src/Router/`, `docs/modules/gateway/`.
- Expected evidence: clean build of `StellaOps.Router.sln`, all Router tests pass, no dangling references.
## Dependencies & Concurrency
- No upstream sprint dependencies.
- Safe to run in parallel with all other consolidation sprints.
- This is the lowest-risk consolidation — Gateway is already dead code.
## Documentation Prerequisites
- Read `docs/modules/gateway/architecture.md` (confirms Router is canonical).
- Read `docs/modules/router/architecture.md` (confirms Gateway.WebService is hosted here).
## Delivery Tracker
### TASK-200-001 - Verify Gateway is fully superseded by Router
Status: TODO
Dependency: none
Owners: Developer
Task description:
- Compare `src/Gateway/StellaOps.Gateway.WebService/Program.cs` with `src/Router/StellaOps.Gateway.WebService/Program.cs`.
- Confirm the Router version is a superset (has all routes, middleware, config the Gateway version has).
- Check `StellaOps.Gateway.sln` — confirm it only references projects inside `src/Gateway/`.
- Search all `.csproj` files in the repo for any `ProjectReference` pointing into `src/Gateway/`.
- Search `devops/compose/` and `.gitea/` for any references to the Gateway solution or its Docker image.
Completion criteria:
- [ ] Diff report confirming Router Gateway is superset
- [ ] Zero external references to `src/Gateway/` projects
- [ ] Zero CI/Docker references to Gateway-specific builds
### TASK-200-002 - Delete src/Gateway/ and update solution
Status: TODO
Dependency: TASK-200-001
Owners: Developer
Task description:
- Remove `src/Gateway/` directory entirely.
- Remove any Gateway-specific entries from `StellaOps.sln` (the root solution).
- If `StellaOps.Gateway.sln` in `src/Gateway/` is referenced anywhere, update references to use `StellaOps.Router.sln`.
- Run `dotnet build src/Router/StellaOps.Router.sln` — must succeed.
- Run `dotnet test src/Router/StellaOps.Router.sln` — all tests must pass.
Completion criteria:
- [ ] `src/Gateway/` deleted
- [ ] Root solution updated
- [ ] Router solution builds clean
- [ ] Router tests pass
### TASK-200-003 - Update documentation
Status: TODO
Dependency: TASK-200-002
Owners: Developer
Task description:
- Move `docs/modules/gateway/` to `docs-archived/modules/gateway/`.
- Update `docs/modules/router/architecture.md` — remove any "see also Gateway" references; add a note that Gateway was consolidated into Router on 2026-02-25.
- Update `docs/INDEX.md` — remove the Gateway row from the module table, or mark it as "(archived — see Router)".
- Search `docs/**/*.md` for references to `src/Gateway/` or `modules/gateway/` and update them.
- Update `CLAUDE.md` section 1.4 if it references Gateway.
Completion criteria:
- [ ] Gateway docs archived
- [ ] Router docs updated with consolidation note
- [ ] INDEX.md updated
- [ ] No broken references to Gateway in active docs
### TASK-200-004 - Validate CLI and Web routing references
Status: TODO
Dependency: TASK-200-002
Owners: Developer
Task description:
- Audit `src/Cli/` for Gateway-specific references (`Gateway`, `/gateway`, `StellaOps.Gateway.*`). Expected from current audit: no direct CLI references.
- Validate `src/Web/StellaOps.Web/proxy.conf.json` still routes `/gateway` through Router-owned gateway handling after deleting `src/Gateway/`.
- Validate gateway-based URL composition in `src/Web/StellaOps.Web/src/app/app.config.ts` and `src/Web/StellaOps.Web/src/app/core/config/app-config.service.ts` remains unchanged.
- If any `src/Gateway/` source paths appear in CLI/Web build metadata, update them to Router-owned paths.
Completion criteria:
- [ ] CLI audit confirms zero direct `src/Gateway/` references.
- [ ] Web proxy/app-config routing verified for gateway path forwarding.
- [ ] Any stale Gateway path references removed.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
| 2026-02-25 | CLI/UI module reference audit completed and sprint rework aligned to `AUDIT_20260225_cli_ui_module_reference_matrix.md`. | Planning |
## Decisions & Risks
- Risk: Gateway may have Translations/ folder content not in Router. Mitigation: TASK-200-001 diff will catch this.
- Decision: Gateway docs are archived, not deleted — preserves historical context.
## Next Checkpoints
- Gateway deletion can be completed in a single session.

View File

@@ -1,138 +0,0 @@
# Sprint 201 - Scanner: Absorb Cartographer Module
## Topic & Scope
- Consolidate `src/Cartographer/` (1 csproj, zero external consumers) into `src/Scanner/` as `StellaOps.Scanner.Cartographer`.
- Cartographer materializes SBOM graphs for indexing — this is SBOM processing, which is Scanner's domain.
- Working directory: `src/Cartographer/`, `src/Scanner/`, `docs/modules/cartographer/`, `docs/modules/scanner/`.
- Expected evidence: clean build, all Scanner tests pass, Cartographer functionality preserved.
## Dependencies & Concurrency
- No upstream dependencies.
- Can run in parallel with other consolidation sprints except BinaryIndex+Symbols (Domain 2).
- Coordinate with Graph module if Cartographer's output contract changes.
## Documentation Prerequisites
- Read `src/Cartographer/AGENTS.md` — confirms required reading is `docs/modules/graph/architecture.md`.
- Read `docs/modules/cartographer/README.md`.
- Read `docs/modules/scanner/architecture.md` for project layout conventions.
## Delivery Tracker
### TASK-201-001 - Analyze Cartographer project structure and dependencies
Status: TODO
Dependency: none
Owners: Developer
Task description:
- Read `src/Cartographer/StellaOps.Cartographer/StellaOps.Cartographer.csproj` — list all dependencies.
- Confirm Cartographer depends on: Configuration, DependencyInjection, Policy.Engine, Auth.Abstractions, Auth.ServerIntegration.
- Verify zero external consumers: grep all `.csproj` files for `Cartographer` references outside `src/Cartographer/`.
- Document the Cartographer API surface (endpoints, ports — confirmed port 10210).
- Check if Cartographer has its own database schema/migrations.
- Check `devops/compose/` for Cartographer service definitions.
Completion criteria:
- [ ] Full dependency list documented
- [ ] Zero external consumer confirmed
- [ ] API surface documented
- [ ] Docker compose references identified
### TASK-201-002 - Move Cartographer into Scanner module
Status: TODO
Dependency: TASK-201-001
Owners: Developer
Task description:
- Create `src/Scanner/StellaOps.Scanner.Cartographer/` directory.
- Move all source files from `src/Cartographer/StellaOps.Cartographer/` into the new location.
- Rename the `.csproj` to `StellaOps.Scanner.Cartographer.csproj`.
- Update the `<RootNamespace>` and `<AssemblyName>` in the csproj.
- Update all `ProjectReference` paths within the csproj to use new relative paths.
- Move test projects: `src/Cartographer/__Tests/``src/Scanner/__Tests/StellaOps.Scanner.Cartographer.Tests/`.
- Update test csproj references.
- Add `StellaOps.Scanner.Cartographer.csproj` to `StellaOps.Scanner.sln`.
- Remove `src/Cartographer/` directory.
- Remove Cartographer entries from root `StellaOps.sln`.
Completion criteria:
- [ ] Source moved and renamed
- [ ] Test projects moved
- [ ] Scanner solution includes Cartographer
- [ ] Old Cartographer directory removed
- [ ] Root solution updated
### TASK-201-003 - Update Docker compose and CI
Status: TODO
Dependency: TASK-201-002
Owners: Developer
Task description:
- Update `devops/compose/` files — change Cartographer service image/build context to Scanner.Cartographer.
- Update `.gitea/workflows/` if any workflow references `src/Cartographer/` paths.
- Verify the Cartographer service still starts on port 10210 (preserve the API contract).
Completion criteria:
- [ ] Docker compose updated
- [ ] CI workflows updated
- [ ] Service starts and responds on expected port
### TASK-201-004 - Build and test verification
Status: TODO
Dependency: TASK-201-002
Owners: Developer
Task description:
- Run `dotnet build src/Scanner/StellaOps.Scanner.sln` — must succeed.
- Run `dotnet test src/Scanner/__Tests/StellaOps.Scanner.Cartographer.Tests/` — all tests pass.
- Run full Scanner test suite to verify no regressions.
- Run `dotnet build StellaOps.sln` from root — must succeed.
Completion criteria:
- [ ] Scanner solution builds clean
- [ ] Cartographer tests pass in new location
- [ ] Full Scanner test suite passes
- [ ] Root solution builds clean
### TASK-201-005 - Update documentation
Status: TODO
Dependency: TASK-201-004
Owners: Developer
Task description:
- Move `docs/modules/cartographer/` to `docs-archived/modules/cartographer/`.
- Add a "Cartographer (SBOM Graph Materialization)" section to `docs/modules/scanner/architecture.md`.
- Update `docs/INDEX.md` — remove Cartographer row or mark archived.
- Update `CLAUDE.md` section 1.4 if Cartographer is listed.
- Update any docs referencing `src/Cartographer/` paths to `src/Scanner/StellaOps.Scanner.Cartographer/`.
- Update `src/Scanner/AGENTS.md` to include Cartographer working directory.
Completion criteria:
- [ ] Cartographer docs archived
- [ ] Scanner architecture doc updated
- [ ] INDEX and CLAUDE.md updated
- [ ] All path references updated
### TASK-201-006 - Validate CLI and Web references for Cartographer
Status: TODO
Dependency: TASK-201-002
Owners: Developer
Task description:
- Search `src/Cli/` and `src/Web/` for `Cartographer` and `STELLAOPS_CARTOGRAPHER_URL` references.
- Expected from current audit: no direct CLI/Web source references; Cartographer wiring is currently in compose/platform environment configuration.
- If any direct CLI/Web reference exists, update it to Scanner-owned paths or remove stale module naming.
- Record the audit result in Execution Log (including explicit `none found` if no updates were required).
Completion criteria:
- [ ] CLI audit completed.
- [ ] Web audit completed.
- [ ] Any discovered references updated or explicitly recorded as none.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
| 2026-02-25 | CLI/UI module reference audit completed and sprint rework aligned to `AUDIT_20260225_cli_ui_module_reference_matrix.md`. | Planning |
## Decisions & Risks
- Decision: Cartographer keeps its own WebService (port 10210) as a separate deployable within the Scanner module. It is not merged into Scanner.WebService.
- Risk: Namespace rename may break runtime assembly loading if any reflection-based patterns reference `StellaOps.Cartographer`. Mitigation: grep for string literals containing the old namespace.
## Next Checkpoints
- Cartographer consolidation can be completed in a single session.

View File

@@ -1,151 +0,0 @@
# Sprint 202 - BinaryIndex: Absorb Symbols Module
## Topic & Scope
- Consolidate `src/Symbols/` (6 csproj: Core, Client, Infrastructure, Marketplace, Server, Bundle) into `src/BinaryIndex/` as `StellaOps.BinaryIndex.Symbols.*`.
- Symbols provides debug symbol storage and resolution — the primary consumer is BinaryIndex.DeltaSig. The other consumer is Cli.Plugins.Symbols (a thin plugin loader).
- Working directory: `src/Symbols/`, `src/BinaryIndex/`, `src/Cli/`, `docs/modules/symbols/`, `docs/modules/binary-index/`.
- Expected evidence: clean build of BinaryIndex solution, all tests pass, Symbols.Server still deploys independently.
## Dependencies & Concurrency
- No upstream dependencies.
- Can run in parallel with all other consolidation sprints except Scanner+Cartographer (Domain 2).
## Documentation Prerequisites
- Read `docs/modules/symbols/architecture.md` — note: this doc is stale (describes monolithic layout, actual code has 5 projects).
- Read `src/BinaryIndex/AGENTS.md`.
## Delivery Tracker
### TASK-202-001 - Map Symbols project structure and consumers
Status: TODO
Dependency: none
Owners: Developer
Task description:
- List all 6 Symbols csproj files and their inter-dependencies:
- Symbols.Core (leaf)
- Symbols.Client → Core
- Symbols.Infrastructure → Core
- Symbols.Marketplace (leaf)
- Symbols.Server → Core, Infrastructure, Marketplace + Authority libs
- Symbols.Bundle → Core
- Confirm external consumers:
- `BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig` → Symbols.Core
- `Cli/__Libraries/StellaOps.Cli.Plugins.Symbols` → Symbols.Core, Symbols.Client
- Check for any other consumers via grep.
- Document the Symbols.Server API surface and port.
- Check `devops/compose/` for Symbols service definition.
Completion criteria:
- [ ] Full dependency graph documented
- [ ] All consumers identified
- [ ] Server API surface and port documented
- [ ] Docker compose references identified
### TASK-202-002 - Move Symbols projects into BinaryIndex
Status: TODO
Dependency: TASK-202-001
Owners: Developer
Task description:
- Create directories under `src/BinaryIndex/`:
- `StellaOps.BinaryIndex.Symbols.Core/`
- `StellaOps.BinaryIndex.Symbols.Client/`
- `StellaOps.BinaryIndex.Symbols.Infrastructure/`
- `StellaOps.BinaryIndex.Symbols.Marketplace/`
- `StellaOps.BinaryIndex.Symbols.Server/`
- `StellaOps.BinaryIndex.Symbols.Bundle/`
- Move source files from `src/Symbols/` into new locations.
- Rename csproj files, update `<RootNamespace>` and `<AssemblyName>`.
- Update all internal `ProjectReference` paths.
- Move test projects from `src/Symbols/__Tests/` into `src/BinaryIndex/__Tests/`.
- Update test csproj references.
- Add all new csproj files to `StellaOps.BinaryIndex.sln`.
- Remove `src/Symbols/` directory.
- Remove Symbols entries from root `StellaOps.sln`.
Completion criteria:
- [ ] All 6 projects moved and renamed
- [ ] Test projects moved
- [ ] BinaryIndex solution includes all Symbols projects
- [ ] Old Symbols directory removed
- [ ] Root solution updated
### TASK-202-003 - Update external consumers
Status: TODO
Dependency: TASK-202-002
Owners: Developer
Task description:
- Update `src/BinaryIndex/__Libraries/StellaOps.BinaryIndex.DeltaSig.csproj`:
- Change `ProjectReference` from `../../../Symbols/...` to the new BinaryIndex-local path.
- Update `src/Cli/__Libraries/StellaOps.Cli.Plugins.Symbols/StellaOps.Cli.Plugins.Symbols.csproj`:
- Change `ProjectReference` paths from `..\..\..\Symbols\...` to new BinaryIndex.Symbols locations.
- Update `src/Cli/StellaOps.Cli.sln` Symbols project entries that currently point to `..\Symbols\...`.
- Search all `.csproj` and `.sln` files for remaining `Symbols` project paths and update.
- Audit `src/Web/StellaOps.Web` for direct Symbols backend route usage (`/symbols`). Expected from current audit: no dedicated Symbols API route migration required.
Completion criteria:
- [ ] BinaryIndex.DeltaSig references updated.
- [ ] Cli.Plugins.Symbols references updated.
- [ ] StellaOps.Cli.sln Symbols paths updated.
- [ ] Web Symbols route audit completed (none or updates documented).
- [ ] All external references updated.
### TASK-202-004 - Update Docker compose and CI
Status: TODO
Dependency: TASK-202-002
Owners: Developer
Task description:
- Update `devops/compose/` files for Symbols service → BinaryIndex.Symbols.Server.
- Update `.gitea/workflows/` if any reference `src/Symbols/`.
- Verify Symbols.Server still deploys on its original port.
Completion criteria:
- [ ] Docker compose updated
- [ ] CI workflows updated
- [ ] Server deploys on expected port
### TASK-202-005 - Build and test verification
Status: TODO
Dependency: TASK-202-003
Owners: Developer
Task description:
- `dotnet build src/BinaryIndex/StellaOps.BinaryIndex.sln` — must succeed.
- Run all BinaryIndex tests including new Symbols tests.
- `dotnet build StellaOps.sln` — root solution must succeed.
- Run Cli.Plugins.Symbols tests if they exist.
Completion criteria:
- [ ] BinaryIndex solution builds clean
- [ ] All tests pass
- [ ] Root solution builds clean
### TASK-202-006 - Update documentation
Status: TODO
Dependency: TASK-202-005
Owners: Developer
Task description:
- Move `docs/modules/symbols/` to `docs-archived/modules/symbols/`.
- Add a "Symbols (Debug Symbol Resolution)" section to `docs/modules/binary-index/architecture.md`.
- Rewrite the section to match the actual 5-project structure (the old symbols doc was stale).
- Update `docs/INDEX.md`.
- Update `CLAUDE.md` section 1.4.
- Update path references in all docs.
Completion criteria:
- [ ] Symbols docs archived
- [ ] BinaryIndex architecture updated with accurate Symbols section
- [ ] INDEX and CLAUDE.md updated
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
| 2026-02-25 | CLI/UI module reference audit completed and sprint rework aligned to `AUDIT_20260225_cli_ui_module_reference_matrix.md`. | Planning |
## Decisions & Risks
- Decision: Symbols.Server remains a separately deployable WebService within BinaryIndex. The module consolidation is organizational, not a service merge.
- Risk: Namespace rename (`StellaOps.Symbols.*``StellaOps.BinaryIndex.Symbols.*`) may break serialized type names if any are persisted. Mitigation: check for `typeof(...)`, `nameof(...)`, or JSON `$type` discriminators referencing old namespaces.
## Next Checkpoints
- Estimate: 1-2 sessions due to the 6-project scope and namespace rename.

View File

@@ -1,114 +0,0 @@
# Sprint 203 - Advisory Domain: Concelier, Feedser, and Excititor
## Topic & Scope
- Shift from service-folder consolidation to domain-first consolidation for advisory ingestion and proof generation.
- Consolidate source layout under `src/Concelier/` while preserving independent deployables (`Concelier` and `Excititor`).
- Document advisory domain schema ownership. Schemas (`vuln`, `feedser`, `vex`, `proofchain`, `advisory_raw`) remain separate; no cross-schema DB merge. Each service keeps its existing DbContext.
- Working directory: `src/Concelier/`.
- Cross-module edits explicitly allowed for referenced consumers (`src/Attestor/`, `src/Scanner/`, `src/Cli/`, `src/Web/`, `devops/compose/`) as listed in tasks.
- Expected evidence: successful builds/tests, correct ProjectReference paths, and unchanged external API paths.
## Dependencies & Concurrency
- No upstream dependency.
- **Sprint 204 (Attestor) depends on this sprint** — Attestor references Feedser, which moves here. Sprint 204 must start after Sprint 203 source layout consolidation (TASK-203-002) is complete, or Attestor's ProjectReference paths will break.
- **Sprint 205 (VEX consolidation)** is deferred in the current wave. If reactivated later, it depends on Sprint 203 TASK-203-002 completion because VexHub references Excititor.
- **Sprint 220 (SbomService absorption)** was canceled (decision: do not merge SbomService in this wave). Keep note only for future reactivation of that sprint.
- Coordinate with Sprint 216 for IssuerDirectory client dependency inside Excititor.
## Documentation Prerequisites
- Read `docs/modules/concelier/architecture.md`.
- Read `docs/modules/excititor/architecture.md`.
- Read `docs/modules/feedser/architecture.md`.
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
## Delivery Tracker
### TASK-203-001 - Document advisory domain schema ownership and service boundaries
Status: TODO
Dependency: none
Owners: Developer
Task description:
- Document current DbContext ownership: ConcelierDbContext, ProofServiceDbContext, ExcititorDbContext.
- Document PostgreSQL schema ownership per service (`vuln`, `feedser`, `vex`, `proofchain`, `advisory_raw`) and confirm schemas remain separate.
- Document connection-string ownership and runtime config keys for the advisory domain.
- Record the domain boundary decision: schemas stay isolated, no cross-schema merge. Each service retains its own DbContext.
Completion criteria:
- [ ] Advisory domain schema ownership documented in sprint notes.
- [ ] Connection-string and runtime config keys documented.
- [ ] No-merge decision recorded with rationale.
### TASK-203-002 - Consolidate source layout into advisory domain module
Status: TODO
Dependency: TASK-203-001
Owners: Developer
Task description:
- Move `src/Feedser/` and `src/Excititor/` source trees into `src/Concelier/` domain layout.
- Preserve project names and runtime service identities.
- Update all `ProjectReference` paths (including Attestor, Scanner, and CLI consumers).
- Update solution files (`StellaOps.Concelier.sln` and root solution).
- Verify `<Compile Remove>` paths for compiled model assembly attributes in moved `.csproj` files are updated for ProofServiceDbContext compiled models.
Completion criteria:
- [ ] Feedser and Excititor source trees are under Concelier domain layout.
- [ ] All project references compile with new paths.
- [ ] Compiled model paths verified in moved `.csproj` files.
- [ ] Legacy top-level directories removed.
### TASK-203-003 - Update CLI/Web and infrastructure references
Status: TODO
Dependency: TASK-203-002
Owners: Developer
Task description:
- Validate/update CLI references from matrix evidence:
- `src/Cli/StellaOps.Cli/Services/BackendOperationsClient.cs` (`excititor/*`).
- `src/Cli/StellaOps.Cli/Commands/CommandHandlers.cs` (Excititor verbs).
- `src/Cli/StellaOps.Cli.sln` and `src/Cli/StellaOps.Cli/StellaOps.Cli.csproj` path updates.
- Validate/update Web references:
- `src/Web/StellaOps.Web/proxy.conf.json` (`/excititor`, `/concelier`).
- `src/Web/StellaOps.Web/src/app/app.config.ts` (`/api/v1/concelier`).
- Keep existing public endpoints backward compatible.
Completion criteria:
- [ ] CLI references updated and buildable.
- [ ] Web proxy/config references validated.
- [ ] Public endpoint compatibility confirmed.
### TASK-203-004 - Build, test, and documentation closeout
Status: TODO
Dependency: TASK-203-003
Owners: Developer
Task description:
- Build and test Concelier domain solution and root solution.
- Run targeted tests for Attestor and Scanner consumers affected by Feedser path changes.
- Update module docs to reflect advisory domain model (source consolidation, schema ownership unchanged).
- Archive superseded Feedser/Excititor standalone docs after replacement sections are in Concelier docs.
- Add ADR entry to `docs/modules/concelier/architecture.md` documenting the no-merge decision and deployment boundary freeze.
Completion criteria:
- [ ] Domain and root builds succeed.
- [ ] Targeted dependent tests pass.
- [ ] Documentation updated for domain-first model.
- [ ] ADR entry recorded in architecture dossier.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
| 2026-02-25 | CLI/UI module reference audit completed and sprint rework aligned to `AUDIT_20260225_cli_ui_module_reference_matrix.md`. | Planning |
| 2026-02-25 | Reworked to domain-first consolidation with phased advisory DB merge plan. | Planning |
| 2026-02-25 | DB merge REJECTED after deep analysis: 49 entities across 5 schemas (`vuln`, `feedser`, `vex`, `proofchain`, `advisory_raw`) is too complex for marginal benefit when all data is already in one PostgreSQL database (`stellaops_platform`). Sprint reduced from 8 tasks to 4 (source consolidation only). | Planning |
## Decisions & Risks
- Decision: Advisory domain is source-consolidation only. No cross-schema DB merge.
- Rationale: All services already share the `stellaops_platform` database. The 49 entities across 5 schemas have distinct lifecycles (raw ingestion vs. proof generation vs. VEX processing). Merging DbContexts would couple unrelated write patterns for zero operational benefit. Schema isolation is a feature, not a problem to solve.
- Decision: Deployable services remain separate at runtime while sharing one domain source root.
- Decision: Each service retains its own DbContext and PostgreSQL schema ownership.
- Risk: Largest project move in the batch (17 csproj). Mitigation: source move is isolated from schema changes, reducing blast radius.
- Note: Sprint 219 generated compiled models for ProofServiceDbContext (under `src/Concelier/`). After the source move, verify that `<Compile Remove>` paths for compiled model assembly attributes in moved `.csproj` files are updated.
## Next Checkpoints
- Milestone 1: domain schema ownership documented and source layout consolidated.
- Milestone 2: CLI/Web references updated and builds pass.
- Milestone 3: docs updated and sprint ready for closure.

View File

@@ -1,104 +0,0 @@
# Sprint 204 - Trust Domain: Attestor, Signer, and Provenance Consolidation
## Topic & Scope
- Shift trust-related modules to a single trust domain model while preserving explicit runtime security boundaries.
- Consolidate source ownership for `Attestor`, `Signer`, and `Provenance` under the trust domain structure.
- Document trust domain schema ownership. Schemas remain separate; the security boundary between signer key material and attestation evidence is preserved deliberately. No cross-schema DB merge.
- Working directory: `src/Attestor/`.
- Cross-module edits explicitly allowed for dependent consumers and runtime paths (`src/Concelier/`, `src/Cli/`, `src/Web/`, `devops/compose/`) as listed in tasks.
- Expected evidence: builds/tests pass, DSSE/signing contracts unchanged, and no API regressions.
## Dependencies & Concurrency
- **Upstream dependency: Sprint 203 (Concelier absorbs Feedser)** — Attestor references Feedser libraries (ProofChain, PatchVerification). Sprint 203 moves Feedser into `src/Concelier/`. This sprint's source move (TASK-204-002) must use Feedser's post-203 paths, so Sprint 203 TASK-203-002 must be complete before this sprint starts TASK-204-002.
- Coordinate with Sprint 216 for broader identity/trust alignment.
## Documentation Prerequisites
- Read `docs/modules/attestor/architecture.md`.
- Read `docs/modules/signer/architecture.md`.
- Read `docs/modules/provenance/architecture.md` (or module docs in repo).
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
## Delivery Tracker
### TASK-204-001 - Document trust domain security boundaries and schema ownership
Status: TODO
Dependency: none
Owners: Developer
Task description:
- Classify trust data: attestation evidence (proofchain schema), provenance evidence, signer metadata, signer key material.
- Document PostgreSQL schema ownership per service and confirm schemas remain separate.
- Record the domain boundary decision: signer key-material isolation from attestation evidence is a deliberate security boundary, not an accident. No cross-schema merge.
Completion criteria:
- [ ] Trust data classification documented.
- [ ] Schema ownership per service documented.
- [ ] Security boundary no-merge decision recorded with rationale.
### TASK-204-002 - Consolidate source layout under trust domain ownership
Status: TODO
Dependency: TASK-204-001
Owners: Developer
Task description:
- Move `src/Signer/` and `src/Provenance/` source into trust domain layout under `src/Attestor/`.
- Preserve deployable service names and package identities.
- Update all `ProjectReference` paths, including external consumers.
- Update solution files and remove old top-level module roots.
Completion criteria:
- [ ] Source layout consolidated under trust domain.
- [ ] Project references compile.
- [ ] Legacy top-level folders removed.
### TASK-204-003 - CLI/Web, compose, and CI updates
Status: TODO
Dependency: TASK-204-002
Owners: Developer
Task description:
- Update CLI references and solution paths for Signer/Provenance relocation.
- Validate Web/platform service identity references for signer health and routing.
- Update compose/workflow paths for moved trust-domain projects.
- Verify DSSE signing endpoint `/api/v1/signer/sign/dsse` remains accessible.
Completion criteria:
- [ ] CLI references updated and buildable.
- [ ] Web/platform references validated.
- [ ] Compose and CI paths updated.
- [ ] Signing API compatibility confirmed.
### TASK-204-004 - Build/test and documentation closeout
Status: TODO
Dependency: TASK-204-003
Owners: Developer
Task description:
- Run trust domain builds and tests plus dependent module tests (Concelier provenance consumer).
- Update trust-domain architecture docs to reflect domain ownership model and schema boundaries.
- Archive superseded standalone Signer/Provenance module docs after replacement content is live.
- Add ADR entry to `docs/modules/attestor/architecture.md` documenting the no-merge decision and security boundary rationale.
Completion criteria:
- [ ] All required builds/tests pass.
- [ ] Trust-domain docs updated for domain model.
- [ ] ADR entry recorded in architecture dossier.
- [ ] Archived docs and active links validated.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
| 2026-02-25 | CLI/UI module reference audit completed and sprint rework aligned to `AUDIT_20260225_cli_ui_module_reference_matrix.md`. | Planning |
| 2026-02-25 | Reworked to trust-domain plan with phased DB merge and key-boundary safeguards. | Planning |
| 2026-02-25 | DB merge REJECTED after deep analysis: the security boundary between signer key material and attestation evidence is a deliberate architectural feature. A merged DbContext would widen blast radius of credential compromise. Sprint reduced from 8 tasks to 4 (source consolidation only). | Planning |
## Decisions & Risks
- Decision: Trust domain is source-consolidation only. No cross-schema DB merge.
- Rationale: The separation between signer (key material, HSM/KMS operations) and proofchain (attestation evidence, provenance records) is a deliberate security boundary. A merged DbContext would mean a single connection string with access to both key material and evidence stores, increasing blast radius of any credential compromise. Schema isolation is a security feature.
- Decision: Signing API contracts remain stable for CLI promotion workflows.
- Decision: Each trust service retains its own DbContext and PostgreSQL schema ownership.
- Risk: ProjectReference path breakage after source move. Mitigation: Attestor references Feedser libraries moved by Sprint 203; this sprint uses post-203 paths.
## Next Checkpoints
- Milestone 1: trust security boundaries documented and source layout consolidated.
- Milestone 2: CLI/Web/compose references updated and builds pass.
- Milestone 3: docs and ADR updated, sprint ready for closure.

View File

@@ -1,108 +0,0 @@
# Sprint 206 - Policy/Unknowns Boundary Preservation (No Consolidation)
## Topic & Scope
- Retain `Unknowns` as its own microservice and database owner.
- Keep `src/Unknowns/` and `src/Policy/` as separate module roots; no source move, no DbContext merge, no schema merge.
- Replace stale assumptions from earlier draft (Unknowns persistence is active and must not be deleted).
- Working directory: `src/Unknowns/`.
- Cross-module edits explicitly allowed for documentation and integration references (`src/Policy/`, `src/Platform/`, `src/Scanner/`, `src/Cli/`, `src/Web/`, `devops/compose/`, `docs/modules/policy/`, `docs/modules/unknowns/`).
- Expected evidence: Unknowns service + DB boundary explicitly documented, compatibility validated, and no consolidation side effects introduced.
## Dependencies & Concurrency
- No upstream dependency.
- Can run in parallel with other sprints, except any sprint that attempts to move/delete `src/Unknowns/`.
- Coordinate with Sprint 218 for final docs alignment.
## Documentation Prerequisites
- Read `docs/modules/unknowns/architecture.md`.
- Read `docs/modules/policy/architecture.md`.
- Read `src/Unknowns/AGENTS.md` and `src/Policy/AGENTS.md`.
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
## Delivery Tracker
### TASK-206-001 - Re-baseline Unknowns runtime and persistence reality
Status: TODO
Dependency: none
Owners: Developer
Task description:
- Prove current state with commands and capture output in sprint notes:
- `rg -n "class UnknownsDbContext|DbSet<UnknownEntity>" src/Unknowns -g "*.cs"`
- `rg -n "ProjectReference Include=.*Unknowns\\.Persistence" src -g "*.csproj"`
- `rg -n "Map(Get|Post|Put|Delete|Group)\\(" src/Unknowns -g "Program.cs"`
- Confirm Unknowns is an active service boundary with active persistence and consumers.
- Explicitly identify any placeholder-only context so it is not confused with the active persistence context.
Completion criteria:
- [ ] Active Unknowns persistence context confirmed and documented.
- [ ] Unknowns runtime service surface confirmed and documented.
- [ ] Consumer list captured from project references.
### TASK-206-002 - Record decision: keep Unknowns as standalone microservice + DB owner
Status: TODO
Dependency: TASK-206-001
Owners: Developer
Task description:
- Update sprint `Decisions & Risks` and module docs to state:
- Unknowns remains independently deployable.
- Unknowns retains its own DbContext and schema ownership.
- No source consolidation into Policy and no DbContext merge.
- Remove/replace any stale wording that implies Unknowns DB deletion.
Completion criteria:
- [ ] No-consolidation decision recorded in sprint.
- [ ] Unknowns/Policy architecture docs updated with explicit boundary statement.
- [ ] Stale "empty DbContext delete" language removed.
### TASK-206-003 - Validate integration contracts without consolidation
Status: TODO
Dependency: TASK-206-002
Owners: Developer
Task description:
- Validate that Policy/Scanner/Platform integrations continue to reference Unknowns correctly after decision freeze:
- `dotnet build src/Unknowns/StellaOps.Unknowns.WebService/StellaOps.Unknowns.WebService.csproj`
- `dotnet build src/Policy/StellaOps.Policy.Engine/StellaOps.Policy.Engine.csproj`
- `dotnet build src/Scanner/StellaOps.Scanner.Worker/StellaOps.Scanner.Worker.csproj`
- `dotnet build src/Platform/__Libraries/StellaOps.Platform.Database/StellaOps.Platform.Database.csproj`
- Verify no accidental path assumptions toward `src/Policy/` ownership of Unknowns.
Completion criteria:
- [ ] Affected projects build successfully.
- [ ] No broken ProjectReference paths.
- [ ] No accidental consolidation changes required.
### TASK-206-004 - CLI/Web/infra reference validation for preserved boundary
Status: TODO
Dependency: TASK-206-003
Owners: Developer
Task description:
- Validate references stay correct with Unknowns still standalone:
- `rg -n "unknowns|Unknowns" src/Cli -g "*.cs"`
- `rg -n "unknowns|Unknowns" src/Web/StellaOps.Web/src -g "*.ts"`
- `rg -n "STELLAOPS_UNKNOWNS_URL|unknowns" devops -g "*.yml" -g "*.yaml" -g "*.json"`
- If any references assume consolidation, create follow-up tasks and keep this sprint `DOING` until addressed.
Completion criteria:
- [ ] CLI references validated.
- [ ] Web references validated.
- [ ] DevOps/env references validated.
- [ ] Follow-up tasks created for any mismatches.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created (initial consolidation draft). | Planning |
| 2026-02-25 | Reworked: Unknowns retained as standalone microservice and DB owner; consolidation and DbContext deletion removed. | Planning |
| 2026-02-25 | Validation evidence captured: active Unknowns DbContext with `DbSet<UnknownEntity>` confirmed; representative builds passed for Unknowns.WebService, Policy.Engine, Scanner.Worker, and Platform.Database. | Planning |
## Decisions & Risks
- Decision: `Unknowns` remains a standalone module/service (`src/Unknowns/`) and is not consolidated into `Policy`.
- Decision: `UnknownsDbContext` and Unknowns schema ownership are retained; no DbContext merge and no schema merge.
- Rationale: current codebase contains active Unknowns persistence/entities and active runtime consumers; deletion/merge assumptions were stale.
- Risk: future duplicate logic across Policy and Unknowns. Mitigation: track explicit API/contract ownership and prefer integration contracts over source moves.
- Risk: reintroduction of consolidation assumptions in later sprints. Mitigation: add cross-reference note in Sprint 218 final docs sweep.
## Next Checkpoints
- Milestone 1: runtime/persistence re-baseline evidence captured.
- Milestone 2: docs and decision records updated to boundary-preserved model.
- Milestone 3: integration validation complete and sprint ready for closure.

View File

@@ -1,97 +0,0 @@
# Sprint 207 - Findings: Absorb RiskEngine and VulnExplorer Modules
## Topic & Scope
- Consolidate `src/RiskEngine/` and `src/VulnExplorer/` (1 csproj each) into `src/Findings/`.
- RiskEngine computes risk scores over findings. VulnExplorer is the API surface for browsing findings.
- Working directory: `src/RiskEngine/`, `src/VulnExplorer/`, `src/Findings/`.
- Expected evidence: clean builds, all tests pass.
## Dependencies & Concurrency
- No upstream dependencies. Can run in parallel.
## Documentation Prerequisites
- Read `src/RiskEngine/AGENTS.md` and `src/VulnExplorer/AGENTS.md`.
- Read `docs/modules/findings-ledger/architecture.md`.
## Delivery Tracker
### TASK-207-001 - Map RiskEngine and VulnExplorer structure
Status: TODO
Dependency: none
Owners: Developer
Task description:
- RiskEngine: list csproj files, dependencies, consumers, API surface, port.
- VulnExplorer: list csproj files (1 Api project), dependencies, consumers, port.
- Document Docker definitions for both.
Completion criteria:
- [ ] Both modules fully mapped
### TASK-207-002 - Move RiskEngine and VulnExplorer into Findings
Status: TODO
Dependency: TASK-207-001
Owners: Developer
Task description:
- Move RiskEngine projects → `src/Findings/StellaOps.RiskEngine.*/` or `src/Findings/__Libraries/StellaOps.RiskEngine.*/`.
- Move VulnExplorer → `src/Findings/StellaOps.VulnExplorer.*/`.
- Move tests from both into `src/Findings/__Tests/`.
- Keep project names as-is.
- Update `ProjectReference` paths.
- Add to Findings solution.
- Remove `src/RiskEngine/` and `src/VulnExplorer/` directories.
- Update root solution.
Completion criteria:
- [ ] All projects moved
- [ ] Findings solution includes both
- [ ] Old directories removed
### TASK-207-003 - Update Docker, CI, build verification
Status: TODO
Dependency: TASK-207-002
Owners: Developer
Task description:
- Update `devops/compose/` and `.gitea/workflows/`.
- `dotnet build` Findings solution — must succeed.
- Run all Findings, RiskEngine, and VulnExplorer tests.
- `dotnet build StellaOps.sln` — root solution.
Completion criteria:
- [ ] Docker and CI updated
- [ ] All builds and tests pass
### TASK-207-004 - Update documentation and CLI/Web references
Status: TODO
Dependency: TASK-207-003
Owners: Developer
Task description:
- Archive `docs/modules/risk-engine/` and `docs/modules/vuln-explorer/` to `docs-archived/modules/`.
- Add sections to Findings architecture doc.
- Update `docs/INDEX.md`, `CLAUDE.md`.
- Update all path references in docs.
- Validate runtime entrypoints used by Web and CLI:
- Web risk APIs use `/risk` base from `src/Web/StellaOps.Web/src/app/app.config.ts` (`RISK_API_BASE_URL`) and `risk-http.client.ts`; no direct `/riskengine` path expected.
- Compose/platform environment still carries `STELLAOPS_RISKENGINE_URL`; confirm gateway mapping keeps `/risk` behavior stable.
- Audit `src/Cli/` for direct `RiskEngine` and `VulnExplorer` source-path references (expected minimal to none).
- Update stale module-path references without changing public `/risk` API shape.
Completion criteria:
- [ ] Docs archived and Findings architecture updated.
- [ ] Web `/risk` compatibility verified.
- [ ] CLI audit completed (none or updates documented).
- [ ] All references updated.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
| 2026-02-25 | CLI/UI module reference audit completed and sprint rework aligned to `AUDIT_20260225_cli_ui_module_reference_matrix.md`. | Planning |
## Decisions & Risks
- Decision: RiskEngine and VulnExplorer keep their service identities if they have WebService projects.
- Low risk — small modules (1 csproj each).
## Next Checkpoints
- Estimate: 1 session.

View File

@@ -1,97 +0,0 @@
# Sprint 208 - Orchestration Domain: Orchestrator, Scheduler, TaskRunner, PacksRegistry
## Topic & Scope
- Consolidate orchestration components into one domain ownership model.
- Move source layout under `src/Orchestrator/` while preserving deployable services.
- Document orchestration domain schema ownership. Schemas remain separate; OrchestratorDbContext and SchedulerDbContext have entity name collisions (Jobs, JobHistory) with incompatible models. No cross-schema DB merge.
- Working directory: `src/Orchestrator/`.
- Cross-module edits explicitly allowed for dependent consumers and integrations (`src/Platform/`, `src/Cli/`, `src/Web/`, `devops/compose/`) as listed in tasks.
- Expected evidence: all orchestration services remain operational, correct ProjectReference paths, CLI/Web integrations preserved.
## Dependencies & Concurrency
- No upstream dependency.
- Coordinate with Sprint 218 for final architecture and docs updates.
## Documentation Prerequisites
- Read `docs/modules/orchestrator/architecture.md`.
- Read `docs/modules/scheduler/architecture.md`.
- Read `docs/modules/taskrunner/architecture.md`.
- Read module AGENTS files for Scheduler, TaskRunner, and PacksRegistry.
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
## Delivery Tracker
### TASK-208-001 - Document orchestration domain schema ownership and service boundaries
Status: TODO
Dependency: none
Owners: Developer
Task description:
- Document DbContext ownership for Orchestrator, Scheduler, TaskRunner, and PacksRegistry.
- Document PostgreSQL schema ownership per service and confirm schemas remain separate.
- Record the domain boundary decision: OrchestratorDbContext (39 entities) and SchedulerDbContext (11 entities) have Jobs/JobHistory name collisions with fundamentally different models. TaskRunner and PacksRegistry have stub contexts with zero entities. No merge.
Completion criteria:
- [ ] Orchestration domain schema ownership documented.
- [ ] Name collision analysis recorded (Jobs, JobHistory).
- [ ] No-merge decision recorded with rationale.
### TASK-208-002 - Consolidate source layout under Orchestrator domain
Status: TODO
Dependency: TASK-208-001
Owners: Developer
Task description:
- Move Scheduler, TaskRunner, and PacksRegistry source trees under Orchestrator domain layout.
- Preserve deployable runtime identities.
- Update all project/solution references and remove legacy top-level roots.
- Update `<Compile Remove>` paths for compiled model assembly attributes in moved `.csproj` files (both OrchestratorDbContext and SchedulerDbContext have compiled models from Sprint 219).
Completion criteria:
- [ ] Source trees consolidated under Orchestrator domain.
- [ ] References compile after move.
- [ ] Compiled model paths verified in moved `.csproj` files.
- [ ] Legacy roots removed.
### TASK-208-003 - CLI/Web, infrastructure, build/test, and documentation closeout
Status: TODO
Dependency: TASK-208-002
Owners: Developer
Task description:
- Validate external contracts for CLI and Web:
- CLI `api/task-runner/simulations` and route aliases.
- Web `/scheduler` proxy and scheduler API base URL providers.
- Validate compose/workflow paths after source move.
- Build/test orchestration domain and root solution.
- Update Orchestrator architecture docs with Scheduler, TaskRunner, and PacksRegistry subdomain sections.
- Archive superseded standalone docs and update INDEX/architecture references.
- Add ADR entry to `docs/modules/orchestrator/architecture.md` documenting the no-merge decision, naming collision rationale, and future rename consideration.
Completion criteria:
- [ ] CLI/Web contracts verified.
- [ ] Compose/workflow updates complete.
- [ ] Domain and root builds/tests pass.
- [ ] Docs updated for domain model.
- [ ] ADR entry recorded in architecture dossier.
- [ ] Archived docs and active links validated.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
| 2026-02-25 | CLI/UI module reference audit completed and sprint rework aligned to `AUDIT_20260225_cli_ui_module_reference_matrix.md`. | Planning |
| 2026-02-25 | Reworked to orchestration domain plan with explicit DB merge and baseline migration tasks. | Planning |
| 2026-02-25 | DB merge REJECTED after deep analysis: OrchestratorDbContext (39 entities) and SchedulerDbContext (11 entities) both define Jobs and JobHistory entities with incompatible semantics (pipeline runs vs. cron executions). Merging would require entity renaming that propagates through entire codebases. Sprint reduced from 8 tasks to 3 (source consolidation only). | Planning |
## Decisions & Risks
- Decision: Orchestration domain is source-consolidation only. No cross-schema DB merge.
- Rationale: OrchestratorDbContext and SchedulerDbContext both define `Jobs` and `JobHistory` entities with incompatible semantics (orchestrator pipeline runs vs. scheduler cron executions). Merging into one DbContext would require renaming one set, propagating through repositories, query code, and external contracts. All data is already in `stellaops_platform`; the schemas provide clean separation at no cost.
- Decision: Services remain independently deployable while source ownership is unified by domain.
- Decision: TaskRunner and PacksRegistry stub contexts (zero entities, deferred by Sprint 219) remain as-is until they have actual persistence needs.
- Risk: Module name confusion between `Orchestrator` (scheduling/execution domain) and `ReleaseOrchestrator` (core release control plane). Future sprint should rename Orchestrator to a less ambiguous name (e.g., `JobScheduler` or `ExecutionEngine`).
- Note: Both OrchestratorDbContext and SchedulerDbContext have compiled models from Sprint 219. After moving Scheduler projects, update `<Compile Remove>` paths.
## Next Checkpoints
- Milestone 1: orchestration domain schema ownership documented and source layout consolidated.
- Milestone 2: CLI/Web/compose references validated and builds pass.
- Milestone 3: docs updated and sprint ready for closure.

View File

@@ -1,97 +0,0 @@
# Sprint 209 - Notify/Notifier Boundary Preservation (No Consolidation)
## Topic & Scope
- Keep `Notify` and `Notifier` as separate deployable services.
- Cancel the absorb plan: no source move, no project merge, no deletion of `src/Notifier/`.
- Replace stale assumption that Notifier is a thin host; current code contains substantial independent API surface.
- Working directory: `src/Notify/`, `src/Notifier/`.
- Cross-module edits explicitly allowed for docs and integration references (`src/Cli/`, `src/Web/`, `devops/compose/`, `docs/modules/notify/`, `docs/modules/notifier/`).
- Expected evidence: service boundaries are explicitly documented, builds remain green, and compatibility expectations are clear.
## Dependencies & Concurrency
- No upstream dependency.
- Can run in parallel with other consolidation sprints.
- Coordinate with Sprint 218 documentation closeout.
## Documentation Prerequisites
- Read `docs/modules/notifier/README.md`.
- Read `docs/modules/notify/architecture.md`.
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
## Delivery Tracker
### TASK-209-001 - Baseline current Notify/Notifier runtime boundaries
Status: TODO
Dependency: none
Owners: Developer
Task description:
- Capture route and complexity evidence for both services:
- `src/Notifier/.../Program.cs` line count and mapped routes.
- `src/Notify/.../Program.cs` line count and mapped routes.
- Document endpoint overlap and endpoint gaps (Notifier-only and Notify-only).
- Confirm external project references to `Notifier` are zero and record result.
Completion criteria:
- [ ] Notify/Notifier route matrix documented.
- [ ] Complexity and endpoint-gap evidence recorded.
- [ ] Consumer reference scan result recorded.
### TASK-209-002 - Record decision to keep split deployment model
Status: TODO
Dependency: TASK-209-001
Owners: Developer
Task description:
- Update sprint notes and module docs to state:
- Notify and Notifier remain separate services.
- No source consolidation and no project relocation.
- Any future convergence requires explicit API parity plan first.
- Remove stale wording that claims Notifier is purely a host.
Completion criteria:
- [ ] No-consolidation decision recorded in sprint.
- [ ] Notify/notifier docs updated with explicit split rationale.
- [ ] Stale thin-host assumptions removed.
### TASK-209-003 - Validate builds and key contracts without consolidation
Status: TODO
Dependency: TASK-209-002
Owners: Developer
Task description:
- Build both services and representative consumers:
- `dotnet build src/Notifier/StellaOps.Notifier/StellaOps.Notifier.WebService/StellaOps.Notifier.WebService.csproj`
- `dotnet build src/Notify/StellaOps.Notify.WebService/StellaOps.Notify.WebService.csproj`
- `dotnet build src/Cli/StellaOps.Cli/StellaOps.Cli.csproj`
- Validate that current API base-path expectations remain unchanged.
Completion criteria:
- [ ] Builds pass for Notify, Notifier, and representative consumer(s).
- [ ] API compatibility assumptions documented.
### TASK-209-004 - Finalize docs and follow-up backlog items
Status: TODO
Dependency: TASK-209-003
Owners: Developer
Task description:
- Update `docs/INDEX.md` and sprint cross-references to reflect canceled consolidation.
- Add follow-up backlog item(s) only if explicit parity/convergence work is still desired.
Completion criteria:
- [ ] Documentation index updated.
- [ ] Follow-up items created only where actionable.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created (initial absorb draft). | Planning |
| 2026-02-25 | Reworked: consolidation canceled; Notify/Notifier remain separate services. | Planning |
| 2026-02-25 | Discovery evidence captured: Notifier Program.cs 3271 lines / 85 map calls; Notify Program.cs 1585 lines / 30 map calls; route sets are not equivalent. | Planning |
## Decisions & Risks
- Decision: keep Notify and Notifier unconsolidated in this consolidation wave.
- Rationale: current endpoint and logic divergence means absorb would be a feature-migration project, not a safe organizational move.
- Risk: dual-service ownership overhead remains. Mitigation: maintain explicit boundary docs and revisit only with approved parity roadmap.
## Next Checkpoints
- Milestone 1: boundary baseline documented.
- Milestone 2: split-deployment decision reflected in docs.
- Milestone 3: compatibility validation complete and sprint ready for closure.

View File

@@ -1,98 +0,0 @@
# Sprint 210 - Timeline: Absorb TimelineIndexer Module
## Topic & Scope
- Consolidate `src/TimelineIndexer/` (4 csproj) into `src/Timeline/`.
- CQRS split (read/write) is an internal architecture pattern, not a module boundary. Same schema domain.
- Working directory: `src/TimelineIndexer/`, `src/Timeline/`.
- Expected evidence: clean build, all tests pass.
## Dependencies & Concurrency
- No upstream dependencies.
- ExportCenter references TimelineIndexer.Core — coordinate path updates.
## Documentation Prerequisites
- Read `docs/modules/timeline/architecture.md`.
- Read `docs/modules/timeline-indexer/architecture.md`.
## Delivery Tracker
### TASK-210-001 - Map TimelineIndexer structure
Status: TODO
Dependency: none
Owners: Developer
Task description:
- List all 4 TimelineIndexer csproj, dependencies, consumers.
- Confirm consumers: ExportCenter references TimelineIndexer.Core.
- Document ports, Docker definitions.
Completion criteria:
- [ ] Module fully mapped
### TASK-210-002 - Move TimelineIndexer into Timeline
Status: TODO
Dependency: TASK-210-001
Owners: Developer
Task description:
- Move TimelineIndexer projects:
- WebService and Worker as deployables under `src/Timeline/`.
- Libraries to `src/Timeline/__Libraries/StellaOps.TimelineIndexer.*/`.
- Tests to `src/Timeline/__Tests/StellaOps.TimelineIndexer.*/`.
- Keep project names.
- Update all references.
- Add to Timeline solution.
- Remove `src/TimelineIndexer/`.
- Update root solution.
Completion criteria:
- [ ] All projects moved
- [ ] Old directory removed
### TASK-210-003 - Update consumers, Docker, CI, build, and test
Status: TODO
Dependency: TASK-210-002
Owners: Developer
Task description:
- Update ExportCenter references to TimelineIndexer.Core (new path).
- Update `devops/compose/`, `.gitea/workflows/`.
- Build and test Timeline solution.
- Build root solution.
Completion criteria:
- [ ] All references updated
- [ ] Docker and CI updated
- [ ] All builds and tests pass
### TASK-210-004 - Update documentation and CLI/Web references
Status: TODO
Dependency: TASK-210-003
Owners: Developer
Task description:
- Archive `docs/modules/timeline-indexer/` to `docs-archived/modules/`.
- Add "TimelineIndexer (Event Ingestion and Indexing)" section to Timeline architecture.
- Update `docs/INDEX.md`, `CLAUDE.md`.
- Update path references.
- Update CLI TimelineIndexer references:
- `src/Cli/StellaOps.Cli/StellaOps.Cli.csproj` `TimelineIndexer.Infrastructure` project reference path.
- `src/Cli/StellaOps.Cli.sln` `TimelineIndexer.Core` project entry path.
- Audit `src/Web/StellaOps.Web` for direct `timelineindexer` references (expected none in current audit) and document result.
Completion criteria:
- [ ] Docs archived and Timeline architecture updated.
- [ ] CLI TimelineIndexer references updated.
- [ ] Web audit recorded (none or updates documented).
- [ ] All references updated.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
| 2026-02-25 | CLI/UI module reference audit completed and sprint rework aligned to `AUDIT_20260225_cli_ui_module_reference_matrix.md`. | Planning |
## Decisions & Risks
- Decision: TimelineIndexer keeps its Worker as a separately deployable container.
- Risk: TimelineIndexer has EfCore compiled model — migration identity must be preserved.
## Next Checkpoints
- Estimate: 1 session.

View File

@@ -1,96 +0,0 @@
# Sprint 211 - Offline Distribution Boundary Preservation (No Consolidation)
## Topic & Scope
- Keep `ExportCenter`, `AirGap`, and `Mirror` as separate module roots and service boundaries.
- Cancel merge plan: no source move under `src/ExportCenter/`, no DbContext merge, no schema merge.
- Preserve existing database ownership: `ExportCenterDbContext` and `AirGapDbContext` stay separate.
- Working directory: `src/ExportCenter/`, `src/AirGap/`, `src/Mirror/`.
- Cross-module edits explicitly allowed for docs/integration checks (`src/Cli/`, `src/Web/`, `devops/compose/`, `docs/modules/export-center/`, `docs/modules/airgap/`).
- Expected evidence: boundaries are explicit, key builds pass, and offline workflows remain stable.
## Dependencies & Concurrency
- No upstream dependency.
- Can run in parallel with other consolidation sprints.
- Coordinate with Sprint 218 documentation closeout.
## Documentation Prerequisites
- Read `docs/modules/export-center/architecture.md`.
- Read `docs/modules/airgap/architecture.md`.
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
## Delivery Tracker
### TASK-211-001 - Baseline current offline boundary and coupling
Status: TODO
Dependency: none
Owners: Developer
Task description:
- Record current DbContext ownership and entity sets for AirGap and ExportCenter.
- Record external consumer coupling (ProjectReference counts and key consumers).
- Capture evidence that `AirGap` is cross-cutting and `ExportCenter` is narrower in dependency footprint.
Completion criteria:
- [ ] DbContext ownership map documented.
- [ ] Coupling evidence documented.
- [ ] Boundary rationale evidence recorded in sprint notes.
### TASK-211-002 - Record no-consolidation/no-merge decision
Status: TODO
Dependency: TASK-211-001
Owners: Developer
Task description:
- Update sprint and module docs to state:
- no source consolidation,
- no DbContext merge,
- no schema merge.
- Remove stale wording about unified offline domain DbContext.
Completion criteria:
- [ ] No-consolidation decision recorded.
- [ ] No-merge decision recorded.
- [ ] Stale merge wording removed.
### TASK-211-003 - Validate critical build paths without consolidation
Status: TODO
Dependency: TASK-211-002
Owners: Developer
Task description:
- Run representative builds:
- `dotnet build src/ExportCenter/StellaOps.ExportCenter/StellaOps.ExportCenter.WebService/StellaOps.ExportCenter.WebService.csproj`
- `dotnet build src/AirGap/StellaOps.AirGap.Controller/StellaOps.AirGap.Controller.csproj`
- `dotnet build src/Cli/StellaOps.Cli/StellaOps.Cli.csproj`
- Confirm no integration breaks from decision freeze.
Completion criteria:
- [ ] Representative builds pass.
- [ ] No integration regressions identified from boundary-preserved model.
### TASK-211-004 - Document deferred convergence criteria (if ever revisited)
Status: TODO
Dependency: TASK-211-003
Owners: Developer
Task description:
- Add explicit criteria required before any future merge attempt (for example: reduced AirGap external coupling, approved rollback plan, measured performance gain target).
- If no convergence objective is active, record `deferred` and close sprint.
Completion criteria:
- [ ] Future-convergence entry criteria documented.
- [ ] Deferred state explicitly recorded when applicable.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created (initial consolidation draft). | Planning |
| 2026-02-25 | Reworked: consolidation canceled; AirGap/ExportCenter/Mirror boundaries preserved. | Planning |
| 2026-02-25 | Discovery evidence captured: AirGap has materially broader cross-module coupling than ExportCenter; merge risk exceeds benefit for current wave. | Planning |
## Decisions & Risks
- Decision: keep AirGap and ExportCenter unconsolidated in this consolidation wave.
- Decision: keep separate DbContexts and schema ownership.
- Rationale: asymmetric coupling and blast radius make DbContext/source merge a poor tradeoff now.
- Risk: duplicated offline-domain concepts remain across modules. Mitigation: define explicit contracts and revisit only under measured business need.
## Next Checkpoints
- Milestone 1: boundary/coupling baseline documented.
- Milestone 2: no-merge decision propagated to docs.
- Milestone 3: build validation complete and sprint ready for closure.

View File

@@ -1,130 +0,0 @@
# Sprint 212 - Tools: Absorb Bench, Verifier, Sdk, and DevPortal
## Topic & Scope
- Consolidate `src/Bench/` (5 csproj benchmarks), `src/Verifier/` (1 csproj CLI), `src/Sdk/` (2 csproj generator), and `src/DevPortal/` into `src/Tools/`.
- All are non-service, developer-facing tooling with no production deployment.
- Working directory: `src/Bench/`, `src/Verifier/`, `src/Sdk/`, `src/DevPortal/`, `src/Tools/`.
- Expected evidence: clean builds, all tools still function.
## Dependencies & Concurrency
- No upstream dependencies. Can run in parallel.
- Coordinate with Attestor sprint (204) if Provenance CLI tool also moves here.
## Documentation Prerequisites
- Read `src/Bench/AGENTS.md`, `src/Tools/AGENTS.md`.
## Delivery Tracker
### TASK-212-001 - Map all four modules
Status: TODO
Dependency: none
Owners: Developer
Task description:
- Bench: 5 benchmark csproj, no external consumers.
- Verifier: 1 CLI csproj (`BundleVerifier`), no external consumers.
- Sdk: 2 csproj (Generator + Release), no external consumers.
- DevPortal: list csproj files, confirm no external consumers.
- Tools: list existing 7+ csproj for naming conventions.
Completion criteria:
- [ ] All modules mapped
### TASK-212-002 - Move Bench into Tools
Status: TODO
Dependency: TASK-212-001
Owners: Developer
Task description:
- Move `src/Bench/StellaOps.Bench/` → `src/Tools/StellaOps.Bench/`.
- Move individual benchmark projects:
- `Bench.LinkNotMerge`, `Bench.Notify`, `Bench.PolicyEngine`, `Bench.ScannerAnalyzers`, `Bench.LinkNotMerge.Vex`.
- Move tests.
- Update references (Bench projects reference Policy, Scanner, Notify — these paths change).
- Remove `src/Bench/`.
Completion criteria:
- [ ] All Bench projects moved
- [ ] Old directory removed
### TASK-212-003 - Move Verifier into Tools
Status: TODO
Dependency: TASK-212-001
Owners: Developer
Task description:
- Move `src/Verifier/StellaOps.Verifier/` → `src/Tools/StellaOps.Verifier/`.
- Move tests.
- Remove `src/Verifier/`.
Completion criteria:
- [ ] Verifier moved
- [ ] Old directory removed
### TASK-212-004 - Move Sdk into Tools
Status: TODO
Dependency: TASK-212-001
Owners: Developer
Task description:
- Move `src/Sdk/StellaOps.Sdk.Generator/` → `src/Tools/StellaOps.Sdk.Generator/`.
- Move `src/Sdk/StellaOps.Sdk.Release/` → `src/Tools/StellaOps.Sdk.Release/`.
- Move tests.
- Remove `src/Sdk/`.
Completion criteria:
- [ ] Both Sdk projects moved
- [ ] Old directory removed
### TASK-212-005 - Move DevPortal into Tools
Status: TODO
Dependency: TASK-212-001
Owners: Developer
Task description:
- Move `src/DevPortal/` projects → `src/Tools/StellaOps.DevPortal.*/`.
- Move tests.
- Remove `src/DevPortal/`.
Completion criteria:
- [ ] DevPortal moved
- [ ] Old directory removed
### TASK-212-006 - Update solutions, build, and test
Status: TODO
Dependency: TASK-212-002, TASK-212-003, TASK-212-004, TASK-212-005
Owners: Developer
Task description:
- Add all moved projects to Tools solution (or create one if none exists).
- Update root solution.
- Build all moved projects.
- Run all benchmark and tool tests.
Completion criteria:
- [ ] Tools solution includes all moved projects
- [ ] All builds succeed
- [ ] All tests pass
### TASK-212-007 - Update documentation and CLI
Status: TODO
Dependency: TASK-212-006
Owners: Developer
Task description:
- Archive `docs/modules/bench/`, `docs/modules/sdk/`, `docs/modules/devportal/` to `docs-archived/modules/`.
- Note: `docs/modules/verifier/` — archive if it exists.
- Add sections to Tools architecture doc.
- Update `docs/INDEX.md`, `CLAUDE.md`.
- Update path references.
Completion criteria:
- [ ] Docs archived
- [ ] Tools architecture updated
- [ ] All references updated
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
## Decisions & Risks
- Low risk — all are non-service, dev-only tools.
- Decision: Keep individual tool identities (project names) for independent `dotnet tool` packaging.
## Next Checkpoints
- Estimate: 1-2 sessions.

View File

@@ -1,105 +0,0 @@
# Sprint 213 - AdvisoryAI: Absorb OpsMemory Module
## Topic & Scope
- Consolidate `src/OpsMemory/` (2 csproj: WebService + library) into `src/AdvisoryAI/`.
- OpsMemory is primarily owned by AdvisoryAI and serves the AI operational memory / RAG domain; Web UI consumes its HTTP API for playbook suggestions.
- Working directory: `src/OpsMemory/`, `src/AdvisoryAI/`.
- Expected evidence: clean build, all tests pass, OpsMemory service still deploys.
## Dependencies & Concurrency
- No upstream dependencies. Can run in parallel.
## Documentation Prerequisites
- Read `docs/modules/opsmemory/architecture.md`.
- Read `docs/modules/advisory-ai/architecture.md`.
## Delivery Tracker
### TASK-213-001 - Map OpsMemory dependencies
Status: TODO
Dependency: none
Owners: Developer
Task description:
- OpsMemory: `StellaOps.OpsMemory` (library) + `StellaOps.OpsMemory.WebService`.
- Confirm AdvisoryAI is the only consumer.
- Check if OpsMemory has its own database schema/migrations.
- Document API surface, port, Docker definition.
- Note: AdvisoryAI currently references OpsMemory via ProjectReference — this coupling should be evaluated (could become HTTP client).
Completion criteria:
- [ ] Full dependency map
- [ ] Consumer list confirmed
- [ ] Schema/migration status documented
### TASK-213-002 - Move OpsMemory into AdvisoryAI
Status: TODO
Dependency: TASK-213-001
Owners: Developer
Task description:
- Move `src/OpsMemory/StellaOps.OpsMemory/``src/AdvisoryAI/__Libraries/StellaOps.OpsMemory/`.
- Move `src/OpsMemory/StellaOps.OpsMemory.WebService/``src/AdvisoryAI/StellaOps.OpsMemory.WebService/`.
- Move tests → `src/AdvisoryAI/__Tests/StellaOps.OpsMemory.*/`.
- Keep project names.
- Update `ProjectReference` paths.
- Add to AdvisoryAI solution.
- Remove `src/OpsMemory/`.
- Update root solution.
Completion criteria:
- [ ] All projects moved
- [ ] AdvisoryAI solution includes OpsMemory
- [ ] Old directory removed
### TASK-213-003 - Update Docker, CI, build, test
Status: TODO
Dependency: TASK-213-002
Owners: Developer
Task description:
- Update `devops/compose/` for OpsMemory service.
- Update `.gitea/workflows/`.
- Build AdvisoryAI solution — must succeed.
- Run all AdvisoryAI + OpsMemory tests.
- Build root solution.
Completion criteria:
- [ ] Docker and CI updated
- [ ] All builds and tests pass
### TASK-213-004 - Update documentation and CLI/Web references
Status: TODO
Dependency: TASK-213-003
Owners: Developer
Task description:
- Archive `docs/modules/opsmemory/` to `docs-archived/modules/`.
- Add "OpsMemory (Operational Memory and RAG)" section to AdvisoryAI architecture.
- Update `docs/INDEX.md`, `CLAUDE.md`.
- Update path references.
- Update Web OpsMemory references:
- `src/Web/StellaOps.Web/src/app/features/opsmemory/services/playbook-suggestion.service.ts` base URL (`/api/v1/opsmemory`).
- OpsMemory-related feature components/models and triage integrations under `src/Web/StellaOps.Web/src/app/features/opsmemory/**`.
- E2E and unit tests hitting `/api/v1/opsmemory/suggestions`.
- Audit CLI for direct OpsMemory references (expected none in current audit) and document outcome.
- Preserve `/api/v1/opsmemory` endpoint contract.
Completion criteria:
- [ ] Docs archived and AdvisoryAI architecture updated.
- [ ] Web OpsMemory references validated/updated.
- [ ] CLI audit recorded (none or updates documented).
- [ ] OpsMemory API path compatibility verified.
- [ ] All references updated.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
| 2026-02-25 | CLI/UI module reference audit completed and sprint rework aligned to `AUDIT_20260225_cli_ui_module_reference_matrix.md`. | Planning |
## Decisions & Risks
- Decision: OpsMemory WebService keeps its own container for independent deployment.
- Risk: OpsMemory README and architecture doc have content overlap. Consolidation into AdvisoryAI resolves this.
## Next Checkpoints
- Estimate: 1 session.

View File

@@ -1,119 +0,0 @@
# Sprint 214 - Integrations: Absorb Extensions Module
## Topic & Scope
- Consolidate `src/Extensions/` (VS Code + JetBrains IDE plugins) into `src/Integrations/`.
- Extensions are developer-facing tooling that consumes the same Orchestrator/Router APIs as other integrations. Logically part of the Integrations domain.
- Note: Extensions are non-.NET projects (TypeScript/Kotlin). No .csproj files. No .sln. No Docker service.
- Working directory: `src/Extensions/`, `src/Integrations/`.
- Expected evidence: both IDE plugins still build and function, docs updated.
## Dependencies & Concurrency
- No upstream dependencies. Can run in parallel.
## Documentation Prerequisites
- Read `docs/modules/integrations/architecture.md`.
- Read `docs/modules/extensions/architecture.md`.
- Read `src/Integrations/AGENTS.md`.
## Delivery Tracker
### TASK-214-001 - Map Extensions structure
Status: TODO
Dependency: none
Owners: Developer
Task description:
- VS Code extension: `src/Extensions/vscode-stella-ops/` — TypeScript, package.json.
- JetBrains plugin: `src/Extensions/jetbrains-stella-ops/` — Kotlin, build.gradle.kts.
- Confirm zero .NET csproj files in Extensions.
- Confirm zero external consumers (no other src/ module references Extensions).
- Document any shared configs, scripts, or CI steps for Extensions.
- Check if Extensions has its own AGENTS.md (expected: missing — create task if so).
Completion criteria:
- [ ] Extensions module fully mapped
- [ ] Consumer list confirmed (expected: none)
- [ ] Build tooling documented (npm/gradle)
### TASK-214-002 - Move Extensions into Integrations
Status: TODO
Dependency: TASK-214-001
Owners: Developer
Task description:
- Move `src/Extensions/vscode-stella-ops/` -> `src/Integrations/__Extensions/vscode-stella-ops/`.
- Move `src/Extensions/jetbrains-stella-ops/` -> `src/Integrations/__Extensions/jetbrains-stella-ops/`.
- Use `__Extensions/` prefix (not `__Plugins/`) to avoid confusion with Integrations plugin system.
- Copy any root-level Extensions files (README, AGENTS.md if created, etc.).
- Remove `src/Extensions/`.
- Update root solution file if Extensions was referenced.
Completion criteria:
- [ ] Both IDE extensions moved to `src/Integrations/__Extensions/`
- [ ] Old `src/Extensions/` directory removed
- [ ] No broken imports or path references
### TASK-214-003 - Verify builds and functionality
Status: TODO
Dependency: TASK-214-002
Owners: Developer
Task description:
- VS Code extension:
- `cd src/Integrations/__Extensions/vscode-stella-ops && npm install && npm run build` (or equivalent).
- Verify extension manifest (`package.json`) references are intact.
- JetBrains plugin:
- `cd src/Integrations/__Extensions/jetbrains-stella-ops && ./gradlew build` (or equivalent).
- Verify plugin descriptor references are intact.
- Check for any hardcoded paths in extension source code that referenced `src/Extensions/`.
- Build Integrations .NET solution — must still succeed (Extensions are non-.NET, should not affect).
Completion criteria:
- [ ] VS Code extension builds successfully
- [ ] JetBrains plugin builds successfully
- [ ] Integrations .NET solution builds successfully
### TASK-214-004 - Update CI and build scripts
Status: TODO
Dependency: TASK-214-003
Owners: Developer
Task description:
- Search `.gitea/workflows/` for any Extensions-specific CI steps. Update paths.
- Search `devops/` for any Extensions build scripts. Update paths.
- Search root `package.json` or workspace configs for Extensions references. Update.
- If no CI exists for Extensions, note this in Decisions & Risks.
Completion criteria:
- [ ] All CI/build references updated
- [ ] Build pipeline verified
### TASK-214-005 - Update documentation and CLI/Web audits
Status: TODO
Dependency: TASK-214-004
Owners: Developer
Task description:
- Archive `docs/modules/extensions/` to `docs-archived/modules/extensions/`.
- Add "IDE Extensions (VS Code, JetBrains)" section to Integrations architecture doc.
- Update `docs/INDEX.md`, `CLAUDE.md` section 1.4.
- Update path references across docs.
- Audit `src/Cli/` and `src/Web/` for runtime references to `Extensions` / `__Extensions` (expected none because these are IDE plugins, not runtime services).
- Create `src/Integrations/__Extensions/AGENTS.md` documenting the non-.NET projects.
Completion criteria:
- [ ] Docs archived and Integrations architecture updated.
- [ ] CLI/Web audit result recorded.
- [ ] All references updated.
- [ ] Extensions AGENTS.md created.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
| 2026-02-25 | CLI/UI module reference audit completed and sprint rework aligned to `AUDIT_20260225_cli_ui_module_reference_matrix.md`. | Planning |
## Decisions & Risks
- Decision: Use `__Extensions/` subfolder (not `__Plugins/`) to clearly separate IDE tooling from the Integrations plugin framework (GitHubApp, Harbor, etc.).
- Risk: Extensions are non-.NET (TypeScript, Kotlin). Build verification requires npm and Gradle toolchains. If not available in CI, mark build tasks as BLOCKED.
- Note: Extensions have no AGENTS.md currently — one will be created as part of this sprint.
## Next Checkpoints
- Estimate: 1 session.

View File

@@ -1,107 +0,0 @@
# Sprint 216 - Identity and Trust Domain: Authority and IssuerDirectory
## Topic & Scope
- Consolidate identity and issuer trust capabilities into one domain ownership model.
- Move IssuerDirectory source ownership under `src/Authority/` while preserving runtime service identity.
- Document identity domain schema ownership. Schemas remain separate; Authority is the most security-critical domain and schema isolation from IssuerDirectory is a deliberate security feature. No cross-schema DB merge.
- Working directory: `src/Authority/`.
- Cross-module edits explicitly allowed for consumer/client and runtime integration paths (`src/Excititor/`, `src/DeltaVerdict/`, `src/__Libraries/`, `devops/compose/`) as listed in tasks.
- Expected evidence: authority and issuer flows remain stable, client consumers continue to build, and no API regressions.
## Dependencies & Concurrency
- No hard upstream dependency, but **coordinate with Sprint 203** — IssuerDirectory.Client is consumed by Excititor. If Sprint 203 has already moved Excititor into `src/Concelier/`, this sprint's TASK-216-002 must update the IssuerDirectory.Client ProjectReference path in Excititor's new location under Concelier. If Sprint 203 has not yet run, this sprint's consumer path updates will target the original `src/Excititor/` location (and Sprint 203 will later update the path during its own move).
- Sprint 205 is deferred in the current wave; no active dependency.
## Documentation Prerequisites
- Read `docs/modules/authority/architecture.md`.
- Read `docs/modules/issuer-directory/architecture.md`.
- Read `src/Authority/AGENTS.md` and `src/IssuerDirectory/AGENTS.md`.
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
## Delivery Tracker
### TASK-216-001 - Document identity domain schema ownership and security boundaries
Status: TODO
Dependency: none
Owners: Developer
Task description:
- Document AuthorityDbContext schema ownership (users, sessions, tokens, roles, permissions, MFA, tenants).
- Document IssuerDirectoryDbContext schema ownership (issuer metadata, key metadata, audit).
- Record the domain boundary decision: Authority is the most security-critical domain (passwords, MFA state, token material). Schema isolation from IssuerDirectory is a security feature. No merge.
Completion criteria:
- [ ] Identity domain schema ownership documented.
- [ ] Security classification per schema documented.
- [ ] No-merge decision recorded with rationale.
### TASK-216-002 - Consolidate source layout under Authority domain
Status: TODO
Dependency: TASK-216-001
Owners: Developer
Task description:
- Move IssuerDirectory source/projects under `src/Authority/` domain structure.
- Move `StellaOps.IssuerDirectory.Client` under Authority domain libraries.
- Update all project/solution references for Excititor and DeltaVerdict consumers.
- Remove legacy top-level module roots after reference updates.
- Verify `<Compile Remove>` paths for compiled model assembly attributes (AuthorityDbContext has compiled models from Sprint 219).
Completion criteria:
- [ ] IssuerDirectory and client library relocated under Authority domain.
- [ ] Consumer references compile.
- [ ] Compiled model paths verified.
- [ ] Legacy roots removed.
### TASK-216-003 - Runtime compatibility, infra updates, and validation
Status: TODO
Dependency: TASK-216-002
Owners: Developer
Task description:
- Validate compose and launch settings references (`STELLAOPS_ISSUERDIRECTORY_URL` and IssuerDirectory client base address).
- Validate CLI/Web direct references (expected minimal from matrix audit) and record outcome.
- Build/test Authority, IssuerDirectory, and known consumers (Excititor and DeltaVerdict).
- Update CI workflow paths for moved source.
Completion criteria:
- [ ] Infra references validated or updated.
- [ ] Consumer compatibility builds pass.
- [ ] CI paths updated.
- [ ] CLI/Web audit outcome recorded.
### TASK-216-004 - Documentation and AGENTS closeout
Status: TODO
Dependency: TASK-216-003
Owners: Developer
Task description:
- Update Authority docs with IssuerDirectory domain ownership (source consolidation, schema boundaries unchanged).
- Archive superseded IssuerDirectory standalone docs after replacement content exists.
- Update Authority and moved subproject AGENTS files for new paths and ownership.
- Update docs index/architecture references.
- Add ADR entry to `docs/modules/authority/architecture.md` documenting the no-merge decision and security rationale.
Completion criteria:
- [ ] Docs updated for domain-first model.
- [ ] ADR entry recorded in architecture dossier.
- [ ] AGENTS files updated.
- [ ] Archived docs and links validated.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
| 2026-02-25 | CLI/UI module reference audit completed and sprint rework aligned to `AUDIT_20260225_cli_ui_module_reference_matrix.md`. | Planning |
| 2026-02-25 | Reworked to identity/trust domain plan with explicit Authority-IssuerDirectory DB merge phases. | Planning |
| 2026-02-25 | DB merge REJECTED after deep analysis: Authority is the most security-critical domain (passwords, MFA, tokens, tenant isolation). Merging IssuerDirectory tables into AuthorityDbContext would widen the blast radius of any credential compromise. Sprint reduced from 6 tasks to 4 (source consolidation only). | Planning |
## Decisions & Risks
- Decision: Identity domain is source-consolidation only. No cross-schema DB merge.
- Rationale: AuthorityDbContext manages the most security-sensitive data in the system (password hashes, MFA state, session tokens, refresh tokens, tenant boundaries). A merged DbContext would mean any code path with access to issuer metadata could also reach authentication internals via the same connection. The security principle of least privilege demands keeping these schemas separate even though they are in the same PostgreSQL instance.
- Decision: Authority and IssuerDirectory are managed as one identity/trust domain for source ownership.
- Decision: Runtime service contracts remain compatible during source relocation.
- Risk: shared client breakage in downstream modules. Mitigation: explicit consumer build gates.
- Note: AuthorityDbContext has compiled models generated by Sprint 219. After moving IssuerDirectory projects into `src/Authority/`, verify `<Compile Remove>` paths.
## Next Checkpoints
- Milestone 1: identity domain schema ownership documented and source layout consolidated.
- Milestone 2: infrastructure validated and builds pass.
- Milestone 3: docs and ADR updated, sprint ready for closure.

View File

@@ -1,127 +0,0 @@
# Sprint 217 - Platform: Orphan Library Cleanup
## Topic & Scope
- Clean up confirmed orphan libraries with zero production consumers.
- Two confirmed orphans:
- `src/__Libraries/StellaOps.AdvisoryLens/` — 0 consumers, not in main solution, has tests.
- `src/__Libraries/StellaOps.Resolver/` — 0 consumers, in main solution, has tests. Research/PoC code.
- One previously suspected orphan confirmed ACTIVE:
- `src/__Libraries/StellaOps.Configuration.SettingsStore/` — actively used by ReleaseOrchestrator, Platform, Cli, AdvisoryAI. **Do NOT archive.**
- Working directory: `src/__Libraries/`.
- Expected evidence: orphan source archived, solution file cleaned, docs updated.
## Dependencies & Concurrency
- No upstream dependencies. Can run in parallel with other consolidation sprints.
- Must verify no consumers were missed before archiving.
## Documentation Prerequisites
- Read `src/__Libraries/StellaOps.AdvisoryLens/` source to understand purpose.
- Read `src/__Libraries/StellaOps.Resolver/AGENTS.md`.
- Read `docs/features/checked/libraries/advisory-lens.md`.
- Read `docs/features/checked/libraries/unified-deterministic-resolver.md`.
## Delivery Tracker
### TASK-217-001 - Final consumer verification
Status: TODO
Dependency: none
Owners: Developer
Task description:
- For each orphan library, perform a final comprehensive search:
- Search all `.csproj` files for any `ProjectReference` mentioning `AdvisoryLens`.
- Search all `.csproj` files for any `ProjectReference` mentioning `StellaOps.Resolver`.
- Search all `.cs` files for `using StellaOps.AdvisoryLens` (outside the library itself).
- Search all `.cs` files for `using StellaOps.Resolver` (outside the library and its tests).
- Search Docker compose and CI for references to either library.
- Confirm: SettingsStore is NOT an orphan (used by ReleaseOrchestrator, Platform, Cli, AdvisoryAI via indirect dependency through Plugin/IntegrationHub).
- Document findings in Execution Log.
Completion criteria:
- [ ] AdvisoryLens confirmed as orphan (zero consumers)
- [ ] Resolver confirmed as orphan (zero consumers)
- [ ] SettingsStore confirmed as active (removed from cleanup scope)
### TASK-217-002 - Archive AdvisoryLens
Status: TODO
Dependency: TASK-217-001
Owners: Developer
Task description:
- Move `src/__Libraries/StellaOps.AdvisoryLens/` -> `src/__Libraries/_archived/StellaOps.AdvisoryLens/`.
- Move `src/__Libraries/__Tests/StellaOps.AdvisoryLens.Tests/` -> `src/__Libraries/_archived/StellaOps.AdvisoryLens.Tests/`.
- AdvisoryLens is NOT in the main solution file — no .sln update needed.
- If any other solution files reference it, remove those references.
- Archive docs: move `docs/modules/advisory-lens/` to `docs-archived/modules/advisory-lens/`.
- Update `docs/features/checked/libraries/advisory-lens.md` to note the library is archived/dormant.
Completion criteria:
- [ ] Source archived to `_archived/`
- [ ] Tests archived
- [ ] Docs archived
- [ ] Feature file updated
### TASK-217-003 - Archive Resolver
Status: TODO
Dependency: TASK-217-001
Owners: Developer
Task description:
- Move `src/__Libraries/StellaOps.Resolver/` -> `src/__Libraries/_archived/StellaOps.Resolver/`.
- Move `src/__Libraries/StellaOps.Resolver.Tests/` -> `src/__Libraries/_archived/StellaOps.Resolver.Tests/`.
- Remove from `StellaOps.sln` (root solution):
- Remove `StellaOps.Resolver` project entry.
- Remove `StellaOps.Resolver.Tests` project entry.
- Archive docs: check `docs/modules/` for any Resolver-specific docs. Archive if found.
- Update `docs/features/checked/libraries/unified-deterministic-resolver.md` to note the library is archived/dormant.
- Archive audit materials if they exist in `docs-archived/implplan-blocked/audits/`.
Completion criteria:
- [ ] Source archived to `_archived/`
- [ ] Tests archived
- [ ] Removed from root solution
- [ ] Feature file updated
### TASK-217-004 - Verify builds
Status: TODO
Dependency: TASK-217-002, TASK-217-003
Owners: Developer
Task description:
- Build root solution: `dotnet build StellaOps.sln` — must succeed.
- Verify no broken references anywhere in the codebase.
- Run a quick test of any module that might have had indirect dependencies.
Completion criteria:
- [ ] Root solution builds successfully
- [ ] No broken references
### TASK-217-005 - Update documentation
Status: TODO
Dependency: TASK-217-004
Owners: Developer
Task description:
- Update `docs/INDEX.md` if AdvisoryLens or Resolver are referenced.
- Update `CLAUDE.md` if either is referenced.
- Add note in `src/__Libraries/_archived/README.md` explaining the archive policy:
- Libraries here are dormant — zero production consumers at time of archival.
- They can be restored if a future feature needs them.
- Each library retains its tests for easy reactivation.
- Check for any references in feature docs, architecture docs, or sprint docs. Update.
Completion criteria:
- [ ] INDEX.md updated
- [ ] CLAUDE.md updated
- [ ] Archive README created
- [ ] All references updated
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
## Decisions & Risks
- Decision: Archive to `src/__Libraries/_archived/` (not delete) — preserves code history and enables reactivation.
- Decision: SettingsStore removed from cleanup scope — actively used by 4+ modules.
- Risk: AdvisoryLens may have been intended for a feature not yet implemented. Archiving (not deleting) preserves the option to restore.
- Risk: Resolver has extensive SOLID review and audit documentation. Archiving does not lose this — it moves with the code.
## Next Checkpoints
- Estimate: 1 session (small scope).

View File

@@ -1,89 +0,0 @@
# Sprint 218 - DOCS: Consolidation Decision Finalization
## Topic & Scope
- Final documentation sweep after consolidation-plan rework and boundary decisions.
- Publish final outcomes per sprint: proceed, deferred, canceled, or boundary-preserved.
- Remove stale claims about DbContext/service merges that were rejected.
- Working directory: `docs/`.
- Cross-module edits explicitly allowed for root documentation files and sprint evidence files under `docs/implplan/`.
- Expected evidence: active docs reflect actual approved work; canceled/no-op sprint assumptions are removed.
## Dependencies & Concurrency
- Depends on active implementation-affecting consolidation sprints being completed or explicitly canceled.
- Must run after Sprint 221 rename execution.
## Documentation Prerequisites
- Read `docs/INDEX.md`.
- Read `docs/07_HIGH_LEVEL_ARCHITECTURE.md`.
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
- Read execution logs of active consolidation sprints.
## Delivery Tracker
### TASK-218-001 - Publish consolidation decision ledger
Status: TODO
Dependency: none
Owners: Developer
Task description:
- Create/update a decision ledger that marks each consolidation sprint as one of:
- Proceed (implementation)
- Boundary-preserved (no consolidation)
- Deferred (future wave)
- Canceled/no-op (removed from active plan)
- Link each row to sprint file evidence.
Completion criteria:
- [ ] Decision ledger published.
- [ ] Every impacted sprint has explicit state.
### TASK-218-002 - Remove stale merge language from active docs
Status: TODO
Dependency: TASK-218-001
Owners: Developer
Task description:
- Remove claims that DbContext merges were executed where they are now rejected/deferred.
- Ensure docs describe preserved boundaries for Unknowns, Notify/Notifier, AirGap/ExportCenter, and SbomService.
Completion criteria:
- [ ] Stale merge claims removed.
- [ ] Boundary-preserved outcomes reflected in docs.
### TASK-218-003 - Align indexes and architecture maps with approved scope
Status: TODO
Dependency: TASK-218-001, TASK-218-002
Owners: Developer
Task description:
- Update `docs/INDEX.md` and architecture references so they match approved sprint outcomes.
- Ensure renamed orchestration domain references remain consistent with Sprint 221 execution.
Completion criteria:
- [ ] Index and architecture references aligned.
- [ ] No stale references to canceled/no-op consolidations.
### TASK-218-004 - Final documentation quality gate
Status: TODO
Dependency: TASK-218-003
Owners: Developer
Task description:
- Run final docs cross-reference checks.
- Record residual risks and deferred items.
Completion criteria:
- [ ] Cross-reference checks completed.
- [ ] Residual risks/deferred items documented.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. | Planning |
| 2026-02-25 | Reworked to decision-finalization closeout after consolidation scope changes. | Planning |
| 2026-02-25 | Updated outcomes: 206 boundary-preserved; 209 boundary-preserved; 211 boundary-preserved; 205 deferred/no-op; 215 no-op in consolidation wave; 220 canceled per decision not to merge SbomService; 221 proceed. | Planning |
## Decisions & Risks
- Decision: final docs must mirror approved execution scope, not earlier consolidation drafts.
- Risk: stale references to canceled/deferred merges may reappear from older notes. Mitigation: decision ledger + final grep gate.
## Next Checkpoints
- Milestone 1: decision ledger complete.
- Milestone 2: stale merge language removed.
- Milestone 3: final docs gate passed and sprint ready for closure.

View File

@@ -1,192 +0,0 @@
# Sprint 221 - Rename Orchestrator Domain to Resolve ReleaseOrchestrator Naming Collision
## Topic & Scope
- Rename the `src/Orchestrator/` domain directory, all `StellaOps.Orchestrator.*` namespaces, Docker images, API routes, authority scopes, and documentation to a new unambiguous name.
- The current name creates persistent confusion with `src/ReleaseOrchestrator/` (the core product feature — release promotion pipeline). This confusion will compound as the product matures and onboards contributors.
- Pre-alpha with zero clients — this is the last low-cost window for a clean rename.
- Working directory: `src/Orchestrator/` (becomes `src/<NewName>/` after rename).
- Cross-module edits explicitly allowed for all consumers, infrastructure, and documentation.
- Expected evidence: zero references to old name in code/config/docs (except PostgreSQL schema name, which is preserved for data continuity), all builds/tests pass.
## Dependencies & Concurrency
- **Upstream dependency: Sprint 208** — Sprint 208 consolidates Scheduler, TaskRunner, and PacksRegistry under `src/Orchestrator/`. This sprint renames the result. Sprint 208 must be DONE before this sprint starts.
- **Sprint 218 (DOCS) must wait for this sprint** — final docs sweep needs the rename to be complete.
- No other dependencies. Can run in parallel with any non-Orchestrator sprint.
## Documentation Prerequisites
- Read `docs/modules/orchestrator/architecture.md`.
- Read `src/Orchestrator/StellaOps.Orchestrator/AGENTS.md`.
- Read Sprint 208 execution log for post-consolidation layout.
- Read `devops/compose/docker-compose.stella-ops.yml` for infrastructure references.
- Read `devops/helm/stellaops/values-orchestrator.yaml` for Helm config.
## Naming Decision
The new name must satisfy:
1. **Unambiguous** — cannot be confused with ReleaseOrchestrator.
2. **Descriptive** — captures the domain: job scheduling, task DAG execution, pack runs, quotas, SLOs, circuit breakers, dead letters.
3. **Short enough** for a directory name and namespace prefix.
Candidate names (to be decided in TASK-221-001):
| Candidate | Pros | Cons |
|-----------|------|------|
| `JobEngine` | Clear, short, matches "job" terminology used throughout. | Doesn't capture pack-run or DAG aspects explicitly. |
| `Conductor` | Evocative of orchestration without the word. No collision risk. | Slightly abstract. May conflict with MassTransit's "Conductor" concept. |
| `Dispatch` | Short, action-oriented. Captures scheduling and routing. | Might be confused with message dispatch/event dispatch patterns. |
| `RunEngine` | Matches the existing "runs" terminology in the API. | Could be confused with test runner or CI runner concepts. |
## Delivery Tracker
### TASK-221-001 - Confirm new domain name and document impact assessment
Status: TODO
Dependency: Sprint 208 DONE
Owners: Developer
Task description:
- Select the new domain name from candidates (or propose alternative).
- Produce a complete rename mapping document:
- Directory: `src/Orchestrator/``src/<NewName>/`
- Namespaces: `StellaOps.Orchestrator.*``StellaOps.<NewName>.*` (3,268 references)
- Projects: 5 main + 2 shared library csproj files
- External ProjectReferences: 36 consumer csproj files
- Docker images: `stellaops/orchestrator`, `stellaops/orchestrator-worker`
- Compose services: `orchestrator`, `orchestrator-worker`
- Hostnames: `orchestrator.stella-ops.local`, `orchestrator-worker.stella-ops.local`
- API routes: `/api/v1/orchestrator/*` (5+ endpoint groups, 20+ endpoint files)
- OpenAPI spec: `/openapi/orchestrator.json`
- Authority scopes: `orchestrator:read`, `orchestrator:write`, `orchestrator:admin`
- Kafka consumer group: `orchestrator`
- Helm values: `values-orchestrator.yaml`
- Frontend: 40+ TypeScript files, Angular route config, proxy config
- PostgreSQL schema: `orchestrator`**DO NOT RENAME** (data continuity; schema name stays)
- EF compiled models: regeneration required after namespace change
- Record the decision and mapping in sprint notes.
Completion criteria:
- [ ] New name selected with rationale.
- [ ] Complete rename mapping documented.
- [ ] PostgreSQL schema preservation strategy confirmed.
### TASK-221-002 - Source directory, namespace, and project rename
Status: TODO
Dependency: TASK-221-001
Owners: Developer
Task description:
- Rename `src/Orchestrator/` directory to `src/<NewName>/`.
- Rename all `.csproj` files: `StellaOps.Orchestrator.*``StellaOps.<NewName>.*`.
- Rename shared library: `src/__Libraries/StellaOps.Orchestrator.Schemas/``src/__Libraries/StellaOps.<NewName>.Schemas/`.
- Update all `namespace` declarations in 324 C# files.
- Update all `using StellaOps.Orchestrator.*` statements in 222 C# files.
- Update all 36 external `ProjectReference` paths in consumer csproj files.
- Update solution files (`.sln`, `.slnf`).
- Verify build compiles: `dotnet build` on domain solution and root solution.
Completion criteria:
- [ ] Directory and all projects renamed.
- [ ] All namespace declarations updated.
- [ ] All using statements updated.
- [ ] All external ProjectReferences updated.
- [ ] Domain solution builds.
- [ ] Root solution builds.
### TASK-221-003 - Infrastructure and deployment rename
Status: TODO
Dependency: TASK-221-002
Owners: Developer
Task description:
- Update Docker image names in Dockerfiles: `stellaops/orchestrator``stellaops/<newname>`.
- Update Docker Compose files (3 files): service names, hostnames, environment variables.
- Update `STELLAOPS_ORCHESTRATOR_URL` environment variable name across all compose/launch/helm files.
- Update Helm values file: rename `values-orchestrator.yaml``values-<newname>.yaml`.
- Update Helm templates referencing orchestrator service.
- Update Kafka consumer group name.
- Update Authority scope names: `orchestrator:read/write/admin``<newname>:read/write/admin`.
- Update any launch settings or local dev configuration.
Completion criteria:
- [ ] Docker images and compose services renamed.
- [ ] Environment variable names updated.
- [ ] Helm values and templates updated.
- [ ] Kafka consumer group updated.
- [ ] Authority scopes updated.
- [ ] Local dev tooling updated.
### TASK-221-004 - API routes and frontend rename
Status: TODO
Dependency: TASK-221-002
Owners: Developer
Task description:
- Update all API endpoint route prefixes: `/api/v1/orchestrator/*``/api/v1/<newname>/*`.
- Update OpenAPI spec path: `/openapi/orchestrator.json``/openapi/<newname>.json`.
- Update Web proxy config: `src/Web/StellaOps.Web/proxy.conf.json` (`/orchestrator` target).
- Update Angular API clients: `orchestrator.client.ts`, `orchestrator-control.client.ts`.
- Update Angular feature routes and components under `src/app/features/orchestrator/`.
- Update Angular app config and navigation references.
- Update CLI route references if any exist for orchestrator endpoints.
Completion criteria:
- [ ] All API route prefixes updated.
- [ ] OpenAPI spec path updated.
- [ ] Web proxy config updated.
- [ ] Angular clients and routes updated.
- [ ] CLI references updated.
### TASK-221-005 - EF compiled model regeneration and database compatibility
Status: TODO
Dependency: TASK-221-002
Owners: Developer
Task description:
- PostgreSQL schema name `orchestrator` is **preserved** (no data migration). The DbContextFactory maps the new namespace to the existing schema name.
- Verify OrchestratorDbContextFactory (renamed) still sets `HasDefaultSchema("orchestrator")`.
- Verify SchedulerDbContextFactory still sets its existing schema.
- Regenerate EF compiled models for both DbContexts using `dotnet ef dbcontext optimize`.
- Verify `<Compile Remove>` entries for compiled model assembly attributes.
- Run all migration scripts to confirm they still apply against the existing schema.
- Run integration tests to confirm database operations work with renamed context.
Completion criteria:
- [ ] PostgreSQL schema name preserved (confirmed `orchestrator` in factory).
- [ ] EF compiled models regenerated for both contexts.
- [ ] `<Compile Remove>` entries verified.
- [ ] Migration scripts still apply cleanly.
- [ ] Integration tests pass.
### TASK-221-006 - Documentation, cross-references, and final validation
Status: TODO
Dependency: TASK-221-003, TASK-221-004, TASK-221-005
Owners: Developer
Task description:
- Rename and update `docs/modules/orchestrator/``docs/modules/<newname>/`.
- Update architecture dossier content for new name.
- Update all feature docs under `docs/features/checked/orchestrator/`.
- Update API docs: `docs/api/gateway/orchestrator.md`, `docs/api/orchestrator-first-signal.md`.
- Update `AGENTS.md` files (module-local and repo-wide CLAUDE.md references).
- Update `docs/code-of-conduct/CODE_OF_CONDUCT.md` Section 15.1 canonical domain roots table.
- Run repo-wide search for any remaining `orchestrator` references (excluding PostgreSQL schema name, which stays).
- Run full build and test suite to confirm zero regressions.
Completion criteria:
- [ ] All docs renamed and updated.
- [ ] AGENTS.md and CLAUDE.md references updated.
- [ ] CODE_OF_CONDUCT.md domain roots table updated.
- [ ] Zero stale `orchestrator` references remain (except PostgreSQL schema).
- [ ] Full build and test pass.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-02-25 | Sprint created. Rename scope assessed: 3,268 namespace references, 336 C# files, 36 external ProjectReferences, 40+ TypeScript files, Docker/Helm/Compose/Kafka/authority scopes. | Planning |
## Decisions & Risks
- Decision: Orchestrator is renamed to avoid confusion with ReleaseOrchestrator (the core product feature).
- Decision: PostgreSQL schema name `orchestrator` is preserved for data continuity. The factory class maps the new code name to the existing schema.
- Decision: Pre-alpha with zero clients — all API routes, Docker images, authority scopes, and Kafka consumer groups are renamed cleanly without backward-compatibility aliases.
- Risk: Rename scope is large (3,268+ references). Mitigation: automated find-and-replace with manual review for edge cases (serialized type names, reflection, string interpolation).
- Risk: missed references cause runtime failures. Mitigation: repo-wide grep for old name as final validation step. PostgreSQL schema exclusion must be explicit and documented.
- Risk: Helm/Compose rename coordination with any active deployment. Mitigation: pre-alpha with no production deployments.
## Next Checkpoints
- Milestone 1: name decided and mapping document approved.
- Milestone 2: source + infrastructure + frontend rename complete.
- Milestone 3: compiled models regenerated, full build/test pass, docs updated.

View File

@@ -0,0 +1,104 @@
# Sprint 20260305-002 - JobEngine Storage Completion (PacksRegistry and TaskRunner)
## Topic & Scope
- Complete the remaining delivery gap for Point 1: Postgres-first metadata/state with production-ready object-store blob handling for `PacksRegistry` and `TaskRunner`.
- Preserve deterministic replay semantics while removing non-dev ambiguity in storage-driver behavior.
- Align runtime wiring, compose overlays, and tests so storage mode is explicit and verifiable.
- Working directory: `src/JobEngine`.
- Expected evidence: targeted persistence/integration test passes, compose config validation output, and updated JobEngine/platform architecture docs.
## Dependencies & Concurrency
- Depends on shared storage contract documented in `docs/modules/platform/architecture.md`.
- Can run in parallel with Replay, Remediation, and Platform boundary sprints.
- Documentation cleanup sprint (`SPRINT_20260305_006_DOCS_webservice_catalog_and_domain_consistency.md`) depends on final runtime behavior from this sprint.
## Documentation Prerequisites
- `docs/modules/platform/architecture.md`
- `docs/modules/jobengine/architecture.md`
- `src/JobEngine/StellaOps.PacksRegistry/StellaOps.PacksRegistry.WebService/Program.cs`
- `src/JobEngine/StellaOps.TaskRunner/StellaOps.TaskRunner.WebService/Program.cs`
- `docs/implplan/CONSOLIDATION_WEBSERVICE_FUNCTION_DB_MATRIX_20260305.md`
## Delivery Tracker
### JOBENG-STOR-001 - Reconcile declared driver contract with actual runtime behavior
Status: TODO
Dependency: none
Owners: Project Manager, Implementer
Task description:
- Produce a precise behavior matrix for `Storage:Driver` and `Storage:ObjectStore:Driver` for both services.
- Confirm and document current mismatch points (for example, drivers accepted by validation but not backed by concrete adapter behavior).
Completion criteria:
- [ ] Behavior matrix committed under module docs with config keys, defaults, and startup fail-fast rules.
- [ ] Every accepted driver value is either fully implemented or explicitly rejected with deterministic startup failure.
### JOBENG-STOR-002 - Implement production RustFS object-store adapters for blob payloads
Status: TODO
Dependency: JOBENG-STOR-001
Owners: Implementer, Test Automation
Task description:
- Implement and wire RustFS/S3-compatible blob adapters for:
- `PacksRegistry` pack/provenance/attestation payload channels.
- `TaskRunner` run artifact payload channel.
- Preserve existing Postgres-backed metadata stores and deterministic ordering semantics.
Completion criteria:
- [ ] `Storage:ObjectStore:Driver=rustfs` uses concrete RustFS adapter implementations in both services.
- [ ] Existing `seed-fs` behavior remains supported for local/offline deterministic workflows.
- [ ] Non-development startup fails when RustFS is configured without required endpoint/credentials settings.
### JOBENG-STOR-003 - Harden non-development startup behavior and fallback policy
Status: TODO
Dependency: JOBENG-STOR-002
Owners: Implementer
Task description:
- Remove silent non-dev behavior drift by enforcing explicit fail-fast for missing Postgres/object-store configuration.
- Ensure development-only fallback behavior is intentional, documented, and test-covered.
Completion criteria:
- [ ] Non-development runtime has no implicit filesystem fallback for stores expected to be Postgres-backed.
- [ ] Error messages are actionable and identify missing config keys.
- [ ] Startup behavior is covered by automated tests for success/failure modes.
### JOBENG-STOR-004 - Expand deterministic storage tests across drivers
Status: TODO
Dependency: JOBENG-STOR-002
Owners: Test Automation
Task description:
- Add targeted tests that validate parity across `postgres + seed-fs` and `postgres + rustfs`.
- Include replay-critical assertions for stable ordering, digest consistency, and tenant isolation.
Completion criteria:
- [ ] Targeted test projects include both happy-path and misconfiguration-path assertions.
- [ ] Evidence captures command output and test counts for each driver profile.
- [ ] No regression in existing persistence tests for Postgres repositories.
### JOBENG-STOR-005 - Update architecture and operations docs for final storage contract
Status: TODO
Dependency: JOBENG-STOR-003
Owners: Documentation author, Implementer
Task description:
- Update JobEngine and platform storage docs with final runtime contract, config examples, and migration notes.
- Record decisions and residual risks in sprint log and link to docs changed.
Completion criteria:
- [ ] `docs/modules/jobengine/architecture.md` and `docs/modules/platform/architecture.md` reflect final behavior.
- [ ] Compose/ops guidance references valid config keys for both services.
- [ ] Sprint Decisions & Risks includes links to all updated docs.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-03-05 | Sprint created from architecture review; points 1 and 2 were partially implemented and require completion/hardening work. | Project Manager |
## Decisions & Risks
- Current code already wires Postgres state stores for TaskRunner and Postgres persistence extension for PacksRegistry, but remaining object-store adapter parity and fallback hardening are unresolved.
- `PacksRegistry` currently carries an explicit RustFS-not-implemented guard in runtime contract paths; this blocks full completion of Point 1 in production modes.
- `TaskRunner` currently accepts object-store driver values while artifact reading remains filesystem-root based; implementation parity must be enforced to avoid config drift.
- Mitigation: complete adapter implementation and add startup contract tests before documentation sprint declares Point 1 as complete.
## Next Checkpoints
- Driver matrix and gap report complete.
- RustFS adapter PR ready with targeted test evidence.
- Docs and compose parity review complete before marking DONE.

View File

@@ -0,0 +1,93 @@
# Sprint 20260305-003 - Replay Feed Snapshot Storage Completion
## Topic & Scope
- Complete the remaining Replay portion of Point 2: durable Postgres index plus production-ready object-store blob channel behavior.
- Preserve deterministic replay guarantees across storage drivers and deployment profiles.
- Remove ambiguous driver semantics for Replay object storage in non-development runtime.
- Working directory: `src/Replay`.
- Expected evidence: targeted Replay storage tests, startup contract tests, and updated Replay/platform docs.
## Dependencies & Concurrency
- Depends on shared storage contract in `docs/modules/platform/architecture.md`.
- Can run in parallel with JobEngine and Remediation workstreams.
- Documentation cleanup sprint depends on this sprint's final object-store behavior.
## Documentation Prerequisites
- `docs/modules/replay/architecture.md`
- `docs/modules/platform/architecture.md`
- `src/Replay/StellaOps.Replay.WebService/Program.cs`
- `src/Replay/__Tests/StellaOps.Replay.Core.Tests/FeedSnapshots/ReplayFeedSnapshotStoresTests.cs`
- `docs/implplan/CONSOLIDATION_WEBSERVICE_FUNCTION_DB_MATRIX_20260305.md`
## Delivery Tracker
### REPLAY-STOR-001 - Finalize Replay storage driver contract and reject unsupported runtime paths
Status: DOING
Dependency: none
Owners: Project Manager, Implementer
Task description:
- Review current `Storage:Driver` and `Storage:ObjectStore:Driver` behavior and define final accepted production combinations.
- Ensure unsupported combinations fail deterministically at startup with precise error text.
Completion criteria:
- [ ] Contract table is documented with defaults, required keys, and non-dev fail-fast behavior.
- [ ] Contract tests cover valid and invalid storage configuration paths.
### REPLAY-STOR-002 - Implement RustFS blob adapter path or narrow contract explicitly
Status: DOING
Dependency: REPLAY-STOR-001
Owners: Implementer
Task description:
- Implement a concrete RustFS blob adapter for Replay snapshots, or formally narrow the contract to `seed-fs` and remove ambiguous `rustfs` acceptance.
- Keep Postgres index storage unchanged and deterministic.
Completion criteria:
- [x] Runtime behavior matches documented contract without hidden fallback semantics.
- [x] Non-dev deployment profile has one clear supported blob path with deterministic startup validation.
- [ ] Blob read/write paths are integration-tested.
### REPLAY-STOR-003 - Validate deterministic replay behavior under finalized storage modes
Status: BLOCKED
Dependency: REPLAY-STOR-002
Owners: Test Automation
Task description:
- Add or extend tests to verify index/blob persistence consistency, stable ordering, and deterministic replay outputs.
- Execute targeted test runs against Replay core and webservice projects for selected storage modes.
Completion criteria:
- [ ] Replay storage tests cover create/read/list flows and deterministic ordering.
- [ ] Test evidence includes command lines, test counts, and pass/fail status.
- [ ] No regression in existing point-in-time query and verdict replay tests.
### REPLAY-STOR-004 - Update replay docs and storage runbook references
Status: DOING
Dependency: REPLAY-STOR-003
Owners: Documentation author, Implementer
Task description:
- Update Replay module architecture docs with finalized storage contract and operator guidance.
- Link the final contract from platform architecture docs and sprint Decisions & Risks.
Completion criteria:
- [x] `docs/modules/replay/architecture.md` reflects final storage behavior and required config.
- [ ] Platform-level storage contract docs reference Replay accurately.
- [ ] Sprint log links to all updated docs and evidence artifacts.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-03-05 | Sprint created from architecture review; Replay index persistence is in place, but object-store driver contract remains incomplete for production parity. | Project Manager |
| 2026-03-05 | Started REPLAY-STOR-001/002/004: narrowed object-store contract by rejecting `rustfs` at startup and keeping `seed-fs` as the only supported blob driver. | Implementer |
| 2026-03-05 | Updated `docs/modules/replay/architecture.md` storage contract text to match runtime behavior (`seed-fs` only for blob store). | Documentation author |
| 2026-03-05 | REPLAY-STOR-003 blocked by unrelated replay API auth regressions in existing suite: `dotnet test src/Replay/__Tests/StellaOps.Replay.Core.Tests/StellaOps.Replay.Core.Tests.csproj --filter FullyQualifiedName~FeedSnapshots -m:1 -v minimal` ran full suite (`MTP0001` indicates filter ignored) and failed `2/99` with `401` on point-in-time API integration tests. | Test Automation |
## Decisions & Risks
- Replay already resolves Postgres index store with non-dev fail-fast when connection is missing.
- Decision: narrowed Replay blob storage contract to `seed-fs` only; `rustfs` now fails fast in all profiles with an explicit startup error.
- Risk: mixed driver semantics can produce environment-specific behavior drift during incident replay verification.
- Risk: existing replay API integration auth failures currently block a clean green run of the targeted feed-snapshot suite and prevent closing REPLAY-STOR-003.
- Mitigation: resolve/triage auth regression in replay API tests, then rerun targeted storage suite and complete platform-level doc linkage.
## Next Checkpoints
- Storage contract decision recorded (narrowed to `seed-fs` blob driver).
- Resolve replay API auth test failures and rerun targeted feed-snapshot suite.
- Complete platform storage-contract doc linkage once REPLAY-STOR-003 is unblocked.

View File

@@ -0,0 +1,116 @@
# Sprint 20260305-004 - Remediation Postgres Runtime Wiring and Service Standardization
## Topic & Scope
- Complete Point 3 by wiring Remediation runtime to real Postgres data source and removing implicit in-memory production behavior.
- Bring Remediation webservice in line with StellaOps webservice baseline (router/local hostname integration, explicit storage contract, deterministic startup rules).
- Add missing module-level AGENTS contract for `src/Remediation`.
- Working directory: `src/Remediation`.
- Expected evidence: Remediation webservice startup contract tests, persistence integration tests, and updated module docs/AGENTS.
## Dependencies & Concurrency
- Depends on platform storage contract from `docs/modules/platform/architecture.md`.
- Can run in parallel with JobEngine, Replay, and Platform boundary sprints.
- Documentation cleanup sprint depends on this sprint for final Remediation inventory and host/path metadata.
## Documentation Prerequisites
- `docs/modules/remediation/architecture.md`
- `src/Remediation/StellaOps.Remediation.WebService/Program.cs`
- `src/Remediation/StellaOps.Remediation.Persistence/Postgres/RemediationDataSource.cs`
- `src/Remediation/StellaOps.Remediation.Persistence/Repositories/PostgresFixTemplateRepository.cs`
- `src/Remediation/StellaOps.Remediation.Persistence/Repositories/PostgresPrSubmissionRepository.cs`
- `src/Remediation/StellaOps.Remediation.Persistence/Repositories/PostgresMarketplaceSourceRepository.cs`
## Delivery Tracker
### REMED-RUNTIME-001 - Create module-local AGENTS contract for Remediation
Status: DONE
Dependency: none
Owners: Project Manager, Documentation author
Task description:
- Add `src/Remediation/AGENTS.md` with required reading, working directory scope, deterministic/testing requirements, and endpoint metadata.
- Ensure repo-wide and module-level instructions are aligned and enforceable for implementers.
Completion criteria:
- [x] `src/Remediation/AGENTS.md` exists and is consistent with repo-wide AGENTS rules.
- [x] Sprint docs reference the new module-local AGENTS contract.
### REMED-RUNTIME-002 - Replace parameterless repository wiring with data-source-backed DI
Status: DONE
Dependency: REMED-RUNTIME-001
Owners: Implementer
Task description:
- Register and inject `RemediationDataSource` and remove parameterless repository construction from webservice runtime.
- Preserve deterministic behavior while ensuring non-dev runtime does not silently degrade to in-memory mode.
Completion criteria:
- [x] Webservice DI uses data-source-backed repository constructors.
- [x] Non-development startup fails fast when required Postgres config is missing.
- [x] In-memory mode remains explicit and test-profile scoped only.
### REMED-RUNTIME-003 - Add standard webservice integration hooks and policy-safe defaults
Status: DONE
Dependency: REMED-RUNTIME-002
Owners: Implementer
Task description:
- Align Remediation host with standard middleware and service integrations used by peer webservices:
- Router microservice integration.
- Local hostname logging/binding.
- Explicit CORS and auth policy conventions matching module scope.
Completion criteria:
- [x] Remediation host exposes deterministic local alias behavior (`*.stella-ops.local`) consistent with platform conventions.
- [x] Router integration and endpoint exposure are documented and test-verified.
- [x] Authz policy behavior is explicit and covered in tests.
### REMED-RUNTIME-004 - Add persistence and startup contract tests
Status: DONE
Dependency: REMED-RUNTIME-002
Owners: Test Automation
Task description:
- Add targeted tests validating startup contract behavior for:
- valid Postgres configuration.
- missing Postgres configuration in non-development profile.
- explicit in-memory test profile behavior.
- Add integration tests for repository CRUD paths against Postgres fixture.
Completion criteria:
- [x] Tests assert deterministic ordering and tenant-safe behavior for repository operations.
- [x] Startup contract tests fail when configuration contract is violated.
- [x] Evidence includes command output and test counts.
### REMED-RUNTIME-005 - Update Remediation architecture docs and migration notes
Status: DONE
Dependency: REMED-RUNTIME-004
Owners: Documentation author, Implementer
Task description:
- Update module architecture docs to reflect final runtime wiring and configuration contract.
- Record migration guidance from current behavior to finalized storage mode.
Completion criteria:
- [x] `docs/modules/remediation/architecture.md` matches implemented runtime behavior.
- [x] Sprint Decisions & Risks links all relevant docs and test evidence.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-03-05 | Sprint created after architecture review identified Remediation runtime still using parameterless repository constructors and in-memory fallback behavior. | Project Manager |
| 2026-03-05 | REMED-RUNTIME-001 completed: added `src/Remediation/AGENTS.md` with scope, required reading, and deterministic/testing rules. | Implementer |
| 2026-03-05 | Started REMED-RUNTIME-002/003/004/005: switched webservice to storage-driver contract wiring, added router/local-hostname integration, and added startup-contract tests plus architecture doc updates. | Implementer |
| 2026-03-05 | Test evidence: `dotnet test src/Remediation/__Tests/StellaOps.Remediation.WebService.Tests/StellaOps.Remediation.WebService.Tests.csproj -m:1 -v minimal` -> Passed `8/8`; includes startup contract and source endpoint integration checks. | Test Automation |
| 2026-03-05 | Test evidence: `dotnet test src/Remediation/__Tests/StellaOps.Remediation.Tests/StellaOps.Remediation.Tests.csproj -m:1 -v minimal` -> Passed `28/28` (with existing `MTP0001` warning from project settings). | Test Automation |
| 2026-03-05 | REMED-RUNTIME-002/003/004/005 marked DONE after runtime wiring, router/local alias integration, startup tests, and architecture migration notes were merged. | Implementer |
## Decisions & Risks
- Decision: Remediation webservice now defaults to `Storage:Driver=postgres` with explicit startup failure when Postgres connection settings are absent.
- Decision: `Storage:Driver=inmemory` is allowed only in `Test`/`Testing` profiles to keep non-test deployments from silently degrading to process memory.
- Decision: Remediation host now follows baseline webservice integration (`AddRouterMicroservice`, `TryAddStellaOpsLocalBinding`, `LogStellaOpsLocalHostname`, `UseStellaOpsCors`).
- References:
- `src/Remediation/AGENTS.md`
- `src/Remediation/StellaOps.Remediation.WebService/Program.cs`
- `src/Remediation/__Tests/StellaOps.Remediation.WebService.Tests/RemediationStartupContractTests.cs`
- `docs/modules/remediation/architecture.md`
- Residual risk: production startup still cannot validate Postgres connectivity without invoking repository operations.
- Mitigation: add explicit connectivity health probe in follow-up ops hardening if required.
## Next Checkpoints
- Completed for this sprint stream; handoff can proceed to cross-sprint docs synchronization (`SPRINT_20260305_006_DOCS_webservice_catalog_and_domain_consistency.md`).

View File

@@ -0,0 +1,95 @@
# Sprint 20260305-005 - Platform Read-Model Boundary Enforcement
## Topic & Scope
- Execute Point 4 by formalizing and enforcing Platform read-model boundaries to prevent cross-module persistence coupling drift.
- Preserve aggregation behavior while introducing explicit contract and test guardrails for future changes.
- Ensure migration-management dependencies are clearly separated from runtime query dependencies.
- Working directory: `src/Platform`.
- Expected evidence: boundary inventory, guard tests, updated architecture dossier/ADR, and endpoint-level verification.
## Dependencies & Concurrency
- Depends on current Platform architecture docs and runtime service inventory.
- Can run in parallel with storage sprints for JobEngine/Replay/Remediation.
- Documentation cleanup sprint depends on final boundary statement from this sprint.
## Documentation Prerequisites
- `docs/modules/platform/architecture-overview.md`
- `docs/modules/platform/architecture.md`
- `src/Platform/StellaOps.Platform.WebService/Program.cs`
- `src/Platform/StellaOps.Platform.WebService/Services/TopologyReadModelService.cs`
- `src/Platform/StellaOps.Platform.WebService/Services/SecurityReadModelService.cs`
- `src/Platform/StellaOps.Platform.WebService/Services/IntegrationsReadModelService.cs`
- `src/Platform/__Libraries/StellaOps.Platform.Database/MigrationModulePlugins.cs`
## Delivery Tracker
### PLATFORM-BOUND-001 - Produce runtime dependency inventory and classify boundary risks
Status: TODO
Dependency: none
Owners: Project Manager, Implementer
Task description:
- Inventory Platform runtime dependencies and classify each as:
- allowed runtime read-model dependency.
- migration-only dependency.
- prohibited cross-module persistence coupling.
- Capture inventory output in module docs so future reviewers can validate changes quickly.
Completion criteria:
- [ ] Inventory table committed with explicit allowed/prohibited categories.
- [ ] Every cross-module reference in Platform runtime code is justified or queued for remediation.
### PLATFORM-BOUND-002 - Add enforceable guard tests for persistence boundary violations
Status: TODO
Dependency: PLATFORM-BOUND-001
Owners: Implementer, Test Automation
Task description:
- Add architecture-style tests that fail if `StellaOps.Platform.WebService` references foreign module DbContext/persistence internals outside approved contracts.
- Keep migration plugin assembly scanning excluded from runtime boundary assertions by explicit allowlist.
Completion criteria:
- [ ] Guard tests fail on introduced boundary violations.
- [ ] Allowlist exceptions are minimal and documented.
- [ ] Test project and commands are documented in sprint evidence.
### PLATFORM-BOUND-003 - Introduce explicit query contract interfaces where boundary is implicit
Status: TODO
Dependency: PLATFORM-BOUND-001
Owners: Implementer
Task description:
- For any remaining implicit data coupling paths, introduce explicit query interfaces/adapters to make dependency direction clear.
- Preserve deterministic ordering and tenant isolation semantics of existing read-model endpoints.
Completion criteria:
- [ ] Runtime read-model services depend on explicit contracts rather than ad-hoc persistence internals.
- [ ] Endpoint behavior remains backward-compatible or includes versioned contract notes.
- [ ] Deterministic ordering tests remain green.
### PLATFORM-BOUND-004 - Document boundary policy and migration/runtime separation
Status: TODO
Dependency: PLATFORM-BOUND-002
Owners: Documentation author, Implementer
Task description:
- Update Platform architecture docs with a "runtime boundary policy" section.
- Add clear guidance differentiating:
- migration orchestration references (allowed in database module plugins).
- runtime read-model dependencies (must stay behind explicit contracts).
Completion criteria:
- [ ] `docs/modules/platform/architecture.md` and/or `architecture-overview.md` include boundary policy text and examples.
- [ ] Decision log links to updated docs and guard test evidence.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-03-05 | Sprint created to execute architecture Point 4 and prevent Platform cross-module coupling regressions. | Project Manager |
## Decisions & Risks
- Platform runtime currently uses in-service read-model services; this sprint codifies and enforces that boundary rather than assuming it remains stable.
- `StellaOps.Platform.Database` migration plugins intentionally reference multiple module persistence assemblies; runtime boundary tests must not conflate migration wiring with runtime coupling.
- Risk: over-restrictive guards can block valid evolution.
- Mitigation: maintain explicit allowlist and update via documented architectural decisions only.
## Next Checkpoints
- Dependency inventory reviewed.
- Guard tests merged and running in CI.
- Boundary policy documented and referenced by docs sprint.

View File

@@ -0,0 +1,129 @@
# Sprint 20260305-006 - Docs Webservice Catalog and Domain Consistency
## Topic & Scope
- Deliver the documentation improvements needed to support points 1-4 implementation and handoff.
- Create one canonical service catalog for webservice domain, hostname, purpose, and persistence backing.
- Resolve stale path/hostname inconsistencies across architecture and operations docs.
- Working directory: `docs`.
- Expected evidence: updated docs pages, link/path validation output, and cross-sprint references in Decisions & Risks.
## Dependencies & Concurrency
- Depends on finalized behavior from:
- `SPRINT_20260305_002_JobEngine_packsregistry_taskrunner_storage_completion.md`
- `SPRINT_20260305_003_Replay_feed_snapshot_storage_completion.md`
- `SPRINT_20260305_004_Remediation_postgres_runtime_wiring.md`
- `SPRINT_20260305_005_Platform_read_model_boundary_enforcement.md`
- Can start in parallel for baseline cleanup, then finalize after implementation sprints converge.
## Documentation Prerequisites
- `docs/implplan/CONSOLIDATION_WEBSERVICE_FUNCTION_DB_MATRIX_20260305.md`
- `docs/technical/architecture/port-registry.md`
- `docs/modules/router/webservices-valkey-rollout-matrix.md`
- `docs/quickstart.md`
- `docs/INSTALL_GUIDE.md`
- `docs/modules/platform/architecture.md`
- `docs/technical/architecture/README.md`
## Delivery Tracker
### DOCS-SVC-001 - Publish canonical webservice catalog page
Status: TODO
Dependency: none
Owners: Documentation author, Project Manager
Task description:
- Create a canonical service-catalog doc listing each webservice with:
- module domain.
- local hostname/domain alias.
- purpose/functional surface summary.
- persistence mode and primary backing technology.
- source path and owner module.
- Mark this catalog as source-of-truth and link it from architecture index pages.
Completion criteria:
- [ ] Canonical catalog exists under `docs/technical/architecture/`.
- [ ] `docs/technical/architecture/README.md` links to the catalog.
- [ ] Catalog includes all active webservices, including Remediation.
### DOCS-SVC-002 - Correct stale path and service-name drift in port registry
Status: TODO
Dependency: DOCS-SVC-001
Owners: Documentation author
Task description:
- Update `docs/technical/architecture/port-registry.md` entries whose source paths no longer match repository layout.
- Add or correct missing service rows where runtime services exist but are absent/inaccurate.
Completion criteria:
- [ ] All path references in the port table resolve to existing directories.
- [ ] Service naming/path mapping matches current module consolidation layout.
- [ ] Port registry includes Remediation or documents its absence with explicit rationale and follow-up.
### DOCS-SVC-003 - Standardize runtime hostname/domain convention guidance
Status: TODO
Dependency: DOCS-SVC-001
Owners: Documentation author
Task description:
- Define canonical runtime hostname form (`*.stella-ops.local`) and document permitted exceptions.
- Normalize conflicting usage examples across quickstart, operations, and API docs.
- Preserve intentional schema ID and non-runtime examples where needed, with explicit explanation.
Completion criteria:
- [ ] Runtime URL examples are consistent with canonical hostname convention.
- [ ] Exception policy is documented (schema IDs, synthetic examples, external references).
- [ ] Search audit evidence is captured in sprint log.
### DOCS-SVC-004 - Update router rollout inventory and service integration docs
Status: TODO
Dependency: DOCS-SVC-002
Owners: Documentation author, Implementer
Task description:
- Update router rollout matrix and integration guide to include missing/renamed services and current route ownership.
- Ensure service hostnames and route prefixes align with the canonical service catalog.
Completion criteria:
- [ ] `docs/modules/router/webservices-valkey-rollout-matrix.md` is synchronized with active service inventory.
- [ ] Missing Remediation routing status is explicitly tracked.
- [ ] Route ownership and fallback notes are current and actionable.
### DOCS-SVC-005 - Synchronize consolidation matrix with verified runtime state
Status: TODO
Dependency: DOCS-SVC-001
Owners: Documentation author, Project Manager
Task description:
- Refresh `CONSOLIDATION_WEBSERVICE_FUNCTION_DB_MATRIX_20260305.md` so per-service DB rows match current code.
- Remove contradictory statements between matrix rows and later remediation-status sections.
Completion criteria:
- [ ] DB/Persistence column reflects verified runtime wiring.
- [ ] Contradictions are removed and replaced by one clear status statement.
- [ ] Matrix references point to current source file paths.
### DOCS-SVC-006 - Add lightweight docs validation for service-path and hostname drift
Status: TODO
Dependency: DOCS-SVC-002
Owners: Test Automation, Documentation author
Task description:
- Add a deterministic docs validation script/check for:
- unresolved service path references in registry tables.
- forbidden runtime hostname variants where canonical form is required.
- Integrate check into docs/testing guidance and optionally CI path filters.
Completion criteria:
- [ ] Validation command/script is documented and runnable locally.
- [ ] At least one failing fixture/case demonstrates drift detection.
- [ ] Sprint log captures validation command output.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-03-05 | Sprint created to execute documentation improvements and provide an actionable handoff surface for points 1-4. | Project Manager |
## Decisions & Risks
- Current docs contain drift between inventory, runtime wiring notes, and path/domain conventions; this blocks efficient multi-agent execution.
- Canonical catalog and validation checks are required to keep docs synchronized after module consolidation work.
- Risk: broad doc edits can unintentionally rewrite historical examples.
- Mitigation: document exception policy and scope normalization to runtime/service-discovery contexts first.
## Next Checkpoints
- Canonical service catalog draft completed and linked.
- Port registry and router inventory path verification complete.
- Hostname normalization pass completed with validation evidence.