@flowdular/sdk 0.2.4 → 0.3.1

package/modules/metering/translations/pl.json

@@ -0,0 +1,68 @@
+{
+	"navigation.usage": "Zużycie",
+	"navigation.usageDescription": "Co ten obszar roboczy zużył w tym miesiącu, licznik po liczniku.",
+	"navigation.limits": "Limity",
+	"navigation.limitsDescription": "Miesięczne pułapy ustawione dla tego obszaru roboczego przez operatora wdrożenia.",
+	"common.administration": "Administracja",
+	"common.refresh": "Odśwież",
+	"common.refreshing": "Odświeżanie…",
+	"common.filters": "Filtry",
+	"common.accessDenied": "Brak dostępu",
+	"common.notYet": "Jeszcze nie",
+	"kind.cumulative": "Sumaryczny",
+	"kind.gauge": "Wskaźnikowy",
+	"usage.title": "Zużycie",
+	"usage.description": "Każdy licznik zgłoszony przez moduł dla tego obszaru roboczego, z sumą tego miesiąca w UTC.",
+	"usage.denied": "Potrzebujesz uprawnienia do zużycia, aby zobaczyć, co zużył ten obszar roboczy.",
+	"usage.note": "Właściciele są powiadamiani przy {percent} procentach limitu i ponownie po jego osiągnięciu. Limity ustawia operator wdrożenia.",
+	"usage.unlimited": "Zużyto {used}",
+	"usage.ofLimit": "{used} z {limit}",
+	"usage.column.key": "Licznik",
+	"usage.column.label": "Nazwa",
+	"usage.column.unit": "Jednostka",
+	"usage.column.kind": "Rodzaj",
+	"usage.column.used": "W tym miesiącu",
+	"usage.table.title": "Liczniki",
+	"usage.table.count": "Liczników: {count}",
+	"usage.table.caption": "Liczniki tego obszaru roboczego",
+	"usage.table.loading": "Wczytywanie liczników…",
+	"usage.search.label": "Szukaj liczników",
+	"usage.search.placeholder": "Klucz lub nazwa licznika",
+	"usage.filter.module": "Moduł",
+	"usage.filter.allModules": "Wszystkie moduły",
+	"usage.empty.title": "Nic jeszcze nie zmierzono",
+	"usage.empty.hint": "Licznik pojawi się tutaj, gdy moduł po raz pierwszy zgłosi zużycie dla tego obszaru roboczego.",
+	"usage.emptyFiltered.title": "Brak pasujących liczników",
+	"usage.emptyFiltered.hint": "Zmień wyszukiwanie lub moduł, aby poszerzyć listę.",
+	"usage.error.load": "Nie udało się wczytać liczników.",
+	"limits.title": "Limity",
+	"limits.description": "Miesięczne pułapy na licznik. Ustawia je operator wdrożenia, a po wyczerpaniu operacja jest odrzucana.",
+	"limits.denied": "Potrzebujesz uprawnienia do zużycia, aby zobaczyć limity tego obszaru roboczego.",
+	"limits.note": "Obszar roboczy nie zmienia własnego limitu. Ustawia go operator wdrożenia poleceniem metering limits set.",
+	"limits.column.meter": "Licznik",
+	"limits.column.monthlyLimit": "Limit miesięczny",
+	"limits.column.used": "W tym miesiącu",
+	"limits.column.setBy": "Ustawił",
+	"limits.column.updatedAt": "Zaktualizowano",
+	"limits.table.title": "Limity miesięczne",
+	"limits.table.count": "Limitów: {count}",
+	"limits.table.caption": "Miesięczne limity liczników tego obszaru roboczego",
+	"limits.table.loading": "Wczytywanie limitów…",
+	"limits.search.label": "Szukaj limitów",
+	"limits.search.placeholder": "Klucz licznika",
+	"limits.empty.title": "Brak limitów",
+	"limits.empty.hint": "Każdy licznik tego obszaru roboczego jest bez limitu, dopóki operator wdrożenia nie ustawi pułapu.",
+	"limits.emptyFiltered.title": "Brak pasujących limitów",
+	"limits.emptyFiltered.hint": "Zmień wyszukiwanie, aby poszerzyć listę.",
+	"limits.error.load": "Nie udało się wczytać limitów.",
+	"widget.unlimited": "Brak limitu",
+	"widget.share": "{percent}% limitu, {usage}",
+	"widget.attention": "Uwaga",
+	"widget.link": "Otwórz zużycie",
+	"error.request": "Żądanie nie powiodło się.",
+	"error.code.INVALID_INPUT": "Żądanie nie zostało przyjęte. Sprawdź licznik i zakres dat.",
+	"error.code.METER_NOT_DECLARED": "Żaden złożony moduł nie deklaruje tego licznika.",
+	"settings.warningPercent.label": "Próg ostrzeżenia dla limitu (procent)",
+	"settings.warningPercent.description": "Udział limitu miesięcznego, przy którym właściciele obszaru roboczego są powiadamiani, zanim limit odrzuci operację.",
+	"report.usage.label": "Zużycie w tym miesiącu"
+}

