PTSIP 0.3.6__tar.gz → 0.3.7__tar.gz

{ptsip-0.3.6/src/PTSIP.egg-info → ptsip-0.3.7}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: PTSIP
-Version: 0.3.6
+Version: 0.3.7
 Summary: Reference tooling for primary lifecycle ownership and responsibility isolation
 Author: Kinirin
 Maintainer: Kinirin
@@ -37,21 +37,23 @@ Dynamic: license-file
 
 # PTSIP — Primary Lifecycle Ownership and Responsibility Isolation Policy
 
-**Status:** Tool `0.3.6` development complete — pre-publication release candidate  
-**Tool/package version:** `0.3.6`  
-**Specification family:** `0.3.6-draft`  
-**Bound immutable Specification revision:** `d6995ed232e845b88d8235b851e80ab54b7804ea`  
-**License:** Apache License 2.0
+**Status:** Tool `0.3.7` WU-12 implementation integrated — exact-SHA verification pending<br>
+**Tool/package version:** `0.3.7`<br>
+**Project Profile contract:** `pp.1.01`<br>
+**Specification family:** `0.3.7-draft`<br>
+**Bound immutable Specification revision:** `3c47816770d194ae42f98faedc911d980db0e62a`<br>
+**License:** Apache License 2.0<br>
+**Localized documentation:** `README.md` is canonical. Localized README files are regenerated on `main` by the self-hosted Argos Translate workflow; if a translation conflicts with this file, this file governs.
 
 PTSIP is a project-defined architecture policy for separating project responsibilities by **primary lifecycle ownership** while preserving explicit architecture intent, lifecycle isolation, reproducible conformance, verification-purpose separation, and multi-environment decision consistency.
 
 > **Purpose precedes reuse.** Classify a coherent responsibility by why it exists and which lifecycle owns it before optimizing for code sharing.
 
-Tool `0.3.6` development is complete on the release-candidate line. The remaining boundary is release operations: merge the approved state to `main`, verify that exact `main` SHA on the self-hosted gate, then prepare and publish the release from the same source identity. The latest PyPI package remains Tool `0.3.5` until Tool `0.3.6` is actually published.
+Tool `0.3.7` now carries the WU-12 implementation and frozen Specification binding on `main` as the release candidate. The WU-12 implementation is complete, but any repository change after exact-SHA verification requires a fresh self-hosted workflow pass before release preparation. The latest published PyPI package remains Tool `0.3.5` until the publication boundary succeeds.
 
 ## Primary lifecycle ownership
 
-Canonical Tool `0.3.6` classifications are exactly:
+Canonical Tool `0.3.7` classifications remain exactly:
 
 | Classification | Meaning |
 | --- | --- |
@@ -73,9 +75,9 @@ TOOLCHAIN
 NEUTRAL_CONTRACT
 ```
 
-Tool `0.3.6` uses the five-classification model above. `TOOLCHAIN` is therefore **legacy Tool `0.3.5` input**, not a Tool `0.3.6` alias. A legacy Toolchain responsibility may become `DEVELOPMENT_TOOLING`, `DELIVERY`, `OPERATIONS`, or require a split depending on its actual lifecycle ownership. Blind `TOOLCHAIN -> DEVELOPMENT_TOOLING` rewriting is prohibited.
+Tool `0.3.7` preserves the five-classification model established by Tool `0.3.6`. `TOOLCHAIN` is therefore **legacy Tool `0.3.5` input**, not a current canonical alias. A legacy Toolchain responsibility may become `DEVELOPMENT_TOOLING`, `DELIVERY`, `OPERATIONS`, or require a split depending on its actual lifecycle ownership. Blind `TOOLCHAIN -> DEVELOPMENT_TOOLING` rewriting is prohibited.
 
-Evidence-driven assisted migration from Tool `0.3.5` declarations is intentionally deferred to Tool `0.3.6.1`; it is not claimed as a Tool `0.3.6` release capability.
+Tool `0.3.7` provides evidence-bound direct current-target migration for explicitly supported historical sources. Migration capability remains separate from repository adoption authority and never turns inference into project intent.
 
 ## Classification is not path or technology
 
@@ -96,7 +98,7 @@ Paths such as `tests/`, `tools/`, `deploy/`, `ops/`, or `.github/workflows/` are
 
 ## Responsibility Map v2
 
-Tool `0.3.6` uses Responsibility Map v2 as the project-owned architecture declaration model. It keeps several axes independent:
+Tool `0.3.7` uses Responsibility Map v2 as the project-owned architecture declaration model. It keeps several axes independent:
 
 ```text
 classification
