Record how JavaScript reaches the schema prose - #3
Merged
Conversation
@idfkit/schemas gains SchemaBundle.loadProse and SchemaBundle.prose, so a consumer holding the shared name can obtain the prose pool that describeObjectType and the language service already accept. Two names, both divergent, both recorded here before review rather than after. The divergence is the same one SchemaBundle.load already carries against get_schema, and for the same reason. JavaScript deduplicates every memo and note of all seventeen schemas into one side file the manifests index into, and reads it on demand; Python ships the full schemas on disk and reads note and memo off the record it already holds. There is nothing for Python to load and no moment at which to load it. This is not a capability difference and must not be read as one. describe_object_type reports the same prose in both languages, and the corpus compares a digest over every memo and note of all 858 types in 26.1.0. Only the moment of loading differs, which is what `divergent` is for. The gate does not require these. Its coverage reaches the names an entry point exports at the top level, and a method on an exported class sits outside that, as check-naming-register.mjs says in its own header: caught by review, not by the gate. They are registered because Principle I is about the vocabulary rather than about what the gate can see, and because leaving them out is how a Python counterpart gets added later without anyone noticing the difference was decided.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two register entries for
SchemaBundle.loadProseandSchemaBundle.prose, the pair that lets a consumer of the shared name obtain the prose pool.Why the entries
The divergence is the one
SchemaBundle.loadalready carries againstget_schema. JavaScript deduplicates every memo and note of the seventeen schemas into one side file the manifests index into, and reads it on demand. Python ships the full schemas on disk and readsnoteandmemooff the record it already holds, so there is nothing to load and no moment at which to load it.Not a capability difference.
describe_object_typereports the same prose in both languages and the corpus compares a digest over every memo and note of all 858 types in 26.1.0. Only the moment of loading differs, which is whatdivergentis for.Why they are here at all
The naming gate does not require them. Its coverage reaches the names an entry point exports at the top level, and a method on an exported class sits outside that reach, as
check-naming-register.mjssays in its own header: caught by review, not here. They are registered because Principle I is about the vocabulary rather than about what the gate happens to see, and because omitting them is how a Python counterpart gets added later without the difference having been decided.Sequencing
This does not block the code. Because the gate cannot see class members, the implementation in idfkit-js passes
check:namingwith or without this PR, so the two can land in either order and no new governance tag is needed before the code. That is different from feature 005, where the names were top-level exports and the tag was a hard prerequisite.A
governance-2026.12tag is still wanted so the rendered naming map carries these rows, but nothing is red while it waits.Verification
The parity ledger is untouched: this adds no capability. The corpus level does not move.