enrich the setup. setup fixes. minimize the consolidation plan
This commit is contained in:
master
@@ -11,8 +11,8 @@
|
||||
## 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 (VexLens) depends on this sprint** — Excititor feeds VexHub. Sprint 205 must start after Sprint 203 source layout consolidation (TASK-203-002) is complete, or VexHub's ProjectReference paths to Excititor will break.
|
||||
- **Sprint 220 (SbomService → Scanner)** — SbomService.WebService references `StellaOps.Excititor.Persistence`. If Sprint 220 runs after this sprint, the SbomService .csproj must point to Excititor's new path under `src/Concelier/`.
|
||||
- **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
|
||||
@@ -112,4 +112,3 @@ Completion criteria:
|
||||
- Milestone 2: CLI/Web references updated and builds pass.
|
||||
- Milestone 3: docs updated and sprint ready for closure.
|
||||
|
||||
|
||||
|
||||
@@ -1,109 +0,0 @@
|
||||
# Sprint 205 - VEX Domain: VexHub and VexLens Consolidation
|
||||
|
||||
## Topic & Scope
|
||||
- Consolidate VEX aggregation and adjudication into a single VEX domain ownership model.
|
||||
- Move VexHub source ownership under VexLens domain while keeping deployables independent.
|
||||
- Merge VexHub and VexLens EF Core DbContexts into one domain DbContext. PostgreSQL schemas (`vexhub`, `vexlens`) remain separate; this is a code-level consolidation, not a schema merge.
|
||||
- Working directory: `src/VexLens/`.
|
||||
- Cross-module edits explicitly allowed for UI/runtime integration paths (`src/Web/`, `src/Cli/`, `devops/compose/`) as listed in tasks.
|
||||
- Expected evidence: no API regressions, successful DB merge rollout, and stable VEX ingestion/adjudication behavior.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- **Upstream dependency: Sprint 203 (Concelier absorbs Excititor)** — Excititor feeds VexHub. Sprint 203 moves Excititor into `src/Concelier/`. VexHub's ProjectReferences to Excititor must use post-203 paths, so Sprint 203 TASK-203-002 must be complete before this sprint starts TASK-205-002.
|
||||
- Can run in parallel with non-VEX/non-advisory consolidation sprints.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- Read `docs/modules/vex-hub/architecture.md`.
|
||||
- Read `docs/modules/vex-lens/architecture.md`.
|
||||
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### TASK-205-001 - Define VEX domain contract and schema ownership
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Map current VexHub and VexLens DbContext/table ownership.
|
||||
- Document PostgreSQL schema ownership (`vexhub`, `vexlens`) and confirm schemas remain separate.
|
||||
- Confirm zero entity name collisions between VexHubDbContext and VexLensDbContext (9 total entities, no overlaps).
|
||||
- Document the DbContext merge plan: combine into one VEX domain DbContext while keeping schemas separate.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] VEX domain schema ownership documented.
|
||||
- [ ] Zero-collision confirmation recorded.
|
||||
- [ ] DbContext merge plan approved.
|
||||
|
||||
### TASK-205-002 - Consolidate source layout under VEX domain module
|
||||
Status: TODO
|
||||
Dependency: TASK-205-001
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Move VexHub source/projects under `src/VexLens/` domain layout.
|
||||
- Preserve deployable runtime identities and project names.
|
||||
- Update all project and solution references.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] VexHub source relocated under VexLens domain.
|
||||
- [ ] Solution and project references compile.
|
||||
- [ ] Legacy `src/VexHub/` root removed.
|
||||
|
||||
### TASK-205-003 - Merge VEX DbContexts and regenerate compiled models
|
||||
Status: TODO
|
||||
Dependency: TASK-205-001
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Merge VexHubDbContext entities into VexLensDbContext (or create a unified VexDomainDbContext).
|
||||
- PostgreSQL schemas (`vexhub`, `vexlens`) remain separate — this is a DbContext-level consolidation only, not a schema merge. No data migration, no dual-write, no backfill.
|
||||
- Regenerate EF compiled models using `dotnet ef dbcontext optimize`.
|
||||
- Verify `<Compile Remove>` entry for compiled model assembly attributes in `.csproj`.
|
||||
- Run targeted integration tests against the merged context to confirm query behavior unchanged.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] VEX DbContexts merged into a single domain context.
|
||||
- [ ] PostgreSQL schemas remain separate (no data migration).
|
||||
- [ ] EF compiled models regenerated and committed.
|
||||
- [ ] Integration tests pass with merged context.
|
||||
|
||||
### TASK-205-004 - Update Web, infra, build/test, and docs
|
||||
Status: TODO
|
||||
Dependency: TASK-205-002, TASK-205-003
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Validate/update Web integration points:
|
||||
- `src/Web/StellaOps.Web/proxy.conf.json` (`/vexhub`).
|
||||
- `src/Web/StellaOps.Web/src/app/app.config.ts` (`VEX_HUB_API_BASE_URL`, `VEX_LENS_API_BASE_URL`).
|
||||
- `src/Web/StellaOps.Web/src/app/core/config/app-config.service.ts` (`vexhub -> vex`).
|
||||
- Update compose/workflows for moved source paths.
|
||||
- Build/test VEX domain and dependent integration paths.
|
||||
- Update and archive module docs to reflect domain-first model.
|
||||
- Add ADR entry to `docs/modules/vex-lens/architecture.md` documenting the DbContext merge decision.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Web references validated or updated.
|
||||
- [ ] Compose/workflow paths updated.
|
||||
- [ ] Builds/tests pass.
|
||||
- [ ] Docs updated for VEX domain + DbContext merge.
|
||||
- [ ] ADR entry recorded.
|
||||
|
||||
## 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 VEX consolidation with explicit VexHub/VexLens DB merge phases. | Planning |
|
||||
| 2026-02-25 | DB merge simplified after deep analysis: 9 entities with zero collisions. DbContext merge only (no schema merge, no dual-write, no backfill). Schemas remain separate. Sprint reduced from 5 tasks to 4. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: VexHub and VexLens DbContexts merge into one domain DbContext. PostgreSQL schemas remain separate.
|
||||
- Rationale: 9 total entities with zero name collisions makes DbContext consolidation safe and low-risk. All data already in `stellaops_platform`. Schemas stay separate for clean lifecycle boundaries.
|
||||
- Decision: Existing public VEX APIs remain backward compatible.
|
||||
- Risk: adjudication result drift after DbContext merge. Mitigation: targeted integration tests with merged context before deploying.
|
||||
- Note: EF compiled model regeneration is required after DbContext merge (TASK-205-003).
|
||||
|
||||
## Next Checkpoints
|
||||
- Milestone 1: VEX domain contract documented and source layout consolidated.
|
||||
- Milestone 2: DbContext merge complete with compiled models regenerated.
|
||||
- Milestone 3: Web/infra updated and docs finalized.
|
||||
|
||||
|
||||
@@ -1,106 +1,108 @@
|
||||
# Sprint 206 - Policy Domain: Policy and Unknowns Consolidation
|
||||
# Sprint 206 - Policy/Unknowns Boundary Preservation (No Consolidation)
|
||||
|
||||
## Topic & Scope
|
||||
- Consolidate policy decisioning and unknowns handling into one Policy domain.
|
||||
- Move Unknowns source ownership under `src/Policy/` while preserving runtime service contracts.
|
||||
- Remove empty UnknownsDbContext placeholder (zero entities, no tables). PolicyDbContext and its schemas remain unchanged.
|
||||
- Working directory: `src/Policy/`.
|
||||
- Cross-module edits explicitly allowed for dependent consumers and UI/CLI integration (`src/Platform/`, `src/Scanner/`, `src/Cli/`, `src/Web/`, `devops/compose/`) as listed in tasks.
|
||||
- Expected evidence: policy/unknowns APIs remain stable, DB merge executed with reconciliation, and dependent modules continue to build.
|
||||
- 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 Unknowns module docs/AGENTS in current source tree.
|
||||
- Read `src/Unknowns/AGENTS.md` and `src/Policy/AGENTS.md`.
|
||||
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### TASK-206-001 - Verify Unknowns has no persistence and document Policy domain schema ownership
|
||||
### TASK-206-001 - Re-baseline Unknowns runtime and persistence reality
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Verify UnknownsDbContext has zero entities (confirmed: empty placeholder with no tables, no data).
|
||||
- Document PolicyDbContext schema ownership and confirm it remains unchanged.
|
||||
- Record the domain boundary decision: Unknowns is absorbed as source only; its empty DbContext placeholder is deleted.
|
||||
- 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:
|
||||
- [ ] UnknownsDbContext zero-entity status confirmed.
|
||||
- [ ] Policy domain schema ownership documented.
|
||||
- [ ] Absorption decision recorded.
|
||||
- [ ] Active Unknowns persistence context confirmed and documented.
|
||||
- [ ] Unknowns runtime service surface confirmed and documented.
|
||||
- [ ] Consumer list captured from project references.
|
||||
|
||||
### TASK-206-002 - Consolidate Unknowns source under Policy domain module
|
||||
### TASK-206-002 - Record decision: keep Unknowns as standalone microservice + DB owner
|
||||
Status: TODO
|
||||
Dependency: TASK-206-001
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Move Unknowns projects into Policy domain source layout.
|
||||
- Preserve runtime service identities and external API contracts.
|
||||
- Update all project/solution references including Platform and Scanner consumers.
|
||||
- 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:
|
||||
- [ ] Unknowns source relocated under Policy domain.
|
||||
- [ ] References compile across Policy, Platform, and Scanner.
|
||||
- [ ] Legacy `src/Unknowns/` root removed.
|
||||
- [ ] No-consolidation decision recorded in sprint.
|
||||
- [ ] Unknowns/Policy architecture docs updated with explicit boundary statement.
|
||||
- [ ] Stale "empty DbContext delete" language removed.
|
||||
|
||||
### TASK-206-003 - Remove empty UnknownsDbContext placeholder
|
||||
### TASK-206-003 - Validate integration contracts without consolidation
|
||||
Status: TODO
|
||||
Dependency: TASK-206-001
|
||||
Dependency: TASK-206-002
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Delete the UnknownsDbContext class and its empty persistence project (zero entities, zero tables).
|
||||
- If Unknowns has any configuration that referenced a separate connection string, redirect to PolicyDbContext's connection or remove.
|
||||
- No data migration needed (zero entities means zero data). No dual-write, no backfill, no cutover.
|
||||
- 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:
|
||||
- [ ] UnknownsDbContext deleted.
|
||||
- [ ] No orphaned connection strings or configuration keys.
|
||||
- [ ] Policy domain builds without the removed placeholder.
|
||||
- [ ] Affected projects build successfully.
|
||||
- [ ] No broken ProjectReference paths.
|
||||
- [ ] No accidental consolidation changes required.
|
||||
|
||||
### TASK-206-004 - CLI/Web/infrastructure updates, tests, and docs
|
||||
### TASK-206-004 - CLI/Web/infra reference validation for preserved boundary
|
||||
Status: TODO
|
||||
Dependency: TASK-206-002, TASK-206-003
|
||||
Dependency: TASK-206-003
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Validate/update CLI unknowns references:
|
||||
- `src/Cli/StellaOps.Cli/Commands/UnknownsCommandGroup.cs`.
|
||||
- `src/Cli/StellaOps.Cli/cli-routes.json` compatibility aliases.
|
||||
- Validate/update Web policy/unknowns references:
|
||||
- `src/Web/StellaOps.Web/proxy.conf.json` (`/policyGateway`).
|
||||
- `src/Web/StellaOps.Web/src/app/core/config/app-config.service.ts` policy key mapping.
|
||||
- Validate infra references (`STELLAOPS_POLICY_GATEWAY_URL`, `STELLAOPS_UNKNOWNS_URL`) and compose/build paths.
|
||||
- Build/test affected modules and update docs for domain-first model.
|
||||
- Add ADR entry to `docs/modules/policy/architecture.md` documenting the Unknowns absorption and DbContext deletion.
|
||||
- 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 and Web references validated or updated.
|
||||
- [ ] Infra references verified.
|
||||
- [ ] Builds/tests pass for affected modules.
|
||||
- [ ] Docs updated and legacy module docs archived.
|
||||
- [ ] ADR entry recorded.
|
||||
- [ ] 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. | 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 Policy consolidation with Unknowns DB merge phases. | Planning |
|
||||
| 2026-02-25 | DB merge simplified after deep analysis: UnknownsDbContext is an empty placeholder (0 entities, 0 tables). No data migration needed — just delete the empty DbContext. Sprint reduced from 6 tasks to 4. | Planning |
|
||||
| 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: Policy and Unknowns are one domain ownership model with compatible runtime APIs.
|
||||
- Rationale: UnknownsDbContext has zero entities — it is an empty placeholder. The "merge" is simply deleting the empty class. PolicyDbContext and its schemas remain unchanged. No data migration, no risk.
|
||||
- Decision: API paths remain backward compatible.
|
||||
- Risk: scanner/platform dependencies break after source move. Mitigation: targeted consumer build/test gates.
|
||||
- Note: PolicyDbContext has compiled models generated by Sprint 219. These are unaffected by the Unknowns source move since UnknownsDbContext has no entities to merge.
|
||||
- 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: Unknowns empty-DbContext status confirmed and source consolidated.
|
||||
- Milestone 2: Empty DbContext deleted and CLI/Web references updated.
|
||||
- Milestone 3: docs refreshed and sprint ready for closure.
|
||||
|
||||
|
||||
- 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.
|
||||
|
||||
@@ -1,101 +1,97 @@
|
||||
# Sprint 209 - Notify: Absorb Notifier Module
|
||||
# Sprint 209 - Notify/Notifier Boundary Preservation (No Consolidation)
|
||||
|
||||
## Topic & Scope
|
||||
- Consolidate `src/Notifier/` (2 csproj: WebService + Worker) into `src/Notify/`.
|
||||
- Notifier is a thin deployment host for Notify libraries. The 2025-11-02 separation decision should be revisited.
|
||||
- Working directory: `src/Notifier/`, `src/Notify/`.
|
||||
- Expected evidence: clean build, all tests pass.
|
||||
- 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 dependencies. Can run in parallel.
|
||||
- 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 - Verify Notifier is purely a host
|
||||
### TASK-209-001 - Baseline current Notify/Notifier runtime boundaries
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Confirm `StellaOps.Notifier.WebService` only references Notify libraries (no unique logic).
|
||||
- Confirm `StellaOps.Notifier.Worker` only references Notify libraries.
|
||||
- Check for any Notifier-specific configuration, middleware, or endpoints not in Notify.
|
||||
- Confirm zero external consumers of Notifier packages.
|
||||
- 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:
|
||||
- [ ] Notifier confirmed as pure host
|
||||
- [ ] No unique logic identified
|
||||
- [ ] Notify/Notifier route matrix documented.
|
||||
- [ ] Complexity and endpoint-gap evidence recorded.
|
||||
- [ ] Consumer reference scan result recorded.
|
||||
|
||||
### TASK-209-002 - Move Notifier into Notify
|
||||
### TASK-209-002 - Record decision to keep split deployment model
|
||||
Status: TODO
|
||||
Dependency: TASK-209-001
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Move `src/Notifier/StellaOps.Notifier.WebService/` → `src/Notify/StellaOps.Notifier.WebService/`.
|
||||
- Move `src/Notifier/StellaOps.Notifier.Worker/` → `src/Notify/StellaOps.Notifier.Worker/`.
|
||||
- Move tests → `src/Notify/__Tests/`.
|
||||
- Update `ProjectReference` paths (now local to Notify).
|
||||
- Add to Notify solution.
|
||||
- Remove `src/Notifier/`.
|
||||
- Update root solution.
|
||||
- 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:
|
||||
- [ ] Both projects moved
|
||||
- [ ] Notify solution includes Notifier
|
||||
- [ ] Old directory removed
|
||||
- [ ] No-consolidation decision recorded in sprint.
|
||||
- [ ] Notify/notifier docs updated with explicit split rationale.
|
||||
- [ ] Stale thin-host assumptions removed.
|
||||
|
||||
### TASK-209-003 - Update Docker, CI, build, and test
|
||||
### TASK-209-003 - Validate builds and key contracts without consolidation
|
||||
Status: TODO
|
||||
Dependency: TASK-209-002
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Update `devops/compose/` for Notifier services.
|
||||
- Update `.gitea/workflows/`.
|
||||
- `dotnet build src/Notify/` — must succeed.
|
||||
- Run all Notify + Notifier tests.
|
||||
- `dotnet build StellaOps.sln`.
|
||||
- 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:
|
||||
- [ ] Docker and CI updated
|
||||
- [ ] All builds and tests pass
|
||||
- [ ] Builds pass for Notify, Notifier, and representative consumer(s).
|
||||
- [ ] API compatibility assumptions documented.
|
||||
|
||||
### TASK-209-004 - Update documentation and CLI/Web references
|
||||
### TASK-209-004 - Finalize docs and follow-up backlog items
|
||||
Status: TODO
|
||||
Dependency: TASK-209-003
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Move `docs/modules/notifier/` to `docs-archived/modules/notifier/`.
|
||||
- Update Notify architecture doc to mention the Notifier host.
|
||||
- Update `docs/INDEX.md`, `CLAUDE.md`.
|
||||
- Update Web notifier integration points:
|
||||
- `src/Web/StellaOps.Web/src/app/app.config.ts` `NOTIFIER_API_BASE_URL` provider (`/api/v1/notifier`).
|
||||
- `src/Web/StellaOps.Web/src/app/core/api/notifier.client.ts` default base URL fallback.
|
||||
- `src/Web/StellaOps.Web/src/app/features/admin-notifications/**` imports using notifier client/models.
|
||||
- Update CLI notifier references:
|
||||
- `src/Cli/StellaOps.Cli/Commands/ConfigCatalog.cs` notifier configuration keys.
|
||||
- Any notifier command/help references that include module paths.
|
||||
- Preserve `/api/v1/notifier` contract.
|
||||
- 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:
|
||||
- [ ] Notifier docs archived.
|
||||
- [ ] Notify architecture updated.
|
||||
- [ ] Web notifier references validated/updated.
|
||||
- [ ] CLI notifier references validated/updated.
|
||||
- [ ] Notifier API path compatibility verified.
|
||||
- [ ] Documentation index updated.
|
||||
- [ ] Follow-up items created only where actionable.
|
||||
|
||||
## 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 | 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: Revisit the 2025-11-02 separation decision. If offline kit parity still requires separate packaging, document that in Notify architecture and keep containers separate.
|
||||
- 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
|
||||
- Estimate: 1 session (2 projects only).
|
||||
|
||||
|
||||
|
||||
- Milestone 1: boundary baseline documented.
|
||||
- Milestone 2: split-deployment decision reflected in docs.
|
||||
- Milestone 3: compatibility validation complete and sprint ready for closure.
|
||||
|
||||
@@ -1,111 +1,96 @@
|
||||
# Sprint 211 - Offline Distribution Domain: ExportCenter, Mirror, and AirGap
|
||||
# Sprint 211 - Offline Distribution Boundary Preservation (No Consolidation)
|
||||
|
||||
## Topic & Scope
|
||||
- Consolidate offline distribution capabilities into one domain ownership model.
|
||||
- Move Mirror and AirGap source ownership under `src/ExportCenter/` while preserving runtime identities.
|
||||
- Merge AirGap and ExportCenter EF Core DbContexts into one domain DbContext. PostgreSQL schemas (`export_center`, `airgap`) remain separate; this is a code-level consolidation, not a schema merge.
|
||||
- Working directory: `src/ExportCenter/`.
|
||||
- Cross-module edits explicitly allowed for offline flow integrations (`src/Cli/`, `src/Web/`, `devops/compose/`) as listed in tasks.
|
||||
- Expected evidence: offline workflows remain functional (`mirror create`, `airgap import`), DB merge reconciliation completed, and no API regressions.
|
||||
- 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.
|
||||
- Coordinate with Sprint 203 if shared export/advisory payload contracts change.
|
||||
- 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 module AGENTS for `Mirror` and `AirGap`.
|
||||
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### TASK-211-001 - Define offline distribution domain schema ownership and DbContext merge plan
|
||||
### TASK-211-001 - Baseline current offline boundary and coupling
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Map current ExportCenterDbContext and AirGapDbContext ownership and confirm zero entity name collisions (7 total entities).
|
||||
- Document PostgreSQL schema ownership (`export_center`, `airgap`) and confirm schemas remain separate.
|
||||
- Identify Mirror data artifacts that stay file-based versus persisted.
|
||||
- Document the DbContext merge plan: combine into one offline domain DbContext while keeping schemas separate.
|
||||
- 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:
|
||||
- [ ] Offline domain schema ownership documented.
|
||||
- [ ] Zero-collision confirmation recorded.
|
||||
- [ ] DbContext merge plan approved.
|
||||
- [ ] File-based versus persisted boundary documented.
|
||||
- [ ] DbContext ownership map documented.
|
||||
- [ ] Coupling evidence documented.
|
||||
- [ ] Boundary rationale evidence recorded in sprint notes.
|
||||
|
||||
### TASK-211-002 - Consolidate source layout under ExportCenter domain
|
||||
### TASK-211-002 - Record no-consolidation/no-merge decision
|
||||
Status: TODO
|
||||
Dependency: TASK-211-001
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Move Mirror and AirGap source trees under `src/ExportCenter/` domain structure.
|
||||
- Preserve project names and deployable runtime identities.
|
||||
- Update project/solution references and remove legacy top-level roots.
|
||||
- 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:
|
||||
- [ ] Source trees relocated under ExportCenter domain.
|
||||
- [ ] References compile after move.
|
||||
- [ ] Legacy roots removed.
|
||||
- [ ] No-consolidation decision recorded.
|
||||
- [ ] No-merge decision recorded.
|
||||
- [ ] Stale merge wording removed.
|
||||
|
||||
### TASK-211-003 - Merge offline distribution DbContexts and regenerate compiled models
|
||||
### TASK-211-003 - Validate critical build paths without consolidation
|
||||
Status: TODO
|
||||
Dependency: TASK-211-001
|
||||
Dependency: TASK-211-002
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Merge AirGapDbContext entities into ExportCenterDbContext (or create a unified OfflineDomainDbContext).
|
||||
- PostgreSQL schemas (`export_center`, `airgap`) remain separate — this is a DbContext-level consolidation only, not a schema merge. No data migration, no dual-write, no backfill.
|
||||
- Regenerate EF compiled models using `dotnet ef dbcontext optimize`.
|
||||
- Verify `<Compile Remove>` entry for compiled model assembly attributes in `.csproj`.
|
||||
- Run targeted integration tests against the merged context to confirm query behavior unchanged.
|
||||
- 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:
|
||||
- [ ] Offline domain DbContexts merged into a single domain context.
|
||||
- [ ] PostgreSQL schemas remain separate (no data migration).
|
||||
- [ ] EF compiled models regenerated and committed.
|
||||
- [ ] Integration tests pass with merged context.
|
||||
- [ ] Representative builds pass.
|
||||
- [ ] No integration regressions identified from boundary-preserved model.
|
||||
|
||||
### TASK-211-004 - CLI/Web/infrastructure updates, tests, and docs
|
||||
### TASK-211-004 - Document deferred convergence criteria (if ever revisited)
|
||||
Status: TODO
|
||||
Dependency: TASK-211-002, TASK-211-003
|
||||
Dependency: TASK-211-003
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Validate/update CLI references:
|
||||
- AirGap project references in `src/Cli/StellaOps.Cli/StellaOps.Cli.csproj`.
|
||||
- command handlers for `mirror create` and `airgap import`.
|
||||
- Validate/update Web references for feed/airgap routes and clients.
|
||||
- Update compose/workflow paths for moved source trees.
|
||||
- Build/test affected modules and update docs for domain-first + DbContext merge model.
|
||||
- Add ADR entry to `docs/modules/export-center/architecture.md` documenting the DbContext merge decision.
|
||||
- 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:
|
||||
- [ ] CLI and Web references validated or updated.
|
||||
- [ ] Compose/workflow paths updated.
|
||||
- [ ] Builds/tests pass.
|
||||
- [ ] Documentation updated and legacy standalone docs archived.
|
||||
- [ ] ADR entry recorded.
|
||||
- [ ] Future-convergence entry criteria documented.
|
||||
- [ ] Deferred state explicitly recorded when applicable.
|
||||
|
||||
## 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 offline-domain consolidation with explicit AirGap/ExportCenter DB merge phases. | Planning |
|
||||
| 2026-02-25 | DB merge simplified after deep analysis: 7 entities with zero collisions. DbContext merge only (no schema merge, no dual-write, no backfill). Schemas remain separate. Sprint reduced from 5 tasks to 4. | Planning |
|
||||
| 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: AirGap and ExportCenter DbContexts merge into one domain DbContext. PostgreSQL schemas remain separate.
|
||||
- Rationale: 7 total entities with zero name collisions makes DbContext consolidation safe and low-risk. All data already in `stellaops_platform`. Schemas stay separate for clean lifecycle boundaries.
|
||||
- Decision: Runtime API paths remain backward compatible.
|
||||
- Risk: offline bundle integrity regressions. Mitigation: targeted integration tests with merged context before deploying.
|
||||
- Risk: offline kit identity drift. Mitigation: preserve project/package identities and validate CLI workflows.
|
||||
- Note: ExportCenterDbContext has compiled models generated by Sprint 219. EF compiled model regeneration is required after DbContext merge (TASK-211-003).
|
||||
- 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: offline domain contract documented and source layout consolidated.
|
||||
- Milestone 2: DbContext merge complete with compiled models regenerated.
|
||||
- Milestone 3: CLI/Web/infra updated and docs finalized.
|
||||
|
||||
|
||||
- Milestone 1: boundary/coupling baseline documented.
|
||||
- Milestone 2: no-merge decision propagated to docs.
|
||||
- Milestone 3: build validation complete and sprint ready for closure.
|
||||
|
||||
@@ -1,128 +0,0 @@
|
||||
# Sprint 215 - Signals: Absorb RuntimeInstrumentation Module
|
||||
|
||||
## Topic & Scope
|
||||
- Consolidate `src/RuntimeInstrumentation/` into `src/Signals/`.
|
||||
- RuntimeInstrumentation provides eBPF/Tetragon event adapters that feed into Signals. Same domain: runtime observability.
|
||||
- Critical finding: RuntimeInstrumentation has NO .csproj files. Source code exists (12 .cs files across 3 directories) but lacks build integration.
|
||||
- Working directory: `src/RuntimeInstrumentation/`, `src/Signals/`.
|
||||
- Expected evidence: clean build with RuntimeInstrumentation integrated, all tests pass.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- No upstream dependencies. Can run in parallel.
|
||||
- Signals is heavily consumed (10+ external consumers: Platform, Policy, Scanner, Findings, etc.). Changes must not break Signals API surface.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- Read `docs/modules/signals/architecture.md`.
|
||||
- Read `docs/modules/runtime-instrumentation/architecture.md`.
|
||||
- Read `src/Signals/AGENTS.md`.
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### TASK-215-001 - Audit RuntimeInstrumentation source code
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- RuntimeInstrumentation has 3 subdirectories with no .csproj files:
|
||||
- `StellaOps.Agent.Tetragon/` — 2 .cs files (TetragonAgentCapability, TetragonGrpcClient).
|
||||
- `StellaOps.RuntimeInstrumentation.Tetragon/` — 5 .cs files (EventAdapter, FrameCanonicalizer, HotSymbolBridge, PrivacyFilter, WitnessBridge).
|
||||
- `StellaOps.RuntimeInstrumentation.Tetragon.Tests/` — 5 .cs files (benchmarks + 4 test classes).
|
||||
- Confirm zero external consumers (expected: no .csproj = no ProjectReference possible).
|
||||
- Read each .cs file to understand:
|
||||
- What namespaces are used.
|
||||
- What Signals types are referenced (if any).
|
||||
- Whether the code is complete/compilable or stub/WIP.
|
||||
- Determine if RuntimeInstrumentation code should become:
|
||||
- (a) New .csproj projects under Signals, or
|
||||
- (b) Merged directly into existing Signals projects (StellaOps.Signals.Ebpf already exists).
|
||||
- Check if `StellaOps.Signals.Ebpf` already contains some of this logic (potential duplication).
|
||||
|
||||
Completion criteria:
|
||||
- [ ] All 12 source files reviewed
|
||||
- [ ] Integration strategy decided (new project vs merge into Ebpf)
|
||||
- [ ] Duplication with Signals.Ebpf documented
|
||||
|
||||
### TASK-215-002 - Move RuntimeInstrumentation into Signals
|
||||
Status: TODO
|
||||
Dependency: TASK-215-001
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Based on TASK-215-001 decision:
|
||||
- **If new projects**: Create .csproj files under `src/Signals/__Libraries/StellaOps.RuntimeInstrumentation.Tetragon/` and `src/Signals/__Libraries/StellaOps.Agent.Tetragon/`.
|
||||
- **If merge into Ebpf**: Move source files into `src/Signals/__Libraries/StellaOps.Signals.Ebpf/` with appropriate namespace adjustments.
|
||||
- Move test files to `src/Signals/__Tests/StellaOps.RuntimeInstrumentation.Tetragon.Tests/` (or merge into `StellaOps.Signals.Ebpf.Tests`).
|
||||
- Add new/modified projects to `StellaOps.Signals.sln`.
|
||||
- Remove `src/RuntimeInstrumentation/`.
|
||||
- Update root solution file.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] All source files moved/integrated
|
||||
- [ ] Projects added to Signals solution
|
||||
- [ ] Old directory removed
|
||||
|
||||
### TASK-215-003 - Build and test
|
||||
Status: TODO
|
||||
Dependency: TASK-215-002
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- `dotnet build src/Signals/StellaOps.Signals.sln` — must succeed.
|
||||
- Run all Signals tests: `dotnet test src/Signals/StellaOps.Signals.sln`.
|
||||
- Run RuntimeInstrumentation tests (now under Signals).
|
||||
- Verify no regressions in Signals API surface (10+ external consumers depend on it).
|
||||
- Build root solution: `dotnet build StellaOps.sln`.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Signals solution builds successfully
|
||||
- [ ] All Signals tests pass
|
||||
- [ ] RuntimeInstrumentation tests pass
|
||||
- [ ] Root solution builds successfully
|
||||
|
||||
### TASK-215-004 - Update Docker, CI, and infrastructure
|
||||
Status: TODO
|
||||
Dependency: TASK-215-003
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- RuntimeInstrumentation has no Docker service — no compose changes needed.
|
||||
- Search `.gitea/workflows/` for RuntimeInstrumentation references. Update if found.
|
||||
- Search `devops/` for RuntimeInstrumentation references. Update if found.
|
||||
- Verify Signals Docker service still works (`stellaops/signals:dev`).
|
||||
|
||||
Completion criteria:
|
||||
- [ ] CI references updated (if any exist)
|
||||
- [ ] Signals Docker service unaffected
|
||||
|
||||
### TASK-215-005 - Update documentation and CLI/Web audits
|
||||
Status: TODO
|
||||
Dependency: TASK-215-004
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Archive `docs/modules/runtime-instrumentation/` to `docs-archived/modules/runtime-instrumentation/`.
|
||||
- Add "RuntimeInstrumentation (eBPF/Tetragon Adapters)" section to Signals architecture doc.
|
||||
- Update `docs/INDEX.md`, `CLAUDE.md` section 1.4.
|
||||
- Update path references.
|
||||
- Audit `src/Cli/` and `src/Web/` for direct `RuntimeInstrumentation` references. Current audit expectation: none.
|
||||
- Record explicit `none found` evidence (or updated files if found).
|
||||
- Update `src/Signals/AGENTS.md` to document absorbed RuntimeInstrumentation components.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Docs archived and Signals architecture updated.
|
||||
- [ ] CLI/Web audit result recorded.
|
||||
- [ ] All references updated.
|
||||
- [ ] Signals AGENTS.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: Integration strategy (new .csproj vs merge into Ebpf) deferred to TASK-215-001 audit.
|
||||
- Risk: RuntimeInstrumentation has no .csproj files — source may be incomplete/WIP. If code is not compilable, document gaps and create follow-up tasks.
|
||||
- Risk: Signals has 10+ external consumers. Any API surface changes require careful coordination.
|
||||
- Note: `StellaOps.Signals.Ebpf` already exists under `src/Signals/__Libraries/`. Potential overlap with RuntimeInstrumentation.Tetragon must be resolved.
|
||||
|
||||
## Next Checkpoints
|
||||
- Estimate: 1 session.
|
||||
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
|
||||
## 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).
|
||||
- Coordinate with Sprint 205 (VEX trust ingest) for client compatibility.
|
||||
- Sprint 205 is deferred in the current wave; no active dependency.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- Read `docs/modules/authority/architecture.md`.
|
||||
@@ -105,4 +105,3 @@ Completion criteria:
|
||||
- Milestone 2: infrastructure validated and builds pass.
|
||||
- Milestone 3: docs and ADR updated, sprint ready for closure.
|
||||
|
||||
|
||||
|
||||
@@ -1,122 +1,89 @@
|
||||
# Sprint 218 - DOCS: Domain-First Consolidation and DB Merge Finalization
|
||||
# Sprint 218 - DOCS: Consolidation Decision Finalization
|
||||
|
||||
## Topic & Scope
|
||||
- Final documentation sweep after consolidation sprints are executed in domain-first mode.
|
||||
- Align architecture docs to domain ownership model instead of module-per-service wording.
|
||||
- Publish consolidated DB merge outcomes, compatibility windows, and rollback states per domain sprint.
|
||||
- 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 (`CLAUDE.md`) and sprint evidence files in `docs/implplan/`.
|
||||
- Expected evidence: no stale module-path guidance, consistent domain map, and DB merge status traceable from 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 all relevant consolidation sprints being DONE (200-217, 219-221).
|
||||
- Must run after DB cutover checkpoints in domain sprints (203, 204, 205, 206, 208, 211, 216).
|
||||
- Must run after Sprint 220 (SbomService → Scanner) source move is complete.
|
||||
- Must run after Sprint 221 (Orchestrator domain rename) is complete.
|
||||
- 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 `CLAUDE.md` section 1.4.
|
||||
- Read `docs/07_HIGH_LEVEL_ARCHITECTURE.md`.
|
||||
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
|
||||
- Read execution logs of domain sprints for DB merge outcomes.
|
||||
- Read Sprint 220 (SbomService → Scanner) execution log for source move outcome.
|
||||
- Read execution logs of active consolidation sprints.
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### TASK-218-001 - Audit docs against domain-first source structure
|
||||
### TASK-218-001 - Publish consolidation decision ledger
|
||||
Status: TODO
|
||||
Dependency: Consolidation sprints DONE
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Audit `docs/modules/` against actual `src/` domain ownership after consolidation.
|
||||
- Confirm standalone module docs were replaced or archived per domain decisions.
|
||||
- Verify active docs no longer describe consolidation as only folder movement where DB merge was executed.
|
||||
- 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:
|
||||
- [ ] Active module docs match current domain ownership.
|
||||
- [ ] Archived standalone module docs are in `docs-archived/modules/`.
|
||||
- [ ] No stale module-structure claims remain.
|
||||
- [ ] Decision ledger published.
|
||||
- [ ] Every impacted sprint has explicit state.
|
||||
|
||||
### TASK-218-002 - Publish domain DB merge ledger and outcomes
|
||||
### TASK-218-002 - Remove stale merge language from active docs
|
||||
Status: TODO
|
||||
Dependency: TASK-218-001
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Create/refresh a documentation section that records DB merge status per domain sprint:
|
||||
- Contract defined.
|
||||
- Expand migration complete.
|
||||
- Dual-write complete.
|
||||
- Backfill reconciliation complete.
|
||||
- Cutover complete.
|
||||
- Rollback status.
|
||||
- Link each status row to sprint execution log evidence.
|
||||
- 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:
|
||||
- [ ] Domain DB merge ledger published.
|
||||
- [ ] Each domain sprint has linked evidence.
|
||||
- [ ] Rollback window state documented per domain.
|
||||
- [ ] Stale merge claims removed.
|
||||
- [ ] Boundary-preserved outcomes reflected in docs.
|
||||
|
||||
### TASK-218-003 - Update CLAUDE.md and architecture docs to domain paradigm
|
||||
### 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 root module-location guidance to domain-first language.
|
||||
- Update high-level architecture docs to show domain groupings and bounded runtime services.
|
||||
- Update module count claims to match post-consolidation reality.
|
||||
- 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:
|
||||
- [ ] CLAUDE.md reflects domain-first structure.
|
||||
- [ ] Architecture docs reflect domain ownership and service boundaries.
|
||||
- [ ] Module/domain count claims are accurate.
|
||||
- [ ] Index and architecture references aligned.
|
||||
- [ ] No stale references to canceled/no-op consolidations.
|
||||
|
||||
### TASK-218-004 - Validate CLI/Web and infra documentation references
|
||||
### TASK-218-004 - Final documentation quality gate
|
||||
Status: TODO
|
||||
Dependency: TASK-218-001
|
||||
Dependency: TASK-218-003
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Re-run docs cross-reference checks against authoritative config surfaces:
|
||||
- CLI project/route files.
|
||||
- Web proxy/config files.
|
||||
- compose and launch settings env vars.
|
||||
- Ensure docs reference current domain endpoints and compatibility aliases.
|
||||
- Run final docs cross-reference checks.
|
||||
- Record residual risks and deferred items.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] CLI/Web doc references validated.
|
||||
- [ ] Infra env var references validated.
|
||||
- [ ] Compatibility aliases documented where still required.
|
||||
|
||||
### TASK-218-005 - Final cross-reference and quality gate
|
||||
Status: TODO
|
||||
Dependency: TASK-218-002, TASK-218-003, TASK-218-004
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Run repo-wide doc checks for stale absorbed-module paths and outdated architecture claims.
|
||||
- Verify all links and references in updated docs are valid.
|
||||
- Add final execution log summary with open risks (if any) and remaining deprecation deadlines.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] No stale path references remain in active docs.
|
||||
- [ ] All updated links resolve.
|
||||
- [ ] Final summary and residual risks recorded.
|
||||
- [ ] Cross-reference checks completed.
|
||||
- [ ] Residual risks/deferred items documented.
|
||||
|
||||
## 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 documentation closeout with DB merge ledger requirements. | Planning |
|
||||
| 2026-02-25 | DB merge verdicts finalized: REJECT (source-only) for Advisory/203, Trust/204, Orchestration/208, Identity/216. PROCEED (DbContext merge) for VEX/205, Offline/211. PROCEED (delete empty placeholder) for Policy/206. TASK-218-002 DB merge ledger reflects these outcomes. | 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: this sprint finalizes domain-first architecture language and DB merge traceability.
|
||||
- Risk: if any domain sprint lacks reconciliation evidence, docs may overstate completion. Mitigation: gate documentation closure on evidence links.
|
||||
- Decision: absorbed module docs remain archived, not deleted, for audit history.
|
||||
- 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: domain audit and DB merge ledger draft complete.
|
||||
- Milestone 2: architecture + CLAUDE update complete.
|
||||
- Milestone 3: final cross-reference gate passed and sprint ready for closure.
|
||||
|
||||
|
||||
- Milestone 1: decision ledger complete.
|
||||
- Milestone 2: stale merge language removed.
|
||||
- Milestone 3: final docs gate passed and sprint ready for closure.
|
||||
|
||||
@@ -1,133 +0,0 @@
|
||||
# Sprint 220 - Scanner Domain: Absorb SbomService
|
||||
|
||||
## Topic & Scope
|
||||
- Consolidate `src/SbomService/` (6 csproj) into `src/Scanner/` domain ownership.
|
||||
- SbomService generates, processes, and tracks SBOM lineage from scanned artifacts — this is Scanner's domain (scan -> produce SBOM -> index -> track lineage).
|
||||
- SbomServiceDbContext stub was already deleted in a prior session — no DB merge required.
|
||||
- SbomService.WebService keeps its own Docker container and port (10390/10391).
|
||||
- Working directory: `src/Scanner/`, `src/SbomService/`.
|
||||
- Cross-module edits explicitly allowed for: `src/Platform/` (Platform.Database references SbomService.Lineage), `src/Cli/`, `src/Web/`, `devops/compose/`.
|
||||
- Expected evidence: clean builds, all tests pass, Docker service remains operational, no API regressions.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- No upstream sprint dependency.
|
||||
- Can run in parallel with Sprint 201 (Cartographer -> Scanner) but if both are in flight simultaneously, coordinate Scanner solution file edits to avoid merge conflicts. Recommend serializing: run 201 first (smaller, 1 csproj), then 220.
|
||||
- Coordinate with Sprint 203 (Concelier absorbs Excititor) because SbomService.WebService has a `ProjectReference` to `StellaOps.Excititor.Persistence` — if Sprint 203 moves Excititor first, the path in SbomService's .csproj must be updated to point to the new location under `src/Concelier/`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- Read `src/SbomService/AGENTS.md`.
|
||||
- Read `docs/modules/sbom-service/architecture.md`.
|
||||
- Read `AUDIT_20260225_cli_ui_module_reference_matrix.md`.
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### TASK-220-001 - Map SbomService structure and consumer references
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Enumerate all 6 csproj files and their dependencies:
|
||||
- `StellaOps.SbomService` (WebService) — depends on Configuration, DependencyInjection, Excititor.Persistence, SbomService.Lineage, Auth.ServerIntegration.
|
||||
- `StellaOps.SbomService.Persistence` (library).
|
||||
- `StellaOps.SbomService.Lineage` (library, EF Core).
|
||||
- `StellaOps.SbomService.Tests` (tests).
|
||||
- `StellaOps.SbomService.Persistence.Tests` (tests).
|
||||
- `StellaOps.SbomService.Lineage.Tests` (tests).
|
||||
- Identify all external consumers:
|
||||
- `src/Platform/__Libraries/StellaOps.Platform.Database/` references `StellaOps.SbomService.Lineage`.
|
||||
- E2E integration tests reference SbomService.
|
||||
- Confirm SbomServiceDbContext stub is deleted (no DB merge needed).
|
||||
- Document Docker service definition (`sbomservice` slot 39, image `stellaops/sbomservice:dev`).
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Full dependency and consumer map documented.
|
||||
- [ ] DbContext deletion confirmed.
|
||||
- [ ] Docker definition documented.
|
||||
|
||||
### TASK-220-002 - Move SbomService source tree into Scanner domain
|
||||
Status: TODO
|
||||
Dependency: TASK-220-001
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Move `src/SbomService/StellaOps.SbomService/` -> `src/Scanner/StellaOps.SbomService/` (WebService).
|
||||
- Move `src/SbomService/__Libraries/` -> `src/Scanner/__Libraries/` (merge with existing Scanner libraries):
|
||||
- `StellaOps.SbomService.Persistence/`
|
||||
- `StellaOps.SbomService.Lineage/`
|
||||
- Move `src/SbomService/__Tests/` -> `src/Scanner/__Tests/` (merge with existing Scanner tests):
|
||||
- `StellaOps.SbomService.Persistence.Tests/`
|
||||
- `StellaOps.SbomService.Lineage.Tests/`
|
||||
- Move `src/SbomService/StellaOps.SbomService.Tests/` -> `src/Scanner/__Tests/StellaOps.SbomService.Tests/`.
|
||||
- Keep all project names unchanged — no namespace renames.
|
||||
- Update all `ProjectReference` paths in:
|
||||
- Moved SbomService projects (internal references).
|
||||
- `src/Platform/__Libraries/StellaOps.Platform.Database/` (references SbomService.Lineage).
|
||||
- Any other consumers identified in TASK-220-001.
|
||||
- Add moved projects to Scanner solution file (`StellaOps.Scanner.sln` or equivalent).
|
||||
- Remove SbomService entries from root solution (`StellaOps.sln`) old paths and re-add at new paths.
|
||||
- Remove `src/SbomService/` directory after all moves complete.
|
||||
- Move `src/SbomService/AGENTS.md` -> `src/Scanner/AGENTS_SBOMSERVICE.md` or merge into Scanner's AGENTS.md.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] All 6 projects moved under Scanner domain.
|
||||
- [ ] All ProjectReference paths updated and compile.
|
||||
- [ ] Scanner solution includes SbomService projects.
|
||||
- [ ] Root solution updated.
|
||||
- [ ] Legacy `src/SbomService/` directory removed.
|
||||
|
||||
### TASK-220-003 - Update Docker, CI, and infrastructure references
|
||||
Status: TODO
|
||||
Dependency: TASK-220-002
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Update `devops/compose/docker-compose.stella-ops.yml`:
|
||||
- SbomService build context and Dockerfile path to new location under Scanner.
|
||||
- Update `.gitea/workflows/` if any workflow references SbomService source paths.
|
||||
- Update `src/Platform/StellaOps.Platform.WebService/Properties/launchSettings.json` if SbomService URLs are defined there.
|
||||
- Build verification:
|
||||
- `dotnet build` Scanner solution — must succeed.
|
||||
- `dotnet test` all SbomService test projects — must pass.
|
||||
- `dotnet build StellaOps.sln` — root solution must succeed.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Docker compose updated with new paths.
|
||||
- [ ] CI workflows updated if affected.
|
||||
- [ ] All builds and tests pass.
|
||||
|
||||
### TASK-220-004 - Update documentation and validate CLI/Web references
|
||||
Status: TODO
|
||||
Dependency: TASK-220-003
|
||||
Owners: Developer
|
||||
Task description:
|
||||
- Move `docs/modules/sbom-service/` to `docs-archived/modules/sbom-service/` (standalone docs).
|
||||
- Add SbomService subsection to Scanner architecture doc (`docs/modules/scanner/architecture.md`).
|
||||
- Update `docs/INDEX.md` — mark SbomService as consolidated into Scanner.
|
||||
- Update `CLAUDE.md` section 1.4 if SbomService is listed.
|
||||
- Audit CLI references:
|
||||
- Search `src/Cli/` for SbomService-specific references.
|
||||
- Update any source-path references.
|
||||
- Audit Web references:
|
||||
- Search `src/Web/` for SbomService API base URLs or proxy config.
|
||||
- Validate runtime API paths remain unchanged.
|
||||
- Search all `docs/**/*.md` for references to `src/SbomService/` and update.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Standalone SbomService docs archived.
|
||||
- [ ] Scanner architecture doc updated with SbomService subsection.
|
||||
- [ ] INDEX.md and CLAUDE.md updated.
|
||||
- [ ] CLI and Web audits completed.
|
||||
- [ ] No broken references remain.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-25 | Sprint created. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: SbomService is treated as part of Scanner's domain (scan -> SBOM -> lineage).
|
||||
- Decision: SbomServiceDbContext stub was already deleted — no DB merge work required.
|
||||
- Decision: Project names preserved — no namespace renames to avoid breaking serialized types or API contracts.
|
||||
- Risk: SbomService.WebService references `StellaOps.Excititor.Persistence` (cross-domain dependency). If Sprint 203 moves Excititor first, this ProjectReference path must be updated. Mitigation: coordinate with Sprint 203 or update path after both sprints complete.
|
||||
- Risk: Platform.Database references SbomService.Lineage — path must be updated atomically with the move. Low risk (single consumer, clear path update).
|
||||
|
||||
## Next Checkpoints
|
||||
- Estimate: 1 session (medium scope — 6 csproj, straightforward organizational move, no DB merge).
|
||||
Reference in New Issue
Block a user