mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-10 10:35:51 +00:00
rcourtman
54a312bebd
Six of the eight Pro-exclusive features had no telemetry field at all, so there was no way to answer whether RBAC, audit logging, scheduled reporting, agent profiles, alert-triggered AI, or Kubernetes AI were being used by the installs paying for them. Schema v6 adds nine content-free adoption signals: alert_ai_enabled AIConfig.IsAlertTriggeredAnalysisEnabled() rbac_custom_roles non-built-in roles, per org rbac_user_assignments user-to-role assignments, per org audit_logging_persistent a persistent audit store is active, not console audit_events_30d audit events retained inside the window report_schedules configured scheduled reports report_schedules_enabled scheduled reports switched on report_schedules_run_30d schedules whose last run falls inside the window agent_profiles configured agent profiles Counts only. Role names, permissions, usernames, schedule names, delivery recipients, report scope, profile names, and every audit event field stay on the install. kubernetes_ai needs no field of its own: it is derivable at read time from alert_ai_enabled combined with the existing kubernetes_clusters count, and a dedicated field would be redundant. Config-sourced signals are read through applyLicensedFeatureConfigSnapshot; RBAC and audit live behind the router and are read through Router.ApplyLicensedFeatureTelemetrySnapshot. The RBAC read goes through a new TenantRBACProvider.PeekManager so a background telemetry read can never provision an RBAC store for an org that has never used RBAC. Also removes pulse_intelligence_patrol_autofixes_30d and the AutoFixCount field behind it. patrol_run.go hardcoded AutoFixCount to 0 and no increment site existed anywhere in the tree, so the counter was zero in all 233,364 retained production pings. That was a wiring bug, not evidence that nobody uses Patrol fixes; governed fixes are delivered through the approved-action pipeline, which is already instrumented. The field was plumbed through run records, history persistence, the Assistant handoff, and telemetry while being structurally incapable of holding a non-zero value. Verified end to end against a running install rather than only in unit tests, which is precisely the check the autofix counter never had: seeding three report schedules (two enabled, one last run inside the window) and two agent profiles produced report_schedules 3, report_schedules_enabled 2, report_schedules_run_30d 1, agent_profiles 2 in the Settings telemetry preview, and signing in moved audit_events_30d to 1. The private receiver landed first in pulse-pro 78ff7dd so the new fields are accepted on arrival.