From 835e02e49c1b12f9439783667fe1f8bea9018247 Mon Sep 17 00:00:00 2001 From: SquarePots <46488165+squarepots@users.noreply.github.com> Date: Wed, 30 Sep 2026 20:16:07 +0800 Subject: [PATCH 1/2] Require one behavior per pull request and real-account acceptance before tagging Recent patch releases bundled several behaviors with a version bump and were first exercised with real accounts only after the public installer existed, so provider-facing regressions reached users. Keep each pull request to one behavior, move the version change to its own release commit, and accept account-behavior releases with real accounts on a maintainer preview before the tag. The maintainer can waive that check. Co-Authored-By: Claude Opus 5.5 --- AGENTS.md | 7 +++++++ docs/release.md | 36 +++++++++++++++++++++++++++++++++++- docs/testing.md | 7 ++++--- 3 files changed, 46 insertions(+), 4 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index fee2a58..e7f4b77 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -61,6 +61,10 @@ path, account mirror, or parallel source of truth. - Never force-push, rewrite history, push a protected branch, or stage unrelated work. Use branch and PR metadata that describes the accepted product change. +- Keep each pull request to one independently reviewable behavior, with its + tests and the documentation it changes. Change the version only in a + separate release commit; a product pull request leaves the version files + untouched. ## Documentation routing @@ -98,6 +102,9 @@ normal release sequence for that change. Unless the maintainer specifies a version, choose the next unused patch version; after the required checks, tag the exact merged `main` commit, run the existing production updater-signing workflow, inspect the draft assets and notes, and publish the verified Release. +For a release that changes account behavior, the required checks include the +real-account acceptance in `docs/release.md`, which only the maintainer can +perform or waive. An authorization in the current conversation persists across its turns. Do not ask again solely because the version has been chosen or the workflow reaches signing or publication. A review-only or stop request takes precedence and diff --git a/docs/release.md b/docs/release.md index 1382092..d846ac0 100644 --- a/docs/release.md +++ b/docs/release.md @@ -92,12 +92,42 @@ official Codex installer's default `$HOME/.local/bin/codex` location. A custom Codex location must be in the graphical session's `PATH` or set with `GSWITCH_CODEX_BIN`. +## Real-account acceptance + +Tests and fictional-data screenshots cannot show how the provider or an +installed Codex treats a real account. A release that changes sign-in, +switching, quota, Wake, credential storage, or recovery is therefore accepted +with real accounts before its tag is pushed, not after the public installer +exists. + +The agent builds the [maintainer Windows preview](#maintainer-windows-preview) +from the merged `main` commit and hands it over; only the maintainer uses real +accounts. With at least two saved ChatGPT accounts, the maintainer checks: + +1. launch shows the current account and loads each card's quota; +2. Switch to another saved account with Codex closed, then switch back; +3. Refresh one account, then Refresh all; +4. Wake one account and read its result; +5. **Sign in again** from a card menu replaces that saved login, and the + current account's renewed login is applied or offered as **Apply**; +6. an account whose saved sign-in no longer works shows **Sign in required** + and recovers through **Sign in again**, when such an account is available. + +Reset-credit redemption is not part of this list; it keeps its own explicit +confirmation. The maintainer may waive the acceptance for a release, including +in the publish request itself. Record the preview commit and either the result +or the waiver in the release pull request. The version commit that follows may +differ from the accepted commit only in the version files. A failed or +unanswered acceptance stops the release like any other failed gate; do not +describe a waived or unperformed flow as validated. + ## Release workflow Pushing a tag named `v` starts the sole release workflow. The tag must point to the exact current merged `main` commit and match `src-tauri/tauri.conf.json`. Run the remote CI path against that commit before -tagging it. The workflow runs version, frontend, and Rust checks, then builds +tagging it, and complete the [real-account acceptance](#real-account-acceptance) +when the release changes account behavior. The workflow runs version, frontend, and Rust checks, then builds all release bundles locally. It smoke checks the Windows install and uninstall, both macOS DMGs and updater archives, and both Linux package payloads before signing the final updater bytes. The workflow verifies signatures against the @@ -191,6 +221,10 @@ pnpm run version:sync pnpm run version:check ``` +Make the version change its own commit and pull request, after the product +changes it releases have merged. A product pull request does not touch the +version files. + After an authorized version change is merged and the exact `main` commit passes the required remote checks, tag that commit as the matching `v`. The workflow creates a draft; review its assets and notes before publishing it. diff --git a/docs/testing.md b/docs/testing.md index 2ca237e..63dc796 100644 --- a/docs/testing.md +++ b/docs/testing.md @@ -226,6 +226,7 @@ Standard CI does not by itself prove: - the exact permissions of a packaged artifact; - public-release readiness. -Those claims require the matching integration or release check. Never report a -platform, provider, installer, or recovery path as validated unless that exact -proof ran. +Those claims require the matching integration or release check. Real-account +behavior is accepted before a release through the procedure in +[`release.md`](./release.md#real-account-acceptance). Never report a platform, +provider, installer, or recovery path as validated unless that exact proof ran. From 1d550fc08ac60312dd43e722f51a54627e9bfe0f Mon Sep 17 00:00:00 2001 From: SquarePots <46488165+squarepots@users.noreply.github.com> Date: Wed, 30 Sep 2026 20:17:51 +0800 Subject: [PATCH 2/2] Derive the maintainer preview version from the next patch With the version change moved to its own release commit, a preview built from a product commit still carries the last released version. A suffix on that version sorts below the installed release, so the preview would be offered the public release as an update. Use the next patch version. Co-Authored-By: Claude Opus 5.5 --- docs/release.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/release.md b/docs/release.md index d846ac0..5bef50d 100644 --- a/docs/release.md +++ b/docs/release.md @@ -60,13 +60,15 @@ Issue. If feedback leads to another change, commit it and increase the preview suffix before rebuilding. From the repository root in PowerShell 7, derive a unique preview version from -the current product version, then build: +the next patch version, then build. Product pull requests leave the version +files at the last release, so a suffix on the current version would sort below +the installed release and be offered that release as an update: ```powershell $dirty = git status --porcelain if ($dirty) { throw 'Build the preview from a clean, committed source revision.' } -$baseVersion = node -p "require('./src-tauri/tauri.conf.json').version" -$previewVersion = "$baseVersion-rc.1" +$major, $minor, $patch = (node -p "require('./src-tauri/tauri.conf.json').version").Split('.') +$previewVersion = "$major.$minor.$([int]$patch + 1)-rc.1" New-Item -ItemType Directory -Force -Path 'src-tauri/target' | Out-Null $previewConfig = Join-Path (Resolve-Path 'src-tauri/target').Path "tauri-$previewVersion.json" Set-Content -LiteralPath $previewConfig -Value "{`"version`":`"$previewVersion`"}" -NoNewline -Encoding utf8