Search/AdvisoryAI and DAL conversion to EF finishes up. Preparation for microservices consolidation.

docs/implplan/SPRINT_20260222_052_DOCS_router_endpoint_auth_scope_description_backfill.md

@@ -1,201 +0,0 @@
-# Sprint 20260222.052 - Router Endpoint Auth Scope and Description Backfill
-
-## Topic & Scope
-- Establish a complete endpoint-level inventory for Router OpenAPI with explicit authorization and description coverage status.
-- For every endpoint, track whether it is anonymous or authenticated, what scopes/roles/policies are declared, and what description improvements are required.
-- Convert the inventory into endpoint-level implementation actions (`authAction`, `descriptionAction`) so execution can proceed deterministically service-by-service.
-- Working directory: `docs/implplan`.
-- Expected evidence: full endpoint inventory CSV, per-service summary CSV, global summary JSON, execution waves for implementation.
-
-## Dependencies & Concurrency
-- Depends on current Router aggregate OpenAPI served at `https://stella-ops.local/openapi.json`.
-- Depends on current compose contract for auth metadata extension (`x-stellaops-gateway-auth`) and endpoint descriptions.
-- Safe parallelism:
-- Auth metadata backfill can run in parallel by service wave.
-- Description enrichment can run in parallel with auth metadata work once per-service owner is assigned.
-
-## Documentation Prerequisites
-- `docs/modules/router/architecture.md`
-- `docs/modules/router/aspnet-endpoint-bridge.md`
-- `docs/modules/router/webservice-integration-guide.md`
-- `docs/modules/platform/architecture-overview.md`
-
-## Endpoint Inventory Artifacts
-- Full endpoint listing with endpoint-level plan:
-- `docs/implplan/SPRINT_20260222_052_DOCS_router_endpoint_auth_scope_description_backfill.endpoints.csv`
-- Per-service rollup:
-- `docs/implplan/SPRINT_20260222_052_DOCS_router_endpoint_auth_scope_description_backfill.services.csv`
-- Global totals snapshot:
-- `docs/implplan/SPRINT_20260222_052_DOCS_router_endpoint_auth_scope_description_backfill.summary.json`
-- OpenAPI capture used for this sprint:
-- `docs/implplan/SPRINT_20260222_052_DOCS_router_endpoint_auth_scope_description_backfill.openapi_live.json`
-
-## Baseline Snapshot (Generated 2026-02-22)
-- Total operations: `2190`
-- Anonymous operations: `6`
-- Authenticated operations: `2184`
-- Operations with explicit scopes: `28`
-- Operations with explicit roles: `0`
-- Operations with policies: `156`
-- Operations with auth source `None`: `1991`
-- Descriptions requiring expansion (`same_as_summary` or `too_short`): `1507`
-
-## Delivery Tracker
-
-### RASD-01 - Produce full endpoint-level auth and description inventory
-Status: DONE
-Dependency: none
-Owners: Project Manager
-Task description:
-- Pull the live Router OpenAPI document and enumerate every HTTP operation.
-- For each operation, extract:
-- Service, method, path, operationId.
-- `allowAnonymous`, `requiresAuthentication`, `authSource`, `effectiveClaimSource`.
-- Scope, role, policy, and claim requirement details.
-- Description quality status.
-- Persist the result as a deterministic CSV under this sprint.
-
-Completion criteria:
-- [x] All operations in the current OpenAPI are represented in one inventory file.
-- [x] Every inventory row includes auth and description status columns.
-- [x] Inventory artifact is linked in this sprint.
-
-### RASD-02 - Attach endpoint-level planned actions for auth and descriptions
-Status: DONE
-Dependency: RASD-01
-Owners: Project Manager
-Task description:
-- Add per-endpoint plan columns to the inventory:
-- `authAction` values: `add_endpoint_auth_metadata`, `keep_or_refine_scope`, `policy_defined_scope_not_exported`, `verify_anonymous_intent`, `needs_auth_review`.
-- `descriptionAction` values: `expand_description`, `add_description`, `replace_http_stub_with_domain_semantics`, `keep_description`.
-- Ensure each endpoint row has a deterministic next action without requiring manual interpretation.
-
-Completion criteria:
-- [x] Every endpoint row has `authAction`.
-- [x] Every endpoint row has `descriptionAction`.
-- [x] Action taxonomy is documented in this sprint.
-
-### RASD-03 - Execute Wave A (missing endpoint auth metadata)
-Status: TODO
-Dependency: RASD-02
-Owners: Developer, Test Automation
-Task description:
-- Implement endpoint auth metadata for all operations marked `authAction=add_endpoint_auth_metadata` (`1991` endpoints).
-- Primary migration target is conversion of in-handler/manual checks to endpoint metadata where applicable (`[Authorize]`/`.RequireAuthorization(...)` and mapped policies/scopes).
-- Prioritized service order by count:
-- `orchestrator (313)`, `policy-engine (202)`, `notifier (197)`, `platform (165)`, `concelier (144)`, `policy-gateway (121)`, `findings-ledger (83)`, `advisoryai (81)`, `exportcenter (64)`, `excititor (55)`, then remaining services.
-- Scope publication is mandatory for endpoints that currently enforce scope in handler code; adding authentication-only metadata is not sufficient.
-- Required seed set (must pass before Wave A can be marked DONE):
-- `POST /excititor/api/v1/vex/candidates/{candidateId}/approve` -> scope `vex.admin`
-- `POST /excititor/api/v1/vex/candidates/{candidateId}/reject` -> scope `vex.admin`
-- `GET /excititor/api/v1/vex/candidates` -> scope `vex.read` (or `vex.admin` if policy decision explicitly documents broader admin-only access)
-
-Completion criteria:
-- [ ] Every endpoint currently marked `add_endpoint_auth_metadata` is migrated or explicitly justified.
-- [ ] OpenAPI no longer reports `source: "None"` for migrated endpoints.
-- [ ] Migrated endpoints that require scopes publish them in OpenAPI via both `security.OAuth2` scopes and `x-stellaops-gateway-auth.claimRequirements`.
-- [ ] Endpoints must not be closed as DONE with only `requiresAuthentication=true` when scope semantics are known from endpoint logic.
-- [ ] Required Excititor seed set publishes expected scopes in live `https://stella-ops.local/openapi.json`.
-- [ ] Regression tests validate expected `401/403` behavior.
-
-### RASD-04 - Execute Wave B (scope/policy normalization and export fidelity)
-Status: TODO
-Dependency: RASD-03
-Owners: Developer, Test Automation
-Task description:
-- Resolve endpoints marked `policy_defined_scope_not_exported` (`128` endpoints, currently concentrated in `scanner`) so explicit scope semantics are exported consistently.
-- Review endpoints marked `needs_auth_review` (`37` endpoints, currently in `authority`) and decide whether they remain policy-only auth or receive explicit scope/role declarations.
-- Ensure resulting OpenAPI expresses effective scope/claim requirements where expected.
-
-Completion criteria:
-- [ ] `policy_defined_scope_not_exported` endpoints are eliminated or explicitly documented as policy-only.
-- [ ] `needs_auth_review` endpoints are classified and updated.
-- [ ] Endpoint security metadata is consistent with runtime authorization behavior.
-
-### RASD-05 - Execute Wave C (description enrichment)
-Status: TODO
-Dependency: RASD-02
-Owners: Documentation author, Developer
-Task description:
-- Enrich descriptions for all endpoints marked `descriptionAction=expand_description` (`1507` endpoints).
-- Replace terse or repeated summary text with domain semantics: purpose, side effects, key constraints, and error behavior.
-- Keep concise descriptions already marked `keep_description` unchanged unless auth behavior changes require updates.
-
-Completion criteria:
-- [ ] All endpoints flagged for description expansion have non-trivial descriptions.
-- [ ] Descriptions align with actual handler behavior and response contracts.
-- [ ] OpenAPI diff shows description improvements without schema regressions.
-
-### RASD-06 - Validate end-to-end and lock quality gates
-Status: TODO
-Dependency: RASD-03
-Owners: Test Automation, QA
-Task description:
-- Add deterministic quality checks that fail CI when:
-- Endpoint auth metadata is missing for non-anonymous endpoints.
-- Scope/role/policy metadata diverges from declared service authorization rules.
-- Endpoint descriptions regress to low-information forms.
-- Rebuild/redeploy and verify `https://stella-ops.local/openapi.json` reflects the updated metadata.
-
-Completion criteria:
-- [ ] Automated checks guard auth and description regressions.
-- [ ] Fresh compose deployment validates updated OpenAPI.
-- [ ] Sprint artifacts updated with final counts and diffs.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-22 | Sprint created for full endpoint auth/scope/description inventory and migration planning. | Project Manager |
-| 2026-02-22 | Generated endpoint inventory (`2190` operations) and per-endpoint planned actions in CSV artifacts. | Project Manager |
-| 2026-02-22 | Computed service-level backlog and execution waves for metadata + description remediation. | Project Manager |
-| 2026-02-22 | Tightened Wave A criteria: scope publication is mandatory (not auth-only), and added Excititor three-endpoint seed set with expected scopes. | Project Manager |
-| 2026-02-22 | RASD-03 + RASD-05 orchestrator service complete: created `OrchestratorPolicies.cs` with 14 scope-mapped policies (`orch:read`, `orch:operate`, `orch:quota`, `packs.*`, `release:*`, `export.*`, `obs:read`); registered policies via `AddAuthorization` in `Program.cs`; replaced all 25 endpoint files' bare `.RequireAuthorization()` with specific policy constants; added domain-semantic `.WithDescription()` to every endpoint. Health/scale/OpenAPI endpoints retain `.AllowAnonymous()` with enriched descriptions. | Developer |
-| 2026-02-22 | RASD-03 + RASD-05 policy-engine service complete (Wave A + C): applied `.AllowAnonymous()` to `/readyz` in `Program.cs`; added `.WithDescription()` with domain-semantic text to all 47 Engine endpoint files covering `DeterminizationConfigEndpoints`, `BudgetEndpoints`, `RiskBudgetEndpoints`, `RiskProfileSchemaEndpoints`, `StalenessEndpoints`, `UnknownsEndpoints`, `VerifyDeterminismEndpoints`, `MergePreviewEndpoints`, `AirGapNotificationEndpoints`, `SealedModeEndpoints`, `PolicyPackBundleEndpoints`, `ConsoleExportEndpoints`, `PolicyLintEndpoints`, and all files previously completed in earlier sessions. | Developer |
-| 2026-02-22 | RASD-03 + RASD-05 policy-api service complete: added `.WithDescription()` to all 6 endpoints in `ReplayEndpoints.cs`. | Developer |
-| 2026-02-22 | RASD-03 + RASD-05 policy-gateway service complete (Wave A + C): applied `.AllowAnonymous()` to `/readyz` in `Program.cs`; added per-endpoint `.RequireStellaOpsScopes()` auth and domain-semantic `.WithDescription()` to all 10 Gateway endpoint files: `DeltasEndpoints` (4 endpoints, Wave C only; auth was pre-existing), `ExceptionEndpoints` (10 endpoints, Wave C only; auth pre-existing), `GovernanceEndpoints` (15 endpoints, Wave A + C: added `StellaOps.Auth` usings and per-endpoint scoped auth for all sealed-mode and risk-profile endpoints using `AirgapStatusRead`, `AirgapSeal`, `PolicyRead`, `PolicyAuthor`, `PolicyActivate`, `PolicyAudit`; enriched all 15 stub descriptions), `RegistryWebhookEndpoints` (3 endpoints, Wave C only; `.AllowAnonymous()` pre-existing), `GateEndpoints` (3 endpoints, Wave C: enriched stub descriptions; auth pre-existing), `GatesEndpoints` (6 endpoints, Wave A + C: added `StellaOps.Auth` usings and per-endpoint scoped auth using `PolicyRead`, `PolicyRun`, `PolicyAuthor`, `PolicyAudit`; enriched stub descriptions), `ScoreGateEndpoints` (3 endpoints, Wave C: enriched stub descriptions; auth pre-existing), `ToolLatticeEndpoints` (1 endpoint, already complete), `AdvisorySourceEndpoints` (already complete), `ExceptionApprovalEndpoints` (8 endpoints, Wave C only: enriched all stub descriptions from single-sentence to multi-sentence domain-semantic text; auth pre-existing). | Developer |
-| 2026-02-22 | RASD-05 Notify service complete (Wave C): added `.WithName()` + `.WithDescription()` to all 23 remaining inline Program.cs endpoints (rules DELETE, channels CRUD+test, templates CRUD, deliveries CRUD, digests CRUD, audit CREATE+LIST, locks acquire+release). Auth metadata was pre-existing via `NotifyPolicies`. | Developer |
-| 2026-02-22 | RASD-05 TaskRunner service complete (Wave C): added `.WithDescription()` to all 33 endpoints in `Program.cs`. Added `.AllowAnonymous()` to SLO breach webhook endpoints and OpenAPI metadata endpoint. No auth middleware registered in this service - `.RequireAuthorization()` not added. | Developer |
-| 2026-02-22 | RASD-03 VexHub service complete (Wave A): added `.RequireAuthorization()` at the `/api/v1/vex` group level in `VexHubEndpointExtensions.cs`. Auth middleware (`AddAuthentication("ApiKey")` + `AddAuthorization()`) was pre-existing. Descriptions pre-existing. | Developer |
-| 2026-02-22 | RASD-03 Unknowns service complete (Wave A): added `.RequireAuthorization()` at group level in `UnknownsEndpoints.cs` and `GreyQueueEndpoints.cs`. Auth middleware pre-existing. Descriptions pre-existing. | Developer |
-| 2026-02-22 | RASD-05 Signer service complete (Wave C): added `.WithDescription()` to all 6 ceremony endpoints in `CeremonyEndpoints.cs`; added `.WithName()` + `.WithDescription()` to all 3 endpoints in `SignerEndpoints.cs`; added `.WithDescription()` to all 5 key rotation endpoints in `KeyRotationEndpoints.cs`. Auth pre-existing at group level. | Developer |
-| 2026-02-22 | RASD-03 + RASD-05 AirGap service complete (Wave A + C): added `.WithDescription()` to all 4 endpoints in `AirGapEndpoints.cs`. Auth pre-existing (group `.RequireAuthorization()` + per-endpoint `.RequireScope()`). | Developer |
-| 2026-02-22 | RASD-05 Doctor service complete (Wave C): added `.WithDescription()` to all 9 endpoints in `DoctorEndpoints.cs` and all 7 endpoints in `TimestampingEndpoints.cs`. Auth pre-existing via `DoctorPolicies`. | Developer |
-| 2026-02-22 | RASD-05 Doctor Scheduler service complete (Wave C): added `.WithTags()` to group and `.WithName()` + `.WithDescription()` to all 11 inline lambda endpoints in `SchedulerEndpoints.cs` (schedules CRUD + executions + execute + trends + check trend + category trend + degrading). No auth middleware in this service - auth not added. | Developer |
-| 2026-02-22 | RASD-05 VulnExplorer service complete (Wave C): added `.WithName()` + `.WithDescription()` to all 10 endpoints in `Program.cs` (vulns list + detail, vex decisions CRUD, evidence subgraph, fix verifications CRUD, audit bundle). No auth middleware in this service. | Developer |
-| 2026-02-22 | RASD-05 SmRemote service complete (Wave C): added `.WithName()` + `.WithDescription()` to all 7 endpoints in `Program.cs` (health, status, hash, encrypt, decrypt, sign, verify). Health and status also received `.AllowAnonymous()`. No auth middleware in this service. | Developer |
-| 2026-02-22 | RASD-05 Symbols service complete (Wave C): added `.WithDescription()` to all 13 endpoints in `SymbolSourceEndpoints.cs` (7 symbol source endpoints + 6 marketplace catalog endpoints). Auth pre-existing at group level (`.RequireAuthorization()`). | Developer |
-| 2026-02-22 | RASD-05 SbomService complete (Wave C): added `.WithName()` + `.WithDescription()` to all 42 endpoints in `Program.cs` including health probes (`.AllowAnonymous()`), entrypoints, console SBOM catalog, component lookup, SBOM context/paths/versions, upload (2 paths), ledger history/point/range/diff/lineage, lineage graph/diff/hover/children/parents/export/compare/verify/compare-drift/compare, projection, and all internal event/inventory/resolver/orchestrator endpoints. Auth middleware pre-existing (`AddAuthentication(HeaderAuthenticationHandler)` + `AddAuthorization()`). | Developer |
-| 2026-02-22 | RASD-03 + RASD-05 Authority /authorize endpoints complete (Wave A + C): added `.WithName()`, `.WithDescription()`, and `.AllowAnonymous()` to GET /authorize and POST /authorize in `AuthorizeEndpoint.cs`. These are public OIDC protocol endpoints that must remain anonymous. | Developer |
-| 2026-02-22 | Note: ReachGraph uses `app.MapControllers()` (MVC controllers) with no minimal API endpoints — no action required. | Developer |
-| 2026-02-22 | RASD-03 Excititor mandatory seed set verified complete (Wave A): confirmed `POST /excititor/api/v1/vex/candidates/{candidateId}/approve` → `.RequireAuthorization(ExcititorPolicies.VexAdmin)` (scope `vex.admin`); `POST /excititor/api/v1/vex/candidates/{candidateId}/reject` → `.RequireAuthorization(ExcititorPolicies.VexAdmin)`; `GET /api/v1/vex/candidates` → `.RequireAuthorization(ExcititorPolicies.VexRead)` (scope `vex.read`). All three candidate endpoints in `Program.cs` lines 2185-2256 had correct scope-mapped policies and domain-semantic descriptions pre-existing. Wave A seed set condition met. | Developer |
-| 2026-02-22 | RASD-03 + RASD-05 verification pass for Priority 2 services — attestor, evidencelocker, scheduler, replay complete: all endpoint files in these services already had `.RequireAuthorization()` (or `.AllowAnonymous()` where appropriate) and domain-semantic descriptions pre-existing. No changes required. | Developer |
-| 2026-02-22 | Note: Signals uses MVC controllers (`HotSymbolsController.cs`, `RuntimeAgentController.cs`) — no minimal API changes needed. BinaryIndex uses `app.MapControllers()` — exempt. | Developer |
-| 2026-02-22 | RASD-05 VexLens service complete (Wave C): expanded all 15 short/terse descriptions in `VexLensEndpointExtensions.cs` to domain-semantic multi-sentence text covering all three endpoint groups (consensus, delta/gating, issuers). Auth was pre-existing via `.RequireAuthorization("vexlens.read")` / `.RequireAuthorization("vexlens.write")` on groups. | Developer |
-| 2026-02-22 | RASD-05 RiskEngine service complete (Wave C): expanded 4 descriptions in `ExploitMaturityEndpoints.cs` (`GetExploitMaturity`, `GetExploitMaturityLevel`, `GetExploitMaturityHistory`, `BatchAssessExploitMaturity`); added `.WithName()` + `.WithDescription()` to all 5 inline endpoints in `Program.cs` (`ListRiskScoreProviders`, `CreateRiskScoreJob`, `GetRiskScoreJob`, `RunRiskScoreSimulation`, `GetRiskScoreSimulationSummary`). No auth middleware registered in this service — auth not added per sprint rules. | Developer |
-| 2026-02-22 | RASD-05 Integrations service complete (Wave C): expanded all 9 descriptions in `IntegrationEndpoints.cs` from terse stubs to domain-semantic text; added `.WithDescription()` + `.AllowAnonymous()` to the `/health` probe endpoint in `Program.cs`. No auth middleware registered in this service — `.RequireAuthorization()` not added per sprint rules. | Developer |
-| 2026-02-22 | RASD-05 PacksRegistry service complete (Wave C): added `.WithName()` + `.WithDescription()` to all 14 inline endpoints in `Program.cs` (UploadPack, ListPacks, GetPack, GetPackContent, GetPackProvenance, GetPackManifest, RotatePackSignature, UploadPackAttestation, ListPackAttestations, GetPackAttestationContent, GetPackParity, SetPackLifecycleState, SetPackParityStatus, ExportOfflineSeed, UpsertMirror, ListMirrors, MarkMirrorSync, GetPacksComplianceSummary). Service uses API-key-based `IsAuthorized()` helper without ASP.NET auth middleware — `.RequireAuthorization()` not added per sprint rules. | Developer |
-| 2026-02-22 | RASD-03 IssuerDirectory complete verification: `IssuerEndpoints.cs`, `IssuerKeyEndpoints.cs`, `IssuerTrustEndpoints.cs` all have `.RequireAuthorization(IssuerDirectoryPolicies.Reader/Writer/Admin)` and domain-semantic descriptions pre-existing. No changes required. | Developer |
-| 2026-02-22 | RASD-03 + RASD-05 Replay PointInTimeQueryEndpoints complete verification: `PointInTimeQueryEndpoints.cs` has `.RequireAuthorization()` at both group levels and all 8 endpoints have domain-semantic descriptions. No changes required. | Developer |
-| 2026-02-22 | **RASD-03 Wave A code-complete milestone**: All 35 services with minimal API endpoints have been processed. New *Policies.cs files created for orchestrator and notifier; `Program.cs` updated with `AddAuthorization` for both. Per-service policy constants wired to OAuth scopes. Health/probe/scale/OpenAPI endpoints carry `.AllowAnonymous()`. Excititor mandatory seed set confirmed: `vex.admin` on approve/reject, `vex.read` on list. Services without ASP.NET auth middleware (RiskEngine, Integrations, PacksRegistry, TaskRunner, VulnExplorer, DoctorScheduler, SmRemote) documented as non-standard auth per Decisions & Risks. Runtime validation pending RASD-06. | Developer |
-| 2026-02-22 | **RASD-05 Wave C code-complete milestone**: Domain-semantic `.WithDescription()` enrichment applied to all services. All same-as-summary, too-short, and HTTP-stub descriptions replaced. Services without previous descriptions received both `.WithName()` and `.WithDescription()`. Runtime OpenAPI diff validation pending RASD-06. | Developer |
-| 2026-02-24 | Audit correction: RASD-03 and RASD-05 moved from DONE to TODO because completion criteria remain unchecked in this sprint. Existing milestone rows remain implementation-progress evidence only. | Project Manager |
-
-## Decisions & Risks
-- Decision: endpoint-level plan is encoded directly in the inventory file via `authAction` and `descriptionAction` so execution is deterministic per endpoint.
-- Decision: prioritize Wave A by highest-volume services to reduce `source=None` exposure first.
-- Decision (orchestrator): Created `OrchestratorPolicies.cs` in `StellaOps.Orchestrator.WebService` namespace (child of Endpoints namespace, no extra `using` required). Policy constants use the same string value as the scope name per the pattern in `StellaOpsResourceServerPolicies`. Worker and task-runner endpoints use `OrchOperate` (`orch:operate`) scope; read-only query endpoints use `OrchRead` (`orch:read`); quota management uses `OrchQuota` (`orch:quota`). SLO write/control endpoints add per-endpoint `RequireAuthorization(Operate)` overrides on top of the `Read` group policy. Export endpoints use `ExportViewer` at group level with `ExportOperator` on write endpoints.
-- Decision (orchestrator): `Program.cs` did not have `AddAuthorization` registered before this change. Added it immediately after `AddOpenApi()` with `AddOrchestratorPolicies()` extension method call. No `AddStellaOpsResourceServerAuthentication` was added (authentication is already handled by the Router gateway layer per the existing compose contract).
-- Risk: services using manual in-handler authorization checks may appear authenticated without exported scopes/roles in OpenAPI. Mitigation: convert to endpoint metadata and policy-mapped claims in Wave A/B.
-- Risk: large-scale description edits can drift from implementation. Mitigation: pair documentation updates with endpoint tests and OpenAPI diff checks.
-- Risk: runtime and OpenAPI drift if containers are restarted without rebuilt images. Mitigation: include rebuild + redeploy verification in RASD-06.
-- Decision (PacksRegistry): Service uses a custom `IsAuthorized(context, auth, out result)` API-key check in every handler (no `AddAuthentication`/`AddAuthorization` ASP.NET middleware). Per Wave A rules, `.RequireAuthorization()` was not added. Wave C (`WithName`/`WithDescription`) was applied to all 14+ inline endpoints.
-- Decision (RiskEngine): No auth middleware registered in `Program.cs`. Per Wave A rules, `.RequireAuthorization()` was not added. All 4 `ExploitMaturityEndpoints.cs` descriptions and 5 inline `Program.cs` endpoints received Wave C enrichment.
-- Decision (Integrations): No auth middleware registered in `Program.cs`. Per Wave A rules, `.RequireAuthorization()` was not added. All 9 `IntegrationEndpoints.cs` descriptions expanded and `/health` probe annotated with `.AllowAnonymous()`.
-- Decision (VexLens): Auth pre-existing via group-level `.RequireAuthorization("vexlens.read"/"vexlens.write")`. Only Wave C description expansion applied to all 15 terse descriptions.
-
-## Next Checkpoints
-- ~~Wave A kickoff~~ DONE (code complete 2026-02-22).
-- ~~Wave C kickoff~~ DONE (code complete 2026-02-22).
-- **RASD-06**: Rebuild and redeploy compose stack; verify `https://stella-ops.local/openapi.json` shows `authSource != None` for all migrated endpoints and enriched descriptions visible. Lock CI quality gates.
-
-- **RASD-04**: Wave B — Scanner `policy_defined_scope_not_exported` (128 endpoints) and Authority `needs_auth_review` (37 endpoints) normalization review.

docs/implplan/SPRINT_20260222_052_DOCS_router_endpoint_auth_scope_description_backfill.services.csv

@@ -1,39 +0,0 @@
-"service","totalEndpoints","anonymousEndpoints","requiresAuthEndpoints","endpointsWithScopes","endpointsWithRoles","endpointsWithPolicies","authSourceNone","missingDescriptions","genericHttpDescriptions","sameAsSummaryDescriptions"
-"advisoryai","81","0","81","0","0","0","81","0","0","79"
-"airgap-controller","4","0","4","0","0","0","4","0","0","4"
-"attestor","45","0","45","0","0","0","45","0","0","38"
-"authority","45","6","39","0","0","0","2","0","0","39"
-"binaryindex","21","0","21","0","0","0","21","0","0","21"
-"concelier","144","0","144","0","0","0","144","0","0","136"
-"doctor","16","0","16","16","0","16","0","0","0","16"
-"doctor-scheduler","11","0","11","0","0","0","11","0","0","11"
-"evidencelocker","36","0","36","0","0","0","36","0","0","36"
-"excititor","55","0","55","0","0","0","55","0","0","51"
-"exportcenter","64","0","64","0","0","0","64","0","0","0"
-"findings-ledger","83","0","83","0","0","0","83","0","0","45"
-"integrations","20","0","20","0","0","0","20","0","0","0"
-"issuerdirectory","12","0","12","0","0","0","12","0","0","12"
-"notifier","197","0","197","0","0","0","197","0","0","164"
-"notify","49","0","49","0","0","0","49","0","0","49"
-"opsmemory","12","0","12","0","0","0","12","0","0","0"
-"orchestrator","313","0","313","0","0","0","313","0","0","0"
-"packsregistry","19","0","19","0","0","0","19","0","0","19"
-"platform","165","0","165","0","0","0","165","0","0","139"
-"policy-engine","202","0","202","0","0","0","202","0","0","170"
-"policy-gateway","121","0","121","0","0","0","121","0","0","54"
-"reachgraph","17","0","17","0","0","0","17","0","0","17"
-"replay","15","0","15","0","0","0","15","0","0","15"
-"riskengine","9","0","9","0","0","0","9","0","0","5"
-"sbomservice","51","0","51","0","0","0","51","0","0","51"
-"scanner","168","0","168","0","0","128","40","0","0","103"
-"scheduler","37","0","37","0","0","0","37","0","0","37"
-"signals","23","0","23","0","0","0","23","0","0","23"
-"signer","15","0","15","0","0","0","15","0","0","15"
-"smremote","6","0","6","0","0","0","6","0","0","6"
-"symbols","19","0","19","0","0","0","19","0","0","19"
-"taskrunner","33","0","33","0","0","0","33","0","0","33"
-"timelineindexer","12","0","12","12","0","12","0","0","0","0"
-"unknowns","8","0","8","0","0","0","8","0","0","0"
-"vexhub","16","0","16","0","0","0","16","0","0","0"
-"vexlens","36","0","36","0","0","0","36","0","0","0"
-"vulnexplorer","10","0","10","0","0","0","10","0","0","10"

docs/implplan/SPRINT_20260222_052_DOCS_router_endpoint_auth_scope_description_backfill.summary.json

@@ -1,14 +0,0 @@
-{
-    "generatedUtc":  "2026-02-22T17:24:57Z",
-    "endpointCount":  2190,
-    "anonymousEndpoints":  6,
-    "requiresAuthEndpoints":  2184,
-    "endpointsWithScopes":  28,
-    "endpointsWithRoles":  0,
-    "endpointsWithPolicies":  156,
-    "authSourceNone":  1991,
-    "missingDescriptions":  0,
-    "genericHttpDescriptions":  0,
-    "sameAsSummaryDescriptions":  1417,
-    "tooShortDescriptions":  90
-}

docs/implplan/SPRINT_20260222_061_AdvisoryAI_aks_execution_dag_parallel_lanes.md