@@ -225,7 +227,7 @@ Upgrade to the latest **published** release:
 python -m pip install --upgrade PTSIP
 ```
 
-Until Tool `0.3.6` is published, those commands may still install Tool `0.3.5` from PyPI. For source development on this release-candidate line:
+Until Tool `0.3.7` is published, those commands may still install Tool `0.3.5` from PyPI. For source development on this release-candidate line:
 
 ```powershell
 python -m pip install -e ".[dev]"
@@ -253,7 +255,7 @@ The default project-owned profile is repository-root `ptsip.yaml`; projects may
 
 Repository evidence is not architecture authority. Candidate discovery, path names, templates, heuristics, and agent confidence can support review but cannot manufacture project intent.
 
-Canonical Tool `0.3.6` explicit adoption facts center on `classification` as lifecycle ownership authority. New canonical decisions use facts such as:
+Canonical Tool `0.3.7` explicit adoption facts center on `classification` as lifecycle ownership authority. New canonical decisions use facts such as:
 
 ```text
 classification
@@ -263,7 +265,7 @@ runtime_required
 executable
 ```
 
-The historical `lifecycle_owner` field is legacy migration evidence, not a second Tool `0.3.6` ownership authority.
+The historical `lifecycle_owner` field is legacy migration evidence, not a second Tool `0.3.7` ownership authority.
 
 Example dry-run:
 
@@ -328,7 +330,7 @@ PTSIP uses action-time synchronization rather than continuous background polling
 
 Artifact ownership is independent from producer ownership. A `DEVELOPMENT_TOOLING` or `DELIVERY` component may validly build a `PRODUCT` artifact, but the resulting artifact must still satisfy the Product package boundary.
 
-Tool `0.3.6` supports snapshot-bound Product Artifact evidence. Release verification checks actual built distribution content rather than treating packaging configuration as proof. Product distribution verification rejects definite non-Product implementation leakage under `PTSIP-PKG-001`.
+Tool `0.3.7` supports snapshot-bound Product Artifact evidence. Release verification checks actual built distribution content rather than treating packaging configuration as proof. Product distribution verification rejects definite non-Product implementation leakage under `PTSIP-PKG-001`.
 
 ## VPMS — Verification Purpose Management System
 
@@ -344,7 +346,7 @@ VPMS
 
 PTSIP classification and VPMS Verification Purpose remain separate axes. PTSIP core does not depend on VPMS. VPMS consumes only a narrow read-only projection of already-resolved PTSIP metadata.
 
-The current VPMS compatibility vocabulary may still contain `PRODUCT | TOOLCHAIN`. VPMS `TOOLCHAIN` is not a canonical Tool `0.3.6` PTSIP classification.
+The current VPMS compatibility vocabulary may still contain `PRODUCT | TOOLCHAIN`. VPMS `TOOLCHAIN` is not a canonical Tool `0.3.7` PTSIP classification.
 
 VPMS verification PASS does not imply PTSIP `CONFORMANT`, and PTSIP `CONFORMANT` does not imply functional verification PASS.
 
@@ -372,52 +374,43 @@ The PTSIP Tool and PTSIP Specification are independently versioned.
 - `spec/`, `schemas/`, and `registry/` contain canonical Specification assets;
 - `src/ptsip/specdata/` contains matching embedded machine-readable assets.
 
-Tool `0.3.6` is bound to:
+Tool `0.3.7` is bound to independent PP and Specification identities:
 
 ```text
-Specification 0.3.6-draft
-SPEC_REVISION d6995ed232e845b88d8235b851e80ab54b7804ea
+Project Profile pp.1.01
+Specification 0.3.7-draft
+SPEC_REVISION 3c47816770d194ae42f98faedc911d980db0e62a
 ```
 
 A new immutable revision is required only for a genuine normative change. Release workflow, test, planning, status, or documentation-only changes do not move `SPEC_REVISION` by themselves.
 
-## Tool 0.3.6 verification and release state
+## Tool 0.3.7 verification and release state
 
