[WRONG BRANCH] release: promote 2.47.0 to main

.github/workflows/release.yml

@@ -334,40 +334,57 @@ jobs:
           }
 
       - name: Publish (or dry-run)
+        id: publication
         env:
           DRY_RUN: ${{ inputs.dry-run }}
           NPM_DIST_TAG: ${{ inputs.tag }}
         run: |
+          set -euo pipefail
           if [ "$DRY_RUN" = "true" ]; then
             echo "::notice::DRY RUN — building + packing, not publishing"
             npm run prepublishOnly
             npm pack --dry-run
           else
             npm publish --tag "$NPM_DIST_TAG" --access public
+            echo "published=true" >> "$GITHUB_OUTPUT"
           fi
 
-      # Confirm the registry actually has the new version (real publishes only).
+      # Publication is acknowledged before registry reads, which can lag or fail.
+      # Recover only observation failures in this run; never retry npm publish.
       - name: Post-publish registry smoke
-        if: ${{ inputs.dry-run != true }}
+        id: registry-smoke
+        if: ${{ inputs.dry-run != true && steps.publication.outputs.published == 'true' }}
         env:
           RELEASE_VERSION: ${{ inputs.version }}
+          PUBLISHED: ${{ steps.publication.outputs.published }}
         run: |
-          for attempt in $(seq 1 30); do
-            if VERSION=$(npm view "@bitkyc08/opencodex@${RELEASE_VERSION}" version 2>/dev/null); then
+          set -euo pipefail
+          test "$PUBLISHED" = "true" || {
+            echo "::error::No successful publication receipt; refusing registry recovery"
+            exit 1
+          }
+          pkg_name="$(node -p "require('./package.json').name")"
+          for attempt in $(seq 1 6); do
+            if VERSION=$(timeout --kill-after=2s 10s npm view "${pkg_name}@${RELEASE_VERSION}" version --fetch-retries=0 --fetch-timeout=8000 2>/dev/null); then
+              if [ "$VERSION" != "$RELEASE_VERSION" ]; then
+                echo "::error::Registry returned an unexpected version; refusing to create a release"
+                exit 1
+              fi
               echo "registry version=$VERSION"
-              test "$VERSION" = "$RELEASE_VERSION"
-              npm dist-tag ls @bitkyc08/opencodex
+              echo "verification=verified" >> "$GITHUB_OUTPUT"
+              echo "Registry verified ${pkg_name}@${RELEASE_VERSION}." >> "$GITHUB_STEP_SUMMARY"
+              timeout --kill-after=2s 10s npm dist-tag ls "$pkg_name" --fetch-retries=0 --fetch-timeout=8000 || echo "::warning::Could not read npm dist-tags; exact version was verified"
               exit 0
             fi
-            echo "::notice::@bitkyc08/opencodex@${RELEASE_VERSION} not visible in npm registry yet (attempt $attempt/30)"
-            sleep 10
+            echo "::notice::Registry lookup not confirmed (attempt $attempt/6)"
+            if [ "$attempt" -lt 6 ]; then sleep 5; fi
           done
-          echo "::error::npm registry smoke failed after 30 attempts"
-          npm view @bitkyc08/opencodex versions dist-tags --json || true
-          exit 1
+          echo "verification=pending" >> "$GITHUB_OUTPUT"
+          echo "::warning::npm publish succeeded, but registry verification remains pending; continuing GitHub release creation without republishing"
+          echo "Publication acknowledged for ${pkg_name}@${RELEASE_VERSION}; registry verification pending after bounded reads. Inspect the registry before announcing availability. Do not republish this version." >> "$GITHUB_STEP_SUMMARY"
 
       - name: Create GitHub release
-        if: ${{ inputs.dry-run != true }}
+        if: ${{ inputs.dry-run != true && steps.publication.outputs.published == 'true' }}
         env:
           GH_TOKEN: ${{ github.token }}
           RELEASE_VERSION: ${{ inputs.version }}

README.md

@@ -99,6 +99,26 @@ account exclusion, affinity expiry, or 401/403 and 429 recovery can rebind them.
 selection order when one of them — usually your Codex Desktop login — should only be reached for
 once the others are drained.
 
+### Sponsors
+
+Sponsors keep opencodex maintained across every upstream protocol change. Interested?
+See [SPONSORS.md](./SPONSORS.md).
+
+<!-- sponsors:main — one banner, model developers only; empty until a Main sponsor signs -->
+
+<!-- sponsors:standard — one row per sponsor, in order of signing. Uncomment the table with the first row:
+<table>
+<tbody>
+<tr>
+<td width="180"><a href="SPONSOR_URL"><img src="https://raw.githubusercontent.com/lidge-jun/opencodex/main/assets/sponsors/SPONSOR.png" alt="SPONSOR" width="150"></a></td>
+<td>Thanks to SPONSOR for sponsoring this project! BLURB</td>
+</tr>
+</tbody>
+</table>
+-->
+
+---
+
 <details>
 <summary>Docker Compose</summary>
 
