openstatspec 0.7.0__tar.gz → 0.7.1__tar.gz

{openstatspec-0.7.0 → openstatspec-0.7.1}/.github/workflows/ci.yml

@@ -20,7 +20,7 @@ jobs:
         uses: actions/checkout@v7
         with: &specification-checkout
           repository: OpenStatSpec/specification
-          ref: f2fdf687d8cb32b944ca55a3e9e7215ffc603019
+          ref: cd8f198c68b849eb8ed018a894670a0904c2181d
           path: openstatspec-specification
       - name: Checkout required SPSS engine
         uses: actions/checkout@v7

{openstatspec-0.7.0 → openstatspec-0.7.1}/.github/workflows/release.yml

@@ -48,7 +48,7 @@ jobs:
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
         with:
           repository: OpenStatSpec/specification
-          ref: f2fdf687d8cb32b944ca55a3e9e7215ffc603019
+          ref: cd8f198c68b849eb8ed018a894670a0904c2181d
           path: openstatspec-specification
       - name: Checkout specification package source
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

{openstatspec-0.7.0 → openstatspec-0.7.1}/CHANGELOG.md

@@ -6,6 +6,14 @@ All notable changes to this reference implementation are documented here.
 
 _No unreleased changes._
 
+## 0.7.1 - 2026-08-12
+
+### Changed
+
+- Pinned capability declarations, conformance fixtures, and release validation
+  to the published OpenStatSpec specification `v0.3.0` at exact commit
+  `cd8f198c68b849eb8ed018a894670a0904c2181d`.
+
 ## 0.7.0 - 2026-08-11
 
 ### Added

