test(schema): bidirectional guard on the OSS/FULL problemspec variant split - #216
Merged
Conversation
… split packages/schema/schemas/ vendors two problemspec variants -- FULL (emitted from PRIVATE Piccolissimo, and the one registered as the `problemspec` kind) and OSS (emitted from public Piccolo, for Phase-3 package-access staging). Piccolo's suite asserts the schema IT emits carries no private capability names, but nothing on this side asserted the vendored COPIES stayed distinct. A re-vendor that wrote the FULL schema over the OSS filename -- or an OSS build that shipped FULL -- would expose six private capability names, and every existing test would still pass, because both files parse and validate identically well. That is a silent open-core leak, and it is exactly the failure mode the two-variant design exists to prevent. Deliberately BIDIRECTIONAL. Asserting only "OSS lacks the private names" would still pass if someone vendored the OSS schema over BOTH filenames, quietly narrowing the shipped schema so it rejects specs Piccolissimo can really run. So this asserts the private names are absent from OSS AND present in FULL, that the files differ, that FULL-minus-OSS is EXACTLY the known private set (a new private capability added without listing it here trips this), and that OSS introduces nothing FULL lacks (which would mean the variants were built from divergent revisions). Compares enum/const VALUES rather than raw text, so public names that merely contain a private substring cannot false-positive. Verified it fails closed: copying the FULL schema over the OSS filename fails 3 of 5 assertions and names all six leaked capabilities. schema suite 97/97 (was 92, +5).
The five set-difference assertions here cannot see an OSS schema that starts
offering the paid `exponential`/`spline` integrator backends — the exact leak
this file exists to prevent.
`enumValues` flattens every enum in the document into one Set, so a value
becomes invisible to it once that value appears anywhere. `exponential` and
`spline` ALREADY appear in the OSS schema, inside a conditional:
`allOf[3].then` requires `integrator.kind ∈ {exponential, spline}` for a spline
pulse. So they are members of `ossEnums` even though the OSS schema does not
OFFER them in the enum a caller picks from, they cancel out of `onlyInFull`,
and the widening is undetectable by set difference.
Verified fail-closed: injecting the leak (OSS integrator.kind enum widened to
["bilinear","exponential","spline"]) fails the two new assertions while ALL
FIVE original ones still pass.
So the real FULL − OSS capability delta is eight, not the six in PRIVATE_ONLY.
The two integrator backends need their own positional assertion because, unlike
the six, they are not absent from the OSS document — merely not offered.
Reaching into a fixed schema path is deliberately brittle: if the shape moves
this should fail loudly and make someone re-derive the guard, rather than
silently stop guarding.
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
2 participants
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.
Small follow-up to #212 (already merged). One new test file, no source changes.
packages/schema/schemas/vendors two problemspec variants — FULL (emitted from private Piccolissimo, and the one registered as theproblemspeckind) and OSS (emitted from public Piccolo, vendored for Phase-3 package-access staging). Piccolo's own suite asserts the schema it emits carries no private capability names, but nothing on this side asserted the vendored copies stayed distinct.A re-vendor that wrote the FULL schema over the OSS filename — or an OSS build that shipped FULL — would expose six private capability names (
altissimobackend,continuation/stagedstrategies,hermite_bending_energy/hermite_c2objectives,robustwrapper), and every existing test would still pass, because both files parse and validate identically well. Silent open-core leak, and precisely the failure the two-variant design exists to prevent.Why bidirectional
Asserting only "OSS lacks the private names" would still pass if someone vendored the OSS schema over both filenames — quietly narrowing the shipped schema so it rejects specs Piccolissimo can really run. So the test asserts:
FULL − OSSis exactly the known private set — so adding a new private capability without listing it here trips the test;It compares
enum/constvalues rather than raw text, so public names that merely contain a private substring can't false-positive (SplinePulseProblem,cubic_spline,magnus_*are all legitimately public).Verified fail-closed
Copying the FULL schema over the OSS filename fails 3 of 5 assertions and names all six leaked capabilities in the message. Restored after.
@amicode/schema104/104.🤖 Generated with Claude Code