package/modules/notifications/migrations/0001_notifications_core.down.sql

@@ -0,0 +1 @@
+DROP TABLE IF EXISTS notifications_inbox;

package/modules/notifications/migrations/0001_notifications_core.up.sql

@@ -0,0 +1,26 @@
+CREATE TABLE IF NOT EXISTS notifications_inbox (
+  id TEXT PRIMARY KEY,
+  tenant_id TEXT NOT NULL,
+  recipient_account_id TEXT NOT NULL,
+  kind TEXT NOT NULL CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter')),
+  title TEXT NOT NULL,
+  body TEXT,
+  source_module TEXT NOT NULL,
+  source_ref TEXT NOT NULL,
+  status TEXT NOT NULL CHECK (status IN ('unread', 'read', 'archived')),
+  read_at TIMESTAMPTZ,
+  created_at BIGINT NOT NULL
+);
+CREATE INDEX IF NOT EXISTS notifications_inbox_tenant_recipient_account_id_idx
+  ON notifications_inbox (tenant_id, recipient_account_id, id);
+-- Publishing is idempotent on the source reference. The capability checks first,
+-- but this index is what actually guarantees one item per member per event.
+CREATE UNIQUE INDEX IF NOT EXISTS notifications_inbox_source_idx
+  ON notifications_inbox (tenant_id, recipient_account_id, kind, source_ref);
+CREATE INDEX IF NOT EXISTS notifications_inbox_member_status_idx
+  ON notifications_inbox (tenant_id, recipient_account_id, status, created_at DESC, id);
+ALTER TABLE notifications_inbox ENABLE ROW LEVEL SECURITY;
+ALTER TABLE notifications_inbox FORCE ROW LEVEL SECURITY;
+CREATE POLICY notifications_inbox_tenant_policy ON notifications_inbox
+  USING (tenant_id = current_setting('coreloom.tenant_id', true))
+  WITH CHECK (tenant_id = current_setting('coreloom.tenant_id', true));

package/modules/notifications/migrations/0002_notifications_preferences.down.sql

@@ -0,0 +1 @@
+DROP TABLE IF EXISTS notifications_preferences;

package/modules/notifications/migrations/0002_notifications_preferences.up.sql

@@ -0,0 +1,17 @@
+CREATE TABLE IF NOT EXISTS notifications_preferences (
+  id TEXT PRIMARY KEY,
+  tenant_id TEXT NOT NULL,
+  recipient_account_id TEXT NOT NULL,
+  kind TEXT NOT NULL CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter')),
+  enabled SMALLINT NOT NULL CHECK (enabled IN (0, 1)),
+  created_at BIGINT NOT NULL,
+  updated_at BIGINT NOT NULL
+);
+-- An absent row means enabled, so one row per member and kind is the whole rule.
+CREATE UNIQUE INDEX IF NOT EXISTS notifications_preferences_member_kind_idx
+  ON notifications_preferences (tenant_id, recipient_account_id, kind);
+ALTER TABLE notifications_preferences ENABLE ROW LEVEL SECURITY;
+ALTER TABLE notifications_preferences FORCE ROW LEVEL SECURITY;
+CREATE POLICY notifications_preferences_tenant_policy ON notifications_preferences
+  USING (tenant_id = current_setting('coreloom.tenant_id', true))
+  WITH CHECK (tenant_id = current_setting('coreloom.tenant_id', true));

package/modules/notifications/migrations/0003_notifications_webhook_subscriptions.down.sql

@@ -0,0 +1 @@
+DROP TABLE IF EXISTS notifications_webhook_subscriptions;

package/modules/notifications/migrations/0003_notifications_webhook_subscriptions.up.sql