-Development-branch WU-00 through WU-07 are complete. Final WU-07 exact-SHA verification authority is:
+The WU-12 implementation and immutable Specification freeze are complete. The current `main` source state requires a fresh exact-SHA `tooling-test` after the repository CI infrastructure changes made during release handoff.
 
 ```text
-source SHA:       452d0f8b0c78bdebb180ceb2b9994485f59eb43a
-workflow run/job: 32640319047 / 97196299107
-runner:           self-hosted Windows X64
-Python:           3.14.6
-pytest:           331 passed / 0 failed
-Specification:    0.3.6-draft @ d6995ed232e845b88d8235b851e80ab54b7804ea
-profile coverage: unassigned_count=0
-build/twine:      PASS
-Product Artifact: PASS / exact snapshot binding
-PTSIP-PKG-001:    0 definite violations
-wheel smoke/VPMS: PASS
-commit status:    self-hosted/tooling-test = success
+Tool:              0.3.7
+Project Profile:   pp.1.01
+Specification:     0.3.7-draft @ 3c47816770d194ae42f98faedc911d980db0e62a
+exact source SHA:  pending final post-CI main commit
+tooling-test:      PENDING for the current exact main SHA
+publication:       NOT RUN
 ```
 
-Documentation commits after that successful run record closure and do not replace the exact verification authority.
+Earlier workflow evidence remains historical evidence for its own SHA and does not verify a later source state.
 
 The remaining release boundary is:
 
 ```text
-approved 0.3.6 state -> main
-    -> read exact main SHA
-    -> tooling-test.yml on that exact main SHA
+final main exact SHA
+    -> tooling-test.yml on that exact SHA
     -> require self-hosted/tooling-test success
-    -> release.yml from the same current main SHA
-    -> exact Tool / Specification / release-document contract verification
-    -> draft GitHub Release targeting the same SHA
-    -> maintainer publishes reviewed draft
-    -> tooling-release.yml verifies distributions from the published tag
-    -> PyPI Trusted Publishing
+    -> full regression, independent identity, distribution, artifact, and wheel smoke PASS
+    -> release.yml and reviewed draft publication from the same source identity
+    -> tooling-release.yml publication verification and PyPI Trusted Publishing
 ```
 
-See [`STATUS.md`](STATUS.md), [`planning/0.3.6.md`](planning/0.3.6.md), and [`releasenote/0.3.6.md`](releasenote/0.3.6.md) for the release evidence and handoff state.
+See [`STATUS.md`](STATUS.md), [`planning/0.3.7/WU-12-specification-binding-capability-registry-release-readiness.md`](planning/0.3.7/WU-12-specification-binding-capability-registry-release-readiness.md), and [`releasenote/tool/0.3.7.md`](releasenote/tool/0.3.7.md) for the current implementation and handoff boundary.
 
 ## Consumer Repository non-intrusion
 
@@ -425,4 +418,4 @@ PTSIP does not require Consumer Repositories to create PTSIP-specific `.ptsip/`,
 
 ## Project status
 
-PTSIP remains experimental. Tool `0.3.6` is development-complete but not yet published at the time of this release-candidate documentation update. Historical Tool releases and Specification notes are preserved under [`releasenote/`](releasenote/).
+PTSIP remains experimental. Tool `0.3.7` is an unpublished release candidate until the current exact-main completion gate succeeds. Historical Tool releases and Specification notes are preserved under [`releasenote/`](releasenote/).

{ptsip-0.3.6 → ptsip-0.3.7}/README.md

@@ -4,21 +4,23 @@
 
 # PTSIP — Primary Lifecycle Ownership and Responsibility Isolation Policy
 
-**Status:** Tool `0.3.6` development complete — pre-publication release candidate  
-**Tool/package version:** `0.3.6`  
-**Specification family:** `0.3.6-draft`  
-**Bound immutable Specification revision:** `d6995ed232e845b88d8235b851e80ab54b7804ea`  
-**License:** Apache License 2.0
+**Status:** Tool `0.3.7` WU-12 implementation integrated — exact-SHA verification pending<br>
+**Tool/package version:** `0.3.7`<br>
+**Project Profile contract:** `pp.1.01`<br>
+**Specification family:** `0.3.7-draft`<br>
+**Bound immutable Specification revision:** `3c47816770d194ae42f98faedc911d980db0e62a`<br>
+**License:** Apache License 2.0<br>
+**Localized documentation:** `README.md` is canonical. Localized README files are regenerated on `main` by the self-hosted Argos Translate workflow; if a translation conflicts with this file, this file governs.
 
 PTSIP is a project-defined architecture policy for separating project responsibilities by **primary lifecycle ownership** while preserving explicit architecture intent, lifecycle isolation, reproducible conformance, verification-purpose separation, and multi-environment decision consistency.
 
 > **Purpose precedes reuse.** Classify a coherent responsibility by why it exists and which lifecycle owns it before optimizing for code sharing.
 
