Define SPSS syntax frontend 0.3

.github/workflows/ci.yml

@@ -19,4 +19,6 @@ jobs:
       - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97
         with:
           python-version: "3.13"
+      - run: python -m pip install --disable-pip-version-check -e ".[dev]"
+      - run: python -m pytest
       - run: python tools/validate_repository.py

CHANGELOG.md

@@ -2,15 +2,19 @@
 
 ## Unreleased
 
-Future changes will be listed here.
+- SPSS Syntax Frontend 0.3 is a release candidate, not a published stable
+  claim.
+- Added comments, existing-variable `TO`, grouped supported forms, predicate
+  aliases and bounded `NOT`, open recode ranges, and additive value labels.
+- Frontend 0.3 emits only immutable Plan 0.1/0.2 objects and adds no SQL
+  binding operation.
+- Repository validation now covers all Plan/Frontend/Binding schemas,
+  manifests, references, and hashes.
 
 ## 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.
+OpenStatSpec `v0.3.0` is the stable public specification release at immutable
+specification commit `cd8f198c68b849eb8ed018a894670a0904c2181d`.
 
 - Added backward-compatible Transformation Plan and SPSS Syntax Frontend 0.2
   contracts for sequential numeric `COMPUTE` and conditional `IF`, bounded

README.md

@@ -37,10 +37,11 @@ permits a transformation to mutate a core import.
 That separate derived-data profile is not used by the SPSS-like in-place
 frontend below.
 
-The release-candidate [Transformation Plan Profile 0.2](docs/transformation-plan-profile-0.2.md)
-adds sequential bounded numeric assignment and conditional assignment to the
+The released [Transformation Plan Profile 0.2](docs/transformation-plan-profile-0.2.md)
+was released in OpenStatSpec `v0.3.0` and adds sequential bounded numeric assignment and conditional assignment to the
 unchanged 0.1 operations. The
-[SPSS Syntax Frontend Profile 0.2](docs/spss-syntax-frontend-profile-0.2.md)
+[released SPSS Syntax Frontend Profile 0.2](docs/spss-syntax-frontend-profile-0.2.md)
+was released in OpenStatSpec `v0.3.0` and
 lowers `COMPUTE`, `IF`, `FORMATS`, `VARIABLE LEVEL`, and `EXECUTE`
 alongside the 0.1 `RECODE`, `VARIABLE LABELS`, and `VALUE LABELS` subset.
 Programs using only the 0.1 subset retain exact 0.1 plan identity and hash. The
@@ -50,6 +51,10 @@ creates no derived dataset, data copy, or OpenStatSpec undo layer; Dolt-specific
 history and commits remain Dolt's. MySQL, MariaDB, and Dolt require a new target
 to be provisioned separately before an in-place transformation apply.
 
+The release-candidate [SPSS Syntax Frontend Profile 0.3](docs/spss-syntax-frontend-profile-0.3.md)
+adds syntax-only expansion over the released Plan 0.1/0.2 contracts and is not
+published stable yet.
+
 ## Repository layout
 
 - `sql/server-version-policy.md` — server release-series claims and exact reference-CI targets.
@@ -72,8 +77,18 @@ to be provisioned separately before an in-place transformation apply.
 - `transformation/plan-0.1.schema.json` — canonical transformation-plan schema.
 - `sql/transformation-plan-profile-schema.sql` — compact in-place apply audit;
   it is not a dataset-version catalog.
-- `conformance/transformation-plan-0.2.json` and
-  `conformance/spss-syntax-frontend-0.2.json` — additive plan and frontend
+- `docs/spss-syntax-frontend-profile-0.1.md`,
+  `docs/spss-syntax-frontend-profile-0.2.md`, and
+  `docs/spss-syntax-frontend-profile-0.3.md` — bounded syntax frontend
+  profiles and their contract boundaries.
+- `transformation/spss-syntax-frontend-0.1.schema.json`,
+  `transformation/spss-syntax-frontend-0.2.schema.json`, and
+  `transformation/spss-syntax-frontend-0.3.schema.json` — frontend request
+  schemas.
+- `conformance/transformation-plan-0.2.json`,
+  `conformance/spss-syntax-frontend-0.1.json`,
+  `conformance/spss-syntax-frontend-0.2.json`, and
+  `conformance/spss-syntax-frontend-0.3.json` — additive plan and frontend
   conformance cases with independent golden hashes; `conformance/in-place-transformation-0.2.json`
   fixes the same-dataset/same-table execution invariants and the additional
   controlled Dolt context. The 0.1 schemas and fixtures remain unchanged.

ROADMAP.md

@@ -65,6 +65,24 @@ Prerequisite: the SPSS profile, fixtures, and reference-adapter lessons are matu
   this does not block specification publication.
 - [ ] Evaluate additional language frontends as separate adapters that lower to
   the same canonical plan.
+- [ ] Expand the bounded SPSS frontend through the independently versioned
+  milestones in the [SPSS frontend roadmap](docs/spss-frontend-roadmap.md),
+  without creating a general SPSS compatibility claim.
+- [x] Complete the Frontend 0.3 specification candidate as a syntax-only
+   expansion over immutable Plan 0.1/0.2 after its schema, profile, 35 declared
+   cases, inherited compatibility, and repository validation are complete:
+   comments, dictionary-order variable lists, grouped supported forms, ordinary
+   not-equal/NOT predicates, open recode ranges, and additive value labels.
+- [ ] Define typed numeric expressions, deterministic numeric/date functions,
+  missing-value predicates and metadata, additional numeric/date formats, and
+  restricted conditional blocks in a new Plan/Frontend/In-Place Binding
+  generation.
+- [ ] Define string and physical-schema operations separately, with exact
+  add/rename/drop-column atomicity and rollback evidence for every claimed SQL
+  profile.
+- [ ] Keep case-count/order and group/cross-dataset operations in separate
+  profiles whose invariants do not weaken the current same-cases in-place
+  binding.
 
 ## 8. Microsoft SQL Server dialect
 
@@ -101,10 +119,8 @@ follows and does not block specification publication.
    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.
+5. [ ] Have PHP pin the exact specification commit and pass applicable
+   conformance evidence before changing adapter or package-release claims.
 
 The pending in-place service matrix and adapter conformance work in sections 6
 and 7 are downstream implementation gates. They do not block the `v0.3.0`