Module gotify 

Gotify inbound-integration wire types.

A forge session subscribes to a Gotify server via the mcp__forge__gotify__* tool family; matching notifications deliver as a user-turn into the durable subscriber. These are pure data shapes - the stream, REST lookups and match-and-route logic live in forge-connectors::gotify, which reaches workspace state through its host port, and the subscription store in forge-workspace::store::gotify.

Re-exports

use serde::Deserialize; 🔒

use serde::Deserialize; 🔒

use serde::Serialize; 🔒

use serde::Serialize; 🔒

Structs

GotifyConfig

Connection to a Gotify server, parsed from the [gotify] block of forge.toml. One server per v1. Unknown keys are rejected so a mistyped client_token fails the load instead of leaving the connector tokenless.

GotifyMessage

A notification decoded from the Gotify server’s WebSocket stream.

GotifySubscription

An active subscription: which project (and optional team-worker role) receives notifications matching the applications + min_priority filter. Durable ones persist to redb; ephemeral ad-hoc-worker ones stay in memory only.

GotifySubscriptionRepr 🔒

Deserialization shape, tolerant of the v0.20.0 record that stored a single application: Option<String> and no applications key. A non-null legacy application folds forward into applications; a null or absent one leaves the empty match-any set. Serialization always emits the current applications shape (this is deser-only).