-Tool `0.3.6` development is complete on the release-candidate line. The remaining boundary is release operations: merge the approved state to `main`, verify that exact `main` SHA on the self-hosted gate, then prepare and publish the release from the same source identity. The latest PyPI package remains Tool `0.3.5` until Tool `0.3.6` is actually published.
+Tool `0.3.7` now carries the WU-12 implementation and frozen Specification binding on `main` as the release candidate. The WU-12 implementation is complete, but any repository change after exact-SHA verification requires a fresh self-hosted workflow pass before release preparation. The latest published PyPI package remains Tool `0.3.5` until the publication boundary succeeds.
 
 ## Primary lifecycle ownership
 
-Canonical Tool `0.3.6` classifications are exactly:
+Canonical Tool `0.3.7` classifications remain exactly:
 
 | Classification | Meaning |
 | --- | --- |
@@ -40,9 +42,9 @@ TOOLCHAIN
 NEUTRAL_CONTRACT
 ```
 
-Tool `0.3.6` uses the five-classification model above. `TOOLCHAIN` is therefore **legacy Tool `0.3.5` input**, not a Tool `0.3.6` alias. A legacy Toolchain responsibility may become `DEVELOPMENT_TOOLING`, `DELIVERY`, `OPERATIONS`, or require a split depending on its actual lifecycle ownership. Blind `TOOLCHAIN -> DEVELOPMENT_TOOLING` rewriting is prohibited.
+Tool `0.3.7` preserves the five-classification model established by Tool `0.3.6`. `TOOLCHAIN` is therefore **legacy Tool `0.3.5` input**, not a current canonical alias. A legacy Toolchain responsibility may become `DEVELOPMENT_TOOLING`, `DELIVERY`, `OPERATIONS`, or require a split depending on its actual lifecycle ownership. Blind `TOOLCHAIN -> DEVELOPMENT_TOOLING` rewriting is prohibited.
 
-Evidence-driven assisted migration from Tool `0.3.5` declarations is intentionally deferred to Tool `0.3.6.1`; it is not claimed as a Tool `0.3.6` release capability.
+Tool `0.3.7` provides evidence-bound direct current-target migration for explicitly supported historical sources. Migration capability remains separate from repository adoption authority and never turns inference into project intent.
 
 ## Classification is not path or technology
 
@@ -63,7 +65,7 @@ Paths such as `tests/`, `tools/`, `deploy/`, `ops/`, or `.github/workflows/` are
 
 ## Responsibility Map v2
 
-Tool `0.3.6` uses Responsibility Map v2 as the project-owned architecture declaration model. It keeps several axes independent:
+Tool `0.3.7` uses Responsibility Map v2 as the project-owned architecture declaration model. It keeps several axes independent:
 
 ```text
 classification
@@ -192,7 +194,7 @@ Upgrade to the latest **published** release:
 python -m pip install --upgrade PTSIP
 ```
 
-Until Tool `0.3.6` is published, those commands may still install Tool `0.3.5` from PyPI. For source development on this release-candidate line:
+Until Tool `0.3.7` is published, those commands may still install Tool `0.3.5` from PyPI. For source development on this release-candidate line:
 
 ```powershell
 python -m pip install -e ".[dev]"
@@ -220,7 +222,7 @@ The default project-owned profile is repository-root `ptsip.yaml`; projects may
 
 Repository evidence is not architecture authority. Candidate discovery, path names, templates, heuristics, and agent confidence can support review but cannot manufacture project intent.
 
-Canonical Tool `0.3.6` explicit adoption facts center on `classification` as lifecycle ownership authority. New canonical decisions use facts such as:
+Canonical Tool `0.3.7` explicit adoption facts center on `classification` as lifecycle ownership authority. New canonical decisions use facts such as:
 
 ```text
 classification
@@ -230,7 +232,7 @@ runtime_required
 executable
 ```
 
-The historical `lifecycle_owner` field is legacy migration evidence, not a second Tool `0.3.6` ownership authority.
+The historical `lifecycle_owner` field is legacy migration evidence, not a second Tool `0.3.7` ownership authority.
 
 Example dry-run:
 
@@ -295,7 +297,7 @@ PTSIP uses action-time synchronization rather than continuous background polling
 
 Artifact ownership is independent from producer ownership. A `DEVELOPMENT_TOOLING` or `DELIVERY` component may validly build a `PRODUCT` artifact, but the resulting artifact must still satisfy the Product package boundary.
 
