Add unified release strategy across spec and all four clients by colbylwilliams · Pull Request #160 · microsoft/agent-host-protocol

colbylwilliams · 2026-05-27T23:03:15Z

What

Establishes a unified release model for the polyglot AHP repo so the spec and the four clients (Rust, Kotlin, Swift, TypeScript) can each ship through a coherent, automated, symmetrically tag-driven pipeline.

Each artifact gets its own native-SemVer track in its own ecosystem; a machine-readable mapping connects each client release to the protocol version(s) it implements. The Swift release gap is closed (no pipeline existed before; SwiftPM consumers couldn't pin to a Swift-specific version), the spec itself becomes a first-class release artifact via spec/v* tags, and the TypeScript ADO publish pipeline from #157 gets a tag-driven GHA front door so its release flow matches the other clients.

Why

After #157 merged, each of the four clients has a publish path. Several gaps remained that this PR closes:

The Swift package had no release pipeline. SwiftPM only resolves bare semver tags at the repo root; the only tag that exists today is rust/v0.1.0, which it ignores. from: "0.1.0" in the Swift README cannot resolve.
There was no spec release artifact. Bumping PROTOCOL_VERSION was just a code change — no GitHub Release, no versioned schema bundle, no machine-readable diff of what changed.
Versions drift silently. Rust at 0.1.0, Kotlin/TS at 0.2.0, no formal statement of which protocol each client implements.
No release-time enforcement. Nothing today guarantees a CHANGELOG entry exists for the version being released, or that the package version in Cargo.toml / gradle.properties / package.json agrees with what the source claims to support.
The TypeScript ADO pipeline lacked a tag-driven front door, so its release flow diverged from the other clients. Maintainers had to remember to manually toggle the publishPackage parameter in the ADO UI instead of just pushing a tag like everywhere else.

Coupling all clients to the spec's SemVer plus a fourth segment was considered and rejected — npm/Cargo/SwiftPM all reject non-three-part semver, and it forces dead releases of unchanged clients every time the spec patches.

How

Tag conventions (final — symmetric across all clients)

Artifact	Tag pattern	Workflow
Spec	`spec/vX.Y.Z`	`publish-spec.yml` (new)
Rust	`rust/vX.Y.Z`	`publish-rust.yml` (updated)
Kotlin	`kotlin/vX.Y.Z`	`publish-kotlin.yml` (updated)
TypeScript	`typescript/vX.Y.Z`	`publish-typescript.yml` (new) → triggers ADO `clients/typescript/pipeline.yml` (#157) via Pipelines REST API
Swift	`vX.Y.Z` (bare)	`publish-swift.yml` (new)

Bare vX.Y.Z tags at the repo root are reserved for Swift because SwiftPM only resolves bare semver tags at the manifest's repo root.
The TypeScript GHA workflow does all the validation (tag ↔ package.json match, CHANGELOG entry, metadata, full client build + tests), then POSTs to the ADO Pipelines REST API with templateParameters.publishPackage: true and refName pinned to the tag. The ADO pipeline performs the actual signed npm publish via the vscode-engineering template. Manual ADO trigger is preserved as a hotfix escape hatch.

Spec ↔ client mapping (three layers, all CI-enforced)

Generated constant — every client exports SUPPORTED_PROTOCOL_VERSIONS: string[] (most-preferred-first) alongside PROTOCOL_VERSION. Consumers pass it to initialize directly.
Machine-readable release-metadata.json — { client, packageVersion, supportedProtocolVersions } per client, generated and committed.
Human-readable CHANGELOG.md — Keep-a-Changelog format with a mandatory Implements AHP <version> line per release.

Two verification scripts cross-check four independent sources:

npm run verify:release-metadata — generated Version.generated.* files match the registry; release-metadata.json matches the native manifest + registry. Fails CI with a machine-friendly diff on drift.
npm run verify:changelog — every client's CHANGELOG has a ## [X.Y.Z] entry matching its current native manifest version. Normalizes Kotlin's -SNAPSHOT suffix.

Both run in npm test, ci.yml, every per-tag publish workflow, and the ADO pipeline.yml for defense in depth on manual ADO triggers.

What CI / publish workflows now guard against

Drift caught by	How
`Version.generated.{rs,kt,swift}` vs `types/version/registry.ts`	Per-language CI job re-runs `npm run generate:<lang>` and fails on diff (Rust check newly added).
`release-metadata.json` vs native manifest + registry	`npm run verify:release-metadata` (CI + every publish workflow + ADO pipeline).
Native package version vs CHANGELOG entry	`npm run verify:changelog` (CI + every publish workflow + ADO pipeline).
Tag vs manifest version	Every tag-driven publish workflow's "Verify tag matches" step.
Tag-derived version vs CHANGELOG	Every tag-driven publish workflow's `grep -qE '^## \[<tag-version>\]'` step (defense-in-depth alongside `verify:changelog`).

Initial release-metadata state (truthful)

Client	`packageVersion`	`supportedProtocolVersions`
Rust	`0.1.0`	`["0.2.0"]`
Kotlin	`0.2.0-SNAPSHOT`	`["0.2.0"]`
Swift	`0.2.0`	`["0.2.0"]`
TypeScript	`0.2.0`	`["0.2.0"]`

The Rust packageVersion/supported-protocol drift is intentional and documented — it surfaces the existing reality that the in-tree code already supports protocol 0.2.0 even though the latest published crate is 0.1.0. The next Rust release should bump to 0.2.0.

Documentation structure

RELEASING.md (new, root) — operational maintainer doc: tag conventions, per-client release flows, CI guards, and the one-time required-infrastructure table.
CONTRIBUTING.md (~95 lines, focused) — contributor-facing: repo layout, dev loop, brief Releases pointer, an "Updating CHANGELOGs" section (path → changelog map, Keep-a-Changelog conventions), and code-style/review.
AGENTS.md (new, root) — cross-cutting rules for AI coding agents working in the repo. Today it encodes the per-PR CHANGELOG-update convention (mirrors the same rule in CONTRIBUTING.md) so agents add the [Unreleased] bullet at the same time as their code change, instead of relying on the release-time verify:changelog gate as the only catch.
docs/specification/versioning.md — protocol-level versioning policy (SemVer rules, supported-version window) unchanged in scope, with its release-mechanics pointer updated to RELEASING.md.
Per-client CHANGELOG.md files (Keep-a-Changelog format, Implements AHP <version> line per release) added for spec + all four clients.

Verification

Locally on this branch (with origin/main merged in, including #149 and #157):

✅ npm run typecheck + npm run lint clean
✅ npm run generate is idempotent (no second-round diff)
✅ npm run verify:release-metadata ✓ green; negative test (mutated package version in metadata) fails with clear expected/actual diff
✅ npm run verify:changelog ✓ green; negative test (bumped clients/typescript/package.json to 9.9.9) fails with "missing '## [9.9.9]' heading"
✅ cargo test --workspace all green (incl. doc tests)
✅ swift build && swift test — 95 / 95 tests pass
✅ TypeScript client npm test — 23 / 23 tests pass, npm run build clean
✅ npm run docs:build clean (2 pre-existing dead links unrelated to this PR)
✅ All eight workflow YAML files (incl. the ADO pipeline.yml) parse with yaml.safe_load
✅ Kotlin verified via the generator regeneration + diff check (no JDK locally; CI will run ./gradlew check)

Required infrastructure

Used by	Credential	State
`publish-rust.yml`	`crates-io` env + `CARGO_REGISTRY_TOKEN`	already provisioned
`publish-kotlin.yml`	`maven-central` env + Sonatype creds + PGP	already provisioned
`publish-typescript.yml`	`ado-typescript-publish` env + `ADO_PIPELINE_TRIGGER_PAT` secret + `ADO_ORGANIZATION` / `ADO_PROJECT` / `ADO_PIPELINE_ID` variables	*new — needs admin setup before the first `typescript/v` tag.** The PAT needs "Build (Read & execute)" scope on the ADO project. The actual npm publish creds stay inside ADO.
`clients/typescript/pipeline.yml`	ADO npm service connection	provisioned inside Microsoft ADO tenant (#157)
`publish-swift.yml`, `publish-spec.yml`	default `GITHUB_TOKEN`	no new secrets needed

The ado-typescript-publish environment can also be configured with a manual-approval protection rule if maintainers want a human gate between "tag pushed" and "npm publish runs."

Not in this PR (deliberate follow-ups)

A non-blocking PR-time CHANGELOG hint (Tier 2 from the design discussion): a scripts/suggest-changelog.ts that diffs PR head vs. base and emits a ::notice:: if any user-visible-looking change has no matching [Unreleased] bullet. Cheap to add later if the AGENTS.md / CONTRIBUTING.md guidance proves insufficient in practice.
Machine-readable diff of "what's new between spec X and spec Y" (publish-spec.yml snapshots the current introduced-in maps; diffing two snapshots is a v2).
Negotiation tests across multiple supported versions — every client advertises a single version today.
Decoupling the Rust workspace version (so ahp-ws can patch without republishing ahp-types / ahp). Documented in RELEASING.md; not urgent.
The Rust 0.1.0 → 0.2.0 bump itself, to align the package version with the supported protocol version. The infrastructure in this PR makes it a one-line change but the decision is left to a follow-up.

Establishes a unified release model: each artifact (the spec and the four clients) versions independently on its own native SemVer track, with a machine-readable mapping between client releases and the protocol version(s) they implement. Spec - Export SUPPORTED_PROTOCOL_VERSIONS from types/version/registry.ts (most-preferred-first array, invariant-checked against PROTOCOL_VERSION) - Add registry.test.ts asserting semver shape, ordering, and uniqueness - Root CHANGELOG.md for the spec Generators - New scripts/read-protocol-versions.ts shared helper that parses PROTOCOL_VERSION + SUPPORTED_PROTOCOL_VERSIONS from the registry via ts-morph AST traversal (handles Object.freeze([...]) and `as const`) - Rust generator: extend version.rs with SUPPORTED_PROTOCOL_VERSIONS slice - Kotlin generator: emit new Version.generated.kt with both constants - Swift generator: emit new Version.generated.swift with both constants - Re-export SUPPORTED_PROTOCOL_VERSIONS from ahp-types lib.rs Release metadata - New scripts/generate-release-metadata.ts emits clients/<lang>/release-metadata.json for every client, reading the package version from each client's native manifest (Cargo.toml, gradle.properties, package.json, or the new clients/swift/VERSION). - New scripts/verify-release-metadata.ts cross-checks four independent sources (native manifest, generated Version file, registry, metadata JSON) and fails with a machine-friendly diff on drift. - Wired into `npm test` via a new `verify:release-metadata` script. Workflows - New publish-spec.yml on spec/v* tags: validates tag vs PROTOCOL_VERSION + CHANGELOG, regenerates schemas, publishes a GitHub Release with the schema files and a registry-snapshot.json of the introduced-in maps. - New publish-swift.yml on bare v[0-9]+.[0-9]+.[0-9]+ tags: validates tag vs clients/swift/VERSION + CHANGELOG + generator drift, builds + tests on macOS, publishes a GitHub Release. SwiftPM resolves the tag directly; no registry push. - publish-rust.yml: add Node/npm setup, generator drift check, metadata verification, CHANGELOG-entry check, and concurrency guard before the existing fmt/clippy/test/publish flow. - publish-kotlin.yml: add metadata verification, CHANGELOG-entry check, and concurrency guard alongside the existing kotlin generator check. - ci.yml: add a Rust generator drift check (mirrors the existing kotlin / swift / typescript checks), and surface verify:release-metadata as a named step in the check job. CHANGELOGs - Per-client CHANGELOG.md (Rust, Kotlin, Swift, TypeScript) plus the root spec CHANGELOG.md, all following Keep a Changelog with an explicit "Implements AHP <version>" line per release. Documentation - docs/specification/versioning.md: new "Release model" section codifying independent SemVer + tag conventions + the spec/client mapping. - New CONTRIBUTING.md at the repo root with the full release how-to for each artifact, the tag-namespace policy, and required CI environments. - Per-client READMEs (Rust, Kotlin, Swift, TypeScript): add a "Protocol version mapping" section documenting the exported constants and release-metadata.json file. - Per-client AGENTS.md (Kotlin, Swift): refresh release sections to reference CONTRIBUTING.md and the new CHANGELOG/metadata requirements. - Root README.md: link each client to its CHANGELOG, document the bare semver tag namespace for Swift, and link to the new release model docs. Tag conventions (final): - Spec: spec/vX.Y.Z -> publish-spec.yml - Rust: rust/vX.Y.Z -> publish-rust.yml - Kotlin: kotlin/vX.Y.Z -> publish-kotlin.yml - TypeScript: typescript/vX.Y.Z -> publish-typescript.yml (PR #156) - Swift: vX.Y.Z (bare) -> publish-swift.yml Bare semver tags at the repo root are reserved for the Swift release pipeline because SwiftPM only resolves bare semver tags at the manifest's repo root. Initial release-metadata.json captures current source-tree state truthfully. The Rust drift between packageVersion 0.1.0 and supported protocol 0.2.0 is intentional and documented -- it surfaces the existing reality that the in-tree code already supports protocol 0.2.0 even though the latest published crate is 0.1.0. The next Rust release should bump to 0.2.0. PR #156's publish-typescript.yml is intentionally not touched in this PR to avoid a merge conflict. CONTRIBUTING.md notes the same metadata and CHANGELOG enforcement should be added there in a small follow-up. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…d-release-strategy

PR #156's GitHub Actions tag-driven publish workflow was closed in favor of #157, which added an Azure DevOps pipeline at clients/typescript/pipeline.yml extending Microsoft's vscode-engineering npm-package template (manual `publishPackage` parameter; no git tag). Updates to integrate that flow: - Drop the planned `typescript/v*` tag namespace. CONTRIBUTING.md, README.md, and docs/specification/versioning.md tag-conventions tables now describe TypeScript as ADO-published. - New scripts/verify-changelog.ts cross-checks every client's native package version against a matching `## [X.Y.Z]` heading in its CHANGELOG.md. Normalizes Kotlin's `-SNAPSHOT` suffix to its base version (Maven convention: in-progress source lives at `X.Y.Z-SNAPSHOT`, CHANGELOG entry is `[X.Y.Z]`). - npm run verify:changelog wired into npm test and into ci.yml as a named step. This is the only "no release without a changelog entry" gate for TypeScript (no per-tag GHA workflow); other clients also get it for early PR-time catching, in addition to their tag-time grep check. - Add verify:release-metadata and verify:changelog as buildSteps and testSteps in clients/typescript/pipeline.yml so the ADO publish artifact can't ship from a state that would have failed the GHA check. The pipeline.yml is left otherwise unchanged from #157. - publish-rust.yml / publish-kotlin.yml: replace inline grep CHANGELOG checks with `npm run verify:changelog` (against the source-tree manifest), and keep a separate tag-derived grep check as defense-in-depth. - publish-swift.yml: add `npm run verify:changelog` alongside the existing inline tag-derived check. - clients/typescript/CHANGELOG.md: drop the dead reference to publish-typescript.yml, describe the ADO+CI enforcement model. Verification: - npm run typecheck / lint / verify:release-metadata / verify:changelog all green - Negative tests confirmed: bumping clients/typescript/package.json to 9.9.9 without a matching CHANGELOG entry fails verify:changelog with a clear error - All workflow YAMLs (incl. pipeline.yml) parse with yaml.safe_load - npm run docs:build clean (the 2 dead links are pre-existing, not from this PR) - Merged origin/main (incl. #149 Kotlin reducer port, #157 TS pipeline) without source-side conflicts; regenerate idempotent Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Symmetric tag conventions across all four clients: `<lang>/vX.Y.Z`. The TypeScript client uses a new `.github/workflows/publish-typescript.yml` that validates the tag (tag <-> package.json match, CHANGELOG entry, metadata consistency, full client build + tests) and then triggers the Azure DevOps pipeline at clients/typescript/pipeline.yml via the Pipelines REST API with `publishPackage: true` and `refName` pinned to the tag. The ADO pipeline performs the actual signed npm publish via the vscode-engineering template. Manual ADO trigger via the `publishPackage` parameter is preserved as a hotfix escape hatch -- both paths run the same `verify:release-metadata` and `verify:changelog` steps in the ADO pipeline's buildSteps/testSteps so a broken artifact can't ship regardless of trigger source. The trigger-ado job runs in a new `ado-typescript-publish` environment so a repo admin can require manual approval before any tag-driven run actually publishes to npm. Required ADO config (per CONTRIBUTING.md): - secret ADO_PIPELINE_TRIGGER_PAT (Build, Read & execute scope) - variables ADO_ORGANIZATION, ADO_PROJECT, ADO_PIPELINE_ID Doc/copy updates to reflect the restored tag convention: - CONTRIBUTING.md tag-conventions table + TypeScript release flow - docs/specification/versioning.md tag-conventions table - README.md TypeScript bullet - clients/typescript/CHANGELOG.md preamble Verification: - npm run typecheck / lint / verify:release-metadata / verify:changelog all green - All eight workflow YAMLs (including pipeline.yml) parse with yaml.safe_load - npm run docs:build clean (the 2 dead links remaining are pre-existing, not from this PR) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

CONTRIBUTING.md had grown to 218 lines with ~75% of its content covering release operations (tag conventions, per-client publish flows, CI guards, required infrastructure). Those are maintainer/operations concerns, not contributor concerns, and they were drowning out the short contributor-facing material (repo layout, dev loop, code style). Follow the standard convention (used by React, Vue, Rust, Tauri, and others) of a separate RELEASING.md at the repo root: - CONTRIBUTING.md (65 lines): repo layout, dev loop, brief release pointer, code-style and review. - RELEASING.md (164 lines, new): release model, tag conventions, per-client flows for spec/rust/kotlin/typescript/swift, what CI guards against, and the one-time required infrastructure table. All inbound references updated: - README.md → RELEASING.md - docs/specification/versioning.md → RELEASING.md (absolute GitHub URL preserved so the VitePress site can link out) - clients/kotlin/AGENTS.md, clients/swift/AGENTS.md → RELEASING.md - .github/workflows/publish-typescript.yml comment + error message - .github/workflows/publish-spec.yml comment - .github/workflows/publish-swift.yml comment - clients/typescript/pipeline.yml comment No behavioural change. verify:release-metadata and verify:changelog still green; all 8 workflow YAML files still parse. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Pull request overview

This PR introduces a unified, tag-driven release model for the AHP specification and all four client libraries, with generated protocol-version constants, per-client release metadata, changelog enforcement, and publish workflow updates.

Changes:

Adds SUPPORTED_PROTOCOL_VERSIONS, generated client constants, and release-metadata.json verification.
Adds spec/client changelogs plus release documentation and contributor guidance.
Adds/updates GitHub Actions and ADO release pipelines for spec, Swift, TypeScript, Rust, and Kotlin.

Show a summary per file

File	Description
`types/version/registry.ts`	Adds canonical supported protocol versions list.
`types/version/registry.test.ts`	Tests version registry invariants.
`scripts/read-protocol-versions.ts`	Adds shared AST reader for protocol version constants.
`scripts/generate.ts`	Wires release metadata generation into codegen.
`scripts/generate-release-metadata.ts`	Generates per-client release metadata.
`scripts/verify-release-metadata.ts`	Verifies metadata and generated constants.
`scripts/verify-changelog.ts`	Verifies changelog entries match package/spec versions.
`scripts/generate-rust.ts`	Generates Rust supported-version constant.
`scripts/generate-kotlin.ts`	Generates Kotlin version file.
`scripts/generate-swift.ts`	Generates Swift version file.
`package.json`	Adds metadata/changelog scripts and expands tests.
`README.md`	Documents release model and client release tracks.
`CONTRIBUTING.md`	Adds contributor workflow documentation.
`RELEASING.md`	Adds release operations guide.
`CHANGELOG.md`	Adds spec changelog.
`docs/specification/versioning.md`	Documents independent release model and tag conventions.
`clients/rust/release-metadata.json`	Adds Rust release metadata.
`clients/rust/CHANGELOG.md`	Adds Rust client changelog.
`clients/rust/README.md`	Documents Rust protocol-version mapping.
`clients/rust/crates/ahp-types/src/version.rs`	Adds Rust supported-version constant.
`clients/rust/crates/ahp-types/src/lib.rs`	Re-exports Rust version constants.
`clients/kotlin/release-metadata.json`	Adds Kotlin release metadata.
`clients/kotlin/CHANGELOG.md`	Adds Kotlin changelog.
`clients/kotlin/README.md`	Documents Kotlin protocol-version mapping.
`clients/kotlin/AGENTS.md`	Updates Kotlin release instructions.
`clients/kotlin/src/main/kotlin/com/microsoft/agenthostprotocol/generated/Version.generated.kt`	Adds generated Kotlin version constants.
`clients/swift/VERSION`	Adds Swift package version source.
`clients/swift/release-metadata.json`	Adds Swift release metadata.
`clients/swift/CHANGELOG.md`	Adds Swift changelog.
`clients/swift/AGENTS.md`	Documents Swift release flow.
`clients/swift/AgentHostProtocol/README.md`	Documents Swift protocol-version mapping.
`clients/swift/AgentHostProtocol/Sources/AgentHostProtocol/Generated/Version.generated.swift`	Adds generated Swift version constants.
`clients/typescript/release-metadata.json`	Adds TypeScript release metadata.
`clients/typescript/CHANGELOG.md`	Adds TypeScript changelog.
`clients/typescript/README.md`	Documents TypeScript protocol-version mapping.
`clients/typescript/pipeline.yml`	Adds release metadata and changelog checks to ADO pipeline.
`.github/workflows/ci.yml`	Adds named verification steps and Rust generation drift check.
`.github/workflows/publish-rust.yml`	Adds release verification and concurrency controls.
`.github/workflows/publish-kotlin.yml`	Adds release verification and concurrency controls.
`.github/workflows/publish-spec.yml`	Adds spec release workflow.
`.github/workflows/publish-swift.yml`	Adds Swift tag validation and release workflow.
`.github/workflows/publish-typescript.yml`	Adds TypeScript tag-driven GitHub Actions front door for ADO publish.

Copilot's findings

Files reviewed: 40/42 changed files
Comments generated: 1

The release-time gate (verify:changelog refusing to publish a tag whose matching ## [X.Y.Z] heading is missing) only catches CHANGELOG drift after the fact. Make the per-PR convention explicit so contributors and AI coding agents add the [Unreleased] bullet at the same time as the code change, instead of scrambling at release time. - New root AGENTS.md: cross-cutting rule for AI agents. Covers when to add an entry, when to skip, which CHANGELOG(s) to update for which source path, the Keep-a-Changelog subsection convention, and the reminder that ## [X.Y.Z] headings are reserved for release time. - CONTRIBUTING.md gains a parallel 'Updating CHANGELOGs' section so human contributors see the same rule. Cross-links to AGENTS.md. No tooling, no CI changes. Soft guidance only; the release-time verify:changelog gate remains the hard backstop. If contributor compliance turns out to be a problem in practice, we can add a non-blocking PR-time hint later (Tier 2 from the design discussion). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Caught by Copilot reviewer on PR #160: clients/typescript/README.md documented importing both PROTOCOL_VERSION and SUPPORTED_PROTOCOL_VERSIONS from '@microsoft/agent-host-protocol', but types/index.ts only re-exported PROTOCOL_VERSION. The README import would yield undefined for the second constant. Add SUPPORTED_PROTOCOL_VERSIONS to the canonical types/index.ts Version-registry re-export block. The TS client picks it up automatically via npm run generate:typescript (verified the regenerated clients/typescript/src/types/index.ts now exports it, and dist/types/ index.{js,d.ts} surface it after npm run build). Also add a regression test that imports from the public ../index.js entry and asserts both constants are present and match the registry module. This catches future omissions of either constant from the package entry surface. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 42/44 changed files
Comments generated: 3

Three documentation-drift findings from Copilot reviewer on PR #160, all in code introduced earlier in the same PR: - scripts/verify-changelog.ts: header comment claimed the TypeScript client had no per-tag GitHub Actions workflow and verify-changelog was the only enforcement. That was true mid-PR; the final PR adds publish-typescript.yml (GHA -> ADO bridge) plus verify steps in the ADO pipeline.yml itself. Replace the comment with the actual defense-in-depth picture: every per-tag workflow + the ADO pipeline + ci.yml all re-run this script. - .github/workflows/publish-spec.yml: comment said a re-pushed tag cancels the in-flight run, but cancel-in-progress is set to false precisely so we don't abort a half-finished GitHub Release upload. Rewrite the comment to explain the actual queueing behaviour and why it's deliberate. - scripts/read-protocol-versions.ts: JSDoc described a hard-coded fallback when the registry source file isn't in the project. The implementation throws instead. Rewrite the JSDoc to match: throws on missing source file, missing constants, or order-invariant violations, and callers building a partial ts-morph project must include types/version/registry.ts. No behaviour change. typecheck, lint, verify:release-metadata, and verify:changelog all still green; YAML still parses. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…d-release-strategy

PR #159 (merged into main today) added Unknown variants to every generated Kotlin discriminated-union sealed interface for forward compatibility, and upgraded StateActionUnknown to capture the full raw JSON envelope. That change landed before this PR's changelog convention existed, so it's missing a CHANGELOG entry. Add a bullet under the existing [0.2.0] section since #159 ships as part of the first Maven Central release of the Kotlin client. The bullet covers both the Unknown sealed-interface variants and the raw-JSON capture in StateActionUnknown. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

colbylwilliams and others added 5 commits May 27, 2026 18:02

Merge remote-tracking branch 'origin/main' into colbylwilliams/unifie…

edcca9c

…d-release-strategy

colbylwilliams requested a review from Copilot May 27, 2026 23:27

Copilot started reviewing on behalf of colbylwilliams May 27, 2026 23:27 View session

Copilot AI reviewed May 27, 2026

View reviewed changes

Comment thread clients/typescript/README.md

colbylwilliams and others added 2 commits May 27, 2026 18:34

colbylwilliams requested a review from Copilot May 27, 2026 23:40

Copilot started reviewing on behalf of colbylwilliams May 27, 2026 23:41 View session

Copilot AI reviewed May 27, 2026

View reviewed changes

Comment thread scripts/verify-changelog.ts Outdated

Comment thread .github/workflows/publish-spec.yml Outdated

Comment thread scripts/read-protocol-versions.ts

colbylwilliams requested a review from connor4312 May 28, 2026 00:18

colbylwilliams mentioned this pull request May 28, 2026

Proposal: add systemMessageTransform server→client RPC for SDK-style system-prompt section transforms #164

Open

colbylwilliams and others added 2 commits May 28, 2026 09:26

Merge remote-tracking branch 'origin/main' into colbylwilliams/unifie…

f81a01f

…d-release-strategy

connor4312 approved these changes May 28, 2026

View reviewed changes

Merge branch 'main' into colbylwilliams/unified-release-strategy

e315a50

colbylwilliams enabled auto-merge May 28, 2026 15:26

colbylwilliams merged commit 82d24f5 into main May 28, 2026
7 checks passed

colbylwilliams deleted the colbylwilliams/unified-release-strategy branch May 28, 2026 15:27

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add unified release strategy across spec and all four clients#160

Add unified release strategy across spec and all four clients#160
colbylwilliams merged 11 commits into
mainfrom
colbylwilliams/unified-release-strategy

colbylwilliams commented May 27, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

colbylwilliams commented May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Why

How

Tag conventions (final — symmetric across all clients)

Spec ↔ client mapping (three layers, all CI-enforced)

What CI / publish workflows now guard against

Initial release-metadata state (truthful)

Documentation structure

Verification

Required infrastructure

Not in this PR (deliberate follow-ups)

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Copilot's findings

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Copilot's findings

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

colbylwilliams commented May 27, 2026 •

edited

Loading