Update tickets

tickets/019-ntfy-sink-delivery.md

@@ -0,0 +1,44 @@
+# 019 — Ntfy sink delivery
+
+## Summary
+
+Deliver a fired alert ([018](018-alert-trigger-evaluation.md)) to the
+[ntfy](https://ntfy.sh) topic configured on its `AlertRule` ([017](017-ntfy-alerts.md)):
+a plain HTTP POST of the notification body to `{server}/{topic}`, no SDK
+needed.
+
+## Scope
+
+- A small async sender: `POST {server}/{topic}` with the alert's message as
+  the request body (ntfy's plain-text publish API — no auth, no extra
+  dependency beyond an HTTP client ottyl can already reach for, or a minimal
+  one if none exists yet).
+- Message content: rule name plus enough context to be useful (matched log
+  line for Immediate/New value, current value vs. threshold for
+  Threshold/Ratio).
+- Delivery runs off the ingest hot path — spawn it (e.g.
+  `tokio::spawn`/an mpsc queue) so a slow or unreachable ntfy server never
+  blocks log ingestion.
+- Failure handling: log the error to stderr and drop the notification — no
+  retry queue or backoff for this ticket (matches the project's existing
+  "best-effort, log and move on" style, e.g. `remove_css`'s file-removal
+  fallback).
+
+## Acceptance criteria
+
+- A fired alert results in exactly one HTTP POST to the rule's configured
+  `{server}/{topic}`.
+- Ntfy being unreachable/erroring is logged but does not panic, block
+  ingestion, or crash the process.
+- Covered by a test against a local mock HTTP server asserting the request
+  path/body.
+
+## Depends on
+
+- [017 — Alert definitions & settings persistence](017-ntfy-alerts.md)
+- [018 — Alert trigger evaluation](018-alert-trigger-evaluation.md)
+
+## Depended on by
+
+- [020 — Alerts webapp UI](020-alerts-webapp-ui.md) (for a "send test
+  notification" action)