-Tool `0.3.6` supports snapshot-bound Product Artifact evidence. Release verification checks actual built distribution content rather than treating packaging configuration as proof. Product distribution verification rejects definite non-Product implementation leakage under `PTSIP-PKG-001`.
+Tool `0.3.7` supports snapshot-bound Product Artifact evidence. Release verification checks actual built distribution content rather than treating packaging configuration as proof. Product distribution verification rejects definite non-Product implementation leakage under `PTSIP-PKG-001`.
 
 ## VPMS — Verification Purpose Management System
 
@@ -311,7 +313,7 @@ VPMS
 
 PTSIP classification and VPMS Verification Purpose remain separate axes. PTSIP core does not depend on VPMS. VPMS consumes only a narrow read-only projection of already-resolved PTSIP metadata.
 
-The current VPMS compatibility vocabulary may still contain `PRODUCT | TOOLCHAIN`. VPMS `TOOLCHAIN` is not a canonical Tool `0.3.6` PTSIP classification.
+The current VPMS compatibility vocabulary may still contain `PRODUCT | TOOLCHAIN`. VPMS `TOOLCHAIN` is not a canonical Tool `0.3.7` PTSIP classification.
 
 VPMS verification PASS does not imply PTSIP `CONFORMANT`, and PTSIP `CONFORMANT` does not imply functional verification PASS.
 
@@ -339,52 +341,43 @@ The PTSIP Tool and PTSIP Specification are independently versioned.
 - `spec/`, `schemas/`, and `registry/` contain canonical Specification assets;
 - `src/ptsip/specdata/` contains matching embedded machine-readable assets.
 
-Tool `0.3.6` is bound to:
+Tool `0.3.7` is bound to independent PP and Specification identities:
 
 ```text
-Specification 0.3.6-draft
-SPEC_REVISION d6995ed232e845b88d8235b851e80ab54b7804ea
+Project Profile pp.1.01
+Specification 0.3.7-draft
+SPEC_REVISION 3c47816770d194ae42f98faedc911d980db0e62a
 ```
 
 A new immutable revision is required only for a genuine normative change. Release workflow, test, planning, status, or documentation-only changes do not move `SPEC_REVISION` by themselves.
 
-## Tool 0.3.6 verification and release state
+## Tool 0.3.7 verification and release state
 
-Development-branch WU-00 through WU-07 are complete. Final WU-07 exact-SHA verification authority is:
+The WU-12 implementation and immutable Specification freeze are complete. The current `main` source state requires a fresh exact-SHA `tooling-test` after the repository CI infrastructure changes made during release handoff.
 
 ```text
-source SHA:       452d0f8b0c78bdebb180ceb2b9994485f59eb43a
-workflow run/job: 32640319047 / 97196299107
-runner:           self-hosted Windows X64
-Python:           3.14.6
-pytest:           331 passed / 0 failed
-Specification:    0.3.6-draft @ d6995ed232e845b88d8235b851e80ab54b7804ea
-profile coverage: unassigned_count=0
-build/twine:      PASS
-Product Artifact: PASS / exact snapshot binding
-PTSIP-PKG-001:    0 definite violations
-wheel smoke/VPMS: PASS
-commit status:    self-hosted/tooling-test = success
+Tool:              0.3.7
+Project Profile:   pp.1.01
+Specification:     0.3.7-draft @ 3c47816770d194ae42f98faedc911d980db0e62a
+exact source SHA:  pending final post-CI main commit
+tooling-test:      PENDING for the current exact main SHA
+publication:       NOT RUN
 ```
 
-Documentation commits after that successful run record closure and do not replace the exact verification authority.
+Earlier workflow evidence remains historical evidence for its own SHA and does not verify a later source state.
 
 The remaining release boundary is:
 
 ```text
-approved 0.3.6 state -> main
-    -> read exact main SHA
-    -> tooling-test.yml on that exact main SHA
+final main exact SHA
+    -> tooling-test.yml on that exact SHA
     -> require self-hosted/tooling-test success
-    -> release.yml from the same current main SHA
-    -> exact Tool / Specification / release-document contract verification
-    -> draft GitHub Release targeting the same SHA
-    -> maintainer publishes reviewed draft
-    -> tooling-release.yml verifies distributions from the published tag
-    -> PyPI Trusted Publishing
+    -> full regression, independent identity, distribution, artifact, and wheel smoke PASS
+    -> release.yml and reviewed draft publication from the same source identity
+    -> tooling-release.yml publication verification and PyPI Trusted Publishing
 ```
 
