arosasg · Oct 29, 2026 · Oct 29, 2026 · Oct 29, 2026 · Oct 29, 2026
diff --git a/.github/workflows/release-please.yml b/.github/workflows/release-please.yml
@@ -1,20 +1,12 @@
-# NOTHING MAY BE PUBLISHED before Alex's explicit approval and the 2026-11-01 Didit release
-# (docs/DESIGN.md section 13). The PyPI environment `pypi` used by release.yml must require
-# a reviewer.
-#
-# release-please opens the release pull request (version bump and the generated
-# CHANGELOG.md) and, once that pull request is merged and this workflow runs again, creates
-# the tag and the GitHub release, which starts release.yml. It runs only when started by
-# hand, so nothing is cut by accident.
-#
-# Token: a release or pull request created with the default GITHUB_TOKEN does not trigger
-# other workflows, so release.yml would not start and the release pull request would get
-# no CI. Add a repository secret RELEASE_PLEASE_TOKEN (a fine-grained token with Contents,
-# Issues and Pull requests read and write on this repository only) to fix that; without it
-# the workflow falls back to GITHUB_TOKEN.
+# release-please keeps the release pull request (version bump and the generated CHANGELOG.md)
+# up to date on every push to main. Merging that pull request makes the next run create the
+# vX.Y.Z tag and the GitHub release and then start release.yml for that tag, which publishes
+# to PyPI with trusted publishing. No stored token is needed: everything runs on GITHUB_TOKEN.
 name: Release Please
 
 on:
+  push:
+    branches: [main]
   workflow_dispatch:
 
 permissions:
@@ -30,13 +22,23 @@ jobs:
     runs-on: ubuntu-latest
     timeout-minutes: 10
     permissions:
+      actions: write # start release.yml
       contents: write
       issues: write
       pull-requests: write
     steps:
       - name: Run release-please
+        id: release
         uses: googleapis/release-please-action@45996ed1f6d02564a971a2fa1b5860e934307cf7 # v5.0.0
         with:
-          token: ${{ secrets.RELEASE_PLEASE_TOKEN || secrets.GITHUB_TOKEN }}
+          token: ${{ secrets.GITHUB_TOKEN }}
           config-file: release-please-config.json
           manifest-file: .release-please-manifest.json
+      - name: Publish the release
+        # A release created with GITHUB_TOKEN does not trigger the `release` event, so start
+        # release.yml for the new tag directly (workflow_dispatch is allowed with GITHUB_TOKEN).
+        if: ${{ steps.release.outputs.release_created == 'true' }}
+        env:
+          GH_TOKEN: ${{ github.token }}
+          TAG: ${{ steps.release.outputs.tag_name }}
+        run: gh workflow run release.yml --repo "$GITHUB_REPOSITORY" --ref "$TAG" -f tag="$TAG"
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
@@ -1,21 +1,24 @@
-# NOTHING MAY BE PUBLISHED before Alex's explicit approval and the 2026-11-01 Didit release
-# (docs/DESIGN.md section 13). The GitHub environment `pypi` must require a reviewer, so
-# that every upload to PyPI waits for an explicit approval.
-#
-# Publishes didit-sdk to PyPI with trusted publishing (OIDC, no API token) when a GitHub
-# release is published. The PyPI project must list this repository, the workflow
+# Publishes didit-sdk to PyPI with trusted publishing (OIDC, no API token). It runs when
+# release-please creates a release (release-please.yml starts it with the tag) or when a
+# GitHub release is published by hand. The PyPI project lists this repository, the workflow
 # release.yml and the environment pypi as a trusted publisher.
 name: Release
 
 on:
   release:
     types: [published]
+  workflow_dispatch:
+    inputs:
+      tag:
+        description: Release tag to publish (for example v1.2.0); release-please starts this run
+        required: true
+        type: string
 
 permissions:
   contents: read
 
 concurrency:
-  group: release-${{ github.event.release.tag_name }}
+  group: release-${{ github.event.release.tag_name || inputs.tag }}
   cancel-in-progress: false
 
 defaults:
@@ -31,6 +34,7 @@ jobs:
       - name: Check out the release tag
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
         with:
+          ref: ${{ github.event.release.tag_name || inputs.tag }}
           persist-credentials: false
       - name: Set up uv
         uses: astral-sh/setup-uv@18d369b23da25a81e9458561248e1aafff6a70fa # v10.3.1
@@ -39,7 +43,7 @@ jobs:
           enable-cache: false
       - name: Check that the release tag matches the package version
         env:
