strictspec@v0.3.0

Generated code pairs with its runtime by generated-code format rather than by release, the Go module path moves to github.com/stricttools/strictspec/go, and the specification pages move under .stricttools/docs/.

Context

Until this release a generated validator paired with the exact strictspec
release that produced it, and refused any other. Under the ecosystem's
floor-only dependency rule that made every strictspec release an import-time
outage for every already-published consumer: the consumer's install resolved the
new runtime, the committed validator demanded the old one, and nothing the
consumer imported worked until the whole chain regenerated and re-released. It
was observed on 0.2.5.

Pairing is now on a generated-code FORMAT. Generated code declares an integer
GENERATED_CODE_FORMAT describing the shape of the emitted code, bumped only when
that shape changes; every runtime declares the inclusive range of formats it
reads; and pairing succeeds whenever the declared format is in that range,
whatever release produced the file. The GENERATED_BY release stamp stays in the
emitted file as information only, and no tool derives a dependency floor from
it. Generated code written before the format declaration existed declares no
format and is refused with the same regeneration remedy -- never read as format
1 -- so every consumer regenerates exactly once. The bump discipline is
mechanical rather than a convention: the conformance suite pins the emitted
shape of all three targets and fails any change to it that does not move the
format.

Two moves ride along. The repository was transferred to the stricttools
organisation, so the Go module path is now
github.com/stricttools/strictspec/go. Everything published under
github.com/smm-h/strictspec/go stays resolvable through the module proxy, and
GitHub redirects the transferred repository, but new versions publish under the
new path alone -- so a Go consumer changes its imports once, and regenerates its
committed validators, whose own import line names the module too. The emitted Go
shape therefore moves in this release while the generated-code format does not:
the runtimes read the same shape, and bumping the format would refuse every
Python and TypeScript validator already in the wild over a change that never
reached their emitted code.

The specification pages moved from spec/ to .stricttools/docs/, the layout
selfdoc now requires, with the generated pages under
.stricttools/docs-state/pages/ and the tool's own state under
.stricttools/docs-state/. The published site's addresses are unchanged. Inside
the repository the three error-code generators and their freshness tests read
the appendix at its new path, and prose that said spec/ when it meant the
specification says so in words now.

Breaking

• [go-strictspec] Generated validators now pair on a generated-code format, not on the strictspec release. Regenerate every committed validator once with strictspec gen after upgrading: a validator generated before this release declares no format and panics at init, naming regeneration as the remedy. From then on, upgrading the Go runtime only breaks generated code when the generated-code format itself changes -- an ordinary release no longer forces a regeneration.
• [py-strictspec] Generated validators now pair on a generated-code format, not on the strictspec release. Regenerate every committed validator once with strictspec gen after upgrading: a validator generated before this release declares no format and raises PairingError at import, naming regeneration as the remedy. From then on, installing a newer strictspec only breaks generated code when the generated-code format itself changes -- so a published package no longer starts failing at import the day strictspec releases.
• [ts-strictspec] Generated validators now pair on a generated-code format, not on the strictspec release. Regenerate every committed validator once with strictspec gen after upgrading: a validator generated before this release declares no format and throws PairingError at module init, naming regeneration as the remedy. From then on, installing a newer strictspec only breaks generated code when the generated-code format itself changes -- so a published package no longer starts failing on import the day strictspec releases.
• [go-strictspec] The Go module path moved. strictspec's repository was transferred to the stricttools organisation, so the Go module is now github.com/stricttools/strictspec/go. Versions already published under github.com/smm-h/strictspec/go stay resolvable -- the module proxy keeps serving them and GitHub redirects the transferred repository -- but new versions publish under the new path alone, so an import left on the old path stays frozen at the last version released there. Change every import from github.com/smm-h/strictspec/go/strictspec to github.com/stricttools/strictspec/go/strictspec, run go get github.com/stricttools/strictspec/go/strictspec@latest, and regenerate every committed Go validator with strictspec gen so its own import line moves too.

Features

• [go-strictspec] Documentation joins the unified site at https://smmh.dev/strictspec/, and the project describes itself consistently. The Go runtime package's doc comment now opens with the same one-line definition the site, the README and the registries carry.
• [py-strictspec] Documentation joins the unified site at https://smmh.dev/strictspec/, and the project describes itself consistently. The PyPI package now states what strictspec does and links its docs, repository, issues and changelog.
• [ts-strictspec] Documentation joins the unified site at https://smmh.dev/strictspec/, and the project describes itself consistently. The npm package now states what strictspec does and declares its homepage, issue tracker and keywords.

Fixes

