feat(api): establish the stable 1.0.0 release

Cargo.toml

@@ -3,7 +3,7 @@ members = ["crates/workshop-rs", "crates/workshop-rs-cli"]
 resolver = "3"
 
 [workspace.package]
-version = "0.11.0"
+version = "1.0.0"
 edition = "2024"
 rust-version = "1.85.0"
 license = "MIT"

crates/workshop-rs-cli/Cargo.toml

@@ -11,7 +11,7 @@ repository.workspace = true
 workspace = true
 
 [dependencies]
-workshop-rs = { path = "../workshop-rs", version = "0.11.0" }
+workshop-rs = { path = "../workshop-rs", version = "1.0.0" }
 serde = { workspace = true, features = ["derive"] }
 serde_json.workspace = true
 sha2.workspace = true

docs/release.md

@@ -63,6 +63,24 @@ vX.Y.Z
 
 There is no normal draft/published GitHub Release state machine. Build outputs remain GitHub Actions artifacts until all required jobs succeed; the GitHub Release is created only at the final publication boundary.
 
+## First stable API release
+
+The public API freeze and required downstream verification recorded in #252
+are complete. The first stable release therefore sets the shared `workshop-rs`
+version group to `1.0.0` in a dedicated release PR. A breaking change on a
+`0.x` crate normally advances the pre-1.0 minor line (for example, `0.11.0` to
+`0.12.0`), following [release-plz's major semver bump
+rule](https://release-plz.ieni.dev/docs/semver-check), so the stable API
+transition needs this one-time exact version target.
+
+Merging the version PR starts the existing main-branch release-plz workflow,
+which publishes both crates and pushes `v1.0.0`. The tag then starts the binary
+workflow described above. This PR selects the release version; crates.io
+publication, tag creation, and GitHub Release creation remain owned by the
+existing automation. After `1.0.0`, release-plz continues to manage ordinary
+version updates and the compatibility check uses the latest published
+release as its baseline.
+
 ## Binary targets
 
 The release matrix is intentionally explicit because it is small and stable: