mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-23 03:33:53 +00:00
rcourtman
4dff26f728
The reporting feature now ships across two surfaces (PDF/CSV export and pulse_summarize chat tool) and three modes (single-resource, fleet, summarize). Without usage telemetry we can't tell whether the work earns its place — operator demand, AI-vs-heuristic adoption, range/format preferences are all invisible. Stops further feature investment from being pure speculation. Three new info-level log events, structured so an agent can grep transcripts and group by dimension without a separate metrics pipeline (matches the "agent owns ops analysis, human gets outcomes" posture in MEMORY.md): reporting.single.generated — single-resource PDF/CSV reporting.fleet.generated — multi-resource fleet PDF/CSV reporting.summarize.invoked — pulse_summarize chat tool (both modes) Common dimensions: org_id, format/action, range, ai_configured, findings_configured, window_start/end. Single-resource adds resource_type + metric_type + bytes; fleet adds resource_count + bytes; summarize adds resource_type + resource_count (fleet mode) + narrative_source (so we can audit AI-fallback rate). Includes rangeLabel() helper that maps a window to the canonical catalog range token (24h/7d/30d) with a 1h tolerance, falling back to "<hours>h" so non-standard windows still group. Tested. TestReportingTelemetryEventNames pins the canonical event names as a contract — an agent grepping logs depends on them being stable; changing them silently would break audit tooling on the consumer side. The reporting engine already logs the resolved narrative source (heuristic/ai) at debug level via the existing "Generating report" line, useful for diagnosing why a specific report fell back. Kept at debug; the new info-level events cover the operator surface.