feat: adds Slack App construct

[tnolet]

Affected Components

• CLI
• Create CLI
• Test
• Docs
• Examples
• Other

Notes for the Reviewer

Adds a new SlackAppAlertChannel standalone alert channel construct, following the same pattern as SlackAlertChannel.

• SlackAppAlertChannel construct with slackChannels: string[] config, synthesizing as type SLACK_APP
• SlackAppAlertChannelCodegen for code generation from imported resources
• Registered in AlertChannelCodegen type union and codegen map
• AI context updated with fixture, example config, and reference docs

[thebiglabasky]

Just ran a review agent real quick, but didn't yet take the time to review myself, so posting more as an FYI than as a conviction. Usually these findings are relevant. I'll review this afternoon.

AI-generated comments below:

Findings

Critical: packages/cli/src/constructs/slack-app-alert-channel-codegen.ts:12 uses SlackAlertChannel as the generated construct for SLACK_APP. The new class is SlackAppAlertChannel, but import/codegen instantiates the legacy Slack webhook construct while passing slackChannels. I confirmed the runtime effect: new SlackAlertChannel(..., { slackChannels: ['#ops'] }).synthesize() returns {"type":"SLACK","config":{}}, so JS imports silently become the wrong channel type, and TS imports fail because SlackAlertChannelProps requires url. This breaks import plan output for every Slack App alert channel. Change the codegen construct to SlackAppAlertChannel.

Important: packages/cli/src/constructs/slack-app-alert-channel.ts:4 makes slackChannels optional, so new SlackAppAlertChannel('x', {}) type-checks and synthesizes {"type":"SLACK_APP","config":{}}. The backend alert-channel schemas require at least one #channel or @handle, and the delivery path expects config.slackChannels.length. The construct should make slackChannels required at minimum, and ideally validate non-empty entries with the same #/@ prefix rule before deploy.

Verification

I checked the PR diff against the GitHub base/head SHAs and inspected the surrounding alert-channel/codegen patterns. I ran npm ci, npm run prepare:dist --workspace packages/cli, and npm exec --workspace packages/cli -- vitest --run src/constructs/tests/alert-channel.spec.ts; the build and targeted existing tests passed. I did not post any GitHub review comments.

[tnolet]

Just ran a review agent real quick, but didn't yet take the time to review myself, so posting more as an FYI than as a conviction. Usually these findings are relevant. I'll review this afternoon.

AI-generated comments below:

Findings

Critical: packages/cli/src/constructs/slack-app-alert-channel-codegen.ts:12 uses SlackAlertChannel as the generated construct for SLACK_APP. The new class is SlackAppAlertChannel, but import/codegen instantiates the legacy Slack webhook construct while passing slackChannels. I confirmed the runtime effect: new SlackAlertChannel(..., { slackChannels: ['#ops'] }).synthesize() returns {"type":"SLACK","config":{}}, so JS imports silently become the wrong channel type, and TS imports fail because SlackAlertChannelProps requires url. This breaks import plan output for every Slack App alert channel. Change the codegen construct to SlackAppAlertChannel.

Important: packages/cli/src/constructs/slack-app-alert-channel.ts:4 makes slackChannels optional, so new SlackAppAlertChannel('x', {}) type-checks and synthesizes {"type":"SLACK_APP","config":{}}. The backend alert-channel schemas require at least one #channel or @handle, and the delivery path expects config.slackChannels.length. The construct should make slackChannels required at minimum, and ideally validate non-empty entries with the same #/@ prefix rule before deploy.

Verification

I checked the PR diff against the GitHub base/head SHAs and inspected the surrounding alert-channel/codegen patterns. I ran npm ci, npm run prepare:dist --workspace packages/cli, and npm exec --workspace packages/cli -- vitest --run src/constructs/tests/alert-channel.spec.ts; the build and targeted existing tests passed. I did not post any GitHub review comments.

@thebiglabasky why are you reviewing this?

[tnolet]

Fixed both AI comments.

[thebiglabasky]

@thebiglabasky why are you reviewing this?

I've worked a fair bit on CLI and recently did the constructs and codegen for agentic check, so thought the more the merrier. Happy to drop and do something else though 🤷🏻

[tnolet]

@thebiglabasky why are you reviewing this?

I've worked a fair bit on CLI and recently did the constructs and codegen for agentic check, so thought the more the merrier. Happy to drop and do something else though 🤷🏻

ah, ok. Thank for the offer but there is no need to distract you with this.

[sorccu]

Rebased onto main (post-v8.0.0)

Rebased the 3 commits onto current main, which includes the v8.0.0 ESM migration. Changes made during rebase:

• Resolved conflicts in alert-channel-codegen.ts and index.ts — took main's ESM imports, added Slack App entries with .js suffixes
• Updated imports in both new files (slack-app-alert-channel.ts, slack-app-alert-channel-codegen.ts) to ESM style: .js suffixes on all local imports, index.js for barrel re-exports from ./internal/codegen and ../sourcegen

TypeScript compiles cleanly after the rebase.

Observations

Two minor things worth being aware of in the codegen:

1. Fallback name when slackChannels is undefined: In prepare(), if slackChannels is undefined the fallback name becomes "slack-app-undefined". Unlikely in practice since the API should always provide channels for a SLACK_APP type, but worth noting.

2. slackChannels?.concat().slice(-8) operates on array elements, not string characters — it takes the last 8 channel names from the array. This differs from the existing Slack codegen's url.slice(-4) which takes the last 4 characters of a string. The resulting fallback name may be quite long if the channel names are long.