@@ -7,10 +7,6 @@ on:
         type: choice
         default: all
         options: [all, nuget, rust, npm, python, github]
-      publish_python:
-        description: Publish Python packages to PyPI
-        type: boolean
-        default: true
 permissions:
   contents: read
 concurrency:
@@ -172,7 +168,7 @@ jobs:
             esac
           done
   python:
-    if: inputs.registry == 'python' || (inputs.registry == 'all' && inputs.publish_python)
+    if: inputs.registry == 'python' || inputs.registry == 'all'
     needs: [source, assemble]
     runs-on: ubuntu-latest
     environment: pypi
 
@@ -23,7 +23,7 @@ The Native core workflow checks Rust formatting, linting, and the C ABI on Linux
 All packages must use Cloudtoid branding and organization ownership wherever the registry supports it. Personal logins authorize publishing; they do not replace organization ownership. Before publishing to each registry, connect its owners and names:
 
 - crates.io: `cloudtoid-interprocess` and `cloudtoid-interprocess-ffi`. crates.io uses global crate names and GitHub team owners. The `cloudtoid/interprocess` GitHub team exists, with `prezaei` as its maintainer. After initial creation, add `github:cloudtoid:interprocess` as an owner of both crates and verify it with `cargo owner --list`. This needs ownership-management authorization, which the initial publish-only token does not grant. Keep the personal account for ownership administration. Configure `CARGO_REGISTRY_TOKEN` in the `crates-io` GitHub environment with permission to publish these crates; after the initial publish, configure both crates to trust `cloudtoid/interprocess`, workflow `publish.yml`, environment `crates-io`. Remove the initial secret once that configuration is verified; the workflow then obtains short-lived tokens using `rust-lang/crates-io-auth-action`.
-- PyPI: wait for the `cloudtoid` organization request to be approved. Create `cloudtoid-interprocess` through that organization's Projects page, then configure its trusted publisher: GitHub owner `cloudtoid`, repository `interprocess`, workflow `publish.yml`, environment `pypi`. Do not use a personal-account pending publisher to create the project. Confirm organization ownership before publication; the `Cloudtoid` author field alone is not ownership. No long-lived PyPI token is required.
+- PyPI: `cloudtoid-interprocess` is published under `pedramr` while the Cloudtoid organization application is pending. Its trusted publisher uses GitHub owner `cloudtoid`, repository `interprocess`, workflow `publish.yml`, environment `pypi`. Transfer the project to the organization after approval. No long-lived PyPI token is required.
 - npm: use the `@cloudtoid` scope. Configure each of the six packages to trust GitHub repository `cloudtoid/interprocess`, workflow `publish.yml`, environment `npm`, with permission to publish. The workflow uses OIDC without `NPM_TOKEN`; provenance is automatic. Publish the platform packages and main package under the same scope.
 - Go: versions come from the repository tag `src/go/v3.0.0`, matching module path `github.com/cloudtoid/interprocess/src/go/v3`. There is no separate account to create.
 - C SDK: GitHub release assets in `cloudtoid/interprocess` contain the native library, header, pkg-config file, and license.
@@ -34,7 +34,7 @@ Keep credentials in registry/GitHub settings, never in source files or chat mess
 
 1. Update `Cargo.toml`, `src/python/pyproject.toml`, Python `__version__`, and `src/node/package.json` together, including Node optional dependency versions and the CMake SDK version. Update the core dependency versions in wrapper manifests when the core version changes.
 2. Merge reviewed code into main. Stable native publication is forbidden from feature branches; the workflow checks this before building.
-3. Run **Release packages** (`publish.yml`) from main. This is the single manual release entry point for all registries; merges run validation but do not publish automatically. It rebuilds/tests all native packages and all language pairs, cross-builds Intel Mac artifacts on an Apple Silicon runner, assembles npm packages and Python wheels/source distribution, then publishes registries. NuGet, crates.io, npm, PyPI, and the C SDK/Go release run independently after their required validation/build jobs succeed; one registry failure does not block another. Python publication is independent: leave **Publish Python packages to PyPI** unchecked when PyPI setup is not ready. Python wheels and the source distribution are still built and retained in the release artifacts.
+3. Run **Release packages** (`publish.yml`) from main. This is the single manual release entry point for all registries; merges run validation but do not publish automatically. It rebuilds/tests all native packages and all language pairs, cross-builds Intel Mac artifacts on an Apple Silicon runner, assembles npm packages and Python wheels/source distribution, then publishes registries. NuGet, crates.io, npm, PyPI, and the C SDK/Go release run independently after their required validation/build jobs succeed; one registry failure does not block another. Selecting **all** includes PyPI; select **python** to publish only Python. Python wheels and the source distribution are also retained in the release artifacts.
 4. Install from each public registry in fresh environments, rerun representative cross-language delivery, and update the website/README preview notice after availability is verified.
 
 NuGet uses Nerdbank.GitVersioning with `src/dotnet/version.json`. Set only the major/minor version (`3.1`); the patch starts at zero and advances automatically for commits changing `src/dotnet`. Other-language and website commits keep the same NuGet version, and `--skip-duplicate` skips already published versions. Changing the base to `3.2` resets the patch to zero. The patch counts relevant commits, so releases can skip numbers. Only main produces stable package versions; branch builds include a commit suffix. .NET builds need full Git history (`fetch-depth: 0` in Actions).