[Chore] Use a single PR flow for extension releases

.github/workflows/release-validation.yml

@@ -0,0 +1,89 @@
+name: Release Validation
+
+on:
+    workflow_dispatch:
+    pull_request:
+        types: [opened, reopened, synchronize, ready_for_review]
+        paths:
+            - "CHANGELOG.md"
+            - "README.md"
+            - "locales/*/README.md"
+            - "src/package.json"
+            - "src/CHANGELOG.md"
+            - "src/package.nls*.json"
+            - "src/core/webview/ClineProvider.ts"
+            - "webview-ui/src/components/chat/Announcement.tsx"
+            - "releases/**"
+            - ".github/workflows/release-validation.yml"
+
+jobs:
+    validate-release:
+        runs-on: ubuntu-latest
+        permissions:
+            contents: read
+
+        steps:
+            - name: Checkout code
+              uses: actions/checkout@v4
+
+            - name: Setup Node.js and pnpm
+              uses: ./.github/actions/setup-node-pnpm
+              with:
+                  install-args: "--frozen-lockfile"
+
+            - name: Validate package identity
+              run: |
+                  package_name=$(node -p "require('./src/package.json').name")
+                  publisher=$(node -p "require('./src/package.json').publisher")
+
+                  test "$package_name" = "zoo-code"
+                  test "$publisher" = "ZooCodeOrganization"
+
+            - name: Validate release metadata
+              run: |
+                  package_version=$(node -p "require('./src/package.json').version")
+
+                  node -e 'const version = process.argv[1]; if (!/^\d+\.\d+\.\d+(?:[-+][0-9A-Za-z.-]+)?$/.test(version)) { throw new Error("Invalid SemVer version: " + version) }' "$package_version"
+                  grep -q "## \\[$package_version\\]\\|## $package_version" CHANGELOG.md
+
+            - name: Build workspace packages
+              run: |
+                  pnpm --filter @roo-code/build build
+                  pnpm --filter @roo-code/vscode-webview build
+
+            - name: Bundle extension and verify README sync
+              env:
+                  POSTHOG_API_KEY: ${{ secrets.POSTHOG_API_KEY }}
+              run: |
+                  pnpm --filter ./src bundle --production
+                  cmp README.md src/README.md
+
+            - name: Package extension
+              env:
+                  POSTHOG_API_KEY: ${{ secrets.POSTHOG_API_KEY }}
+              run: |
+                  package_version=$(node -p "require('./src/package.json').version")
+                  pnpm --filter ./src vsix
+
+                  vsix_path="bin/zoo-code-${package_version}.vsix"
+                  test -f "$vsix_path"
+
+                  unzip -l "$vsix_path" > /tmp/zoo-code-vsix-contents.txt
+                  grep -q "extension/package.json" /tmp/zoo-code-vsix-contents.txt
+                  grep -q "extension/package.nls.json" /tmp/zoo-code-vsix-contents.txt
+                  grep -q "extension/dist/extension.js" /tmp/zoo-code-vsix-contents.txt
+                  grep -q "extension/webview-ui/audio/celebration.wav" /tmp/zoo-code-vsix-contents.txt
+                  grep -q "extension/webview-ui/build/assets/index.js" /tmp/zoo-code-vsix-contents.txt
+                  grep -q "extension/assets/codicons/codicon.ttf" /tmp/zoo-code-vsix-contents.txt
+                  grep -q "extension/assets/vscode-material-icons/icons/3d.svg" /tmp/zoo-code-vsix-contents.txt
+
+            - name: Validate packaged manifest identity
+              run: |
+                  package_version=$(node -p "require('./src/package.json').version")
+                  vsix_path="bin/zoo-code-${package_version}.vsix"
+
+                  artifact_name=$(unzip -p "$vsix_path" extension/package.json | jq -r '.name')
+                  artifact_publisher=$(unzip -p "$vsix_path" extension/package.json | jq -r '.publisher')
+
+                  test "$artifact_name" = "zoo-code"
+                  test "$artifact_publisher" = "ZooCodeOrganization"

.roo/commands/release.md

