With rafa

The add-on

rafa's repository plans an addons/ folder for modules rafa does not bundle (rafa#1257, add-ons in their own folder). Each add-on is published on its own. ned stays its own repository; the add-on is the bridge.

rafa-notifications would listen to a run's events and hand each one to ned as one message, with source: rafa. The default mapping, decided for the spec:

rafa event	ned kind	severity	priority
halt	alert	error	5
error	alert	error	5
task-blocked	alert	warn	4
decision-needed	alert	warn	4
pr	notice		3

Your ned routes then decide where each one goes. A send would never hold up the loop: it runs in its own queue with a timeout, and a provider that fails is logged once per run.

One person: a phone that rings for what matters

This is the spec's example: every message reaches a Telegram chat, and only priority 4 and up rings a phone through ntfy, so a halt or a decision rings and a pull request does not.

import { defineConfig, defaults } from '@open-tomato/ned/config'

export default defineConfig([
  defaults,
  {
    providers: {
      chat: { use: 'telegram', tokenSecret: 'ned.telegram.token', chatId: '123456789' },
      ring: { use: 'ntfy', topicSecret: 'ned.ntfy.topic' },
    },
    routes: {
      everything: { kind: '*', to: ['chat'] },
      urgent: { kind: 'alert', minPriority: 4, to: ['ring'] },
    },
  },
])

[verify: not run; the ntfy provider spec (ned#10) and this example name the topic's secret differently, and the key is not decided.]

With no ned config at all, a run would log one line saying nothing is routed, send nothing, and carry on.

A team

A team would route alerts to a shared chat and notices to a file journal, with the same add-on and a different ned config. [TBD: a team config example; the spec gives the use case without one.]