@checkstack/catalog-backend 0.7.1 → 1.0.0

package/CHANGELOG.md

@@ -1,5 +1,165 @@
 # @checkstack/catalog-backend
 
+## 1.0.0
+
+### Major Changes
+
+- 32d52c6: feat: notification target pattern + per-spec subscriptions
+
+  Replaces the all-or-nothing catalog system/group notification model with a
+  platform-level target pattern. Each notification-emitting plugin declares
+  _subscription specs_ against typed _target_ objects exported from the
+  target's owning plugin (catalog ships `catalogSystemTarget` and
+  `catalogGroupTarget`). Notification-backend handles every per-resource
+  group lifecycle, parent-edge inheritance, and legacy-subscription seeding
+  — plugins never author groupId helpers, lifecycle hooks, or migration
+  code again.
+
+  **Plugin-author surface area is now ~12 lines per emitter:**
+
+  ```ts
+  // <plugin>-common
+  const { defineSubscription } = createSubscriptionFactory(pluginMetadata);
+  export const fooSystemSubscription = defineSubscription({
+    localId: "system",
+    target: catalogSystemTarget,
+    display: { title: "Foo Alerts", description: "...", iconName: "Bell" },
+  });
+
+  // <plugin>-backend register()
+  env.registerSubscriptionSpecs([fooSystemSubscription]);
+  //   ^ feeds the plugin loader's dependency sorter — each spec's
+  //     target.ownerPlugin becomes an implicit init-order dep, so this
+  //     plugin automatically waits for catalog (the target owner) to
+  //     finish init + afterPluginsReady before its own runs.
+
+  // <plugin>-backend afterPluginsReady
+  await notificationClient.registerSubscriptionSpec(
+    specToRegistration(fooSystemSubscription)
+  );
+  // dispatch
+  await notificationClient.notifyForSubscription({
+    specId: fooSystemSubscription.specId,
+    resourceKeys: [systemId],
+    title,
+    body,
+    importance,
+    action,
+    collapseKey,
+    subjects,
+  });
+
+  // <plugin>-frontend
+  createNotificationSubscriptionExtension({ spec: fooSystemSubscription });
+  ```
+
+  **Migrated plugins**: anomaly, incident, maintenance, healthcheck,
+  dependency. Each lost its bespoke `notification-groups.ts`,
+  `bootstrap*NotificationGroups`, `ensure*Group`, and inheritance walk —
+  all of that is now centralized in notification-backend's
+  `subscription-engine`.
+
+  **Plugin loader change** (`@checkstack/backend-api`,
+  `@checkstack/backend`): the register-time API gains
+  `env.registerSubscriptionSpecs([...specs])`. The dependency sorter
+  walks `spec.target.ownerPlugin` for every declared spec and adds the
+  target owner as an init-order dependency of the emitting plugin. This
+  guarantees that catalog (the owner of the platform's `system` and
+  `group` targets) completes init + afterPluginsReady before any
+  emitting plugin tries to register its specs against the notification
+  service — no string-prefix heuristics, no manual `dependsOnPlugins`
+  list, no stub rows. Plugins that fail to declare their specs at
+  register time get a clear `Target type X is not registered. Did the
+emitting plugin declare this spec via env.registerSubscriptionSpecs?`
+  error from the dispatcher.
+
+  **Removed** (no backwards compat):
+
+  - `catalogClient.notifySystemSubscribers` and
+    `catalogClient.notifyManySystemSubscribers`
+  - `notificationClient.notifyUsers` and `notificationClient.notifyGroups`
+    as direct dispatch primitives — replaced by spec-bound
+    `notifyForSubscription`
+  - catalog's `bootstrapNotificationGroups` (replaced by
+    `bootstrapNotificationTargets`)
+
+  **Enforcement**: the dispatcher rejects calls referencing unregistered
+  specIds, specs owned by other plugins, or resourceKeys that haven't been
+  pushed via `upsertNotificationResource`. Display metadata for any
+  groupId is recoverable via the spec registry, so audit lists render
+  correct labels even when an emitter's frontend isn't loaded.
+
+  **Per-field anomaly mute** keeps working — it now lives inside the
+  generic SubscriptionRow's optional `SubControls` panel
+  (`AnomalyFieldMuteList`), exposed through the catalog system detail
+  page's notifications card.
+
+  The catalog system detail page renders a "Notifications" card hosting
+  `SystemNotificationSubscriptionsSlot`. The matching group surface is
+  not yet rendered — group-level subscriptions are wired end-to-end on
+  the backend; a follow-up will add the host UI.
+
+  **Migration of existing subscribers**: target types declare a
+  `legacyGroupIdTemplate`; on first registration of each spec,
+  notification-backend reads subscribers from the legacy
+  `catalog.system.<id>` / `catalog.group.<id>` groups and seeds the new
+  spec groups exactly once per (spec × resource) pair, tracked in
+  `subscription_migrations`. Anomaly stays opt-in (its target also
+  declares the template, but the user-explicit nature of the original
+  opt-in flow means the seeding produces the same set of subscribers
+  they already had).
+
+### Minor Changes
+
+- 32d52c6: feat(anomaly): per-system and per-field notification mute
+
+  Anomaly notifications now flow through their own subscription group
+  (`anomaly.system.<systemId>`) instead of the shared catalog system group, so
+  users can opt out of anomaly noise without losing incident or healthcheck
+  alerts for the same system. On first deploy, existing subscribers of each
+  `catalog.system.<id>` group are seeded onto the new anomaly group so no one
+  silently stops getting alerts.
+
+  A new mute table (`anomaly_notification_mutes`) backs two granularities:
+
+  - **Per-field**: silence a single noisy metric on one system.
+  - **Per-system**: silence every anomaly for one system in one click.
+
+  The system anomaly widget now exposes a bell icon on each anomaly row plus a
+  `Mute all` toggle in the card header. Mutes are user-scoped and persist
+  across sessions.
+
+  Catalog gains a `systemCreated` hook so anomaly (and any future plugin) can
+  provision per-system state on creation rather than waiting for a restart.
+  The notification service gains a `bulkSubscribe` service-RPC used by the
+  one-time migration described above.
+
+- 32d52c6: Bulk notifications affecting multiple systems and collapse lifecycle events into a single card.
+
+  Notifications now carry an optional `subjects` array (the entities they affect) and an optional `collapseKey` (so related notifications collapse into one row per recipient). Incidents, maintenances, anomalies, healthchecks, and dependency-impact events route through these new fields, so an incident affecting three systems produces one in-app notification + one external send per subscriber instead of three. Lifecycle updates for the same entity (created → updated → resolved) also collapse, with an expandable "+N updates" timeline.
+
+  Subject kinds are namespaced as `<pluginId>.<localKind>` and built via type-safe helpers exported from each domain's common package (`createSystemSubject`, `incidentCollapseKey`, etc.). The frontend kind registry (`registerSubjectKind`) lets plugins bind icon + label for their kinds; unknown kinds fall back to a generic chip.
+
+  All notification strategies (SMTP, Slack, Discord, Teams, Telegram, Pushover, Gotify, Webex, Backstage) render the affected subjects natively in their format (HTML cards, Slack blocks, Discord embed fields, adaptive cards, markdown lists, etc.).
+
+### Patch Changes
+
+- Updated dependencies [32d52c6]
+- Updated dependencies [32d52c6]
+- Updated dependencies [32d52c6]
+- Updated dependencies [32d52c6]
+- Updated dependencies [32d52c6]
+- Updated dependencies [32d52c6]
+  - @checkstack/gitops-backend@0.2.6
+  - @checkstack/notification-common@1.0.0
+  - @checkstack/catalog-common@2.0.0
+  - @checkstack/backend-api@0.14.0
+  - @checkstack/auth-backend@0.4.22
+  - @checkstack/auth-common@0.6.4
+  - @checkstack/cache-api@0.2.2
+  - @checkstack/command-backend@0.1.22
+  - @checkstack/cache-utils@0.2.2
+
 ## 0.7.1
 
 ### Patch Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@checkstack/catalog-backend",
