Soul F3 and F4, and F1 in CultMesh's schema descriptor.
- The schema descriptor built from a definition uses schemaIdentityOf, so
a handle's schema id is the id the cache stamps.
- Store documents (F3): a handle reads the record under its schema id, or,
for a definition, under an id the definition lists as compatible, as the
cache resolves it. The catalog-entry name/version match and both parse
fallbacks are deleted: a record under another id is not this document,
whatever its payload parses as.
- Peer snapshots (F4): syncDocumentFromPeerSnapshot and definition-named
peer-snapshot handles take the peer's record at the key under the type's
schema id only. The shape filter is deleted and no match is not-found.
P8a (syncing A at k while the peer holds only B at k overwrote the local
B and then threw) and P8b (a peer's C stored as A) write nothing now.
- HELD: a peer-snapshot handle named by a bare schema-id string still takes
the first record at the key. Eve Electron reads the C# Aetheria daemon
that way (EveElectron src/cultmesh-provider-client.mjs:129-142): the
daemon stamps SHA-256 schema ids and the client asks by
"gamecult.eve.provider_advertisement.v1", so only the fallback finds its
records. How a TS reader names a C#-hosted schema is raised as a fork;
the fallback goes when it is ruled.
Tests: the store- and peer-snapshot tests that asserted shape routing are
replaced by tests of the refusal, including P8a and P8b, and one that pins
the held fallback.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
9118e24976