New library crate crates/muninn-contracts holds the records Muninn owns
(telemetry surface, capture stream and command, OBS catalog, Move marker
candidate, controller state, identity, light command, hue program,
tracker health and evidence transport health, HID controller state,
Quest access, command boundary, transport profile), their schema
constants, and the MuninnRecords document set. The definitions are the
odin-core ones moved verbatim; the wire is unchanged.
muninn and sleipnir import the records from here, so both link one
definition. muninn registers MuninnRecords after OdinDocuments, which
stays because it still carries Odin's own records and stale copies of
the same schema ids. Muninn's odin-core imports are now
EveProviderAdvertisementRecord, EveSurfaceStateRecord and OdinDocuments.
Tests pin every type name and schema id, the document-set bindings, and
the positional wire layout of two records.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Odin main's Sleipnir was written against CultLib a8aedda, and its two
CultNetRudpSocketTransportOptions initialisers do not compile at
Muninn's c2a9a6e pin. media_delivery: None is the field's default, so
behaviour is unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The drift was 94 hunks across 4 files, not 94 files as I described it earlier.
muninn-daemon carries almost all of it; sleipnir-daemon needed four lines.
Checked rather than assumed. Ignoring whitespace, the only remaining deltas are
trailing commas rustfmt adds when it wraps an argument list, and braces removed
from single-expression closure bodies. Both are semantics-preserving.
sleipnir-daemon's change is whitespace and nothing else.
Everything except the Unix-only odin-daemon builds; muninn and sleipnir pass 162
tests, with the same pre-existing media-channel failure.
vendor/cultmesh-rs is its own workspace so `cargo fmt` does not reach it, but it
reports no drift of its own.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The CultNet submodule and the in-tree CultCache copy are gone. Both now come
from CultLib, and vendor/cultmesh-rs is the only fork left -- it too consumes
CultLib, so exactly one version of each crate spans the graph. That mattered:
mixing sources would have put two cultnet-rs crates in one build, and the types
would not have unified.
The in-flight CultMesh RUDP document server comes with it because it is a
prerequisite, not a coincidence. The previously committed CultMesh calls
assume_connected(), a CultNet method Odin's fork carried and CultLib does not,
so the old code cannot build against CultLib at all. The newer code no longer
calls it. Verified by reverting the file and watching it fail.
Three API differences needed adapting: CultLib's transport options carry a
reconnect_policy the fork lacked (7 sites), its create_ack builds the packet
straight from ack state and so cannot fail, and its transport profile owns each
channel's reliable expiry.
Everything but odin-daemon builds; odin-daemon is Unix-only and does not compile
on this machine either way. muninn and sleipnir pass 162 tests. The one failure,
rudp_media_transport_options_follow_low_latency_profile, expects an Unreliable
media channel while every CultNet lineage including both revisions Odin had
pinned declares it Reliable, so it failed before this change too.
The in-flight idunn-daemon work is deliberately left uncommitted; the committed
tree was verified to build without it. Also left alone: the untracked
odin-daemon crate and deployment recipe, and the root manifest, whose now-dead
vendor excludes are inert. That recipe still requires the vendor/cultnet-rs
gitlink and will refuse admission until that line is dropped -- the fix is in
the working tree, waiting on that directory being tracked.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
