//! The hive-notices stream: its name and subject shape.
//!
//! A hive that publishes and a swarm-level reader that consumes live in
//! different crates, and a literal name repeated across both is an agreement
//! nothing checks.
//!
//! **This is a stream, not a bucket.** The hive-status snapshot has a current
//! value, so a KV bucket (last value per key) is the right shape. A lifecycle
//! notice ("container crashed at 04:12") has no such steady state: miss the
//! message and nothing left to read later says it happened. That needs durable
//! delivery (a `JetStream` stream a consumer acks against), which
//! `swarm_queue_client::notices::open_or_create` opens.

/// The stream a hive publishes lifecycle notices into.
///
/// A constant and not an option, like every bucket name here:
/// reader and writer must name the same stream, and letting either side
/// pick its own name is how two deployments end up disagreeing about
/// which stream a notice actually landed in.
pub const STREAM: &str = "hive-notices";

/// Build the subject a given hive's notices publish to.
///
/// Every hive's notices land under `STREAM`, one subject per hive:
/// `hive-notices.<hiveName>`.
///
/// Not one subject per notice *kind* — a consumer that wants a specific
/// hive's notices subscribes to `subject(hive)`; one that wants the whole
/// swarm's subscribes to `{STREAM}.>`. The kind travels inside the message
/// payload instead, so adding a new notice kind is never a subject-design
/// change. Deliberately reuses `STREAM` rather than a second `PREFIX`
/// constant with the same value — one name for one fact, same reasoning
/// the module doc above gives for a shared `const` over a repeated literal.
#[must_use]
pub fn subject(hive: &str) -> String {
    format!("{STREAM}.{hive}")
}