-          RELEASE_TAG: ${{ github.event.release.tag_name }}
+          RELEASE_TAG: ${{ github.event.release.tag_name || inputs.tag }}
         run: |
           uv run --no-project python - <<'PY'
           import os
@@ -91,7 +95,6 @@ jobs:
     runs-on: ubuntu-latest
     timeout-minutes: 10
     environment:
-      # Must require a reviewer (Settings > Environments > pypi > Required reviewers).
       name: pypi
       url: https://pypi.org/project/didit-sdk/
     permissions:

diff --git a/AGENTS.md b/AGENTS.md
@@ -1,7 +1,7 @@
 # Didit Python SDK (`sdk-python`)
 
 The official Didit server-side library for Python: `didit-sdk` on PyPI (name transfer pending, see docs/DESIGN.md 2.1).
-Status: in development, not released.
+Status: released (1.0.0 on 2026-10-29). Merging the release-please pull request publishes the next version.
 
 ## Read first
 
@@ -39,7 +39,7 @@ uv for environments and locking, hatchling for the build, pytest, mypy --strict,
 - `openapi/verification.json`, `openapi/account.json` and `openapi/webhook-vectors.json` are upstream copies; never edit them by hand. Only the spec sync workflow updates them.
 - Keep the SDKs in sync (HARD RULE). Any public API change in `service-didit-verification` or `service-didit-auth` must reach the OpenAPI documents in mintlify-docs, and from there every server SDK through the spec sync pull request. A change to hand-written core behaviour that DESIGN.md describes (client options, errors, retries, pagination, webhooks, Authentication) is made in all seven SDK repositories, one pull request each, and DESIGN.md is updated in all seven in the same words.
 - Feature parity across languages: a capability shipped in one server SDK ships in the other six.
-- Never publish a package, push a release tag or make this repository public without Alex's explicit approval; nothing is released before the 2026-11-01 Didit release.
+- Releases publish straight from this repository (Alex, 2026-10-29): merging the release-please pull request is the release approval, and the release workflow then creates the vX.Y.Z tag and publishes to the registry. Never push a release tag, create a release or publish by hand outside that flow, and never store a registry token where trusted publishing works.
 - Unit tests never touch the network. Live smoke tests run only when `DIDIT_SANDBOX_API_KEY` is set.
 - Never commit secrets, API keys or real customer data. Fixtures are synthetic.
 - `CHANGELOG.md` is generated by release-please from conventional commits; never edit it by hand.

diff --git a/CLAUDE.md b/CLAUDE.md
@@ -1,7 +1,7 @@
 # Didit Python SDK (`sdk-python`)
 
 The official Didit server-side library for Python: `didit-sdk` on PyPI (name transfer pending, see docs/DESIGN.md 2.1).
-Status: in development, not released.
+Status: released (1.0.0 on 2026-10-29). Merging the release-please pull request publishes the next version.
 
 ## Read first
 
@@ -39,7 +39,7 @@ uv for environments and locking, hatchling for the build, pytest, mypy --strict,
 - `openapi/verification.json`, `openapi/account.json` and `openapi/webhook-vectors.json` are upstream copies; never edit them by hand. Only the spec sync workflow updates them.
 - Keep the SDKs in sync (HARD RULE). Any public API change in `service-didit-verification` or `service-didit-auth` must reach the OpenAPI documents in mintlify-docs, and from there every server SDK through the spec sync pull request. A change to hand-written core behaviour that DESIGN.md describes (client options, errors, retries, pagination, webhooks, Authentication) is made in all seven SDK repositories, one pull request each, and DESIGN.md is updated in all seven in the same words.
 - Feature parity across languages: a capability shipped in one server SDK ships in the other six.
