The previous revision assigned provider ingress and live-publication acceptance
to Odin, and described Hermodr as a second Odin holding a parallel instance of
the same store. Both claims were wrong, and the second was asserted without
checking.
Odin is a rendezvous organ. It publishes what state is available, what schema
speaks it, and where to reach it. It is not in the data path, and it never
carried this state: neither odin-coordinator.cjs nor any Odin test references
OdinLivePublicationSource or provider-session-ingress.cjs. Those modules are
Hermodr's own state machinery wearing Odin's name and filed under src/odin/,
which is what made it read as sanctioned.
So there is no second Odin. There was never a first one for this state. The cut
is not to hand acceptance back to Odin, which does not want it, but to delete it
and have Hermodr resolve providers through the catalog and subscribe to them
directly.
The command path already models this correctly. findProviderCommandRoute looks a
route up in the catalog and publishes to the provider's own endpoint, and
Erycina's surface names Odin as discoveryOwner while pointing canonicalSurfaceUri
at Erycina's own address. The retrofitted leg got the architecture right; the
original state leg did not.
Dependency picture corrected by actual reference counts. Only documents.cjs and
idunn-rudp.cjs are genuinely shared with the coordinator. utils.cjs,
live-publication-source.cjs, and provider-session-ingress.cjs are Hermodr-only
and leave with it or are deleted, which shrinks src/odin/ from fourteen modules
to ten and removes the documents.cjs decision from the critical path of
everything else.
Negative checks now include the one that matters for the corrected model: with
Odin stopped, existing provider subscriptions must keep delivering. If they do
not, Odin is in the data path and the plan failed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
9282ea9dd6