-  "version": "0.7.1",
+  "version": "1.0.0",
   "type": "module",
   "main": "src/index.ts",
   "checkstack": {
@@ -13,16 +13,16 @@
     "lint:code": "eslint . --max-warnings 0"
   },
   "dependencies": {
-    "@checkstack/backend-api": "0.13.0",
-    "@checkstack/cache-api": "0.2.0",
-    "@checkstack/cache-utils": "0.2.0",
+    "@checkstack/backend-api": "0.13.1",
+    "@checkstack/cache-api": "0.2.1",
+    "@checkstack/cache-utils": "0.2.1",
     "@checkstack/auth-common": "0.6.3",
-    "@checkstack/catalog-common": "1.5.2",
-    "@checkstack/command-backend": "0.1.20",
-    "@checkstack/auth-backend": "0.4.20",
-    "@checkstack/gitops-backend": "0.2.4",
+    "@checkstack/catalog-common": "1.5.3",
+    "@checkstack/command-backend": "0.1.21",
+    "@checkstack/auth-backend": "0.4.21",
+    "@checkstack/gitops-backend": "0.2.5",
     "@checkstack/gitops-common": "0.2.1",
-    "@checkstack/notification-common": "0.2.9",
+    "@checkstack/notification-common": "0.3.0",
     "@orpc/server": "^1.13.2",
     "drizzle-orm": "^0.45.0",
     "hono": "^4.12.14",
@@ -37,6 +37,7 @@
     "@types/bun": "^1.3.5",
     "@types/node": "^20.0.0",
     "@types/uuid": "^11.0.0",
+    "drizzle-kit": "^0.31.10",
     "typescript": "^5.0.0"
   }
 }

