swarm-controller, hive-c0re: the module docs still describe one shared bucket

Both were prose about the model this branch replaces, caught in review.

`swarm-controller/src/wanted.rs` was the worse of the two: its header
called the lifecycle "deliberately identical" to `status` and the handle
"resolved on first use and cached", while `store`'s own doc seventy lines
below says "resolved per call rather than cached". One file, two
contradictory claims, and the `OnceCell` that would have settled it is
gone. Rewritten to say where the mirror stops rather than to patch the
stale clause, since the divergence is the point of the change.

`hive-c0re/src/workers/wanted.rs` named a `hive-wanted` bucket that no
longer exists.

Swept by content rather than fixing only the two that were named: the
sweep surfaced a third candidate, `swarm-nats-auth/src/policy.rs`'s
"one key per hive", and reading it cleared it — that sentence is about
the hive-status bucket, whose shape is unchanged. Left alone
deliberately.
This commit is contained in:
atlas 2026-09-02 21:30:15 +02:00 committed by mara
commit c5b86afcb0
2 changed files with 7 additions and 4 deletions

View file

@ -1,6 +1,6 @@
//! Converging this hive onto the agent set the swarm controller declares.
//!
//! The controller writes one key per hive into the `hive-wanted` bucket (see
//! The controller gives each hive its own `hive-wanted-<hive>` bucket (see
//! [`swarm_queue_client::wanted`]); this reads its own and acts on it. It is
//! the **repair** path, not the fast one: a deploy event
//! ([`crate::swarm_status`]) is core NATS, so a hive that was down never hears

View file

@ -2,9 +2,12 @@
//!
//! The mirror of [`crate::status`]: that module reads what hives report,
//! this one writes what they are told, and both address the same queue.
//! The lifecycle is deliberately identical — a NATS client rather than a
//! bucket handle, resolved on first use and cached, so a controller that
//! starts before the bucket exists picks it up without a restart.
//! Both hold a NATS client rather than a bucket handle, so a controller
//! that starts before a bucket exists picks it up without a restart.
//!
//! Where the mirror stops is the handle itself: `status` resolves one on
//! first use and caches it, while there is one wanted-state bucket **per
//! hive**, so no single handle serves them and `store` resolves per call.
//!
//! The bucket is the record. Nothing here keeps a second copy of the
//! declaration to reconcile against, because the current value can be read