Release workflow: attach the files before publishing; test build is 0.9.0-dev2

.github/workflows/release.yml

@@ -72,14 +72,23 @@ jobs:
           git fetch --force origin "refs/tags/${GITHUB_REF_NAME}:refs/tags/${GITHUB_REF_NAME}"
           git tag -l --format='%(contents:body)' "${GITHUB_REF_NAME}" > "${RUNNER_TEMP}/release-notes.md"
 
-      # A tag with a suffix (v0.9.0-dev, v1.0.0-rc1) is a test build, shown as a pre-release
+      # A tag with a suffix (v0.9.0-dev, v1.0.0-rc1) is a test build, shown as a pre-release.
+      # The repository's releases are immutable: nothing can be attached once a release is
+      # published. The action publishes a pre-release before uploading, so the release is
+      # created as a draft, the files are attached, and the next step publishes it.
       - name: Create GitHub Release
         uses: softprops/action-gh-release@v2
         with:
+          draft: true
           prerelease: ${{ contains(github.ref_name, '-') }}
           body_path: ${{ runner.temp }}/release-notes.md
           append_body: true
           generate_release_notes: true
           files: |
             build/libs/wpilog-mcp-${{ steps.version.outputs.version }}-all.jar
             vscode-extension/*.vsix
+
+      - name: Publish the release
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: gh release edit "${GITHUB_REF_NAME}" --draft=false --repo "${{ github.repository }}"

CHANGELOG.md

@@ -76,6 +76,7 @@ Most of this release is robustness work from [doc/ROBUSTNESS_REVIEW.md](doc/ROBU
 - `power_analysis` reports `channel_analysis` for every current entry (signed peak and its time, minimum, maximum, average), expanding per-channel arrays such as `/PowerDistribution/ChannelCurrent`, capped by `channel_limit` (default 30). Current entries are recognized by a naming rule, so names like `CurrentLimit` are not taken for currents.
 
 ### Fixed
+- The release workflow attaches the JAR and the `.vsix` before the release is published, and takes the release notes from the annotated tag's message. The repository's releases are immutable, and a pre-release used to be published first, so `v0.9.0-dev` was published with no files; its tag name cannot be reused, so the test build is `v0.9.0-dev2`.
 - VS Code extension: the extension's version comes from `build.gradle` (`./gradlew syncExtensionVersion`, which every extension task and the release workflow run). Its `package.json` had stayed at 0.8.2, so a release would have looked already installed; a release now stops when its tag does not match `build.gradle`.
 - VS Code extension: the TBA API key is kept in VS Code's secret storage (**WPILog Analyzer: Set The Blue Alliance API Key** and **Clear The Blue Alliance API Key**) instead of in plaintext settings and `.mcp.json`, where a commit could publish it. On upgrade, a key found in settings is moved there, and a key an earlier version wrote into `.mcp.json` is removed with a note to revoke it if the file was shared.
 - VS Code extension: requires VS Code 1.101 or later (`engines.vscode` is `^1.101.0`). On 1.100 it installed but failed on activation.

build.gradle

@@ -12,7 +12,7 @@ plugins {
 }
 
 group = 'org.triplehelix'
-version = '0.9.0-dev'
+version = '0.9.0-dev2'
 
 java {
     sourceCompatibility = JavaVersion.VERSION_17

doc/DEVELOPMENT.md

@@ -120,7 +120,7 @@ The extension's version is the project version in `build.gradle`. Every extensio
 1. Set `version` in `build.gradle` (e.g. `0.9.0`) and run `./gradlew syncExtensionVersion`; a test fails until the extension's files match.
 2. Regenerate [TOOL_RESPONSES.md](TOOL_RESPONSES.md), whose first lines carry the version (step 7 of [Changing or Adding a Tool](#changing-or-adding-a-tool)).
 3. Move the `[Unreleased]` entries in [CHANGELOG.md](../CHANGELOG.md) under the new version.
-4. Commit, then tag `v0.9.0` with an annotated tag (`git tag -a v0.9.0 -F notes.md`, whose first line is a title and whose body becomes the release notes, with the list of merged pull requests appended) and push the tag. The release workflow (`.github/workflows/release.yml`) builds the server JAR and the `.vsix` under that version and attaches both to a GitHub release. It stops if the tag and `build.gradle` disagree. A tag with a suffix, such as `v0.9.0-dev`, is published as a pre-release; for one, skip steps 1 to 3 and tag the version `build.gradle` already carries.
+4. Commit, then tag `v0.9.0` with an annotated tag (`git tag -a v0.9.0 -F notes.md`, whose first line is a title and whose body becomes the release notes, with the list of merged pull requests appended) and push the tag. The release workflow (`.github/workflows/release.yml`) builds the server JAR and the `.vsix` under that version and attaches both to a GitHub release. It stops if the tag and `build.gradle` disagree. A tag with a suffix, such as `v0.9.0-dev`, is published as a pre-release; for one, skip steps 2 and 3 and tag the version `build.gradle` carries. The repository's releases are immutable: a published release's files and tag cannot be changed, and a deleted release's tag name cannot be used again, so a release that went wrong gets a new version (`0.9.0-dev2`), never a moved tag.
 
 ## Contributing
 

vscode-extension/package.json

@@ -2,7 +2,7 @@
   "name": "wpilog-analyzer",
   "displayName": "WPILog Analyzer",
   "description": "AI-powered FRC robot log analysis via MCP. Analyzes .wpilog telemetry from the roboRIO.",
-  "version": "0.9.0-dev",
+  "version": "0.9.0-dev2",
   "publisher": "TripleHelixProgramming",
   "license": "MIT",
   "icon": "images/icon.png",