From 0cc5fcb33493325d2b7f566adc837d7cb8d94eab Mon Sep 17 00:00:00 2001 From: Haider Date: Wed, 9 Sep 2026 13:26:44 +0530 Subject: [PATCH 1/3] docs: add missing CHANGELOG entry for v0.11.0-beta.5 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit beta.5 was tagged without a changelog section (release-beta skill's gate list doesn't call one out) — fixing forward via PR. The already- built beta.5 binary still ships with beta.4 as its embedded latest entry, since the changelog is baked in at tag time; this is correct starting with the next beta. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01H8gZMvZunXzx4LPSZzCafq --- CHANGELOG.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 2eb35a703..e3395d168 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -5,6 +5,22 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). +## [0.11.0-beta.5] - 2026-09-09 + +> **Beta channel release.** Publishes to the npm `beta` dist-tag; `latest` (0.10.0) is unaffected. Install: `npm i -g @altimateai/altimate-code@beta`. + +### Added + +- **Altimate Base registration over HTTP, for non-TUI hosts.** Previously only the interactive TUI could ever mint a Base credential — a host that talks HTTP to `altimate serve` (e.g. the VS Code extension) saw Altimate Base in `GET /provider`'s `all` list but could never connect it, failing with `model altimate-base not found`. Two new routes: `GET /altimate/base/disclosure` (read-only consent text plus a hash the client echoes back) and `POST /altimate/base/register` (verifies the echoed hash, then registers). Gated per-process — the TUI worker still owns registration when it's the one serving HTTP, and any other host gets `501`. (#1266) + +### Changed + +- **Altimate Base consent gate copy softened.** Dropped "Logs are linked to a persistent per-installation identifier" from the dialog (still disclosed in docs); "Usage is rate limited" → "Usage can be rate limited." (#1268) + +### Fixed + +- **Datamate stdio MCP server now inherits the IDE entry's env** when wired from an IDE integration. (#1081) + ## [0.11.0-beta.4] - 2026-09-08 > **Beta channel release.** Publishes to the npm `beta` dist-tag; `latest` (0.10.0) is unaffected. Install: `npm i -g @altimateai/altimate-code@beta`. From 3ae1e5f7a4a965611d5d071603e3fc0a5f1bb46d Mon Sep 17 00:00:00 2001 From: Haider Date: Wed, 9 Sep 2026 13:30:53 +0530 Subject: [PATCH 2/3] docs: add a CHANGELOG gate to the release-beta process beta.5 shipped without a changelog entry because the skill's gate checklist never asked for one, unlike the stable /release flow which has a natural checkpoint (release branch + PR review) that would have caught it. Adds it as gate 0 in Step 3, and calls out in Hard Rules that it must land on main before the tag exists -- the changelog is baked into the compiled binary at build time, so fixing it after tagging only helps the next beta, not the one just cut. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01H8gZMvZunXzx4LPSZzCafq --- .claude/commands/release-beta.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/.claude/commands/release-beta.md b/.claude/commands/release-beta.md index eda20ec75..f332a2a47 100644 --- a/.claude/commands/release-beta.md +++ b/.claude/commands/release-beta.md @@ -75,6 +75,24 @@ issues the release workflow (full `bun turbo typecheck` + Verdaccio + npm publis will hit. Do NOT skip any of these: ```bash +# 0. CHANGELOG entry — MUST exist in the tagged commit, not after. The changelog +# is baked into the compiled binary + every npm package at build time +# (script/build.ts / script/publish.ts). A follow-up commit does NOT fix the +# binary about to be built — only the *next* beta will read the corrected +# entry, so this is not a "fix forward later" gate like the others below. +# Every prior beta (beta.1, beta.3, beta.4, ...) has its own +# "## [X.Y.Z-beta.N] - YYYY-MM-DD" section — match that format and voice. +git log ..HEAD --oneline # the commits this beta actually adds +# Read the actual PR for each one (gh pr view ) — do not write the entry +# from commit subjects alone, they're too terse to be useful changelog copy. +# Then add the section to CHANGELOG.md and commit it. +# +# Direct pushes to main are normally blocked (branch protection). If you're +# tagging from anywhere other than main itself — including a same-commit +# worktree — this commit has to land on main via a normal PR BEFORE the tag +# is cut, or the built binary ships one entry behind. Budget time for that +# PR before Step 4, don't tag first and try to fix forward. + # 1. FULL monorepo typecheck (what the release workflow runs — clean install to match CI) rm -rf node_modules && bun install --frozen-lockfile bun turbo typecheck --force # all packages, not just changed ones @@ -184,6 +202,11 @@ Only after the beta has soaked and the round-trip is proven: - The tag MUST contain `-beta.N`. A plain `vX.Y.Z` from this skill would hit `latest` — never do that here. +- **The CHANGELOG entry (Step 3, gate 0) must be committed and, if not on main + already, merged to main BEFORE the tag exists.** Discovered the hard way on + beta.5: tagging first and adding the entry afterward ships a binary with a + stale embedded changelog, and there is no way to fix that specific binary + short of a new tag. This is not a "fix forward" gate like the others. - Never skip Step 6 (the `latest`-didn't-move assertion). It is the one check that catches a channel-routing regression before it bricks everyone. - npm publishes are effectively irreversible — get the explicit user yes at From 5beb6c50b97299040dc9bb2bfa089fa630791d2b Mon Sep 17 00:00:00 2001 From: Haider Date: Wed, 9 Sep 2026 18:01:56 +0530 Subject: [PATCH 3/3] =?UTF-8?q?docs:=20address=20cubic=20review=20?= =?UTF-8?q?=E2=80=94=20fix=20path,=20shell-safe=20tag=20resolution,=20inva?= =?UTF-8?q?riant=20wording?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - packages/opencode/script/build.ts / packages/opencode/script/publish.ts, not script/build.ts at repo root (doesn't exist). - Resolve the previous beta tag with a real command instead of a literal placeholder, which a shell parses as redirection into a file named "beta-tag>" rather than a git range. - The actual invariant is "in the tagged commit," not "on main" -- Step 4 already supports tagging a branch. main's branch protection needing a PR first is a separate, situational fact about that one ref, not a rule the release process itself imposes. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01H8gZMvZunXzx4LPSZzCafq --- .claude/commands/release-beta.md | 44 ++++++++++++++++++++------------ 1 file changed, 28 insertions(+), 16 deletions(-) diff --git a/.claude/commands/release-beta.md b/.claude/commands/release-beta.md index f332a2a47..2c044e240 100644 --- a/.claude/commands/release-beta.md +++ b/.claude/commands/release-beta.md @@ -75,23 +75,30 @@ issues the release workflow (full `bun turbo typecheck` + Verdaccio + npm publis will hit. Do NOT skip any of these: ```bash -# 0. CHANGELOG entry — MUST exist in the tagged commit, not after. The changelog -# is baked into the compiled binary + every npm package at build time -# (script/build.ts / script/publish.ts). A follow-up commit does NOT fix the -# binary about to be built — only the *next* beta will read the corrected -# entry, so this is not a "fix forward later" gate like the others below. +# 0. CHANGELOG entry — MUST exist in the commit you are about to tag, not after. +# The changelog is baked into the compiled binary + every npm package at +# build time (packages/opencode/script/build.ts reads CHANGELOG.md into +# OPENCODE_CHANGELOG; packages/opencode/script/publish.ts ships it). The +# workflow builds from the TAGGED COMMIT, wherever it lives — a follow-up +# commit does NOT fix the binary about to be built from THIS tag, only the +# *next* beta will read the corrected entry, so this is not a "fix forward +# later" gate like the others below. # Every prior beta (beta.1, beta.3, beta.4, ...) has its own # "## [X.Y.Z-beta.N] - YYYY-MM-DD" section — match that format and voice. -git log ..HEAD --oneline # the commits this beta actually adds +LAST_BETA_TAG=$(git tag --list 'v*-beta.*' --sort=-version:refname | head -1) +test -n "$LAST_BETA_TAG" || { echo "No previous beta tag found — STOP"; exit 1; } +git log "${LAST_BETA_TAG}..HEAD" --oneline # the commits this beta actually adds # Read the actual PR for each one (gh pr view ) — do not write the entry # from commit subjects alone, they're too terse to be useful changelog copy. # Then add the section to CHANGELOG.md and commit it. # -# Direct pushes to main are normally blocked (branch protection). If you're -# tagging from anywhere other than main itself — including a same-commit -# worktree — this commit has to land on main via a normal PR BEFORE the tag -# is cut, or the built binary ships one entry behind. Budget time for that -# PR before Step 4, don't tag first and try to fix forward. +# The invariant is "in the tagged commit", not "on main" — Step 4 explicitly +# supports tagging from a branch, and the workflow builds whatever ref you +# tag regardless of main. main's branch protection is a separate, situational +# fact: if you can't push directly there (the usual case) and you're tagging +# main's own tip, this commit needs a normal PR merged first, or the tag you +# push next is missing it. A branch-beta tagged straight off its own branch +# has no such dependency — commit it there and tag. # 1. FULL monorepo typecheck (what the release workflow runs — clean install to match CI) rm -rf node_modules && bun install --frozen-lockfile @@ -202,11 +209,16 @@ Only after the beta has soaked and the round-trip is proven: - The tag MUST contain `-beta.N`. A plain `vX.Y.Z` from this skill would hit `latest` — never do that here. -- **The CHANGELOG entry (Step 3, gate 0) must be committed and, if not on main - already, merged to main BEFORE the tag exists.** Discovered the hard way on - beta.5: tagging first and adding the entry afterward ships a binary with a - stale embedded changelog, and there is no way to fix that specific binary - short of a new tag. This is not a "fix forward" gate like the others. +- **The CHANGELOG entry (Step 3, gate 0) must be committed into the commit you + tag, before the tag exists** — not "on main," specifically: the workflow + builds from the tagged ref, and Step 4 explicitly supports tagging a branch + that isn't main. Whether that commit needs a PR first is a separate, + situational fact about whether *you personally* can push directly to + whatever ref you're tagging (usually blocked for main, not for your own + branch). Discovered the hard way on beta.5: tagging first and adding the + entry afterward ships a binary with a stale embedded changelog, and there is + no way to fix that specific binary short of a new tag. This is not a "fix + forward" gate like the others. - Never skip Step 6 (the `latest`-didn't-move assertion). It is the one check that catches a channel-routing regression before it bricks everyone. - npm publishes are effectively irreversible — get the explicit user yes at