fix: activation was never sent on the launch that shows the disclosure

[JasonYeYuhe]

Why this is urgent

The v1.45 activation counter could not fire on a first launch. It is the counter the whole release exists to provide, and it would have made the first read of the funnel wrong — in the pessimistic direction, which is the reading that would have sent us rebuilding onboarding.

Found while doing the P0 from the v1.46 plan: prove the counter before reading any number.

What happened

AnonymousTelemetryCoordinator subscribes to ProviderState.$providers at launch. On the first non-empty emission it called recordFirstProviderDetectedIfNeeded() — correctly refused, because maySend requires hasSeenDisclosure and the disclosure card lives inside the lazily-built MenuBarExtra. Nothing was sent; the persisted activationReported correctly stayed false.

But the in-process latch activationSent was set on entry, before the call. It recorded that the coordinator had tried, not that it had succeeded:

guard !activationSent else { return }
activationSent = true                                    // <- set against a refusal
Task { await telemetry.recordFirstProviderDetectedIfNeeded() }

So when the user opened the menu and tapped "Got it", disclosureAcknowledged called back into reportActivation() and returned at the stale latch. The Combine sink could not rescue it either — removeDuplicates() stays latched on true while the list stays non-empty.

Activation therefore slipped to a later process launch, and was lost entirely for anyone who uninstalled before one. For an always-running menu bar app that can be days.

It hits the v1.44 → v1.45 upgrade wave hardest — their providers are already detected at launch, hours before they ever open the menu — which is exactly the population dominating the first days of v1.45 data. disclosureAcknowledged's documented purpose ("if a provider was already found while the card was up, that counts too") was dead code in the scenario it was written for.

The fix

recordInstallIfNeeded / recordFirstProviderDetectedIfNeeded now return whether the fact is durably recorded, and the coordinator latches on that result instead of on the attempt. A refusal stays retryable within the same launch.

Why it shipped — and why that is also fixed

The coordinator lived in the app target, which has no test bundle. Nothing could reach it, so ProviderPublisherSubscribeSemanticsTests re-implemented its Combine chain and tested the copy. The copy was faithful and passed — the defect was in the latch around the chain, which the copy did not have. Testing a replica cannot find that class of bug.

So the coordinator moves into CLIPulseCore (it already depended on nothing else) and AnonymousTelemetryCoordinatorTests drives the real object: real subscription, real latch, real actor. 4 pbxproj references removed; xcodebuild -configuration Release confirms the app still links it.

Verification

• Negative control — the new guard was proven to fire. Reverting only the latch makes test_activationIsSentOnTheLaunchTheDisclosureIsAcknowledged fail 0 != 1, reproducing the shipped bug.
• Runtime, on the notarized DEVID 1.45.0 DMG installed on a Mac with real CLI history, against production: disclosure gate holds (nothing sent pre-acknowledgement), then install and first_provider_detected both land — channel=devid, app_version=1.45.0. This is the P0 deliverable: the counter is alive.
• swift test --package-path "CLI Pulse Bar/CLIPulseCore" — 2662 passed, 0 failures.
• xcodebuild -scheme "CLI Pulse Bar" -configuration Release — BUILD SUCCEEDED.
• ci_check_rpc_contract.py and check_migration_numbers.sh — pass. No schema change; no payload shape change.

Also in here

Corrects a comment in the sibling test claiming the second activation edge is "guarded downstream by the persisted activation flag". It is not — the in-process latch is hit first and the actor is never reached. That belief was load-bearing and wrong.

Not in here

Two smaller findings from the same audit, deliberately left for separate PRs so this one stays reviewable: the disclosure card's toggle reads "on" while privacy.localOnlyMode is silently forcing telemetry off, and the RPC's 20k/day ceiling returns 204 so the client marks the event reported forever.

🤖 Generated with Claude Code