Repository navigation
Define 0.3.0 release naming and maturity status - #246
Merged
Merged
Conversation
Record the accepted Core release and release-candidate names. Separate conformance maturity from exact specification versions, update the manifests and schema descriptions, and cover the status ladder with hand-written vectors. Co-Authored-By: Codex <noreply@openai.com> Signed-off-by: kikashy <kikashy@hotmail.com>
#231) Signed-off-by: kikashy <kikashy@hotmail.com>
Contributor
|
Carry needed from base commit fc27546. |
Signed-off-by: kikashy <kikashy@hotmail.com>
…ntries Signed-off-by: kikashy <kikashy@hotmail.com>
Contributor
Author
Review (OpenAI gpt-5.6-sol, effort medium, 2026-10-23), reviewed SHA 6214a06Clean-room clone at the head, probes under
Disposition: the one MEDIUM (the RFC process still said "Research-preview RFCs") is fixed by the coordinator in one word at |
Contributor
|
🎉 Thank you for your contribution to Judgment Pack! If you’d like another task, choose a path that interests you: |
kikashy
added a commit
that referenced
this pull request
Oct 28, 2026
…ceholders (#231) The "Checks run for this release" section now states the mechanism: the release reuses main's repository-conformance evidence for the exact commit through the release evidence gate, the reused run's id and attempt are in the release's decision artifact and are appended to the published release body at publication, and the candidates were reviewed on their pull requests (#246, #248 and #258 for rc.1; #274 for rc.2, with its same-vendor statement). The notes test checks that form and that no placeholder remains. Signed-off-by: kikashy <35789537+kikashy@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kikashy
added a commit
that referenced
this pull request
Oct 28, 2026
…n the final bundle, a release draft that is not a pre-release (#231) (#278) Prepares the `v0.3.0` final for milestone v0.3.0 (#231). This PR creates no tag; the tag is cut later. The published candidates' files under `releases/` (rc.1, rc.2) are untouched. Nothing under `conformance/`, `schema/` or `rfcs/` changes. `conformance/` and `schema/` are unchanged, and under `spec/` and `rfcs/` only the leaf's adoption sentences change, per the maintainer's decisions below. ## Maintainer decision: the final is the leaf's normative support distribution The maintainer chose to make `v0.3.0` the normative home of the selected `retained-column/1` leaf, so a final installation supports the leaf. Without this, the readers named only the rc.2 distribution, and the final bundle answered a leaf selection with `capability-unsupported`. The change: - **`spec/retained-column.md`, lines 6, 23, 28 and 266 only:** - Line 6 (the A2 decision): accepted at draft maturity in the `v0.3.0` release, first distributed as the `v0.3.0-rc.2` candidate. - The support tuple's distribution version is `0.3.0`. - The inventory is `releases/v0.3.0.retained-column.json`. - The normative support version is exactly `0.3.0`, the `v0.3.0` distribution. - `v0.3.0-rc.2` was its candidate distribution and remains published. The schema, corpus and digests are the candidate's, while the companion page and the two readers name the release. - A leaf support claim is made against a `v0.3.0` installation. - **The readers** (`tools/retained_column.py`, `tools/dialect-verify-ts/src/retained.ts`): - They check the generated `release-identity.json` (tag `v0.3.0`, releaseVersion `0.3.0`, specVersion, maturity, a 40-hex sourceCommit). - They check `releases/v0.3.0.retained-column.json` (distribution `v0.3.0`, every pinned byte). - They report support version `0.3.0`. They name `0.3.0` only, because rc.2 installations run rc.2's published readers. - They still refuse unknown exact pins and roles before artifact admission. - **The builder:** - The `v0.3.0` bundles carry a generated `release-identity.json`. It is generated, never a tracked mapping; no `releases/v0.3.0.json` exists or is admitted. - The final's inventory must equal RC2's in the schema, the corpus and every other digest. Only these may differ: the companion page, `spec/judgment-pack-core.md`, `spec/dialect.md`, `tools/retained_column.py` and `retained.ts`. - RC2's inventory is used for that comparison only when it has the SHA-256 that tag `v0.3.0-rc.2` published (`RC2_RETAINED_INVENTORY_SHA256`). - Both readers must name the tag, its version and its inventory. - **The frozen corpus keeps its `v0.3.0-rc.2` labels:** the `cases.json` status, the `manifest`/`capabilities` distribution and the synthetic test pins. The notes say in one sentence that these labels name the candidate distribution whose bytes the final publishes unchanged. - **Probe:** a final bundle built from this branch with the real builder CLI answers as follows. A `0.3.0` selection naming its own commit is `supported` by both the Python and the TypeScript reader. A `0.3.0-rc.2` selection is `capability-unsupported` from both. The CLI test in `tests/test_retained_release.py` repeats this probe on every run. ## What changed 1. **Final notes at `releases/v0.3.0.md`** (the immutable path the builder prefers). They keep the prepared notes' Included work, Versioning and maturity, Migration note and preserved-schema sections. They add: - both candidates with their publication dates and what each carried (rc.1, 2026-10-25: the maturity ladder and the 0.3.0 re-pin; rc.2, 2026-10-27: the leaf, RFC 0029); - the leaf section for the decision above; - RFC 0024 as not in the release (still Draft) and the Policy companion as unchanged; - **What this release pins**, including the leaf's support version and inventory; - **Checks run for this release**, with no placeholders. It says the release reuses main's `repository-conformance` evidence for the exact commit through the release evidence gate. It says the reused run's id and attempt are in the gate's decision record, kept as the release run's `release-evidence-<attempt>` artifact (`web/DEPLOYMENT.md`, "Release evidence"). It names where the candidates were reviewed: rc.1 on #246, #248 and #258, with its review records on issues #259 and #261; rc.2 on #274, with its same-vendor statement. - A **Candidate period** paragraph: the two publication dates, the adopter feedback and its disposition recorded on #231 before the tag, and the tag cut no earlier than one week after rc.2's publication. `docs/releases/v0.3.0.md` becomes a pointer; it is kept because the published rc.1 notes link to it. The site's `project/releases/0.3.0/` page renders the immutable notes. 2. **The leaf in the final bundle** (`tools/build_release.py`). For `v0.3.0`, `bundle_paths()` adds the reader paths, `releases/v0.3.0.retained-column.json`, `releases/v0.3.0.milestone.json` and the notes, and no mapping. `validate_artifacts()` holds the final to RC2's leaf rules (a valid inventory with draft maturity, RFC 0029 Accepted, milestone #2) plus the rules above. It refuses when: - either inventory is missing; - a mapping sits beside a tag the RC allowlist does not name. 3. **The draft is not a pre-release for a plain tag** (`release.yml`). The evidence job hands the release job its `route` output, which is the tag grammar alone. `--prerelease` is passed unless the route is exactly `evidence`, so `v0.3.0` is drafted as a release the maintainer publishes, while RCs, `policy-v` tags and any other route value stay pre-releases. `web/DEPLOYMENT.md` and `.github/ci-evidence.json`'s `fresh_at_release` text are updated to match. 4. **`VERSIONING.md`** names `vX.Y.Z-rc.N` and `vX.Y.Z-alpha.N`. A candidate graduates with no change to its normative artifacts (schemas, corpus, Core and companion rules). Text and tooling that named the candidate distribution are updated to name the release, and the release's notes list those changes. 5. **`CHANGELOG.md`**: - The 0.3.0 entries move under `## \`0.3.0\``; RFC 0027 (targets 0.4.0) stays under Unreleased; a leaf entry is added. - `0.2.0-draft`'s entries, which were still under Unreleased, move verbatim under `## \`0.2.0-draft\` — 2026-07-28`, so the move is exact. - The `0.3.0` heading has no date: the maintainer adds it at the tag. ## What the final bundle carries beyond rc.2's - **Adds:** `releases/v0.3.0.md`, `releases/v0.3.0.retained-column.json` and `releases/v0.3.0.milestone.json`. The generated `release-identity.json` now names `v0.3.0`. - **Drops:** rc.2's mapping, inventory and milestone link, and `docs/releases/v0.3.0.md`. - **Leaf bytes:** the schema and corpus are byte-identical to rc.2's, and so is every other leaf file except the companion page and the two readers. ## Safeguards and their mutants I broke each safeguard in a scratch copy and confirmed that the named test failed: 26 mutants, all caught, including the review round's published-digest rule and the narrowed revised-set mutant. When a mutant targeted a reader, the scratch copy re-pinned that reader's digest, so only the mutated logic could fail the test. | Safeguard | Mutants | Caught by | | --- | --- | --- | | final inventory equals RC2's except `distribution` and the three revised files | any file allowed to differ; top-level comparison removed; file-set comparison removed; revised set widened to `_retained_column.py` | `test_retained_release.test_final_route_refuses_each_leaf_rule` (and the pin tests for the widened set) | | RC2's inventory has the bytes tag `v0.3.0-rc.2` published (a leaf change re-pinned in both inventories is refused) | check removed | `test_retained_release.test_final_route_refuses_each_leaf_rule` | | both readers name the tag, its version and its inventory | check skipped; Python-only; Python tag-only | same | | published RC2 inventory / the exact tag's inventory must exist | each check removed | same | | inventory `distribution` equals the exact tag | any allowlisted distribution accepted | same | | final keeps milestone #2; requires RFC 0029 Accepted | each skipped for `v0.3.0` | same | | no mapping outside the RC allowlist | check removed | same | | final bundle carries the leaf | leaf paths limited to rc.2 | `test_final_bundle_paths_carry_the_leaf_without_a_mapping`, `test_final_cli_archives_the_leaf_and_its_readers_support_it` | | final bundle carries the generated identity | identity generated for RC tags only | `test_final_cli_archives_the_leaf_and_its_readers_support_it` | | Python reader: inventory `distribution`, `releaseVersion`, reported version | each check dropped or rc.2 reported | `test_retained_column.test_installed_identity_is_the_v0_3_0_distribution` | | TypeScript reader: the same three | each check dropped or rc.2 reported | `retained.test.ts` "installed identity is the v0.3.0 distribution" | | `--prerelease` only outside `vMAJOR.MINOR.PATCH` | always; never; prefix match on `evidence` | `test_release_evidence.test_only_a_plain_release_tag_is_drafted_without_the_prerelease_flag` | The RC2 route tests no longer validate RC2 against this tree, because the tree's support identity is now the final's. The rc.2 assertions on its own immutable files (mapping, milestone, inventory pins outside the revised three) stay. The RC2 route now refuses this tree, which is pinned by a test, so rc.2 is built only from its tag. ## Tests - `python -m unittest tests.test_release tests.test_retained_release tests.test_release_milestone`: 41 tests, OK. - `python -m unittest tests.test_retained_column tests.test_site`: 70 tests, OK. - `PYTHONPATH=tests python -m unittest test_release_evidence test_release_recovery test_historical_release test_dialect_ts`: 62 tests, OK. - The TypeScript tool (`node --disable-wasm-trap-handler --test test/*.test.ts`): 385 tests, all pass. - All of these ran under `ulimit -v 4000000`. `--disable-wasm-trap-handler`, the flag the suite's own Node calls use, lets Node's TypeScript stripping run under the cap. ## Checks I ran `jpdev check --changed origin/main` on the head under `ulimit -v 4000000`, with `NODE_OPTIONS=--disable-wasm-trap-handler`. That flag is the one the suite's own Node calls use, and it lets `test_profiles` run under the cap. The workflow change is an unmapped path, so the whole list ran: ``` == jpdev check --changed: 23 changed paths since origin/main (merge base bcac15b) == unmapped path .github/workflows/release.yml: whole list == check summary (dev.json) == handover: boundary 2 paths, shared 3 paths; see AGENTS.md "Before you hand over" PASS local-paths 0s PASS agent-docs 0s sync-agent-docs: CLAUDE.md matches AGENTS.md PASS diff-check 0s PASS repository-tests 119s, python .venv/bin/python3 (Python 3.12.11) Ran 472 tests in 118.377s OK PASS policy-prototype 1s, python .venv/bin/python3 (Python 3.12.11) Ran 38 tests in 1.123s OK PASS policy-contract 3s, python .venv/bin/python3 (Python 3.12.11) Ran 13 tests in 2.632s OK PASS policy-official-draft 2s, python .venv/bin/python3 (Python 3.12.11) Ran 16 tests in 2.402s OK PASS retained-column 45s, python .venv/bin/python3 (Python 3.12.11) 21 lines matched; last: Draft reference/source schema: 16 changed member/alternative controls PASS == 8 passed, 0 failed, 0 skipped, 0 not run == ``` Self-checks (AGENTS.md): - (a) Under `spec/`, only the three support-identity lines named above changed; `schema/` has no diff. - (b) No schema member or enum value is added. - (c) Both readers pass the new installation tests and the shared corpus. - (d) Every refusal added has a caught mutant (table above). - (g) The spec, the notes and the code describe the same final. ## Review fixes (clean-room record of cdb9f6d) - **M1:** `validate_final_retained_inventory` uses RC2's inventory only when that file has the SHA-256 tag `v0.3.0-rc.2` published. That digest is a constant, so the tests read no tag. I checked it against `git show refs/tags/v0.3.0-rc.2:releases/v0.3.0-rc.2.retained-column.json`. The tests cover three cases: a leaf change re-pinned in both inventories (refused), the honest tree (accepted), and the comparison behind the digest. - **M2:** the notes no longer claim a release-body edit. The run id and attempt are in the decision record kept as `release-evidence-<attempt>`, which is what `web/DEPLOYMENT.md` "Release evidence" already documents. - **M3:** the `VERSIONING.md` sentence now says what holds (item 4). - **L1 and L2:** issues #259 and #261 are added to the rc.1 review list, and the notes gain the Candidate period paragraph. - **H1, the maintainer's decision (A2):** the normative text names `v0.3.0` as the leaf's adoption release, and `v0.3.0-rc.2` as its candidate. - `spec/retained-column.md` lines 6 and 266. - `spec/judgment-pack-core.md` lines 54–55 and 371. - `spec/dialect.md` lines 142 and 144: the closing "Immutable RC2 publication remains separate." is dropped. - Each sentence keeps its existing non-claims. - `rfcs/0029-retained-column-conversions.md` gains one dated note after the first adoption paragraph (new line 19). It names `v0.3.0` as the accepted route's final distribution; its Status and history are unchanged. RFC 0000 does not forbid this. It is a non-material note in the repository's dated-note convention, not an amendment of the design. - The builder's allowed-to-differ set adds the Core and Dialect pages. The RFC is not inventory-pinned, so the set does not name it. - The notes list these text changes in one sentence. The inventory-rule mutants were re-run, plus a narrowed-set mutant: 8 of 8 caught. - **Not in these rounds:** L3–L6. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: kikashy <35789537+kikashy@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #231.
What it adds
0.3.0, tagv0.3.0, as the first unsuffixed Core release and requires the singlev0.3.0-rc.1GitHub pre-release before it.draft,candidate, andreleaseas a maturity ladder independent ofspecVersion,changes both current manifests to
draft, and admits the ladder in all three requested manifestschemas.
specVersion; the frozenPolicy consumer schema is deliberately unchanged.
empty values. Repository tests apply them to the Core, evaluation, and preserved
0.1.0-draftmanifest schemas and assert both current manifests remain
draft.v0.3.0release note from merged RFC 0025, RFC 0026, overlap-check, RFC 0020 bulk andlater-sibling, Dialect data-quality/research-contract, and RFC 0022 alignment work.
research-previewschema/status occurrences inconformance/manifest.json,conformance/evaluation/manifest.json,conformance/manifest.schema.json,conformance/evaluation/manifest.schema.json,schema/conformance-manifest-0.1.0-draft.schema.json,conformance/evaluation/README.md,schema/judgment-pack-core.schema.json, andschema/judgment-pack-core-0.1.0-draft.schema.json; this PR updates all eight. The untouchedoccurrences are historical prose in
rfcs/0009-interim-review-regime.mdandrfcs/0021-dialect-artifact-identity.md, plus the frozenschema/policy/1.0.0/consumer-core-0.2.0-draft.schema.json. The only new occurrences are therelease note explaining the retirement and the negative test vector.
Checks
Not in this PR
re-pinned from
0.2.0-draftto0.3.0.conformance/policy/1.0.0/,schema/policy/1.0.0/,releases/policy-*, orspec/policy.mdchanges.rfcs/0023-policy-companion.mdis also untouched.the release only if merged before the tag.
Open for the maintainer
The machine-readable
0.2.0-draftidentifier is carried by these exact surfaces:schema/judgment-pack-core.schema.json;conformance/manifest.jsonand its schema;conformance/evaluation/manifest.jsonand its schema; andschema/workflow-1.schema.json.conformance/carrier/(11),conformance/structural/(80),conformance/semantic/(18),conformance/valid/(15), and the five top-level JSON files inconformance/advisory/; the four files inconformance/evaluation/packs/; the eight files inconformance/evaluation/staged/packs/; and all 47conformance/dialect/vectors/*/run.jsonfiles.examples/*.jsonpacks and the six versioned demo packs underweb/demos/*/v*/packs/.examples, and 18 document vectors under
conformance/policy/1.0.0/, plus the Policy releasemanifest and notes.
tests/test_repository.py,tests/test_release.py,tests/test_policy_release.py, andtests/test_site.py; release logic intools/build_release.py; and the Core, Dialect, workflow, witness, site, and release prose thatpublishes or links the exact identifier.
Accepting
0.3.0requires re-pinning the editable schema$idandspecVersionconstant, bothmanifest
specVersion/suiteVersionpins and schema identifiers/constants, every released Core packand vector above, examples and versioned site routes, the reader/build constants and assertions, and
adding the release-builder note at
releases/v0.3.0.md. Historical0.2.0-draftartifacts and thefrozen Policy consumer copy must remain available. The Runtime must vendor the resulting
0.3.0specification artifacts byte-exact and add
0.3.0beside0.2.0-draftin its acceptedspecVersionset; it must not overwrite its existing vendored release.A Codex session wrote the change.