Generated schema source for namespaced-domain-id contains:
new RegExp("[a-z0-9]([a-z0-9-]*[a-z0-9])?(\\\\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)+/[A-Za-z0-9_.-]+")
That string literal is \\. at runtime — a literal backslash followed by any character — instead of \. (escaped dot). Every string with a dot in the registrant part is rejected: domainIdSchema.safeParse("example.com/rooms") fails, as does "dev.exadev.agent-comms/mesh" and any private-use domain (x-foo passes only because it has no escape). private-use-domain-id has the same double-escape wherever the source pattern carries one.
Root cause: the .cddl source writes the XSD regex in a CDDL text string, where \\. is the string-level escape for \. (RFC 8610: the .regexp value is an XSD regular expression carried as a text string). The vendored lexer hands the emitter the raw token text (\\. — two backslashes), and the emitter passes it through JSON.stringify, preserving both. The emitter needs to unescape CDDL text-string escapes when consuming a literal destined for .regexp (at least \\\\→\\; the XSD-to-JS regex translation is otherwise compatible for the classes the spec uses).
Why nothing caught it: wire-mesh's conformance vectors only exercise core/* domains, which are plain literals in the schema's union — the regex branches have no vector coverage. Found while consuming the generated schemas from agent-comms (the first real namespaced-domain user: dev.exadev.agent-comms/mesh failed handshakeFrameSchema validation).
Repro: node -e "import('./dist/generated/protocol.mjs').then(m => console.log(m.domainIdSchema.safeParse('example.com/rooms').success))" in a wire-mesh checkout's ts/packages/core — false.
Generated schema source for
namespaced-domain-idcontains:That string literal is
\\.at runtime — a literal backslash followed by any character — instead of\.(escaped dot). Every string with a dot in the registrant part is rejected:domainIdSchema.safeParse("example.com/rooms")fails, as does"dev.exadev.agent-comms/mesh"and any private-use domain (x-foopasses only because it has no escape).private-use-domain-idhas the same double-escape wherever the source pattern carries one.Root cause: the .cddl source writes the XSD regex in a CDDL text string, where
\\.is the string-level escape for\.(RFC 8610: the .regexp value is an XSD regular expression carried as a text string). The vendored lexer hands the emitter the raw token text (\\.— two backslashes), and the emitter passes it throughJSON.stringify, preserving both. The emitter needs to unescape CDDL text-string escapes when consuming a literal destined for.regexp(at least\\\\→\\; the XSD-to-JS regex translation is otherwise compatible for the classes the spec uses).Why nothing caught it: wire-mesh's conformance vectors only exercise
core/*domains, which are plain literals in the schema's union — the regex branches have no vector coverage. Found while consuming the generated schemas from agent-comms (the first real namespaced-domain user:dev.exadev.agent-comms/meshfailedhandshakeFrameSchemavalidation).Repro:
node -e "import('./dist/generated/protocol.mjs').then(m => console.log(m.domainIdSchema.safeParse('example.com/rooms').success))"in a wire-mesh checkout's ts/packages/core — false.