oneharness 0.11.3

# Automated releases from conventional commits, driven by release-plz. Mirrors
# the proven setup in nickderobertis/allowlister.
#
# Flow:
#   1. Commits land on `main` (feat -> minor, fix/perf -> patch, `!`/BREAKING ->
#      major; docs/test/chore/ci do not release).
#   2. The `release-pr` job opens/updates a PR that bumps the version in
#      Cargo.toml + Cargo.lock and writes the CHANGELOG section.
#   3. Merging that PR makes the `release` job tag `vX.Y.Z` and cut a GitHub
#      Release with the changelog notes. That Release (created with a PAT, not
#      the default GITHUB_TOKEN) triggers `release.yml`, which builds, archives,
#      checksums, and attaches the cross-platform binaries.

[workspace]
# Both crates are published to crates.io on release. release-plz runs
# `cargo publish` in dependency order — `oneharness-core` first, then the
# `oneharness` binary that depends on it — as part of the same `release` run
# that tags and cuts the GitHub Release. crates.io publishing is additive: the
# binary is still distributed via GitHub Releases and `cargo install --git`.
# The publish needs a CARGO_REGISTRY_TOKEN secret (see release-plz.yml).
publish = false

# Only release on release-worthy conventional commits. Without this, release-plz
# treats every commit as eligible, so generated `chore(...): release v...`
# commits can open the next release PR and create an auto-merge loop.
release_commits = "(?s)^(feat|fix|perf)(\\([^)]+\\))?!?:|BREAKING CHANGE:"

# Run the `release` (publish/tag) step on every push to main, publishing only
# packages whose manifest version isn't yet on crates.io. Releases are still
# effectively gated by the release PR — the version only *changes* when that PR
# merges, so a normal push finds nothing unreleased and no-ops — but this also
# makes the release step RECOVERABLE: if a publish fails partway (a bad config, a
# rate limit, a registry hiccup), the fix can land as an ordinary commit and the
# next push completes the pending release. With `release_always = false` the
# publish only fires on the exact release-PR merge commit, so a failure there
# wedges the release permanently (the versions are already bumped, so no new
# release PR is opened to re-fire it) — which is exactly what happened on the
# first crates.io release. `release_commits` below still stops `chore: release`
# commits from opening a fresh release PR, so there is no auto-merge loop.
release_always = true

# API breaking-change detection. `oneharness-core` is a published library with
# real consumers, so a breaking change that ships as a patch — because a commit
# subject said `fix` — breaks them silently; that has already happened once in
# this workspace family. cargo-semver-checks reads the actual API surface, so the
# bump follows the code rather than the subject line.
#
# release-plz shells out to a `cargo-semver-checks` BINARY and, when it is
# missing, only warns and skips — so this setting is inert unless the tool is
# installed. release-plz.yml installs it and verifies it runs before release-plz
# starts, which is what keeps this from being a check that quietly does nothing.
#
# It decides the VERSION, at release time. What the subject line said is a
# separate question, and a tier earlier: `just semver-check` refuses a break the
# release-driving subject never declared, so the changelog a consumer reads is
# not silent about one release-plz quietly bumped the major for.
semver_check = true

# Tag and name each release `vX.Y.Z`, matching v0.1.0..v0.2.0. Only the
# `oneharness` binary is released (see the per-package block below); the
# `oneharness-core` library is internal — shipped inside the binary and consumed
# as a git dependency by sibling tools — so one `vX.Y.Z` tag still means one thing.
git_tag_name = "v{{ version }}"
git_release_name = "v{{ version }}"

# The reusable engine crate is now published to crates.io so the binary that
# depends on it can be published too (a path dependency must resolve to a
# registry version at publish time — see the `version` on the dep in
# `Cargo.toml`, which release-plz keeps in step with this crate's version). It
# keeps its own independent version line — bumped by release-plz from
# conventional commits touching `crates/oneharness-core/` — and its own CHANGELOG.
#
# It IS git-tagged, but in its own `oneharness-core-v{{ version }}` namespace,
# NOT the binary's `v{{ version }}`. This is load-bearing: release-plz uses the
# per-package tag to decide whether a version is already released, so a shared
# `v{{ version }}` scheme collides — core's next version (0.3.0) matched the
# binary's historical `v0.3.0` tag, so release-plz thought core was already
# published, skipped its `cargo publish`, and then the binary publish failed
# because core was never actually on crates.io. A distinct namespace keeps that
# check accurate. `git_release_enable = false` still means NO GitHub Release for
# the engine, so the `vX.Y.Z` Release (and the `release.yml` it fires) remains
# the binary's alone — one `vX.Y.Z` tag still means one thing.
[[package]]
name = "oneharness-core"
git_tag_name = "oneharness-core-v{{ version }}"
git_release_enable = false

# Keep-a-Changelog-style grouping. The version bump is computed from the
# conventional-commit *type* (pre-1.0 follows Cargo's 0.x rules: feat/fix/perf ->
# patch, `!`/BREAKING -> minor), independent of these display groups — so
# skipping a type from the changelog never changes the bump.
[changelog]
commit_parsers = [
  { message = "^feat", group = "Added" },
  { message = "^fix", group = "Fixed" },
  { message = "^perf", group = "Performance" },
  { message = "^refactor", group = "Changed" },
  { message = "^docs", group = "Documentation" },
  { message = "^test", skip = true },
  { message = "^ci", skip = true },
  { message = "^chore", skip = true },
  { message = "^build", skip = true },
  { message = "^style", skip = true },
  { message = ".*", skip = true },
]