@@ -1,45 +1,111 @@
 ---
-description: "Create a new release of the Roo Code extension"
+description: "Prepare a new release of the Zoo Code extension"
 argument-hint: patch | minor | major
 mode: code
 ---
 
-1. Identify the SHA corresponding to the most recent release using GitHub CLI: `gh release view --json tagName,targetCommitish,publishedAt`
-2. Analyze changes since the last release using: `gh pr list --state merged --base main --json number,title,author,url,mergedAt,closingIssuesReferences --limit 1000 -q '[.[] | select(.mergedAt > "TIMESTAMP") | {number, title, author: .author.login, url, mergedAt, issues: .closingIssuesReferences}] | sort_by(.number)'`
-3. For each PR with linked issues, fetch the issue details to get the issue reporter: `gh issue view ISSUE_NUMBER --json number,author -q '{number, reporter: .author.login}'`
-4. Summarize the changes. If the user did not specify, ask them whether this should be a major, minor, or patch release.
-5. Create a changeset in .changeset/v[version].md instead of directly modifying package.json. The format is:
+1. Identify the most recent stable extension release:
 
-```
----
-"roo-cline": patch|minor|major
----
-[list of changes]
-```
-
-- Always include contributor attribution and the PR number: use "(PR #<prNumber> by @username)".
-- For PRs that close issues, include both the issue number and the PR number and authors: "- Fix: Description (#123 by @reporter, PR #456 by @contributor)"
-- For PRs without linked issues, include the PR number and author: "- Add support for feature (PR #456 by @contributor)"
-- Provide brief descriptions of each item to explain the change
-- Order the list from most important to least important
-- Example formats:
-    - With issue: "- Fix: Resolve memory leak in extension (#456 by @issueReporter, PR #789 by @prAuthor)"
-    - Without issue: "- Add support for Gemini 2.5 Pro caching (PR #789 by @contributor)"
-- CRITICAL: Include EVERY SINGLE PR in the changeset - don't assume you know which ones are important. Count the total PRs to verify completeness and cross-reference the list to ensure nothing is missed.
-
-6. If the generate_image tool is available, create a release image at `releases/[version]-release.png`
-    - The image should feature a realistic-looking kangaroo doing something human-like that relates to the main highlight of the release
-    - Pass `releases/template.png` as the reference image for aspect ratio and kangaroo style
-    - Add the generated image to .changeset/v[version].md before the list of changes with format: `![X.Y.Z Release - Description](/releases/X.Y.Z-release.png)`
-7. If a major or minor release:
-    - Ask the user what the three most important areas to highlight are in the release
-    - Update the English version relevant announcement files and documentation (webview-ui/src/components/chat/Announcement.tsx, README.md, and the `latestAnnouncementId` in src/core/webview/ClineProvider.ts)
-    - Ask the user to confirm that the English version looks good to them before proceeding
-    - Use the new_task tool to create a subtask in `translate` mode with detailed instructions of which content needs to be translated into all supported languages (The READMEs as well as the translation strings)
-8. Create a new branch for the release preparation: `git checkout -b release/v[version]`
-9. Commit and push the changeset file and any documentation updates to the repository: `git add . && git commit -m "chore: add changeset for v[version]" && git push origin release/v[version]`
-10. Create a pull request for the release: `gh pr create --title "Release v[version]" --body "Release preparation for v[version]. This PR includes the changeset and any necessary documentation updates." --base main --head release/v[version]`
-11. The GitHub Actions workflow will automatically:
-    - Create a version bump PR when changesets are merged to main
-    - Update the CHANGELOG.md with proper formatting
-    - Publish the release when the version bump PR is merged
+    ```bash
+    gh release view --json tagName,targetCommitish,publishedAt
+    ```
+
+2. Analyze changes since that release:
+
+    ```bash
+    gh pr list --state merged --base main --json number,title,author,url,mergedAt,closingIssuesReferences --limit 1000 -q '[.[] | select(.mergedAt > "TIMESTAMP") | {number, title, author: .author.login, url, mergedAt, issues: .closingIssuesReferences}] | sort_by(.number)'
+    ```
+
+3. For each PR with linked issues, fetch the issue reporter:
+
+    ```bash
+    gh issue view ISSUE_NUMBER --json number,author -q '{number, reporter: .author.login}'
+    ```
+
+4. Summarize the changes. If the user did not specify a release type, ask whether this should be a major, minor, or patch release.
+
+5. Review and update the Marketplace-facing root `README.md`.
+
+    - Treat root `README.md` as the source of truth for Marketplace content.
+    - Update the "What's New" section for the release when appropriate.
+    - Do not manually edit `src/README.md`; the extension bundle step copies root `README.md` into `src/README.md`.
+    - Check for stale upstream Roo Code wording that should now say Zoo Code.
+
+6. Create the release notes as a changeset file at `.changeset/v[version].md`, then run `pnpm changeset:version` on the release branch before opening the PR.
+
+    ```md
+    ---
+    "zoo-code": patch|minor|major
+    ---
+
+    [list of changes]
+    ```
+
+    - Always include contributor attribution and the PR number: use `(PR #<prNumber> by @username)`.
+    - For PRs that close issues, include both issue and PR authors: `- Fix: Description (#123 by @reporter, PR #456 by @contributor)`.
+    - For PRs without linked issues, include the PR number and author: `- Add support for feature (PR #456 by @contributor)`.
+    - Provide brief descriptions of each item to explain the change.
+    - Order the list from most important to least important.
+    - Include every PR in the release window. Count the PRs and cross-reference the list before continuing.
+
+7. If an image generation tool is available, create a release image at `releases/[version]-release.png`.
+
+    - The image should relate to the main release highlight and fit the existing release-image style.
+    - Add the generated image to `.changeset/v[version].md` before the list of changes:
+
+        ```md
+        ![X.Y.Z Release - Description](/releases/X.Y.Z-release.png)
+        ```
+
+8. For a major or minor release:
+
+    - Ask the user what three areas should be highlighted.
+    - Update relevant announcement files and documentation, including `webview-ui/src/components/chat/Announcement.tsx`, `README.md`, and the `latestAnnouncementId` in `src/core/webview/ClineProvider.ts`.
+    - Ask the user to confirm the English announcement before proceeding.
+    - Arrange translation updates for all supported locales affected by README, announcement, or package localization changes.
+
+9. Create the release branch:
+
+    ```bash
+    git checkout -b release/v[version]
+    ```
+
+10. Generate the final release state on that branch:
+
+    ```bash
+    pnpm changeset:version
+    ```
+
+    - This should update `src/package.json`, `CHANGELOG.md`, and `src/CHANGELOG.md`, then consume the `.changeset` file.
+    - Review the generated version and changelog before opening the PR.
+
+11. Open a single release PR with the fully generated release state.
+
+    ```bash
+    git add CHANGELOG.md src/CHANGELOG.md src/package.json README.md locales/*/README.md src/package.nls*.json
+    # If generated or updated:
+    git add releases/[version]-release.png webview-ui/src/components/chat/Announcement.tsx src/core/webview/ClineProvider.ts
+    git commit -m "chore: prepare v[version] release"
+    git push origin release/v[version]
+    gh pr create --title "Release v[version]" --body "Release preparation for v[version]. This PR includes the final version bump, changelog updates, Marketplace README updates, and any release assets or announcement changes." --base main --head release/v[version]
+    ```
+
+    - There is no separate version-bump PR in this flow.
+    - The release PR should already contain the final version number and generated changelog updates.
+    - If the release includes translated README or package-localization updates, include those files in the same PR.
+    - Let the release validation workflow and normal PR checks run before merge.
+
+12. After the release PR is merged, create the release tag on the resulting `main` commit:
+
+    ```bash
+    git switch main
+    git pull origin main
+    git tag v[version]
+    git push origin v[version]
+    ```
+
+13. The stable publish workflow runs from the `v[version]` tag.
+
+    - Do not create the tag before the release PR is merged.
+    - The publish workflow validates that the tag version matches `src/package.json`.
+    - Marketplace and Open VSX publishing use the configured CI secrets.