{openstatspec-0.7.0 → openstatspec-0.7.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: openstatspec
-Version: 0.7.0
+Version: 0.7.1
 Summary: Reference adapter for the OpenStatSpec relational contract
 Author: OpenStatSpec
 License: Apache-2.0

{openstatspec-0.7.0 → openstatspec-0.7.1}/docs/release-readiness.md

@@ -1,4 +1,4 @@
-# 0.7.0 release readiness
+# 0.7.1 release readiness
 
 This page records the expected release contract, not a publication event.
 Creating a version tag remains a separate maintainer action.
@@ -114,12 +114,10 @@ capability claim, or implied support.
 4. Build with `python -m build` and install the generated wheel in a clean
    environment.
 5. Confirm `openstatspec capabilities` reflects the intended support boundary.
-6. Confirm CI, release fixtures, and capabilities use the untagged OpenStatSpec
-   specification release candidate at exact commit
-   `f2fdf687d8cb32b944ca55a3e9e7215ffc603019`, publish
-   `specification_status=release_candidate`, and leave
-   `specification_release` null. If that exact commit receives a stable tag
-   before this package is tagged, update the identity and re-run every gate.
+6. Confirm CI, release fixtures, and capabilities use the published OpenStatSpec
+   specification `v0.3.0` at exact commit
+   `cd8f198c68b849eb8ed018a894670a0904c2181d`, publish
+   `specification_status=stable`, and set `specification_release` to `v0.3.0`.
 7. Review this document, the README, and CHANGELOG for accurate scope.
 
 The tag-triggered release workflow repeats the non-service test suite, builds

openstatspec-0.7.1/docs/superpowers/plans/2026-08-12-python-v071-stable-pin.md

@@ -0,0 +1,158 @@
+# Python 0.7.1 Stable Specification Pin Implementation Plan
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Release Python adapter `0.7.1` with stable, exact provenance for specification `v0.3.0`.
+
+**Architecture:** Keep the provenance values centralized in `src/openstatspec/sql/capabilities.py`; tests and capability declarations consume those values. CI and release-readiness documentation pin the same immutable specification commit, while the package version changes only in packaging metadata.
+
+**Tech Stack:** Python 3.11–3.14, pytest, GitHub Actions, `python -m build`, Twine, PyPI Trusted Publishing.
+
+## Global Constraints
+
+- Specification commit: `cd8f198c68b849eb8ed018a894670a0904c2181d`.
+- Specification status: `stable`.
+- Specification release: `v0.3.0`.
+- Package version: `0.7.1`.
+- Keep the SPSS engine pin, companion package pin, SQL profile matrix, and runtime behavior unchanged.
+- Do not publish or change the normative specification package in this task.
+
+---
+
+### Task 1: Update provenance contract tests first
+
+**Files:**
+- Modify: `tests/test_cli.py:44-48`
+- Modify: `tests/test_sql_profiles.py:32-40`
+
+**Interfaces:**
+- Consumes: public `openstatspec.capability_matrix()` and SQL profile declarations.
+- Produces: executable expectations for stable `v0.3.0` provenance.
+
+- [ ] **Step 1: Change the assertions to the stable identity**
+
+Replace the candidate expectations with:
+
+```python
+assert matrix["specification_status"] == "stable"
+assert matrix["specification_release"] == "v0.3.0"
+assert matrix["specification_commit"] == "cd8f198c68b849eb8ed018a894670a0904c2181d"
+```
+
+Apply the same three values to each profile declaration assertion.
+
+- [ ] **Step 2: Run the focused tests and confirm the expected red state**
+
+Run:
+
+```bash
+python -m pytest -q tests/test_cli.py::test_capability_matrix_is_public_and_cli_matches_engine_boundary tests/test_sql_profiles.py::test_profile_declarations_publish_stable_specification_provenance
+```
+
+Expected: both tests fail because production constants still expose the old release-candidate identity.
+
+- [ ] **Step 3: Commit the failing-test update**
+
+```bash
+git add tests/test_cli.py tests/test_sql_profiles.py
+git commit -m "test: expect stable specification v0.3.0"
+```
+
+### Task 2: Bind production provenance and release metadata
+
+**Files:**
+- Modify: `src/openstatspec/sql/capabilities.py:20-23`
+- Modify: `pyproject.toml:7`
+- Modify: `.github/workflows/ci.yml:23`
+- Modify: `.github/workflows/release.yml:51`
+- Modify: `docs/release-readiness.md:1,116-123`
+- Modify: `CHANGELOG.md` after the `Unreleased` section
+
+**Interfaces:**
+- Consumes: the exact specification commit from the published `v0.3.0` tag.
+- Produces: capability output and release automation identifying `stable`, `v0.3.0`, and `cd8f198c...`.
+
+- [ ] **Step 1: Update the centralized capability constants**
+
+Set the declarations to:
+
+```python
+SPECIFICATION_COMMIT = "cd8f198c68b849eb8ed018a894670a0904c2181d"
+SPECIFICATION_STATUS = "stable"
+SPECIFICATION_RELEASE: str | None = "v0.3.0"
+```
+
+- [ ] **Step 2: Bump the package and CI fixture pin**
+
+Set `project.version` in `pyproject.toml` to `0.7.1`. Replace the old specification checkout ref in both workflows with the exact commit `cd8f198c68b849eb8ed018a894670a0904c2181d`; leave the companion package ref unchanged.
+
+- [ ] **Step 3: Update release documentation and changelog**
+
+Rename the readiness heading to `0.7.1 release readiness`, change its specification checklist to the stable commit/release identity, and add a dated `0.7.1` entry explaining that the adapter now pins published specification `v0.3.0`.
+
+- [ ] **Step 4: Run focused tests and confirm green**
+
+Run the focused command from Task 1. Expected: both tests pass.
+
+- [ ] **Step 5: Commit the implementation and metadata**
+
+```bash
+git add src/openstatspec/sql/capabilities.py pyproject.toml .github/workflows/ci.yml .github/workflows/release.yml docs/release-readiness.md CHANGELOG.md
+git commit -m "release: pin Python adapter to specification v0.3.0"
+```
+
+### Task 3: Verify the complete Python release candidate
+
+**Files:**
+- Verify: all tracked files in the Python repository.
+
+- [ ] **Step 1: Check the diff and stale current references**
+
+Run:
+
+```bash
+git diff --check
+rg -n 'f2fdf687d8cb32b944ca55a3e9e7215ffc603019|specification_status.*release_candidate|specification_release.*None|version = "0\.7\.0"' src tests .github docs pyproject.toml
+```
+
+Expected: no stale current references; historical changelog entries may retain their original release evidence.
+
+- [ ] **Step 2: Run the non-service test suite**
+
+```bash
+python -m pytest -m "not services"
+```
+
+Expected: zero failures.
+
+- [ ] **Step 3: Build and smoke-test the package**
+
+```bash
+rm -rf /tmp/openstatspec-v071-dist /tmp/openstatspec-v071-smoke
+python -m build --outdir /tmp/openstatspec-v071-dist
+python -m twine check /tmp/openstatspec-v071-dist/*
+python -m venv /tmp/openstatspec-v071-smoke
+/tmp/openstatspec-v071-smoke/bin/python -m pip install ./openstatspec-pyspssio
+/tmp/openstatspec-v071-smoke/bin/python -m pip install /tmp/openstatspec-v071-dist/openstatspec-0.7.1-*.whl
+/tmp/openstatspec-v071-smoke/bin/openstatspec capabilities
+```
+
+Expected: build and Twine checks pass, and capabilities reports `stable`, `v0.3.0`, and the exact commit.
+
+### Task 4: Review, publish, and release
+
+- [ ] **Step 1: Run the local review loop and fix every actionable finding**
+
+Review the complete branch diff against `origin/main`; repeat the tests after each fix until no actionable findings remain.
+
+- [ ] **Step 2: Push the branch and open a draft PR**
+
+Push `agent/stable-spec-v071` to `OpenStatSpec/python`, open a PR targeting `main`, mark it ready for review, and add `@codex review`.
+
+- [ ] **Step 3: Iterate on GitHub review and CI**
+
+Inspect every Codex review finding and failing check, fix actionable issues locally, push, and repeat until the review and required checks are clean.
+
+- [ ] **Step 4: After merge, create and push annotated tag `v0.7.1`**
+
+Verify the tag targets the merge commit and wait for tag-context CI to pass before relying on the existing PyPI workflow.

openstatspec-0.7.1/docs/superpowers/specs/2026-08-12-python-stable-specification-pin-design.md

@@ -0,0 +1,35 @@
+# Python 0.7.1 stable specification pin
+
+## Goal
+
+Publish the Python adapter's first patch release after Python adapter `v0.7.0`
+with its capability declarations and conformance fixtures bound to the
+published OpenStatSpec specification `v0.3.0`.
+
+## Scope
+
+- Bump the Python distribution from `0.7.0` to `0.7.1`.
+- Replace the release-candidate specification identity with:
+  - commit `cd8f198c68b849eb8ed018a894670a0904c2181d`;
+  - status `stable`;
+  - release `v0.3.0`.
+- Update unit expectations, CI fixture checkouts, release-readiness guidance,
+  and the changelog so every release surface carries the same identity.
+- Keep the required SPSS engine pin, specification companion package pin,
+  database version matrix, and runtime behavior unchanged.
+- Separately update the specification repository roadmap to mark the completed
+  `v0.3.0` release gates and current public release.
+
+## Release and verification
+
+The Python change is reviewed through a pull request. Before tagging `v0.7.1`,
+run the non-service suite, package build and wheel smoke test, and the full
+GitHub CI matrix. The annotated `v0.7.1` tag must target the merged release
+commit; its tag-context workflow must pass before the existing trusted-PyPI
+workflow publishes the package artifacts.
+
+## Non-goals
+
+This work does not add transformation behavior, change SQL dialect support,
+modify the normative specification, or publish a new specification package
+version.

openstatspec-0.7.1/openstatspec-specification/.github/workflows/ci.yml

@@ -0,0 +1,22 @@
+name: CI
+
+on:
+  push:
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  specification:
+    runs-on: ubuntu-latest
+    steps:
+      # v7.0.1: https://github.com/actions/checkout/commit/3d3c42e5aac5ba805825da76410c181273ba90b1
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1
+        with:
+          persist-credentials: false
+      # v7.0.0: https://github.com/actions/setup-python/commit/5fda3b95a4ea91299a34e894583c3862153e4b97
+      - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97
+        with:
+          python-version: "3.13"
+      - run: python tools/validate_repository.py

openstatspec-0.7.1/openstatspec-specification/.github/workflows/release.yml

@@ -0,0 +1,108 @@
+name: Publish Python specification package
+
+on:
+  push:
+    tags:
+      - "package-v*"
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  build:
+    name: Build and verify distribution
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Check out repository
+        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
+        with:
+          persist-credentials: false
+
+      - name: Set up Python
+        uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7.0.0
+        with:
+          python-version: "3.13"
+
+      - name: Build distribution
+        run: |
+          python -m pip install --upgrade pip
+          python -m pip install build twine pytest
+          python -m pip install -e .
+          python -m pytest -q tests/test_dolt_declarations.py
+          python tools/validate_repository.py
+          python -m build
+
+      - name: Verify distribution metadata
+        run: python -m twine check dist/*
+
+      - name: Verify release tag version
+        if: startsWith(github.ref, 'refs/tags/package-v')
+        env:
+          RELEASE_TAG: ${{ github.ref_name }}
+        run: |
+          python - <<'PY'
+          import os
+          import tomllib
+          from pathlib import Path
+
+          project = tomllib.loads(Path("pyproject.toml").read_text())
+          version = project["project"]["version"]
+          tag = os.environ["RELEASE_TAG"]
+          if tag != f"package-v{version}":
+              raise SystemExit(
+                  f"release tag {tag!r} does not match project version package-v{version}"
+              )
+          PY
+
+      - name: Store distribution artifacts
+        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
+        with:
+          name: python-package-distributions
+          path: dist/
+          if-no-files-found: error
+
+  publish-testpypi:
+    name: Publish to TestPyPI
+    if: github.event_name == 'workflow_dispatch'
+    needs: build
+    runs-on: ubuntu-latest
+    environment:
+      name: testpypi
+      url: https://test.pypi.org/p/openstatspec-specification
+    permissions:
+      id-token: write
+
+    steps:
+      - name: Download distribution artifacts
+        uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
+        with:
+          name: python-package-distributions
+          path: dist/
+
+      - name: Publish distribution to TestPyPI
+        uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33 # v1.14.2
+        with:
+          repository-url: https://test.pypi.org/legacy/
+
+  publish-pypi:
+    name: Publish to PyPI
+    if: startsWith(github.ref, 'refs/tags/package-v')
+    needs: build
+    runs-on: ubuntu-latest
+    environment:
+      name: pypi
+      url: https://pypi.org/p/openstatspec-specification
+    permissions:
+      id-token: write
+
+    steps:
+      - name: Download distribution artifacts
+        uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
+        with:
+          name: python-package-distributions
+          path: dist/
+
+      - name: Publish distribution to PyPI
+        uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33 # v1.14.2

openstatspec-0.7.1/openstatspec-specification/.gitignore

@@ -0,0 +1,5 @@
+__pycache__/
+*.py[cod]
+dist/
+build/
+*.egg-info/

{openstatspec-0.7.0 → openstatspec-0.7.1}/openstatspec-specification/CHANGELOG.md

@@ -2,9 +2,15 @@
 
 ## Unreleased
 
-Target stable specification release: `v0.3.0` (not published).
+Future changes will be listed here.
 
-Until a protected or signed `v0.3.0` tag targets this work, implementations MUST identify it with `specification_status: release_candidate`, `specification_release: null`, and the exact immutable specification commit. The entries below do not constitute a stable release.
+## v0.3.0 - 2026-08-12
+
+Release preparation for the planned stable `v0.3.0` tag. Until a protected or
+signed `v0.3.0` tag targets this exact release commit, implementations MUST
+identify it with `specification_status: release_candidate`,
+`specification_release: null`, and the exact immutable specification commit.
+The entries below become the stable release only when that tag exists.
 
 - Added backward-compatible Transformation Plan and SPSS Syntax Frontend 0.2
   contracts for sequential numeric `COMPUTE` and conditional `IF`, bounded
@@ -17,9 +23,24 @@ Until a protected or signed `v0.3.0` tag targets this work, implementations MUST
   action followed by an existing-target apply with no automatic Dolt commit.
 - Added independent synthetic golden fixtures, hashes, examples, and repository
   validation gates for the new contracts.
-- Corrected the SPSS Syntax Frontend 0.1 schema's `$defs` and `$ref` keywords
-  so typed value-label values are constrained as the existing contract states;
-  this is eligible for a patch-series backport under the schema-defect policy.
+
+- Packaged the repository's Dolt declaration validator and authoritative SQL
+  resources as the `openstatspec-specification` companion distribution.
+- Bound every concrete Dolt declaration to a declaration ID, adapter
+  implementation and exact version, exact specification commit, and conformance
+  run ID; exact single-match selection is required before mutation.
+
+- Added a pending symbolic Dolt profile template and a separate concrete adapter
+  declaration schema/path and contract for tested active-version identity,
+  numeric limits, DDL atomicity, audit-safe cleanup failure, and machine-linked
+  boundary/fault evidence.
+
+## v0.2.1 - 2026-08-04
+
+- Corrected the SPSS Syntax Frontend 0.1 schema's `$defs` and `$ref`
+  keywords so typed value-label values are constrained as the existing
+  contract states. This maintenance release contains no Transformation Plan or
+  SPSS Syntax Frontend 0.2 work.
 
 ## v0.2.0 - 2026-07-31
 

{openstatspec-0.7.0 → openstatspec-0.7.1}/openstatspec-specification/README.md

@@ -25,7 +25,7 @@ remains an explicitly unsupported [future dialect](docs/mssql-dialect-roadmap.md
 
 OpenStatSpec does not define long-form cells, EAV storage, table splitting, reshaping, automatic harmonization, or questionnaire/study entities. It does not infer respondent keys or combine datasets. All conformant database-object identifiers are generic; the double-underscore prefix is reserved for standard technical identifiers.
 
-[Versioning](VERSIONING.md) defines compatibility and release rules. [Roadmap](ROADMAP.md) tracks remaining project work and maintainer setup.
+[Versioning](VERSIONING.md) defines compatibility and release rules. [Releasing](RELEASING.md) defines the maintainer release checklist. [Roadmap](ROADMAP.md) tracks remaining project work and maintainer setup.
 
 ## Optional SQL transformation workflow
 
@@ -59,6 +59,13 @@ to be provisioned separately before an in-place transformation apply.
 - `docs/spss-profile.md` — SPSS source-faithful mapping rules.
 - [Python / pinned pyspssio implementation profile](docs/implementation-profiles/python-pyspssio-0.5.1.md) — Python adapter pyspssio capability boundary; it does not relax the normative SAV/ZSAV profile.
 - `sql/dialect-profiles.md` — initial SQLite, PostgreSQL, MySQL/MariaDB and Dolt physical profiles.
+- `sql/dolt-adapter-declaration-schema.json` — machine-readable contract for
+  concrete Dolt adapter declarations.
+- `sql/dolt-adapter-declarations/` — declaration and evidence resources; the
+  checked-in baseline remains a symbolic template until a concrete adapter
+  declaration is published.
+- `openstatspec-specification` — installable companion distribution exposing
+  the shared Dolt declaration validator and authoritative SQL resources.
 - `sql/` — dialect-neutral schema outline and profile notes.
 - `sql/transformation-workflow-profile-schema.sql` - optional derived-data
   catalog outline, separate from the immutable core catalog.
@@ -76,7 +83,7 @@ to be provisioned separately before an in-place transformation apply.
 
 Implementations must preflight target capabilities before import. If the target cannot faithfully create one wide table because of column, identifier, string, or row limits, import must fail atomically with a machine-readable capability diagnostic. It must never silently truncate, drop, split, transpose, pivot, or transform source data.
 
-This specification repository publishes only normative Transformation Plan and SPSS syntax frontend schemas, documentation, and declarative fixtures. Executable validation or behavioral conformance code, including parser, SQL-engine, transaction, and adapter behavior, belongs in each implementation or adapter repository.
+This specification repository publishes normative Transformation Plan and SPSS syntax frontend schemas, documentation, declarative fixtures, and its own structural/hash/fixture validation in tools/validate_repository.py. It does not contain executable implementation or behavioral conformance code: parser, SQL-engine, transaction, and adapter behavior belong in each implementation or adapter repository.
 
 ## Who it is for
 

openstatspec-0.7.1/openstatspec-specification/RELEASING.md

@@ -0,0 +1,60 @@
+# Releasing OpenStatSpec
+
+This checklist governs releases of this specification repository. It does not
+publish an implementation package and does not substitute for implementation
+or adapter conformance evidence.
+
+The repository release maintainer with repository-admin authority is responsible
+for completing this checklist and preserving the release controls it requires.
+
+The Python companion distribution is released separately from the specification.
+Package tags use the `package-vX.Y.Z` convention; specification tags use
+`vX.Y.Z`. A specification tag MUST NOT publish the package, and a package tag
+MUST match the version declared in `pyproject.toml`.
+
+## Before preparing a release
+
+- Choose an exact reviewed commit on the appropriate branch and record its
+  full commit ID. Stable tags use the convention `vX.Y.Z`.
+- Keep maintenance releases on their maintained release branch. Merge the
+  equivalent corrective change to `main` separately when it is also needed by
+  the next minor release; do not make a maintenance tag point at unrelated
+  unreleased `main` work.
+- Run the repository validation at that exact commit and confirm the required
+  CI run for that commit is successful. A green run for a nearby commit is not
+  sufficient.
+- Gate a specification release on its normative artifacts, review, versioning,
+  repository validation, and exact-commit CI. Adapter conformance and
+  service-matrix evidence are downstream: they gate only an implementation's
+  support or conformance claims and package releases against the exact
+  specification commit and, once published, its release identifier. They do not
+  gate specification publication.
+- Confirm the changelog, versioning impact, and release notes describe only
+  the included specification changes.
+
+## Tag and release
+
+- Create and push `vX.Y.Z` only after the exact release commit has passed
+  CI. Use the selected signed annotated-tag path where signing is available,
+  or the selected protected-tag path restricted to release maintainers. Do not
+  move or reuse a published tag.
+- Wait for the CI run in that exact tag context to succeed before creating or
+  publishing the immutable GitHub release; a branch-commit CI result is not a
+  substitute for the tag-context result.
+- Create the GitHub release as a draft from that exact tag and verify the tag
+  target, title, notes, links, and any release assets before publication.
+- Before publishing, verify the repository immutable-releases setting is
+  enabled. If that setting or the selected signed-or-protected tag path is
+  unavailable, stop and restore the missing selected control before publishing.
+- Publish the release only after those checks are confirmed.
+
+## After publication
+
+- Verify GitHub reports immutable true for the published release and its tag as
+  the intended full commit ID.
+- Verify the tag-triggered CI run is successful and that the release notes are
+  visible from the repository release page.
+- Track implementation conformance and service-matrix work separately from
+  specification release gates. Publishing a specification does not assert
+  implementation conformance, and incomplete implementation evidence does not
+  block specification publication.

{openstatspec-0.7.0 → openstatspec-0.7.1}/openstatspec-specification/ROADMAP.md

@@ -26,10 +26,12 @@ Prerequisite: the core mapping and canonical fixtures are stable enough to test
 
 ## 4. CI, releases, and documentation
 
-- [x] Add continuous checks for specification links, schema examples, fixtures, and adapter conformance once the relevant repositories exist.
+- [x] Add continuous specification-repository checks for links, schema examples,
+  and fixtures.
+- [x] Define adapter conformance guidance; each adapter repository owns its runtime CI and evidence.
 - [x] Define versioning and compatibility guidance for the specification and profiles.
-- [x] Publish release notes and tagged specification releases; `v0.2.0` is the
-  current public specification release.
+- [x] Publish release notes and tagged specification releases; `v0.2.1` is the
+  current public specification release and is immutable.
 - [ ] Expand implementation, dialect-profile, and adoption documentation from real adapter experience.
 
 ## 5. Future adapters
@@ -45,7 +47,10 @@ Prerequisite: the SPSS profile, fixtures, and reference-adapter lessons are matu
 - [x] Define parameter binding, lineage, hashes, audit, metadata and weight
   propagation, dialect boundaries, and atomic publication.
 - [x] Add machine-readable positive and failure conformance cases.
-- [ ] Run all cases in reference adapters before publishing profile 1.0.
+- [ ] Publish profile 1.0 after its normative contract, declarative cases, and
+  specification-repository checks are complete.
+- [ ] Require each implementation to pass the relevant cases before claiming
+  profile 1.0 conformance.
 
 ## 7. Canonical transformation plans and syntax frontends
 
@@ -55,8 +60,9 @@ Prerequisite: the SPSS profile, fixtures, and reference-adapter lessons are matu
   machine-readable conformance cases.
 - [x] Define the in-place binding that preserves dataset/table identity on
   supported SQL profiles and never creates an OpenStatSpec undo/copy layer.
-- [ ] Run the in-place apply service matrix against every claimed SQL profile
-  before publishing execution claims.
+- [ ] Require each implementation to run the in-place apply service matrix
+  against every claimed SQL profile before publishing its execution claims;
+  this does not block specification publication.
 - [ ] Evaluate additional language frontends as separate adapters that lower to
   the same canonical plan.
 
@@ -69,32 +75,42 @@ scope without creating a capability claim.
 - [ ] Select and pin Python and PHP driver stacks after fidelity and security evaluation.
 - [ ] Define T-SQL types, quoting, catalog binding, identity probes and effective-limit preflight.
 - [ ] Add exact cumulative-update CI services and complete conformance/fault-injection evidence.
-- [ ] Publish an independent dialect profile only after both reference adapters pass the evidence gate.
+- [ ] Publish an independent dialect profile after its normative T-SQL contract,
+  declarative cases, and specification-repository checks are complete.
+- [ ] Require each reference adapter to pass the relevant evidence gate before
+  claiming Microsoft SQL Server support.
 - [ ] Evaluate Azure SQL identities separately; do not inherit a SQL Server claim implicitly.
 
 ## 9. Next release dependency order
 
-The next release work must proceed in this order. Completion of an earlier
-artifact is a dependency, not evidence that later adapter or service-matrix
-work has passed.
+The specification release and implementation claims have separate gates. The
+specification defines and publishes the contract first; implementation evidence
+follows and does not block specification publication.
 
 1. [x] Merged Transformation Plan and SPSS Frontend profile 0.2 as
    unreleased, release-candidate work for the planned specification `v0.3.0`.
-2. [ ] Rebase Python `0.5.0` conditional transformations on the lifecycle
-   implementation, pin the final profile commit, and pass the combined service
-   and conformance gates before making an adapter claim.
-3. [ ] Migrate PHP to the canonical transformation plan and pass the same
-   relevant conformance cases before it claims conditional profile 0.2 support.
-4. [ ] Select the exact intended `v0.3.0` commit and require that
-   same commit to pass repository validation and all required reference-adapter
-   gates. Only after those gates pass and release-tag signing or protection is
-   configured, create a signed or protected `v0.3.0` tag on that commit.
+2. [ ] Complete and review the normative `v0.3.0` documents, schemas,
+   declarative fixtures, and hashes; select the exact release commit and pass
+   this repository's validation and CI on that commit.
+3. [ ] After confirming release-tag signing or protection, create a signed or
+   protected `v0.3.0` tag on that commit, require its exact tag-context CI run
+   to pass, and follow the [release checklist](RELEASING.md) draft and control
+   verification before publishing the immutable release.
    Until then claims use `release_candidate`, a null release identifier, and
    the exact tested commit.
+4. [ ] Have Python pin the exact specification commit and, once published,
+   record its `v0.3.0` release identifier; rebase conditional transformations
+   on the lifecycle implementation and pass the combined service and
+   conformance gates before making an adapter claim or package release.
+5. [ ] Have PHP pin the exact specification commit and, once published, record
+   its `v0.3.0` release identifier; migrate to the canonical transformation plan
+   and pass the relevant conformance cases before making an adapter claim or
+   package release.
 
 The pending in-place service matrix and adapter conformance work in sections 6
-and 7 remains required; implementation package publication does not complete
-either evidence gate.
+and 7 are downstream implementation gates. They do not block the `v0.3.0`
+specification release, and publishing the specification does not complete those
+implementation evidence gates.
 
 ## Maintainer setup
 
@@ -108,5 +124,11 @@ These are maintainer actions, not implementation tasks for the specification rep
 - [x] Register and publish the OpenStatSpec PHP package through Packagist. The
   public package establishes the registry setup; repository update ownership
   still needs release-process verification.
-- [ ] Decide the release owner(s), tag naming convention, and release checklist for every repository.
-- [ ] Protect the default branches and ensure release tags are created only by the agreed release workflow; `main` is currently unprotected.
+- [x] Define the specification release tag convention and maintainer checklist in
+  [RELEASING.md](RELEASING.md); the repository release maintainer with repository-admin responsibility owns release-process controls.
+- [x] Protect the default branch and release tags. main requires pull requests,
+  successful specification CI, and resolved conversations; force pushes and
+  deletion are disabled, and these controls apply to administrators. The active
+  v* tag ruleset permits bypass only to repository administrators. GitHub
+  Actions use full-SHA, GitHub-owned actions, and merged head branches are
+  automatically deleted.