feat(gateway): add kanban.notification_sources config for cross-profile notification delivery

[LizerAIDev]

feat(gateway): add kanban.notification_sources config for cross-profile notification delivery

Problem Description

Background

Hermes Agent supports multi-profile and Kanban multi-agent collaboration. Each profile can create its own Kanban tasks and subscribe to task status change notifications via notify-subscribe.

Problem Scenario

Users cannot receive task completion notifications in the following scenarios:

1. Multi-profile collaboration: The user creates a task and subscribes to notifications under the default profile, but the task is executed and completed by a worker profile (e.g., zilor-ppt, webmaster).
2. Single Notification Center Requirement: The user wants to use a single gateway as a "notification center" to uniformly receive all subscription notifications created by any profile.
3. Current Behavior: _kanban_notifier_watcher uses hard-coded profile isolation logic—it only delivers subscriptions created by the current gateway profile, and notifications created by other profiles are silently dropped.

Specific Manifestation

# User creates task and subscribes in default profile
hermes kanban create --title "Web Design Task" --body "Complete with zilor-ppt"
hermes kanban notify-subscribe t_xxx --platform qqbot --chat-id xxx

# After zilor-ppt worker completes the task
# Expected: User receives QQ notification "task completed"
# Actual: No notification (notifier_watcher finds notifier_profile=worker, current profile=default, and skips it)

Previous Workaround

Previously, users temporarily bypassed this by directly modifying the SQLite database to clear the notifier_profile field, but this is not a permanent fix:

• Manual modification is required every time a new subscription is created.
• It does not align with the principle of "configurable and flexible solutions".
• Introduces data consistency risks.

Solution

Design Concept

Change the hard-coded profile isolation mode to a configurable notification_sources whitelist/wildcard mode:

• Default behavior unchanged: Keeps profile isolation when not configured, so existing users are not affected.
• Wildcard support: ['*'] accepts subscriptions from all profiles.
• Whitelist support: ['profile-a', 'profile-b'] only accepts subscriptions from specified profiles.
• Comma-separated string: "profile-a,profile-b" is also supported (convenient for CLI configuration).

Why this change

1. Backward Compatibility: notification_sources defaults to None, making the behavior identical to before the refactor.
2. Flexibility: Supports multiple deployment modes such as a single notification center, multiple notification centers, and grouping by profile.
3. User Preference: Users explicitly prefer a "configurable and flexible solution" over "violently deleting" the original logic.
4. Minimal Changes: Only 2 files and 39 lines of code were modified. The logic is clear and the risk is controllable.

Changes

gateway/run.py (+33 lines)

Change 1: Read configuration at startup (lines 4191-4214)
Reads the kanban.notification_sources configuration during the _kanban_notifier_watcher initialization phase.

Change 2: Replace hard-coded filtering (lines 4276-4289)
Replaced the strict owner_profile != notifier_profile check with source configuration matching ("*" not in sources and owner_profile not in sources).

hermes_cli/config.py (+6 lines)

Added default values in KANBAN_DEFAULTS:

# Which profile-created subscriptions this gateway should deliver.
# Default: only handle subscriptions created by this profile itself.
#   ["*"]          — accept all profiles (notification center)
#   ["a", "b"]     — only accept subscriptions created by profile a or b
#   [] / missing   — same as [self] (legacy behaviour, profile-isolated)
"notification_sources": None,

Configuration Examples

Scenario 1: Single Notification Center (Accept all profiles)

# ~/.hermes/config.yaml
kanban:
  notification_sources:
    - '*'

Scenario 2: Whitelist Mode (Only accept specified profiles)

kanban:
  notification_sources:
    - default
    - zilor-ppt
    - webmaster

Scenario 3: Comma-separated string

kanban:
  notification_sources: "default,zilor-ppt"

Scenario 4: Default Behavior (Profile isolation, not configured)

# Do not configure kanban.notification_sources
# OR
kanban:
  notification_sources: []

Impact Analysis

• Backward Compatibility: ✅ Fully compatible: Default behavior remains unchanged (notification_sources: None → profile isolation). No database migration is required. Existing subscriptions are unaffected.
• Performance Impact: ✅ Configuration is only read once when the watcher starts. Filtering logic complexity remains O(1) set lookup.
• Security: ✅ No security impact: Only controls the scope of notification delivery without involving privilege escalation.

Related Files

• gateway/run.py — Configuration reading + filtering logic
• hermes_cli/config.py — Default value definition
• ~/.hermes/config.yaml — User configuration (optional)

Test Checklist

• Wildcard mode ['*'] functionality verification
• No duplicate notifications verification
• Whitelist mode functionality verification
• Default mode backward compatibility verification
• Comma-separated string parsing verification
• Exception fallback verification

[teknium1]

Merged via PR #28395 (cherry-picked onto current main with your authorship preserved via rebase-merge — commit f12382f). Thanks for the contribution!