parity_venv.sh follows the app to 3.13; the abi3 tag stays at cp312

The wheel is cp312-abi3, so it loads on 3.13 unchanged — the pin that has to
move is the interpreter the parity venv is built with, since its whole point is
resembling what the image ships.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CDYRXGB8tW4NE7b91g7Kdb

docs/design.md

@@ -151,9 +151,11 @@ dlopen. One `.cpp` per module keeps incremental compiles cheap — only the link
 is shared.
 
 **abi3 (`cp312-abi3`)** from the first build, matching forge/assay, so the
-Python 3.13 bump (roadmap 10D) needs no rebuild. Escape hatch if a nanobind
+Python 3.13 bump (roadmap 10D) needed no rebuild — the same wheel loads on the
-STABLE_ABI limitation ever bites: drop `STABLE_ABI` and `wheel.py-api`, since
+3.13 the app now ships. The tag stays at `cp312`: it is a floor, and raising it
-every deployed environment is 3.12. Stub generation works fine under abi3.
+would buy nothing. Escape hatch if a nanobind STABLE_ABI limitation ever bites:
+drop `STABLE_ABI` and `wheel.py-api`, since every deployed environment is on one
+interpreter. Stub generation works fine under abi3.
 
 **Version `<occt>.N`**, asserted at configure time against the OCCT actually
 found, so `occt_version()` keeps reporting the truth for assay's goldens.

pyproject.toml

@@ -18,6 +18,7 @@ authors = [{ name = "N3XD" }]
 classifiers = [
     "Private :: Do Not Upload",
     "Programming Language :: Python :: 3.12",
+    "Programming Language :: Python :: 3.13",
     "Programming Language :: C++",
 ]
 

tools/parity_venv.sh

@@ -4,15 +4,17 @@
 #
 # The app's manifests are never touched: a swap is per-environment because both
 # distributions own the OCP/ import path and a process can hold only one OCCT
-# build.  main therefore keeps resolving cadquery-ocp-novtk until the Phase 10C
+# build.  Since the Phase 10C cutover the app resolves n3xd-ocp itself, so the
-# cutover, and this venv is how parity is proven in the meantime.
+# uninstall below is a no-op on a fresh venv; what the script still buys is a
+# side environment pinned to the image's interpreter, and `--local` for trying
+# an unpublished wheelhouse build against the full app suite.
 #
 #   tools/parity_venv.sh            install from the Gitea registry
 #   tools/parity_venv.sh --local    install the local wheelhouse build
 #
-# Then run whichever slice of the app suite the current increment claims — with
+# Then run whichever slice of the app suite you care about — with the venv's own
-# the venv's own interpreter, NOT `uv run`, which re-syncs the environment
+# interpreter, NOT `uv run`, which re-syncs the environment against the manifest
-# against the manifest and so puts the stock wheel straight back:
+# and so puts the pinned wheel straight back over a `--local` build:
 #   cd ../app && .venv-ocp-parity/bin/python -m pytest backend/tests/test_geom_memo.py
 set -euo pipefail
 
@@ -29,10 +31,10 @@ cd "$APP"
 export UV_PROJECT_ENVIRONMENT="$VENV_NAME"
 
 echo "--- syncing the app's dependencies into $VENV_NAME ---"
-# 3.12 explicitly: the app's floor is >=3.12, so uv would otherwise pick the
+# 3.13 explicitly: uv would otherwise pick the newest interpreter on the box and
-# newest interpreter on the box and the parity venv would stop resembling what
+# the parity venv would stop resembling what the image ships.  Move this pin
-# the image ships.
+# whenever the app's floor moves (roadmap 10D).
-uv sync --all-groups --python 3.12
+uv sync --all-groups --python 3.13
 
 # `uv pip` does NOT honour UV_PROJECT_ENVIRONMENT — it discovers an environment
 # the way pip does, which here means the app's own .venv.  Without --python it