@@ -0,0 +1,30 @@
+CREATE TABLE IF NOT EXISTS notifications_webhook_subscriptions (
+  id TEXT PRIMARY KEY,
+  tenant_id TEXT NOT NULL,
+  name TEXT NOT NULL,
+  url TEXT NOT NULL,
+  events_json TEXT NOT NULL,
+  secret_key_id TEXT NOT NULL,
+  secret_iv TEXT NOT NULL,
+  secret_tag TEXT NOT NULL,
+  secret_ciphertext TEXT NOT NULL,
+  secret_fingerprint TEXT NOT NULL,
+  secret_revision BIGINT NOT NULL,
+  status TEXT NOT NULL CHECK (status IN ('active', 'paused', 'disabled')),
+  description TEXT,
+  last_delivery_at BIGINT,
+  created_at BIGINT NOT NULL,
+  updated_at BIGINT NOT NULL,
+  created_by TEXT NOT NULL
+);
+-- The name is compared normalized, so the index has to normalize too or a
+-- duplicate would only be caught by the service it is meant to back up.
+CREATE UNIQUE INDEX IF NOT EXISTS notifications_webhook_subscriptions_name_idx
+  ON notifications_webhook_subscriptions (tenant_id, lower(name));
+CREATE INDEX IF NOT EXISTS notifications_webhook_subscriptions_status_idx
+  ON notifications_webhook_subscriptions (tenant_id, status, lower(name), id);
+ALTER TABLE notifications_webhook_subscriptions ENABLE ROW LEVEL SECURITY;
+ALTER TABLE notifications_webhook_subscriptions FORCE ROW LEVEL SECURITY;
+CREATE POLICY notifications_webhook_subscriptions_tenant_policy ON notifications_webhook_subscriptions
+  USING (tenant_id = current_setting('coreloom.tenant_id', true))
+  WITH CHECK (tenant_id = current_setting('coreloom.tenant_id', true));

package/modules/notifications/migrations/0004_notifications_deliveries.down.sql

@@ -0,0 +1 @@
+DROP TABLE IF EXISTS notifications_deliveries;

package/modules/notifications/migrations/0004_notifications_deliveries.up.sql

@@ -0,0 +1,35 @@
+CREATE TABLE IF NOT EXISTS notifications_deliveries (
+  id TEXT PRIMARY KEY,
+  tenant_id TEXT NOT NULL,
+  subscription_id TEXT NOT NULL,
+  kind TEXT NOT NULL CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter')),
+  source_module TEXT NOT NULL,
+  source_ref TEXT NOT NULL,
+  sequence BIGINT NOT NULL,
+  attempt_number BIGINT NOT NULL,
+  status TEXT NOT NULL CHECK (status IN ('pending', 'succeeded', 'failed', 'dead-letter')),
+  scheduled_for BIGINT NOT NULL,
+  completed_at BIGINT,
+  response_status BIGINT,
+  error_class TEXT,
+  payload_digest TEXT NOT NULL,
+  payload_bytes BIGINT NOT NULL,
+  occurred_at BIGINT NOT NULL,
+  created_at BIGINT NOT NULL
+);
+-- One row per attempt. The sequence separates the original attempt run from the
+-- ones a replay starts, so publishing the same event twice collides on attempt
+-- one of sequence one while a replay still numbers its own attempts from one.
+CREATE UNIQUE INDEX IF NOT EXISTS notifications_deliveries_attempt_idx
+  ON notifications_deliveries (tenant_id, subscription_id, kind, source_ref, sequence, attempt_number);
+CREATE INDEX IF NOT EXISTS notifications_deliveries_routing_idx
+  ON notifications_deliveries (status, scheduled_for, tenant_id, id);
+CREATE INDEX IF NOT EXISTS notifications_deliveries_tenant_status_idx
+  ON notifications_deliveries (tenant_id, status, scheduled_for DESC, id);
+CREATE INDEX IF NOT EXISTS notifications_deliveries_retention_idx
+  ON notifications_deliveries (tenant_id, completed_at);
+ALTER TABLE notifications_deliveries ENABLE ROW LEVEL SECURITY;
+ALTER TABLE notifications_deliveries FORCE ROW LEVEL SECURITY;
+CREATE POLICY notifications_deliveries_tenant_policy ON notifications_deliveries
+  USING (tenant_id = current_setting('coreloom.tenant_id', true))
+  WITH CHECK (tenant_id = current_setting('coreloom.tenant_id', true));

package/modules/notifications/migrations/0005_notifications_delivery_routing_role.down.sql