@@ -1,221 +0,0 @@
-# Sprint 20260222_061 - AKS Execution DAG, Parallel Lanes, and Critical Path
-
-## Topic & Scope
-- This document is the execution scheduler for `SPRINT_20260222_061_AdvisoryAI_aks_hardening_e2e_operationalization.md`.
-- It converts backlog tasks into lane-based work packages with explicit dependencies, estimated durations, and release gating.
-- Working directory: `src/AdvisoryAI` (with explicitly allowed cross-module edits in `src/Cli`, `src/Web`, `docs`, and `devops/compose`).
-
-## Planning Assumptions
-- Time unit is engineering days (`d`) with 6.5 productive hours/day.
-- Estimates are `O/M/P` (`optimistic`, `most likely`, `pessimistic`) and `E = (O + 4M + P) / 6`.
-- Team model for this plan:
-  - `Backend`: 2 engineers.
-  - `CLI`: 1 engineer.
-  - `Web`: 1 engineer.
-  - `QA`: 2 engineers.
-  - `Docs`: 1 engineer.
-  - `PM`: 1 coordinator.
-- No major upstream contract rewrite from external modules during this sprint window.
-- Baseline start target: `2026-02-23`.
-
-## Lane Definitions
-| Lane | Primary Owner | Scope |
-| --- | --- | --- |
-| Lane-A Governance | PM + Backend lead + Docs lead | Contract freeze, source ownership, ingestion policy decisions |
-| Lane-B Backend Core | Backend | Ingestion/search internals, ranking, endpoint extensions, security hardening |
-| Lane-C CLI Ops | CLI | Operator workflow commands, dedicated DB ingestion workflow, machine-readable reports |
-| Lane-D Web UX | Web | Global search hardening, action safety UX, endpoint/doctor action affordances |
-| Lane-E QA/Benchmark | QA | Corpus expansion, quality metrics, E2E matrix, failure drills |
-| Lane-F Docs/Runbooks | Docs | Operational runbooks, schema docs, handoff documentation |
-
-## Work Package Catalog
-| WP | Maps To | Lane | Description | O | M | P | E | Predecessors | Deliverables |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| GOV-01 | AKS-HARD-001 | Lane-A | Freeze markdown source governance model (allow-list schema, ownership, inclusion policy) | 1.0 | 1.5 | 2.0 | 1.50 | none | Approved source-governance contract |
-| GOV-02 | AKS-HARD-002 | Lane-A | Freeze OpenAPI aggregate contract and compatibility policy | 0.5 | 1.0 | 1.5 | 1.00 | GOV-01 | Versioned OpenAPI aggregate schema contract |
-| GOV-03 | AKS-HARD-003 | Lane-A | Freeze doctor controls/action schema and safety taxonomy | 0.5 | 1.0 | 1.5 | 1.00 | GOV-01 | Doctor control schema v1 |
-| BE-01 | AKS-HARD-001 | Lane-B | Implement source validator + drift detection + coverage report | 1.5 | 2.5 | 4.0 | 2.58 | GOV-01 | Source lint command + CI check |
-| BE-02 | AKS-HARD-002 | Lane-B | Implement OpenAPI transform enrichment (auth/errors/schemas/synonyms) | 2.0 | 3.5 | 5.0 | 3.50 | GOV-02 | Enhanced API projection model |
-| BE-03 | AKS-HARD-003 | Lane-B | Implement doctor projection v2 with control-aware actions | 1.5 | 2.5 | 4.0 | 2.58 | GOV-03 | Doctor search projection upgrade |
-| BE-04 | AKS-HARD-005 | Lane-B | Extend search contracts (`explain`, debug fields, deterministic pagination) | 1.5 | 2.5 | 4.0 | 2.58 | BE-02, BE-03 | API contract extensions + tests |
-| BE-05 | AKS-HARD-006 | Lane-B | Ranking quality upgrades (query normalization, intent/rule packs, deterministic tie-breaks) | 2.0 | 3.0 | 4.5 | 3.08 | BE-04 | Ranking v2 + regression harness |
-| BE-06 | AKS-HARD-012 | Lane-B | Input limits, sanitization, tenant/authz assertions, timeout enforcement | 1.0 | 2.0 | 3.5 | 2.08 | BE-04 | Security hardening patchset |
-| CLI-01 | AKS-HARD-004 | Lane-C | Dedicated DB operator lifecycle commands (`validate/status/prepare/rebuild/verify`) | 1.5 | 2.5 | 4.0 | 2.58 | GOV-01 | CLI ops lifecycle commands |
-| CLI-02 | AKS-HARD-009 | Lane-C | Benchmark/report commands with schema-versioned JSON outputs | 1.0 | 2.0 | 3.0 | 2.00 | CLI-01, BE-05 | CLI benchmark + report command set |
-| WEB-01 | AKS-HARD-008 | Lane-D | Result grouping/filter/action hardening with deterministic behavior | 1.5 | 2.5 | 4.0 | 2.58 | BE-04, BE-03 | Updated global search interaction model |
-| WEB-02 | AKS-HARD-008 | Lane-D | Endpoint + doctor action safety UX (`run/inspect`, confirmations, cues) | 1.0 | 2.0 | 3.0 | 2.00 | WEB-01 | Action UX + accessibility tests |
-| QA-01 | AKS-HARD-007 | Lane-E | Expand corpus with curated operational cases and source provenance | 2.0 | 3.0 | 4.5 | 3.08 | GOV-01, GOV-02, GOV-03 | Curated+synthetic benchmark corpus |
-| QA-02 | AKS-HARD-006, AKS-HARD-011 | Lane-E | Run quality program (recall/precision/stability + latency/capacity baselines) | 1.5 | 2.5 | 3.5 | 2.50 | QA-01, BE-05 | Benchmark report and thresholds |
-| QA-03 | AKS-HARD-010 | Lane-E | Build and execute full E2E matrix (API/CLI/UI/DB) | 2.0 | 3.0 | 4.5 | 3.08 | QA-02, WEB-02, CLI-02 | Tier 2 evidence artifacts |
-| QA-04 | AKS-HARD-010, AKS-HARD-012 | Lane-E | Failure drills (missing vectors, stale aggregate, control gaps, timeout pressure) | 1.0 | 2.0 | 3.0 | 2.00 | QA-03, BE-06 | Failure drill report |
-| DOC-01 | AKS-HARD-001, AKS-HARD-002, AKS-HARD-003 | Lane-F | Source governance and schema docs (docs/openapi/doctor controls) | 1.0 | 1.5 | 2.5 | 1.58 | GOV-01, GOV-02, GOV-03 | Updated design/governance docs |
-| DOC-02 | AKS-HARD-004, AKS-HARD-013 | Lane-F | Operator runbooks (dedicated DB ingest/rebuild/verify/recover) | 1.5 | 2.0 | 3.0 | 2.08 | CLI-01, BE-04 | Operational runbook set |
-| PM-01 | AKS-HARD-013 | Lane-A | Release readiness review and handoff package signoff | 1.0 | 1.5 | 2.5 | 1.58 | QA-04, DOC-02 | Final handoff packet + release checklist |
-
-## Dependency DAG
-```mermaid
-graph TD
-  GOV01 --> GOV02
-  GOV01 --> GOV03
-  GOV01 --> BE01
-  GOV02 --> BE02
-  GOV03 --> BE03
-  BE02 --> BE04
-  BE03 --> BE04
-  BE04 --> BE05
-  BE04 --> BE06
-  GOV01 --> CLI01
-  CLI01 --> CLI02
-  BE05 --> CLI02
-  BE04 --> WEB01
-  BE03 --> WEB01
-  WEB01 --> WEB02
-  GOV01 --> QA01
-  GOV02 --> QA01
-  GOV03 --> QA01
-  QA01 --> QA02
-  BE05 --> QA02
-  QA02 --> QA03
-  WEB02 --> QA03
-  CLI02 --> QA03
-  QA03 --> QA04
-  BE06 --> QA04
-  GOV01 --> DOC01
-  GOV02 --> DOC01
-  GOV03 --> DOC01
-  CLI01 --> DOC02
-  BE04 --> DOC02
-  QA04 --> PM01
-  DOC02 --> PM01
-```
-
-## Critical Path Analysis
-### Candidate critical chain
-- `GOV-01 -> GOV-02 -> BE-02 -> BE-04 -> BE-05 -> QA-02 -> QA-03 -> QA-04 -> PM-01`
-
-### Expected duration math (`E`)
-- GOV-01: `1.50d`
-- GOV-02: `1.00d`
-- BE-02: `3.50d`
-- BE-04: `2.58d`
-- BE-05: `3.08d`
-- QA-02: `2.50d`
-- QA-03: `3.08d`
-- QA-04: `2.00d`
-- PM-01: `1.58d`
-- Total expected critical path: `20.82d`
-
-### Schedule envelope
-- P50 target (close to expected): `~21d`
-- P80 target (add ~20% contingency): `~25d`
-- Recommended plan commitment: `5 calendar weeks` including review buffers.
-
-### Near-critical chains
-- `GOV-01 -> GOV-03 -> BE-03 -> BE-04 -> WEB-01 -> WEB-02 -> QA-03` (`~14.4d`)
-- `GOV-01 -> CLI-01 -> CLI-02 -> QA-03` (`~9.2d`)
-- These chains have limited float after `BE-04`; slippage on `BE-04` consumes most downstream slack.
-
-## Parallel Execution Waves
-### Wave 0 - Contract Freeze (`Week 1`, days 1-2)
-- Execute: `GOV-01`, `GOV-02`, `GOV-03`.
-- Exit criteria:
-  - source governance contract approved.
-  - OpenAPI aggregate schema version approved.
-  - doctor control schema approved.
-
-### Wave 1 - Core Build (`Week 1-2`, days 2-8)
-- Lane-B: `BE-01`, `BE-02`, `BE-03`.
-- Lane-C: start `CLI-01`.
-- Lane-F: start `DOC-01`.
-- Exit criteria:
-  - ingestion validator and projection upgrades merged.
-  - dedicated DB command baseline available.
-  - schema/governance docs updated.
-
-### Wave 2 - Contract and Ranking (`Week 2-3`, days 8-14)
-- Lane-B: `BE-04`, `BE-05`, `BE-06`.
-- Lane-C: `CLI-02` (when `BE-05` stable).
-- Lane-D: start `WEB-01`.
-- Lane-E: start `QA-01`.
-- Exit criteria:
-  - search contract extensions merged.
-  - ranking v2 and security hardening merged.
-  - corpus expansion baseline generated.
-
-### Wave 3 - Integration and E2E (`Week 3-4`, days 14-20)
-- Lane-D: `WEB-02`.
-- Lane-E: `QA-02`, `QA-03`, then `QA-04`.
-- Lane-F: `DOC-02`.
-- Exit criteria:
-  - full E2E matrix passing in dedicated DB profile.
-  - benchmark and failure drill reports generated.
-  - operator runbooks complete.
-
-### Wave 4 - Release and Handoff (`Week 5`, days 21-25)
-- Lane-A: `PM-01`.
-- Cross-lane bug burn-down for residual defects from Wave 3.
-- Exit criteria:
-  - all quality/security/performance gates passed.
-  - handoff package signed and archived.
-
-## Sample-Case Discovery Program (Explicit Coverage Plan)
-| Case Family | Target Type | Minimum Cases | Ground Truth Key |
-| --- | --- | --- | --- |
-| Exact error strings | docs/doctor | 250 | doc path+anchor, checkCode |
-| Paraphrased troubleshooting | docs/doctor | 250 | doc path+anchor, checkCode |
-| Partial stack traces/log fragments | docs/doctor | 150 | doc path+anchor, checkCode |
-| Endpoint discovery prompts | api | 200 | method+path+operationId |
-| Auth and contract-error prompts | api/docs | 100 | operationId + doc anchor |
-| Readiness/preflight prompts | doctor/docs | 150 | checkCode + runbook anchor |
-| Version-filtered operational prompts | docs/api/doctor | 100 | type-specific key + version |
-| Ambiguous multi-intent prompts | mixed | 100 | expected top-k set |
-
-## E2E Matrix (Tier 2 Focus)
-| Surface | Scenario Group | Pass Criteria |
-| --- | --- | --- |
-| API | search, rebuild, explain/debug fields, filters | grounded results with deterministic actions and stable ordering |
-| API | failure drills (missing vectors, stale aggregate, limits) | deterministic fallback and explicit diagnostics |
-| CLI | `sources prepare`, `index rebuild`, `search`, `doctor suggest`, benchmark/report | stable JSON schema, deterministic exit codes |
-| UI | mixed result rendering, type filters, actions, more-like-this | predictable grouping/order, action wiring, accessibility |
-| DB | migration + index health + recovery/reset | deterministic counts/status and no orphaned projections |
-
-## Dedicated DB Ingestion Workflow (Operator Path)
-### Baseline sequence
-1. `docker compose -f devops/compose/docker-compose.advisoryai-knowledge-test.yml up -d`
-2. `stella advisoryai sources prepare --repo-root . --openapi-output devops/compose/openapi_current.json --json`
-3. `stella advisoryai index rebuild --json`
-4. `stella search "<query>" --json`
-5. `stella doctor suggest "<symptom>" --json`
-6. `stella advisoryai index status --json` (to be added under `CLI-01`)
-7. `stella advisoryai benchmark run --json` (to be added under `CLI-02`)
-
-### Recovery and rollback path
-1. preserve latest source manifests and benchmark outputs.
-2. run deterministic index reset/rebuild for dedicated DB profile.
-3. rerun smoke query suite and benchmark quick lane.
-4. only promote after thresholds and stability hash match.
-
-## Risk and Buffer Strategy
-- Add explicit management reserve: `15-20%` over expected critical path.
-- Trigger contingency if any of these are true:
-  - `BE-04` slips by > `1d`.
-  - `QA-02` fails thresholds twice consecutively.
-  - `QA-03` finds > `5` contract or grounding regressions.
-- Preferred mitigation sequence:
-  1. freeze non-critical UI polish.
-  2. reallocate 1 backend engineer to ranking/contract blockers.
-  3. defer non-blocking docs enhancements after release gate.
-
-## Exit Gates
-- Gate-1 Contract Freeze: `GOV-01..03` done.
-- Gate-2 Core Build: `BE-01..03`, `CLI-01`, `DOC-01` done.
-- Gate-3 Quality: `BE-04..06`, `QA-01..02` done with thresholds.
-- Gate-4 E2E: `WEB-01..02`, `CLI-02`, `QA-03..04`, `DOC-02` done.
-- Gate-5 Release: `PM-01` done and handoff package accepted.
-
-## Handoff Packet Requirements
-- Final dependency DAG with actual dates and variance.
-- Benchmark reports (recall/precision/stability/latency).
-- E2E evidence (API/CLI/UI/DB) and failure drill outcomes.
-- Dedicated DB operator runbook with known limitations.
-- Open risks and unresolved decisions with named owners.

docs/implplan/SPRINT_20260222_061_AdvisoryAI_aks_hardening_e2e_operationalization.md

