Conversation
NSchatz
force-pushed
the
changeset-release/main
branch
2 times, most recently
from
September 8, 2026 05:54
fee9cd4 to
9b988f3
Compare
NSchatz
force-pushed
the
changeset-release/main
branch
from
September 8, 2026 17:02
9b988f3 to
90a4e83
Compare
Contributor
Author
|
Closing on the maintainer's instruction ahead of the coordinated 0.1.0 suite release. Nothing is lost: every pending declaration still sits in .changeset/ on main, and this PR is regenerated from them. The release is being cut for the whole suite in one pass, and the release pipeline itself is being corrected first. Do not merge a regenerated version of this PR piecemeal. |
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.
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
@cosyte/synth@0.0.10
Patch Changes
32fd419: The repository's PHI commit-gate (
pnpm phi-scan) no longer honours a whole-file--allow-fixturebypass. A path the run enumerated and then did not open is now refused (exit 2) and named on stderr, because a scan that did not read a file has no clean verdict to give about it. The flag and itsphi-scan-overrides.mdlog are both kept, so an attempt is still recorded and reviewable; what it can no longer do is produce a clean report.This changes an observable exit code for an existing invocation shape: an argv carrying
--allow-fixturethat used to exit 0, or to exit with the hits code, now exits 2 in every mode,--stagedincluded. Declaring a genuinely synthetic value inscripts/phi-allow-list.txtis the way to clear it, and unlike a whole-file bypass it leaves the file in the sweep. Nothing a consumer installs is affected: no generator, export, warning code or published artifact changes.9b69baf: The synthetic-safety floor table now cites, for every locus, the authority that reserves the range or defines the check digit, by that authority's own published identifier and with the sentence the row rests on, so you can open the text and check the claim instead of taking the page's word for it. Where a row was previously grounded on a bare hostname (
ssa.gov,nanpa.com) or on nothing at all, it now names a document: SSA POMS RM 10201.035, IRS Internal Revenue Manual 3.21.263, 69 FR 3434 (FR Doc 04-1149), the NANPA 555 Line Numbers page, RFC 2606, RFC 6761, RFC 5737, RFC 3849, and USPS Postal Facts.Two justifications were wrong and are corrected rather than restated. The NPI check-digit rule was attributed, with no citation, to a "CMS NPI check-digit rule, ISO 7812". The rule that requires the
80840-prefixed Luhn check is the final rule at 69 FR 3434 (FR Doc 04-1149, docket CMS-0045-F), and the doc comments onNPI_LUHN_PREFIX,npiCheckDigitandisSyntheticNpinow cite it. Only the ISO half of the old attribution is retracted: the rule names no ISO document number, and what replacesISO 7812is the rule's own name for the algorithm, "the ISO standard Luhn check digit algorithm", a modulus 10 double-add-double algorithm. The CMS half stands and is now cited instead of asserted, that document recording its issuing agency as "Centers for Medicare & Medicaid Services, HHS" and stating that "The specification for calculation of the NPI check digit will be made available on the CMS Web site". The SSN row said SSA "never issues" the areas it draws from; what SSA's manual states is that those areas identify an invalid SSN, defined there as one SSA never assigned, so that is what the row andisSyntheticSsnnow say.Three limits that were implicit are now stated on the surface a consumer reads.
deaCheckDigitimplements is quoted from a pharmacy journal article (PMC3847977), not from the DEA, and no DEA-published statement of the algorithm is cited anywhere in this package.isSyntheticDeareturningtruemeans "fails that formula", not "the DEA could not have issued this", and both doc comments now say so, together with the consequence: if the formula is wrong, a value built to fail it could pass the real check.00501; that00000is therefore unassigned is this package's inference, not a Postal Service statement.The claim that
2.16.840.1.113883.19is a designated example root has been dropped fromSYNTHETIC_ASSIGNING_AUTHORITY: no published designation could be shown, so none is claimed. The OID is unchanged and the guarantee never rested on it.No generated value changes. Every reserved range, check-digit computation and predicate result is byte-for-byte what it was, so a pinned golden corpus is unaffected: this release changes what the package says about its floors, not where it draws from. A new suite fails the build if a floor-table locus is ever added without an authority identifier and the supporting text to go with it.
7daedf4: Seed determinism is now verified ACROSS Node majors, not just twice inside one process. Until now every determinism assertion in this repository generated the same seed twice in a single Node process and compared the two, and a single process cannot disagree with itself about the engine it is running on. A change in the JavaScript engine that shifted number formatting, sort stability or key order between Node majors would have landed with every check green, while a consumer's committed golden file quietly stopped matching.
On every change, a declared seed corpus covering all six formats is now generated in its own job on Node 22 and on Node 24, each job carries out one digest per
(format, seed)pair and nothing else, and a third job fails the build if the two engines disagree. A mismatch is reported by seed, format and engine identity; the differing bytes are never printed, because the corpus is reproducible from the seed. There is no tolerance on a digest, no warning-only mode and no suppression list. Taking a pair out of the compared set means naming it and its reason in a committed declaration, which every report republishes.Each per-engine run is also measured against a committed baseline for the current compatibility window, so a toolchain or dependency change that moves every engine together, the one thing a cross-engine comparison is blind to, is caught as well. That baseline cannot change without a release declaring a breaking change, so a golden fixture pinned to a version inside the window keeps matching.
docs-content/limitations.mdnow states which Node majors the seed-to-bytes mapping is verified byte-identical across, that the verification is a digest comparison across separate runs, and that a change to that mapping is released as a breaking change.Nothing about what the generator emits changed. Same seeds, same bytes.
8389346: You can now ask for a FHIR fixture by US Core 6.1.0 profile name instead of by generator name, and the answer is one of exactly two things: an artifact claiming that profile, or a refusal raised before any artifact exists.
New exports on
@cosyte/synth/fhir:usCoreCoverage()reports one entry for every one of the 49 resource profiles the adopted implementation guide publishes, each carrying its canonical URL and whether this build generates it;generateUsCoreProfile({ profile, seed })resolves the requested name against that closed set before generating anything.US_CORE_ADOPTED_PROFILES,US_CORE_PROFILE_BASEand theUsCoreProfileId/UsCoreProfileCoveragetypes are exported alongside them. Identifiers only, as ever: no implementation-guide content is bundled.The two refusals are deliberately different codes, because they are different facts about your request.
SYNTH_PROFILE_NOT_GENERATED(new) says the guide publishes the profile and this build does not generate it yet.SYNTH_UNSUPPORTED_KINDsays the name is not in the adopted set at all: a typo, a blank, a value that is not a string, or one of the guide's extension definitions, which are not standalone artifacts. Neither quotes your value back, and neither returns a mislabelled artifact.Coverage moves from 10 profiles to 11:
generateProvenance()generates a US CoreProvenance, built through@cosyte/fhir's model constructors like every other resource here, and validated against the publishedus-core-provenanceStructureDefinition with zero errors over arbitrary seeds. The other 38 adopted profiles are reported as uncovered and refuse: this release closes the contract, not the breadth.The conformance suite is now driven by the coverage surface rather than by a list kept beside it, so a profile reported as generated with no committed StructureDefinition behind it fails the suite instead of being skipped.
fd8c32d: Generated FHIR R4 output is now graded by a validator that is not ours. Until now, every "spec-clean" claim this package made was the sibling parser reading back what the sibling parser wrote: a strong structural property, and one that cannot see a misreading of a standard that the builder and the reader share. On every change, the HL7-maintained FHIR validator, pinned by version and by content digest, now validates a seeded corpus of generated FHIR R4 resources against US Core 6.1.0, and any issue it reports at severity
errororfatalfails the build. There is no severity downgrade, no warning-only mode and no suppression list.The run publishes a coverage declaration alongside its verdict. It names every format the library generates and marks each one either independently graded, with the grader named, or ungraded, with a reason, and it is built from the set of formats the generators actually emit rather than from a hand-kept list, so a format cannot ship without that judgement being made. Today FHIR R4 is the graded one; HL7 v2, C-CDA, X12, NCPDP and ASTM carry only the sibling parser's round-trip, and the declaration says so in those words. The verdict also records the validator version, the package version, and every external endpoint the run was configured to contact.
docs-content/limitations.mdgains the distinction a consumer needs to read the promise correctly: which formats carry an independent external verdict, which carry only a round-trip, and what the external verdict deliberately leaves out (it runs with no terminology server, so code membership in a value set is not part of it).Nothing about what the generator emits changed. Same seeds, same bytes.
f6d18d7: Synthetic SSNs now clear both federal authorities that share the SSN number space, not just SSA's. An IRS ITIN is itself an SSN-format number beginning with
9, so the never-issued900-999area alone never ruled one out: 44 of the 100 group values placed a generated value inside a published ITIN group range, and the fixed advertising block sat inside one for every seed.safe.ssn()now draws its group only from values outside every published ITIN group range (and outside the two the IRS reserves for other programs), and its fixed block is987-00-4320through987-00-4329. No draw can produce an ITIN-shaped candidate, so generation still returns a value for every seed.New exports:
isItinFormatted(value)andITIN_GROUP_RANGES, so a consumer can assert the second half of the guarantee directly (isSyntheticSsn(v) && !isItinFormatted(v)). The synthetic-safety sweeps for HL7 v2, FHIR, C-CDA, X12, the cross-format suite and the de-identification pairing loop now fail on an ITIN-formatted value at an SSN-bearing locus, over arbitrary seeds.ssn(rng, "advertising")keeps its name and its shape (a fixed ten-value display block) but loses one property: its old value was the block the Social Security Administration itself prints in advertising, and that block is ITIN-formatted, so it could not stay. If you chose that option because the number is the one SSA publishes, it no longer is. The option name is unchanged so no call site breaks.If you pin a golden corpus: this changes more than the SSN field. The default block now takes one random draw fewer than before (a single pick from the safe group pool replaced two independent group digits), so every value drawn after an SSN in the same seeded stream moves too: identifiers, codes, amounts and timestamps in an affected artifact all regenerate with different bytes, not only its SSN.