@@ -0,0 +1,2 @@
+DROP POLICY IF EXISTS notifications_deliveries_background_policy ON notifications_deliveries;
+REVOKE SELECT (tenant_id, id, scheduled_for, status) ON notifications_deliveries FROM coreloom_background;

package/modules/notifications/migrations/0005_notifications_delivery_routing_role.up.sql

@@ -0,0 +1,17 @@
+-- The delivery loop must find due attempts across tenants, and retention must
+-- find the tenants that still hold attempts at all. It is granted exactly the
+-- four routing columns: the subscription, the source reference, the digest and
+-- the ledger outcome stay invisible to it, and every attempt is read again under
+-- the tenant the routing row named before any request leaves the process.
+DO $$
+BEGIN
+  IF NOT EXISTS (SELECT 1 FROM pg_roles WHERE rolname = 'coreloom_background') THEN
+    RAISE EXCEPTION 'The coreloom_background role must exist before this migration.';
+  END IF;
+END
+$$;
+CREATE POLICY notifications_deliveries_background_policy ON notifications_deliveries
+  FOR SELECT TO coreloom_background
+  USING (true);
+REVOKE SELECT ON notifications_deliveries FROM coreloom_background;
+GRANT SELECT (tenant_id, id, scheduled_for, status) ON notifications_deliveries TO coreloom_background;

package/modules/notifications/migrations/0006_notifications_delivery_title.down.sql

@@ -0,0 +1 @@
+ALTER TABLE notifications_deliveries DROP COLUMN IF EXISTS title;

package/modules/notifications/migrations/0006_notifications_delivery_title.up.sql

@@ -0,0 +1,11 @@
+-- The payload carries the published title so a customer system can show the
+-- event without calling back into the source module. It is part of the signed
+-- body, so it has to live on the attempt row: a retry and a replay rebuild the
+-- payload from the row alone and must produce the same bytes.
+--
+-- The default is empty rather than absent because the column is NOT NULL and a
+-- deployment may already hold attempt rows. Such a row carries no title, so an
+-- attempt left pending across this upgrade sends a body with an empty title
+-- while the digest on it was taken before the field existed; the retry that
+-- attempt schedules is digested from the row again and matches.
+ALTER TABLE notifications_deliveries ADD COLUMN IF NOT EXISTS title TEXT NOT NULL DEFAULT '';

package/modules/notifications/migrations/0007_notifications_secret_rotation_inventory.down.sql

@@ -0,0 +1,2 @@
+DROP POLICY IF EXISTS notifications_webhook_subscriptions_background_policy ON notifications_webhook_subscriptions;
+REVOKE SELECT (tenant_id, secret_key_id) ON notifications_webhook_subscriptions FROM coreloom_background;

package/modules/notifications/migrations/0007_notifications_secret_rotation_inventory.up.sql

@@ -0,0 +1,19 @@
+-- The rotation command has to find the subscriptions still sealed with a
+-- retired key before it knows whose they are, and the subscriptions table is
+-- invisible to the cross-tenant role: it carries no background policy and the
+-- role holds no default table grant. This adds the tenant id and the key id and
+-- nothing else. The nonce, the tag, the ciphertext, the URL and the fingerprint
+-- stay unreadable on this connection, and every row it re-seals is read again
+-- under the tenant that row named.
+DO $$
+BEGIN
+  IF NOT EXISTS (SELECT 1 FROM pg_roles WHERE rolname = 'coreloom_background') THEN
+    RAISE EXCEPTION 'The coreloom_background role must exist before this migration.';
+  END IF;
+END
+$$;
+CREATE POLICY notifications_webhook_subscriptions_background_policy ON notifications_webhook_subscriptions
+  FOR SELECT TO coreloom_background
+  USING (true);
+REVOKE SELECT ON notifications_webhook_subscriptions FROM coreloom_background;
+GRANT SELECT (tenant_id, secret_key_id) ON notifications_webhook_subscriptions TO coreloom_background;

package/modules/notifications/migrations/0008_notifications_delivery_claim.down.sql

@@ -0,0 +1,8 @@
+-- A claimed attempt has to return to the queue before the column goes, or the
+-- rollback leaves rows in a state the old check constraint refuses.
+UPDATE notifications_deliveries SET status = 'pending' WHERE status = 'sending';
+REVOKE SELECT (claimed_at) ON notifications_deliveries FROM coreloom_background;
+ALTER TABLE notifications_deliveries DROP CONSTRAINT IF EXISTS notifications_deliveries_status_check;
+ALTER TABLE notifications_deliveries ADD CONSTRAINT notifications_deliveries_status_check
+  CHECK (status IN ('pending', 'succeeded', 'failed', 'dead-letter'));
+ALTER TABLE notifications_deliveries DROP COLUMN IF EXISTS claimed_at;