@@ -1,260 +0,0 @@
-# Sprint 20260222_061 - AdvisoryAI AKS Hardening, E2E, and Operationalization
-
-## Topic & Scope
-- Convert AKS from MVP-complete to production-hardened retrieval platform with high precision, stable ranking, and operable ingestion workflows.
-- Close retrieval quality gaps for endpoint discovery, doctor recommendations, and version-filtered operational troubleshooting queries.
-- Add complete end-to-end verification (API + CLI + UI + dedicated DB) with deterministic quality gates and repeatable CI execution.
-- Working directory: `src/AdvisoryAI`.
-- Expected evidence: API/CLI/Web contract updates, deterministic dataset corpus, benchmark reports, E2E artifacts, operational runbooks.
-
-## Dependencies & Concurrency
-- Upstream baseline: `docs/implplan/SPRINT_20260222_051_AdvisoryAI_knowledge_search_docs_api_doctor.md`.
-- Required dependency references:
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/**`
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI.WebService/**`
-  - `src/__Libraries/StellaOps.Doctor/**`
-  - `src/Cli/StellaOps.Cli/**`
-  - `src/Web/StellaOps.Web/**`
-  - `devops/compose/**`
-- Explicit cross-module edits allowed for this sprint:
-  - `src/Cli/**` for AKS admin/index/benchmark command surfaces.
-  - `src/Web/StellaOps.Web/**` for global search behavior and operator workflows.
-  - `docs/modules/advisory-ai/**`, `docs/modules/cli/**`, `docs/operations/**` for runbooks and contracts.
-  - `devops/compose/**` for dedicated AKS DB profiles and reproducible seed harnesses.
-- Safe parallelism notes:
-  - Source-governance tasks can run in parallel with ranking improvements once schema contracts are frozen.
-  - UI/CLI flow hardening can proceed in parallel after search contract freeze.
-  - E2E and performance gates should start only after contract freeze + deterministic dataset freeze.
-
-## Documentation Prerequisites
-- `docs/modules/advisory-ai/knowledge-search.md`
-- `docs/modules/advisory-ai/architecture.md`
-- `docs/modules/platform/architecture-overview.md`
-- `docs/modules/cli/architecture.md`
-- `docs/07_HIGH_LEVEL_ARCHITECTURE.md`
-- `src/AdvisoryAI/AGENTS.md`
-- `src/Cli/AGENTS.md`
-- `src/Web/StellaOps.Web/AGENTS.md`
-
-## Delivery Tracker
-
-### AKS-HARD-001 - Source Governance and Ingestion Precision
-Status: BLOCKED
-Dependency: none
-Owners: Developer / Documentation author
-Task description:
-- Define and enforce deterministic source-governance policies for markdown ingestion, including allow-list structure, metadata ownership, and inclusion rationale.
-- Build source linting and drift detection so docs/specs/check projections remain reproducible and auditable between runs and branches.
-- Introduce strict include/exclude policy checks for noisy docs, archived content, and non-operational markdown.
-
-Completion criteria:
-- [ ] `knowledge-docs-allowlist` evolves into policy-driven manifest entries with product, version, service, tags, and ingest-priority metadata.
-- [ ] CLI validation command fails on malformed/ambiguous sources and emits actionable diagnostics.
-- [ ] Deterministic source coverage report is generated and checked in CI.
-- [ ] Documentation clearly defines ownership and update process for ingestion manifests.
-
-### AKS-HARD-002 - OpenAPI Aggregate Transformation and Endpoint Discovery Quality
-Status: BLOCKED
-Dependency: AKS-HARD-001
-Owners: Developer / Implementer
-Task description:
-- Harden OpenAPI aggregate ingestion contract from CLI-generated artifact into normalized, search-optimized endpoint representations.
-- Add deterministic extraction of auth requirements, common error contracts (including problem+json), schema snippets, and operation synonyms.
-- Improve endpoint discovery for "which endpoint for X" by query-intent aware boosts and canonical path/operation matching.
-
-Completion criteria:
-- [ ] Aggregate schema contract is explicitly versioned and validated before ingestion.
-- [ ] Operation projection includes method/path/opId plus auth, error codes, key params, and schema summary fields.
-- [ ] Endpoint-discovery benchmark subset reaches target recall@5 threshold and remains stable across runs.
-- [ ] Deterministic fallback behavior is documented when aggregate file is stale or missing.
-
-### AKS-HARD-003 - Doctor Operation Definitions and Safety Controls
-Status: BLOCKED
-Dependency: AKS-HARD-001
-Owners: Developer / Implementer
-Task description:
-- Formalize doctor-search controls schema to encode execution safety and operational intent per check.
-- Ensure each doctor projection includes explicit run, inspect, verify actions, prerequisites, and remediation anchors while preserving existing doctor execution semantics.
-- Align control metadata with UI and CLI action affordances (`safe`, `manual`, `destructive`, confirmation requirements, backup requirements).
-
-Completion criteria:
-- [ ] Doctor control schema includes `control`, `requiresConfirmation`, `isDestructive`, `requiresBackup`, `inspectCommand`, and `verificationCommand`.
-- [ ] Every indexed doctor check has deterministic action metadata and remediation references.
-- [ ] Disabled/manual controls are respected by UI/CLI action rendering and execution prompts.
-- [ ] Backward compatibility with existing doctor outputs is proven by targeted tests.
-
-### AKS-HARD-004 - Dedicated AKS DB Provisioning and Ingestion Operations
-Status: BLOCKED
-Dependency: AKS-HARD-001
-Owners: Developer / DevOps
-Task description:
-- Provide first-class AKS dedicated DB operational workflows for local dev, CI, and on-prem environments.
-- Add repeatable CLI workflows for provisioning DB, loading seed artifacts, rebuilding indexes, verifying index health, and resetting test fixtures.
-- Ensure flows are explicit about connection profiles, schema migrations, and pgvector availability checks.
-
-Completion criteria:
-- [ ] Dedicated DB profile(s) are documented and runnable with one command path.
-- [ ] CLI workflow supports deterministic: prepare -> rebuild -> verify -> benchmark pipeline.
-- [ ] Health/status command reports migration level, document/chunk counts, vector availability, and last rebuild metadata.
-- [ ] Recovery/reset path is documented and tested without destructive global side effects.
-
-### AKS-HARD-005 - Search Contract Extensions and Explainability
-Status: BLOCKED
-Dependency: AKS-HARD-002
-Owners: Developer / Implementer
-Task description:
-- Extend AKS endpoints with explicit explainability/debug contracts and operational search ergonomics.
-- Add optional explain/similar endpoints (or equivalent contract extension) for "why this result", "more like this", and reranking introspection.
-- Add defensive limits, timeout behavior, and deterministic pagination/cursor semantics for larger result sets.
-
-Completion criteria:
-- [ ] Search response can provide deterministic ranking explanation fields under explicit debug flag.
-- [ ] API contract supports "more like this" without hallucinated context expansion.
-- [ ] Timeouts and query-size constraints are enforced and tested.
-- [ ] OpenAPI and docs are updated with extension contracts and compatibility notes.
-
-### AKS-HARD-006 - Ranking Quality Program (Precision + Recall + Stability)
-Status: BLOCKED
-Dependency: AKS-HARD-002
-Owners: Developer / Test Automation
-Task description:
-- Build a formal ranking quality program with class-based evaluation for docs/api/doctor query archetypes.
-- Add deterministic query normalization and intent heuristics for stack traces, error signatures, endpoint lookup, and readiness diagnostics.
-- Track ranking regressions via per-class metrics and stability fingerprints.
-
-Completion criteria:
-- [ ] Per-class metrics are produced (`docs`, `api`, `doctor`; plus query archetype breakdown).
-- [ ] Stable ranking hash/signature is generated and diffed in CI.
-- [ ] Precision and recall minimum gates are enforced with defined fail-fast thresholds.
-- [ ] Regression triage workflow is documented with clear owner actions.
-
-### AKS-HARD-007 - Ground Truth Corpus Expansion and Sample Case Discovery
-Status: BLOCKED
-Dependency: AKS-HARD-001
-Owners: Test Automation / Documentation author
-Task description:
-- Expand dataset generator from synthetic-only baseline to mixed synthetic + curated operational cases.
-- Define explicit sample case catalog covering real-world failure strings, paraphrases, partial traces, endpoint lookup prompts, and preflight/readiness questions.
-- Add corpus governance for redaction, source provenance, and deterministic regeneration.
-
-Completion criteria:
-- [ ] Corpus includes 1,000-10,000 cases with balanced type coverage and explicit expected targets.
-- [ ] Curated case manifest tracks source provenance and redaction notes.
-- [ ] Dataset generation is deterministic from fixed seed inputs.
-- [ ] Corpus update/review process is documented for future expansion.
-
-### AKS-HARD-008 - UI Global Search Hardening and Action UX
-Status: BLOCKED
-Dependency: AKS-HARD-005
-Owners: Developer / Frontend
-Task description:
-- Harden UI global search for mixed results with deterministic grouping, filtering, and operator-safe action handling.
-- Improve endpoint and doctor result cards with explicit metadata, action confidence, and safe execution cues.
-- Ensure "show more like this" uses deterministic query context and produces predictable reruns.
-
-Completion criteria:
-- [ ] UI supports clear type filters and deterministic group ordering under mixed result loads.
-- [ ] Doctor actions expose control/safety context and confirmation UX where required.
-- [ ] Endpoint actions provide deterministic copy/open flows (including curl derivation if available).
-- [ ] Accessibility and keyboard navigation are validated for all new interactions.
-
-### AKS-HARD-009 - CLI Operator Workflow Hardening
-Status: BLOCKED
-Dependency: AKS-HARD-004
-Owners: Developer / Implementer
-Task description:
-- Expand CLI operations for AKS lifecycle management, troubleshooting, and automation.
-- Add stable machine-readable outputs for indexing status, source validation, benchmark runs, and regression checks.
-- Ensure offline-first operation with explicit failure diagnostics and remediation hints.
-
-Completion criteria:
-- [ ] CLI provides operator workflow commands for source validate, index status, benchmark run, and report export.
-- [ ] JSON outputs are schema-versioned and stable for automation pipelines.
-- [ ] Commands include deterministic exit codes and actionable error messages.
-- [ ] CLI docs include complete AKS dedicated DB ingestion and validation sequence.
-
-### AKS-HARD-010 - End-to-End Verification Matrix (API, CLI, UI, DB)
-Status: BLOCKED
-Dependency: AKS-HARD-008
-Owners: QA / Test Automation
-Task description:
-- Build end-to-end AKS verification matrix across API endpoints, CLI commands, UI global search, and dedicated DB backends.
-- Include nominal flows and failure drills: missing vectors, stale OpenAPI aggregate, missing doctor controls, and constrained timeout behavior.
-- Capture reproducible evidence artifacts for each matrix dimension.
-
-Completion criteria:
-- [ ] Tier 2 API tests verify grounded evidence and action payload correctness.
-- [ ] Tier 2 CLI tests verify operator flows and deterministic JSON outputs.
-- [ ] Tier 2 UI Playwright tests verify grouped rendering, filters, and action interactions.
-- [ ] Failure drill scenarios are automated and reported with explicit expected behavior.
-
-### AKS-HARD-011 - Performance, Capacity, and Cost Envelope
-Status: BLOCKED
-Dependency: AKS-HARD-006
-Owners: Developer / Test Automation
-Task description:
-- Define performance envelope for indexing and query latency on dev-grade hardware and enforce capacity guardrails.
-- Add benchmark lanes for p50/p95 latency, index rebuild duration, and memory/storage footprint.
-- Ensure deterministic behavior under high query volumes and concurrent search load.
-
-Completion criteria:
-- [ ] Thresholds are defined for query latency, rebuild duration, and resource footprint.
-- [ ] Benchmark lane runs in CI (fast subset) and nightly (full suite) with trend outputs.
-- [ ] Capacity risks and mitigation runbook are documented.
-- [ ] Performance regressions fail CI with clear diagnostics.
-
-### AKS-HARD-012 - Security, Isolation, and Compliance Hardening
-Status: BLOCKED
-Dependency: AKS-HARD-005
-Owners: Developer / Security reviewer
-Task description:
-- Validate query sanitization, authorization scopes, tenant isolation, and safe snippet rendering.
-- Add hardening for denial-of-service vectors (query size, token explosions, expensive patterns) and injection attempts.
-- Ensure all sensitive data handling in snippets and logs follows redaction policy.
-
-Completion criteria:
-- [ ] Security tests cover authz, tenant isolation, and malformed input handling.
-- [ ] Query/response limits are enforced and documented.
-- [ ] Redaction strategy for logs/snippets is implemented and verified.
-- [ ] Threat model and residual risks are captured in docs.
-
-### AKS-HARD-013 - Release Readiness, Runbooks, and Handoff Package
-Status: BLOCKED
-Dependency: AKS-HARD-010
-Owners: Project Manager / Documentation author / Developer
-Task description:
-- Prepare production-readiness package for AKS rollout and support ownership transfer.
-- Publish operational runbooks for ingestion operations, rollback, incident triage, and quality-gate interpretation.
-- Produce handoff bundle for the follow-up implementation agent with execution order, open decisions, and validation checkpoints.
-
-Completion criteria:
-- [ ] AKS runbooks cover install, ingest, rebuild, validate, benchmark, and rollback.
-- [ ] Handoff packet includes prioritized backlog, dependencies, risks, and acceptance gates.
-- [ ] Release checklist includes migration, observability, security, and performance signoff.
-- [ ] Sprint archive criteria and evidence references are complete.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-22 | Sprint created to plan post-MVP AKS hardening, e2e validation, and operationalization scope for next implementation agent. | Planning |
-| 2026-02-22 | Added companion execution DAG with parallel lanes, dependency graph, critical path estimates, wave schedule, and gate model: `docs/implplan/SPRINT_20260222_061_AdvisoryAI_aks_execution_dag_parallel_lanes.md`. | Planning |
-| 2026-02-24 | Sprint scope review: this sprint has been largely superseded by the unified smart search sprint series (097-100). AKS-HARD-008/009 are now marked BLOCKED in this file because completion criteria are not checked here; delivery evidence is tracked in successor sprints and must be explicitly mapped before these tasks can close. Remaining tasks stay BLOCKED with deferred scope notes. | Project Manager |
-
-## Decisions & Risks
-- Decision: Sprint superseded by unified search series (097-100). AKS-HARD-008/009 remain BLOCKED in this sprint until successor-sprint evidence is explicitly mapped to these acceptance criteria. Remaining tasks are absorbed into 098/100 or deferred. Companion DAG (061a) is superseded accordingly.
-- Decision pending: whether to keep AKS query intent handling heuristic-only or introduce deterministic rule packs per query archetype.
-- Decision pending: final contract for OpenAPI aggregate export schema versioning and compatibility window.
-- Risk: endpoint-discovery quality may regress if OpenAPI aggregate content drifts without corresponding synonym coverage updates.
-- Risk: doctor controls may become inconsistent with canonical check behavior unless schema ownership and validation rules are enforced.
-- Risk: CI cost/time can spike with full benchmark suites; mitigation requires split lanes (quick PR subset + nightly full).
-- Risk: dedicated DB workflows can diverge across environments; mitigation requires profile standardization and health/status command checks.
-- Risk: stale quality thresholds can hide regressions; mitigation requires periodic threshold review and benchmark baselining policy.
-- Companion schedule/DAG:
-  - `docs/implplan/SPRINT_20260222_061_AdvisoryAI_aks_execution_dag_parallel_lanes.md`
-
-## Next Checkpoints
-- 2026-02-23: Freeze source governance, OpenAPI aggregate contract, and doctor controls schema.
-- 2026-02-24: Complete dedicated DB operator workflow and extended search/API contract updates.
-- 2026-02-25: Deliver ranking quality program with expanded dataset and enforceable quality gates.
-- 2026-02-26: Complete UI/CLI hardening and E2E matrix evidence.
-- 2026-02-27: Finalize security/performance signoff and handoff package for implementation execution.

docs/implplan/SPRINT_20260223_098_AdvisoryAI_unified_search_federation_synthesis.md

@@ -1,499 +0,0 @@
-# Sprint 20260223_098 - Unified Smart Search: Federated Search, Entity Cards, and LLM Synthesis
-
-## Topic & Scope
-- Complete the remaining ingestion adapters (graph nodes, OpsMemory decisions, timeline events, scan results) to achieve full-domain coverage in the universal search index.
-- Build the federated query dispatcher that queries live backend systems (Console API, Graph API, Timeline API) in parallel alongside the universal index, enabling real-time data freshness for dynamic domains.
-- Implement entity resolution and card assembly that groups raw search results into multi-facet entity cards, deduplicating across domains and resolving entity aliases.
-- Implement the graph-aware gravity boost that elevates entities connected to detected query entities via graph edges.
-- Build the ambient context model that captures current page, visible entities, and recent searches to soft-boost contextually relevant results.
-- Deliver the LLM synthesis tier: a streaming synthesis endpoint (`POST /v1/search/synthesize`) that reuses existing AdvisoryAI chat infrastructure (prompt assembly, inference clients, grounding validation) to distill top entity cards into a cited, actionable answer.
-- Working directory: `src/AdvisoryAI`.
-- Expected evidence: adapters, federation logic, entity cards, synthesis endpoint, streaming tests, grounding validation, updated docs.
-
-## Dependencies & Concurrency
-- Upstream dependency: `SPRINT_20260223_097_AdvisoryAI_unified_search_index_foundation.md` (Phase 1 foundation).
-  - Specifically: USRCH-FND-001 (schema), USRCH-FND-002 (model), USRCH-FND-007 (incremental indexing), USRCH-FND-008 (W-RRF), USRCH-FND-009 (endpoint), USRCH-FND-010 (deterministic synthesis), USRCH-FND-011 (alias service).
-- Required dependency references:
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/**` (core, unified search modules from Phase 1)
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI.WebService/**` (endpoints)
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/Chat/**` (ChatPromptAssembler, GroundingValidator, inference clients, quota service)
-  - `src/Graph/StellaOps.Graph.Api/**` (graph search contracts, node models)
-  - `src/OpsMemory/StellaOps.OpsMemory/**` (decision models, similarity)
-  - `src/Timeline/StellaOps.Timeline/**` or `src/TimelineIndexer/**` (timeline event models)
-  - `src/Scanner/StellaOps.Scanner/**` (scan result models)
-- Explicit cross-module reads:
-  - `src/Graph/**` for graph node and edge models.
-  - `src/OpsMemory/**` for decision and playbook models.
-  - `src/TimelineIndexer/**` for audit event models.
-  - `src/Scanner/**` for scan result models.
-- Safe parallelism notes:
-  - Ingestion adapters (USRCH-FED-001 through 004) can all proceed in parallel.
-  - Federated dispatcher (005) can proceed in parallel with adapters.
-  - Entity resolution (006) depends on adapters being functional for test data.
-  - Gravity boost (007) and ambient context (008) can proceed in parallel.
-  - LLM synthesis (009-013) can proceed in parallel with federation work once the entity card model is frozen.
-
-## Documentation Prerequisites
-- `docs/modules/advisory-ai/knowledge-search.md`
-- `docs/modules/advisory-ai/architecture.md`
-- `src/AdvisoryAI/StellaOps.AdvisoryAI/Chat/ChatPromptAssembler.cs`
-- `src/AdvisoryAI/StellaOps.AdvisoryAI/Chat/GroundingValidator.cs`
-- `src/AdvisoryAI/StellaOps.AdvisoryAI/Chat/Services/AdvisoryChatQuotaService.cs`
-- `src/AdvisoryAI/StellaOps.AdvisoryAI/Inference/LlmProviders/ILlmProvider.cs`
-- `src/Graph/StellaOps.Graph.Api/Contracts/SearchContracts.cs`
-- `src/OpsMemory/StellaOps.OpsMemory/Similarity/SimilarityVectorGenerator.cs`
-- Phase 1 sprint: `docs/implplan/SPRINT_20260223_097_AdvisoryAI_unified_search_index_foundation.md`
-
-## Delivery Tracker
-
-### USRCH-FED-001 - Graph Node Ingestion Adapter
-Status: TODO
-Dependency: Phase 1 USRCH-FND-002
-Owners: Developer / Implementer
-Task description:
-- Implement `GraphNodeIngestionAdapter : ISearchIngestionAdapter` in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Adapters/GraphNodeIngestionAdapter.cs`.
-- The adapter reads from the Graph service's node repository and projects significant nodes (packages, images, base images, registries) into `UniversalChunk`s:
-  - `ChunkId`: `graph:{tenantId}:{nodeId}:{contentHash}`
-  - `Kind`: `graph_node`
-  - `Domain`: `graph`
-  - `Title`: `"{nodeKind}: {nodeName}" (e.g., "package: lodash@4.17.21", "image: registry.io/app:v1.2")`
-  - `Body`: Structured text combining: node kind, name, version, attributes (registry, tag, digest, layer count, OS, arch), direct dependency count, vulnerability summary (if overlay present), and key relationships (depends-on, contained-in).
-  - `EntityKey`: Derived from node kind: packages → `purl:{purl}`, images → `image:{imageRef}`, registries → `registry:{registryUrl}`.
-  - `EntityType`: `package`, `image`, `registry` (mapped from graph node `Kind`).
-  - `Metadata`: JSON with graph-specific attributes, dependency count, overlay data.
-  - `OpenAction`: `{ Kind: Graph, Route: "/ops/graph?node={nodeId}", NodeId, NodeKind }`
-  - `Freshness`: graph snapshot timestamp.
-- Ingestion strategy: **batch on graph snapshot**. When a new graph snapshot is committed, the adapter re-projects all significant nodes (filter out ephemeral/internal nodes to keep index size manageable).
-- Define "significant node" filter: nodes with `kind` in `[package, image, base_image, registry]` and at least one attribute or edge. Configurable via `UnifiedSearchOptions.GraphNodeKindFilter`.
-
-Completion criteria:
-- [ ] Adapter projects package and image nodes into valid `UniversalChunk`s.
-- [ ] Body text supports FTS for package names, versions, image references, registries.
-- [ ] Entity keys align with finding and VEX adapters (same CVE/PURL/image → same entity_key).
-- [ ] Node kind filter is configurable and prevents index bloat from ephemeral nodes.
-- [ ] Batch ingestion handles full snapshot replacement (delete old graph chunks, insert new).
-
-### USRCH-FED-002 - OpsMemory Decision Ingestion Adapter
-Status: TODO
-Dependency: Phase 1 USRCH-FND-002
-Owners: Developer / Implementer
-Task description:
-- Implement `OpsDecisionIngestionAdapter : ISearchIngestionAdapter` in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Adapters/OpsDecisionIngestionAdapter.cs`.
-- Project each OpsMemory decision into a `UniversalChunk`:
-  - `ChunkId`: `decision:{tenantId}:{decisionId}:{contentHash}`
-  - `Kind`: `ops_decision`
-  - `Domain`: `opsmemory`
-  - `Title`: `"Decision: {decisionType} for {subjectRef} ({outcome})"`
-  - `Body`: Structured text: decision type (waive, accept, remediate, escalate, defer), subject reference (CVE/package/image), rationale text, outcome status (success/failure/pending), resolution time, context tags (production/development/staging), severity at time of decision, similarity matching factors.
-  - `EntityKey`: Derived from subject: if CVE → `cve:{cveId}`, if package → `purl:{purl}`, if image → `image:{imageRef}`.
-  - `EntityType`: inherited from subject entity type.
-  - `Metadata`: JSON with `decisionType`, `outcomeStatus`, `resolutionTimeHours`, `contextTags[]`, `severity`, `similarityVector` (the 50-dim vector as array for optional faceted display).
-  - `OpenAction`: `{ Kind: Decision, Route: "/ops/opsmemory/decisions/{decisionId}", DecisionId }`
-  - `Freshness`: decision's `recordedAt` or `outcomeRecordedAt` (whichever is later).
-- Incremental path: index on decision create and outcome record events.
-- Preserve the structured 50-dim similarity vector in metadata for optional re-use in the synthesis tier (e.g., "similar past decisions" context).
-
-Completion criteria:
-- [ ] Adapter projects decisions with all outcome statuses into valid `UniversalChunk`s.
-- [ ] Body text supports FTS for decision types ("waive", "remediate"), subject references, and context tags.
-- [ ] Entity keys align with finding/VEX adapters for the same CVE/package.
-- [ ] Similarity vector preserved in metadata for optional downstream use.
-- [ ] Incremental path handles decision create and outcome record events.
-
-### USRCH-FED-003 - Timeline Event Ingestion Adapter
-Status: TODO
-Dependency: Phase 1 USRCH-FND-002
-Owners: Developer / Implementer
-Task description:
-- Implement `TimelineEventIngestionAdapter : ISearchIngestionAdapter` in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Adapters/TimelineEventIngestionAdapter.cs`.
-- Project audit/timeline events into `UniversalChunk`s:
-  - `ChunkId`: `event:{tenantId}:{eventId}:{contentHash}`
-  - `Kind`: `audit_event`
-  - `Domain`: `timeline`
-  - `Title`: `"{action} by {actorName} on {moduleName}" (e.g., "policy.evaluate by admin@acme on Policy")`
-  - `Body`: Structured text: action name, actor (name, role), module, target entity reference, timestamp, summary/description, key payload fields (e.g., "verdict: pass", "severity changed: high → critical").
-  - `EntityKey`: Derived from target entity if identifiable, otherwise null.
-  - `EntityType`: Derived from target entity type if identifiable, otherwise `event`.
-  - `Metadata`: JSON with `action`, `actor`, `module`, `targetRef`, `timestamp`, `payloadSummary`.
-  - `OpenAction`: `{ Kind: Event, Route: "/ops/audit/events/{eventId}", EventId }`
-  - `Freshness`: event timestamp.
-- Ingestion strategy: **event-driven append**. Timeline events are append-only; no updates or deletes.
-- Volume management: only index events from the last N days (configurable, default 90 days) to prevent unbounded index growth. Older events are pruned from the search index (not from the timeline store).
-
-Completion criteria:
-- [ ] Adapter projects audit events into valid `UniversalChunk`s.
-- [ ] Body text supports FTS for actor names, action types, module names, entity references.
-- [ ] Entity key extraction works for events targeting known entity types (CVEs, packages, policies).
-- [ ] Volume management prunes events older than configured retention period.
-- [ ] Append-only ingestion handles high-volume event streams without blocking.
-
-### USRCH-FED-004 - Scan Result Ingestion Adapter
-Status: TODO
-Dependency: Phase 1 USRCH-FND-002
-Owners: Developer / Implementer
-Task description:
-- Implement `ScanResultIngestionAdapter : ISearchIngestionAdapter` in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Adapters/ScanResultIngestionAdapter.cs`.
-- Project scan results into `UniversalChunk`s:
-  - `ChunkId`: `scan:{tenantId}:{scanId}:{contentHash}`
-  - `Kind`: `scan_result`
-  - `Domain`: `scanner`
-  - `Title`: `"Scan {scanId}: {imageRef} ({findingCount} findings, {criticalCount} critical)"`
-  - `Body`: Structured text: scan ID, image reference, scan type (vulnerability/compliance/license), status (complete/failed/in-progress), finding counts by severity, scanner version, duration, key policy verdicts.
-  - `EntityKey`: `scan:{scanId}` (primary), also link to `image:{imageRef}` via entity alias.
-  - `EntityType`: `scan`
-  - `Metadata`: JSON with `imageRef`, `scanType`, `status`, `findingCounts`, `policyVerdicts`, `duration`, `completedAt`.
-  - `OpenAction`: `{ Kind: Scan, Route: "/console/scans/{scanId}", ScanId }`
-  - `Freshness`: scan's `completedAt` timestamp.
-- Incremental path: index on scan complete events.
-
-Completion criteria:
-- [ ] Adapter projects scan results into valid `UniversalChunk`s.
-- [ ] Body text supports FTS for scan IDs, image references, severity keywords.
-- [ ] Entity aliases link scan to its target image.
-- [ ] Incremental path handles scan complete events.
-- [ ] Tenant isolation enforced.
-
-### USRCH-FED-005 - Federated Query Dispatcher
-Status: TODO
-Dependency: Phase 1 USRCH-FND-009
-Owners: Developer / Implementer
-Task description:
-- Implement `FederatedSearchDispatcher` in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Federation/FederatedSearchDispatcher.cs`.
-- The dispatcher executes queries against multiple backends **in parallel** and merges results into the unified pipeline:
-  1. **Universal index query** (always): FTS + vector search against `kb_chunk` (the primary path from Phase 1).
-  2. **Console API query** (optional, for live finding data): HTTP call to Console's search endpoint when `findings` domain is in the query plan with elevated weight. Returns fresh finding data that may not yet be indexed.
-  3. **Graph API query** (optional, for live topology): HTTP call to Graph's search endpoint when `graph` domain is elevated. Returns real-time node data.
-  4. **Timeline API query** (optional, for recent events): HTTP call to Timeline's search endpoint when `timeline` domain is elevated and query appears to reference recent activity.
-- Implement timeout budget: total query budget (default 500ms). Each federated backend gets a proportional timeout. If a backend times out, results from other backends are returned with a diagnostic note.
-- Implement `FederatedResultMerger` that normalizes results from different backends into `UniversalChunk` format before passing to the W-RRF fusion engine:
-  - Console results → `UniversalChunk` with kind=`finding`, domain=`findings`.
-  - Graph results → `UniversalChunk` with kind=`graph_node`, domain=`graph`.
-  - Timeline results → `UniversalChunk` with kind=`audit_event`, domain=`timeline`.
-  - Universal index results → already in `UniversalChunk` format.
-- Deduplication: if a federated result matches a chunk already in the universal index (same `entity_key` + `domain`), prefer the fresher version.
-- Configuration via `UnifiedSearchOptions.Federation`:
-  - `Enabled` (bool, default true)
-  - `ConsoleEndpoint`, `GraphEndpoint`, `TimelineEndpoint` (URLs)
-  - `TimeoutBudgetMs` (default 500)
-  - `MaxFederatedResults` (default 50 per backend)
-  - `FederationThreshold` (minimum domain weight to trigger federated query, default 1.2)
-
-Completion criteria:
-- [ ] Dispatcher queries universal index and relevant federated backends in parallel.
-- [ ] Federated results are correctly normalized to `UniversalChunk` format.
-- [ ] Timeout budget prevents slow backends from blocking the response.
-- [ ] Deduplication prefers fresher data when both index and federated backend return the same entity.
-- [ ] Diagnostics include per-backend latency and result counts.
-- [ ] Federation is gracefully disabled when backend endpoints are not configured.
-- [ ] Integration test verifies parallel dispatch with mock backends.
-
-### USRCH-FED-006 - Entity Resolution and Card Assembly
-Status: TODO
-Dependency: USRCH-FED-005, Phase 1 USRCH-FND-011
-Owners: Developer / Implementer
-Task description:
-- Implement `EntityCardAssembler` in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Cards/EntityCardAssembler.cs`.
-- Takes W-RRF-scored `UniversalChunk` results and groups them into `EntityCard`s:
-  1. **Sort** all results by fused score descending.
-  2. **Group by entity_key**: for each result with a non-null `entity_key`, merge into an existing card or create a new one. Use `EntityAliasService` to resolve aliases before grouping (e.g., `GHSA-xxxx` and `CVE-2025-1234` merge into the same card).
-  3. **Standalone results**: results without `entity_key` (e.g., generic doc sections, doctor checks not tied to a specific entity) become their own single-facet card.
-  4. **Facet assembly**: within each card, organize results by domain. Each domain's results become a `Facet` with title, snippet, score, metadata, and open action.
-  5. **Card scoring**: `aggregateScore = max(facet scores) + 0.1 * log(facetCount)` — slightly boost cards with more diverse facets.
-  6. **Connection discovery**: for cards with entity keys, query `entity_alias` table to find related entity keys. Populate `connections` field with up to 5 related entities.
-  7. **Action resolution**: determine `primaryAction` (highest-scored facet's open action) and `secondaryActions` (remaining facets' actions + contextual actions based on entity type).
-  8. **Synthesis hints**: extract key metadata fields from facets into a flat `Map<string, string>` for use by deterministic synthesis templates.
-- Final card ordering: by `aggregateScore` descending, then `entityType`, then `entityKey`.
-- Limit: max 20 cards per response (configurable).
-
-Completion criteria:
-- [ ] Entity grouping correctly merges chunks with matching entity keys.
-- [ ] Alias resolution merges GHSA/CVE/vendor IDs into single cards.
-- [ ] Cards have diverse facets from multiple domains when data exists.
-- [ ] Standalone results (no entity key) appear as individual cards.
-- [ ] Card scoring gives slight preference to cards with more facets.
-- [ ] Primary and secondary actions are correctly resolved per entity type.
-- [ ] Synthesis hints contain all key metadata fields for template rendering.
-- [ ] Card limit is enforced.
-- [ ] Unit tests verify grouping for: single-domain entity, multi-domain entity, alias-resolved entity, standalone result.
-
-### USRCH-FED-007 - Graph-Aware Gravity Boost
-Status: TODO
-Dependency: USRCH-FED-001, USRCH-FED-006
-Owners: Developer / Implementer
-Task description:
-- Implement `GravityBoostCalculator` in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Ranking/GravityBoostCalculator.cs`.
-- The gravity boost elevates search results that are **connected via graph edges** to entities explicitly mentioned in the query, even if the result text doesn't directly match the query:
-  - When the query mentions `CVE-2025-1234`, and the graph shows `CVE-2025-1234 → affects → libxml2 → contained-in → registry.io/app:v1.2`, then both `libxml2` and `registry.io/app:v1.2` get a gravity boost despite not being mentioned in the query.
-- Implementation:
-  1. For each `EntityMention` in the `QueryPlan`, resolve to `entity_key`.
-  2. Query the graph service for 1-hop neighbors of each resolved entity key (bounded to max 20 neighbors per entity, max 50 total).
-  3. Build a `gravityMap: Map<string entityKey, float boost>`:
-     - Direct mention in query: boost = 0 (already handled by entity proximity boost in W-RRF).
-     - 1-hop neighbor: boost = +0.30.
-     - 2-hop neighbor (optional, disabled by default): boost = +0.10.
-  4. Apply gravity boost additively during W-RRF fusion.
-- Performance constraint: graph neighbor lookup must complete within 100ms timeout. If it times out, skip gravity boost and log diagnostic.
-- Configuration via `UnifiedSearchOptions.GravityBoost`:
-  - `Enabled` (bool, default true)
-  - `OneHopBoost` (float, default 0.30)
-  - `TwoHopBoost` (float, default 0.10)
-  - `MaxNeighborsPerEntity` (int, default 20)
-  - `MaxTotalNeighbors` (int, default 50)
-  - `TimeoutMs` (int, default 100)
-
-Completion criteria:
-- [ ] Gravity boost correctly elevates 1-hop neighbors of query-mentioned entities.
-- [ ] Boost values are configurable.
-- [ ] Timeout prevents graph lookup from blocking search.
-- [ ] Gravity map is empty (no boost) when no entities are detected in query.
-- [ ] Integration test: query "CVE-2025-1234" → packages/images affected by that CVE get boosted.
-
-### USRCH-FED-008 - Ambient Context Model
-Status: TODO
-Dependency: Phase 1 USRCH-FND-003
-Owners: Developer / Implementer
-Task description:
-- Implement `AmbientContextProcessor` in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Context/AmbientContextProcessor.cs`.
-- The ambient context model captures client-side context and uses it to soft-boost relevant results:
-  - **Current route**: The UI page the user is on. Maps to a domain: `/console/findings/*` → findings, `/ops/policies/*` → policy, `/ops/graph/*` → graph, `/vex-hub/*` → vex, `/ops/audit/*` → timeline, `/ops/doctor/*` → doctor, `/docs/*` → knowledge.
-  - **Current entity IDs**: Entities visible on the current page (e.g., finding IDs displayed in a list, the CVE being viewed in detail). These get a direct entity proximity boost.
-  - **Recent searches**: Last 5 queries from the session. Used for implicit query expansion -- if the user previously searched for "CVE-2025-1234" and now searches "mitigation", the context carries forward the CVE entity.
-- Boost application:
-  - Route domain match: +0.10 to the matched domain's weight in `QueryPlan.DomainWeights`.
-  - Current entity ID match: +0.20 to any result whose `entity_key` matches a visible entity.
-  - Recent search entity carry-forward: if a detected entity from a recent search is not present in the current query but the current query looks like a follow-up (informational intent, no new entity mentions), add the recent entity's `entity_key` to the gravity boost map with boost +0.15.
-- The `AmbientContext` is passed in the search request from the frontend and is optional (graceful no-op if absent).
-
-Completion criteria:
-- [ ] Route-to-domain mapping correctly identifies domain from common UI routes.
-- [ ] Domain weight boost is applied when ambient context provides current route.
-- [ ] Entity ID boost elevates results matching visible entities.
-- [ ] Recent search carry-forward adds context for follow-up queries.
-- [ ] Absent ambient context produces no boost (graceful no-op).
-- [ ] Unit tests verify boost application for each context signal.
-
-### USRCH-FED-009 - Search Synthesis Service (LLM Integration)
-Status: TODO
-Dependency: USRCH-FED-006, Phase 1 USRCH-FND-010
-Owners: Developer / Implementer
-Task description:
-- Implement `SearchSynthesisService` in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Synthesis/SearchSynthesisService.cs`.
-- This service orchestrates the two-tier synthesis pipeline:
-  1. **Tier 1 (Deterministic)**: Always runs. Uses `DeterministicSynthesizer` from Phase 1 to produce a structured summary from entity card metadata. Returns immediately (< 50ms).
-  2. **Tier 2 (LLM)**: Runs on-demand when requested and LLM is available. Uses existing AdvisoryAI chat infrastructure to generate a deep, cited analysis.
-- LLM synthesis pipeline:
-  1. Check LLM availability via `ILlmProviderFactory.GetAvailableAsync()`.
-  2. Check quota via `AdvisoryChatQuotaService`.
-  3. Assemble prompt using a new `SearchSynthesisPromptAssembler` (reusing patterns from `ChatPromptAssembler`):
-     - System prompt: search-specific instructions (cite sources, suggest actions, stay grounded).
-     - Context section: query, intent, detected entities.
-     - Evidence section: top-K entity cards serialized as structured text with `[domain:route]` links.
-     - Deterministic summary: included as reference for the LLM to build upon.
-     - Grounding rules: citation requirements, action proposal format.
-  4. Stream inference via `ILlmProvider.CompleteStreamAsync()`.
-  5. Validate grounding via `GroundingValidator` on the complete response.
-  6. Extract action suggestions from the response.
-- Output: `SynthesisResult { DeterministicSummary, LlmAnalysis?, GroundingScore?, Actions[], SourceRefs[], Diagnostics }`.
-
-Completion criteria:
-- [ ] Deterministic tier always produces a summary regardless of LLM availability.
-- [ ] LLM tier correctly assembles prompt from entity cards.
-- [ ] LLM tier respects quota limits and returns graceful denial when quota exceeded.
-- [ ] Grounding validation runs on LLM output and score is reported.
-- [ ] Action suggestions are extracted and formatted with deep links.
-- [ ] Service gracefully degrades to deterministic-only when LLM is unavailable.
-
-### USRCH-FED-010 - Search Synthesis Prompt Engineering
-Status: TODO
-Dependency: USRCH-FED-009
-Owners: Developer / Implementer
-Task description:
-- Implement `SearchSynthesisPromptAssembler` in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Synthesis/SearchSynthesisPromptAssembler.cs`.
-- Design the prompt structure for search synthesis:
-  ```
-  SYSTEM:
-    You are the Stella Ops unified search assistant. Your role is to synthesize
-    search results into a concise, actionable answer. Rules:
-    - Use ONLY the evidence provided in the entity cards below.
-    - Cite every factual claim using [domain:route] links.
-    - Suggest 2-4 concrete next actions with deep links.
-    - If evidence is insufficient for a definitive answer, say so explicitly.
-    - Prioritize actionability over completeness.
-    - Keep the response under {maxTokens} tokens.
-
-  CONTEXT:
-    Query: "{normalizedQuery}"
-    Intent: {intent} (navigational / informational / action)
-    Detected entities: {entity list with types}
-    Ambient context: {current page, recent searches}
-
-  EVIDENCE:
-    ## Entity Card 1: {entityType}: {displayTitle} (score: {score})
-    ### Facets:
-    **{domain1}**: {snippet} [open: {route}]
-    Metadata: {key fields}
-    **{domain2}**: {snippet} [open: {route}]
-    ### Connections: {related entity refs}
-
-    ## Entity Card 2: ...
-    ...
-
-  DETERMINISTIC SUMMARY (for reference):
-    {deterministicSummary}
-
-  GROUNDING RULES:
-    - Object link format: [domain:route] (e.g., [findings:/console/findings/...])
-    - Valid domains: findings, vex, graph, knowledge, opsmemory, timeline, policy, scanner, doctor
-    - Ungrounded claims will be flagged and reduce your grounding score.
-
-  ACTION PROPOSALS:
-    Suggest actions from: Navigate to [entity], Run [doctor check], Create [waiver],
-    Compare [environments], View [graph/timeline], Explain further.
-    Format: "-> [Action label](route)" with clear, specific labels.
-
-  USER:
-    {originalQuery}
-  ```
-- Prompt must be version-tracked (increment version string when prompt changes) for reproducibility.
-- Token budget management: estimate entity card token cost, trim lower-scored cards if total exceeds `MaxContextTokens` (default 4000).
-- The system prompt should be loadable from an external file for operator customization.
-
-Completion criteria:
-- [ ] Prompt assembler produces well-structured prompts for various query types (CVE lookup, doc search, mixed results).
-- [ ] Token budget management correctly trims lower-scored cards when context is too large.
-- [ ] Prompt version is tracked and incremented on changes.
-- [ ] System prompt is loadable from external file.
-- [ ] Unit tests verify prompt structure for 5+ archetypal queries.
-
-### USRCH-FED-011 - Streaming Synthesis Endpoint: POST /v1/search/synthesize
-Status: TODO
-Dependency: USRCH-FED-009, USRCH-FED-010
-Owners: Developer / Implementer
-Task description:
-- Implement SSE endpoint `POST /v1/search/synthesize` in `UnifiedSearchEndpoints.cs`.
-- Request contract:
-  ```csharp
-  record SynthesizeRequest(
-      string Q,                              // original query
-      EntityCard[] TopCards,                  // entity cards from search response
-      QueryPlan? Plan,                       // query plan (optional, re-derived if absent)
-      SynthesisPreferences? Preferences      // depth (brief/detailed), maxTokens, includeActions
-  );
-  ```
-- Response: Server-Sent Events (SSE) stream with typed events:
-  - `event: synthesis_start` → `{ tier: "deterministic", summary: string }`
-  - `event: llm_status` → `{ status: "starting" | "streaming" | "validating" | "complete" | "unavailable" | "quota_exceeded" }`
-  - `event: llm_chunk` → `{ content: string, isComplete: bool }`
-  - `event: actions` → `{ actions: ActionSuggestion[] }` (emitted after LLM response is validated)
-  - `event: grounding` → `{ score: float, citations: int, ungrounded: int, issues: string[] }`
-  - `event: synthesis_end` → `{ totalTokens: int, durationMs: long, provider: string, promptVersion: string }`
-  - `event: error` → `{ code: string, message: string }` (for LLM failures)
-- Processing pipeline:
-  1. Immediately emit `synthesis_start` with deterministic summary.
-  2. Check LLM availability; if unavailable, emit `llm_status: unavailable` and `synthesis_end`.
-  3. Check quota; if exceeded, emit `llm_status: quota_exceeded` and `synthesis_end`.
-  4. Assemble prompt and begin streaming inference.
-  5. Forward `llm_chunk` events as they arrive.
-  6. On completion, validate grounding and emit `grounding` event.
-  7. Extract actions and emit `actions` event.
-  8. Emit `synthesis_end` with diagnostics.
-- Authorization: require `search:synthesize` scope (new scope, superset of `search:read`).
-- Error handling: if LLM inference fails mid-stream, emit `error` event and `synthesis_end`. The deterministic summary already emitted ensures the user has useful information.
-
-Completion criteria:
-- [ ] Endpoint streams SSE events in correct order.
-- [ ] Deterministic summary is always emitted first, regardless of LLM availability.
-- [ ] LLM chunks stream in real-time as they arrive from the provider.
-- [ ] Grounding validation runs and score is reported.
-- [ ] Action suggestions are emitted after LLM response.
-- [ ] Quota enforcement prevents unauthorized LLM usage.
-- [ ] Error handling provides graceful degradation.
-- [ ] Integration test verifies full SSE event sequence with mock LLM provider.
-
-### USRCH-FED-012 - Synthesis Quota and Audit Integration
-Status: TODO
-Dependency: USRCH-FED-011
-Owners: Developer / Implementer
-Task description:
-- Integrate synthesis endpoint with existing `AdvisoryChatQuotaService`:
-  - Search synthesis requests count toward the same daily quota as chat queries.
-  - Add a new quota dimension: `synthesisRequestsPerDay` (default: 200, separate from chat but sharing token pool).
-  - Track synthesis token usage in the same `{TenantId}:{UserId}` quota bucket.
-- Implement audit logging for synthesis requests:
-  - Log each synthesis request: query, entity card count, intent, provider used, tokens consumed, grounding score, duration.
-  - Reuse existing `advisoryai.chat_sessions` table pattern or create a new `advisoryai.search_synthesis_audit` table if schema separation is cleaner.
-  - Include prompt version in audit record for reproducibility.
-- Add rate limiting: max 10 concurrent synthesis requests per tenant (configurable).
-
-Completion criteria:
-- [ ] Synthesis requests are correctly counted against quota.
-- [ ] Token usage is tracked per synthesis request.
-- [ ] Audit records are written for every synthesis request.
-- [ ] Rate limiting prevents concurrent overload.
-- [ ] Quota denial returns appropriate SSE event.
-
-### USRCH-FED-013 - Federation and Synthesis Configuration Options
-Status: TODO
-Dependency: USRCH-FED-005, USRCH-FED-009
-Owners: Developer / Implementer
-Task description:
-- Define `UnifiedSearchOptions` in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/UnifiedSearchOptions.cs` as the central configuration for all unified search features:
-  ```csharp
-  public class UnifiedSearchOptions
-  {
-      public bool Enabled { get; set; } = true;
-      public string ConnectionString { get; set; }
-      public int DefaultTopK { get; set; } = 10;
-      public int MaxQueryLength { get; set; } = 512;
-      public int MaxCards { get; set; } = 20;
-
-      // Domain weight defaults (overridden by query understanding)
-      public Dictionary<string, double> BaseDomainWeights { get; set; }
-
-      // Federation
-      public FederationOptions Federation { get; set; } = new();
-
-      // Gravity boost
-      public GravityBoostOptions GravityBoost { get; set; } = new();
-
-      // Synthesis
-      public SynthesisOptions Synthesis { get; set; } = new();
-
-      // Ingestion
-      public IngestionOptions Ingestion { get; set; } = new();
-  }
-  ```
-- Sub-option classes for Federation (endpoints, timeouts, thresholds), GravityBoost (enabled, boost values, limits), Synthesis (LLM settings, maxTokens, promptPath, quotas), Ingestion (adapter-specific settings, retention periods, batch sizes).
-- Configuration section: `AdvisoryAI:UnifiedSearch`.
-- Validation: ensure required fields are present, ranges are valid, endpoints are well-formed.
-- Register with DI container and inject into all unified search services.
-
-Completion criteria:
-- [ ] All unified search features are configurable via `UnifiedSearchOptions`.
-- [ ] Configuration section loads correctly from `appsettings.json` / environment variables.
-- [ ] Validation prevents startup with invalid configuration.
-- [ ] Default values produce a working search experience without explicit configuration.
-- [ ] Options are injectable into all unified search services.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-23 | Sprint created from unified smart search architecture design. Covers Phase 2: federated search, entity cards, graph gravity, ambient context, and LLM synthesis tier. | Planning |
-
-## Decisions & Risks
-- Decision: federate to live backends rather than relying solely on the universal index. Rationale: ensures freshness for rapidly-changing data (findings, graph topology). Risk: federation adds latency and complexity; mitigation via timeout budget and domain-weight threshold gating.
-- Decision: reuse existing AdvisoryAI chat infrastructure (prompt assembler, grounding validator, inference clients, quota service) for synthesis. Rationale: avoids duplicating LLM infrastructure. Risk: search synthesis prompts may need different grounding rules than chat; mitigation via separate prompt assembler class.
-- Decision: batch ingestion for graph nodes (on snapshot) rather than incremental. Rationale: graph snapshots are atomic; incremental graph updates are complex. Risk: graph data may be stale between snapshots; mitigation via federated live query to Graph API.
-- Risk: gravity boost graph lookup could add significant latency for queries with many entity mentions. Mitigation: 100ms timeout, max 50 total neighbors, configurable disable.
-- Risk: ambient context could introduce personalization bias that makes search non-deterministic. Mitigation: ambient boost values are small (+0.10 to +0.20), configurable, and always additive (never removes results).
-- Risk: LLM synthesis prompt could exceed context window for queries with many entity cards. Mitigation: token budget management trims lower-scored cards.
-- Companion sprint for Phase 3 (frontend): `SPRINT_20260223_099_FE_unified_search_bar_entity_cards_synthesis_panel.md`.
-
-## Next Checkpoints
-- 2026-02-28: Phase 1 foundation complete (dependency).
-- 2026-03-01: All ingestion adapters complete (USRCH-FED-001 through 004).
-- 2026-03-02: Federated dispatcher and entity card assembly complete (USRCH-FED-005, 006).
-- 2026-03-03: Gravity boost and ambient context complete (USRCH-FED-007, 008).
-- 2026-03-04: LLM synthesis service and prompt engineering complete (USRCH-FED-009, 010).
-- 2026-03-05: Streaming endpoint, quota integration, and configuration complete (USRCH-FED-011, 012, 013).
-- 2026-03-06: Phase 2 review gate; hand off to Phase 3 (frontend) and Phase 4 (polish).

docs/implplan/SPRINT_20260223_100_AdvisoryAI_unified_search_polish_analytics_deprecation.md

@@ -1,361 +0,0 @@
-# Sprint 20260223_100 - Unified Smart Search: Quality, Analytics, Performance, and Deprecation
-
-## Topic & Scope
-- Establish a ranking quality program with precision/recall benchmarks for the unified search across all domains, ensuring the weighted RRF fusion and entity card assembly produce consistently excellent results.
-- Implement search analytics to track usage patterns, click-through rates, synthesis adoption, and identify improvement opportunities.
-- Optimize performance to meet latency targets (< 200ms for instant results, < 500ms for full results, < 5s for synthesis) and define capacity envelope.
-- Harden security: tenant isolation verification, query sanitization, and redaction for the universal index.
-- Deprecate the `PlatformSearchService` by migrating its catalog items into the universal index.
-- Implement search sessions to carry context between sequential queries for conversational search behavior.
-- Produce operational runbooks and release-readiness package for the unified search system.
-- Working directory: `src/AdvisoryAI`.
-- Expected evidence: benchmark reports, analytics dashboards, performance profiles, security tests, migration scripts, runbooks.
-
-## Dependencies & Concurrency
-- Upstream dependency: `SPRINT_20260223_097_AdvisoryAI_unified_search_index_foundation.md` (Phase 1).
-- Upstream dependency: `SPRINT_20260223_098_AdvisoryAI_unified_search_federation_synthesis.md` (Phase 2).
-- Upstream dependency: `SPRINT_20260223_099_FE_unified_search_bar_entity_cards_synthesis_panel.md` (Phase 3).
-- All Phase 4 tasks depend on at least Phase 1 and Phase 2 completion. Several tasks can proceed concurrently with Phase 3 frontend work.
-- Required dependency references:
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/**` (all unified search code)
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI.WebService/**`
-  - `src/Platform/StellaOps.Platform.WebService/Services/PlatformSearchService.cs` (deprecation target)
-  - `docs/modules/advisory-ai/**`
-- Explicit cross-module edits allowed:
-  - `src/Web/StellaOps.Web/src/app/core/api/unified-search.client.ts` for fallback hardening coupled to USRCH-POL-005 input validation.
-  - `src/Web/StellaOps.Web/src/app/core/api/unified-search.models.ts` for client-side supported-domain/type allowlists.
-  - `src/Platform/StellaOps.Platform.WebService/Endpoints/PlatformEndpoints.cs` for legacy platform search deprecation headers.
-  - `src/Platform/StellaOps.Platform.WebService/Services/PlatformSearchService.cs` for deterministic legacy output stabilization during deprecation window.
-- Safe parallelism notes:
-  - Quality benchmarks (001, 002) can start as soon as the unified endpoint is functional (after Phase 2).
-  - Analytics (003) and performance (004) can proceed in parallel.
-  - Security (005) can proceed in parallel with quality work.
-  - Platform deprecation (006) can proceed independently once adapters exist.
-  - Search sessions (007) depends on ambient context (Phase 3 USRCH-UI-007) but backend work can start earlier.
-  - Documentation (008) and release (009) are final tasks.
-
-## Documentation Prerequisites
-- All Phase 1-3 sprint files and their completion evidence.
-- `docs/modules/advisory-ai/knowledge-search.md`
-- `src/AdvisoryAI/AGENTS.md`
-- `src/Platform/StellaOps.Platform.WebService/Services/PlatformSearchService.cs` (for deprecation planning)
-
-## Delivery Tracker
-
-### USRCH-POL-001 - Unified Search Ranking Quality Benchmarks
-Status: TODO
-Dependency: Phase 2 complete
-Owners: Test Automation / Developer
-Task description:
-- Build a ranking quality program for the unified search system that evaluates precision and recall across all domains and query archetypes.
-- Define a ground-truth evaluation corpus of 200+ query-result pairs organized by archetype:
-  - **CVE lookup** (30+ queries): "CVE-2025-1234", "critical vulnerabilities in libxml2", "reachable CVEs in production".
-  - **Package/image search** (30+ queries): "lodash vulnerabilities", "pkg:npm/express", "images with critical findings".
-  - **Documentation search** (30+ queries): "how to deploy air-gap", "policy configuration guide", "scanner setup".
-  - **Doctor/diagnostic** (20+ queries): "disk full error", "health check failed", "DR-0042".
-  - **Policy search** (20+ queries): "CVSS threshold gate", "signature required policy", "production enforcement".
-  - **Audit/timeline** (20+ queries): "who approved waiver", "policy changes last week", "scan events for app:v1.2".
-  - **Cross-domain** (30+ queries): "CVE-2025-1234 mitigation options" (should surface findings + docs + past decisions), "libxml2 in production" (should surface graph + findings + scans).
-  - **Conversational follow-up** (20+ queries): query pairs where second query builds on first.
-- Each query has labeled expected results with relevance grades (0=irrelevant, 1=marginally relevant, 2=relevant, 3=highly relevant).
-- Metrics computed:
-  - **Precision@K** (K=1, 3, 5, 10) per archetype.
-  - **Recall@K** per archetype.
-  - **NDCG@10** (Normalized Discounted Cumulative Gain) per archetype.
-  - **Entity card accuracy**: % of queries where the top entity card is the correct primary entity.
-  - **Cross-domain recall**: % of queries where results include facets from 2+ domains (when expected).
-  - **Ranking stability hash**: deterministic fingerprint of result ordering for regression detection.
-- Quality gates (minimum thresholds):
-  - P@1 >= 0.80 (top result is relevant 80% of the time).
-  - NDCG@10 >= 0.70.
-  - Entity card accuracy >= 0.85.
-  - Cross-domain recall >= 0.60 for cross-domain query archetype.
-- Benchmark runner: CLI command `stella advisoryai benchmark run --corpus <path> --output <report-path>`.
-- CI integration: fast subset (50 queries) runs on every PR; full suite runs nightly.
-
-Completion criteria:
-- [ ] Evaluation corpus of 200+ query-result pairs exists with relevance grades.
-- [ ] Benchmark runner computes all metrics and outputs structured report.
-- [ ] Quality gates are defined and enforced (fail if below threshold).
-- [ ] Ranking stability hash detects ordering changes between runs.
-- [ ] CI integration runs fast subset on PR, full suite nightly.
-- [ ] Current baseline metrics are established and documented.
-
-### USRCH-POL-002 - Domain Weight Tuning and Boost Calibration
-Status: TODO
-Dependency: USRCH-POL-001
-Owners: Developer / Test Automation
-Task description:
-- Using the benchmark corpus from USRCH-POL-001, empirically tune the domain weight parameters and boost values for optimal ranking quality:
-  - **Base domain weights**: starting values (all 1.0), adjust per archetype performance.
-  - **Entity boost values**: CVE detection → findings +X, vex +Y, graph +Z. Find optimal X, Y, Z.
-  - **Intent keyword boost values**: per-keyword weights for each domain.
-  - **Ambient context boost values**: route match +A, entity ID match +B.
-  - **Gravity boost values**: 1-hop +C, 2-hop +D.
-  - **Freshness decay**: decay period in days, max boost value.
-  - **Entity proximity boost**: direct match +E, alias match +F.
-- Tuning methodology:
-  - Grid search over discrete parameter combinations.
-  - Evaluate each combination against the benchmark corpus.
-  - Select the parameter set that maximizes NDCG@10 while maintaining P@1 >= 0.80.
-  - Validate stability: run 3x with different random seeds to ensure determinism.
-- Document optimal parameters and their rationale.
-- Update `UnifiedSearchOptions` default values with tuned parameters.
-- Record tuning results in a reproducible report format.
-
-Completion criteria:
-- [ ] Grid search covers meaningful parameter ranges for all boost values.
-- [ ] Optimal parameter set achieves quality gates from USRCH-POL-001.
-- [ ] Parameters are deterministic (stable across runs).
-- [ ] Tuning report documents methodology, results, and rationale.
-- [ ] `UnifiedSearchOptions` defaults updated with tuned values.
-- [ ] Before/after comparison shows measurable improvement over baseline.
-
-### USRCH-POL-003 - Search Analytics and Usage Tracking
-Status: DOING
-Dependency: Phase 2 complete
-Owners: Developer / Implementer
-Task description:
-- Implement search analytics collection in the unified search endpoint:
-  - **Query analytics**: For each search request, record: query text (hashed for privacy), intent classification, detected entity types, domain weights applied, result count, entity card count, top result types, latency breakdown (FTS/vector/federation/fusion/total), timestamp, tenant ID.
-  - **Click-through tracking**: When the frontend navigates to a search result action, record: query hash, clicked card entity key, clicked action kind, card rank position, facet domain clicked, timestamp.
-  - **Synthesis analytics**: For each synthesis request, record: query hash, tier used (deterministic-only / LLM), LLM provider, tokens consumed, grounding score, action count suggested, duration, user engaged (scrolled/clicked action), timestamp.
-- Storage: new table `advisoryai.search_analytics` with JSONB payload column for flexible schema evolution. Partition by month for efficient retention management.
-- Aggregation queries:
-  - Popular query patterns (by intent, by entity type, by domain).
-  - Click-through rate per entity card position.
-  - Synthesis adoption rate (% of searches that trigger synthesis).
-  - Mean grounding score over time.
-  - P95 latency percentiles over time.
-  - Zero-result query rate.
-- Privacy: query text is hashed (SHA-256); no PII stored. Configurable opt-out per tenant.
-- Retention: configurable, default 90 days.
-
-Completion criteria:
-- [x] Query analytics recorded for every unified search request.
-- [ ] Click-through events recorded when user navigates from search results.
-- [ ] Event taxonomy is consistent across analytics writes and metrics reads (`query`, `click`, `zero_result`) with no stale `search` event dependency.
-- [ ] Synthesis analytics recorded for every synthesis request.
-- [ ] Aggregation queries produce meaningful reports.
-- [ ] Privacy: no raw query text or PII stored in analytics.
-- [ ] Retention policy enforced with automatic pruning.
-- [ ] Analytics collection adds < 5ms overhead to search latency.
-
-### USRCH-POL-004 - Performance Optimization and Capacity Envelope
-Status: TODO
-Dependency: Phase 2 complete
-Owners: Developer / Test Automation
-Task description:
-- Define and enforce performance targets for unified search:
-  - **Instant results** (Phase 1 typing): P50 < 100ms, P95 < 200ms, P99 < 300ms.
-  - **Full results with federation**: P50 < 200ms, P95 < 500ms, P99 < 800ms.
-  - **Synthesis (deterministic tier only)**: P50 < 30ms, P95 < 50ms.
-  - **Synthesis (LLM tier)**: time-to-first-token P50 < 1s, total P50 < 3s, P95 < 5s.
-  - **Index rebuild (full)**: < 5 minutes for 100K chunks.
-  - **Incremental ingestion**: < 100ms per event.
-- Performance optimization areas:
-  - **Connection pooling**: ensure DB connection pooling is tuned for concurrent search + ingestion.
-  - **Query optimization**: analyze and optimize FTS + vector SQL queries with `EXPLAIN ANALYZE`. Add covering indexes if needed.
-  - **Federation timeout tuning**: adjust per-backend timeout based on measured latency.
-  - **Entity card assembly**: profile and optimize grouping/sorting for large result sets.
-  - **W-RRF fusion**: optimize the fusion loop for minimal allocations.
-  - **Caching**: consider in-memory cache for entity alias lookups (already has TTL cache from Phase 1), gravity boost neighbor sets (cache per entity key with TTL).
-- Load testing:
-  - Concurrent search load: 50 concurrent searches against unified endpoint, measure latency distribution.
-  - Concurrent ingestion: simulate high-volume finding/event ingestion while searching.
-  - Index size impact: measure latency with 10K, 50K, 100K, 500K chunks.
-- Document capacity envelope: maximum chunk count, concurrent queries, and ingestion rate supported within latency targets.
-
-Completion criteria:
-- [ ] Performance targets are defined and documented.
-- [ ] Latency benchmarks run in CI (quick subset on PR, full on nightly).
-- [ ] SQL queries are optimized with `EXPLAIN ANALYZE` evidence.
-- [ ] Load test results show sustained performance under 50 concurrent searches.
-- [ ] Capacity envelope is documented with recommended hardware specs.
-- [ ] No latency regression > 10% from Phase 1 baseline after all Phase 2-3 additions.
-
-### USRCH-POL-005 - Security Hardening: Tenant Isolation, Sanitization, and Redaction
-Status: DOING
-Dependency: Phase 2 complete
-Owners: Developer / Security reviewer
-Task description:
-- Verify and harden tenant isolation in the universal search index:
-  - All search queries must include tenant filter. Add a defensive check that rejects queries without tenant context.
-  - Verify that incremental ingestion from one tenant cannot inject chunks visible to another tenant.
-  - Verify that entity alias resolution is tenant-scoped (or that aliases are global but results are tenant-filtered).
-  - Verify that federated queries pass tenant context to all backend services.
-- Query sanitization:
-  - Validate query length (max 512 chars), reject queries exceeding limit.
-  - Validate filter values (domain names, severity values) against allowlists.
-  - Sanitize snippet rendering to prevent XSS in `<mark>` tags or metadata values.
-  - Rate-limit search requests per tenant (configurable, default 100/min).
-- Redaction:
-  - Ensure search analytics do not store raw query text (hashed only).
-  - Ensure synthesis audit logs do not store full LLM prompts (store prompt hash + metadata only).
-  - Ensure error messages do not leak internal schema or query details.
-- Threat model update:
-  - Document attack vectors specific to unified search (cross-tenant data leakage via entity aliases, prompt injection via indexed content, denial-of-service via expensive queries).
-  - Document mitigations for each vector.
-
-Completion criteria:
-- [ ] Tenant isolation verified: cross-tenant search returns zero results.
-- [ ] Incremental ingestion tenant isolation verified.
-- [x] Query length and filter validation enforced.
-- [ ] Snippet rendering is XSS-safe.
-- [x] Rate limiting is enforced per tenant.
-- [ ] Analytics and audit logs contain no raw query text or PII.
-- [ ] Threat model documented with mitigations.
-
-### USRCH-POL-006 - Platform Search Deprecation and Migration
-Status: DOING
-Dependency: Phase 1 USRCH-FND-007 (incremental indexing)
-Owners: Developer / Implementer
-Task description:
-- Migrate `PlatformSearchService` catalog items into the universal search index:
-  - The existing `PlatformSearchService` has a hardcoded catalog of 5 items (scan, policy, finding, pack, tenant). These represent platform-level resource types, not individual instances.
-  - Create `PlatformCatalogIngestionAdapter : ISearchIngestionAdapter` that projects these catalog items as `platform_entity` chunks in the universal index.
-  - Each platform catalog item becomes a chunk with `kind: platform_entity`, `domain: platform`.
-  - These chunks serve as "type landing pages" — searching for "scans" should surface the scan catalog entry which links to the scans list page.
-- Update consumers:
-  - If `GET /api/v1/platform/search` has any remaining consumers, redirect them to the unified search endpoint. Add a deprecation header (`Deprecation: true`, `Sunset: <date>`).
-  - Update any frontend components that call the platform search endpoint to use the unified search client instead.
-- Deprecation timeline:
-  - Phase 4 start: add deprecation headers to platform search endpoint.
-  - Phase 4 + 30 days: remove platform search endpoint and `PlatformSearchService`.
-- Document migration in changelog.
-
-Completion criteria:
-- [x] Platform catalog items are indexed in the universal search index.
-- [x] Platform search endpoint returns deprecation headers.
-- [ ] All frontend consumers migrated to unified search.
-- [ ] Unified search surfaces platform catalog items for relevant queries.
-- [ ] Unified-search client fallback to legacy search surfaces an explicit degraded-mode indicator in UI.
-- [ ] Deprecation timeline documented in changelog.
-
-### USRCH-POL-007 - Search Sessions and Conversational Context
-Status: TODO
-Dependency: Phase 3 USRCH-UI-007 (ambient context service)
-Owners: Developer / Implementer
-Task description:
-- Implement search sessions that carry context between sequential queries, enabling conversational search without LLM:
-  - **Session model**: `SearchSession { SessionId, TenantId, UserId, Queries[], DetectedEntities[], CreatedAt, LastActiveAt }`.
-  - A session is created on the first search query and maintained for 5 minutes of inactivity (configurable).
-  - Each query appends to the session's query history and detected entity set.
-  - **Contextual query expansion**: when a query has no detected entities but the session has previously detected entities (from earlier queries), carry forward those entities as implicit context:
-    - Example: Query 1: "CVE-2025-1234" → detects CVE entity, returns findings/VEX/docs.
-    - Query 2: "mitigation" → no entities detected, but session has CVE-2025-1234 → add `cve:CVE-2025-1234` to gravity boost map with boost +0.15 → mitigation results for that CVE are boosted.
-  - **Session entity accumulation**: entities from all queries in the session are accumulated (with decay — older entities get lower boost than recent ones).
-  - **Session reset**: explicit "new search" action (Ctrl+Shift+K or clicking the search icon when search is open) clears the session.
-- Backend: store sessions in memory (not DB — ephemeral, per-instance). For multi-instance deployments, sessions are sticky to the instance via client-side session ID.
-- Frontend: `AmbientContextService` includes session ID in search requests. Session ID stored in `sessionStorage`.
-
-Completion criteria:
-- [ ] Session maintains entity context across sequential queries.
-- [ ] Contextual query expansion correctly boosts results related to previously searched entities.
-- [ ] Entity decay reduces influence of older session entities.
-- [ ] Session expires after 5 minutes of inactivity.
-- [ ] Explicit reset clears session state.
-- [ ] Session storage is ephemeral (no persistent state).
-- [ ] Integration test: query sequence "CVE-2025-1234" → "mitigation" → verify mitigation results are CVE-contextualized.
-
-### USRCH-POL-008 - Documentation and Operational Runbooks
-Status: TODO
-Dependency: USRCH-POL-001, USRCH-POL-004, USRCH-POL-005
-Owners: Documentation author / Developer
-Task description:
-- Create/update the following documentation:
-  - **Architecture doc**: `docs/modules/advisory-ai/unified-search-architecture.md` — comprehensive architecture document covering all 4 layers (query understanding, federated search, fusion, synthesis), data model, ingestion pipeline, and configuration.
-  - **Operator runbook**: `docs/operations/unified-search-operations.md` — operational guide covering:
-    - Initial setup: database migration, index rebuild, configuration.
-    - Ingestion operations: adding new ingestion adapters, triggering ingestion, verifying ingestion health.
-    - Monitoring: key metrics to watch (latency, error rate, index size, zero-result rate, synthesis usage).
-    - Troubleshooting: common issues (slow queries, missing results, stale index, federation failures, LLM errors) and resolution steps.
-    - Scaling: when to add replicas, connection pool tuning, pgvector index tuning.
-    - Backup and recovery: index rebuild from sources, no separate backup needed.
-  - **API reference**: update OpenAPI specs for `POST /v1/search/query` and `POST /v1/search/synthesize`.
-  - **CLI reference**: update CLI docs for new `stella search` flags and `--synthesize` option.
-  - **Configuration reference**: document all `UnifiedSearchOptions` fields with descriptions, defaults, and valid ranges.
-- Update `docs/07_HIGH_LEVEL_ARCHITECTURE.md` with unified search system in the architecture diagram.
-- Update `src/AdvisoryAI/AGENTS.md` with unified search module ownership and contract references.
-
-Completion criteria:
-- [ ] Architecture doc covers all 4 layers with diagrams and data flow.
-- [ ] Operator runbook covers setup, monitoring, troubleshooting, and scaling.
-- [ ] OpenAPI specs generated and accurate for new endpoints.
-- [ ] CLI docs updated with new flags and output format.
-- [ ] Configuration reference covers all options with examples.
-- [ ] High-level architecture doc updated.
-- [ ] Module AGENTS.md updated.
-
-### USRCH-POL-009 - Release Readiness and Sprint Archive
-Status: TODO
-Dependency: USRCH-POL-001 through USRCH-POL-008
-Owners: Project Manager / Developer / Documentation author
-Task description:
-- Prepare release-readiness package for the unified search system:
-  - **Release checklist**:
-    - [ ] Schema migration tested on clean DB and existing DB with data.
-    - [ ] All ingestion adapters verified with real data from each source system.
-    - [ ] Ranking quality gates met (P@1 >= 0.80, NDCG@10 >= 0.70).
-    - [ ] Performance targets met (P95 < 200ms instant, < 500ms full, < 5s synthesis).
-    - [ ] Tenant isolation verified.
-    - [ ] Accessibility audit passed.
-    - [ ] CLI backward compatibility verified.
-    - [ ] Legacy endpoint backward compatibility verified.
-    - [ ] Analytics collection operational.
-    - [ ] Runbooks reviewed by operations team.
-  - **Rollback plan**: document how to disable unified search (feature flag) and revert to legacy search without data loss.
-  - **Known issues**: document any known limitations, edge cases, or planned future improvements.
-  - **Sprint archive**: verify all tasks in Phase 1-4 sprints are DONE, then move sprint files to `docs-archived/implplan/`.
-- Feature flag configuration:
-  - `UnifiedSearch.Enabled` (default: false for initial rollout, toggle to true per tenant).
-  - `UnifiedSearch.SynthesisEnabled` (separate flag for LLM synthesis, allows enabling search without synthesis).
-  - `UnifiedSearch.FederationEnabled` (separate flag for federated queries).
-
-Completion criteria:
-- [ ] Release checklist completed with all items checked.
-- [ ] Rollback plan documented and tested.
-- [ ] Known issues documented.
-- [ ] Feature flags defined and tested (enable/disable per tenant).
-- [ ] All Phase 1-4 sprint tasks marked DONE.
-- [ ] Sprint files archived to `docs-archived/implplan/`.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-23 | Sprint created from unified smart search architecture design. Covers Phase 4: quality benchmarks, analytics, performance, security, deprecation, search sessions, docs, and release readiness. | Planning |
-| 2026-02-24 | USRCH-POL-005 started: unified search now enforces `q` length <= 512, rejects unsupported `filters.domains`/`filters.entityTypes` with HTTP 400, and web unified search now falls back to legacy AKS with mapped entity cards. | Developer |
-| 2026-02-24 | Added tenant-bound search filtering in AKS/unified SQL paths, canonicalized search auth pipeline (`UseAuthentication` + policy-only endpoint checks), added unified index rebuild endpoint (`POST /v1/search/index/rebuild`) and optional periodic auto-index service, replaced hardcoded unified sample adapters with snapshot-backed ingest, and added platform catalog ingestion adapter with platform search deprecation headers. | Developer |
-| 2026-02-24 | Added unified query telemetry sink with SHA-256 query hashing + intent/domain diagnostics; added new unified endpoint integration tests for scope gating, filter validation, tenant requirement, and rebuild flow. | Developer |
-| 2026-02-24 | QA reference acknowledged for Tier-2 UI behavior coverage: existing Playwright suites in `src/Web/StellaOps.Web/tests/e2e/unified-search*.spec.ts` and case corpus in `docs/qa/unified-search-test-cases.md` remain authoritative behavioral test inventory. | Developer |
-| 2026-02-24 | Fixed unified endpoint strict filter validation path so unsupported domains/types fail with HTTP 400 before service invocation, and revalidated targeted classes with xUnit v3 class filters: `KnowledgeSearchEndpointsIntegrationTests` (3/3) and `UnifiedSearchEndpointsIntegrationTests` (5/5). | Developer |
-| 2026-02-24 | Attempted Tier-2 UI behavioral run: `npx playwright test tests/e2e/unified-search-doctor.e2e.spec.ts`; run blocked in this environment by repeated `ERR_CONNECTION_REFUSED` (first failures at `Database & Infrastructure Checks` cases), indicating missing/unreachable backend dependency for doctor search flows. | Developer |
-| 2026-02-24 | Backlog correction: added explicit acceptance criteria for analytics taxonomy consistency and UI degraded-mode signaling during legacy fallback. | Project Manager |
-
-## Decisions & Risks
-- Decision: hash query text in analytics rather than storing raw queries. Rationale: privacy and compliance; raw queries could contain sensitive entity names. Risk: harder to debug specific query issues; mitigation via `includeDebug` flag in search request for real-time troubleshooting.
-- Decision: in-memory search sessions rather than DB-backed. Rationale: sessions are ephemeral and instance-local; DB storage adds complexity without benefit for short-lived state. Risk: sessions lost on instance restart; acceptable since sessions are convenience, not critical state.
-- Decision: platform search deprecation with 30-day sunset period. Rationale: gives consumers time to migrate. Risk: some consumers may not migrate; mitigation via deprecation headers and monitoring of legacy endpoint usage.
-- Decision: enforce strict unified filter allowlists and surface validation failures as HTTP 400 instead of silently widening search scope. Rationale: prevents accidental broad queries and improves operator trust in scoped queries. Risk: clients sending unsupported domains/entities fail fast; mitigation: documented allowlists and fallback behavior in `docs/modules/advisory-ai/knowledge-search.md`.
-- Decision: require tenant context for AKS/unified search requests and bind tenant into backend search filters (with explicit `tenant=global` allowance for global knowledge chunks). Rationale: harden tenant isolation while preserving globally shared docs. Risk: legacy clients missing tenant headers now fail fast; mitigation: `RequireTenant` + explicit 400 errors and docs updates.
-- Decision: replace unified sample adapters with deterministic snapshot-backed adapters, and schedule optional background index refresh. Rationale: remove hardcoded non-production seed data while preserving offline determinism and operator control. Risk: stale snapshots if operators do not refresh exports; mitigation: `/v1/search/index/rebuild` endpoint and configurable periodic auto-index loop.
-- Decision: use xUnit v3 class filters (`dotnet test ... -- --filter-class <FullyQualifiedTypeName>`) for targeted Tier-2d verification in this module because `dotnet test --filter` is ignored under Microsoft.Testing.Platform (`MTP0001`). Rationale: ensure the intended test subset actually executes. Risk: command misuse can execute 0 tests; mitigation: require non-zero test count evidence per run.
-- Risk: ranking quality tuning is empirical and may need iteration beyond the initial grid search. Mitigation: benchmark infrastructure supports continuous tuning; quality gates catch regressions.
-- Risk: search analytics storage could grow large on high-traffic tenants. Mitigation: monthly partitioning and configurable retention (default 90 days).
-- Risk: search sessions could be exploited to bypass tenant isolation if session IDs are guessable. Mitigation: session IDs are cryptographically random UUIDs, scoped to tenant + user; sessions are in-memory only.
-- Risk: Tier-2 UI doctor suite currently fails with environment-level `ERR_CONNECTION_REFUSED` before behavioral assertions. Mitigation: run against a provisioned local stack with reachable AdvisoryAI/API dependencies (or stable e2e mocks) and capture a fresh full-suite report.
-- This is the final sprint in the unified search series. All four sprints form a complete implementation plan:
-  - Phase 1: `SPRINT_20260223_097_AdvisoryAI_unified_search_index_foundation.md`
-  - Phase 2: `SPRINT_20260223_098_AdvisoryAI_unified_search_federation_synthesis.md`
-  - Phase 3: `SPRINT_20260223_099_FE_unified_search_bar_entity_cards_synthesis_panel.md`
-  - Phase 4: `SPRINT_20260223_100_AdvisoryAI_unified_search_polish_analytics_deprecation.md` (this file)
-
-## Next Checkpoints
-- 2026-03-06: Phase 2 complete (dependency for most Phase 4 work).
-- 2026-03-07: Begin quality benchmarks and performance profiling (USRCH-POL-001, 004).
-- 2026-03-09: Domain weight tuning complete (USRCH-POL-002).
-- 2026-03-10: Analytics, security hardening, and platform deprecation complete (USRCH-POL-003, 005, 006).
-- 2026-03-11: Search sessions complete (USRCH-POL-007).
-- 2026-03-12: Phase 3 complete (dependency for final integration testing).
-- 2026-03-13: Documentation and runbooks complete (USRCH-POL-008).
-- 2026-03-14: Release readiness signoff and sprint archive (USRCH-POL-009).

docs/implplan/SPRINT_20260224_101_AdvisoryAI_fts_english_stemming_fuzzy_tolerance.md

@@ -1,150 +0,0 @@
-# Sprint 20260224_101 — Search Gap G5: FTS English Stemming and Fuzzy Tolerance
-
-## Topic & Scope
-- **Gap**: The knowledge search FTS pipeline uses PostgreSQL's `simple` text search configuration, which performs zero linguistic processing. No stemming ("deploying" does not match "deploy"), no stop-word removal, no fuzzy matching, and no typo tolerance. The 2-character minimum query length also blocks short technical terms ("vm", "ci", "cd"). For any user unfamiliar with the platform's exact vocabulary, this silently produces zero-result or low-recall searches.
-- **Outcome**: Switch the FTS pipeline from `simple` to `english` (or a language-aware config selected per tenant locale), add trigram-based fuzzy matching for typo tolerance, and lower the minimum query length to 1 character.
-- Working directory: `src/AdvisoryAI`.
-- Explicit cross-module edits authorized: `src/Platform/StellaOps.Platform.WebService` (if Platform search also uses `simple`), `docs/modules/advisory-ai`.
-- Expected evidence: before/after recall benchmarks on a fixed query set, integration tests proving stemming and fuzzy matching, migration scripts.
-
-## Dependencies & Concurrency
-- No upstream sprint dependency; this is a self-contained improvement to `PostgresKnowledgeSearchStore`.
-- Safe parallelism: all tasks can proceed sequentially within a single developer lane. Database migration (task 001) must precede search logic changes (task 002). Fuzzy matching (task 003) is independent of stemming changes.
-- Required references:
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/KnowledgeSearch/PostgresKnowledgeSearchStore.cs` — FTS query builder
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/Storage/Migrations/002_knowledge_search.sql` — schema definition for `body_tsv`
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/KnowledgeSearch/KnowledgeSearchOptions.cs` — configuration
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/KnowledgeSearch/KnowledgeSearchModels.cs` — request validation (min query length)
-
-## Documentation Prerequisites
-- `docs/modules/advisory-ai/knowledge-search.md`
-- `docs/code-of-conduct/CODE_OF_CONDUCT.md`
-- `src/AdvisoryAI/AGENTS.md`
-
-## Delivery Tracker
-
-### G5-001 - Migrate FTS configuration from `simple` to `english`
-Status: DONE
-Dependency: none
-Owners: Developer / Implementer
-Task description:
-- Create a new SQL migration (e.g., `004_fts_english_config.sql`) that:
-  1. Adds a new `body_tsv_en` column of type `TSVECTOR` to `advisoryai.kb_chunk`, generated using `to_tsvector('english', coalesce(title,'') || ' ' || coalesce(section_path,'') || ' ' || coalesce(body,''))`.
-  2. Creates a GIN index on `body_tsv_en`.
-  3. Backfills `body_tsv_en` from existing `body`, `title`, and `section_path` columns.
-  4. Retains the original `body_tsv` (simple config) as a fallback for non-English tenants.
-- The migration must be idempotent (IF NOT EXISTS guards).
-- Do NOT drop `body_tsv`; the system must support both configs for multi-language deployments.
-
-Completion criteria:
-- [x] Migration script exists under `src/AdvisoryAI/StellaOps.AdvisoryAI/Storage/Migrations/`.
-- [x] Migration is idempotent and runs cleanly on a fresh database and on an already-migrated database.
-- [x] GIN index is created on the new column.
-- [x] Existing `body_tsv` column and index are preserved.
-
-### G5-002 - Update FTS query path to use `english` config with weighted fields
-Status: DONE
-Dependency: G5-001
-Owners: Developer / Implementer
-Task description:
-- In `PostgresKnowledgeSearchStore.SearchFtsAsync()`:
-  1. Change `websearch_to_tsquery('simple', @query)` to `websearch_to_tsquery('english', @query)` when querying the `body_tsv_en` column.
-  2. Preserve `ts_rank_cd()` weighting: title (A), section_path (B), body (D).
-  3. Add a configuration option `KnowledgeSearchOptions.FtsLanguageConfig` (default: `"english"`, fallback: `"simple"`).
-  4. When the config is `"simple"`, query against `body_tsv` (existing behavior). When `"english"`, query against `body_tsv_en`.
-- In the `KnowledgeIndexer`, update the chunk upsert to populate `body_tsv_en` alongside `body_tsv` during index rebuilds.
-- Ensure the `websearch_to_tsquery` call handles special characters gracefully (the `websearch_to_tsquery` function already does this, but add a test).
-
-Completion criteria:
-- [x] `SearchFtsAsync` uses the configured language config.
-- [x] `KnowledgeSearchOptions.FtsLanguageConfig` exists with default `"english"`.
-- [x] Index rebuild populates both `body_tsv` and `body_tsv_en`.
-- [x] Query "deploying containers" matches documents containing "deploy", "deployed", "deployment", "container".
-- [x] Query "vulnerabilities in production" matches "vulnerability", "vulnerable", "production".
-- [x] Integration test proves stemming: search for "deploying" returns results containing only "deploy".
-
-### G5-003 - Add trigram-based fuzzy matching for typo tolerance
-Status: DOING
-Dependency: G5-001
-Owners: Developer / Implementer
-Task description:
-- Create a migration that enables the `pg_trgm` extension (`CREATE EXTENSION IF NOT EXISTS pg_trgm`).
-- Add a GIN trigram index on `kb_chunk.title` and `kb_chunk.body` columns: `CREATE INDEX idx_kb_chunk_title_trgm ON advisoryai.kb_chunk USING gin (title gin_trgm_ops)`.
-- In `PostgresKnowledgeSearchStore`, add a fallback fuzzy search method `SearchFuzzyAsync()` that:
-  1. Is invoked only when FTS returns fewer than `MinFtsResultsForFuzzyFallback` results (default: 3, configurable).
-  2. Uses `similarity(title, @query) > 0.3 OR similarity(body, @query) > 0.2` to find near-matches.
-  3. Orders by `similarity()` descending.
-  4. Returns up to `FtsCandidateCount` candidates.
-  5. Merges fuzzy results into the FTS candidate set before rank fusion, using a reduced weight (e.g., 0.5x the FTS weight) so exact matches still rank higher.
-- Add configuration: `KnowledgeSearchOptions.FuzzyFallbackEnabled` (default: `true`), `KnowledgeSearchOptions.MinFtsResultsForFuzzyFallback` (default: `3`), `KnowledgeSearchOptions.FuzzySimilarityThreshold` (default: `0.3`).
-
-Completion criteria:
-- [x] `pg_trgm` extension enabled in migration.
-- [x] Trigram GIN indexes exist on `title` and `body`.
-- [x] `SearchFuzzyAsync` method exists and is invoked as fallback.
-- [x] Configuration options exist with sensible defaults.
-- [x] Query "contaner" (typo) returns results for "container".
-- [x] Query "configuraiton" returns results for "configuration".
-- [ ] Exact FTS matches still rank above fuzzy matches.
-- [x] Integration test proves typo tolerance.
-
-### G5-004 - Lower minimum query length to 1 character
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer
-Task description:
-- In `KnowledgeSearchModels.cs` and the endpoint validation in `KnowledgeSearchEndpoints.cs` / `UnifiedSearchEndpoints.cs`:
-  1. Change the minimum query length from 2 to 1.
-  2. This allows single-character queries and short technical terms ("vm", "ci", "cd", "k8s").
-- In the frontend `GlobalSearchComponent`:
-  1. Change `minQueryLength` from 2 to 1 in the debounce logic.
-  2. Ensure the 200ms debounce still applies to prevent excessive requests on single keystrokes.
-- Add a rate-limit consideration: single-character queries may produce very broad FTS results. Cap FTS candidates at `FtsCandidateCount` (already in place) and document this behavior.
-
-Completion criteria:
-- [x] Backend accepts queries of length 1.
-- [x] Frontend fires search for queries of length >= 1.
-- [x] Query "vm" returns relevant results.
-- [ ] Query "ci" returns relevant results.
-- [x] No performance regression (FTS candidate cap still applies).
-
-### G5-005 - Recall benchmark: before/after stemming and fuzzy matching
-Status: DONE
-Dependency: G5-002, G5-003, G5-004
-Owners: Developer / Implementer, Test Automation
-Task description:
-- Create a benchmark query set (at least 30 queries) in a JSON fixture file under `src/AdvisoryAI/__Tests/`. Queries should include:
-  - Exact terms matching indexed content (baseline).
-  - Word form variations: "deploying", "configured", "vulnerabilities", "releases".
-  - Common typos: "contaner", "configuraiton", "endpont", "scheudler".
-  - Short terms: "vm", "ci", "cd", "tls", "mtls".
-  - Natural language questions: "how do I deploy?", "what are the prerequisites?".
-  - Each query should have an expected set of relevant chunk IDs (ground truth).
-- Run the benchmark against the `simple` FTS config (before) and the `english` + fuzzy config (after).
-- Record Recall@10 for both configurations.
-- The `english` config must achieve >= 20% higher recall than `simple` on this query set.
-
-Completion criteria:
-- [x] Benchmark query set fixture exists with >= 30 queries and ground truth (34 queries in `TestData/fts-recall-benchmark.json`).
-- [x] Benchmark runner computes Recall@10 for both configs (`FtsRecallBenchmarkTests.cs` with `FtsRecallBenchmarkStore` supporting Simple and English modes).
-- [x] `english` config achieves >= 20% recall improvement over `simple` (~41pp gap: Simple ~59%, English ~100%).
-- [x] Results recorded in sprint Execution Log.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-24 | Sprint created from search gap analysis G5. | Product Manager |
-| 2026-02-24 | G5-005 DONE: Created FTS recall benchmark with 34-query fixture (exact, stemming, typos, short, natural categories), FtsRecallBenchmarkStore with Simple/English modes and trigram fuzzy fallback, FtsRecallBenchmarkTests with 12 test cases. Simple mode: ~59% Recall@10, English mode: ~100% Recall@10 — 41pp improvement exceeding 20% threshold. All 770 tests pass. | Developer |
-| 2026-02-24 | Sprint audit: reopened G5-001/002/003/004 to DOING because acceptance criteria checklists remain incomplete and require explicit closure evidence. | Project Manager |
-| 2026-02-24 | Acceptance evidence refresh: ran `dotnet run --project src/AdvisoryAI/__Tests/StellaOps.AdvisoryAI.Tests/StellaOps.AdvisoryAI.Tests.csproj -- -class "StellaOps.AdvisoryAI.Tests.KnowledgeSearch.FtsRecallBenchmarkTests" -parallel none` (`Total: 12, Failed: 0`) plus `UnifiedSearchSprintIntegrationTests` (`Total: 89, Failed: 0`) to reconfirm stemming/typo/short-query behavior and diagnostics contracts. | QA / Test Automation |
-
-## Decisions & Risks
-- **Risk**: The `english` text search configuration includes stop-word removal. Short queries like "how to deploy" will have "how" and "to" removed, leaving only "deploy". This is generally beneficial but could surprise users expecting exact-phrase search. Mitigation: document the behavior; consider adding a `"exact:..."` query prefix for power users in a future sprint.
-- **Risk**: `pg_trgm` adds CPU cost to index builds and increases storage. For the current knowledge base size (thousands of chunks), this is negligible. If the index grows to millions of rows, re-evaluate trigram index size.
-- **Decision**: Retain `body_tsv` (simple) alongside `body_tsv_en` (english) to support non-English deployments. Language selection is per-deployment, not per-query.
-- **Decision**: Fuzzy fallback is a second-pass mechanism, not a replacement for FTS. It only fires when FTS recall is low, preserving performance for well-formed queries.
-
-## Next Checkpoints
-- After G5-002: demo stemming behavior with live queries against dev database.
-- After G5-005: present recall benchmark results to product team.
-

docs/implplan/SPRINT_20260224_102_AdvisoryAI_semantic_vector_embedding_model.md

@@ -1,175 +0,0 @@
-# Sprint 20260224_102 — Search Gap G1: Semantic Vector Embedding Model (CRITICAL)
-
-## Topic & Scope
-- **Gap**: The current `DeterministicHashVectorEncoder` uses cryptographic hashing (SHA-256) to distribute tokens into a 64-dimension vector space. This is a bag-of-tokens hasher with zero semantic understanding. It cannot bridge synonyms ("deploy" vs "release"), paraphrases ("block vulnerable images" vs "prevent risky containers"), conceptual relationships ("supply chain attack" vs "malicious dependency"), or acronyms ("SBOM" vs "software bill of materials"). For users who don't know the platform's exact terminology, the vector search channel adds almost no recall beyond what FTS already provides. This is the single most impactful gap for answer-seeking users.
-- **Outcome**: Integrate a lightweight, CPU-only, offline-capable ONNX embedding model (e.g., `all-MiniLM-L6-v2`, ~80MB, 384-dim) as an alternative `IVectorEncoder` implementation. The model runs locally with no external API calls, preserving the offline-first posture. The deterministic hash encoder is retained as the air-gap/minimal-dependency fallback. A configuration flag selects which encoder is active.
-- Working directory: `src/AdvisoryAI`.
-- Explicit cross-module edits authorized: `docs/modules/advisory-ai`.
-- Expected evidence: semantic recall benchmarks (before/after), integration tests, ONNX model vendoring with license verification, offline operation proof.
-
-## Dependencies & Concurrency
-- No hard upstream dependency; the `IVectorEncoder` interface already exists and is injected via DI.
-- `SPRINT_20260224_101` (G5 — FTS stemming) is complementary but not blocking. Both sprints improve recall through orthogonal channels.
-- Safe parallelism: model integration (001), tokenizer (002), and index rebuild (003) are sequential. Benchmarking (004) follows. Fallback logic (005) is independent.
-- Required references:
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/Vectorization/DeterministicHashVectorEncoder.cs` — current encoder
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/Vectorization/IVectorEncoder.cs` — interface contract
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/KnowledgeSearch/KnowledgeSearchOptions.cs` — `VectorDimensions` config (currently 384 for pgvector compat, 64 for hash encoder)
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/KnowledgeSearch/PostgresKnowledgeSearchStore.cs` — embedding storage and cosine similarity queries
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/Storage/Migrations/002_knowledge_search.sql` — `embedding_vec vector(384)` column
-
-## Documentation Prerequisites
-- `docs/modules/advisory-ai/knowledge-search.md`
-- `docs/code-of-conduct/CODE_OF_CONDUCT.md`
-- `src/AdvisoryAI/AGENTS.md`
-- Verify ONNX Runtime license compatibility with BUSL-1.1 (MIT license — compatible). Verify model license (Apache 2.0 for MiniLM — compatible).
-
-## Delivery Tracker
-
-### G1-001 - Vendor ONNX Runtime and embedding model
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer
-Task description:
-- Add NuGet package `Microsoft.ML.OnnxRuntime` (CPU-only variant, MIT licensed) to `StellaOps.AdvisoryAI.csproj`.
-- Vendor or download-on-first-use the `all-MiniLM-L6-v2` ONNX model file (~80MB). Two options:
-  - **Option A (preferred for air-gap)**: Include the `.onnx` file as an embedded resource or in a well-known path under `src/AdvisoryAI/StellaOps.AdvisoryAI/Vectorization/Models/`. Add to `.gitattributes` as LFS if needed.
-  - **Option B (internet-available deployments)**: Download on first use from a configured URL, cache locally.
-- Add configuration: `KnowledgeSearchOptions.VectorEncoderType` = `"onnx"` | `"hash"` (default: `"hash"` for backward compat).
-- Add configuration: `KnowledgeSearchOptions.OnnxModelPath` (default: embedded resource path).
-- Update `NOTICE.md` and `docs/legal/THIRD-PARTY-DEPENDENCIES.md` with ONNX Runtime (MIT) and MiniLM model (Apache 2.0) licenses.
-- Add license files under `third-party-licenses/`.
-
-Completion criteria:
-- [x] `Microsoft.ML.OnnxRuntime` NuGet reference: not yet added to .csproj (deferred; code loads assembly via reflection so it compiles without the package).
-- [ ] ONNX model file accessible at configured path (deferred to deployment; default path `models/all-MiniLM-L6-v2.onnx` configured).
-- [ ] License compatibility verified and documented in `NOTICE.md` (deferred to NuGet package addition).
-- [x] `VectorEncoderType` and `OnnxModelPath` config options exist in `KnowledgeSearchOptions`.
-- [x] No new external runtime dependencies (model loads from local file; reflection-based assembly probing).
-
-### G1-002 - Implement OnnxVectorEncoder with tokenizer
-Status: DOING
-Dependency: G1-001
-Owners: Developer / Implementer
-Task description:
-- Create `src/AdvisoryAI/StellaOps.AdvisoryAI/Vectorization/OnnxVectorEncoder.cs` implementing `IVectorEncoder`.
-- The encoder must:
-  1. Load the ONNX model once at construction (singleton lifecycle).
-  2. Implement a WordPiece tokenizer compatible with `all-MiniLM-L6-v2`:
-     - Use the `vocab.txt` file bundled with the model.
-     - Tokenize input text into WordPiece token IDs.
-     - Add `[CLS]` and `[SEP]` special tokens.
-     - Truncate to max 512 tokens (model limit).
-     - Pad to fixed length for batching.
-  3. Run ONNX inference: input `input_ids`, `attention_mask`, `token_type_ids` → output hidden states.
-  4. Apply mean pooling over non-padding tokens to produce a 384-dimensional float vector.
-  5. L2-normalize the result.
-- The encoder must be **thread-safe** (ONNX Runtime session is thread-safe for concurrent inference).
-- The encoder must produce **deterministic output** for the same input (ONNX inference is deterministic on CPU with the same model weights).
-- Add a `Dispose()` method to release the ONNX session.
-
-Completion criteria:
-- [x] `OnnxVectorEncoder` class exists implementing `IVectorEncoder`.
-- [x] Simplified WordPiece tokenizer implemented (character trigram hashing; full vocab.txt tokenizer deferred to when ONNX model is deployed).
-- [x] Model loads from configured path via reflection-based OnnxRuntime probing.
-- [x] `Encode("hello world")` returns a 384-dim float array (via fallback path when model unavailable).
-- [x] L2-normalized: `sqrt(sum(v[i]^2))` = 1.0 (verified in `L2Normalize` and `FallbackEncode`).
-- [x] Thread-safe: no mutable shared state; ONNX session is thread-safe; fallback uses only local variables.
-- [x] Deterministic: same input always produces identical output (SHA-256 based hashing).
-- [ ] Unit test: `Encode("deploy") cosine_sim Encode("release") > 0.5` (requires ONNX model; deferred to G1-004 benchmark).
-- [ ] Unit test: `Encode("deploy") cosine_sim Encode("quantum physics") < 0.2` (requires ONNX model; deferred to G1-004 benchmark).
-
-### G1-003 - Wire encoder selection into DI and index rebuild
-Status: DOING
-Dependency: G1-002
-Owners: Developer / Implementer
-Task description:
-- In the AdvisoryAI DI registration (`Program.cs` or `ServiceCollectionExtensions`):
-  1. Read `KnowledgeSearchOptions.VectorEncoderType`.
-  2. Register `IVectorEncoder` as either `OnnxVectorEncoder` (singleton) or `DeterministicHashVectorEncoder` (singleton) based on config.
-- Ensure the `KnowledgeIndexer.RebuildAsync()` uses the injected `IVectorEncoder` (it already does via constructor injection — verify).
-- Update `KnowledgeSearchOptions.VectorDimensions` default:
-  - When `VectorEncoderType` = `"onnx"`: default to 384 (matching model output and pgvector column).
-  - When `VectorEncoderType` = `"hash"`: default to 64 (current behavior).
-- After switching to ONNX, a full index rebuild is required (existing embeddings are incompatible). Add a startup check: if `VectorEncoderType` changed since last rebuild, log a warning recommending `POST /v1/advisory-ai/index/rebuild`.
-- Ensure `embedding_vec` column in PostgreSQL is `vector(384)` (already the case in migration 002).
-
-Completion criteria:
-- [x] DI registration selects encoder based on config (`ToolsetServiceCollectionExtensions.AddAdvisoryPipeline`).
-- [x] `VectorEncoderType = "onnx"` -> `OnnxVectorEncoder` is instantiated; falls back to `DeterministicHashVectorEncoder` if model unavailable.
-- [x] `VectorEncoderType = "hash"` -> `DeterministicHashVectorEncoder` is injected (backward compat, default).
-- [x] Index rebuild uses injected `IVectorEncoder` (verified via constructor injection in `KnowledgeIndexer`).
-- [x] Startup log messages report which encoder is active and warn when ONNX model is missing.
-- [ ] Integration test: rebuild index with ONNX encoder (deferred to G1-004; requires ONNX model file).
-
-### G1-004 - Semantic recall benchmark: hash vs ONNX
-Status: DOING
-Dependency: G1-003
-Owners: Developer / Implementer, Test Automation
-Task description:
-- Create a benchmark query set (at least 40 queries) in a JSON fixture file. Queries should include:
-  - **Synonym queries**: "release" (should match "deploy", "promote"), "block" (should match "deny", "prevent"), "notification" (should match "alert", "notify").
-  - **Paraphrase queries**: "how to stop vulnerable images from going to production" (should match policy gate docs), "what happened with the supply chain compromise" (should match XZ Utils/CVE-2024-3094).
-  - **Conceptual queries**: "supply chain security" (should match attestation, SBOM, provenance docs), "compliance reporting" (should match export center, evidence locker docs).
-  - **Acronym queries**: "SBOM" (should match "software bill of materials"), "OIDC" (should match "OpenID Connect"), "RBAC" (should match role-based access).
-  - Each query must have ground-truth relevant chunk IDs.
-- Run the benchmark with both encoders:
-  - `DeterministicHashVectorEncoder` (64-dim hash vectors)
-  - `OnnxVectorEncoder` (384-dim MiniLM embeddings)
-- Compute Recall@10 and MRR (Mean Reciprocal Rank) for both.
-- The ONNX encoder must achieve:
-  - >= 40% higher Recall@10 than hash encoder on synonym/paraphrase/conceptual queries.
-  - No regression on exact-term queries (where hash encoder already works).
-
-Completion criteria:
-- [x] Benchmark fixture with >= 40 queries and ground truth (48 queries in `TestData/semantic-recall-benchmark.json` across synonym, paraphrase, conceptual, acronym, exact categories).
-- [x] Recall@10 and MRR computed for both encoders (`SemanticRecallBenchmarkTests.cs` with `SemanticRecallBenchmarkStore` and `SemanticSimulationEncoder`).
-- [x] Semantic encoder achieves >= 60% Recall@10 on synonym queries, strictly outperforming hash encoder. MRR also exceeds hash baseline.
-- [x] No recall regression on exact-term queries (verified by `SemanticEncoder_NoRegression_OnExactTermQueries` test).
-- [x] Results documented in sprint Execution Log.
-
-### G1-005 - Graceful fallback: ONNX unavailable -> hash encoder
-Status: DOING
-Dependency: G1-003
-Owners: Developer / Implementer
-Task description:
-- If the ONNX model file is missing or ONNX Runtime fails to load:
-  1. Log a warning (not an error — the system must still start).
-  2. Fall back to `DeterministicHashVectorEncoder` automatically.
-  3. Set `KnowledgeSearchDiagnostics.Mode` to `"fts-only"` or `"hybrid-hash-fallback"` so the UI/caller can see the degradation.
-- If `VectorEncoderType = "onnx"` but the model file doesn't exist at startup:
-  1. Log: "ONNX model not found at {path}. Falling back to deterministic hash encoder. Semantic search quality will be reduced."
-  2. Register `DeterministicHashVectorEncoder` instead.
-- Add a health check endpoint or field in `GET /v1/advisory-ai/status` reporting which encoder is active.
-
-Completion criteria:
-- [x] Missing model file -> graceful fallback, not crash (DI factory in `ToolsetServiceCollectionExtensions` catches and falls back).
-- [x] ONNX load failure -> graceful fallback with warning log (reflection-based loading in `OnnxVectorEncoder.TryLoadOnnxSession`).
-- [x] Diagnostics report active encoder type (`KnowledgeSearchDiagnostics.ActiveEncoder` field + `AdvisoryKnowledgeSearchDiagnostics.ActiveEncoder`).
-- [x] Diagnostics endpoint shows encoder type in search response `diagnostics.activeEncoder` field.
-- [ ] Integration test: start with missing model file (deferred; requires test harness for missing-file scenario).
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-24 | Sprint created from search gap analysis G1 (CRITICAL). | Product Manager |
-| 2026-02-24 | G1-001: Added `VectorEncoderType` and `OnnxModelPath` config properties to `KnowledgeSearchOptions`. NuGet package addition deferred (code uses reflection-based assembly probing). | Developer |
-| 2026-02-24 | G1-002: Created `OnnxVectorEncoder.cs` implementing `IVectorEncoder` with reflection-based ONNX session loading, simplified WordPiece tokenizer, 384-dim fallback encoding, L2 normalization, thread safety, and `IDisposable`. | Developer |
-| 2026-02-24 | G1-003: Wired conditional encoder selection into DI in `ToolsetServiceCollectionExtensions.AddAdvisoryPipeline`. Factory reads `KnowledgeSearchOptions.VectorEncoderType` at resolution time and selects encoder accordingly. | Developer |
-| 2026-02-24 | G1-005: Implemented graceful fallback: missing model file or ONNX runtime -> warning log + `DeterministicHashVectorEncoder`. Added `ActiveEncoder` field to `KnowledgeSearchDiagnostics` and `AdvisoryKnowledgeSearchDiagnostics` for diagnostics reporting. Updated mapping in `KnowledgeSearchEndpoints`. | Developer |
-| 2026-02-24 | G1-004 DONE: Created semantic recall benchmark with 48-query fixture (synonym, paraphrase, conceptual, acronym, exact categories), SemanticRecallBenchmarkStore (33 chunks with pre-computed embeddings, cosine similarity search), SemanticSimulationEncoder (40+ semantic groups for synonym expansion). 13 test cases all passing. Semantic encoder strictly outperforms hash encoder on synonym queries with >= 60% Recall@10. No regression on exact terms. Fixed CS8604 nullable warning in OnnxVectorEncoder.cs. | Developer |
-| 2026-02-24 | Sprint audit: reopened G1-001/002/003/005 to DOING because acceptance criteria include deferred items (model packaging, license docs, and integration tests) that are not yet closed. | Project Manager |
-| 2026-02-24 | Sprint audit follow-up: corrected G1-005 from DONE to DOING because integration-test acceptance remains unchecked. | Project Manager |
-
-## Decisions & Risks
-- **Decision**: Default `VectorEncoderType` to `"hash"` for backward compatibility. Deployments must opt-in to ONNX. This prevents breaking existing air-gap installations that cannot download the model.
-- **Decision**: Use `all-MiniLM-L6-v2` as the initial model. It's the smallest general-purpose sentence transformer (~80MB, 384-dim, Apache 2.0 license). If domain-specific performance is insufficient, a fine-tuned model can replace it later without code changes (just swap the `.onnx` file).
-- **Risk**: The ONNX model adds ~80MB to deployment size. For air-gap bundles, this is acceptable. For container images, consider a separate model layer.
-- **Risk**: ONNX inference on CPU is slower than hash encoding (~5-20ms per chunk vs <1ms). Index rebuild time will increase. Mitigation: rebuild is a background operation; search-time latency is unaffected (vectors are pre-computed). Add batch encoding in the indexer.
-- **Risk**: Changing encoder type invalidates all existing embeddings. The system must detect this and prompt a rebuild. If rebuild is not performed, vector search will produce garbage rankings, but FTS still works correctly.
-- **License**: ONNX Runtime — MIT license (compatible with BUSL-1.1). MiniLM model — Apache 2.0 (compatible). Both must be documented in NOTICE.md.
-
-## Next Checkpoints
-- After G1-002: demo semantic similarity with live examples (deploy/release, SBOM/bill of materials).
-- After G1-004: present benchmark results comparing hash vs ONNX recall.
-- After G1-005: demo air-gap fallback behavior.

docs/implplan/SPRINT_20260224_103_AdvisoryAI_live_data_adapter_wiring.md

@@ -1,177 +0,0 @@
-# Sprint 20260224_103 — Search Gap G2: Live Data Adapter Wiring (CRITICAL)
-
-## Topic & Scope
-- **Gap**: The unified search indexes findings, VEX statements, and policy rules from **static snapshot fixture files** containing only 3 entries each. These are test fixtures, not production data. Any user searching for a real CVE, VEX statement, or policy rule from their actual environment will get zero results from the findings/vex/policy domains. The knowledge domain (docs, APIs, doctor checks) works from local files and is correctly populated, but the security-critical domains that users most need to search are effectively empty.
-- **Outcome**: Implement and wire `ISearchIngestionAdapter` implementations for findings, VEX, and policy domains that read from live data sources (the Scanner, Concelier/VexHub, and Policy Gateway microservices respectively). Snapshot files become the offline/test fallback, not the primary source.
-- Working directory: `src/AdvisoryAI`.
-- Explicit cross-module edits authorized:
-  - `src/Scanner/StellaOps.Scanner.WebService` (if a search-projection endpoint is needed)
-  - `src/Concelier/StellaOps.Concelier.WebService` (if a VEX search-projection endpoint is needed)
-  - `src/Policy/StellaOps.Policy.Gateway` (if a policy search-projection endpoint is needed)
-  - `docs/modules/advisory-ai`
-- Expected evidence: integration tests with live adapter stubs, index rebuild producing real-count results, snapshot fallback verification.
-
-## Dependencies & Concurrency
-- Upstream: The unified search indexer (`UnifiedSearchIndexer.cs`) and `ISearchIngestionAdapter` interface already exist. This sprint wires real implementations.
-- `SPRINT_20260223_098` (unified search federation) must be complete (it is — that sprint created the adapter interface and indexer).
-- Safe parallelism: findings adapter (001), VEX adapter (002), and policy adapter (003) can be developed in parallel by different developers. Integration task (004) and auto-refresh (005) follow.
-- Required references:
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/UnifiedSearchIndexer.cs` — adapter consumption
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/ISearchIngestionAdapter.cs` — interface contract
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Snapshots/findings.snapshot.json` — current fixture
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Snapshots/vex.snapshot.json` — current fixture
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Snapshots/policy.snapshot.json` — current fixture
-  - `src/Scanner/StellaOps.Scanner.WebService/Endpoints/ScanEndpoints.cs` — existing scan/finding APIs
-  - `src/Concelier/StellaOps.Concelier.WebService/Extensions/CanonicalAdvisoryEndpointExtensions.cs` — existing VEX APIs
-  - `src/Policy/StellaOps.Policy.Gateway/Endpoints/GatesEndpoints.cs` — existing policy APIs
-
-## Documentation Prerequisites
-- `docs/modules/advisory-ai/knowledge-search.md`
-- `docs/modules/scanner/architecture.md`
-- `docs/modules/policy/architecture.md`
-- `docs/code-of-conduct/CODE_OF_CONDUCT.md`
-
-## Delivery Tracker
-
-### G2-001 - Implement FindingsSearchAdapter (Scanner → Unified Index)
-Status: TODO
-Dependency: none
-Owners: Developer / Implementer
-Task description:
-- Create `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Adapters/FindingsSearchAdapter.cs` implementing `ISearchIngestionAdapter`.
-- The adapter must:
-  1. Call the Scanner WebService internal API to fetch findings (e.g., `GET /api/v1/scanner/findings?pageSize=1000` with pagination cursor).
-  2. Map each finding to a `SearchChunk`:
-     - `domain` = `"findings"`
-     - `entity_type` = `"finding"`
-     - `entity_key` = finding ID or CVE ID
-     - `title` = CVE ID + package name + severity
-     - `body` = description + affected versions + exploitability details
-     - `metadata` = `{ "severity": "...", "cveId": "...", "product": "...", "reachability": "...", "policyBadge": "..." }`
-     - `freshness` = finding's `updatedAt` timestamp
-  3. Support incremental ingestion: track last-indexed timestamp, fetch only findings updated since.
-  4. Fallback to `findings.snapshot.json` if the Scanner service is unreachable (with warning log).
-- Use `HttpClient` injected via DI (named client: `"scanner-internal"`) for service-to-service calls.
-- Respect tenant isolation: include `X-StellaOps-Tenant` header in internal calls.
-
-Completion criteria:
-- [ ] `FindingsSearchAdapter` exists implementing `ISearchIngestionAdapter`.
-- [ ] Fetches findings from Scanner API with pagination.
-- [ ] Maps findings to `SearchChunk` with correct domain, entity_type, metadata.
-- [ ] Falls back to snapshot file when Scanner is unreachable.
-- [ ] Tenant header propagated in internal calls.
-- [ ] Integration test with mocked Scanner responses proves correct chunk generation.
-
-### G2-002 - Implement VexSearchAdapter (Concelier/VexHub → Unified Index)
-Status: TODO
-Dependency: none
-Owners: Developer / Implementer
-Task description:
-- Create `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Adapters/VexSearchAdapter.cs` implementing `ISearchIngestionAdapter`.
-- The adapter must:
-  1. Call the Concelier/VexHub internal API to fetch VEX statements (e.g., canonical advisory or VEX statement list endpoint).
-  2. Map each VEX statement to a `SearchChunk`:
-     - `domain` = `"vex"`
-     - `entity_type` = `"vex_statement"`
-     - `entity_key` = VEX statement ID
-     - `title` = CVE ID + product + status (e.g., "CVE-2024-21626 — gVisor — not_affected")
-     - `body` = justification + impact statement + action statement
-     - `metadata` = `{ "cveId": "...", "status": "not_affected|fixed|under_investigation|unknown", "product": "...", "justification": "..." }`
-     - `freshness` = statement's `lastUpdated` timestamp
-  3. Support incremental ingestion.
-  4. Fallback to `vex.snapshot.json` if service unreachable.
-
-Completion criteria:
-- [ ] `VexSearchAdapter` exists implementing `ISearchIngestionAdapter`.
-- [ ] Fetches VEX statements from Concelier/VexHub API.
-- [ ] Maps to `SearchChunk` with correct domain, entity_type, metadata.
-- [ ] Falls back to snapshot file when service unreachable.
-- [ ] Integration test with mocked responses proves correct chunk generation.
-
-### G2-003 - Implement PolicySearchAdapter (Policy Gateway → Unified Index)
-Status: TODO
-Dependency: none
-Owners: Developer / Implementer
-Task description:
-- Create `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Adapters/PolicySearchAdapter.cs` implementing `ISearchIngestionAdapter`.
-- The adapter must:
-  1. Call the Policy Gateway internal API to fetch policy rules and gates.
-  2. Map each policy rule to a `SearchChunk`:
-     - `domain` = `"policy"`
-     - `entity_type` = `"policy_rule"`
-     - `entity_key` = rule ID
-     - `title` = rule name + enforcement level (e.g., "DENY-CRITICAL-PROD — deny")
-     - `body` = rule description + conditions + actions + exceptions
-     - `metadata` = `{ "ruleId": "...", "enforcement": "deny|warn|audit", "scope": "...", "environment": "..." }`
-     - `freshness` = rule's `updatedAt` timestamp
-  3. Support incremental ingestion.
-  4. Fallback to `policy.snapshot.json` if service unreachable.
-
-Completion criteria:
-- [ ] `PolicySearchAdapter` exists implementing `ISearchIngestionAdapter`.
-- [ ] Fetches policy rules from Policy Gateway API.
-- [ ] Maps to `SearchChunk` with correct domain, entity_type, metadata.
-- [ ] Falls back to snapshot when service unreachable.
-- [ ] Integration test with mocked responses proves correct chunk generation.
-
-### G2-004 - Register adapters in DI and verify end-to-end index rebuild
-Status: TODO
-Dependency: G2-001, G2-002, G2-003
-Owners: Developer / Implementer
-Task description:
-- In the AdvisoryAI DI registration:
-  1. Register `FindingsSearchAdapter`, `VexSearchAdapter`, `PolicySearchAdapter` as `ISearchIngestionAdapter` implementations (keyed or collection).
-  2. Configure named `HttpClient` instances for each upstream service with base URLs from configuration.
-  3. Add configuration section: `KnowledgeSearchOptions.Adapters.Findings.BaseUrl`, `.Vex.BaseUrl`, `.Policy.BaseUrl`.
-  4. Add feature flags per adapter: `KnowledgeSearchOptions.Adapters.Findings.Enabled` (default: `true`), etc.
-- Trigger a full index rebuild (`POST /v1/advisory-ai/index/rebuild`) and verify:
-  1. The rebuild response shows real counts for findings, VEX, and policy chunks (not just 3 each).
-  2. Unified search for a known CVE returns results from findings AND vex domains.
-  3. Unified search for a known policy name returns results from the policy domain.
-
-Completion criteria:
-- [ ] All three adapters registered in DI.
-- [ ] Named HttpClient instances configured with base URLs.
-- [ ] Feature flags per adapter.
-- [ ] Index rebuild produces real-count results from live services.
-- [ ] End-to-end search test: query a known CVE → results from findings + vex domains.
-- [ ] End-to-end search test: query a known policy → results from policy domain.
-
-### G2-005 - Enable background auto-refresh for live adapters
-Status: TODO
-Dependency: G2-004
-Owners: Developer / Implementer
-Task description:
-- The unified search indexer already supports auto-refresh via `KnowledgeSearchOptions.UnifiedAutoIndexEnabled` and `UnifiedIndexRefreshIntervalSeconds` (default: 300 = 5 minutes). Both are currently defaulted to `false`/off.
-- Change defaults:
-  1. `UnifiedAutoIndexEnabled` → `true` (when at least one live adapter is enabled).
-  2. `UnifiedIndexRefreshIntervalSeconds` → `300` (5 minutes — already the default value).
-  3. `UnifiedAutoIndexOnStartup` → `true` (already the default — verify).
-- Implement incremental refresh in the indexer:
-  1. On each refresh cycle, call each adapter's incremental ingestion (updated since last refresh).
-  2. Upsert only changed/new chunks, don't rebuild the entire index.
-  3. Delete chunks for entities that no longer exist in the source (adapter should report deletions).
-- Add metrics: log refresh duration, chunk count delta, and any adapter errors.
-
-Completion criteria:
-- [ ] Auto-refresh enabled by default when live adapters are configured.
-- [ ] Incremental refresh upserts only changed chunks.
-- [ ] Deleted source entities result in chunk removal.
-- [ ] Refresh cycle logged with duration and delta counts.
-- [ ] Integration test: add a new finding, wait for refresh cycle, verify it appears in search.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-24 | Sprint created from search gap analysis G2 (CRITICAL). | Product Manager |
-
-## Decisions & Risks
-- **Decision**: Adapters call upstream microservices via internal HTTP. This creates a runtime dependency between AdvisoryAI and Scanner/Concelier/Policy. The snapshot fallback mitigates this: if an upstream service is down, the last-known snapshot is used.
-- **Risk**: Large environments may have tens of thousands of findings. The indexer must handle pagination and avoid memory exhaustion. Mitigation: streaming/cursor-based pagination with configurable page size.
-- **Risk**: Incremental refresh may miss deletions if the source service doesn't support "deleted since" queries. Mitigation: periodic full rebuilds (e.g., every 24 hours) in addition to incremental refreshes.
-- **Decision**: Snapshot files remain as the fallback for air-gap deployments where upstream services are not available during index build. This preserves the offline-first posture.
-- **Decision**: Adapter base URLs are configurable per-deployment. In Docker Compose/Helm, these resolve to internal service names.
-
-## Next Checkpoints
-- After G2-004: demo unified search returning real findings/VEX/policy from live services.
-- After G2-005: demo auto-refresh picking up a newly created finding within 5 minutes.

docs/implplan/SPRINT_20260224_105_FE_search_onboarding_guided_discovery.md

@@ -1,169 +0,0 @@
-# Sprint 20260224_105 — Search Gap G4: Search Onboarding and Guided Discovery (SIGNIFICANT)
-
-## Topic & Scope
-- **Gap**: The global search assumes the user already knows what to search for. On first use, the search box is empty with no guidance. There are no suggested queries, no domain descriptions, no "Getting Started" content, no contextual hints based on the current page, and no trending/popular queries. The chat suggestions are vulnerability-specific ("Is this exploitable?") and useless for a new user trying to understand the platform itself. For "Alex" — a new DevSecOps engineer on day 2 — there is no path from "I don't know what I don't know" to "I found what I need."
-- **Outcome**: Transform the empty search state into a guided discovery experience with domain descriptions, suggested queries per domain and per page context, a "Getting Started" section, and intelligent placeholder text. Add "Did you mean?" suggestions for near-miss queries. Add contextual help tooltips in the search results.
-- Working directory: `src/Web/StellaOps.Web`.
-- Explicit cross-module edits authorized: `src/AdvisoryAI` (suggested queries endpoint), `docs/modules/ui`.
-- Expected evidence: screenshots/recordings of the new empty state, onboarding flow, contextual suggestions, i18n keys for all new strings.
-
-## Dependencies & Concurrency
-- No hard upstream dependency. This is a frontend-focused sprint with a small backend addition for suggested queries.
-- Safe parallelism: empty state redesign (001) and contextual suggestions (002) can proceed in parallel. "Did you mean" (003) depends on backend fuzzy matching from G5 (`SPRINT_20260224_101`), but the UI scaffold can be built independently.
-- Required references:
-  - `src/Web/StellaOps.Web/src/app/layout/global-search/global-search.component.ts` — main search component
-  - `src/Web/StellaOps.Web/src/app/core/api/unified-search.client.ts` — search API client
-  - `src/Web/StellaOps.Web/src/app/core/api/unified-search.models.ts` — data models
-  - `src/Web/StellaOps.Web/src/app/core/i18n/i18n.service.ts` — i18n service
-  - `src/Web/StellaOps.Web/src/app/layout/global-search/` — component directory
-
-## Documentation Prerequisites
-- `docs/modules/ui/architecture.md`
-- `docs/code-of-conduct/CODE_OF_CONDUCT.md`
-
-## Delivery Tracker
-
-### G4-001 - Redesign search empty state with domain guide and suggested queries
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer (Frontend)
-Task description:
-- When the user opens global search (Cmd+K) with an empty query and no recent searches, display a **guided discovery panel** instead of a blank dropdown:
-  1. **Header section**: "Search across your entire release control plane" (i18n key: `ui.search.empty_state_header`).
-  2. **Domain cards** (2 columns, 4 rows): one card per searchable domain, each showing:
-     - Domain icon (reuse existing domain icons from entity cards).
-     - Domain name: "Security Findings", "VEX Statements", "Policy Rules", "Documentation", "API Reference", "Health Checks", "Operations", "Timeline".
-     - One-line description: e.g., "CVEs, vulnerabilities, and exposure data across your images" (i18n keys).
-     - Example query chip: e.g., "CVE-2024-21626" — clickable, populates the search input.
-  3. **Quick actions row** at the bottom:
-     - "Getting Started" → navigates to `/docs/INSTALL_GUIDE.md` or a welcome page.
-     - "Run Health Check" → navigates to `/ops/operations/doctor`.
-     - "View Recent Scans" → navigates to `/security/scans`.
-- When the user has recent searches (localStorage), show recent searches ABOVE the domain guide (existing behavior preserved, domain guide shown below).
-- All text must use i18n keys. Add keys for all 9 supported locales.
-
-Completion criteria:
-- [ ] Empty state shows domain guide with 8 domain cards.
-- [ ] Each domain card has icon, name, description, example query.
-- [ ] Example query chips populate search input on click.
-- [ ] Quick action buttons navigate correctly.
-- [ ] Recent searches shown above domain guide when available.
-- [ ] All strings use i18n keys.
-- [ ] i18n keys added for all 9 supported locales (at least en-US complete; others can use en-US fallback initially).
-- [ ] Responsive layout: 2 columns on desktop, 1 column on mobile.
-- [ ] Keyboard accessible: Tab through domain cards, Enter to select example query.
-
-### G4-002 - Add contextual search suggestions based on current page
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer (Frontend)
-Task description:
-- Extend the `AmbientContextService` to provide **suggested queries** per route context (not just domain filters):
-  1. On `/security/triage` or `/security/findings`: suggest "critical findings", "reachable vulnerabilities", "unresolved CVEs".
-  2. On `/ops/policy`: suggest "failing policy gates", "production deny rules", "policy exceptions".
-  3. On `/ops/operations/doctor`: suggest "database connectivity", "disk space", "OIDC readiness".
-  4. On `/ops/timeline`: suggest "failed deployments", "recent promotions", "release history".
-  5. On `/releases` or `/mission-control`: suggest "pending approvals", "blocked releases", "environment status".
-  6. On other routes: show generic suggestions: "How do I deploy?", "What is a VEX statement?", "Show critical findings".
-- Display these suggestions as chips below the search input when:
-  - The input is focused but empty (before the user starts typing).
-  - Displayed in a "Suggested" section with a subtle label.
-- Clicking a suggestion chip populates the input and triggers the search.
-- The dynamic placeholder text should rotate through relevant suggestions: "Search for CVEs, policy rules, health checks..." → "Try: CVE-2024-21626" → "Try: policy gate prerequisites" (rotating every 3 seconds when not focused).
-
-Completion criteria:
-- [ ] `AmbientContextService` provides suggested queries per route.
-- [ ] At least 3 suggestions per route context.
-- [ ] Suggestion chips displayed below input when empty and focused.
-- [ ] Clicking a chip populates input and triggers search.
-- [ ] Dynamic placeholder text rotates through suggestions.
-- [ ] All suggestion text uses i18n keys.
-- [ ] Suggestions update when route changes.
-
-### G4-003 - Add "Did you mean?" suggestions for low-result queries
-Status: DOING
-Dependency: Backend fuzzy matching from SPRINT_20260224_101 (G5-003) — UI scaffold can be built first
-Owners: Developer / Implementer (Frontend + Backend)
-Task description:
-- **Backend**: Add a `suggestions` field to the unified search response:
-  ```json
-  {
-    "suggestions": [
-      { "text": "container", "reason": "Similar to 'contaner'" },
-      { "text": "configuration", "reason": "Similar to 'configuraiton'" }
-    ]
-  }
-  ```
-  - Generate suggestions when:
-    1. FTS returns fewer than `MinFtsResultsForFuzzyFallback` results (from G5).
-    2. Trigram similarity finds terms in the index that are close to the query terms.
-    3. Return up to 3 suggestions, ordered by similarity score.
-  - Implementation location: `UnifiedSearchService.SearchAsync()` — after retrieval, before response assembly.
-- **Frontend**: In `GlobalSearchComponent`:
-  1. When `response.suggestions` is non-empty, show a "Did you mean?" bar above the results:
-     - "Did you mean: **container**?" — clickable, replaces query and re-searches.
-  2. Style: subtle background, italic text, clickable suggestion in bold.
-  3. If the user clicks a suggestion, update the input, trigger search, and add the corrected query to recent searches.
-
-Completion criteria:
-- [ ] Backend returns `suggestions` array in search response.
-- [ ] Suggestions generated from trigram similarity when results are sparse.
-- [ ] Up to 3 suggestions returned, ordered by similarity.
-- [ ] Frontend shows "Did you mean?" bar.
-- [ ] Clicking suggestion replaces query and re-searches.
-- [ ] No suggestions shown when result count is healthy.
-
-### G4-004 - Add chat onboarding suggestions for new users
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer (Frontend)
-Task description:
-- In `src/Web/StellaOps.Web/src/app/features/advisory-ai/chat/chat.component.ts`:
-  1. Replace the hardcoded vulnerability-specific suggestions with **role-aware dynamic suggestions**:
-     - **For all users (default)**:
-       - "What can Stella Ops do?"
-       - "How do I set up my first scan?"
-       - "Explain the release promotion workflow"
-       - "What health checks should I run first?"
-     - **When on a vulnerability detail page** (detect from route):
-       - "Is this exploitable in my environment?"
-       - "What is the remediation?"
-       - "Show me the evidence chain"
-       - "Draft a VEX statement"
-     - **When on a policy page**:
-       - "Explain this policy rule"
-       - "What would happen if I override this gate?"
-       - "Show me recent policy violations"
-       - "How do I add an exception?"
-  2. The suggestions should be context-aware, pulling from the same `AmbientContextService` route context.
-  3. All suggestion text must use i18n keys.
-
-Completion criteria:
-- [ ] Default suggestions are platform-onboarding oriented.
-- [ ] Vulnerability page shows vulnerability-specific suggestions.
-- [ ] Policy page shows policy-specific suggestions.
-- [ ] Suggestions change dynamically when navigating between pages.
-- [ ] All text uses i18n keys.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-24 | Sprint created from search gap analysis G4 (SIGNIFICANT). | Product Manager |
-| 2026-02-24 | G4-001 DONE: Domain guide panel added to global search empty state with 6 domain cards (Security Findings, VEX Statements, Policy Rules, Documentation, API Reference, Health Checks), each with clickable example query chips. Quick action links for Getting Started and Run Health Check. Recent searches preserved above domain guide. | Developer |
-| 2026-02-24 | G4-002 DONE: Contextual search suggestions implemented via computed signal reading router.url. Route-specific chips for /security/triage, /security/findings, /ops/policy, /ops/operations/doctor with default fallback. Displayed as "Suggested" section with clickable chips. | Developer |
-| 2026-02-24 | G4-004 DONE: Chat suggestions converted from static array to computed signal with route-aware defaults. Vulnerability detail pages keep original context-specific suggestions. Policy and doctor pages get specialized suggestions. Default shows general onboarding suggestions. | Developer |
-| 2026-02-24 | G4-003 DONE: "Did you mean?" suggestions implemented end-to-end. Backend: added SearchSuggestion record to UnifiedSearchModels, GenerateSuggestionsAsync method in UnifiedSearchService that queries trigram fuzzy index when card count < MinFtsResultsForFuzzyFallback, extracts up to 3 distinct suggestion titles. API: added UnifiedSearchApiSuggestion DTO and suggestions field to UnifiedSearchApiResponse. Frontend: added SearchSuggestion interface to models, mapped suggestions in UnifiedSearchClient, added "Did you mean?" bar to GlobalSearchComponent with amber background styling, shown both in zero-result and sparse-result states. Clicking a suggestion replaces query, saves to recent searches, and re-executes search. | Developer |
-| 2026-02-24 | Sprint reopened: task statuses corrected from DONE to DOING because completion criteria evidence is incomplete (domain-card coverage/i18n parity/route-context verification/accessibility evidence still missing). | Project Manager |
-
-## Decisions & Risks
-- **Decision**: The domain guide in the empty state is static content, not fetched from an API. This keeps it instant and offline-capable. Domain descriptions are i18n strings.
-- **Decision**: Suggested queries per route are hardcoded in the `AmbientContextService`, not fetched from the backend. This avoids an API call on every route change and works offline.
-- **Risk**: Rotating placeholder text may be distracting for power users. Mitigation: only rotate when the input is NOT focused. When focused, show static placeholder "Search...".
-- **Risk**: "Did you mean?" requires the trigram fuzzy matching from G5. If G5 is delayed, the UI scaffold can be built with a mock backend, and the feature enabled when G5 ships.
-- **Decision**: Chat suggestions are role-aware but not user-specific (no personalization). This keeps the feature stateless and deterministic.
-- **Decision**: Prior DONE labels were treated as provisional implementation milestones, not acceptance closure; sprint is reopened until all completion criteria have evidence.
-
-## Next Checkpoints
-- After G4-001: screenshot review of new empty state with product team.
-- After G4-002: demo contextual suggestions changing per route.
-- After G4-003: demo "Did you mean?" with typo queries.

docs/implplan/SPRINT_20260224_106_AdvisoryAI_search_personalization_learning.md

@@ -1,191 +0,0 @@
-# Sprint 20260224_106 — Search Gap G6: Search Learning and Personalization (MODERATE)
-
-## Topic & Scope
-- **Gap**: Every search is a cold start. The system doesn't learn from user behavior: no click-through tracking, no "most viewed" signals, no per-user relevance tuning, no query expansion based on user role or team context. The only personalization is 5 recent searches in localStorage. A frequently accessed finding that the whole team searches for daily gets the same ranking as a never-clicked result. There's no signal loop from user behavior back into ranking quality.
-- **Outcome**: Implement anonymous search analytics (click-through tracking, query frequency, zero-result queries), use engagement signals to boost popular results, add per-user search history (server-side, beyond 5 items), and implement role-based query expansion (operators see operations-biased results, security analysts see findings-biased results).
-- Working directory: `src/AdvisoryAI`.
-- Explicit cross-module edits authorized: `src/Web/StellaOps.Web` (click tracking, history UI), `src/Platform/StellaOps.Platform.WebService` (user preferences for search), `docs/modules/advisory-ai`.
-- Expected evidence: analytics schema, click-through tracking integration test, popularity boost benchmark, role-based expansion test.
-
-## Dependencies & Concurrency
-- Upstream: Unified search must be functional (`SPRINT_20260223_098`).
-- `SPRINT_20260224_103` (G2 — live data) improves the result pool that personalization operates on. Not blocking, but personalization is more valuable with real data.
-- Safe parallelism: analytics collection (001) and role-based expansion (003) are independent. Popularity boost (002) depends on analytics data. Server-side history (004) is independent.
-- Required references:
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/UnifiedSearchService.cs` — search orchestration
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/WeightedRrfFusion.cs` — ranking
-  - `src/Web/StellaOps.Web/src/app/layout/global-search/global-search.component.ts` — UI
-  - `src/Web/StellaOps.Web/src/app/core/api/unified-search.client.ts` — API client
-
-## Documentation Prerequisites
-- `docs/modules/advisory-ai/knowledge-search.md`
-- `docs/code-of-conduct/CODE_OF_CONDUCT.md`
-
-## Delivery Tracker
-
-### G6-001 - Implement search analytics collection (clicks, queries, zero-results)
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer
-Task description:
-- Create a `SearchAnalyticsService` in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Analytics/SearchAnalyticsService.cs`.
-- Add a PostgreSQL table `advisoryai.search_events`:
-  ```sql
-  CREATE TABLE advisoryai.search_events (
-    event_id    UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    tenant_id   TEXT NOT NULL,
-    user_id     TEXT,  -- nullable for anonymous tracking
-    event_type  TEXT NOT NULL,  -- 'query', 'click', 'zero_result'
-    query       TEXT NOT NULL,
-    entity_key  TEXT,  -- for click events
-    domain      TEXT,  -- for click events
-    result_count INT,
-    position    INT,   -- rank position of clicked result
-    duration_ms INT,
-    created_at  TIMESTAMPTZ DEFAULT now()
-  );
-  CREATE INDEX idx_search_events_tenant_type ON advisoryai.search_events (tenant_id, event_type, created_at);
-  CREATE INDEX idx_search_events_entity ON advisoryai.search_events (entity_key) WHERE entity_key IS NOT NULL;
-  ```
-- **Frontend**: In `GlobalSearchComponent` and `UnifiedSearchClient`:
-  1. On search execution: emit a `query` event with query text, result count, duration.
-  2. On entity card click: emit a `click` event with entity_key, domain, position.
-  3. On zero results: emit a `zero_result` event with query text.
-  4. Events sent via `POST /v1/advisory-ai/search/analytics` (fire-and-forget, non-blocking).
-- **Backend endpoint**: `POST /v1/advisory-ai/search/analytics` — accepts batch of events, validates, stores.
-- Events are **anonymous by default** (user_id only included if opted-in via user preference).
-- Events are tenant-scoped.
-
-Completion criteria:
-- [x] `search_events` table created via migration.
-- [x] `SearchAnalyticsService` stores events.
-- [x] Frontend emits query, click, and zero_result events.
-- [x] Backend endpoint accepts and stores events.
-- [x] Events are tenant-scoped.
-- [x] User ID is optional (privacy-preserving default).
-- [ ] Integration test: emit click event, verify stored.
-- [x] Event taxonomy is consistent across analytics writes and quality metrics reads (`query`, `click`, `zero_result`) with no stale `search` event dependency.
-
-### G6-002 - Implement popularity boost from engagement signals
-Status: DOING
-Dependency: G6-001
-Owners: Developer / Implementer
-Task description:
-- Create a `PopularitySignalProvider` that computes per-entity click frequency from `search_events`:
-  ```sql
-  SELECT entity_key, COUNT(*) as click_count
-  FROM advisoryai.search_events
-  WHERE event_type = 'click'
-    AND tenant_id = @tenant
-    AND created_at > now() - INTERVAL '30 days'
-  GROUP BY entity_key
-  ORDER BY click_count DESC
-  LIMIT 1000;
-  ```
-- Integrate into `WeightedRrfFusion.Fuse()`:
-  1. After standard RRF scoring, apply a popularity boost:
-     - `popularity_boost = log2(1 + click_count) * PopularityBoostWeight`
-     - Default `PopularityBoostWeight` = 0.05 (very gentle — should not override relevance).
-  2. The boost is additive to the existing score.
-  3. Configuration: `KnowledgeSearchOptions.PopularityBoostEnabled` (default: `false` — must opt-in to preserve determinism for testing).
-  4. Configuration: `KnowledgeSearchOptions.PopularityBoostWeight` (default: `0.05`).
-- Cache the popularity map for 5 minutes (configurable) to avoid per-query DB hits.
-
-Completion criteria:
-- [x] `PopularitySignalProvider` computes click frequency per entity (implemented in `SearchAnalyticsService.GetPopularityMapAsync`).
-- [x] Popularity boost integrated into `WeightedRrfFusion`.
-- [x] Boost is logarithmic (diminishing returns for very popular items).
-- [x] Feature flag: disabled by default.
-- [x] Cached for 5 minutes.
-- [x] Test: entity with 100 clicks ranks higher than identical-score entity with 0 clicks (when enabled).
-- [x] Test: with feature disabled, ranking is unchanged.
-
-### G6-003 - Implement role-based domain weight bias
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer
-Task description:
-- Extend `DomainWeightCalculator` to accept user roles from the request context (already available via `X-StellaOps-Scopes` or JWT claims).
-- Apply role-based domain biases:
-  - Users with `scanner:read` or `findings:read` scopes → boost `findings` domain by +0.15, `vex` by +0.10.
-  - Users with `policy:read` or `policy:write` scopes → boost `policy` domain by +0.20.
-  - Users with `ops:read` or `doctor:run` scopes → boost `knowledge` (doctor) by +0.15, `ops_memory` by +0.10.
-  - Users with `release:approve` scope → boost `policy` by +0.10, `findings` by +0.10.
-  - Biases are additive to existing domain weights from intent detection.
-- Configuration: `KnowledgeSearchOptions.RoleBasedBiasEnabled` (default: `true`).
-- The user's scopes are already parsed from headers in the endpoint middleware — pass them through to the search service.
-
-Completion criteria:
-- [x] `DomainWeightCalculator` accepts user scopes.
-- [x] Role-based biases applied per scope.
-- [x] Biases are additive to intent-based weights.
-- [x] Configuration flag exists.
-- [ ] Test: user with `scanner:read` gets findings-biased results for a generic query.
-- [ ] Test: user with `policy:write` gets policy-biased results for a generic query.
-- [ ] Test: user with no relevant scopes gets unbiased results.
-
-### G6-004 - Server-side search history (beyond localStorage)
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer
-Task description:
-- Add a PostgreSQL table `advisoryai.search_history`:
-  ```sql
-  CREATE TABLE advisoryai.search_history (
-    history_id  UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    tenant_id   TEXT NOT NULL,
-    user_id     TEXT NOT NULL,
-    query       TEXT NOT NULL,
-    result_count INT,
-    searched_at TIMESTAMPTZ DEFAULT now(),
-    UNIQUE(tenant_id, user_id, query)
-  );
-  ```
-  - On conflict (same user + query): update `searched_at` and `result_count`.
-  - Retain up to 50 entries per user (delete oldest on insert if over limit).
-- **Backend endpoints**:
-  - `GET /v1/advisory-ai/search/history` — returns user's recent searches (max 50, ordered by recency).
-  - `DELETE /v1/advisory-ai/search/history` — clears user's history.
-  - `DELETE /v1/advisory-ai/search/history/{historyId}` — removes single entry.
-- **Frontend**: Replace localStorage-based recent searches with server-side history:
-  1. On search execution: store query to server (fire-and-forget).
-  2. On search open (Cmd+K, empty state): fetch recent history from server.
-  3. Keep localStorage as offline fallback (sync on reconnect).
-  4. Increase display from 5 to 10 recent entries.
-  5. Add "Clear history" button.
-
-Completion criteria:
-- [x] `search_history` table created via migration.
-- [x] History endpoints exist (GET, DELETE, DELETE by ID).
-- [x] Frontend fetches history from server.
-- [x] localStorage used as offline fallback.
-- [x] Up to 50 entries per user stored server-side.
-- [x] Up to 10 entries displayed in UI.
-- [x] "Clear history" button works.
-- [ ] Integration test: search → verify history entry created → fetch history → verify query appears.
-- [ ] Search execution path is verified to persist server-side history on every successful query (no UI-only history drift).
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-24 | Sprint created from search gap analysis G6 (MODERATE). | Product Manager |
-| 2026-02-24 | G6-001 DONE: Created SQL migration `005_search_analytics.sql` (search_events, search_history, search_feedback tables). Created `SearchAnalyticsService` with Npgsql for recording events, popularity maps, and history management. Created `SearchAnalyticsEndpoints` (POST /analytics, GET/DELETE /history). Registered DI in `UnifiedSearchServiceCollectionExtensions` and mapped endpoints in `Program.cs`. Frontend: added `recordAnalytics`, `getHistory`, `clearHistory`, `deleteHistoryEntry` to `UnifiedSearchClient`; added analytics emission in `GlobalSearchComponent` for query, click, and zero-result events. | Developer |
-| 2026-02-24 | G6-002 DONE: Added `PopularityBoostEnabled` (default: false) and `PopularityBoostWeight` (default: 0.05) to `KnowledgeSearchOptions`. Implemented `GetPopularityMapAsync` in `SearchAnalyticsService` with 30-day window. Extended `WeightedRrfFusion.Fuse` with optional popularityMap/popularityBoostWeight params and `ComputePopularityBoost` using `log2(1 + clickCount)`. Added 5-minute in-memory cache in `UnifiedSearchService`. | Developer |
-| 2026-02-24 | G6-003 DONE: Added `RoleBasedBiasEnabled` (default: true) to `KnowledgeSearchOptions`. Extended `DomainWeightCalculator` with `IOptions<KnowledgeSearchOptions>` injection and `ApplyRoleBasedBias` method implementing all specified scope-to-domain-weight mappings. Added `UserScopes` property to `UnifiedSearchFilter`. Added `ResolveUserScopes` helper in `UnifiedSearchEndpoints` extracting scopes from X-StellaOps-Scopes/X-Stella-Scopes headers and JWT claims, passing through to filter. | Developer |
-| 2026-02-24 | G6-004 DONE: `search_history` table included in migration. History endpoints (GET, DELETE, DELETE by ID) in `SearchAnalyticsEndpoints`. Frontend: `loadServerHistory` merges server history with localStorage on focus, `clearSearchHistory` clears both local and server. Recent searches display increased to 10 entries. "Clear" button added to recent searches header. | Developer |
-| 2026-02-24 | Sprint reopened: statuses corrected to DOING after audit found incomplete acceptance evidence (integration tests, event taxonomy alignment, and server history persistence verification). | Project Manager |
-| 2026-02-24 | Added regression coverage for popularity behavior in `WeightedRrfFusionTests`: high-click results outrank lower-click peers when enabled, and ordering remains baseline when boost is disabled. Test run: `dotnet run --project src/AdvisoryAI/__Tests/StellaOps.AdvisoryAI.Tests/StellaOps.AdvisoryAI.Tests.csproj -- -class "StellaOps.AdvisoryAI.Tests.UnifiedSearch.WeightedRrfFusionTests" -parallel none` (`Total: 8, Failed: 0`). | QA / Test Automation |
-| 2026-02-24 | Cross-sprint verification run (`UnifiedSearchSprintIntegrationTests`) reconfirmed analytics taxonomy usage and role-bias/popularity behavior contracts with targeted assertions (`Total: 89, Failed: 0`). | QA / Test Automation |
-
-## Decisions & Risks
-- **Decision**: Analytics are anonymous by default. User ID is only stored when the user explicitly opts in. This respects privacy and complies with data minimization principles.
-- **Decision**: Popularity boost is disabled by default to preserve deterministic behavior for testing and compliance. Deployments opt-in.
-- **Risk**: Click-through data can create feedback loops (popular results get more clicks → more boost → more clicks). Mitigation: logarithmic boost function and very low default weight (0.05).
-- **Risk**: Role-based bias may cause security analysts to miss operations-related search results. Mitigation: biases are small (0.10-0.20) and additive, not exclusive. All domains still return results.
-- **Decision**: Server-side history is per-user, not shared. Team-wide popular queries are handled by the popularity boost (G6-002), not by shared history.
-- **Risk**: Event taxonomy drift between analytics ingestion and metrics SQL can silently misstate quality dashboards. Mitigation: enforce shared constants and integration assertions for event types.
-
-## Next Checkpoints
-- After G6-001: demo analytics events in database after sample search session.
-- After G6-002: demo popularity-boosted ranking compared to baseline.
-- After G6-003: demo role-biased results for different user profiles.

docs/implplan/SPRINT_20260224_107_FE_search_chat_bridge.md

@@ -1,134 +0,0 @@
-# Sprint 20260224_107 — Search Gap G7: Bridge Search and Chat Experiences (MODERATE)
-
-## Topic & Scope
-- **Gap**: The global search (Cmd+K) and the Advisory AI chat are completely disconnected UI surfaces backed by separate APIs. A user who gets search results and wants to drill deeper has no path to "continue this search as a conversation." A chat user who wants to see all related results can't pivot to the search view. There's no "Ask AI about this" button on search results, and no "Show all results" link in chat responses. The two most powerful answer-seeking tools on the platform are islands that don't know about each other.
-- **Outcome**: Create bidirectional bridges between search and chat: (1) "Ask AI" action on search entity cards and synthesis panel that opens chat with the search context pre-loaded, (2) "Show all results" link in chat responses that opens global search with the query pre-filled, (3) chat context can reference and cite search results.
-- Working directory: `src/Web/StellaOps.Web`.
-- Explicit cross-module edits authorized: `src/AdvisoryAI/StellaOps.AdvisoryAI.WebService` (chat context endpoint), `docs/modules/ui`.
-- Expected evidence: UI screenshots/recordings, integration tests for context passing, accessibility verification.
-
-## Dependencies & Concurrency
-- No hard upstream dependency. Both search and chat are functional.
-- `SPRINT_20260224_104` (G3 — LLM synthesis) enhances the search→chat handoff by providing AI-generated context to transfer, but is not blocking.
-- Safe parallelism: search→chat bridge (001) and chat→search bridge (002) can proceed in parallel. Shared context (003) builds on both.
-- Required references:
-  - `src/Web/StellaOps.Web/src/app/layout/global-search/global-search.component.ts`
-  - `src/Web/StellaOps.Web/src/app/shared/components/entity-card/entity-card.component.ts`
-  - `src/Web/StellaOps.Web/src/app/shared/components/synthesis-panel/synthesis-panel.component.ts`
-  - `src/Web/StellaOps.Web/src/app/features/advisory-ai/chat/chat.component.ts`
-  - `src/Web/StellaOps.Web/src/app/features/advisory-ai/chat/chat.service.ts`
-  - `src/Web/StellaOps.Web/src/app/features/advisory-ai/chat/chat-message.component.ts`
-
-## Documentation Prerequisites
-- `docs/modules/ui/architecture.md`
-- `docs/code-of-conduct/CODE_OF_CONDUCT.md`
-
-## Delivery Tracker
-
-### G7-001 - Add "Ask AI" action on search results → opens chat with context
-Status: DONE
-Dependency: none
-Owners: Developer / Implementer (Frontend)
-Task description:
-- **Entity card action**: Add an "Ask AI" action button (icon: AI/chat bubble) to every entity card in global search results:
-  1. The action type is `"ask_ai"`.
-  2. On click:
-     a. Close the global search panel.
-     b. Open the Advisory AI chat panel (or navigate to chat route if it's a page).
-     c. Pre-populate the chat with a system context message (invisible to user) containing the entity card details (entity_key, title, snippet, domain, severity, metadata).
-     d. Pre-populate the user input with a contextual question:
-        - For findings: "Tell me about this vulnerability and its impact"
-        - For VEX: "Explain this VEX assessment"
-        - For policy: "Explain this policy rule and its implications"
-        - For docs: "Summarize this documentation section"
-        - For doctor: "What does this health check mean and what should I do?"
-     e. Auto-send the message so the user immediately gets a response.
-     f. Ensure route/panel activation consumes `openChat=true` (or equivalent) so chat reliably opens after navigation.
-- **Synthesis panel action**: Add an "Ask AI for more details" button at the bottom of the synthesis panel:
-  1. On click: open chat with the full search query and all result summaries as context.
-  2. Pre-populate: "I searched for '{query}' and got these results. Can you help me understand them in detail?"
-
-Completion criteria:
-- [x] "Ask AI" button appears on every entity card in search results.
-- [x] Clicking "Ask AI" closes search and opens chat.
-- [x] Chat receives entity context (entity_key, title, domain, severity, snippet).
-- [x] User input pre-populated with domain-specific question.
-- [x] Message auto-sent on chat open.
-- [x] Route-level chat activation is deterministic (`openChat` or equivalent is consumed by the target chat host).
-- [x] Synthesis panel has "Ask AI for more details" button.
-- [x] Chat receives all search results as context when triggered from synthesis.
-- [x] Keyboard accessible: "Ask AI" reachable via Tab.
-
-### G7-002 - Add "Show all results" link in chat responses → opens search
-Status: DONE
-Dependency: none
-Owners: Developer / Implementer (Frontend)
-Task description:
-- In `ChatMessageComponent`, when a chat response contains object link citations:
-  1. Add a "Search for more" link at the bottom of the citations section.
-  2. On click: open global search (Cmd+K) with the query pre-filled based on the chat context:
-     - If the chat message references a CVE → search for that CVE ID.
-     - If the chat message references a policy rule → search for that rule ID.
-     - Otherwise → search for the user's original question text.
-  3. The search input gains focus and results are fetched immediately.
-- In `ChatMessageComponent`, for each object link chip (SBOM, finding, VEX, etc.):
-  1. Add a secondary action (right-click or long-press): "Search related" → opens global search filtered to that entity's domain.
-
-Completion criteria:
-- [x] "Search for more" link appears below citations in chat responses.
-- [x] Clicking opens global search with pre-filled query.
-- [x] Query derived from chat context (CVE ID, rule ID, or question text).
-- [x] Object link chips have "Search related" secondary action.
-- [x] "Search related" filters to relevant domain.
-- [x] Keyboard accessible.
-
-### G7-003 - Create shared SearchChatContext service for bidirectional state
-Status: DOING
-Dependency: G7-001, G7-002
-Owners: Developer / Implementer (Frontend)
-Task description:
-- Create `src/Web/StellaOps.Web/src/app/core/services/search-chat-context.service.ts`:
-  1. A singleton Angular service that holds transient state between search and chat.
-  2. Properties:
-     - `searchToChat`: `{ query: string, entityCards: EntityCard[], synthesis: SynthesisResult | null }` — set when user transitions from search to chat.
-     - `chatToSearch`: `{ query: string, domain?: string, entityKey?: string }` — set when user transitions from chat to search.
-  3. The state is consumed once (cleared after the target component reads it), preventing stale context.
-- Update `ChatService.createConversation()`:
-  1. If `searchToChat` context exists, include it in the conversation creation request as `initialContext`.
-  2. The backend (if it supports initial context) uses this to prime the conversation. If not, the context is included as the first system message.
-- Update `GlobalSearchComponent.onOpen()`:
-  1. If `chatToSearch` context exists, pre-fill the search input and trigger search.
-- Wire call sites explicitly:
-  1. `SearchChatContextService.consumeSearchToChat()` is called by the chat host/page on open.
-  2. `SearchChatContextService.consumeChatToSearch()` is called by global search open/focus flow.
-
-Completion criteria:
-- [x] `SearchChatContextService` exists as singleton.
-- [x] Search→chat transition carries entity cards and synthesis.
-- [x] Chat→search transition carries query and domain filter.
-- [x] Context consumed once (no stale state).
-- [x] Chat conversation created with search context when available.
-- [x] Search pre-filled with chat context when available.
-- [x] Both consume methods are wired into real call sites (no orphan service methods).
-- [ ] Integration test: search for CVE → click "Ask AI" → chat opens with CVE context → chat responds with reference to the CVE.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-24 | Sprint created from search gap analysis G7 (MODERATE). | Product Manager |
-| 2026-02-24 | Scope clarified from implementation audit: added explicit criteria for route-level `openChat` consumption and real call-site wiring for `SearchChatContextService` consume methods. | Project Manager |
-| 2026-02-24 | G7-001/002 marked DONE after implementation audit: search Ask-AI handoff, triage chat host `openChat` consumption, chat auto-send, search-more and search-related actions, and route normalization wiring are in place across global-search/chat components. | Developer |
-| 2026-02-24 | G7-003 remains DOING pending the explicit end-to-end integration test evidence path (search → chat → search round-trip assertions). | Project Manager |
-
-## Decisions & Risks
-- **Decision**: The context bridge is frontend-only (no new backend API required for the basic bridge). Chat context is passed as initial message content.
-- **Decision**: "Ask AI" auto-sends the message to reduce friction. The user doesn't have to press Enter — the conversation starts immediately.
-- **Risk**: Auto-sending may surprise users who wanted to edit the pre-filled question. Mitigation: show a brief animation (1 second) with "Asking AI..." before sending, giving the user a chance to cancel.
-- **Risk**: Large search result sets (10+ entity cards) passed as chat context may produce long initial messages. Mitigation: limit context to top 5 results + synthesis summary.
-- **Decision**: The shared context service is transient (not persisted). Refreshing the page clears the bridge state. This is acceptable for in-session navigation.
-- **Docs sync**: UI bridge behavior and route handoff are documented in `docs/modules/ui/architecture.md` (section "Global Search and Assistant Bridge").
-
-## Next Checkpoints
-- After G7-001: demo search → "Ask AI" → chat flow.
-- After G7-002: demo chat → "Search for more" → search flow.
-- After G7-003: demo round-trip: search → chat → search with preserved context.

docs/implplan/SPRINT_20260224_109_AdvisoryAI_multilingual_search_intelligence.md

@@ -1,175 +0,0 @@
-# Sprint 20260224_109 — Search Gap G9: Multilingual Search Intelligence (MINOR)
-
-## Topic & Scope
-- **Gap**: The i18n system supports 9 locales (en-US, de-DE, bg-BG, ru-RU, es-ES, fr-FR, uk-UA, zh-TW, zh-CN), but the search intelligence layer is English-only. Query processing (tokenization, intent classification, entity extraction) uses English patterns. FTS uses the `simple` text search config (or `english` after G5) with no multi-language support. Doctor check descriptions, remediation text, synthesis templates, and chat suggestions are all English-only. Intent keywords ("deploy", "troubleshoot", "fix") only work in English. A German-speaking user searching "Sicherheitslücke" (vulnerability) gets zero results even though the UI labels are in German.
-- **Outcome**: Add multi-language FTS configurations for supported locales, extend intent classification with multilingual keyword sets, localize doctor check descriptions and synthesis templates, and implement query-language detection to select the appropriate FTS config dynamically.
-- Working directory: `src/AdvisoryAI`.
-- Explicit cross-module edits authorized: `src/Web/StellaOps.Web` (localized suggestions), `docs/modules/advisory-ai`.
-- Expected evidence: multilingual FTS tests, localized intent classification tests, query language detection accuracy test.
-
-## Dependencies & Concurrency
-- Upstream: `SPRINT_20260224_101` (G5 — FTS english config) should be complete first, as this sprint extends the FTS config approach to multiple languages.
-- Safe parallelism: FTS configs (001) and intent localization (002) can proceed in parallel. Doctor localization (003) is independent. Language detection (004) depends on 001.
-- Required references:
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/KnowledgeSearch/PostgresKnowledgeSearchStore.cs` — FTS queries
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/QueryUnderstanding/IntentClassifier.cs` — intent keywords
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Synthesis/SynthesisTemplateEngine.cs` — templates
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/KnowledgeSearch/doctor-search-seed.json` — doctor descriptions
-
-## Documentation Prerequisites
-- `docs/modules/advisory-ai/knowledge-search.md`
-- `docs/code-of-conduct/CODE_OF_CONDUCT.md`
-- PostgreSQL documentation on text search configurations: `german`, `french`, `spanish`, `russian` are built-in.
-
-## Delivery Tracker
-
-### G9-001 - Add multi-language FTS configurations and tsvector columns
-Status: DOING
-Dependency: SPRINT_20260224_101 (G5-001 — FTS english migration)
-Owners: Developer / Implementer
-Task description:
-- Create a migration that adds FTS tsvector columns for each supported language that PostgreSQL has a built-in text search config for:
-  - `body_tsv_de` using `to_tsvector('german', ...)`
-  - `body_tsv_fr` using `to_tsvector('french', ...)`
-  - `body_tsv_es` using `to_tsvector('spanish', ...)`
-  - `body_tsv_ru` using `to_tsvector('russian', ...)`
-  - For `bg-BG`, `uk-UA`, `zh-TW`, `zh-CN`: PostgreSQL has no built-in configs. Use `simple` config for these locales (no stemming, but at least tokenization works). Consider `pg_jieba` extension for Chinese in a future sprint.
-- Add GIN indexes on each new tsvector column.
-- Update `KnowledgeIndexer.RebuildAsync()` to populate all tsvector columns during index rebuild.
-- Add a mapping in `KnowledgeSearchOptions`:
-  ```
-  FtsLanguageConfigs:
-    en-US: english
-    de-DE: german
-    fr-FR: french
-    es-ES: spanish
-    ru-RU: russian
-    bg-BG: simple
-    uk-UA: simple
-    zh-TW: simple
-    zh-CN: simple
-  ```
-
-Completion criteria:
-- [x] Migration creates tsvector columns for de, fr, es, ru.
-- [x] GIN indexes created.
-- [x] Indexer populates all tsvector columns on rebuild.
-- [x] Language config mapping exists in options.
-- [ ] Test: German tsvector stemming works ("Sicherheitslücken" -> "Sicherheitslück").
-
-### G9-002 - Localize intent classification keyword sets
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer
-Task description:
-- In `IntentClassifier.cs`:
-  0. Normalize keyword resource encoding to UTF-8 and replace any mojibake examples in source/docs before functional validation.
-  1. Extract the current English keyword sets into a localizable resource file or dictionary.
-  2. Add equivalent keyword sets for each supported locale:
-     - **Navigate intent** (en: "go to", "open", "show me", "find"):
-       - de: "gehe zu", "öffne", "zeige mir", "finde"
-       - fr: "aller à", "ouvrir", "montre-moi", "trouver"
-       - es: "ir a", "abrir", "muéstrame", "buscar"
-       - ru: "перейти", "открыть", "покажи", "найти"
-     - **Troubleshoot intent** (en: "fix", "error", "failing", "broken", "debug"):
-       - de: "beheben", "Fehler", "fehlgeschlagen", "kaputt", "debuggen"
-       - fr: "corriger", "erreur", "échoué", "cassé", "déboguer"
-       - es: "arreglar", "error", "fallando", "roto", "depurar"
-       - ru: "исправить", "ошибка", "сбой", "сломан", "отладка"
-     - Similarly for explore and compare intents.
-  3. Select keyword set based on detected query language or user's locale preference.
-  4. If language is unknown, try all keyword sets and use the one with the highest match count.
-
-Completion criteria:
-- [x] Keyword sets extracted to localizable resource.
-- [x] At least en, de, fr, es, ru keyword sets defined.
-- [x] Intent classifier uses locale-appropriate keywords.
-- [x] Fallback: try all locales when language unknown.
-- [x] Keyword resources are UTF-8 clean (no mojibake) for de/fr/es/ru terms.
-- [x] Test: "Fehler beheben" (German for "fix error") -> troubleshoot intent.
-- [x] Test: "corriger l'erreur" (French for "fix error") -> troubleshoot intent.
-
-### G9-003 - Localize doctor check descriptions and synthesis templates
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer, Documentation Author
-Task description:
-- **Doctor checks**: Create locale-specific variants of `doctor-search-seed.json`:
-  - `doctor-search-seed.de.json`, `doctor-search-seed.fr.json`, etc.
-  - Each contains the same check codes but with localized titles, descriptions, remediation text, and symptoms.
-  - If a locale-specific file doesn't exist, fall back to English.
-  - The indexer should ingest the locale-specific doctor metadata alongside English, creating separate chunks tagged with locale.
-- **Synthesis templates**: In `SynthesisTemplateEngine.cs`:
-  1. Extract template strings to a localizable resource.
-  2. Add localized templates for supported locales.
-  3. Select template based on user's locale (from `Accept-Language` header or user preference).
-  4. Fallback: English if locale template doesn't exist.
-- **Priority**: Start with de-DE and fr-FR as the two most-requested locales. Other locales can follow.
-
-Completion criteria:
-- [x] Locale-specific doctor seed files exist for at least de-DE and fr-FR.
-- [x] Indexer ingests locale-specific doctor metadata.
-- [x] Synthesis templates localized for at least de-DE and fr-FR.
-- [x] Locale selection based on user preference or Accept-Language.
-- [x] English fallback for missing locales.
-- [ ] Test: German user gets German doctor check descriptions.
-- [x] Test: French user gets French synthesis summaries.
-
-### G9-004 - Implement query language detection and FTS config routing
-Status: DOING
-Dependency: G9-001
-Owners: Developer / Implementer
-Task description:
-- Add a lightweight query language detector in `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/QueryUnderstanding/QueryLanguageDetector.cs`:
-  1. Use character set analysis:
-     - Cyrillic characters -> ru-RU or uk-UA or bg-BG.
-     - CJK characters -> zh-CN or zh-TW.
-     - Latin characters with diacritics patterns -> attempt to distinguish de/fr/es.
-  2. Use a small stop-word list per language (top 20 stop words each) for disambiguation among Latin-script languages.
-  3. Fallback to user's locale preference from `Accept-Language` header or `X-StellaOps-Locale`.
-  4. Ultimate fallback: `english` (the best FTS config for unknown languages).
-- In `PostgresKnowledgeSearchStore.SearchFtsAsync()`:
-  1. Accept a `locale` parameter.
-  2. Select the appropriate tsvector column and tsquery config based on detected language.
-  3. Use `websearch_to_tsquery(@config, @query)` with the detected config.
-
-Completion criteria:
-- [x] `QueryLanguageDetector` detects language from query text.
-- [x] Cyrillic -> Russian/Ukrainian/Bulgarian.
-- [x] CJK -> Chinese.
-- [x] Latin + stop words -> English/German/French/Spanish.
-- [x] Fallback to user locale, then to English.
-- [x] `SearchFtsAsync` uses detected language for FTS config.
-- [x] Test: "Sicherheitsl<73>cke" -> german FTS config used.
-- [x] Test: "vulnerability" -> english FTS config used.
-- [x] Test: "uyazvimost" -> russian FTS config used.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-24 | Sprint created from search gap analysis G9 (MINOR). | Product Manager |
-| 2026-02-24 | G9-001: Created migration `007_multilingual_fts.sql` with idempotent tsvector columns (de, fr, es, ru) and GIN indexes. Added `FtsLanguageConfigs` dictionary to `KnowledgeSearchOptions`. Updated `InsertChunksAsync` in `PostgresKnowledgeSearchStore` to populate all multilingual tsvector columns on index rebuild. Added `ResolveFtsConfigAndColumn` helper and `locale` parameter to `SearchFtsAsync` in both interface and implementation. | Developer |
-| 2026-02-24 | G9-002: Created `MultilingualIntentKeywords.cs` with localized keyword dictionaries for navigate, troubleshoot, explore, and compare intents across en, de, fr, es, ru. Updated `IntentClassifier.Classify()` to accept optional `languageCode` parameter, use locale-specific keywords when provided, and fall back to trying all locales when language is unknown. | Developer |
-| 2026-02-24 | G9-003: Refactored `SynthesisTemplateEngine` to use `LocalizedTemplateStrings` with localized dictionaries for en, de, fr, es, ru. Added `locale` parameter to `Synthesize()` method. Template string resolution falls back to English for unknown locales. Doctor seed localization deferred (content authoring effort). | Developer |
-| 2026-02-24 | G9-004: Created `QueryLanguageDetector.cs` with character-set analysis (Cyrillic, CJK), stop-word frequency analysis for Latin-script languages, and diacritics detection. Provides `DetectLanguage()`, `MapLanguageToFtsConfig()`, `MapLanguageToTsvColumn()`, and `MapLanguageToLocale()` methods. | Developer |
-| 2026-02-24 | Doctor seed localization DONE: Created `doctor-search-seed.de.json` (German) and `doctor-search-seed.fr.json` (French) with professional translations of all 8 doctor checks (title, description, remediation, symptoms). Updated `.csproj` for copy-to-output. Added `DoctorSearchSeedLoader.LoadLocalized()` method and extended `KnowledgeIndexer.IngestDoctorAsync()` to index locale-tagged chunks for de/fr alongside English chunks. | Developer |
-| 2026-02-24 | Sprint reopened: statuses corrected to DOING after audit found encoding corruption (mojibake) and missing multilingual verification evidence in completion criteria. | Project Manager |
-| 2026-02-24 | Added multilingual verification assertions for French troubleshoot intent and UTF-8 keyword hygiene in `UnifiedSearchSprintIntegrationTests`, then reran the targeted suite (`dotnet run --project src/AdvisoryAI/__Tests/StellaOps.AdvisoryAI.Tests/StellaOps.AdvisoryAI.Tests.csproj -- -class "StellaOps.AdvisoryAI.Tests.Integration.UnifiedSearchSprintIntegrationTests" -parallel none`, `Total: 89, Failed: 0`). | QA / Test Automation |
-
-## Decisions & Risks
-- **Decision**: Multiple tsvector columns (one per language) rather than a single column with runtime config switching. This is more storage-intensive but avoids re-indexing when language changes and allows cross-language search in the future.
-- **Risk**: Doctor check localization is a significant content authoring effort. Mitigation: start with de-DE and fr-FR only; other locales use English fallback.
-- **Risk**: Query language detection from short queries (2-3 words) is unreliable. Mitigation: prioritize user locale preference over detection; detection is only used when locale is not set.
-- **Decision**: Chinese text search uses `simple` config initially. Proper Chinese tokenization requires `pg_jieba` or similar, which is a non-trivial dependency. Defer to a future sprint.
-- **Risk**: Adding tsvector columns for 5 languages increases storage by ~5x for the tsvector data. For the current knowledge base size (thousands of chunks), this is negligible (<10MB). Monitor if the index grows significantly.
-- **Decision** (G9-003): Doctor seed file localization completed as follow-up: `doctor-search-seed.de.json` and `doctor-search-seed.fr.json` created with full translations. Indexer extended with locale-tagged chunk ingestion. Synthesis template localization is complete for en, de, fr, es, ru.
-- **Decision** (G9-002): `IntentClassifier.Classify()` now accepts an optional `languageCode` parameter (default null). This is backward-compatible: existing callers that pass no language get the same English-first behavior with multilingual fallback.
-- **Decision** (G9-004): `IKnowledgeSearchStore.SearchFtsAsync()` now accepts an optional `locale` parameter (default null). Backward-compatible: existing callers without locale get the default `FtsLanguageConfig` behavior.
-- **Risk**: Corrupted localized keyword payloads can break intent detection for non-English users and silently degrade newcomer experience. Mitigation: enforce UTF-8 validation in tests and CI.
-
-## Next Checkpoints
-- After G9-001: demo German FTS stemming on German text.
-- After G9-002: demo multilingual intent classification with UTF-8 keyword fixtures.
-- After G9-004: demo query language detection routing.
-- Follow-up: validate doctor seed localization behavior for de-DE and fr-FR in targeted integration tests.
-- Follow-up: complete targeted multilingual FTS/intent/language-detection evidence and attach run outputs.

docs/implplan/SPRINT_20260224_110_AdvisoryAI_search_feedback_analytics_loop.md

@@ -1,217 +0,0 @@
-# Sprint 20260224_110 — Search Gap G10: Search Feedback and Quality Improvement Loop (MINOR)
-
-## Topic & Scope
-- **Gap**: There is no mechanism for users to signal whether search results were helpful. No "Was this helpful?" prompt, no thumbs up/down on results, no zero-result query surfacing to operators, no way to report bad or irrelevant results. Without a feedback loop, the search system operates blind — it cannot distinguish between queries that perfectly satisfy users and queries that produce garbage rankings. Zero-result queries (which indicate vocabulary gaps in the index) are invisible. Operators have no dashboard to monitor search quality or identify improvement opportunities.
-- **Outcome**: Add result-level feedback (thumbs up/down), zero-result alert surfacing, a search quality dashboard for operators, and a query refinement suggestion mechanism powered by the feedback data.
-- Working directory: `src/AdvisoryAI`.
-- Explicit cross-module edits authorized: `src/Web/StellaOps.Web` (feedback UI), `docs/modules/advisory-ai`.
-- Expected evidence: feedback schema, UI integration tests, dashboard wireframe, zero-result alerting tests.
-
-## Dependencies & Concurrency
-- `SPRINT_20260224_106` (G6 — analytics collection) provides the `search_events` table that this sprint extends. If G6 is not complete, this sprint can create its own feedback table independently.
-- Safe parallelism: feedback collection (001), zero-result alerting (002), and quality dashboard (003) can proceed in parallel.
-- Required references:
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI/UnifiedSearch/Analytics/SearchAnalyticsService.cs` (from G6, or created here)
-  - `src/Web/StellaOps.Web/src/app/shared/components/entity-card/entity-card.component.ts`
-  - `src/Web/StellaOps.Web/src/app/layout/global-search/global-search.component.ts`
-
-## Documentation Prerequisites
-- `docs/modules/advisory-ai/knowledge-search.md`
-- `docs/code-of-conduct/CODE_OF_CONDUCT.md`
-
-## Delivery Tracker
-
-### G10-001 - Add result-level feedback (thumbs up/down) with storage
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer
-Task description:
-- **Database**: Create a `advisoryai.search_feedback` table:
-  ```sql
-  CREATE TABLE advisoryai.search_feedback (
-    feedback_id   UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    tenant_id     TEXT NOT NULL,
-    user_id       TEXT,
-    query         TEXT NOT NULL,
-    entity_key    TEXT NOT NULL,
-    domain        TEXT NOT NULL,
-    position      INT NOT NULL,       -- rank position of the result
-    signal        TEXT NOT NULL,       -- 'helpful', 'not_helpful'
-    comment       TEXT,               -- optional free-text (max 500 chars)
-    created_at    TIMESTAMPTZ DEFAULT now()
-  );
-  CREATE INDEX idx_search_feedback_tenant ON advisoryai.search_feedback (tenant_id, created_at);
-  CREATE INDEX idx_search_feedback_entity ON advisoryai.search_feedback (entity_key, signal);
-  ```
-- **Backend endpoint**: `POST /v1/advisory-ai/search/feedback`
-  ```json
-  {
-    "query": "how to deploy",
-    "entityKey": "doc-deploy-guide-123",
-    "domain": "knowledge",
-    "position": 2,
-    "signal": "helpful",
-    "comment": "This was exactly what I needed"
-  }
-  ```
-  - Validate: signal must be `helpful` or `not_helpful`. Comment max 500 chars. Query max 512 chars.
-  - Rate limit: max 10 feedback submissions per user per minute.
-  - Return 201 on success.
-- **Frontend**: On each entity card in global search results:
-  1. Add thumbs-up and thumbs-down icons (small, right-aligned, below actions).
-  2. Initially gray/muted. On hover, show tooltip: "Was this result helpful?"
-  3. On click: icon turns green (helpful) or red (not_helpful). Send feedback event.
-  4. After clicking, show a brief "Thanks for your feedback" toast and optionally expand a text field for a comment.
-  5. Only allow one feedback per result per search session (disable icons after first click).
-  6. On the synthesis panel: add a single thumbs-up/down pair for the overall synthesis quality.
-
-Completion criteria:
-- [x] `search_feedback` table created via migration (005_search_feedback.sql).
-- [x] Feedback endpoint exists with validation and rate limiting (SearchFeedbackEndpoints.cs).
-- [x] Frontend thumbs-up/down on entity cards (entity-card.component.ts).
-- [x] Frontend thumbs-up/down on synthesis panel (synthesis-panel.component.ts).
-- [x] Visual feedback on click (color change, green for helpful, red for not_helpful).
-- [ ] Optional comment field after feedback (deferred: comment param supported in backend but UI text field not yet added).
-- [x] One feedback per result per session (feedbackGiven signal prevents re-click).
-- [ ] Integration test: submit feedback → verify stored in database (deferred to test sprint).
-
-### G10-002 - Zero-result query alerting and vocabulary gap detection
-Status: DOING
-Dependency: G10-001 (or G6-001 if analytics sprint is complete)
-Owners: Developer / Implementer
-Task description:
-- **Backend**: Create a `SearchQualityMonitor` service that periodically (every hour, configurable) analyzes recent search events:
-  1. Identify zero-result queries from the last 24 hours.
-  2. Group by normalized query text (lowercase, trimmed).
-  3. Count occurrences per query.
-  4. For queries with >= 3 occurrences (configurable threshold): flag as "vocabulary gap."
-  5. Store flagged queries in a `advisoryai.search_quality_alerts` table:
-     ```sql
-     CREATE TABLE advisoryai.search_quality_alerts (
-       alert_id      UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-       tenant_id     TEXT NOT NULL,
-       alert_type    TEXT NOT NULL,  -- 'zero_result', 'low_feedback', 'high_negative_feedback'
-       query         TEXT NOT NULL,
-       occurrence_count INT NOT NULL,
-       first_seen    TIMESTAMPTZ NOT NULL,
-       last_seen     TIMESTAMPTZ NOT NULL,
-       status        TEXT DEFAULT 'open',  -- 'open', 'acknowledged', 'resolved'
-       resolution    TEXT,
-       created_at    TIMESTAMPTZ DEFAULT now()
-     );
-     ```
-  6. Also flag queries with high negative feedback ratio (>= 50% `not_helpful` signals, minimum 5 feedback events).
-- **Backend endpoint**: `GET /v1/advisory-ai/search/quality/alerts`
-  - Returns open alerts, ordered by occurrence count descending.
-  - Filterable by `alertType` and `status`.
-  - Requires `advisory-ai:admin` scope.
-- **Backend endpoint**: `PATCH /v1/advisory-ai/search/quality/alerts/{alertId}`
-  - Update status to `acknowledged` or `resolved` with optional resolution text.
-
-Completion criteria:
-- [ ] `SearchQualityMonitor` runs periodically (periodic background service deferred; manual/on-demand analysis via metrics endpoint available).
-- [ ] Zero-result queries with >= 3 occurrences flagged (alerting infrastructure ready; periodic job not yet wired).
-- [ ] High negative feedback queries flagged (alerting infrastructure ready; periodic job not yet wired).
-- [x] Alerting and metrics queries use the emitted analytics taxonomy (`query`, `click`, `zero_result`) consistently; no stale `search` event dependency.
-- [x] `search_quality_alerts` table created (005_search_feedback.sql).
-- [x] GET alerts endpoint returns open alerts (GET /v1/advisory-ai/search/quality/alerts).
-- [x] PATCH endpoint updates alert status (PATCH /v1/advisory-ai/search/quality/alerts/{alertId}).
-- [ ] Integration test: generate 5 zero-result events for same query → verify alert created (deferred to test sprint).
-
-### G10-003 - Search quality dashboard for operators
-Status: DOING
-Dependency: G10-001, G10-002
-Owners: Developer / Implementer (Frontend)
-Task description:
-- Create a new page at `/ops/operations/search-quality` (add to operations navigation).
-- The dashboard shows:
-  1. **Summary metrics** (top row, 4 cards):
-     - Total searches (last 24h / 7d / 30d).
-     - Zero-result rate (percentage).
-     - Average result count per query.
-     - Feedback score (% helpful out of total feedback).
-  2. **Zero-result queries** (table):
-     - Query text, occurrence count, first seen, last seen, status.
-     - Action buttons: "Acknowledge", "Resolve" (with comment).
-     - Sortable by occurrence count and recency.
-  3. **Low-quality results** (table):
-     - Entity key, domain, negative feedback count, total feedback, negative rate.
-     - Helps identify specific results that consistently disappoint users.
-  4. **Top queries** (table):
-     - Most frequent queries with average result count and feedback score.
-     - Helps identify what users search for most.
-  5. **Trend chart** (line graph):
-     - Daily search count, zero-result rate, and feedback score over last 30 days.
-- Data fetched from:
-  - `GET /v1/advisory-ai/search/quality/alerts` (zero-result alerts)
-  - `GET /v1/advisory-ai/search/quality/metrics` (new endpoint — aggregate metrics)
-- Requires `advisory-ai:admin` scope to access.
-
-Completion criteria:
-- [x] Dashboard page exists at `/ops/operations/search-quality` (search-quality-dashboard.component.ts).
-- [x] Added to operations navigation menu (navigation.config.ts + operations.routes.ts).
-- [x] Summary metrics cards display (total searches, zero-result rate, avg results, feedback score).
-- [x] Zero-result queries table with acknowledge/resolve actions.
-- [ ] Low-quality results table with feedback data (deferred: requires additional backend aggregation query).
-- [ ] Top queries table (deferred: requires additional backend aggregation query).
-- [ ] Trend chart for 30-day history (deferred: requires time-series endpoint).
-- [ ] Metric cards validated against raw event samples; total-search count and zero-result rate match source analytics events.
-- [x] Requires admin scope (advisory-ai:admin in nav config).
-- [x] Responsive layout (grid collapses on mobile).
-
-### G10-004 - Query refinement suggestions from feedback data
-Status: DONE
-Dependency: G10-002
-Owners: Developer / Implementer
-Task description:
-- When a zero-result or low-result query is detected, attempt to suggest refinements:
-  1. Check if a resolved zero-result alert exists for a similar query (using trigram similarity from G5). If yes, suggest the resolution's query.
-  2. Check the `search_history` table (from G6) for successful queries (result_count > 0) that are similar to the current query. Suggest the closest successful query.
-  3. Check for entity aliases: if the query matches a known alias in `advisoryai.entity_alias`, suggest the canonical entity key as a query.
-- Return suggestions in the search response:
-  ```json
-  {
-    "refinements": [
-      { "text": "policy gate prerequisites", "source": "resolved_alert" },
-      { "text": "release gate", "source": "similar_successful_query" }
-    ]
-  }
-  ```
-- **Frontend**: Show refinements below "Did you mean?" (from G4-003) as a separate "Try also:" section.
-  - "Try also: **policy gate prerequisites**, **release gate**"
-  - Clickable: replaces query and re-searches.
-
-Completion criteria:
-- [x] Resolved alerts provide refinement suggestions (via `SearchQualityMonitor.GetAlertsAsync` + in-memory trigram similarity).
-- [x] Successful similar queries provide suggestions (via `SearchAnalyticsService.FindSimilarSuccessfulQueriesAsync` using pg_trgm `similarity()`).
-- [x] Entity aliases provide suggestions (via `IEntityAliasService.ResolveAliasesAsync`).
-- [x] Refinements returned in search response (`SearchRefinement` record, `UnifiedSearchApiRefinement` DTO, mapped in `UnifiedSearchEndpoints`).
-- [x] Frontend renders "Try also:" section (blue/sky chip bar below "Did you mean?" in `global-search.component.ts`).
-- [x] Clicking refinement replaces query and re-searches (`applyRefinement` method).
-- [x] Test: integration tests cover refinement generation flow.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-24 | Sprint created from search gap analysis G10 (MINOR). | Product Manager |
-| 2026-02-24 | G10-001 DONE: Added thumbs up/down feedback to entity-card and synthesis-panel components. Created SearchFeedbackEndpoints.cs with POST /feedback (201), validation (signal, comment length, query length). Created SearchQualityMonitor service. Created 005_search_feedback.sql migration with search_feedback and search_quality_alerts tables. Added submitFeedback() fire-and-forget method to UnifiedSearchClient. Global search wires feedbackSubmitted events from entity cards and synthesis panel. | Developer |
-| 2026-02-24 | G10-002 DONE: Created GET /quality/alerts (admin, filterable by status/alertType), PATCH /quality/alerts/{alertId} (status transitions), GET /quality/metrics (aggregate metrics for 24h/7d/30d). SearchQualityMonitor registered in DI via UnifiedSearchServiceCollectionExtensions. Endpoints registered in Program.cs. | Developer |
-| 2026-02-24 | G10-003 DONE: Created SearchQualityDashboardComponent at features/operations/search-quality/. Added route at /ops/operations/search-quality in operations.routes.ts. Added nav entry under Ops group with advisory-ai:admin scope gate. Dashboard shows 4 metric cards with period selector and alerts table with acknowledge/resolve actions. | Developer |
-| 2026-02-24 | G10-004 DONE: Backend: Added `SearchRefinement` record and `Refinements` to `UnifiedSearchResponse`. Added `GenerateRefinementsAsync` with 3-source strategy: resolved alerts (in-memory trigram similarity), similar successful queries (pg_trgm `similarity()`), entity aliases. Added `FindSimilarSuccessfulQueriesAsync` to `SearchAnalyticsService`. Added `TrigramSimilarity` static helper implementing Jaccard over character trigrams. API: Added `UnifiedSearchApiRefinement` DTO mapped in `UnifiedSearchEndpoints`. Frontend: Added `SearchRefinement` interface, mapped in client, "Try also:" bar with blue/sky chip styling in `global-search.component.ts`, `applyRefinement` method. | Developer |
-| 2026-02-24 | Sprint reopened: statuses corrected to DOING for G10-001/002/003 because completion criteria remain partially unmet (periodic monitor wiring, dashboard depth, and metrics validation). | Project Manager |
-| 2026-02-24 | G10-002 criteria updated after code audit: `SearchQualityMonitor` metrics SQL now uses `query`/`zero_result` taxonomy and no longer depends on stale `event_type='search'`; analytics endpoint also persists query history for real user events. | Developer |
-
-## Decisions & Risks
-- **Decision**: Feedback is anonymous by default (user_id optional). This encourages more feedback by reducing friction.
-- **Decision**: The quality dashboard is admin-only. Regular users should not see aggregate search quality metrics.
-- **Risk**: Users may not provide feedback without incentive. Mitigation: make the feedback interaction minimal (single click), show it on every result, and display "Thanks" acknowledgment.
-- **Risk**: Negative feedback may not distinguish between "irrelevant result" and "result was relevant but not helpful for my specific question." Mitigation: the optional comment field allows users to explain; the comment data is available in the dashboard.
-- **Decision**: Feedback data is NOT used for automatic ranking changes (that's G6-002 popularity boost). This sprint focuses on visibility and manual quality improvement. Automated feedback-to-ranking integration is deferred.
-- **Risk**: The search quality dashboard adds a new page and navigation item. Ensure it's behind the admin scope gate so non-admin users don't see an empty or confusing page.
-- **Risk**: Metrics-card math can appear healthy while being wrong if analytics event taxonomy is inconsistent between writer and reader queries. Mitigation: reconcile taxonomy in SQL and add integration checks against raw event samples.
-- **Docs sync**: fallback/degraded-mode and analytics taxonomy notes updated in `docs/modules/advisory-ai/knowledge-search.md`.
-
-## Next Checkpoints
-- After G10-001: demo feedback submission on search results.
-- After G10-002: demo zero-result alerting after simulated traffic.
-- After G10-003: design review of dashboard layout with product team.

docs/implplan/SPRINT_20260224_111_AdvisoryAI_chat_contract_runtime_hardening.md

@@ -1,114 +0,0 @@
-# Sprint 20260224_111 - Advisory AI Chat Contract and Runtime Hardening
-
-## Topic & Scope
-- Close high-impact chat reliability gaps discovered in search-to-chat integration review: request contract mismatch, placeholder conversation responses, and duplicate endpoint behavior.
-- Align chat behavior so users unfamiliar with Stella Ops get deterministic, grounded assistant responses regardless of which chat entrypoint is used.
-- Working directory: `src/AdvisoryAI`.
-- Explicit cross-module edits authorized: `src/Web/StellaOps.Web` (chat client request mapping), `docs/modules/advisory-ai` (API/behavior docs).
-- Expected evidence: endpoint contract diff, integration tests for add-turn behavior, authorization matrix, deprecation compatibility notes.
-
-## Dependencies & Concurrency
-- Upstream: `SPRINT_20260224_107_FE_search_chat_bridge.md` for frontend bridge behavior.
-- Upstream: `SPRINT_20260223_100_AdvisoryAI_unified_search_polish_analytics_deprecation.md` for shared analytics/security conventions.
-- Safe parallelism: contract compatibility work (001) can run in parallel with endpoint-surface/auth cleanup (003). Runtime replacement (002) depends on contract freeze from 001.
-- Required references:
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI.WebService/Program.cs`
-  - `src/AdvisoryAI/StellaOps.AdvisoryAI.WebService/Endpoints/ChatEndpoints.cs`
-  - `src/Web/StellaOps.Web/src/app/features/advisory-ai/chat/chat.service.ts`
-  - `docs/modules/advisory-ai/chat-interface.md`
-
-## Documentation Prerequisites
-- `docs/modules/advisory-ai/chat-interface.md`
-- `docs/modules/advisory-ai/knowledge-search.md`
-- `docs/code-of-conduct/CODE_OF_CONDUCT.md`
-
-## Delivery Tracker
-
-### CHAT-111-001 - Canonicalize add-turn request contract with compatibility shim
-Status: DONE
-Dependency: none
-Owners: Developer / Implementer
-Task description:
-- Define one canonical add-turn payload field for chat user input: `content`.
-- Preserve temporary compatibility by accepting legacy `message` input for one deprecation window and mapping it to `content`.
-- Emit structured warning telemetry when legacy payloads are used so migration progress is measurable.
-- Update frontend chat client calls and OpenAPI docs to match the canonical contract.
-
-Completion criteria:
-- [x] Canonical add-turn contract is `content` across chat endpoints.
-- [x] Legacy `message` payload is accepted only via explicit compatibility mapping.
-- [x] Compatibility use is logged/telemetered with tenant and endpoint context.
-- [x] OpenAPI and docs reflect canonical contract and migration timeline.
-- [x] Frontend chat client payloads are aligned with canonical field names.
-
-### CHAT-111-002 - Replace placeholder conversation responses with grounded runtime path
-Status: DONE
-Dependency: CHAT-111-001
-Owners: Developer / Implementer
-Task description:
-- Remove placeholder assistant response behavior from conversation turn handling.
-- Route conversation turn execution to the same grounded assistant runtime used by the primary chat gateway (or deterministic fallback when LLM is unavailable).
-- Ensure fallback behavior is explicit, non-deceptive, and consistent with offline-first posture.
-
-Completion criteria:
-- [x] Conversation add-turn path no longer emits placeholder responses.
-- [x] Runtime path uses grounded response generation with existing safeguards.
-- [x] Offline or provider-unavailable path returns deterministic fallback output with explicit metadata.
-- [x] Response behavior is consistent across conversation and chat gateway entrypoints.
-- [x] Integration tests cover success, fallback, and error paths.
-
-### CHAT-111-003 - Normalize chat endpoint surfaces and authorization behavior
-Status: DONE
-Dependency: CHAT-111-001
-Owners: Developer / Implementer, Security Reviewer
-Task description:
-- Define canonical chat API surface and mark duplicate/legacy endpoints with deprecation headers and timeline.
-- Harmonize scope checks and policy gates so equivalent chat operations enforce equivalent authorization.
-- Update API docs and runbooks so operators understand which route family is canonical and which is transitional.
-
-Completion criteria:
-- [x] Canonical chat endpoint family is documented and implemented.
-- [x] Legacy/duplicate endpoint family has deprecation headers and sunset plan.
-- [x] Authorization scope behavior is consistent across equivalent chat operations.
-- [x] Endpoint auth/scope docs are updated and traceable.
-- [x] Backward compatibility behavior is tested for migration window.
-
-### CHAT-111-004 - Tier-2 API verification and migration evidence
-Status: DOING
-Dependency: CHAT-111-002, CHAT-111-003
-Owners: QA / Test Automation
-Task description:
-- Execute targeted Tier-2 API verification for chat turn submission and response correctness using real HTTP requests.
-- Capture before/after evidence for contract mismatch handling, placeholder-removal behavior, and auth parity.
-- Add deterministic regression tests for payload compatibility, canonical-path behavior, and deprecation signaling.
-
-Completion criteria:
-- [ ] Tier-2 API evidence includes raw request/response samples for canonical and legacy payloads.
-- [x] Regression tests validate `content` canonical handling and legacy `message` mapping.
-- [x] Regression tests verify no placeholder responses are returned.
-- [x] Regression tests verify auth parity across endpoint surfaces.
-- [x] Evidence is logged in sprint execution notes with test command outputs.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-24 | Sprint created from search+assistant gap audit for chat contract/runtime hardening. | Project Manager |
-| 2026-02-24 | CHAT-111-001/002 moved to DOING after implementation audit: add-turn contract now accepts canonical `content` with legacy `message` shim; frontend payload switched to `content`; conversation runtime path now produces grounded/deterministic responses instead of placeholders. | Developer |
-| 2026-02-24 | Added chat integration tests for legacy payload compatibility and empty-payload rejection; full AdvisoryAI test suite passed (`772/772`, `dotnet test ...`), with MTP warning that legacy `--filter` property was ignored. | QA / Test Automation |
-| 2026-02-24 | CHAT-111-003/004 remain DOING pending endpoint-family deprecation docs/headers, auth-parity matrix evidence, and Tier-2 raw API request/response artifacts. | Project Manager |
-| 2026-02-24 | Closure sweep: added legacy endpoint deprecation/sunset OpenAPI descriptions and response headers in `Program.cs`, added tenant+endpoint compatibility telemetry for legacy `message`, added chat-gateway deterministic runtime fallback parity in `ChatEndpoints`, and expanded `ChatIntegrationTests` coverage for auth parity and cross-endpoint runtime consistency. | Developer |
-| 2026-02-24 | Tier-2 regression evidence captured via targeted xUnit v3 runs: `dotnet run --project src/AdvisoryAI/__Tests/StellaOps.AdvisoryAI.Tests/StellaOps.AdvisoryAI.Tests.csproj -- -class \"StellaOps.AdvisoryAI.Tests.Chat.ChatIntegrationTests\" -parallel none` (`Total: 18, Failed: 0`) and `dotnet run --project src/AdvisoryAI/__Tests/StellaOps.AdvisoryAI.Tests/StellaOps.AdvisoryAI.Tests.csproj -- -class \"StellaOps.AdvisoryAI.Tests.Integration.UnifiedSearchSprintIntegrationTests\" -parallel none` (`Total: 87, Failed: 0`). | QA / Test Automation |
-
-## Decisions & Risks
-- Decision: `content` is the canonical chat input field; `message` remains temporary compatibility only.
-- Decision: Placeholder assistant responses are not acceptable for production paths and must be replaced with grounded or explicit deterministic fallback output.
-- Risk: Tightening contracts can break older clients. Mitigation: compatibility shim + deprecation telemetry + explicit sunset timeline.
-- Risk: Endpoint-surface consolidation may affect existing permission assumptions. Mitigation: auth matrix tests and updated endpoint docs before sunset.
-- Decision: Cross-module edits are explicitly allowed only for chat-client contract alignment and documentation sync.
-- Docs sync: canonical add-turn contract, fallback semantics, and citation link families updated in `docs/modules/advisory-ai/chat-interface.md`.
-
-## Next Checkpoints
-- After CHAT-111-001: review canonical payload contract and migration plan.
-- After CHAT-111-002: demonstrate non-placeholder conversation responses in API verification run.
-- After CHAT-111-003: publish endpoint/scope parity matrix and deprecation timeline.
-- After CHAT-111-004: attach Tier-2 API evidence and close migration readiness gate.

docs/implplan/SPRINT_20260224_112_FE_assistant_entry_search_reliability.md

@@ -1,115 +0,0 @@
-# Sprint 20260224_112 - FE Assistant Entry and Search Reliability
-
-## Topic & Scope
-- Close frontend reliability gaps that reduce trust for newcomers: assistant surface discoverability, route mismatches from search actions, and silent fallback from unified search to legacy behavior.
-- Ensure search and assistant transitions are explicit, predictable, and understandable for first-time operators.
-- Working directory: `src/Web/StellaOps.Web`.
-- Explicit cross-module edits authorized: `src/AdvisoryAI/StellaOps.AdvisoryAI.WebService` (fallback signal contract if needed), `docs/modules/ui`.
-- Expected evidence: route/action validation matrix, degraded-mode UX screenshots, Playwright flow evidence for newcomer path.
-
-## Dependencies & Concurrency
-- Upstream: `SPRINT_20260224_107_FE_search_chat_bridge.md` for bidirectional context bridge.
-- Upstream: `SPRINT_20260224_111_AdvisoryAI_chat_contract_runtime_hardening.md` for canonical chat payload/runtime behavior.
-- Upstream: `SPRINT_20260223_100_AdvisoryAI_unified_search_polish_analytics_deprecation.md` for deprecation/fallback conventions.
-- Safe parallelism: route normalization (002) and degraded-mode UX (003) can proceed in parallel; newcomer E2E verification (004) depends on 001-003.
-- Required references:
-  - `src/Web/StellaOps.Web/src/app/layout/global-search/global-search.component.ts`
-  - `src/Web/StellaOps.Web/src/app/app.routes.ts`
-  - `src/Web/StellaOps.Web/src/app/layout/app-topbar/app-topbar.component.ts`
-  - `src/Web/StellaOps.Web/src/app/features/advisory-ai/chat/*`
-
-## Documentation Prerequisites
-- `docs/modules/ui/architecture.md`
-- `docs/modules/advisory-ai/chat-interface.md`
-- `docs/code-of-conduct/CODE_OF_CONDUCT.md`
-
-## Delivery Tracker
-
-### FE-112-001 - Make assistant a first-class shell surface and consume `openChat` navigation intent
-Status: DOING
-Dependency: `SPRINT_20260224_107` G7-001
-Owners: Developer / Implementer (Frontend)
-Task description:
-- Ensure assistant UI is reachable from the main shell (route or panel) and not hidden behind QA-only workbench wiring.
-- Wire navigation intent (`openChat=true` or equivalent state) so search-triggered assistant handoff always opens the chat surface.
-- Ensure keyboard-only users can reach and activate the same flow deterministically.
-
-Completion criteria:
-- [x] Assistant surface is mounted in primary app routing/shell.
-- [x] `openChat` (or equivalent) is consumed by the assistant host and opens chat deterministically.
-- [x] Search-to-chat navigation works from entity-card and synthesis actions.
-- [ ] Keyboard and focus behavior are accessible and deterministic.
-- [ ] Route-level tests cover assistant activation from search handoff.
-
-### FE-112-002 - Normalize search result action routes (including docs navigation)
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer (Frontend)
-Task description:
-- Audit search result action routes emitted from unified search entity cards and quick actions.
-- Normalize action routing so every route points to a real frontend route; add explicit mapping where backend routes differ from Angular route table.
-- Fix docs action navigation so knowledge/doc actions land on a valid docs viewer path with anchor support (or deterministic fallback).
-
-Completion criteria:
-- [ ] Route/action matrix exists for all unified-search action kinds used in UI.
-- [ ] No result action navigates to a non-existent frontend route.
-- [x] Docs-related actions resolve to valid docs UI route with anchor handling.
-- [x] Fallback behavior is explicit for unsupported/legacy routes.
-- [ ] Integration tests cover at least one action per domain (knowledge/findings/policy/vex/platform).
-
-### FE-112-003 - Expose degraded-mode UX when unified search falls back to legacy
-Status: DOING
-Dependency: none
-Owners: Developer / Implementer (Frontend)
-Task description:
-- When unified search request fails and legacy fallback is used, show explicit degraded-mode state in the search UI.
-- Explain functional limitations of fallback results (reduced coverage, no synthesis parity, potential ranking differences) in concise operator language.
-- Emit telemetry when degraded mode is entered/exited so reliability issues are visible.
-
-Completion criteria:
-- [x] UI displays explicit degraded-mode indicator during fallback.
-- [x] Degraded-mode copy explains user-visible limitations and recovery guidance.
-- [x] Indicator clears automatically when unified search recovers.
-- [x] Degraded-mode transitions emit telemetry events.
-- [ ] UX copy is internationalization-ready.
-
-### FE-112-004 - Tier-2 newcomer flow verification (search -> ask AI -> refine -> act)
-Status: TODO
-Dependency: FE-112-001, FE-112-002, FE-112-003
-Owners: QA / Test Automation
-Task description:
-- Add targeted Playwright flows that emulate a newcomer journey:
-  1. Open global search with no prior context.
-  2. Pick a suggested query and open a result.
-  3. Trigger assistant handoff from search.
-  4. Return to search via chat "search more" behavior.
-  5. Execute a concrete action from a validated route.
-- Capture evidence for both healthy unified mode and degraded fallback mode.
-
-Completion criteria:
-- [ ] Playwright flow validates healthy newcomer journey end-to-end.
-- [ ] Playwright flow validates degraded-mode visibility and recovery.
-- [ ] Route/action assertions prevent dead-link regressions.
-- [ ] Accessibility checks cover focus/order during handoff and return.
-- [ ] Evidence artifacts are linked in sprint execution log.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-24 | Sprint created from search+assistant gap audit for frontend reliability and newcomer trust. | Project Manager |
-| 2026-02-24 | FE-112-001/002/003 moved to DOING after implementation audit: triage chat host route wiring is active (`/security/triage`), search action routes are normalized, and degraded-mode fallback banner + telemetry transitions are implemented in global search. | Developer |
-| 2026-02-24 | FE-112-004 remains TODO pending Playwright Tier-2 evidence and route/accessibility assertions. | QA / Test Automation |
-
-## Decisions & Risks
-- Decision: silent fallback is not acceptable UX; degraded mode must be explicitly signaled.
-- Decision: assistant handoff behavior must be route-deterministic and keyboard-accessible.
-- Risk: route normalization can expose hidden backend/frontend contract drift. Mitigation: explicit route/action matrix and integration tests.
-- Risk: degraded-mode messaging can be noisy if fallback flaps. Mitigation: debounce transitions and instrument enter/exit events.
-- Decision: cross-module edits are restricted to minimal backend signal additions and docs sync.
-- Docs sync: assistant handoff, search return, and degraded-mode behavior documented in `docs/modules/ui/architecture.md` and `docs/modules/advisory-ai/chat-interface.md`.
-
-## Next Checkpoints
-- After FE-112-001: demo reliable assistant opening from search actions.
-- After FE-112-002: review route/action matrix with platform and UI owners.
-- After FE-112-003: UX review of degraded-mode copy and behavior.
-- After FE-112-004: attach Playwright evidence for newcomer flow in healthy and degraded modes.

docs/implplan/SPRINT_20260225_113_Scanner_dal_ef_scaffold_unmapped_tables.md

@@ -1,106 +0,0 @@
-# Sprint 113 — Scanner: Scaffold Missing Entities & Migrate Simple Reads
-
-## Topic & Scope
-- Add EF Core entity classes for 11 unmapped Scanner schema tables derived from migration SQL.
-- Register DbSets and OnModelCreating fluent config in ScannerDbContext.
-- Migrate read-only repository methods from raw SQL to EF Core LINQ where tables are now mapped.
-- Working directory: `src/Scanner/__Libraries/StellaOps.Scanner.Storage/`.
-- Expected evidence: build succeeds, existing tests pass, new entities match migration schema.
-
-## Dependencies & Concurrency
-- No upstream sprint dependencies.
-- Safe to run in parallel with Orchestrator/Policy/Scheduler sprints (different modules).
-
-## Documentation Prerequisites
-- Migration SQL files in `Postgres/Migrations/` (authoritative schema definition).
-
-## Delivery Tracker
-
-### SC-113-001 - Create entity classes for unmapped tables
-Status: DONE
-Dependency: none
-Owners: Developer / Implementer
-
-Task description:
-- Create entity classes in `EfCore/Models/` for 11 unmapped tables based on migration SQL:
-  - `code_changes` -> CodeChangeEntity
-  - `epss_raw` -> EpssRawEntity
-  - `epss_signal` -> EpssSignalEntity
-  - `epss_signal_config` -> EpssSignalConfigEntity
-  - `vex_candidates` -> VexCandidateEntity
-  - `func_proof` -> FuncProofEntity
-  - `func_node` -> FuncNodeEntity
-  - `func_trace` -> FuncTraceEntity
-  - `reachability_drift_results` -> ReachabilityDriftResultEntity
-  - `drifted_sinks` -> DriftedSinkEntity
-  - `facet_seals` -> FacetSealEntity
-
-Completion criteria:
-- [x] All 11 entity classes created in EfCore/Models/
-- [x] Column types match migration SQL exactly
-- [x] DATE columns use DateOnly (native Npgsql mapping)
-
-### SC-113-002 - Register new DbSets and configure OnModelCreating
-Status: DONE
-Dependency: SC-113-001
-Owners: Developer / Implementer
-
-Task description:
-- Add DbSet<T> properties to ScannerDbContext for each new entity.
-- Add OnModelCreating fluent config for table names, schema, keys, indexes.
-- Do NOT add vuln_instance_triage (owned by TriageDbContext).
-
-Completion criteria:
-- [x] ScannerDbContext has DbSets for all 11 new entities
-- [x] OnModelCreating matches migration-defined indexes and constraints
-- [x] Foreign keys: DriftedSink->ReachabilityDriftResult, FuncNode->FuncProof, FuncTrace->FuncProof
-- [x] Build succeeds with 0 warnings
-
-### SC-113-003 - Migrate all read operations to EF Core
-Status: DONE
-Dependency: SC-113-002
-Owners: Developer / Implementer
-
-Task description:
-- Migrate read-only methods in ALL repositories where tables are now mapped to EF LINQ.
-- Keep raw SQL only for: ON CONFLICT upserts, PL/pgSQL functions, window functions, BINARY COPY, JSONB INSERT casts, NOW() updates.
-
-Repositories migrated (6 repos, 25 methods total):
-- **PostgresEpssRawRepository**: GetByDateAsync, GetByDateRangeAsync, GetLatestAsync, ExistsAsync, GetByModelVersionAsync -> LINQ. Removed RawRow helper class.
-- **PostgresEpssSignalRepository**: GetByTenantAsync, GetByCveAsync, GetHighPriorityAsync, GetConfigAsync, GetByDedupeKeyAsync -> LINQ. Removed SignalRow/ConfigRow helper classes.
-- **PostgresReachabilityDriftResultRepository**: TryGetLatestForHeadAsync, TryGetByIdAsync, ExistsAsync, ListSinksAsync -> LINQ with Include(). Removed DriftHeaderRow/DriftSinkRow helper classes.
-- **PostgresVexCandidateStore**: GetCandidatesAsync, GetCandidateAsync -> LINQ. Removed VexCandidateRow helper class. Added MapEntityToCandidate static method with ParseVexStatus/ParseJustification.
-- **PostgresFacetSealStore**: GetLatestSealAsync, GetByCombinedRootAsync, GetHistoryAsync, ExistsAsync, DeleteByImageAsync -> LINQ. Replaced MapSeal(NpgsqlDataReader) with MapEntityToSeal(FacetSealEntity). Removed 5 SQL string constants.
-- **PostgresFuncProofRepository**: GetByIdAsync, GetByProofIdAsync, GetByBuildIdAsync, GetByScanIdAsync, ExistsAsync -> LINQ. Replaced MapRow(NpgsqlDataReader) with MapEntityToRow(FuncProofEntity).
-
-Kept as raw SQL:
-- PostgresCodeChangeRepository.StoreAsync (ON CONFLICT)
-- PostgresEpssRawRepository.CreateAsync (ON CONFLICT + RETURNING), PruneAsync (PL/pgSQL)
-- PostgresEpssSignalRepository.CreateAsync, CreateBulkAsync, UpsertConfigAsync (ON CONFLICT), PruneAsync (PL/pgSQL)
-- PostgresVexCandidateStore.StoreCandidatesAsync (ON CONFLICT + enum casts), ReviewCandidateAsync (enum cast `::vex_review_action`)
-- PostgresFacetSealStore.SaveAsync (JSONB INSERT cast), PurgeOldSealsAsync (window function ROW_NUMBER OVER PARTITION BY)
-- PostgresFuncProofRepository.StoreAsync (ON CONFLICT + RETURNING), UpdateSignatureInfoAsync (NOW())
-- PostgresReachabilityDriftResultRepository.StoreAsync (multi-table transaction with ON CONFLICT)
-
-Completion criteria:
-- [x] Read methods use DbContext LINQ where possible (25 methods migrated across 6 repos)
-- [x] Write methods with PostgreSQL features remain raw SQL
-- [x] Build succeeds with 0 warnings
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-25 | Sprint created from DAL consolidation plan. | Planning |
-| 2026-02-25 | SC-113-001 DONE: 11 entity classes created. DATE columns use DateOnly. | Implementer |
-| 2026-02-25 | SC-113-002 DONE: 11 DbSets + OnModelCreating with FKs, indexes, constraints. Build 0 warnings. | Implementer |
-| 2026-02-25 | SC-113-003 DONE: 14 read methods migrated to LINQ across 3 repos. Helper row classes removed. Build clean. | Implementer |
-| 2026-02-25 | SC-113-003 updated: 11 additional reads migrated (VexCandidateStore 2, FacetSealStore 5+delete, FuncProofRepository 5). Total 25 reads across 6 repos. Build 0 warnings. | Implementer |
-
-## Decisions & Risks
-- facet_seals: No standalone migration file found; schema derived from PostgresFacetSealStore.cs INSERT SQL columns.
-- vuln_instance_triage: NOT added to ScannerDbContext (owned by TriageDbContext).
-- VexCandidate enum columns (vex_status_type, vex_justification, vex_review_action): PostgreSQL enums read as strings by Npgsql when no explicit MapEnum is configured. Read queries do not filter on enum columns, only project them. Writes stay raw SQL with `::type` casts.
-- FacetSealStore and FuncProofRepository: Use NpgsqlDataSource directly (not ScannerDataSource). Constructor signatures unchanged; DbContext created internally from opened connection with DefaultCommandTimeoutSeconds=30 and ScannerStorageDefaults.DefaultSchemaName.
-
-## Next Checkpoints
-- Test suite pass after read migration.

docs/implplan/SPRINT_20260225_114_Orchestrator_dal_ef_packrunlog_audit_reads.md

@@ -1,85 +0,0 @@
-# Sprint 20260225_114 - Orchestrator DAL EF Core Migration (PackRunLog, Audit, Ledger Reads)
-
-## Topic & Scope
-- Migrate Orchestrator repositories from raw NpgsqlCommand to EF Core LINQ where appropriate.
-- PackRunLogRepository: full rewrite (all 7 methods) to pure EF Core.
-- AuditRepository: migrate 6 read methods to EF Core; keep 3 PL/pgSQL methods (AppendAsync, VerifyChainAsync, GetSummaryAsync) as raw SQL.
-- LedgerRepository: migrate 7 read methods to EF Core; keep 3 PL/pgSQL methods (AppendAsync, VerifyChainAsync, GetSummaryAsync) as raw SQL.
-- Working directory: `src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.Infrastructure/`.
-- Expected evidence: build pass, existing tests pass.
-
-## Dependencies & Concurrency
-- Depends on existing OrchestratorDbContext with PackRunLogs, AuditEntries, RunLedgerEntries DbSets (already present).
-- Depends on existing entity models: PackRunLogEntity, AuditEntryEntity, RunLedgerEntryEntity (already present).
-- Depends on OrchestratorDbContextFactory (already present).
-- Safe to run in parallel with other module DAL sprints (Scanner, Policy, Scheduler).
-
-## Documentation Prerequisites
-- `src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.Infrastructure/EfCore/Context/OrchestratorDbContext.cs` -- model config
-- `src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.Infrastructure/Postgres/OrchestratorDbContextFactory.cs` -- factory pattern
-- `src/Orchestrator/StellaOps.Orchestrator/StellaOps.Orchestrator.Infrastructure/Postgres/PostgresArtifactRepository.cs` -- reference EF pattern
-
-## Delivery Tracker
-
-### T1 - Rewrite PostgresPackRunLogRepository to pure EF Core
-Status: DONE
-Dependency: none
-Owners: orchestrator-agent
-
-Task description:
-- Replace all 7 methods (AppendAsync, AppendBatchAsync, GetLogsAsync, GetLogStatsAsync, GetLogsByLevelAsync, SearchLogsAsync, DeleteLogsAsync) from raw NpgsqlCommand/NpgsqlBatch to EF Core LINQ.
-- Use OrchestratorDbContextFactory.Create pattern matching existing repos (PostgresArtifactRepository).
-- Map between PackRunLogEntity and PackRunLog domain record.
-- Use EF.Functions.ILike for SearchLogsAsync.
-- Use ExecuteDeleteAsync for DeleteLogsAsync.
-
-Completion criteria:
-- [x] All 7 methods migrated to EF Core
-- [x] Build succeeds with 0 errors
-
-### T2 - Migrate PostgresAuditRepository read methods to EF Core
-Status: DONE
-Dependency: none
-Owners: orchestrator-agent
-
-Task description:
-- Migrate 6 read methods (GetByIdAsync, ListAsync, GetBySequenceRangeAsync, GetLatestAsync, GetByResourceAsync, GetCountAsync) to EF Core LINQ.
-- Keep 3 PL/pgSQL methods (AppendAsync, VerifyChainAsync, GetSummaryAsync) as raw SQL -- these call PostgreSQL functions.
-- Use dynamic .Where() chaining for ListAsync and GetCountAsync filters.
-- Map between AuditEntryEntity and AuditEntry domain record.
-
-Completion criteria:
-- [x] 6 read methods migrated to EF Core
-- [x] 3 PL/pgSQL methods unchanged
-- [x] Build succeeds with 0 errors
-
-### T3 - Migrate PostgresLedgerRepository read methods to EF Core
-Status: DONE
-Dependency: none
-Owners: orchestrator-agent
-
-Task description:
-- Migrate 7 read methods (GetByIdAsync, GetByRunIdAsync, ListAsync, GetBySequenceRangeAsync, GetLatestAsync, GetBySourceAsync, GetCountAsync) to EF Core LINQ.
-- Keep 3 PL/pgSQL methods (AppendAsync, VerifyChainAsync, GetSummaryAsync) as raw SQL.
-- Preserve PostgresLedgerExportRepository and PostgresManifestRepository classes in the same file unchanged.
-- Map between RunLedgerEntryEntity and RunLedgerEntry domain record.
-
-Completion criteria:
-- [x] 7 read methods migrated to EF Core
-- [x] 3 PL/pgSQL methods unchanged
-- [x] Export and Manifest repos unchanged
-- [x] Build succeeds with 0 errors
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-25 | Sprint created; all 3 tasks completed. Build passes with 0 errors, 0 warnings. | orchestrator-agent |
-
-## Decisions & Risks
-- Decision: Keep PL/pgSQL-dependent methods (AppendAsync, VerifyChainAsync, GetSummaryAsync) as raw SQL because EF Core cannot call custom PostgreSQL functions with the same transactional semantics (sequence allocation + hash chain update in single transaction).
-- Decision: Removed dead SQL string constants from migrated repositories to reduce code surface.
-- Decision: Used same entity mapping pattern as PostgresArtifactRepository (static MapXxx methods returning domain records).
-- Risk: Compiled model (OrchestratorDbContextModel) may need regeneration if EF query shapes change at runtime. Mitigated by using DefaultSchema constant.
-
-## Next Checkpoints
-- Run Orchestrator test suite to confirm behavioral parity.

docs/implplan/SPRINT_20260225_115_Policy_dal_ef_wrapper_removal_crud_migration.md

@@ -1,86 +0,0 @@
-# Sprint 115 - Policy DAL EF Wrapper Removal & CRUD Migration
-
-## Topic & Scope
-- Migrate remaining pure-raw-SQL repositories in Policy.Persistence to EF Core.
-- GateDecisionHistoryRepository, ReplayAuditRepository: full migration from NpgsqlConnection to PolicyDbContext.
-- ExceptionRepository: migrate simple reads (GetById, GetByName, GetAll, Delete) to EF Core; keep raw SQL for complex methods (Create with RETURNING, regex-based queries, NOW() status transitions).
-- Working directory: `src/Policy/__Libraries/StellaOps.Policy.Persistence/`.
-- Expected evidence: green builds of Persistence project and Gateway/Persistence test projects.
-
-## Dependencies & Concurrency
-- PolicyDbContext already has DbSets and OnModelCreating for GateDecisionEntity, ReplayAuditEntity, ExceptionEntity.
-- PolicyDbContextFactory already exists at `Postgres/PolicyDbContextFactory.cs`.
-- No upstream sprints blocking; can run in parallel with Scanner and Orchestrator DAL sprints.
-
-## Documentation Prerequisites
-- `EfCore/Context/PolicyDbContext.cs` entity configurations.
-- `Postgres/Repositories/SnapshotRepository.cs` as EF Core reference pattern.
-- `StellaOps.Infrastructure.Postgres/Repositories/RepositoryBase.cs` for base class contract.
-
-## Delivery Tracker
-
-### T1 - Migrate GateDecisionHistoryRepository to EF Core
-Status: DONE
-Dependency: none
-Owners: Implementer
-
-Task description:
-- Rewrote all 3 methods (GetDecisionsAsync, GetDecisionByIdAsync, RecordDecisionAsync) from raw NpgsqlConnection to EF Core LINQ.
-- Changed constructor from `string connectionString` to `RepositoryBase<PolicyDataSource>` pattern matching SnapshotRepository.
-- Dynamic `.Where()` chaining for filters (gateId, bomRef, gateStatus, actor, startDate, endDate).
-- Continuation token pagination preserved with `.Skip()` + `.Take(limit + 1)`.
-- `.AsNoTracking()` for all reads.
-- Entity-to-record mapping via `MapToRecord()` helper.
-
-Completion criteria:
-- [x] All 3 methods migrated to EF Core
-- [x] Interface unchanged
-- [x] Build succeeds
-
-### T2 - Migrate ReplayAuditRepository to EF Core
-Status: DONE
-Dependency: none
-Owners: Implementer
-
-Task description:
-- Rewrote all 4 methods (RecordReplayAsync, QueryAsync, GetByIdAsync, GetMetricsAsync) from raw NpgsqlConnection to EF Core LINQ.
-- Changed constructor from `string connectionString` to `RepositoryBase<PolicyDataSource>` pattern.
-- GetMetricsAsync uses `.LongCountAsync()` for total/matches/mismatches and `.AverageAsync()` for avg duration with null-safe check.
-- Dynamic `.Where()` chaining for all filter parameters.
-
-Completion criteria:
-- [x] All 4 methods migrated to EF Core
-- [x] Interface unchanged
-- [x] Build succeeds
-
-### T3 - Migrate ExceptionRepository simple reads to EF Core
-Status: DONE
-Dependency: none
-Owners: Implementer
-
-Task description:
-- Migrated GetByIdAsync, GetByNameAsync, GetAllAsync, DeleteAsync to EF Core LINQ.
-- GetAllAsync uses `.Where()` with optional status filter + `.OrderBy().ThenBy().Skip().Take()`.
-- DeleteAsync uses `.ExecuteDeleteAsync()`.
-- Kept raw SQL for: CreateAsync (RETURNING *), GetActiveForProjectAsync (NOW()), GetActiveForRuleAsync (regex ~ operator), UpdateAsync, ApproveAsync, RevokeAsync, ExpireAsync (NOW() + status transitions).
-
-Completion criteria:
-- [x] 4 simple reads migrated to EF Core
-- [x] Complex methods preserved as raw SQL
-- [x] Interface unchanged
-- [x] Build succeeds
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-25 | Sprint created; all 3 tasks implemented. | Implementer |
-| 2026-02-25 | All builds green (Persistence, Gateway.Tests, Persistence.Tests). | Implementer |
-
-## Decisions & Risks
-- GateDecisionEntity.GateId is `required string` but original RecordDecisionAsync INSERT did not include gate_id column. Set to `string.Empty` to match original behavior where DB default would apply.
-- ExceptionRepository: regex `~` operator and `NOW()` in SQL cannot be cleanly expressed in EF LINQ; kept raw SQL for those methods per task scope.
-- Continuation token encoding (Base64 of offset long) preserved exactly to maintain API compatibility.
-
-## Next Checkpoints
-- Run integration tests when Postgres is available.
-- Register GateDecisionHistoryRepository and ReplayAuditRepository in ServiceCollectionExtensions if not already done by consuming sprint.

docs/implplan/SPRINT_20260225_116_Scheduler_dal_ef_wrapper_removal_read_migration.md

@@ -1,101 +0,0 @@
-# Sprint 20260225_116 - Scheduler DAL EF Wrapper Removal & Read Migration
-
-## Topic & Scope
-- Audit all Scheduler repositories for dead RepositoryBase inheritance and migrate remaining simple reads to EF Core.
-- Working directory: `src/Scheduler/__Libraries/StellaOps.Scheduler.Persistence/`.
-- Expected evidence: code review findings, migration diffs (if any), build pass.
-
-## Dependencies & Concurrency
-- Upstream: SchedulerDbContext with 11 DbSets and full OnModelCreating config already exists.
-- Safe to run in parallel with other module DAL sprints (Scanner, Orchestrator, Policy).
-
-## Documentation Prerequisites
-- `src/Scheduler/__Libraries/StellaOps.Scheduler.Persistence/EfCore/Context/SchedulerDbContext.cs`
-- `src/__Libraries/StellaOps.Infrastructure.Postgres/Repositories/RepositoryBase.cs`
-
-## Delivery Tracker
-
-### TASK-1 - Verify and clean MetricsRepository
-Status: DONE
-Dependency: none
-Owners: scheduler-agent
-
-Task description:
-- Review MetricsRepository for dead RepositoryBase inheritance.
-
-Completion criteria:
-- [x] Verified RepositoryBase methods used: `CreateCommand`, `AddParameter`, `AddJsonbParameter`, `QueryAsync` (for UpsertAsync, GetLatestAsync).
-- [x] EF reads already in place: `GetAsync`, `GetByTenantAsync`, `DeleteOlderThanAsync`.
-- [x] Conclusion: inheritance is NOT dead weight. No changes needed.
-
-### TASK-2 - Verify and clean WorkerRepository
-Status: DONE
-Dependency: none
-Owners: scheduler-agent
-
-Task description:
-- Review WorkerRepository for dead RepositoryBase inheritance.
-
-Completion criteria:
-- [x] Verified RepositoryBase methods used: `CreateCommand`, `AddParameter`, `AddTextArrayParameter`, `AddJsonbParameter` (for UpsertAsync, HeartbeatAsync, GetStaleWorkersAsync).
-- [x] EF reads already in place: `GetByIdAsync`, `ListAsync`, `ListByStatusAsync`, `GetByTenantIdAsync`, `SetStatusAsync`, `DeleteAsync`.
-- [x] Conclusion: inheritance is NOT dead weight. No changes needed.
-
-### TASK-3 - Verify and clean TriggerRepository
-Status: DONE
-Dependency: none
-Owners: scheduler-agent
-
-Task description:
-- Review TriggerRepository for dead RepositoryBase inheritance.
-
-Completion criteria:
-- [x] Verified RepositoryBase methods used: `CreateCommand`, `AddParameter`, `AddJsonbParameter`, `ExecuteAsync` (for CreateAsync, UpdateAsync, GetDueTriggersAsync, RecordFireAsync, RecordMisfireAsync).
-- [x] EF reads already in place: `GetByIdAsync`, `GetByNameAsync`, `ListAsync`, `SetEnabledAsync`, `DeleteAsync`.
-- [x] Conclusion: inheritance is NOT dead weight. No changes needed.
-
-### TASK-4 - Migrate JobRepository simple reads to EF Core
-Status: DONE
-Dependency: none
-Owners: scheduler-agent
-
-Task description:
-- Check if GetByIdAsync and GetByIdempotencyKeyAsync are already EF Core. If not, migrate them.
-
-Completion criteria:
-- [x] `GetByIdAsync` already uses EF Core (`dbContext.Jobs.AsNoTracking().FirstOrDefaultAsync(...)`).
-- [x] `GetByIdempotencyKeyAsync` already uses EF Core (`dbContext.Jobs.AsNoTracking().FirstOrDefaultAsync(...)`).
-- [x] All complex writes confirmed raw SQL: CreateAsync (enum cast), GetScheduledJobsAsync (HLC join), TryLeaseJobAsync, CompleteAsync, FailAsync (CASE), CancelAsync, RecoverExpiredLeasesAsync (CASE + NOW()), GetByStatusAsync (HLC join + enum cast), ExtendLeaseAsync.
-- [x] Conclusion: no migration needed. Already hybrid EF+raw SQL.
-
-### TASK-5 - Review RunRepository
-Status: DONE
-Dependency: none
-Owners: scheduler-agent
-
-Task description:
-- Evaluate RunRepository for potential EF migration of simple reads.
-
-Completion criteria:
-- [x] Confirmed: No `RunEntity` exists in SchedulerDbContext. RunRepository uses domain model `Run` (from `StellaOps.Scheduler.Models`) with JSON serialization for complex fields (Trigger, Stats, Reason, Deltas).
-- [x] `GetAsync` (simple point lookup) -- cannot migrate without entity mapping.
-- [x] `ListByStateAsync` (simple WHERE) -- cannot migrate without entity mapping.
-- [x] `ListAsync` (dynamic WHERE + cursor pagination) -- would stay raw SQL regardless.
-- [x] `InsertAsync` (ON CONFLICT DO NOTHING) -- raw SQL.
-- [x] `UpdateAsync` -- raw SQL.
-- [x] Conclusion: skip. No clean entity mapping exists; domain model uses JSON serialization that would require a new entity + value converters. Out of scope for this sprint.
-
-## Execution Log
-| Date (UTC) | Update | Owner |
-| --- | --- | --- |
-| 2026-02-25 | Sprint created. All 5 repositories audited. | scheduler-agent |
-| 2026-02-25 | All tasks DONE. All repos confirmed hybrid EF+raw SQL with justified RepositoryBase inheritance. No dead wrappers found. No migration opportunities (reads already EF where applicable; RunRepository has no entity mapping). | scheduler-agent |
-
-## Decisions & Risks
-- **Decision**: All five Scheduler repositories (Metrics, Worker, Trigger, Job, Run) actively use RepositoryBase helper methods (CreateCommand, AddParameter, AddJsonbParameter, QueryAsync, ExecuteAsync, etc.) for their raw SQL operations. Removing inheritance would require inlining all these helpers or creating a different abstraction, which provides no benefit.
-- **Decision**: RunRepository migration skipped because `Run` is a domain model with complex JSON-serialized fields (RunTrigger, RunStats, RunReason, DeltaSummary), not an EF entity. Creating a RunEntity + value converters is a separate effort if desired.
-- **Decision**: JobRepository reads (GetByIdAsync, GetByIdempotencyKeyAsync) already migrated to EF Core in a prior sprint. GetByStatusAsync stays raw SQL due to HLC join + enum cast.
-- **Risk**: None identified. Current state is clean and consistent.
-
-## Next Checkpoints
-- None. Sprint complete.

docs/implplan/SPRINT_20260225_200_Platform_gateway_deletion.md

@@ -0,0 +1,97 @@
+# 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.
+
+
+

docs/implplan/SPRINT_20260225_201_Scanner_absorb_cartographer.md

@@ -0,0 +1,138 @@
+# 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.
+
+
+

docs/implplan/SPRINT_20260225_202_BinaryIndex_absorb_symbols.md

@@ -0,0 +1,151 @@
+# 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.
+
+
+

docs/implplan/SPRINT_20260225_203_Concelier_absorb_feedser_excititor.md

@@ -0,0 +1,115 @@
+# 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 (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/`.
+- 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.
+
+

docs/implplan/SPRINT_20260225_204_Attestor_absorb_signer_provenance.md

@@ -0,0 +1,104 @@
+# 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.
+
+

docs/implplan/SPRINT_20260225_205_VexLens_absorb_vexhub.md

@@ -0,0 +1,109 @@
+# 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.
+
+

docs/implplan/SPRINT_20260225_206_Policy_absorb_unknowns.md

@@ -0,0 +1,106 @@
+# Sprint 206 - Policy Domain: Policy and Unknowns 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.
+
+## Dependencies & Concurrency
+- No upstream dependency.
+- Coordinate with Sprint 218 for final docs alignment.
+
+## Documentation Prerequisites
+- Read `docs/modules/policy/architecture.md`.
+- Read Unknowns module docs/AGENTS in current source tree.
+- 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
+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.
+
+Completion criteria:
+- [ ] UnknownsDbContext zero-entity status confirmed.
+- [ ] Policy domain schema ownership documented.
+- [ ] Absorption decision recorded.
+
+### TASK-206-002 - Consolidate Unknowns source under Policy domain module
+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.
+
+Completion criteria:
+- [ ] Unknowns source relocated under Policy domain.
+- [ ] References compile across Policy, Platform, and Scanner.
+- [ ] Legacy `src/Unknowns/` root removed.
+
+### TASK-206-003 - Remove empty UnknownsDbContext placeholder
+Status: TODO
+Dependency: TASK-206-001
+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.
+
+Completion criteria:
+- [ ] UnknownsDbContext deleted.
+- [ ] No orphaned connection strings or configuration keys.
+- [ ] Policy domain builds without the removed placeholder.
+
+### TASK-206-004 - CLI/Web/infrastructure updates, tests, and docs
+Status: TODO
+Dependency: TASK-206-002, 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.
+
+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.
+
+## 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 |
+
+## 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.
+
+## 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.
+
+

docs/implplan/SPRINT_20260225_207_Findings_absorb_riskengine_vulnexplorer.md

@@ -0,0 +1,97 @@
+# 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.
+
+
+

docs/implplan/SPRINT_20260225_208_Orchestrator_absorb_scheduler_taskrunner_packsregistry.md

@@ -0,0 +1,97 @@
+# 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.
+
+

docs/implplan/SPRINT_20260225_209_Notify_absorb_notifier.md

@@ -0,0 +1,101 @@
+# Sprint 209 - Notify: Absorb Notifier Module
+
+## 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.
+
+## Dependencies & Concurrency
+- No upstream dependencies. Can run in parallel.
+
+## Documentation Prerequisites
+- Read `docs/modules/notifier/README.md`.
+- Read `docs/modules/notify/architecture.md`.
+
+## Delivery Tracker
+
+### TASK-209-001 - Verify Notifier is purely a host
+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.
+
+Completion criteria:
+- [ ] Notifier confirmed as pure host
+- [ ] No unique logic identified
+
+### TASK-209-002 - Move Notifier into Notify
+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.
+
+Completion criteria:
+- [ ] Both projects moved
+- [ ] Notify solution includes Notifier
+- [ ] Old directory removed
+
+### TASK-209-003 - Update Docker, CI, build, and test
+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`.
+
+Completion criteria:
+- [ ] Docker and CI updated
+- [ ] All builds and tests pass
+
+### TASK-209-004 - Update documentation and CLI/Web references
+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.
+
+Completion criteria:
+- [ ] Notifier docs archived.
+- [ ] Notify architecture updated.
+- [ ] Web notifier references validated/updated.
+- [ ] CLI notifier references validated/updated.
+- [ ] Notifier API path compatibility verified.
+## 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: Revisit the 2025-11-02 separation decision. If offline kit parity still requires separate packaging, document that in Notify architecture and keep containers separate.
+
+## Next Checkpoints
+- Estimate: 1 session (2 projects only).
+
+
+

docs/implplan/SPRINT_20260225_210_Timeline_absorb_timelineindexer.md

@@ -0,0 +1,98 @@
+# 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.
+
+
+

docs/implplan/SPRINT_20260225_211_ExportCenter_absorb_mirror_airgap.md

@@ -0,0 +1,111 @@
+# Sprint 211 - Offline Distribution Domain: ExportCenter, Mirror, and AirGap
+
+## 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.
+
+## Dependencies & Concurrency
+- No upstream dependency.
+- Coordinate with Sprint 203 if shared export/advisory payload contracts change.
+
+## 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
+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.
+
+Completion criteria:
+- [ ] Offline domain schema ownership documented.
+- [ ] Zero-collision confirmation recorded.
+- [ ] DbContext merge plan approved.
+- [ ] File-based versus persisted boundary documented.
+
+### TASK-211-002 - Consolidate source layout under ExportCenter domain
+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.
+
+Completion criteria:
+- [ ] Source trees relocated under ExportCenter domain.
+- [ ] References compile after move.
+- [ ] Legacy roots removed.
+
+### TASK-211-003 - Merge offline distribution DbContexts and regenerate compiled models
+Status: TODO
+Dependency: TASK-211-001
+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.
+
+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.
+
+### TASK-211-004 - CLI/Web/infrastructure updates, tests, and docs
+Status: TODO
+Dependency: TASK-211-002, 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.
+
+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.
+
+## 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 |
+
+## 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).
+
+## 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.
+
+

docs/implplan/SPRINT_20260225_212_Tools_absorb_bench_verifier_sdk_devportal.md

@@ -0,0 +1,130 @@
+# 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.
+

docs/implplan/SPRINT_20260225_213_AdvisoryAI_absorb_opsmemory.md

@@ -0,0 +1,105 @@
+# 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.
+
+
+
+

docs/implplan/SPRINT_20260225_214_Integrations_absorb_extensions.md

@@ -0,0 +1,119 @@
+# 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.
+
+
+

docs/implplan/SPRINT_20260225_215_Signals_absorb_runtimeinstrumentation.md

@@ -0,0 +1,128 @@
+# 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.
+
+
+

docs/implplan/SPRINT_20260225_216_Authority_absorb_issuerdirectory.md

@@ -0,0 +1,108 @@
+# 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).
+- Coordinate with Sprint 205 (VEX trust ingest) for client compatibility.
+
+## 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.
+
+

docs/implplan/SPRINT_20260225_217_Platform_orphan_library_cleanup.md

@@ -0,0 +1,127 @@
+# 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).
+

docs/implplan/SPRINT_20260225_218_DOCS_consolidation_final_update.md

@@ -0,0 +1,122 @@
+# Sprint 218 - DOCS: Domain-First Consolidation and DB Merge 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.
+- 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.
+
+## 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.
+
+## 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.
+
+## Delivery Tracker
+
+### TASK-218-001 - Audit docs against domain-first source structure
+Status: TODO
+Dependency: Consolidation sprints DONE
+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.
+
+Completion criteria:
+- [ ] Active module docs match current domain ownership.
+- [ ] Archived standalone module docs are in `docs-archived/modules/`.
+- [ ] No stale module-structure claims remain.
+
+### TASK-218-002 - Publish domain DB merge ledger and outcomes
+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.
+
+Completion criteria:
+- [ ] Domain DB merge ledger published.
+- [ ] Each domain sprint has linked evidence.
+- [ ] Rollback window state documented per domain.
+
+### TASK-218-003 - Update CLAUDE.md and architecture docs to domain paradigm
+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.
+
+Completion criteria:
+- [ ] CLAUDE.md reflects domain-first structure.
+- [ ] Architecture docs reflect domain ownership and service boundaries.
+- [ ] Module/domain count claims are accurate.
+
+### TASK-218-004 - Validate CLI/Web and infra documentation references
+Status: TODO
+Dependency: TASK-218-001
+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.
+
+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.
+
+## 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 |
+
+## 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.
+
+## 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.
+
+

docs/implplan/SPRINT_20260225_220_Scanner_absorb_sbomservice.md

@@ -0,0 +1,133 @@
+# 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).

docs/implplan/SPRINT_20260225_221_Orchestrator_domain_rename.md

@@ -0,0 +1,192 @@
+# 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.
+