kodiakhq · Oct 17, 2026 · Oct 17, 2026
@@ -1,5 +1,15 @@
 # @wolfstar/plugin-broker
 
+## 0.6.0
+
+### Minor Changes
+
+- [#245](https://github.com/wolfstar-project/plugins/pull/245) [`7257223`](https://github.com/wolfstar-project/plugins/commit/7257223baea1785c72737e103243ab381f6f29f7) - `forwardGatewayDispatches` marks a `GatewayClient` as forwarding (`forwardsDispatches`) until its stop function is called, through the new optional `GatewayDispatchEmitterLike#markDispatchesForwarded`, so listeners registered with `RegisterAsDispatchListener` from `@wolfstar/plugin-gateway` run on the workers only. Emitters without it forward as before.
+
+### Patch Changes
+
+- [#247](https://github.com/wolfstar-project/plugins/pull/247) [`6012bd9`](https://github.com/wolfstar-project/plugins/commit/6012bd9d16cc73abd5e0c866a6ab2d407e3c3b79) - Forward the `guildDelete` of a guild a `READY` drops: when a `READY` no longer lists a cached guild (the bot left it while offline), `GatewayClient` now emits `dispatch` for the `GUILD_DELETE` it applies, after the cache write and with the cached guild as its state, before `guildDelete`. `forwardGatewayDispatches` publishes it like any other dispatch, so a `plugin-broker` worker's `guildDelete` listeners clean these guilds up too. The made-up dispatch carries `s: 0` and is not emitted as `raw`.
+
 ## 0.5.1
 
 ### Patch Changes

@@ -1,6 +1,6 @@
 {
   "name": "@wolfstar/plugin-broker",
-  "version": "0.5.1",
+  "version": "0.6.0",
   "description": "Plugin for @wolfstar/http-framework distributing gateway events across processes over Redis Streams, with at-least-once delivery",
   "keywords": [
     "broker",

@@ -1,5 +1,31 @@
 # @wolfstar/plugin-gateway
 
+## 0.15.0
+
+### Minor Changes
+
+- [#252](https://github.com/wolfstar-project/plugins/pull/252) [`97aaaea`](https://github.com/wolfstar-project/plugins/commit/97aaaeaeb348f968a8bbb21d43147cbdd35d0bf1) - Add `ApplicationCommand` and its managers, fetch-only like `WebhookManager`: `client.application.commands` (`ApplicationCommandManager`) and `guild.commands` (`GuildApplicationCommandManager`, a new instance on every access, also `client.guilds.commands(guildId)`) have `fetch`, `create`, `set`, `edit`, `delete`, `commandPath` and the static `transformCommand`, which accepts camel-cased data, raw payloads and builders. `ApplicationCommand` has the command's fields, `edit()`, the `set*()` helpers, `delete()`, `permissions`, `equals(command, enforceOptionOrder?)` (`false` for a foreign argument) and the static `optionsEqual()` and `transformOption()`. `ApplicationCommandPermissionsManager` (`fetch`, `has`, and `set`, `add` and `remove` taking an explicit bearer `token`, with no OAuth handling) reads through the existing `applicationCommandPermissions` cache, kept up to date by `APPLICATION_COMMAND_PERMISSIONS_UPDATE`. `GatewayError` gains the `ApplicationCommandPermissionsTokenMissing` and `GlobalCommandPermissions` codes. `set()` is the bulk overwrite and replaces whatever `@wolfstar/http-framework` registered, nothing calls it for you.
+
+- [#250](https://github.com/wolfstar-project/plugins/pull/250) [`10a18a5`](https://github.com/wolfstar-project/plugins/commit/10a18a5af98fcc5fc46dd923334c7d415af8ce3e) - Add `ApplicationEmoji` and `ApplicationEmojiManager`, discord.js's emojis owned by the application rather than a guild, reachable as `client.application.emojis`. The manager is fetch-only (Discord sends no event for these emojis, so nothing is cached): `fetch()` lists them in a `Collection` and `fetch(id)` gets one, with `create`, `edit`, `delete` and `fetchAuthor`. An `ApplicationEmoji` extends `Emoji` with `author`, `application`, `edit`, `setName`, `delete`, `fetchAuthor` and `equals`, which compares only the ID, name and `animated`, the fields the API sends.
+
+- [#255](https://github.com/wolfstar-project/plugins/pull/255) [`1ca7f9e`](https://github.com/wolfstar-project/plugins/commit/1ca7f9e0a2da15a4b77afc7abe338f96e81b7eac) - `channel.messages.crosspost` takes a message or its ID, and `client.channels.createMessage(channel, options)` sends a message to a channel or its ID, like discord.js.
+
+- [#248](https://github.com/wolfstar-project/plugins/pull/248) [`12a880f`](https://github.com/wolfstar-project/plugins/commit/12a880ffa1c3b3f3f2c4d79f197cb893f3fb5045) - Add `Message#threadable`, like discord.js: whether the bot can start a thread from the message (a text or announcement channel, no thread yet, and `ViewChannel` plus `CreatePublicThreads`). It reads the cache, so it is a promise with an asynchronous cache and throws `ChannelUncached`, `GuildUncachedMe` or `GuildUncached` on a miss, like the other message checks. Unlike discord.js, an administrator bot is threadable, as the API allows it.
+
+- [#253](https://github.com/wolfstar-project/plugins/pull/253) [`17d2cfd`](https://github.com/wolfstar-project/plugins/commit/17d2cfd71cd8a5274ef435a96e059cc0d5df2293) - Add the monetization managers. `client.application.entitlements` is an `EntitlementManager`, cached from `ENTITLEMENT_CREATE`, `ENTITLEMENT_UPDATE` and `ENTITLEMENT_DELETE` (which emit the new `entitlementCreate`, `entitlementUpdate` and `entitlementDelete` events), with `fetch()` for one entitlement or a filtered `Collection`, `createTest()`, `deleteTest()` and `consume()`. `client.application.fetchSKUs()` returns the `SKU`s of the application, and `sku.subscriptions` (or `client.application.subscriptions(sku)`) is a fetch-only `SubscriptionManager`. Adds the `Entitlement`, `SKU` and `Subscription` structures, `SKUFlagsBitField`, and the `EntitlementCreateInvalidOwner` error; `EntitlementResolvable`, `SKUResolvable` and `SubscriptionResolvable` now also accept the structures.
+
+- [#245](https://github.com/wolfstar-project/plugins/pull/245) [`7257223`](https://github.com/wolfstar-project/plugins/commit/7257223baea1785c72737e103243ab381f6f29f7) - Add `RegisterAsDispatchListener`, a `RegisterAsGatewayListener` whose listener runs on one process only: the workers replaying the dispatches while the gateway client forwards them, the gateway client otherwise, so a bot loading the same pieces on both no longer handles each dispatch twice. `GatewayClient` gains `forwardsDispatches` and `markDispatchesForwarded()` for `forwardGatewayDispatches` to set, and `DispatchEventName`, `GatewayOnlyEventName` and `gatewayOnlyEvents` tell the events a worker receives from the ones only the gateway client emits, which the decorator rejects.
+
+- [#249](https://github.com/wolfstar-project/plugins/pull/249) [`e55801b`](https://github.com/wolfstar-project/plugins/commit/e55801b8a33b217dc6ef3ad9b17732962136b7ea) - `transformResolved` now also resolves `messages` (IDs read from the cache of the new `channelId` option, raw data resolved to the cached message or built from it) and `attachments` (built as `Attachment`), like discord.js. `MessageMentions#parsedUsers` now includes the users the payload mentions even when they are not cached, as discord.js does by adding them to its cache; nothing is written to the cache.
+
+- [#254](https://github.com/wolfstar-project/plugins/pull/254) [`b787c53`](https://github.com/wolfstar-project/plugins/commit/b787c53f830a01012ee7c6a43df3c744ae187b80) - Check the options of `threads.create` and the guild-only message paths against discord.js. `ThreadCreateOptions` is now `TextThreadCreateOptions | ForumThreadCreateOptions`, so mixing the options of a thread (`type`, `invitable`) with those of a forum or media post (`message`, `appliedTags`) is a compile error, and throws a `GatewayTypeError` before any request instead of being dropped silently: `ThreadOptionsPostOnly`, `ThreadOptionsThreadOnly`, and, in a forum or media channel without `message`, `ThreadPostMessageRequired`. `ChannelThreadManager` and `ChannelMessageManager` take the channel type as an optional last constructor argument (`channelType`), which `channel.threads` and `channel.messages` pass. In a direct message or group direct message, `messages.crosspost`, `messages.bulkDelete`, and `messages.startThread` now throw `ChannelMessagesGuildOnly` before any request, as discord.js's `DMMessageManager` has no such methods.
+
+### Patch Changes
+
+- [#247](https://github.com/wolfstar-project/plugins/pull/247) [`6012bd9`](https://github.com/wolfstar-project/plugins/commit/6012bd9d16cc73abd5e0c866a6ab2d407e3c3b79) - Track the guilds `clientReady` waits for by shard, like discord.js: a shard's new `READY` now replaces the unavailable guilds its previous one listed instead of adding to them, so a guild the bot left between two `READY`s of a shard (a session invalidated during startup) no longer holds `clientReady` back until `waitGuildTimeout`. The client also stops collecting these guild IDs once `clientReady` fired, where every reconnect's `READY` used to add them to a set that was never emptied.
+
+- [#247](https://github.com/wolfstar-project/plugins/pull/247) [`6012bd9`](https://github.com/wolfstar-project/plugins/commit/6012bd9d16cc73abd5e0c866a6ab2d407e3c3b79) - Forward the `guildDelete` of a guild a `READY` drops: when a `READY` no longer lists a cached guild (the bot left it while offline), `GatewayClient` now emits `dispatch` for the `GUILD_DELETE` it applies, after the cache write and with the cached guild as its state, before `guildDelete`. `forwardGatewayDispatches` publishes it like any other dispatch, so a `plugin-broker` worker's `guildDelete` listeners clean these guilds up too. The made-up dispatch carries `s: 0` and is not emitted as `raw`.
+
 ## 0.14.0
 
 ### Minor Changes

@@ -1,6 +1,6 @@
 {
   "name": "@wolfstar/plugin-gateway",
-  "version": "0.14.0",
+  "version": "0.15.0",
   "description": "Gateway (WebSocket) support for @wolfstar/http-framework: a GatewayClient emitting Structures, backed by a pluggable cache",
   "keywords": [
     "discord",

@@ -1,5 +1,11 @@
 # @wolfstar/plugin-subcommands-advanced
 
+## 2.2.1
+
+### Patch Changes
+
+- [#257](https://github.com/wolfstar-project/plugins/pull/257) [`481d536`](https://github.com/wolfstar-project/plugins/commit/481d53697243a48416bc0117bf77c9dbc247f820) - Register modular subcommands (and groups) sorted by name instead of in the order the stores loaded them. The load order is not stable between starts, so the same pieces could produce differently ordered options, and `@wolfstar/http-framework` compares deployed commands by position, which updated every parent with modular subcommands on each start. The first start after upgrading may update those commands once; the order is stable after that. Subcommands the parent declares itself keep their place before the registered ones.
+
 ## 2.2.0
 
 ### Minor Changes

@@ -1,6 +1,6 @@
 {
   "name": "@wolfstar/plugin-subcommands-advanced",
-  "version": "2.2.0",
+  "version": "2.2.1",
   "description": "Plugin for @wolfstar/http-framework to modularize slash subcommands into separate command classes",
   "keywords": [
     "discord",