package/modules/notifications/migrations/0008_notifications_delivery_claim.up.sql

@@ -0,0 +1,19 @@
+-- Two processes drain the same queue during a rolling update, and both see the
+-- same due row. The row is claimed under its own tenant before the request
+-- leaves: the winner moves it to 'sending' and stamps the claim, the loser's
+-- update matches nothing and it moves on, so one pending attempt is one request.
+--
+-- The claim is a lease, not a ledger outcome. It leaves the attempt number, the
+-- response and the error class untouched, and a claim older than the request
+-- timeout plus its grace is taken over again so a process that died mid-send
+-- strands nothing. 'sending' is why the routing page advances instead of
+-- returning the rows another process is already holding.
+--
+-- The cross-tenant poll is the one that has to find a stranded claim, so
+-- claimed_at joins the routing columns the background role may read. It carries
+-- a clock reading and nothing about the tenant, the subscription or the payload.
+ALTER TABLE notifications_deliveries ADD COLUMN IF NOT EXISTS claimed_at BIGINT;
+ALTER TABLE notifications_deliveries DROP CONSTRAINT IF EXISTS notifications_deliveries_status_check;
+ALTER TABLE notifications_deliveries ADD CONSTRAINT notifications_deliveries_status_check
+  CHECK (status IN ('pending', 'sending', 'succeeded', 'failed', 'dead-letter'));
+GRANT SELECT (claimed_at) ON notifications_deliveries TO coreloom_background;

package/modules/notifications/migrations/0009_notifications_kind_approvals.down.sql

@@ -0,0 +1,16 @@
+-- The narrowed check refuses rows already written under an approval kind, so
+-- those rows go before it is restored. A subscription that selected one keeps
+-- the entry in its JSON events: nothing publishes that kind after the rollback,
+-- and the next edit of that subscription is refused until it is deselected.
+DELETE FROM notifications_deliveries WHERE kind IN ('approval-requested', 'approval-decided');
+DELETE FROM notifications_preferences WHERE kind IN ('approval-requested', 'approval-decided');
+DELETE FROM notifications_inbox WHERE kind IN ('approval-requested', 'approval-decided');
+ALTER TABLE notifications_deliveries DROP CONSTRAINT IF EXISTS notifications_deliveries_kind_check;
+ALTER TABLE notifications_deliveries ADD CONSTRAINT notifications_deliveries_kind_check
+  CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter'));
+ALTER TABLE notifications_preferences DROP CONSTRAINT IF EXISTS notifications_preferences_kind_check;
+ALTER TABLE notifications_preferences ADD CONSTRAINT notifications_preferences_kind_check
+  CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter'));
+ALTER TABLE notifications_inbox DROP CONSTRAINT IF EXISTS notifications_inbox_kind_check;
+ALTER TABLE notifications_inbox ADD CONSTRAINT notifications_inbox_kind_check
+  CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter'));

package/modules/notifications/migrations/0009_notifications_kind_approvals.up.sql

@@ -0,0 +1,18 @@
+-- approvals.core publishes two kinds, so the closed set the inbox, the
+-- preferences and the ledger all key off gains approval-requested and
+-- approval-decided. Each check was written inline with its column, so it
+-- carries the name PostgreSQL derived from it and is replaced under that name.
+-- Widening a check reads no row and rewrites none.
+--
+-- A subscription's selected events are JSON text with no check behind them, so
+-- an older subscription keeps exactly the kinds it was saved with and the
+-- service is the only thing that decides which ones may be selected next.
+ALTER TABLE notifications_inbox DROP CONSTRAINT IF EXISTS notifications_inbox_kind_check;
+ALTER TABLE notifications_inbox ADD CONSTRAINT notifications_inbox_kind_check
+  CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter', 'approval-requested', 'approval-decided'));
+ALTER TABLE notifications_preferences DROP CONSTRAINT IF EXISTS notifications_preferences_kind_check;
+ALTER TABLE notifications_preferences ADD CONSTRAINT notifications_preferences_kind_check
+  CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter', 'approval-requested', 'approval-decided'));
+ALTER TABLE notifications_deliveries DROP CONSTRAINT IF EXISTS notifications_deliveries_kind_check;
+ALTER TABLE notifications_deliveries ADD CONSTRAINT notifications_deliveries_kind_check
+  CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter', 'approval-requested', 'approval-decided'));

