[Feat] Offer Discord destinations for suggester, announcer, and platform-issue alerts#413
Merged
Merged
Conversation
… alerts Extends the PR #268 Slack-or-Discord one-of destination picker to the three remaining automation destination fields: - suggester: registry now declares 'discord' in supportedCommunicationProviders (scheduled-suggestion delivery already falls through Slack -> Discord); settings write path and picker added. - announcer: settings write path and picker added (Discord delivery already worked via resolveAutomationRuntimeDestination + the comms adapter). - platform_issue_alerts: settings write path, picker, and a new Discord delivery branch in record-task-message-envelope — when the automation's own destination target is a Discord channel, the alert posts there via the Discord communication provider instead of Slack (best-effort, and the existing slackPostedAt marker doubles as the posted-anywhere gate). Details: - normalizeBackgroundAgentSettings now exposes suggesterDiscordChannelId, announcerDiscordChannelId, and platformIssueDiscordChannelId from the automations' discord_channel targets. - settings-update upserts the three automations with buildDestinationChannelTargets + managedTargetKinds ['slack_channel', 'discord_channel'], with the same server-side one-of backstop (Discord preferred) as the six existing pickers. Their keep-persisted Slack values stay un-suppressed because these three resolve via getAutomationSlackChannelTarget, which never merges the manager-channel fallback. - The shared renderSlackDestinationField now serves suggester, announcer, and a newly rendered Alert on Config Errors card; platform_issue_alerts joins MANAGER_REPORTING_AUTOMATION_KEYS so its "Reports to" line resolves. - Suggester's capability badge changes from "Slack only" to "Slack · Discord only". Tests: settings-update-discord real-DB coverage for the three fields (discord save clears slack, slack save clears discord, unrelated saves preserve), a new platform-issue alert delivery test (Discord target, Slack fallback, missing Discord credentials), registry provider-list assertion, and render coverage for the new card. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
|
No code issues remain; no new code issues found in the latest commit. See task
Reviewed a17acd1 |
'Post summaries to this Slack channel' above a picker that offers (or has selected) a Discord channel reads as a bug; drop the provider word when Discord options are shown. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The announcer delivers to whichever provider its destination resolves to, and the card now offers Discord channels directly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…cted On a Discord-only deployment the suffix disambiguates nothing and every option reads as noise. Gate it on the slackConnected capability rather than the momentary Slack channel list so labels don't flicker while the list loads. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The destination renderer read slackConnected without declaring it as a useCallback dependency, so a Slack connect/disconnect while mounted would keep rendering labels for the old state. Use the component-scope value consistently and depend on it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The three new Discord destination fields are optional in the API so in-flight clients keep working across a deploy, but an omitted field was normalized to null and treated as an explicit clear: an older client re-saving the same automation wiped its Discord target, disabling a Discord-only platform-issue alert entirely. Only an explicitly submitted value now reaches resolution; omission keeps the persisted channel without re-validating it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Preserve-on-omit left both targets stored when a pre-deploy client picked a Slack channel while unable to send the Discord field; a later current-client save would then submit both and the Discord-wins backstop silently flipped routing back to Discord. An explicitly selected Slack channel now clears the invisible Discord target; an empty Slack value still preserves it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Completes #268's per-automation Discord destinations: the three destination fields that stayed Slack-only get the same one-of Slack-or-Discord picker as the six triage/auditor automations.
Changes
discordin its registry entry (capability badge becomes "Slack · Discord only"); scheduled suggestion summaries already routed to a targeted Discord channel via the destination waterfall, so only the write path + picker were missing. The experimental suggestion-routing-flag UI is untouched.Alert on Config Errorsdefinition, dirty-tracking, and save wiring existed but nothing displayed it. This PR renders the card (picker-only, in Other automations) and adds Discord delivery inrecord-task-message-envelope: when the automation's own target is a Discord channel, the alert posts there via the runtime-credentials provider (best-effort, Slack path unchanged,slackPostedAtreused as the posted-anywhere marker so no migration).One-of semantics, keep-persisted preservation, and validation mirror the existing six fields; the new zod inputs are optional so in-flight clients keep working across a deploy.
Screenshots
Captured on this branch against a dev deployment with one connected Discord server (Slack also connected, so options carry the "(Discord)" suffix — it is omitted on Discord-only deployments).
The combined destination picker — Discord channels alongside Slack in one searchable dropdown:
A Discord channel selected as an automation's destination (provider-neutral label):
The "Slack · Discord only" capability badge on Suggest Ideas and the newly rendered Alert on Config Errors card:
Alert on Config Errors expanded with a Discord channel selected — this automation previously had no Discord delivery and no settings card:
Review note
Rendering the previously-orphaned platform-issue card is the one product-facing judgment call here — the alternative was a configurable Discord destination with no way to configure it. The card's label/description/icon all pre-existed.
Validation
🤖 Generated with Claude Code