docs(audit): roadmap corrections after M5

M6 head records M5 realities:
- IOptionsMonitor hot-reload pattern verified; M6 retention config can
  reuse.
- AuditRedactionFailure counter site-only in M5; M6 wires central side.
- Filter integration is at 3 writer entry points; purge actor doesn't
  emit so no filter integration needed.
- SwitchOutPartitionAsync drop-and-rebuild dance required (M1 reality
  + M6-T4 already documents it).
- M6 should land the real ISiteStreamAuditClient (Option A) so push
  telemetry leaves NoOp behind.
This commit is contained in:
Joseph Doherty
2026-05-20 17:43:44 -04:00
parent adc490b690
commit db05af897e

View File

@@ -1063,6 +1063,14 @@ The design for both is merged on `main` (`alog.md` cached-call tracking section;
## M6 — Reconciliation, purge, partition maintenance, health metrics ## M6 — Reconciliation, purge, partition maintenance, health metrics
> **M5 realities to honor:**
> - **IOptionsMonitor pattern** works for hot reload (M5 verified via tests). M6's retention/partition cadence options can use the same pattern.
> - **AuditRedactionFailure counter** is wired SITE-ONLY (M5 Bundle C deferred central wiring here). M6 ships the central wiring as part of "all five new health metrics live".
> - **Filter pattern** is integrated at the THREE writer entry points (FallbackAuditWriter, CentralAuditWriter, AuditLogIngestActor). M6's AuditLogPurgeActor does NOT emit events; it only reads + partitions, so no filter integration required.
> - **`SwitchOutPartitionAsync` blocked by UX_AuditLog_EventId**: per the M1 reality note, M6-T4 must replace the M1 NotSupportedException stub with the drop-and-rebuild dance around the non-aligned unique index (already in the roadmap M6-T4 section).
> - **Partition function pre-seeded with 24 monthly boundaries** (Jan 2026 Dec 2027). M6-T5's partition maintenance must SPLIT a new boundary for the upcoming month.
> - **Site→central gRPC client still NoOpSiteStreamAuditClient**: M6's `SiteAuditReconciliationActor` is naturally the first central component that needs to pull from sites; alternatively, the production push path can ship here. EITHER (a) M6 implements the real `ISiteStreamAuditClient` to enable push telemetry (and reconciliation pulls leverage it bidirectionally), OR (b) M6 implements ONLY reconciliation pull (push stays NoOp until a later milestone). Recommended (a) — push is more general and reconciliation is the catch-up.
**Goal:** Self-healing telemetry, monthly partition rollover, daily purge, all five new health metrics live and feeding the existing health-report pipeline. **Goal:** Self-healing telemetry, monthly partition rollover, daily purge, all five new health metrics live and feeding the existing health-report pipeline.
**Affected projects:** `AuditLog` (3 new actors: `SiteAuditReconciliationActor`, `AuditLogPurgeActor`, partition-maintenance worker), `Communication` (the `PullAuditEvents` RPC), `HealthMonitoring` (5 new metrics), `ConfigurationDatabase` (partition-roll-forward SQL helper). **Affected projects:** `AuditLog` (3 new actors: `SiteAuditReconciliationActor`, `AuditLogPurgeActor`, partition-maintenance worker), `Communication` (the `PullAuditEvents` RPC), `HealthMonitoring` (5 new metrics), `ConfigurationDatabase` (partition-roll-forward SQL helper).