package/src/hooks.ts

@@ -4,6 +4,16 @@ import { createHook } from "@checkstack/backend-api";
  * Catalog hooks for cross-plugin communication
  */
 export const catalogHooks = {
+  /**
+   * Emitted when a system is created.
+   * Plugins can subscribe (work-queue mode) to bootstrap related state
+   * (e.g. per-system notification groups).
+   */
+  systemCreated: createHook<{
+    systemId: string;
+    systemName: string;
+  }>("catalog.system.created"),
+
   /**
    * Emitted when a system is deleted.
    * Plugins can subscribe (work-queue mode) to clean up related data.
@@ -13,6 +23,16 @@ export const catalogHooks = {
     systemName?: string;
   }>("catalog.system.deleted"),
 
+  /**
+   * Emitted when a catalog group is created.
+   * Plugins can subscribe to bootstrap related state (e.g. anomaly creates
+   * its own per-group notification group on this signal).
+   */
+  groupCreated: createHook<{
+    groupId: string;
+    groupName: string;
+  }>("catalog.group.created"),
+
   /**
    * Emitted when a group is deleted.
    * Plugins can subscribe (work-queue mode) to clean up related data.

package/src/index.ts

@@ -9,10 +9,15 @@ import {
   pluginMetadata,
   catalogContract,
   catalogRoutes,
+  catalogSystemTarget,
+  catalogGroupTarget,
 } from "@checkstack/catalog-common";
 import { createCatalogRouter } from "./router";
 import { createCatalogCache } from "./cache";
-import { NotificationApi } from "@checkstack/notification-common";
+import {
+  NotificationApi,
+  targetToRegistration,
+} from "@checkstack/notification-common";
 import { AuthApi } from "@checkstack/auth-common";
 import { authHooks } from "@checkstack/auth-backend";
 import { resolveRoute, type InferClient, extractErrorMessage} from "@checkstack/common";
@@ -270,8 +275,12 @@ export default createBackendPlugin({
         const typedDb = database as SafeDatabase<typeof schema>;
         const notificationClient = rpcClient.forPlugin(NotificationApi);
 
-        // Bootstrap: Create notification groups for existing systems and groups
-        await bootstrapNotificationGroups(typedDb, notificationClient, logger);
+        // Catalog owns the platform's "system" and "group" notification
+        // target types. Register both target types, then push the
+        // current set of resources + parent edges to notification-
+        // backend in one shot. Per-resource notification group
+        // provisioning happens server-side from this signal.
+        await bootstrapNotificationTargets(typedDb, notificationClient, logger);
 
         // Subscribe to user deletion to clean up user contacts
         onHook(
@@ -290,45 +299,77 @@ export default createBackendPlugin({
 });
 
 /**
- * Bootstrap notification groups for existing catalog entities
+ * Register the catalog target types and seed every existing system /
+ * group as a known resource. Runs every startup (idempotent on the
+ * notification-backend side via primary-key upsert) so resources stay
+ * in sync even if catalog and notification-backend are restarted in
+ * different orders.
  */
-async function bootstrapNotificationGroups(
+async function bootstrapNotificationTargets(
   database: SafeDatabase<typeof schema>,
   notificationClient: InferClient<typeof NotificationApi>,
   logger: { debug: (msg: string) => void },
 ) {
   try {
-    // Get all existing systems and groups
+    await Promise.all([
+      notificationClient.registerNotificationTarget(
+        targetToRegistration(catalogSystemTarget),
+      ),
+      notificationClient.registerNotificationTarget(
+        targetToRegistration(catalogGroupTarget),
+      ),
+    ]);
+
     const systems = await database.select().from(schema.systems);
     const groups = await database.select().from(schema.groups);
 
-    // Create notification groups for each system
-    for (const system of systems) {
-      await notificationClient.createGroup({
-        groupId: `system.${system.id}`,
-        name: `${system.name} Notifications`,
-        description: `Notifications for the ${system.name} system`,
-        ownerPlugin: pluginMetadata.pluginId,
+    if (systems.length > 0) {
+      await notificationClient.upsertNotificationResources({
+        targetTypeId: catalogSystemTarget.targetTypeId,
+        resources: systems.map((s) => ({
+          resourceKey: s.id,
+          displayLabel: s.name,
+        })),
+      });
+    }
+
+    if (groups.length > 0) {
+      await notificationClient.upsertNotificationResources({
+        targetTypeId: catalogGroupTarget.targetTypeId,
+        resources: groups.map((g) => ({
+          resourceKey: g.id,
+          displayLabel: g.name,
+        })),
       });
     }
 
-    // Create notification groups for each catalog group
-    for (const group of groups) {
-      await notificationClient.createGroup({
-        groupId: `group.${group.id}`,
-        name: `${group.name} Notifications`,
-        description: `Notifications for the ${group.name} group`,
-        ownerPlugin: pluginMetadata.pluginId,
+    // Seed parent edges from the systems_groups join table so the
+    // dispatcher can walk inheritance without re-querying catalog at
+    // notification time.
+    const memberships = await database.select().from(schema.systemsGroups);
+    const parentsBySystem = new Map<string, string[]>();
+    for (const m of memberships) {
+      const arr = parentsBySystem.get(m.systemId) ?? [];
+      arr.push(m.groupId);
+      parentsBySystem.set(m.systemId, arr);
+    }
+    for (const [systemId, parentGroupIds] of parentsBySystem) {
+      await notificationClient.setNotificationResourceParents({
+        childTargetTypeId: catalogSystemTarget.targetTypeId,
+        childResourceKey: systemId,
+        parents: parentGroupIds.map((groupId) => ({
+          parentTargetTypeId: catalogGroupTarget.targetTypeId,
+          parentResourceKey: groupId,
+        })),
       });
     }
 
     logger.debug(
-      `Bootstrapped notification groups for ${systems.length} systems and ${groups.length} groups`,
+      `Bootstrapped notification targets: ${systems.length} systems, ${groups.length} groups, ${memberships.length} parent edges`,
     );
   } catch (error) {
-    // Don't fail startup if notification service is unavailable
     logger.debug(
-      `Failed to bootstrap notification groups: ${
+      `Failed to bootstrap notification targets: ${
         extractErrorMessage(error, "Unknown error")
       }`,
     );

package/src/router.ts

@@ -2,6 +2,8 @@ import { implement, ORPCError } from "@orpc/server";
 import { autoAuthMiddleware, type RpcContext } from "@checkstack/backend-api";
 import {
   catalogContract,
+  catalogSystemTarget,
+  catalogGroupTarget,
   type SystemContact,
 } from "@checkstack/catalog-common";
 import { EntityService } from "./services/entity-service";
@@ -39,7 +41,7 @@ export const createCatalogRouter = ({
   notificationClient,
   authClient,
   gitOpsClient,
-  pluginId,
+  pluginId: _pluginId,
   cache,
 }: CatalogRouterDeps) => {
   const entityService = new EntityService(database);
@@ -56,42 +58,84 @@ export const createCatalogRouter = ({
     }
   };
 
-  // Helper to create notification group for an entity
-  const createNotificationGroup = async (
-    type: "system" | "group",
-    id: string,
-    name: string,
-  ) => {
+  // Resource lifecycle: catalog pushes systems and groups into
+  // notification-backend's resource registry. The platform takes over
+  // from there — registering specs, provisioning per-resource groups,
+  // walking parent edges at dispatch time. Catalog never directly
+  // creates per-resource notification groups any more.
+  const upsertSystemResource = async (system: { id: string; name: string }) => {
     try {
-      await notificationClient.createGroup({
-        groupId: `${type}.${id}`,
-        name: `${name} Notifications`,
-        description: `Notifications for the ${name} ${type}`,
-        ownerPlugin: pluginId,
+      await notificationClient.upsertNotificationResource({
+        targetTypeId: catalogSystemTarget.targetTypeId,
+        resource: { resourceKey: system.id, displayLabel: system.name },
       });
     } catch (error) {
-      // Log but don't fail the operation
       console.warn(
-        `Failed to create notification group for ${type} ${id}:`,
+        `Failed to upsert notification resource for system ${system.id}:`,
         error,
       );
     }
   };
 
-  // Helper to delete notification group for an entity
-  const deleteNotificationGroup = async (
-    type: "system" | "group",
-    id: string,
-  ) => {
+  const upsertGroupResource = async (group: { id: string; name: string }) => {
     try {
-      await notificationClient.deleteGroup({
-        groupId: `${pluginId}.${type}.${id}`,
-        ownerPlugin: pluginId,
+      await notificationClient.upsertNotificationResource({
+        targetTypeId: catalogGroupTarget.targetTypeId,
+        resource: { resourceKey: group.id, displayLabel: group.name },
       });
     } catch (error) {
-      // Log but don't fail the operation
       console.warn(
-        `Failed to delete notification group for ${type} ${id}:`,
+        `Failed to upsert notification resource for catalog group ${group.id}:`,
+        error,
+      );
+    }
+  };
+
+  const refreshSystemParents = async (systemId: string) => {
+    try {
+      const groups = await entityService.getGroups();
+      const parents = groups
+        .filter((g) => g.systemIds?.includes(systemId))
+        .map((g) => ({
+          parentTargetTypeId: catalogGroupTarget.targetTypeId,
+          parentResourceKey: g.id,
+        }));
+      await notificationClient.setNotificationResourceParents({
+        childTargetTypeId: catalogSystemTarget.targetTypeId,
+        childResourceKey: systemId,
+        parents,
+      });
+    } catch (error) {
+      console.warn(
+        `Failed to refresh notification parents for system ${systemId}:`,
+        error,
+      );
+    }
+  };
+
+  const removeSystemResource = async (systemId: string) => {
+    try {
+      await notificationClient.removeNotificationResource({
+        targetTypeId: catalogSystemTarget.targetTypeId,
+        resourceKey: systemId,
+      });
+    } catch (error) {
+      console.warn(
+        `Failed to remove notification resource for system ${systemId}:`,
+        error,
+      );
+    }
+  };
+
+  const removeGroupResource = async (groupId: string) => {
+    try {
+      await notificationClient.removeNotificationResource({
+        targetTypeId: catalogGroupTarget.targetTypeId,
+        resourceKey: groupId,
+      });
+    } catch (error) {
+      console.warn(
+        `Failed to remove notification resource for catalog group ${groupId}:`,
         error,
       );
     }
@@ -154,17 +198,45 @@ export const createCatalogRouter = ({
     }),
   );
 
-  const createSystem = os.createSystem.handler(async ({ input }) => {
+  const getSystemGroups = os.getSystemGroups.handler(
+    async ({ input }) => {
+      // Fetch all groups (cache-warm), then filter to those that contain
+      // the system. This is cheaper than a per-system join because
+      // `getGroups()` already produces the full populated list and is
+      // cached topology-wide; per-system mutations invalidate this cache
+      // alongside everything else.
+      const groups = await entityService.getGroups();
+      const filtered = groups.filter((group) =>
+        group.systemIds?.includes(input.systemId),
+      );
+      return filtered as unknown as Array<
+        (typeof filtered)[number] & {
+          metadata: Record<string, unknown> | null;
+        }
+      >;
+    },
+  );
+
+  const createSystem = os.createSystem.handler(async ({ input, context }) => {
     const result = await entityService.createSystem(input);
 
-    // Create a notification group for this system
-    await createNotificationGroup("system", result.id, result.name);
+    // Push the new system into notification-backend's resource registry.
+    // notification-backend handles all per-spec group provisioning from
+    // this single signal — catalog never authors notification groups
+    // directly.
+    await upsertSystemResource({ id: result.id, name: result.name });
+    await refreshSystemParents(result.id);
 
-    // Drop the topology cache before any downstream side-effect that might
-    // observe it (notification group creation already happened, but the
-    // hook chain in deleteSystem/etc. relies on this ordering).
     await cache.invalidateTopology();
 
+    // Hooks remain for non-notification cleanup concerns (e.g. incident
+    // associations) — emitting plugins no longer use them for
+    // subscription provisioning.
+    await context.emitHook(catalogHooks.systemCreated, {
+      systemId: result.id,
+      systemName: result.name,
+    });
+
     return result as typeof result & {
       metadata: Record<string, unknown> | null;
     };
@@ -191,6 +263,11 @@ export const createCatalogRouter = ({
       });
     }
     await cache.invalidateTopology();
+    // Refresh display label in notification-backend on rename so the
+    // settings/audit UI shows the current name.
+    if (input.data.name !== undefined) {
+      await upsertSystemResource({ id: result.id, name: result.name });
+    }
     return result as typeof result & {
       metadata: Record<string, unknown> | null;
     };
@@ -200,8 +277,7 @@ export const createCatalogRouter = ({
     await enforceNotGitOpsLocked("System", input);
     await entityService.deleteSystem(input);
 
-    // Delete the notification group for this system
-    await deleteNotificationGroup("system", input);
+    await removeSystemResource(input);
 
     // Drop catalog topology + this system's contacts BEFORE the hook fires,
     // so downstream plugins (e.g. healthcheck) and any frontend that
@@ -217,17 +293,21 @@ export const createCatalogRouter = ({
     return { success: true };
   });
 
-  const createGroup = os.createGroup.handler(async ({ input }) => {
+  const createGroup = os.createGroup.handler(async ({ input, context }) => {
     const result = await entityService.createGroup({
       name: input.name,
       metadata: input.metadata,
     });
 
-    // Create a notification group for this catalog group
-    await createNotificationGroup("group", result.id, result.name);
+    await upsertGroupResource({ id: result.id, name: result.name });
 
     await cache.invalidateTopology();
 
+    await context.emitHook(catalogHooks.groupCreated, {
+      groupId: result.id,
+      groupName: result.name,
+    });
+
     // New groups have no systems yet
     return {
       ...result,
@@ -258,6 +338,9 @@ export const createCatalogRouter = ({
       });
     }
     await cache.invalidateTopology();
+    if (input.data.name !== undefined) {
+      await upsertGroupResource({ id: fullGroup.id, name: fullGroup.name });
+    }
     return fullGroup as unknown as typeof fullGroup & {
       metadata: Record<string, unknown> | null;
     };
@@ -267,8 +350,7 @@ export const createCatalogRouter = ({
     await enforceNotGitOpsLocked("Group", input);
     await entityService.deleteGroup(input);
 
-    // Delete the notification group for this catalog group
-    await deleteNotificationGroup("group", input);
+    await removeGroupResource(input);
 
     await cache.invalidateTopology();
 
@@ -279,23 +361,21 @@ export const createCatalogRouter = ({
   });
 
   const addSystemToGroup = os.addSystemToGroup.handler(async ({ input }) => {
-    // Note: We only enforce the lock on the System, not the Group.
-    // This is because system-group associations are reconciled as a kindExtension
-    // of the System kind. The Group reconciler does not touch associations.
-    // Thus, it is perfectly safe (and intended) to manually add an unlocked System
-    // to a GitOps-managed Group.
     await enforceNotGitOpsLocked("System", input.systemId);
     await entityService.addSystemToGroup(input);
     await cache.invalidateTopology();
+    // Push refreshed parent edges so notification-backend's dispatcher
+    // walks the new membership when computing inherited subscribers.
+    await refreshSystemParents(input.systemId);
     return { success: true };
   });
 
   const removeSystemFromGroup = os.removeSystemFromGroup.handler(
     async ({ input }) => {
-      // See addSystemToGroup for why we only check the System provenance lock.
       await enforceNotGitOpsLocked("System", input.systemId);
       await entityService.removeSystemFromGroup(input);
       await cache.invalidateTopology();
+      await refreshSystemParents(input.systemId);
       return { success: true };
     },
   );
@@ -417,51 +497,6 @@ export const createCatalogRouter = ({
     },
   );
 
-  /**
-   * Notify all users subscribed to a system (and optionally its groups).
-   * Delegates deduplication to notification-backend via notifyGroups RPC.
-   */
-  const notifySystemSubscribers = os.notifySystemSubscribers.handler(
-    async ({ input }) => {
-      const {
-        systemId,
-        title,
-        body,
-        importance,
-        action,
-        includeGroupSubscribers,
-      } = input;
-
-      // Collect all notification group IDs to notify
-      // Start with the system's notification group
-      const groupIds = [`${pluginId}.system.${systemId}`];
-
-      // If includeGroupSubscribers is true, add groups containing this system
-      if (includeGroupSubscribers) {
-        const systemGroups = await database
-          .select({ groupId: schema.systemsGroups.groupId })
-          .from(schema.systemsGroups)
-          .where(eq(schema.systemsGroups.systemId, systemId));
-
-        // Spread to avoid mutation
-        groupIds.push(
-          ...systemGroups.map(({ groupId }) => `${pluginId}.group.${groupId}`),
-        );
-      }
-
-      // 3. Send to notification-backend, which handles deduplication
-      const result = await notificationClient.notifyGroups({
-        groupIds,
-        title,
-        body,
-        importance: importance ?? "info",
-        action,
-      });
-
-      return { notifiedCount: result.notifiedCount };
-    },
-  );
-
   /**
    * Get the catalog group IDs that contain a specific system.
    * Used by the dependency plugin for batched notification deduplication.
@@ -484,6 +519,7 @@ export const createCatalogRouter = ({
     getSystems,
     getSystem,
     getGroups,
+    getSystemGroups,
     createSystem,
     updateSystem,
     deleteSystem,
@@ -497,7 +533,6 @@ export const createCatalogRouter = ({
     removeSystemFromGroup,
     getViews,
     createView,
-    notifySystemSubscribers,
     getSystemGroupIds,
   });
 };