vendor/README.md declared cultcache-rs, cultnet-rs and cultmesh-rs "a locally
owned compatible protocol generation". That charter is the defect. A consumer
holding its own generation of the wire stack sits outside the only harness that
checks cross-runtime agreement, and the fork behaved exactly as that predicts:
runtime_authority_contracts.rs drifted to e542225 while this repo's own
authority map named f4ab237, and the Rust CultMesh implementation existed
nowhere else in GameCult.
All three now come from CultLib pinned at 85f7024, and 19,604 lines of forked
substrate are deleted. Nothing was lost on the way out. The vendored cultnet
tree was compared file by file against CultLib: ten of twelve matched, lib.rs
differed only in module declarations, and transport.rs carried one guard that
existed nowhere else -- a framed length checked against the advertised maximum
before allocating. That guard is now CultLib 85f7024 with a test.
The migration this was expected to need does not exist. RuntimePresenceCorrelation
changing from enum to struct is Odin's side of the contract and no file here
touches it; with line endings normalised the two contract copies differ by 132
lines, and the only production change that reaches a provider is
IdunnExpectedRoute requiring rudp:// schemes for rudp transport, which this
service does not use. The code compiles unchanged.
89 tests pass across the workspace against the pinned rev.
vendor/ still holds the cultcache-py and eve submodules. cultcache-py is the
same pattern -- a runtime-specific repo CultLib also carries as
packages/cultcache-py -- but it backs the state tooling rather than the
daemon, so it is left for its own change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
d0510ac85b