Push notifications + one-tap unblock (ntfy/Telegram)

[bborn]

What

A first-class push notifier for TaskYou's weakest spot: getting notified — and able to act — when a task needs you, away from the machine. Borrows herdr's mobile story (ntfy push + one-tap action).

Pushes fire on task lifecycle events and let you resume a blocked agent with one tap from your phone.

How it works

• internal/notify — a provider-agnostic Notifier with two providers:
  • ntfy (simplest): JSON publish with structured action buttons.
  • Telegram (optional second provider): inline deep-link buttons.
• No parallel path. It plugs into the existing events.Emitter through a small Notifier interface. Every mutation path already routes through that emitter (executor, MCP taskyou_needs_input/taskyou_complete, CLI, TUI), so all of them produce pushes. Notifications run on the emitter's wait group, so short-lived CLI/MCP commands flush them before exit.
• OFF by default — nothing is sent unless notify_enabled=true and a provider is configured. Settings are read live from the DB (no restart).

Events → pushes

Event	Push
task.blocked (incl. taskyou_needs_input)	🔔 Needs input + one-tap reply action
task.auth_required	🔐 Auth required + one-tap reply action
task.completed	✅ Completed
task.failed	❌ Failed

Body carries task title + project + a short reason (the reason falls back to the latest taskyou_needs_input question for a meaningful message).

One-tap unblock

needs-input / auth-required pushes carry an ntfy http action that POSTs to the existing POST /api/tasks/{id}/input endpoint with a canned reply (default "continue"), which tmux send-keys into the executor pane and resumes the agent. Plus an "Open task" deep link to type a custom reply. Action links use notify_base_url (falls back to http://localhost:<http_api_port>).

Config (ty settings)

notify_enabled, notify_base_url, notify_unblock_reply, notify_ntfy_server, notify_ntfy_topic, notify_ntfy_token (secret), notify_telegram_token (secret), notify_telegram_chat_id. Token keys are hidden from ty settings and the settings API. Documented in docs/notifications.md + README.

Tests

• Provider unit tests (ntfy payload + action assembly with auth, Telegram deep-link buttons).
• Event allow-list filtering, default-off behavior, reason enrichment, base-URL fallback.
• End-to-end through the real wiring: db.UpdateTaskStatus(blocked) → events.Emitter → notify → HTTP publish, asserting the action targets POST /api/tasks/{id}/input.

go build ./..., go test, and golangci-lint run (v2.8.0) pass on all touched packages.

Acceptance check

• ✅ Blocking a task / taskyou_needs_input delivers a push within seconds (verified end-to-end in tests through the real emitter path).
• ✅ The push's tap action hits the existing input API that resumes the agent (POST /api/tasks/{id}/input → tmux send-keys, the same endpoint ty-web already uses).
• ✅ Completed/failed pushes work; config documented; tests for the notifier + event wiring.

Follow-ups / notes

• Telegram can't POST from inline buttons, so it gets an "Open task" deep link rather than a true one-tap reply — ntfy is the recommended provider for one-tap unblock.
• For phone access, the daemon HTTP API must be reachable (VPN/tailnet/tunnel); notify_base_url points at that reachable origin.

🤖 Generated with Claude Code

[bborn]

Closing in favor of #614, which is the broader feature (phone-first mobile console + push notifications). The two unique wins from this PR — the one-tap ntfy action button (POST to /api/tasks/{id}/input) and the CLI-exit delivery race fix — have been ported onto #614 in commit e0a1894. Consolidating onto one notifier avoids two parallel implementations. See #614 (comment)