-- Never publish a package, push a release tag or make this repository public without Alex's explicit approval; nothing is released before the 2026-11-01 Didit release.
+- Releases publish straight from this repository (Alex, 2026-10-29): merging the release-please pull request is the release approval, and the release workflow then creates the vX.Y.Z tag and publishes to the registry. Never push a release tag, create a release or publish by hand outside that flow, and never store a registry token where trusted publishing works.
 - Unit tests never touch the network. Live smoke tests run only when `DIDIT_SANDBOX_API_KEY` is set.
 - Never commit secrets, API keys or real customer data. Fixtures are synthetic.
 - `CHANGELOG.md` is generated by release-please from conventional commits; never edit it by hand.

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -74,9 +74,9 @@ They never run in the default CI. A maintainer can start them from the CI workfl
 
 Pull request titles and commits follow [Conventional Commits](https://www.conventionalcommits.org/): `fix:` is a patch, `feat:` a minor version, and `feat!:` or a `BREAKING CHANGE:` footer a major version (a minor version while the SDK is 0.x). Pick the type that matches the semver impact of the change.
 
-Releases are cut by release-please from those commits. It updates the version and generates `CHANGELOG.md`; never edit the changelog by hand. Squash-merge pull requests so that their conventional title becomes the commit release-please reads. `.release-please-manifest.json` holds the version in the repository (0.1.0, unreleased). The first public release sets its version with a `Release-As: <version>` footer in a commit on `main`.
+Releases are cut by release-please from those commits. It updates the version and generates `CHANGELOG.md`; never edit the changelog by hand. Squash-merge pull requests so that their conventional title becomes the commit release-please reads. `.release-please-manifest.json` holds the released version.
 
-Nothing is published without Alex's explicit approval, and nothing before the 2026-11-01 Didit release. Do not push release tags or publish packages.
+release-please runs on every push to `main`. Merging the release pull request is the release approval (Alex, 2026-10-29); nobody tags or publishes by hand. The next run creates the `vX.Y.Z` tag and the GitHub release and starts `release.yml`, which publishes to PyPI with trusted publishing (no stored token).
 
 ## Keep the SDKs in sync
 

diff --git a/README.md b/README.md
@@ -2,8 +2,6 @@
 
 The official Didit Python library: identity verification (KYC), business verification (KYB), AML screening, biometrics, transaction monitoring, Travel Rule and customer authentication, from your Python backend.
 
-> In development, not released yet. The package will be published on PyPI as `didit-sdk` with the first release.
-
 - Every server-side endpoint of the Didit API, with typed requests and responses
 - `Didit` (blocking) and `AsyncDidit` (asyncio) clients with the same methods
 - Webhook verification with every Didit signature scheme, and typed events

diff --git a/docs/DESIGN.md b/docs/DESIGN.md
@@ -33,9 +33,8 @@ The Maven group `me.didit` is the one `sdk-android` already publishes under.
 
 PyPI `didit` belongs to an unrelated project from 2013.
 PyPI `didit-sdk` is a community package by Agustin Saiz (MIT, unofficial, sessions only).
-Didit is asking him to transfer the `didit-sdk` project to Didit, so the official SDK ships under that name.
-Until the transfer is confirmed, keep `didit-sdk` as the distribution name in `pyproject.toml` and do not publish.
-The fallback name, if the transfer does not happen, is `didit-python`.
+He transferred the `didit-sdk` project to Didit, and the official SDK published 1.0.0 under that name on 2026-10-29.
+As agreed with him, his releases 0.1.0 to 0.4.0 stay published, his PyPI user stays on the project, and the 1.0.0 release notes credit the initial community versions.
 
 ## 3. Source of truth: the OpenAPI contract
 
@@ -247,9 +246,10 @@ Ruby: `net/http` from the standard library, `jwt` only for Authentication.
 
 - Semantic versioning; a breaking change to the public SDK surface is a major version.
 - Releases are cut by release-please from conventional commits; `CHANGELOG.md` is generated and never edited by hand.
-- Release workflows publish with trusted publishing or provenance where the registry supports it (PyPI and RubyGems trusted publishing, npm provenance, Maven Central via the Central Portal with signed artifacts, NuGet with a scoped key and the `Didit` prefix reserved, Packagist auto-update from tags, Go module tags).
-- Nothing is published before Alex approves the first release, and not before the 2026-11-01 release; until then versions stay `0.x` pre-release in the repository.
-- The repository stays private until that first release.
+- Release workflows publish with trusted publishing where the registry supports it (PyPI, npm with provenance, RubyGems and NuGet), Maven Central through the Central Portal with signed artifacts (token and signing key in the `maven-central` environment), Packagist through its GitHub hook, and Go module tags announced to proxy.golang.org.
+- 1.0.0 shipped on 2026-10-29 with Alex's approval, and the repositories are public.
+- Every release after that publishes straight from the repository: merging the release-please pull request is the approval, and the workflow creates the vX.Y.Z tag and publishes.
+- A release created with `GITHUB_TOKEN` does not trigger other workflows, so a repository that publishes from a separate `release.yml` has release-please start it with `workflow_dispatch` for the new tag. No personal access token is stored.
 
 ## 14. Documentation and positioning