-See [`STATUS.md`](STATUS.md), [`planning/0.3.6.md`](planning/0.3.6.md), and [`releasenote/0.3.6.md`](releasenote/0.3.6.md) for the release evidence and handoff state.
+See [`STATUS.md`](STATUS.md), [`planning/0.3.7/WU-12-specification-binding-capability-registry-release-readiness.md`](planning/0.3.7/WU-12-specification-binding-capability-registry-release-readiness.md), and [`releasenote/tool/0.3.7.md`](releasenote/tool/0.3.7.md) for the current implementation and handoff boundary.
 
 ## Consumer Repository non-intrusion
 
@@ -392,4 +385,4 @@ PTSIP does not require Consumer Repositories to create PTSIP-specific `.ptsip/`,
 
 ## Project status
 
-PTSIP remains experimental. Tool `0.3.6` is development-complete but not yet published at the time of this release-candidate documentation update. Historical Tool releases and Specification notes are preserved under [`releasenote/`](releasenote/).
+PTSIP remains experimental. Tool `0.3.7` is an unpublished release candidate until the current exact-main completion gate succeeds. Historical Tool releases and Specification notes are preserved under [`releasenote/`](releasenote/).

{ptsip-0.3.6 → ptsip-0.3.7}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "PTSIP"
-version = "0.3.6"
+version = "0.3.7"
 description = "Reference tooling for primary lifecycle ownership and responsibility isolation"
 readme = "README.md"
 requires-python = ">=3.11"

