mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-10 18:45:53 +00:00
rcourtman
5500365291
A three-week decline in investigations/new_findings (7.2% to 5.0%) looked like a Patrol regression. It is not one. The ratio is not a rate at all: the two counters come from different stores, cover different spans, and are drawn from populations that barely overlap. new_findings_30d sums run.NewFindings over history.Runs, which SavePatrolRunHistory caps at MaxPatrolRunHistory, so it covers at most the last hundred runs rather than thirty days. investigations_30d instead scans the current findings store and counts surviving finding records investigated in-window, including findings created before it, which is how the paid cohort read 128.57% in the week to 2026-08-25. Finding ShouldInvestigate returns false at monitor autonomy and effective autonomy is licence-gated, so free installs produced 4384 findings and 1 investigation while 67 paid installs produced 242. The decline was composition: flat in version-stable installs, and fleet investigations rose once the single install that swung the total by 38 was excluded. Finding-detection code is identical between v6.3.2 and v6.4.1. The new test pins the asymmetry behind the bad denominator. Its twin already asserts that runs_30d ignores the history cap after 63c40ebe5e; nothing asserted that the findings loop immediately below it does not, so the truncation could regress or be mistaken for a thirty-day total unnoticed. Fixing it needs a per-day findings tally alongside DailyRuns, which the coverage gap tracks as its own slice.