• [go-strictspec] The Go module now says what strictspec does in one line, everywhere it is read. The package doc comment and the module README open with the same sentence the site and the other packages carry, so go doc and pkg.go.dev no longer describe strictspec differently from the docs site.
• [py-strictspec] The PyPI package now says what strictspec does in one line. Its description and README open with the same sentence the docs site and the other packages carry, so the project no longer describes itself differently on each registry.
• [ts-strictspec] The npm package now says what strictspec does in one line. Its description and README open with the same sentence the docs site and the other packages carry, so the project no longer describes itself differently on each registry.
• [py-strictspec] The first-run launcher's manual-install instructions now name a command that works. When the toolchain binary cannot be downloaded, the error's go install line spells the full module path (github.com/stricttools/strictspec/go/cmd/strictspec@v<version>) instead of a path Go cannot resolve, and the GitHub Release it points at is the transferred repository's.
• [ts-strictspec] The package metadata now points at the transferred repository. The homepage, issue-tracker and repository links, and the first-run launcher's GitHub Release downloads, all name stricttools/strictspec instead of the old owner.

strictspec@v0.2.5

Release archives are built again

Context

The 0.2.4 publish job failed under goreleaser-action 2.18.1, which reads the
bare semver tag's contents and errored with couldn't get tag contents: unexpected git tag output for "v0.2.4", so that release carried no binary archives and the
PyPI and npm launchers had nothing to download. The publish workflow now creates
the bare v<version> tag locally before invoking goreleaser.

Fixes

• [go-strictspec] The PyPI and npm packages download a working binary again. 0.2.4 shipped with no release archives because the publish job could not read the bare version tag; the job now creates it before building.

strictspec@v0.2.4

Yanked: published without release archives; the PyPI and npm launchers at this version cannot download a binary. Use v0.2.5 instead.

Clearer TOML parse errors, on go-toml-edit 0.4.0.

Context

The Go TOML reader moved to go-toml-edit 0.4.0, whose diagnostics name tokens in plain language and report accurate byte offsets, so a syntax error in a spec file now points at the right place and reads like a sentence.

Fixes

• [go-strictspec] Clearer TOML parse errors. Syntax diagnostics now read in plain language (expected ']', got newline instead of expected RightBracket, got Newline), and a parse error's byte offset is now correct instead of frequently reported as 0.

strictspec@v0.2.3

Ships the npm CLI's first-run download fix; restores npm publishing.

Context

The npm launcher carried the same stale release-tag defect the Python one did:
it built its GitHub Release URL from the retired per-package
go-strictspec@v<version> prefix, so a fresh install's first strictspec
invocation 404'd before it could fetch the Go binary. 0.2.2 fixed the Python
side and shipped to PyPI, but its npm publish failed on a registry permission
error, so no npm user ever received it and the newest package on npm remained
the affected 0.2.1. With the npm credential restored, this release carries the
fix to the npm package.

Fixes

• [ts-strictspec] The npm CLI's first run downloads its toolchain binary again. The strictspec npm bin built its GitHub Release URL from the retired per-package tag, so a fresh install's first invocation died with a 404 instead of fetching and caching the Go binary -- the same defect the Python launcher had. It now reads from the strictspec@v<version> release the assets actually live on. No published npm version carries this fix yet: 0.2.2 never reached the registry, so the newest package on npm is still the affected 0.2.1.

strictspec@v0.2.2

Fixes the Python CLI's first-run download URL, which pointed at a retired release tag and 404'd.

Context

The Python launcher still built its GitHub Release URL from the per-package
go-strictspec@v<version> tag that the releasable-group migration retired.
Releases have been tagged strictspec@v<version> since that migration and
carry the goreleaser archives and checksums.txt there, so every fresh
install of a 0.2.x wheel failed on its first strictspec invocation with
HTTP Error 404 and the CLI was unusable until the cache was seeded by hand.
This is a fix-forward patch for that shipped defect.

Fixes

• [py-strictspec] The Python CLI's first run downloads its toolchain binary again. The strictspec console script built its GitHub Release URL from the retired per-package tag, so a fresh install's first invocation died with HTTP Error 404 instead of fetching and caching the Go binary. It now reads from the strictspec@v<version> release the assets actually live on, and the manual-install instructions in the failure message point there too.

strictspec@v0.2.1

Publish the Go CLI archives with the release: goreleaser now runs inside the module directory.

Context

