3.5 KiB
| id | date | status | supersedes | superseded-by | affected-paths | affected-components | migration_confidence | migration_source |
|---|---|---|---|---|---|---|---|---|
| 0024 | 2026-07-10 | Accepted | medium | docs/memory-system/03-architecture-decisions.md### ADR-024 — Apprise replaces Pushover as the notification transport (supersedes the Pushover-direct plan) |
0024 — Apprise replaces Pushover as the notification transport (supersedes the Pushover-direct plan)
Context
The planka-api gem's tick/digest delivery was specified as Pushover-direct (PUSHOVER_API_TOKEN/PUSHOVER_USER_KEY, falls back to stdout when unset — see the gem's docs/issues/README.md and the P0 board card "Provision Pushover digest credentials"). Separately, Planka itself ships Apprise as a notification integration, and the user's real need is multi-service: Discord, Telegram, Bark, Home Assistant, Gnome desktop, Zoom, and Pushover are all in active use, and any AI agent (Claude Code, Hermes) on any machine should be able to notify on whichever service fits the moment.
Decision
(1) Apprise becomes the single notification transport: an Apprise API server deployed as a docker-compose service on the OVH production server, following the established service pattern. (2) This iteration's scope is deliberately minimal: stand up the server and swap the gem's Pushover P0 for a minimal Apprise client (one notify call against the API) — the pilot's critical path does not grow. (3) The expansion is captured as P2/P3 backlog cards, to be built soon: an Apprise client gem + CLI wrapper, an os-notify cc-os plugin so any session can route notifications by service/need (per ADR-023's ecosystem framing, notifications are cross-plugin infrastructure and belong in cc-os), multi-service routing config, and wiring Planka's native Apprise integration to the same server.
- Rationale: One integration covers N services — adding a service becomes an Apprise URL/tag config change, not new code; service selection becomes a runtime parameter, which is exactly the "tell the AI where to notify" requirement. Planka speaking Apprise natively means board events and agent-initiated notifications converge on one server. The minimal client is less work than the Pushover gem would have been (Apprise absorbs per-service quirks). Notification-blindness policy (pull beats push, silent days stay silent) is unchanged — this ADR changes the transport, not the policy.
Consequences
Apprise replaces the originally planned Pushover-direct integration as the single notification transport, deployed as an Apprise API server so any service (Discord, Telegram, Bark, Home Assistant, etc.) can be targeted via configuration rather than new code, with Planka's native Apprise support converging on the same server. This iteration's scope stays minimal (server + a minimal Apprise client swapped in for the planned Pushover gem code), with a fuller client gem, CLI wrapper, and an os-notify plugin captured as later backlog work; the underlying notification-blindness policy is unchanged.
Alternatives rejected
Pushover gem as planned — single-service dead end; every future service would be a new integration. Deferring Apprise entirely — the server + minimal client is comparable effort to the Pushover path, so there is no cheaper interim.
- Cross-references: ADR-023 (os-backlog / ecosystem role); vault note
vault-backlog-pilot-plan(notification policy v2); gem repo~/dev/ruby-gems/planka(tick delivery); Apprise docs https://appriseit.com/.