@@ -211,6 +231,7 @@ see the [installation docs](https://opencodex.me/getting-started/installation/).
 - **Sub-agents on any model** — feature routed models in Codex's sub-agent picker, with v1/v2
   surface control and fallback chains. See the
   [sub-agent guide](https://opencodex.me/guides/sub-agent-surface/).
+<!-- sponsors:main-first-mention -->
 - **Log in once, skip the API key** — OAuth for xAI, Anthropic, and Kimi; or forward
   `codex login`, paste a key, or use `${ENV_VAR}` references.
 - **Web search & vision sidecars** — non-OpenAI models get real web search and image understanding
@@ -263,6 +284,7 @@ full-slash form keeps working too. Details: [model routing docs](https://opencod
 
 ## Providers & adapters
 
+<!-- sponsors:main-first-mention -->
 OpenAI (ChatGPT login or API key), Anthropic, Google Gemini, xAI, Kimi, Azure OpenAI, Ollama
 (local + Cloud), Cursor (experimental), and every OpenAI-compatible endpoint — plus DeepSeek,
 Groq, OpenRouter, Together, Fireworks, Cerebras, Mistral, Hugging Face, NVIDIA NIM, MiniMax,

SPONSORS.md

@@ -0,0 +1,105 @@
+# Sponsors
+
+opencodex is an independent, MIT-licensed project maintained without company backing. Provider
+sponsorships fund maintenance and keep the proxy current with every upstream protocol change.
+This page is the public rule set: what a sponsor gets, who qualifies for which tier, and how to
+ask. It is written so that a sponsor, a contributor, and a user reading the README all see the
+same terms.
+
+"Sponsor" here means a paying provider sponsor. It is unrelated to the `maintainer-sponsored`
+label in [`MAINTAINERS.md`](./MAINTAINERS.md), which is about a maintainer vouching for a
+contributor's change to a restricted surface.
+
+Sponsorship buys placement and maintenance attention. It never buys a change in routing behavior,
+a default model, a weaker security default, or an exception to the review policy in
+[`MAINTAINERS.md`](./MAINTAINERS.md). A sponsored preset goes through the same registry
+pattern, typecheck, tests, and review as any other provider.
+
+## Tiers
+
+Two tiers, split by what the sponsor is.
+
+### Main — model developers
+
+Reserved for organizations that train or host their own foundation models (the OpenAI,
+Anthropic, Google, Moonshot, MiniMax class). API relays and gateways are never sold Main
+regardless of budget.
+
+Every model developer is supported as a first-class provider whether or not it sponsors; that
+part does not change. A Main sponsor additionally receives:
+
+- The single banner slot above the sponsor table in the README (one at a time; see
+  [Placement](#placement)).
+- First mention in the README login and provider lines (the "Log in once" OAuth paragraph and
+  the Providers & adapters summary, both marked with a `sponsors:main-first-mention` comment)
+  and priority ordering in the built-in provider picker.
+- Everything in the Standard tier below.
+
+### Standard — relays, gateways, and API resellers
+
+For OpenAI-compatible relays, routers, gateways, and other resellers of model access. A Standard
+sponsor receives:
+
+- One row in the sponsor table: logo (about 150px wide, linking to the sponsor URL), a
+  "Thanks to X for sponsoring this project!" line, and a blurb of up to about 80 English words
+  supplied by the sponsor and published verbatim. The maintainer may decline or require edits to
+  text that is false, misleading, disparages third parties, or breaches applicable law or GitHub
+  policy. A second-language blurb (for example Chinese) may run alongside the English one.
+- A built-in provider preset (`ocx provider select <id>`) shipped in a public npm release,
+  listed near the top of the provider picker in the dashboard and CLI and marked as a sponsor
+  there. (The registry field and picker ordering that back this land with the first sponsor
+  preset; today the picker follows registry order.)
+- A detailed entry on the [providers page](https://opencodex.me/guides/providers/) of the docs
+  site.
+- Maintenance: if a release breaks the preset or its adapter, the maintainer fixes it; issues
+  filed against that provider are triaged first. There is no response-time SLA.
+
+## Placement
+
+The README sponsor section sits directly under **Quick start**, before the Docker Compose
+details, so it is on screen before a first-time visitor scrolls. It carries one line of context
+and the placements themselves:
+
+1. One Main banner (empty until a Main sponsor signs).
+2. The Standard table, one row per sponsor, in order of signing date.
+
+The README says nothing else about sponsorship; tiers, pricing, and contact channels live only on
+this page.
+
+The translated READMEs under [`readme/`](./readme) carry one linking line right after their
+own quick-start block instead of duplicating the section, so a sponsor change is one edit in
+English.
+
+## Pricing
+
+Pricing is by inquiry; there is no public rate card. Sponsors who sign before the repository
+reaches 20,000 GitHub stars lock in their rate for the length of their agreement. Rates rise
+once that mark is passed.
+
+Agreements are integration-scoped: they name the deliverables above, anchor the term to the npm
+release that ships them, and carry no marketing obligations on either side. Both sides can walk
+away with a pro-rated refund of unused months if the integration cannot be delivered.
+
+## How to ask
+
+- X: DM [@claudeebum](https://x.com/claudeebum)
+- Discord: [discord.gg/JEaPEtkHwh](https://discord.gg/JEaPEtkHwh), channel `#sponsors`
+- Email: jun@lidgeai.com
+
+Send what you are (model developer or relay), the base URL and model list of your
+OpenAI-compatible endpoint, and the tier you want. The maintainer replies with terms and a
+draft agreement.
+
+## What sponsors do not get
+
+- No influence on routing defaults, failover order, quota policy, or which provider a user's
+  request reaches.
+- No relaxation of the [security review](./MAINTAINERS.md) that applies to authentication,
+  credentials, or workflow changes.
+- No access to user data, request logs, or telemetry; opencodex does not collect any.
+- No say over unrelated issues, pull requests, or the release schedule.
+
+## Current sponsors
+
+Listed in the README sponsor section. This page carries the rules; the README carries the
+names.

devlog/_fin/260905_always_on_429_failover/090_outcome.md

@@ -18,7 +18,7 @@ the tree rather than against the plan — the plan's own criteria were satisfied
 Two were defects the fix itself created (#3499, #3503), three were surfaces still describing the
 old contract (#3517, #3520, #3523), one closed the structural gap that let this unit ship two
 subset-rotator loops (#3512), and one cleaned up after a collision with concurrent maintainer
-work (#3526). All are recorded in `091`.
+work (#3526). The runtime post-merge findings and CI lessons are recorded in `091`.
 
 ## What changed
 

devlog/_fin/260905_always_on_429_failover/091_post_merge_audit.md

@@ -67,14 +67,37 @@ The post-merge run on `dev` then showed `ci failure`, which was a genuinely alar
 out. It turned out to be cancellation by the maintainer's next merge two minutes later, not a
 real failure — every job read `cancelled`, not `failure`.
 
-**Rule:** verify with the check-runs API and require zero `null` conclusions, not a pass count:
+**Rule:** use the exact head SHA, require every expected aggregate or policy gate by name, and
+also require zero non-terminal check runs. A missing check is not success. Paginate before treating
+the returned set as complete:
 
 ```bash
-gh api repos/<owner>/<repo>/commits/<sha>/check-runs \
-  --jq '[.check_runs[] | .conclusion] | group_by(.) | map({(.[0]//"null"): length}) | add'
+set -o pipefail
+gh api --paginate repos/<owner>/<repo>/commits/<sha>/check-runs \
+  | jq -se '
+      [.[].check_runs[]] as $runs
+      | ["ci", "enforce-target", "hygiene", "react-doctor"] as $expected
+      | ($expected - [
+          $runs[]
+          | select(.status == "completed" and .conclusion == "success")
+          | .name
+        ]) as $missing
+      | [
+          $runs[]
+          | select(.status != "completed" or .conclusion == null)
+          | .name
+        ] as $pending
+      | if ($missing | length) == 0 and ($pending | length) == 0
+        then {ready: true, expected: $expected}
+        else error("missing=\($missing) pending=\($pending)")
+        end'
 ```
 
-A clean result looks like `{"skipped":3,"success":24}` — no `null` key at all.
+A clean result is `{"ready":true,...}` with exit status 0. This does not replace review-policy
+checks such as confirming the approval belongs to the same head. Every `$expected` value is an
+exact Checks API `.check_runs[].name`, not a workflow title or workflow-run name. If those required
+check-run names change, update this list with the policy; silently accepting an absent name
+recreates the original bug.
 
 The near-miss paid for itself: sweeping `dev` afterwards found a real defect. #3511 and #3513
 landed concurrently, one moving `anthropic-quorum-cache.test.ts` into `tests/routing/` and the