ci(sdk): move acceptance to Hosting and retain publish-on-merge

.github/workflows/release-please.yml

@@ -30,16 +30,3 @@ jobs:
       - uses: googleapis/release-please-action@45996ed1f6d02564a971a2fa1b5860e934307cf7 # v5.0.0
         with:
           token: ${{ steps.app.outputs.token }}
-      - name: Enable checked auto-merge for release PRs
-        shell: bash
-        env:
-          GH_TOKEN: ${{ steps.app.outputs.token }}
-          GH_REPO: ${{ github.repository }}
-        # Looking up the branch also handles retries when Release Please leaves the PR unchanged.
-        run: |
-          gh pr list --base main --head release-please--branches--main--components--volcano-sdk --state open \
-            --json number,author,isCrossRepository,isDraft,headRefOid \
-            --jq '.[] | select(.author.login == "app/kong-volcano-app" and .isCrossRepository == false and .isDraft == false) | [.number, .headRefOid] | @tsv' |
-            while IFS=$'\t' read -r number head; do
-              gh pr merge "$number" --auto --squash --match-head-commit "$head"
-            done

AGENTS.md

@@ -9,6 +9,6 @@
   behalf.
 - Keep reviewer and repository-administration credentials outside ordinary
   automation.
-- Preserve shared behavioral scenarios and coordinate contract changes with
-  `Kong/volcano-hosting` and the other SDKs.
+- Keep native unit, type, build, and package checks here. Hosting owns behavioral
+  acceptance scenarios and bindings; coordinate changes with `Kong/volcano-hosting`.
 - Keep maintainer guidance under `maintainers/`; `docs/` is published.

CONTRIBUTING.md

@@ -44,7 +44,7 @@ Classify the impact in the PR before changing the contract:
 | Change                                    | Required updates                                                                                                                                                               |
 | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | Public facade or SDK-facing wire contract | Audit all three SDKs; update each affected facade, native tests, and public language examples. Regenerate internal clients when their wire snapshot changes.                   |
-| Shared behavior                           | Update the canonical requirement ID and Gherkin scenario in Hosting, every affected language binding, checked-in feature copies, native tests, and equivalent public examples. |
+| Shared behavior                           | Update the canonical requirement ID and Gherkin scenario in Hosting, every affected Hosting-owned language binding, native tests, and equivalent public examples. |
 | Native behavior                           | Add native regression coverage and document language-specific behavior. Update shared scenarios only if the shared behavior changes.                                           |
 | Public examples                           | Update equivalent examples in every affected language and verify their public API calls.                                                                                       |
 
@@ -57,30 +57,21 @@ PRs. Keep each PR focused and use Conventional Commits. Obtain clean code and
 security reviews and passing required checks on the final commit before merge.
 Hosting changes also require human approval.
 
-### Roll out shared scenarios
-
-Before merging SDK code, prove it remains compatible with the currently deployed
-Hosting contract. Staging Gherkin does not keep runtime code dormant, and the
-existing release automation can publish a main-derived package. If new server
-support is required, first land a backward-compatible Hosting prerequisite or
-keep the SDK PR in draft until an explicitly reviewed release/rollout plan is in
-place. Do not merge an incompatible implementation merely because its scenario
-is staged.
-
-1. Change the canonical scenario in Hosting once. Copy its bytes into each SDK
-   and implement its native binding.
-2. Stage new scenarios under `features/staged` while Hosting main still uses the
-   older contract. Do not activate scenarios ahead of Hosting.
-3. Merge the required SDK changes before validating and merging the coordinated
-   Hosting PR. Record the Hosting and SDK revisions used by acceptance.
-4. After Hosting merges, promote those unchanged files into `features/contract`
-   and run the default binding-discovery checks. Do not keep duplicate active
-   and staged copies.
-
-Hosting CI checks out each SDK's latest `main` and records the actual tested
-SHAs. Do not introduce a checked-in pin manifest or assume a rerun uses the same
-SDK revisions. Generate and verify each SDK against its own OpenAPI snapshot;
-compatibility with the server is established by integration tests.
+### Roll out shared behavior
+
+Hosting owns the canonical scenarios and all language bindings under
+`tests/sdk-contract`. Its Staging Validation builds each SDK's latest `main`,
+installs the distribution in a fresh environment, and exercises public behavior.
+Do not copy features or acceptance runners into this repository.
+
+Land compatible server support before an SDK version needs it in production.
+Then merge the SDK implementation and native tests. Update the Hosting scenarios
+and bindings in the coordinated PR, and validate those SDK main revisions in
+Staging Validation. Record the Hosting and SDK commits from that run.
+
+A maintainer manually merges the Release Please version PR; the existing release
+and trusted-publisher workflows publish automatically. Hosting acceptance is
+independent and does not gate SDK publication.
 
 When the wire contract changes, first build Hosting's public bundle with
 `scripts/ci/openapi-bundle.sh <output-directory>` and update the affected SDK's
@@ -89,20 +80,17 @@ check. The generator reads the vendored snapshot; it does not update that
 snapshot from Hosting. Do not use snapshot equality as a server compatibility
 gate.
 
-From a Hosting checkout, verify shared tooling and copies before review:
+From a Hosting checkout, verify shared tooling before review:
 
 ```shell
 npm ci --prefix tests/sdk-contract --ignore-scripts
 npm test --prefix tests/sdk-contract
-bash scripts/ci/run-sdk-contract-tests_test.sh
-bash scripts/ci/run-sdk-contract-tests.sh --validate-features-only \
-  /path/to/volcano-sdk-js /path/to/volcano-sdk-python /path/to/volcano-sdk-ruby
+go test ./scripts/ci
 ```
 
-Without `--validate-features-only`, the runner creates and deletes fixtures.
-Use an approved disposable environment for live runs; staging and production
-require explicit authorization. Ordinary Cloud E2E remains post-merge. Do not
-infer live acceptance from tooling checks or a nonblocking staging result.
+Use the installed-package runner's `inspect` mode to verify bindings without
+provisioning. Staging Validation runs the live suite and requires cleanup. Record
+actual live results separately from discovery or package checks.
 
 ### Documentation and release boundaries
 

README.md

@@ -1021,20 +1021,14 @@ uv sync --locked
 uv run --locked poe quality
 ```
 
-Live contract scenarios require an isolated fixture produced by
-`volcano-hosting/tests/sdk-contract/support/fixture.mjs`:
-
-```shell
-VOLCANO_SDK_CONTRACT_FIXTURE=/absolute/path/to/fixture.json \
-  uv run behave features/contract --junit --junit-directory reports/behave
-```
-
-The fixture must be an absolute path to a mode-`0600` JSON file.
+Hosting owns and runs the shared black-box acceptance suite during Staging Validation.
+It builds this repository's latest `main` and installs the wheel in a fresh environment.
+See [Hosting's testing guide](https://github.com/Kong/volcano-hosting/blob/main/docs/internal/guides/sdk-contract-testing.md).
 
 ## Release to PyPI
 
 Release Please creates a version and changelog PR from releasable commits.
-After its required checks pass, the existing auto-merge policy merges the PR.
+A maintainer manually merges the version PR after its required checks pass.
 The Volcano GitHub App creates the stable GitHub release, which automatically
 starts `publish.yml`. The workflow validates the tag, main ancestry, and package
 identity; runs CI; builds and smoke-tests the wheel and source distribution;