Skip to content
HUEHUE Docs

HUE-051 — ADR: choose notification gateways, phone attention surface and delivery privacy

Canonical source: docs/roadmap/issues.json · HUE-051

Specification status: TBD · Readiness: agent:ready

Goal

Section titled “Goal”

Resolve the local and phone notification architecture without making a HUE cloud account mandatory or leaking sensitive task content.

Scope

Section titled “Scope”
  • Compare native OS notifications and sound APIs on the reference desktop platform
  • Compare native/companion push, PWA web push, self-hosted or encrypted relay, Telegram and email fallback
  • Define endpoint registration, authenticated deep links, lock-screen privacy and channel acknowledgement semantics
  • Define durable queue, deduplication, retry, expiry, quiet-hours and operating-cost constraints
  • Choose the alpha phone attention surface and document migration/fallback paths

Acceptance criteria

Section titled “Acceptance criteria”
  • ADR resolves TBD-013 and the alpha portion of TBD-014, explicitly accounting for TBD-017
  • At least one local desktop/sound spike and one phone-delivery spike produce measured evidence
  • No-cloud local mode and a secure opt-in phone path are both preserved
  • Payload minimization, token storage, device revocation, deep-link authentication and receipts are specified
  • The chosen path distinguishes queued, accepted, displayed/delivered, failed, expired, read and acted without fabricated certainty

Dependencies

Section titled “Dependencies”
  • HUE-003
  • HUE-005

Non-goals

Section titled “Non-goals”
  • Implement production notification delivery
  • Deliver full mobile feature parity

Product contract

Section titled “Product contract”

Implementation handoff requirements

Section titled “Implementation handoff requirements”
  • Preserve the documented security, project, memory and event boundaries.
  • Add or update automated tests for every observable acceptance criterion.
  • Provide real verification output; do not rely on a worker/agent self-report.
  • Update only the exact documentation sections whose status changed.
  • Include screenshots or a recording for user-interface changes.
  • Include migration, rollback and recovery notes for data/state changes.
  • Link the pull request to this issue with Closes #<issue-number>.