Establish automated binary releases and the Wright v0.1 distribution contract

[Teakowa]

Goal

Make Wright consumable as a versioned tool by real external repositories instead of requiring consumers to build from main, pin an arbitrary git SHA, or invoke the workspace directly.

This is a horizontal distribution/enablement workstream. It should proceed alongside M12 without expanding the M12 lint scope.

Context

Wright currently has CI but no automated GitHub release pipeline, published tags, or released binary artifacts. wright-cli and wright-lsp already expose executable products and currently carry 0.1.0 package versions, so real consumers such as wrightkit/agent-lab now need an explicit versioned distribution contract.

The first release should optimize for deterministic consumption by agents, CI, and local developer tooling rather than immediately solving every package-manager ecosystem.

Scope

Product version contract

• Establish one authoritative Wright implementation/product version for release artifacts.
• Keep this distinct from the independent compatibility/content/runtime identities tracked conceptually by [v0.2 workshop-rs] Define Workshop catalog, locale, extension, and version boundaries #96.
• Ensure the wright CLI reports its implementation version (wright --version).
• Ensure wright-lsp exposes the same implementation version through an appropriate executable/protocol surface.
• Avoid accidental version drift between release binaries that are shipped together.

Automated release pipeline

• Add a tag-driven release workflow for v* releases.
• Require normal validation gates before publication: formatting, build/check, tests, and clippy/current CI-equivalent quality gates.
• Build release binaries for the initial supported desktop/CI matrix:
  • Linux x86_64
  • macOS arm64
  • macOS x86_64
  • Windows x86_64
• Publish wright and wright-lsp in platform-appropriate archives.
• Publish checksums for downloadable artifacts.
• Create/update the GitHub Release from the version tag.
• Prefer established Rust release tooling such as dist if it cleanly fits the workspace; do not build a large custom release framework without concrete need.

Reproducible consumer contract

• Define stable artifact naming so scripts can resolve a requested version/platform deterministically.
• Document the supported installation path from GitHub Releases.
• Add a release smoke test that downloads/uses the produced artifact or otherwise verifies the packaged binaries execute and report the expected version.
• Ensure a failed build/validation for any required target does not silently create a successful partial release.

Initial release boundary

The first automated release does not need to solve all distribution channels.

Explicitly defer unless required by implementation evidence:

• crates.io publication of workspace crates;
• Homebrew/Scoop/Winget packages;
• npm wrappers;
• auto-update behavior;
• signed/notarized installers;
• independent crate-by-crate versioning/release automation.

Those can be added after the binary release contract is proven by real consumers.

Relationship to architecture

• [M12] Tooling-first lint and Workshop stability analysis platform #89 / M12 remains the active product-value milestone; this issue must not absorb lint/analyzer work.
• [v0.2 workshop-rs] Define Workshop catalog, locale, extension, and version boundaries #96 tracks independent identities such as Wright implementation, language/reference compatibility, Workshop content, and runtime target versions. This issue only establishes the concrete Wright implementation release identity.
• wrightkit/agent-lab should consume a pinned released Wright version only after this contract exists; it should not institutionalize main/git-SHA consumption as the normal integration path.

Acceptance criteria

• A version tag can drive the complete release workflow without manual artifact assembly.
• GitHub Release contains working wright and wright-lsp artifacts for every declared initial target plus checksums.
• The shipped executables report the tagged Wright implementation version consistently.
• Release validation prevents publication when required CI/release checks fail.
• Artifact names and documented installation instructions are stable enough for another repository to pin and fetch an exact Wright version non-interactively.
• A release smoke test verifies packaged artifacts rather than only workspace binaries.
• The first real consumer (wrightkit/agent-lab) can integrate without checking out Wright source or tracking main.

Follow-up

After this issue lands, integrate Wright into wrightkit/agent-lab as a versioned deterministic tooling provider and use its evaluation corpus to validate the public release contract under real agent workflows.