Releases
Identify immutable product releases and rehearse a safe upgrade path.
Release and delivery contract
Product releases are immutable annotated Git tags and deterministic source artifacts. A mutable branch, local checkout, package version, deployment, or generated buyer repository is not a product release.
Versioning
The first approved commercial baseline is v1.0.0. Before it exists, the product remains
unreleased. After v1.0.0:
- patch releases preserve the supported product contract and contain compatible fixes;
- minor releases add backward-compatible capability or supported-path improvements;
- major releases require explicit buyer action to preserve an existing supported contract.
Release candidates use vMAJOR.MINOR.PATCH-rc.N. Internal v0.0.0-rehearsal.N tags may exist only
in isolated rehearsal repositories; they are never customer releases, entitlement events, or public
compatibility claims.
Required release inputs
Every commercial tag requires:
- a clean commit that has passed main CI;
- an annotated tag pointing at that exact commit;
- a matching
CHANGELOG.mdheading; docs/releases/<version>.mdcompleted from the release-note template;- pinned Node, Bun, pnpm, Vite+, TypeScript, Postgres, and provider assumptions;
- migration forward/backward/irreversible notes;
- environment additions/removals/rotations;
- known issues and support transition window;
- root, real-Postgres, custom-buyer, package-native toolchain, audit, packaging, and previous-release upgrade proof.
The first commercial tag has no previous supported release. It still requires a full fresh-buyer
proof. Every later tag requires release:rehearse-upgrade from the previous supported tag.
Verification commands
Run only from the clean commit carrying the annotated target tag and against a disposable database:
RELEASE_DISPOSABLE_DATABASE=1 \
DATABASE_URL='postgresql://app:app@localhost:5432/release_verify?sslmode=disable' \
pnpm release:verify -- v1.0.0-rc.1 v1.0.0-rc.0Omit the second tag only for the first commercial baseline. The verifier refuses a dirty checkout, a lightweight/mismatched tag, missing notes, or a database not explicitly declared disposable.
The verifier:
- freezes dependencies and proves migration
up → down → up; - runs DB-enabled tests, checks, supported builds, package-native escape commands, and audit;
- creates and fully verifies a custom-scope/custom-brand buyer;
- packages the tagged source through Git attributes;
- rehearses an upgrade from the previous tag when supplied.
Artifact contract
release:package produces:
foundation-source-<tag>.tar.gz;foundation-source-<tag>.tar.gz.sha256;foundation-source-<tag>.manifest.json.
The tarball is git archive output compressed with timestamp-free gzip. Re-running the packager for
the same tag produces the same bytes. The manifest records tag, commit, commit timestamp, artifact
checksum, and toolchain pins. A checksum detects accidental change; it is not a cryptographic
signature or proof of publisher identity.
The archive excludes:
- the seller landing site and private planning;
- historical Phase 2 instructions and internal dated author evidence;
- Git history, dependencies, build output, runtime environment, evaluation runs, and release output.
It includes the buyer template, root/scoped agent rules, CI, buyer/commercial contracts, golden paths, create-app, and release/upgrade documentation.
Upgrade rehearsal
The deterministic rehearsal:
- extracts both exact tags;
- generates old/current buyers with the same name, scope, and brand;
- refuses any modified or removed previous migration;
- constructs a shared Git baseline, adds a buyer-owned product file, and merges the target foundation branch;
- proves the buyer-owned file survives;
- runs migration reversal, DB-enabled tests, frozen install, checks, all tests/builds, and audit.
This proves an unmodified reference plus a non-overlapping buyer change. It does not promise that arbitrary application customizations merge without conflict. Buyers must review conflicts using Upgrading.
Entitlement and access
CI artifacts are maintainer evidence, not customer fulfillment. After approval, the fulfillment system must copy the exact immutable artifact, checksum, manifest, notes, and license into the access-controlled release channel.
For each release grant, record:
- order/license and authorized developer;
- tag, commit, artifact checksum, and release publication timestamp;
- entitlement type and
updates_end_at; - grant/revocation/recovery events.
A buyer receives a release only when its publication timestamp falls within the recorded update entitlement, except an approved founding lifetime entitlement. Expiry never disables or revokes source already lawfully downloaded. Revoking managed access cannot erase a clone.
Never grant customer access to a mutable seller branch as a substitute for versioned delivery.
npm bootstrapper
The public superslate npm package is a source-delivery bootstrapper, not a copy of the paid
foundation. Its stable package version must match an approved immutable source tag exactly:
superslate@1.2.3 → v1.2.3 → foundation-source-v1.2.3.tar.gzPublish the npm version only after the matching private GitHub Release contains the source archive,
SHA-256 file, and manifest produced by this contract. The CLI downloads all three through the
buyer's existing authenticated GitHub CLI session and refuses malformed, mismatched, or modified
artifacts. It must never download main, HEAD, another mutable branch, or an unverified archive.
The npm package remains private: true and version 0.0.0 in the pre-release checkout. Removing
that guard, selecting the commercial version, creating the tag and release assets, and publishing
with provenance are one reviewed release operation—not routine development edits.
Security and support
Security fixes use the same immutable release path, plus coordinated disclosure when needed. The current tag is supported. When an update requires buyer action, the prior tag receives the commercially defined transition window unless continued use is unsafe.
Do not publish exploit details, buyer data, secrets, private repository URLs, or provider credentials in release notes, manifests, CI logs, or artifacts.