One-shot timer notifications fire 'ok' but deliver nothing on the web client

**Filed as:** roadmap item, tag `bug` **Reporter:** Luigi Messina (via assistant), web client, Europe/Rome **Date observed:** Sep 28, 2026 ## Summary One-shot scheduled notifications (created with `fire_at` + notify mode) are reported by the scheduler as `fired` / `ok`, but never surface anywhere the user can see them — no Home feed entry, no push, no banner. The failure is silent from every angle: the scheduler believes it succeeded, and the user gets nothing. ## Environment - Platform: Vellum - Interface: **web client** (reproduced on Android browser) - No Vellum desktop app installed - No messaging channel configured (no Telegram/Slack) ## Steps to reproduce 1. Create a one-shot notification with `fire_at` set to a known time (tested: 15 min, then 2 min — "Timer test 2min"). 2. Wait for `fire_at`. 3. `schedule_list` → task reports status `fired`, result `ok`. 4. `assistant notifications list` → nothing for that task. Home feed → nothing. ## Observed - No feed item, no push, no visual indicator. Completely silent. - The task is recorded as successful, so nothing retries and nothing warns. ## Expected - The notification surfaces in the Home feed and triggers push where a push target exists. ## Evidence it's backend-side, not client config The unreliable part is the *timer-created* notification. A notification sent directly via `assistant notifications send` delivers promptly on the same client, same session — verified repeatedly on Sep 28 (multiple sends, all arrived). So the delivery path itself works; the one-shot creation/fire path is what drops the record. ## Practical impact This breaks the most basic assistant promise — "remind me at X". A user with no push target can't tell a broken reminder from one they slept through, and has no error to report. Silent-success is the worst possible failure mode here. ## Asks 1. Fix the one-shot fire path so the notification record is actually created/delivered; if the user has no reachable delivery target, **fail loudly** rather than marking `ok`. 2. If web-client notifications intentionally require a configured push target, say so in the UI when a timer is created, instead of accepting it silently. 3. A `notifications list` filter for scheduled/timer-originated items would make this diagnosable without digging through the scheduler. ## Workaround in use `assistant notifications send` covers anything time-critical, but it has to be sent *by hand at the right moment* — which defeats the point of a timer.