package/modules/notifications/migrations/0010_notifications_kind_meter_threshold.down.sql

@@ -0,0 +1,16 @@
+-- The narrowed check refuses rows already written under the metering kind, so
+-- those rows go before it is restored. A subscription that selected it keeps
+-- the entry in its JSON events: nothing publishes that kind after the rollback,
+-- and the next edit of that subscription is refused until it is deselected.
+DELETE FROM notifications_deliveries WHERE kind = 'meter-threshold';
+DELETE FROM notifications_preferences WHERE kind = 'meter-threshold';
+DELETE FROM notifications_inbox WHERE kind = 'meter-threshold';
+ALTER TABLE notifications_deliveries DROP CONSTRAINT IF EXISTS notifications_deliveries_kind_check;
+ALTER TABLE notifications_deliveries ADD CONSTRAINT notifications_deliveries_kind_check
+  CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter', 'approval-requested', 'approval-decided'));
+ALTER TABLE notifications_preferences DROP CONSTRAINT IF EXISTS notifications_preferences_kind_check;
+ALTER TABLE notifications_preferences ADD CONSTRAINT notifications_preferences_kind_check
+  CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter', 'approval-requested', 'approval-decided'));
+ALTER TABLE notifications_inbox DROP CONSTRAINT IF EXISTS notifications_inbox_kind_check;
+ALTER TABLE notifications_inbox ADD CONSTRAINT notifications_inbox_kind_check
+  CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter', 'approval-requested', 'approval-decided'));

package/modules/notifications/migrations/0010_notifications_kind_meter_threshold.up.sql

@@ -0,0 +1,18 @@
+-- metering.core publishes one kind, so the closed set the inbox, the
+-- preferences and the ledger all key off gains meter-threshold. Each check was
+-- written inline with its column, so it carries the name PostgreSQL derived
+-- from it and is replaced under that name. Widening a check reads no row and
+-- rewrites none.
+--
+-- A subscription's selected events are JSON text with no check behind them, so
+-- an older subscription keeps exactly the kinds it was saved with and the
+-- service is the only thing that decides which ones may be selected next.
+ALTER TABLE notifications_inbox DROP CONSTRAINT IF EXISTS notifications_inbox_kind_check;
+ALTER TABLE notifications_inbox ADD CONSTRAINT notifications_inbox_kind_check
+  CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter', 'approval-requested', 'approval-decided', 'meter-threshold'));
+ALTER TABLE notifications_preferences DROP CONSTRAINT IF EXISTS notifications_preferences_kind_check;
+ALTER TABLE notifications_preferences ADD CONSTRAINT notifications_preferences_kind_check
+  CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter', 'approval-requested', 'approval-decided', 'meter-threshold'));
+ALTER TABLE notifications_deliveries DROP CONSTRAINT IF EXISTS notifications_deliveries_kind_check;
+ALTER TABLE notifications_deliveries ADD CONSTRAINT notifications_deliveries_kind_check
+  CHECK (kind IN ('agent-run-completed', 'agent-run-failed', 'workflow-run-completed', 'workflow-run-failed', 'webhook-dead-letter', 'approval-requested', 'approval-decided', 'meter-threshold'));

package/modules/notifications/migrations/0011_notifications_retention_keyset.down.sql

@@ -0,0 +1,5 @@
+-- Both indexes carry no data of their own, so dropping them loses nothing; the
+-- sweep and the export stay correct and become proportional to the history
+-- instead of the batch.
+DROP INDEX IF EXISTS notifications_deliveries_created_idx;
+DROP INDEX IF EXISTS notifications_inbox_retention_idx;

package/modules/notifications/migrations/0011_notifications_retention_keyset.up.sql

