[jacobo-doist]

Summary

The channel create and update request schemas already expose defaultGroups and defaultRecipients, which define the groups and individual users selected as a channel default audience. They were missing useDefaultRecipients, the flag that tells Comms whether to use those values instead of defaulting to everyone in the channel.

This adds the missing optional useDefaultRecipients field to CreateChannelArgs and UpdateChannelArgs, completing the existing default-audience request shape.

Behavior

• useDefaultRecipients: true activates the audience in defaultGroups and defaultRecipients.
• useDefaultRecipients: false defaults new threads to everyone in the channel.
• Empty defaultGroups and defaultRecipients arrays clear the saved custom audience.

comms-cli use case

This is groundwork for a planned comms-cli default-audience feature. The CLI will be able to configure a custom channel audience by sending useDefaultRecipients: true with the selected groups and users, or reset the channel to everyone by sending useDefaultRecipients: false with empty arrays. With the complete request shape exported by the SDK, that implementation can use CreateChannelArgs and UpdateChannelArgs directly without a CLI-specific type workaround.

Once released, the CLI should adopt the expected @doist/comms-sdk@3.9.0 release.

[doistbot]

This PR adds an optional, nullable useDefaultRecipients flag to the channel create/update request schemas, with wire-serialization tests covering both true and false for create and update plus empty defaultGroups/defaultRecipients arrays, and a changelog entry — nice groundwork for the comms-cli default-audience feature. No inline issues were flagged; the new field follows the existing nullable/optional schema conventions, serialization through the shared snake-case transport is covered by tests that match the established per-client wire-serialization pattern, and the changelog entry fits the repo's keep-a-changelog style.

I also left one optional follow-up note in the details below.

Optional follow-up note (1)

• src/clients/channels-client.test.ts:24: The suffix tuple element is fully determined by method (createChannel → add, updateChannel → update), so the table carries redundant state and the two can drift apart. Derive suffix from method (or drop method and select the call from suffix) so there's a single source of truth.

_{Share Feedback • Review Logs}

[jacobo-doist]

@doistbot Fixed in 94064e0: removed the redundant endpoint suffix from the test matrix and now derive it from method, leaving a single source of truth.

[doistbot]

Confirmed—94064e0 removes the redundant suffix from the test matrix and derives it from method, so that resolves my optional note. I couldn’t run the test because Vitest isn’t installed in the checkout.

[amix]

LGTM 🚀

[doist-release-bot]

🎉 This PR is included in version 3.9.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