From d8a189902fe564ff4b67d354574d33f8ca1f31da Mon Sep 17 00:00:00 2001 From: Alejandro Rosas Date: Thu, 29 Oct 2026 17:02:57 +0400 Subject: [PATCH 1/2] docs(release): releases publish straight from the repository Alex approved the 1.0.0 release on 2026-10-29 and asked that every release publish straight from the repository. The pre-launch rule (no tag or publish before 2026-11-01 without his approval) is replaced: merging the release-please pull request is the release approval. docs/DESIGN.md section 13 records the same, identically in all seven SDK repositories. Co-Authored-By: Claude Opus 5.5 --- AGENTS.md | 2 +- CLAUDE.md | 2 +- docs/DESIGN.md | 7 ++++--- 3 files changed, 6 insertions(+), 5 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 3df847a..688fe10 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -44,7 +44,7 @@ DIDIT_SANDBOX_API_KEY=... bundle exec rspec --tag live # live smoke tests agai - `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 index 3df847a..688fe10 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -44,7 +44,7 @@ DIDIT_SANDBOX_API_KEY=... bundle exec rspec --tag live # live smoke tests agai - `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/docs/DESIGN.md b/docs/DESIGN.md index dfd5287..f4bffe4 100644 --- a/docs/DESIGN.md +++ b/docs/DESIGN.md @@ -247,9 +247,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 From 84a85b92116a82d27ad86dd1610a5bddfdba26bf Mon Sep 17 00:00:00 2001 From: Alejandro Rosas Date: Thu, 29 Oct 2026 17:15:07 +0400 Subject: [PATCH 2/2] docs(release): drop the pre-launch release policy everywhere The SDK is released (1.0.0 on 2026-10-29) and merging the release pull request is the release approval, so the leftover pre-launch text is replaced: the README banners, the agent status line, the CONTRIBUTING release sections and the workflow comments no longer describe a private, unreleased repository or a reviewer gate on the publish environments (which have no required reviewers). docs/DESIGN.md section 2.1 records the completed didit-sdk PyPI transfer and the terms agreed with Agustin Saiz, identically in all seven repositories. Co-Authored-By: Claude Opus 5.5 --- .github/workflows/release.yml | 9 ++++----- AGENTS.md | 2 +- CLAUDE.md | 2 +- CONTRIBUTING.md | 10 +++++----- README.md | 2 -- docs/DESIGN.md | 5 ++--- 6 files changed, 13 insertions(+), 17 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index fad5a47..acf25f7 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -1,7 +1,6 @@ -# NOTHING MAY BE PUBLISHED before Alex's explicit approval and the 2026-11-01 Didit release -# (docs/DESIGN.md section 13). Every job is skipped until a maintainer sets the repository -# variable RELEASES_ENABLED to "true", and the publish job waits for a required reviewer of -# the rubygems environment. CONTRIBUTING.md lists the one-time setup. +# Every job runs while the repository variable RELEASES_ENABLED is "true" (set since the 1.0.0 +# release on 2026-10-29). Merging the release pull request is the release approval; the publish +# job runs in the rubygems environment (the trusted publisher's environment, no reviewers). # # release-please opens and updates the release pull request (the version in # lib/didit/version.rb and the generated CHANGELOG.md). After that pull request is merged, @@ -127,7 +126,7 @@ jobs: group: publish-${{ needs.release-please.outputs.tag_name }} cancel-in-progress: false environment: - # Required reviewers and "Prevent self-review": Settings > Environments > rubygems. + # The RubyGems trusted publisher is bound to this environment; it has no required reviewers. name: rubygems url: https://rubygems.org/gems/didit-sdk permissions: diff --git a/AGENTS.md b/AGENTS.md index 688fe10..13d1ad2 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,7 +1,7 @@ # Didit Ruby SDK (`sdk-ruby`) The official Didit server-side library for Ruby: `didit-sdk` on RubyGems. -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 diff --git a/CLAUDE.md b/CLAUDE.md index 688fe10..13d1ad2 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1,7 +1,7 @@ # Didit Ruby SDK (`sdk-ruby`) The official Didit server-side library for Ruby: `didit-sdk` on RubyGems. -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 diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7bfbce0..1e641b2 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -75,19 +75,19 @@ Pull requests are squash-merged, so the title becomes the commit that release-pl release-please (`.github/workflows/release.yml`) keeps a release pull request open with the next version (`lib/didit/version.rb`, `.release-please-manifest.json`) and the generated `CHANGELOG.md`. Never edit the changelog by hand. Merging the release pull request makes the next run create the `vX.Y.Z` tag and the GitHub release. The `build` job of the same workflow then checks out the tag, checks that it equals `Didit::VERSION`, runs the full test suite and builds the gem. The `publish` job waits for a reviewer of the `rubygems` environment; once approved, it checks that the gem is the one the build job tested, attests its build provenance, attaches it to the GitHub release and pushes it to RubyGems.org with trusted publishing. Only the `publish` job can obtain the OIDC token, and it installs and runs nothing from the repository or its bundle. If a step fails for a transient reason, re-run the failed jobs (RubyGems.org refuses a second push of the same version); if the tagged code itself fails, fix `main` and release the next patch version. -Nothing is published without Alex's explicit approval, and nothing before the 2026-11-01 Didit release. Until then the workflow does nothing (`RELEASES_ENABLED` is unset), the version stays 0.x and the repository stays private. Do not push release tags or publish the gem by hand. -The first release pull request proposes 0.1.0 (`initial-version` in `release-please-config.json`); for another approved version, merge a commit on `main` whose message ends with the footer `Release-As: X.Y.Z` first. +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. The workflow runs while the repository variable `RELEASES_ENABLED` is `true`. +To force a specific version, merge a commit on `main` whose message ends with the footer `Release-As: X.Y.Z` first. -### One-time registry setup (a maintainer, before the first release) +### One-time registry setup (done for 1.0.0 on 2026-10-29) 1. RubyGems.org: use the Didit account (owner `didit`) with MFA enabled, and add the other Didit maintainers as owners of `didit-sdk` once it exists, each with MFA. 2. Trusted publisher: `didit-sdk` does not exist on RubyGems.org yet, so add a pending trusted publisher from the account settings (gem name `didit-sdk`, GitHub Actions, repository `didit-protocol/sdk-ruby`, workflow file `release.yml`, environment `rubygems`). The first push from the workflow creates the gem; after that the publisher is listed on the gem's trusted publishers page. No API key is stored in GitHub. -3. GitHub environment `rubygems` (Settings > Environments): required reviewers, "Prevent self-review" on, and deployment branches limited to `main` (the publish job runs on pushes to `main`). Create it before setting `RELEASES_ENABLED`: a job that names a missing environment creates it without any protection rule. +3. GitHub environment `rubygems` (Settings > Environments): the trusted publisher's environment, with no required reviewers (merging the release pull request is the approval); deployment branches may be limited to `main` (the publish job runs on pushes to `main`). Create it before setting `RELEASES_ENABLED`: a job that names a missing environment creates it without any protection rule. 4. Tag ruleset for `v*` (Settings > Rules > Rulesets): restrict creation, update and deletion, with only the identity that creates the release tags on the bypass list (the role, team or GitHub App behind `RELEASE_PLEASE_TOKEN`). If that identity cannot be added to the bypass list (for example the default `GITHUB_TOKEN`), restrict update and deletion only. 5. Settings > Actions > General: "Allow GitHub Actions to create and approve pull requests", so release-please and the spec sync can open their pull requests. 6. Optional repository secret `RELEASE_PLEASE_TOKEN`: a fine-grained token with contents, issues and pull requests read and write on this repository only (for a GitHub App, mint its token in the workflow with `actions/create-github-app-token` and pass that instead). Without it the release pull request gets no CI run, because pull requests opened with the default `GITHUB_TOKEN` start no workflows. 7. Settings > Collaborators and teams: give `@didit-protocol/backend`, the code owners in `.github/CODEOWNERS`, write access; GitHub ignores code owners without it. -8. Only after Alex approves the first release (not before 2026-11-01): make the repository public, set the repository variable `RELEASES_ENABLED` to `true`, and merge the release pull request that release-please then opens. +8. The repository is public and the repository variable `RELEASES_ENABLED` is `true` (both since 2026-10-29). 9. Check a release with `gh attestation verify didit-sdk-X.Y.Z.gem --repo didit-protocol/sdk-ruby`. ## Keep the SDKs in sync diff --git a/README.md b/README.md index 70fc88e..56611f2 100644 --- a/README.md +++ b/README.md @@ -3,8 +3,6 @@ The official [Didit](https://didit.me) Ruby library. Identity verification (KYC), business verification (KYB), AML screening, biometrics, transaction monitoring, Travel Rule and customer authentication, from your backend. -> In development. Not released yet. - - Every Didit server API: sessions, standalone checks, KYB, users and businesses, workflows, webhooks, cases, transactions, wallet screening, Travel Rule and account management. - Typed results with RBS signatures (checked with Steep), generated from the [OpenAPI contract](openapi/). - Webhook verification and Didit Authentication (OpenID Connect) token verification built in. diff --git a/docs/DESIGN.md b/docs/DESIGN.md index f4bffe4..32996e0 100644 --- 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