@@ -0,0 +1,15 @@
+-- The workspace data class registry sweeps and exports what this module holds,
+-- and both walks key off (tenant_id, created_at, id). Without these indexes the
+-- inbox sweep would scan every row of a workspace on every bounded pass and the
+-- export keyset would sort the whole table per page, so the cost of one pass
+-- would grow with the history rather than with the batch.
+--
+-- created_at and id never change after a row is written, so a walk over them
+-- cannot revisit or skip a row while the table is still being written to. The
+-- deliveries ledger already carries (tenant_id, completed_at) for the delivery
+-- loop's own retention pass; that key is mutable until an attempt completes and
+-- serves the sweep only, so the export gets its own immutable one here.
+CREATE INDEX IF NOT EXISTS notifications_inbox_retention_idx
+  ON notifications_inbox (tenant_id, created_at, id);
+CREATE INDEX IF NOT EXISTS notifications_deliveries_created_idx
+  ON notifications_deliveries (tenant_id, created_at, id);

package/modules/notifications/migrations/0012_notifications_email_channel.down.sql

@@ -0,0 +1,12 @@
+-- An e-mail attempt has no subscription to fall back to, so the rollback drops
+-- those rows rather than leaving the queue holding attempts the webhook loop
+-- cannot address. The member preferences go with the table that held them.
+DELETE FROM notifications_deliveries WHERE channel = 'email';
+DROP INDEX IF EXISTS notifications_deliveries_attempt_idx;
+CREATE UNIQUE INDEX IF NOT EXISTS notifications_deliveries_attempt_idx
+  ON notifications_deliveries (tenant_id, subscription_id, kind, source_ref, sequence, attempt_number);
+ALTER TABLE notifications_deliveries DROP CONSTRAINT IF EXISTS notifications_deliveries_channel_check;
+ALTER TABLE notifications_deliveries ALTER COLUMN subscription_id SET NOT NULL;
+ALTER TABLE notifications_deliveries DROP COLUMN IF EXISTS recipient_account_id;
+ALTER TABLE notifications_deliveries DROP COLUMN IF EXISTS channel;
+DROP TABLE IF EXISTS notifications_member_preferences;

package/modules/notifications/migrations/0012_notifications_email_channel.up.sql

@@ -0,0 +1,38 @@
+-- A member asks for e-mail once, for the whole workspace, rather than per kind:
+-- the per-kind switch already decides whether an inbox item exists at all, and
+-- this decides whether the item that exists is also mailed. An absent row is
+-- the default, e-mail off, so a member who never opened the screen is never
+-- mailed by an upgrade.
+CREATE TABLE IF NOT EXISTS notifications_member_preferences (
+  tenant_id TEXT NOT NULL,
+  recipient_account_id TEXT NOT NULL,
+  email_delivery SMALLINT NOT NULL CHECK (email_delivery IN (0, 1)),
+  created_at BIGINT NOT NULL,
+  updated_at BIGINT NOT NULL,
+  PRIMARY KEY (tenant_id, recipient_account_id)
+);
+ALTER TABLE notifications_member_preferences ENABLE ROW LEVEL SECURITY;
+ALTER TABLE notifications_member_preferences FORCE ROW LEVEL SECURITY;
+CREATE POLICY notifications_member_preferences_tenant_policy ON notifications_member_preferences
+  USING (tenant_id = current_setting('coreloom.tenant_id', true))
+  WITH CHECK (tenant_id = current_setting('coreloom.tenant_id', true));
+
+-- The queue carries two channels now. A webhook attempt is addressed to a
+-- subscription of the workspace, an e-mail attempt to one member, and the
+-- constraint keeps a row from claiming both or neither. Every existing row is a
+-- webhook, which is why the column defaults to it.
+ALTER TABLE notifications_deliveries ADD COLUMN IF NOT EXISTS channel TEXT NOT NULL DEFAULT 'webhook';
+ALTER TABLE notifications_deliveries ADD COLUMN IF NOT EXISTS recipient_account_id TEXT;
+ALTER TABLE notifications_deliveries ALTER COLUMN subscription_id DROP NOT NULL;
+ALTER TABLE notifications_deliveries DROP CONSTRAINT IF EXISTS notifications_deliveries_channel_check;
+ALTER TABLE notifications_deliveries ADD CONSTRAINT notifications_deliveries_channel_check
+  CHECK (
+    (channel = 'webhook' AND subscription_id IS NOT NULL AND recipient_account_id IS NULL)
+    OR (channel = 'email' AND recipient_account_id IS NOT NULL AND subscription_id IS NULL)
+  );
+-- One row per attempt, per target. The target is the subscription on a webhook
+-- and the member on an e-mail, so the two channels of one event never collide
+-- and publishing the same event twice still collides with itself.
+DROP INDEX IF EXISTS notifications_deliveries_attempt_idx;
+CREATE UNIQUE INDEX IF NOT EXISTS notifications_deliveries_attempt_idx
+  ON notifications_deliveries (tenant_id, channel, coalesce(subscription_id, recipient_account_id), kind, source_ref, sequence, attempt_number);

