arosasg · Oct 29, 2026 · Oct 29, 2026 · Oct 29, 2026
diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml
@@ -4,8 +4,8 @@ name: Publish
 # Packagist has no upload step: it publishes every tag it reads from the
 # repository, so the tag itself is the publish. release-please.yml therefore
 # never tags; this workflow finds the merged release pull request still
-# labelled "autorelease: pending", runs the checks on its merge commit, waits
-# for a required reviewer of the packagist environment, and only then lets
+# labelled "autorelease: pending", runs the checks on its merge commit, and
+# then (in the packagist environment, which holds its secrets) lets
 # Release Please create the vX.Y.Z tag and the GitHub release. It then attests
 # a source archive, attaches it to the release and asks Packagist to update.
 # A release made with the default token starts no other workflow, which is why

diff --git a/.github/workflows/release-please.yml b/.github/workflows/release-please.yml
@@ -3,12 +3,10 @@ name: Release Please
 # Opens and updates the release pull request from conventional commits.
 # It never creates a tag or a GitHub release (skip-github-release): Packagist
 # publishes every tag it sees, so the vX.Y.Z tag is created only by
-# publish.yml, after the tests pass and a reviewer of the packagist environment
-# approves. Merging the release pull request leaves it labelled
+# publish.yml, after the tests pass. Merging the release pull request leaves it labelled
 # "autorelease: pending" until then, and no new release pull request opens in
-# the meantime. Nothing runs until a maintainer sets the repository variable
-# RELEASES_ENABLED to "true" after the first release is approved (not before
-# the 2026-11-01 Didit release).
+# the meantime. It runs while the repository variable RELEASES_ENABLED is
+# "true" (set since the 1.0.0 release on 2026-10-29).
 
 on:
   push:

diff --git a/AGENTS.md b/AGENTS.md
@@ -1,7 +1,7 @@
 # Didit PHP SDK (`sdk-php`)
 
 The official Didit server-side library for PHP: `didit-protocol/sdk-php` on Packagist.
-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
 
@@ -42,7 +42,7 @@ There is no build step: Packagist installs the tagged sources (see `.gitattribut
 - `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 PHP SDK (`sdk-php`)
 
 The official Didit server-side library for PHP: `didit-protocol/sdk-php` on Packagist.
-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
 
@@ -42,7 +42,7 @@ There is no build step: Packagist installs the tagged sources (see `.gitattribut
 - `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
@@ -54,18 +54,18 @@ A change to hand-written core behaviour that DESIGN.md describes (client options
 
 ## Releasing
 
-Nothing is released before the first release is approved (not before the 2026-11-01 Didit release). Until then the version stays 0.x and the repository stays private.
+1.0.0 was released on 2026-10-29. Merging the release pull request is the release approval (Alex, 2026-10-29); nobody tags or publishes by hand.
 
 1. Release Please (`.github/workflows/release-please.yml`) keeps a release pull request open with the next version and changelog. It runs only when the repository variable `RELEASES_ENABLED` is `true`, and it never creates tags: Packagist publishes every tag it sees.
 2. Merging that pull request creates no tag yet. The merged pull request stays labelled `autorelease: pending`, and no new release pull request opens until it is tagged.
-3. `.github/workflows/publish.yml` (also gated on `RELEASES_ENABLED`) checks that `Didit\Version::VERSION` equals the release manifest, runs the tests and PHPStan on the merge commit, then waits for a reviewer of the `packagist` environment. Only after that approval does it create the `vX.Y.Z` tag and the GitHub release, attest the build provenance of a source archive (GitHub artifact attestations), attach it to the release and ask Packagist to update. If the checks fail or the approval is rejected, nothing is tagged: fix `main` or run Publish again from the Actions tab.
+3. `.github/workflows/publish.yml` (also gated on `RELEASES_ENABLED`) checks that `Didit\Version::VERSION` equals the release manifest, runs the tests and PHPStan on the merge commit, then, in the `packagist` environment (it holds the Packagist secrets; no reviewers), creates the `vX.Y.Z` tag and the GitHub release, attest the build provenance of a source archive (GitHub artifact attestations), attach it to the release and ask Packagist to update. If the checks fail, nothing is tagged: fix `main` or run Publish again from the Actions tab.
 
-### One-time registry setup (a maintainer, before the first release)
+### One-time registry setup (done for 1.0.0 on 2026-10-29)
 
 1. Make the repository public (Packagist reads public GitHub repositories).
-2. Sign in to packagist.org with the Didit GitHub organisation account and submit `https://github.com/didit-protocol/sdk-php`; the package name `didit-protocol/sdk-php` comes from `composer.json`. Add the Didit maintainers to the package.
+2. The package is registered on packagist.org under the Didit account `didit`, which submitted `https://github.com/didit-protocol/sdk-php`; the package name `didit-protocol/sdk-php` comes from `composer.json`. Add the Didit maintainers to the package.
 3. Install the Packagist GitHub integration (or add the Packagist webhook) so new tags update the package automatically.
 4. Optional fallback: store `PACKAGIST_USERNAME` and `PACKAGIST_TOKEN` (the safe API token from the Packagist profile) as secrets of the `packagist` environment; `publish.yml` then calls the Packagist update API itself.
-5. Create the `packagist` environment in the repository settings with required reviewers, so every publish needs an approval.
+5. The `packagist` environment holds `PACKAGIST_USERNAME` and `PACKAGIST_TOKEN` and has no required reviewers; the Packagist webhook on this repository updates the package on every push.
 6. Set the repository variable `RELEASES_ENABLED` to `true`.
 7. Verify a release: `gh attestation verify sdk-php-vX.Y.Z.zip --repo didit-protocol/sdk-php`.
diff --git a/README.md b/README.md
@@ -3,8 +3,6 @@
 The official Didit PHP library.
 Identity verification (KYC), business verification (KYB), AML screening, biometrics, transaction monitoring, wallet screening, Travel Rule and customer authentication, from your backend, with typed requests and responses for every Didit server API.
 
-> In development. Not released yet: the first release is planned with the 2026-11-01 Didit release.
-
 - API reference: [docs.didit.me](https://docs.didit.me)
 - Design contract shared by every Didit server SDK: [docs/DESIGN.md](docs/DESIGN.md)
 - Runnable examples, including Laravel and Symfony webhook receivers: [examples/](examples/)

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