e0170c2536
The shared-metrics doc states that a future remote exporter 'must not reuse the persistent local identifier by default' and 'requires a separate product and privacy decision covering consent, identity scope, rotation or keyed pseudonymization, reset behavior, retention, and deletion'. That exporter is now being built. Appendix A answers each of those six items before any code lands, so the reasoning is reviewable on its own and survives the implementation: - consent is a separate opt-in from collection, gated on the PERIOD a package covers rather than when it was created (a period is split across packages made on different days, so a created_at gate would send a period's tail while dropping its head and silently undercount the first day) - the transmitted identifier is HMAC-SHA256(local-only salt, install_id), never install_id itself - the salt rotates every 30 days - reset gives a new remote identity but cannot unsend - local retention is unchanged; send state does not extend it - there is no self-service remote deletion, and the user -> derived-id lookup that would enable one is deliberately not built A.7 additionally records what the outbox directory IS (the user's local history, not a send queue) because misreading it would have led to deleting user data on acknowledgement.