Remove executable Dolt validator package

.github/workflows/ci.yml

@@ -12,6 +12,4 @@ jobs:
       - uses: actions/setup-python@v7
         with:
           python-version: "3.13"
-      - run: python -m pip install . pytest
-      - run: python -m pytest -q tests/test_dolt_declarations.py
       - run: python tools/validate_repository.py

CHANGELOG.md

@@ -6,9 +6,6 @@ Target stable specification release: `v0.3.0` (not published).
 
 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.
 
-- Prepared `openstatspec-specification` 0.2.1 with the reusable,
-  fail-closed Dolt adapter declaration validator and packaged schema resources.
-  This package update adds no concrete Dolt support declaration.
 - Added backward-compatible Transformation Plan and SPSS Syntax Frontend 0.2
   contracts for sequential numeric `COMPUTE` and conditional `IF`, bounded
   comparison/`AND`/`OR` expressions, `FORMATS`, `VARIABLE LEVEL`, and

ROADMAP.md

@@ -78,35 +78,23 @@ 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.
 
-1. [ ] Merge the reusable Dolt declaration validator on the current
-   specification `v0.2.0` line without tagging or publishing `v0.2.1` yet,
-   and record the exact merge commit as the release candidate.
-2. [ ] Build a candidate `openstatspec-specification==0.2.1` wheel from that
-   exact commit, bind the Python catalog/Dolt lifecycle implementation to it,
-   and pass both specification validation and the complete adapter matrix
-   before creating an immutable release.
-3. [ ] Only after those gates pass and release-tag signing or protection
-   is configured, create a signed or protected `v0.2.1` tag on that exact
-   specification commit, publish the byte-matching package artifact, reverify
-   installation from the published package, and then merge the Python lifecycle
-   change.
-4. [ ] Reconcile and merge Transformation Plan and SPSS Frontend profile 0.2 as
+1. [x] Merged Transformation Plan and SPSS Frontend profile 0.2 as
    unreleased, release-candidate work for the planned specification `v0.3.0`.
-5. [ ] Rebase Python `0.5.0` conditional transformations on the lifecycle
+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.
-6. [ ] Migrate PHP to the canonical transformation plan and pass the same
+3. [ ] Migrate PHP to the canonical transformation plan and pass the same
    relevant conformance cases before it claims conditional profile 0.2 support.
-7. [ ] Select the exact intended `v0.3.0` commit and require that
+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.
    Until then claims use `release_candidate`, a null release identifier, and
    the exact tested commit.
 
 The pending in-place service matrix and adapter conformance work in sections 6
-and 7 remains required; package publication or a specification pin does not
-complete either evidence gate.
+and 7 remains required; implementation package publication does not complete
+either evidence gate.
 
 ## Maintainer setup