0.2.0 published to PyPI, npm and the Go module proxy, but its GitHub Release
carried no CLI archives: the Go publish job ran goreleaser at the repository
root, where there is no .goreleaser.yml and no main package, because a job's
defaults.run.working-directory reaches run: steps only and never an action.
The first-run launchers in the Python and npm packages download exactly those
archives, so a 0.2.0 launcher could not fetch its binary. This patch names the
module directory on the action and goes out immediately rather than waiting for
the next natural release.

Fixes

• [go-strictspec] The GitHub Release carries the CLI archives again. The Go publish job ran goreleaser at the repository root instead of the module directory, so it built nothing and 0.2.0's release shipped without the strictspec_* archives and checksums.txt that the Python and npm first-run launchers download. Upgrade if a 0.2.0 launcher failed to fetch its binary.

strictspec@v0.2.0

strictspec as one releasable: the Go CLI's effects-regime and declaration-regime migrations (strictcli 0.33), with the Python and npm launcher/runtime packages version-locked to the generator by construction.

Context

strictspec is one tool -- the Go CLI -- plus per-language launcher/runtime
packages whose exact version-pairing charter (DESIGN decision 31) demands a
single version. The three separate releasables it shipped 0.1.0 under were
scaffold inheritance, not design, and they made the pairing a convention that
each release had to honour by hand. They are now one releasable: one version,
one changelog, one release, so the pairing holds by construction. This is the
first release under that shape, and the reason the Python and npm packages
move to 0.2.0 without functional changes of their own.

The Go CLI's own changes are its migration onto strictcli 0.33: every writing
command routes its disk mutations through the effects handle (so --dry-run
reports instead of writing), validate's evidence flags are scoped to
--with-domain-checks instead of being silently ignored under
--structural-only, and an explicitly empty flag value is refused rather than
read as absent.

Breaking

• [go-strictspec] validate's evidence flags are now scoped. --collection and --collection-root belong to --with-domain-checks and are refused under --structural-only, naming both sides. They were previously accepted there and silently ignored.

Features

• [go-strictspec] --dry-run on every writing command. gen, init, export and migrate route every disk mutation through the framework's effects handle, so --dry-run reports what each would write, rename or chmod and touches nothing. migrate --dry-run still renders the would-be document bytes.
• [go-strictspec, py-strictspec, ts-strictspec] One version for all three packages. The Go CLI, the strictspec PyPI package and the strictspec npm package are now a single release unit: one version, one changelog, one release. The exact runtime/CLI pairing the first-run launchers rely on now holds by construction, and a version moves for all three even when only one of them changed.

Fixes

• [go-strictspec] Absent is no longer read as empty. export --output '' is refused instead of silently writing to stdout, and diff --corpus-root '' no longer resolves to the current directory behind the caller's back.

strictspec@v0.1.0

Initial release of the strictspec toolchain: the Go CLI and runtime, plus the Python and TypeScript runtimes with first-run CLI launchers.

Context

Coordinated initial 0.1.0 release of the strictspec toolchain and all three
runtimes (Go, Python, TypeScript). This is the binding construct-set freeze
(root DESIGN.md, Status). The Go module is the toolchain and the Go runtime in
one: consumers go install it directly, and goreleaser publishes cross-compiled
CLI archives + checksums.txt on the GitHub Release as the single binary source
the Python and npm launchers fetch. Those two packages carry in-package
first-run CLI launchers that lazy-download the exact-version binary (SHA-256
verified) on first invocation, so library-only installs perform zero network
access (decision 31). All three package versions move in lockstep so lazy
download and the exact version-pairing rule (decision 19) agree by
construction.

Features

• [go-strictspec] Initial release: the strictspec Go toolchain and runtime. A declarative schema toolchain -- a TOML meta-schema in, generated validators out -- with the eight-command CLI (gen, check, validate, migrate, export, init, diff, doc-diff), integer format_version gates, the closed-op migration engine, the cross-document constraint engine, and corpus-driven diff certificates. Go consumers go install the module directly.
• [strictspec] Initial release: the strictspec Python runtime and CLI stub. Frozen-dataclass generated validators with tagged, lexeme-retaining document I/O (JSON/TOML/JSONL), the shared diagnostic model and constraint engine, and exact runtime/codegen version pairing. The strictspec console script is a first-run launcher that lazy-downloads the paired toolchain binary (SHA-256 verified); importing the library performs zero network access.
• [ts-strictspec] Initial release: the strictspec TypeScript runtime and CLI stub. Lossless JSON, TOML (via toml-eslint-parser), and JSONL parsers producing tagged document-model values, the diagnostic model and cross-document constraint engine, and exact runtime/codegen version pairing. The strictspec bin is a first-run launcher that lazy-downloads the paired toolchain binary (SHA-256 verified); no postinstall, so library-only installs perform zero network access.