package/modules/notifications/migrations/0013_notifications_list_pages.down.sql

@@ -0,0 +1,5 @@
+-- The indexes carry no data of their own, so dropping them loses nothing; the
+-- lists stay correct and pay a sort per page.
+DROP INDEX IF EXISTS notifications_deliveries_page_idx;
+DROP INDEX IF EXISTS notifications_webhook_subscriptions_page_idx;
+DROP INDEX IF EXISTS notifications_inbox_member_page_idx;

package/modules/notifications/migrations/0013_notifications_list_pages.up.sql

@@ -0,0 +1,13 @@
+-- The three list screens page by keyset over their sort column and the id, both
+-- in one direction, and the direction the reader asks for may be either. An
+-- index that mixes directions, such as the member status index on
+-- (created_at DESC, id), serves neither walk without a sort. Each index here
+-- carries the scope of its list, then the sort column, then the id, all
+-- ascending, so a page is a range read and the descending walk is the same
+-- index read backwards.
+CREATE INDEX IF NOT EXISTS notifications_inbox_member_page_idx
+  ON notifications_inbox (tenant_id, recipient_account_id, created_at, id);
+CREATE INDEX IF NOT EXISTS notifications_webhook_subscriptions_page_idx
+  ON notifications_webhook_subscriptions (tenant_id, lower(name), id);
+CREATE INDEX IF NOT EXISTS notifications_deliveries_page_idx
+  ON notifications_deliveries (tenant_id, scheduled_for, id);

package/modules/notifications/migrations/README.md

@@ -0,0 +1,3 @@
+# Migrations
+
+Migrations in this directory are append-only after release.

package/modules/notifications/module.json

@@ -0,0 +1,32 @@
+{
+	"$schema": "../../packages/contracts/schemas/module.schema.json",
+	"schemaVersion": 1,
+	"id": "notifications.core",
+	"package": "@flowdular/module-notifications",
+	"version": "0.2.8",
+	"platformApi": "^0.1.0",
+	"profile": "full",
+	"capabilities": ["api", "database", "client", "translations", "cli"],
+	"platform": {
+		"server": true,
+		"client": true
+	},
+	"dependencies": [
+		{
+			"id": "system.core",
+			"range": "^0.7.0"
+		},
+		{
+			"id": "auth.core",
+			"range": "^0.13.0"
+		}
+	],
+	"provides": ["notifications.publish.v1"],
+	"tenancy": "required",
+	"locales": ["en", "pl"],
+	"stability": "experimental",
+	"cli": {
+		"catalog": "src/cli/commands.json",
+		"entry": "src/cli/index.ts"
+	}
+}

package/modules/notifications/package.json

@@ -0,0 +1,49 @@
+{
+	"name": "@flowdular/module-notifications",
+	"version": "0.2.8",
+	"private": true,
+	"type": "module",
+	"exports": {
+		".": "./src/index.ts",
+		"./client": "./src/client/index.ts",
+		"./server": "./src/server/index.ts",
+		"./platform": "./src/platform.ts",
+		"./module.json": "./module.json"
+	},
+	"files": [
+		"src",
+		"schemas",
+		"dist",
+		"bin",
+		"public",
+		"module.json",
+		"migrations",
+		"translations",
+		"spec",
+		"README.md",
+		"LICENSE"
+	],
+	"scripts": {
+		"typecheck": "tsrx-tsc --noEmit -p tsconfig.json",
+		"test": "vitest run"
+	},
+	"dependencies": {
+		"@flowdular/cli-protocol": "workspace:*",
+		"@flowdular/client": "workspace:*",
+		"@flowdular/contracts": "workspace:*",
+		"@flowdular/database": "workspace:*",
+		"@flowdular/kernel": "workspace:*",
+		"@flowdular/module-auth": "workspace:*",
+		"@flowdular/server": "workspace:*",
+		"@flowdular/ui": "workspace:*",
+		"octane": "0.1.51",
+		"segment-state": "0.2.1"
+	},
+	"devDependencies": {
+		"@flowdular/database-testing": "workspace:*",
+		"@tsrx/typescript-plugin": "0.3.120",
+		"@types/node": "24.13.3",
+		"typescript": "5.9.3",
+		"vitest": "4.1.11"
+	}
+}