{ptsip-0.3.6 → ptsip-0.3.7/src/PTSIP.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: PTSIP
-Version: 0.3.6
+Version: 0.3.7
 Summary: Reference tooling for primary lifecycle ownership and responsibility isolation
 Author: Kinirin
 Maintainer: Kinirin
@@ -37,21 +37,23 @@ Dynamic: license-file
 
 # PTSIP — Primary Lifecycle Ownership and Responsibility Isolation Policy
 
-**Status:** Tool `0.3.6` development complete — pre-publication release candidate  
-**Tool/package version:** `0.3.6`  
-**Specification family:** `0.3.6-draft`  
-**Bound immutable Specification revision:** `d6995ed232e845b88d8235b851e80ab54b7804ea`  
-**License:** Apache License 2.0
+**Status:** Tool `0.3.7` WU-12 implementation integrated — exact-SHA verification pending<br>
+**Tool/package version:** `0.3.7`<br>
+**Project Profile contract:** `pp.1.01`<br>
+**Specification family:** `0.3.7-draft`<br>
+**Bound immutable Specification revision:** `3c47816770d194ae42f98faedc911d980db0e62a`<br>
+**License:** Apache License 2.0<br>
+**Localized documentation:** `README.md` is canonical. Localized README files are regenerated on `main` by the self-hosted Argos Translate workflow; if a translation conflicts with this file, this file governs.
 
 PTSIP is a project-defined architecture policy for separating project responsibilities by **primary lifecycle ownership** while preserving explicit architecture intent, lifecycle isolation, reproducible conformance, verification-purpose separation, and multi-environment decision consistency.
 
 > **Purpose precedes reuse.** Classify a coherent responsibility by why it exists and which lifecycle owns it before optimizing for code sharing.
 
-Tool `0.3.6` development is complete on the release-candidate line. The remaining boundary is release operations: merge the approved state to `main`, verify that exact `main` SHA on the self-hosted gate, then prepare and publish the release from the same source identity. The latest PyPI package remains Tool `0.3.5` until Tool `0.3.6` is actually published.
+Tool `0.3.7` now carries the WU-12 implementation and frozen Specification binding on `main` as the release candidate. The WU-12 implementation is complete, but any repository change after exact-SHA verification requires a fresh self-hosted workflow pass before release preparation. The latest published PyPI package remains Tool `0.3.5` until the publication boundary succeeds.
 
 ## Primary lifecycle ownership
 
-Canonical Tool `0.3.6` classifications are exactly:
+Canonical Tool `0.3.7` classifications remain exactly:
 
 | Classification | Meaning |
 | --- | --- |
@@ -73,9 +75,9 @@ TOOLCHAIN
 NEUTRAL_CONTRACT
 ```
 
-Tool `0.3.6` uses the five-classification model above. `TOOLCHAIN` is therefore **legacy Tool `0.3.5` input**, not a Tool `0.3.6` alias. A legacy Toolchain responsibility may become `DEVELOPMENT_TOOLING`, `DELIVERY`, `OPERATIONS`, or require a split depending on its actual lifecycle ownership. Blind `TOOLCHAIN -> DEVELOPMENT_TOOLING` rewriting is prohibited.
+Tool `0.3.7` preserves the five-classification model established by Tool `0.3.6`. `TOOLCHAIN` is therefore **legacy Tool `0.3.5` input**, not a current canonical alias. A legacy Toolchain responsibility may become `DEVELOPMENT_TOOLING`, `DELIVERY`, `OPERATIONS`, or require a split depending on its actual lifecycle ownership. Blind `TOOLCHAIN -> DEVELOPMENT_TOOLING` rewriting is prohibited.
 
-Evidence-driven assisted migration from Tool `0.3.5` declarations is intentionally deferred to Tool `0.3.6.1`; it is not claimed as a Tool `0.3.6` release capability.
+Tool `0.3.7` provides evidence-bound direct current-target migration for explicitly supported historical sources. Migration capability remains separate from repository adoption authority and never turns inference into project intent.
 
 ## Classification is not path or technology
 
@@ -96,7 +98,7 @@ Paths such as `tests/`, `tools/`, `deploy/`, `ops/`, or `.github/workflows/` are
 
 ## Responsibility Map v2
 
-Tool `0.3.6` uses Responsibility Map v2 as the project-owned architecture declaration model. It keeps several axes independent:
+Tool `0.3.7` uses Responsibility Map v2 as the project-owned architecture declaration model. It keeps several axes independent:
 
 ```text
 classification
@@ -225,7 +227,7 @@ Upgrade to the latest **published** release:
 python -m pip install --upgrade PTSIP
 ```
 
-Until Tool `0.3.6` is published, those commands may still install Tool `0.3.5` from PyPI. For source development on this release-candidate line:
+Until Tool `0.3.7` is published, those commands may still install Tool `0.3.5` from PyPI. For source development on this release-candidate line:
 
 ```powershell
 python -m pip install -e ".[dev]"
@@ -253,7 +255,7 @@ The default project-owned profile is repository-root `ptsip.yaml`; projects may
 
 Repository evidence is not architecture authority. Candidate discovery, path names, templates, heuristics, and agent confidence can support review but cannot manufacture project intent.
 
-Canonical Tool `0.3.6` explicit adoption facts center on `classification` as lifecycle ownership authority. New canonical decisions use facts such as:
+Canonical Tool `0.3.7` explicit adoption facts center on `classification` as lifecycle ownership authority. New canonical decisions use facts such as:
 
 ```text
 classification
@@ -263,7 +265,7 @@ runtime_required
 executable
 ```
 
-The historical `lifecycle_owner` field is legacy migration evidence, not a second Tool `0.3.6` ownership authority.
+The historical `lifecycle_owner` field is legacy migration evidence, not a second Tool `0.3.7` ownership authority.
 
 Example dry-run:
 
@@ -328,7 +330,7 @@ PTSIP uses action-time synchronization rather than continuous background polling
 
 Artifact ownership is independent from producer ownership. A `DEVELOPMENT_TOOLING` or `DELIVERY` component may validly build a `PRODUCT` artifact, but the resulting artifact must still satisfy the Product package boundary.
 
-Tool `0.3.6` supports snapshot-bound Product Artifact evidence. Release verification checks actual built distribution content rather than treating packaging configuration as proof. Product distribution verification rejects definite non-Product implementation leakage under `PTSIP-PKG-001`.
+Tool `0.3.7` supports snapshot-bound Product Artifact evidence. Release verification checks actual built distribution content rather than treating packaging configuration as proof. Product distribution verification rejects definite non-Product implementation leakage under `PTSIP-PKG-001`.
 
 ## VPMS — Verification Purpose Management System
 
@@ -344,7 +346,7 @@ VPMS
 
 PTSIP classification and VPMS Verification Purpose remain separate axes. PTSIP core does not depend on VPMS. VPMS consumes only a narrow read-only projection of already-resolved PTSIP metadata.
 
-The current VPMS compatibility vocabulary may still contain `PRODUCT | TOOLCHAIN`. VPMS `TOOLCHAIN` is not a canonical Tool `0.3.6` PTSIP classification.
+The current VPMS compatibility vocabulary may still contain `PRODUCT | TOOLCHAIN`. VPMS `TOOLCHAIN` is not a canonical Tool `0.3.7` PTSIP classification.
 
 VPMS verification PASS does not imply PTSIP `CONFORMANT`, and PTSIP `CONFORMANT` does not imply functional verification PASS.
 
@@ -372,52 +374,43 @@ The PTSIP Tool and PTSIP Specification are independently versioned.
 - `spec/`, `schemas/`, and `registry/` contain canonical Specification assets;
 - `src/ptsip/specdata/` contains matching embedded machine-readable assets.
 
-Tool `0.3.6` is bound to:
+Tool `0.3.7` is bound to independent PP and Specification identities:
 
 ```text
-Specification 0.3.6-draft
-SPEC_REVISION d6995ed232e845b88d8235b851e80ab54b7804ea
+Project Profile pp.1.01
+Specification 0.3.7-draft
+SPEC_REVISION 3c47816770d194ae42f98faedc911d980db0e62a
 ```
 
 A new immutable revision is required only for a genuine normative change. Release workflow, test, planning, status, or documentation-only changes do not move `SPEC_REVISION` by themselves.
 
-## Tool 0.3.6 verification and release state
+## Tool 0.3.7 verification and release state
 
-Development-branch WU-00 through WU-07 are complete. Final WU-07 exact-SHA verification authority is:
+The WU-12 implementation and immutable Specification freeze are complete. The current `main` source state requires a fresh exact-SHA `tooling-test` after the repository CI infrastructure changes made during release handoff.
 
 ```text
-source SHA:       452d0f8b0c78bdebb180ceb2b9994485f59eb43a
-workflow run/job: 32640319047 / 97196299107
-runner:           self-hosted Windows X64
-Python:           3.14.6
-pytest:           331 passed / 0 failed
-Specification:    0.3.6-draft @ d6995ed232e845b88d8235b851e80ab54b7804ea
-profile coverage: unassigned_count=0
-build/twine:      PASS
-Product Artifact: PASS / exact snapshot binding
-PTSIP-PKG-001:    0 definite violations
-wheel smoke/VPMS: PASS
-commit status:    self-hosted/tooling-test = success
+Tool:              0.3.7
+Project Profile:   pp.1.01
+Specification:     0.3.7-draft @ 3c47816770d194ae42f98faedc911d980db0e62a
+exact source SHA:  pending final post-CI main commit
+tooling-test:      PENDING for the current exact main SHA
+publication:       NOT RUN
 ```
 
-Documentation commits after that successful run record closure and do not replace the exact verification authority.
+Earlier workflow evidence remains historical evidence for its own SHA and does not verify a later source state.
 
 The remaining release boundary is:
 
 ```text
-approved 0.3.6 state -> main
-    -> read exact main SHA
-    -> tooling-test.yml on that exact main SHA
+final main exact SHA
+    -> tooling-test.yml on that exact SHA
     -> require self-hosted/tooling-test success
-    -> release.yml from the same current main SHA
-    -> exact Tool / Specification / release-document contract verification
-    -> draft GitHub Release targeting the same SHA
-    -> maintainer publishes reviewed draft
-    -> tooling-release.yml verifies distributions from the published tag
-    -> PyPI Trusted Publishing
+    -> full regression, independent identity, distribution, artifact, and wheel smoke PASS
+    -> release.yml and reviewed draft publication from the same source identity
+    -> tooling-release.yml publication verification and PyPI Trusted Publishing
 ```
 
-See [`STATUS.md`](STATUS.md), [`planning/0.3.6.md`](planning/0.3.6.md), and [`releasenote/0.3.6.md`](releasenote/0.3.6.md) for the release evidence and handoff state.
+See [`STATUS.md`](STATUS.md), [`planning/0.3.7/WU-12-specification-binding-capability-registry-release-readiness.md`](planning/0.3.7/WU-12-specification-binding-capability-registry-release-readiness.md), and [`releasenote/tool/0.3.7.md`](releasenote/tool/0.3.7.md) for the current implementation and handoff boundary.
 
 ## Consumer Repository non-intrusion
 
@@ -425,4 +418,4 @@ PTSIP does not require Consumer Repositories to create PTSIP-specific `.ptsip/`,
 
 ## Project status
 
-PTSIP remains experimental. Tool `0.3.6` is development-complete but not yet published at the time of this release-candidate documentation update. Historical Tool releases and Specification notes are preserved under [`releasenote/`](releasenote/).
+PTSIP remains experimental. Tool `0.3.7` is an unpublished release candidate until the current exact-main completion gate succeeds. Historical Tool releases and Specification notes are preserved under [`releasenote/`](releasenote/).