pub struct InboxDoc {
pub entries: Vec<InboxEntry>,
pub window: Option<Window>,
pub boundary_request: Option<VerbRequest>,
pub sync_request: Option<VerbRequest>,
}Fields§
§entries: Vec<InboxEntry>§window: Option<Window>§boundary_request: Option<VerbRequest>“Please publish” from outside the pod (§2.5). Deliberately a
FIELD and not a fake no-object InboxEntry: consume_inbox
HEADs file_key(path) for every entry, so an entry naming no
object lands in the NotFound arm as a spurious
consume-object-missing conflict — and special-casing the
single most safety-critical function in the crate to avoid that
is worse than either.
sync_request: Option<VerbRequest>“Please pull” from outside the pod — CARRIED, never performed
(D14). A boundary publishes what is already on disk and touches
no local file; sync re-derives the tree against the current
remote manifest and DELETES local files for remotely-deleted
paths. Performing that on a remote’s say-so would upgrade what a
leaked gateway bearer can do from “publish, plus hand over these
N named objects” to “rewrite and delete across a running agent’s
tree, at my timing, under a scope I choose”.