vaspian
General Vaspian catch-all / legacy default for the ntfy-expert skill
Vaspian catch-all. The general-purpose work topic — one-off publishes and apps that don't merit their own scoped topic.
ntfy.sh/vaspian · added 2026-05-13
Publishers
Every code path / config block that produces messages on this topic today. If you wire a new publisher, add it here.
Tommy is the Zoho ticket classifier + AI review workflow. The poller runs on a configurable cadence, pulls new tickets from Zoho, runs the pre-filter classifier (claude-haiku-4-5) + reviewer agent, and stages anything that needs a human read. At the end of each cycle, if any new tickets landed in the pending queue AND a topic is configured, it POSTs to ntfy.sh with title 'Tommy: pending review' and body 'N new ticket(s) ready for review'. Best-effort — failures are logged, not raised, so a broken ntfy doesn't break the poll. Topic + event filter are read live from the in-app config store each cycle (no restart needed to change them). Default topic is `vaspian`; default ntfy_on filter is [new_pending, budget_alert, integration_error] — but right now the notify() call sites only fire on new_pending, so the other two values are configured-but-aspirational.
- · new_pending — at the end of any poll cycle that created ≥1 new pending-review ticket (only event currently emitted)
- · budget_alert — configured in defaults; would fire when weekly Claude-API spend crosses one of the budget_alert_thresholds (default 80% and 100% of the weekly budget). Not yet wired in code.
- · integration_error — configured in defaults; would fire when a Zoho / Anthropic / Brevo call errors during a cycle. Not yet wired in code.
Synthetic is the scenario-driven call-quality + TTS-QA monitor. It schedules synthetic scenarios (real outbound calls, transcription, scoring), evaluates results against per-scenario thresholds, and dispatches alerts on three conditions. There's a built-in ntfy dispatch path: if NTFY_TOPIC is set in the synthetic deployment's env, seed.py registers a `ntfy` AlertChannel with min_severity WARNING, and the post-run hook publishes via NtfyClient on every alert. NTFY_TOPIC is currently unset in deployment, so the channel is registered conceptually but no messages flow. Documented here so the wiring is remembered when the env var flips on — easiest target topic is `vaspian` (or spin up a scoped `vaspian-synthetic`).
- · Capable: THRESHOLD — N consecutive failed runs for a scenario (severity CRITICAL → priority high)
- · Capable: RECOVERY — scenario returns to healthy thresholds (severity WARNING → priority default)
- · Capable: DRIFT — rolling 7-day WER mean exceeds baseline + k×σ (severity WARNING → priority default)
- · Currently: nothing — NTFY_TOPIC unset in deployment env
The general-purpose default topic when no scoped topic fits. Used for one-off pings: 'deploy finished', 'cron job done', 'reminder to check X' — anything you want on your phone without standing up a dedicated topic.
How priorities are assigned
Mixed — Tommy uses default (3), Synthetic would promote CRITICAL to high (4), manual publishes are whatever the sender chooses. If a class of message starts arriving regularly at high priority, that's a signal to spin up a scoped topic (vaspian-<area>) and move it.
Example payloads
What an alert on this topic actually looks like on a phone.
3 new ticket(s) ready for review Notes
- Prefer a scoped topic (vaspian-<area>) for any new production alert source where the surface is well-defined. `vaspian` stays as the low-volume catch-all so the scoped topics carry meaning.
- Globally namespaced on ntfy.sh — short name, no entropy. Anyone who guesses 'vaspian' can read everything published here. Don't put anything sensitive in the body.
vaspian on server ntfy.sh.