gwm: alte Versionen herunterladen

# [1.11.0] - 2026-10-26

### Security

• **`cargo audit` failed on `dev` itself：the YAML parser under the crate is
unmaintained** ([#688](https://github.com/kbrdn1/gwm-cli/issues/688)).
`RUSTSEC-2024-0449` marks `unsafe-libyaml` unmaintained：the repository was
archived on 2024-03-25, and the crate is a machine translation of libyaml's C
into unsafe Rust, so bugs found in it are not fixed upstream. It reached this
crate through `serde_yaml_ng 0.10.0`, a direct dependency, and the advisory
entered the database after this repo's last green `cargo audit`, which is why
a check that had been green went red without a line of code changing.

Replaced by the pair the advisory itself names, both written in safe Rust:
`serde-saphyr` for the one typed parse in `src/`, and `saphyr` for the
dynamic tree the workflow guards read. `unsafe-libyaml` is gone from the
graph entirely rather than accepted through an `ignore` in `audit.toml`,
which `ci.yml` allows with a rationale (#340) and which #688 offered as the
other outcome.

The other candidates, and why each was not taken. `serde_norway` depends on
`unsafe-libyaml-norway`, the same translated C under a new name, which
silences the advisory by renaming the crate rather than by fixing the cause.
`serde_yml` carries `RUSTSEC-2025-0068`, unsound, with a segfault reachable
through its serializer, `patched = []` and the project archived, so that one
is a disqualification.

`noyalib`, the advisory's second suggestion, is **not** disqualified, and the
first draft of this entry said it was：it carries `RUSTSEC-2026-0333`, but
that advisory is `patched = [">= 0.0.53"]` and the current release is 0.0.58,
so a current `noyalib` is clean. What it is instead is a judgement：it was at
its 58th patch release before a 0.1, it took a denial-of-service advisory two
weeks before this was written, and `serde_yml`, from the same author, is the
archived unsound crate above. `serde-saphyr` is the advisory's first
suggestion and the one taken.

A fourth route was measured and dropped, and is worth recording because it
looked free：deserialising into `serde_json::Value` through `serde-saphyr`
would have been a near-mechanical rename of every read the swap touches,
the bulk of them in `release_workflow_tests.rs`. No count is given because
three attempts at one were each wrong and none of them credited a guard with
anything：a figure derived in prose drifts exactly like the floor it
describes, with nothing to catch it. It sorts mapping
keys, so `string_keys`, which promises document order, would have lost that
guarantee while its own test kept passing on a sample that happens to be
alphabetical. It also reads the YAML key `true:` as the string `"true"`,
which leaves `string_keys` unable to fire at all and turns the guard from
#673 vacuous. Both measured before the route was abandoned.

`tests/workflow_reader_tests.rs` pins what the new reader answers, including
the one semantic that was inherited rather than chosen：an absent key and a
key whose value is YAML null read alike, because the old reader could not
tell them apart and every `must carry no X:` assertion was written against
that. While both crates were declared the two readers were compared head to
head, against the accessor that actually ships：**187 comparisons over 17
documents, zero divergence** on `is_null()`, `as_str()`, `as_bool()`,
sequence length and mapping size, including five-level paths where the old
reader cascaded to null. That is the scope of the number and not a claim
about every behaviour. An earlier measurement covered an adapter that was
replaced before this shipped, which is why it was redone rather than quoted.

Two behaviours changed, below. Separately, a form that repeats a key, even
one `gwm` reads none of (a second `name:`), no longer parses, where
`serde_yaml_ng` let it through. Two paths parse a form and they fail it
differently. `gwm new` refuses it, in `serde-saphyr`'s wording, as it does
any form it cannot parse. `gwm create --issue` a

# [1.10.0] - 2026-09-01

### Added

• **`Ctrl+n` opens the create form on an issue that already exists**
([#625](https://github.com/kbrdn1/gwm-cli/issues/625)). `gwm create --issue`
(#617) derives the whole `<type> <issue> <desc>` triple from an issue on the
forge, and it was CLI-only. The TUI is where a worktree usually gets created,
so the one place already showing a worktree list and its linked issues was
the one place that still asked for the title to be retyped as a slug and the
branch type to be read off the labels by hand.

`Ctrl+n` (and `create-from-issue` in the command palette) opens the form on a
single field, the issue number. Enter looks the issue up rather than creating
anything; when the answer lands the form becomes the ordinary structured form
with the type, the number and the derived slug in it, and a second Enter
creates the worktree. Prefilling rather than creating is the point：the slug
is a guess about a title, and this is the surface that can show the guess
before committing to it. The derivation runs through the very functions the
CLI uses, so the two cannot produce different slugs for the same title.

Where the CLI has to refuse, the form asks. A non-interactive command has
nowhere to ask when the labels name no branch type or name two, which is what
`--type` is for; the form lands the cursor on the type selector with
everything else filled. A closed issue prefills with a warning rather than
refusing, since nothing is written until you confirm. A number that already
has a worktree closes the form and names it, matching the CLI's exit-0
behaviour, and reads the same link `gwm list` shows, so a worktree attached
by hand with `gwm link` counts too.

The lookup runs on the async task spine, never the render path, and a result
is applied only when the form asked for that exact number：the form is a
second consumer of a message that also fires for the sidebar prefetch and for
an explicit refresh. An issue already in the cache prefills straight away
rather than waiting for a message that would never arrive, since the fetch
coalesces on a cache hit.

`Ctrl+t` is inert in this mode and the hint row does not offer it. The
toggle swaps between the structured triple and the free-form name, which
are two ways of typing the same worktree; this one is a two-step mode, left
by answering it or by cancelling, so a third stop on the cycle would only
make the key unpredictable.

• **`gwm create --issue <N>` opens a worktree for an issue that already
exists** ([#617](https://github.com/kbrdn1/gwm-cli/issues/617)). `gwm new`
covered the issue that does not exist yet：it renders the issue from
`[issue_template.by_type.<type>]`, creates it, and opens its worktree.
Nothing covered the other half, the issue a teammate, a bot, or you last
week already filed, where the way through was to open the issue in a
browser, read its title, decide which branch type its labels implied, and
type a kebab-case slug that restated the title. Three of those four steps
were transcription, and the transcription drifted.

`--issue <N>` fetches the issue and derives the triple. `<desc>` comes from
the title with the type's `title_prefix` taken back off, normalised through
the same kebab-case path a hand-typed `<desc>` goes through and truncated
on a word boundary rather than mid-word. The prefix is resolved through the
same combinator `gwm new` uses when it writes the title, falling back to
the issue form's own `title:`, so the two halves of the flow produce the
same slug for the same title. `<type>` comes from the labels:
`[issue_template.by_type.*].labels` is the type-to-labels map `gwm new`
writes with, read backwards. A type declaring no labels is never a
candidate, since an empty list says nothing about which issues belong to
it.

Nothing is guessed. Labels matching no type, labels matching two, and a
repo that never configured the map are three distinct refusals, each
naming what it saw and pointing at `--type <TYPE>`. A closed issue is
refused t

# [1.9.0] - 2026-08-16

### Added

**The libraries compiled into the binary ship their notices**
([#577](https://github.com/kbrdn1/gwm-cli/issues/577)). `git2` builds with
`vendored-libgit2` and `libz-sys` with `static`, so every binary distributed
here statically contains libgit2 and zlib, and no package dependency carries
their terms. libgit2 is GPLv2 **with a linking exception**, and that
exception is what makes a permissively licensed binary possible at all: it
is conditional on the notice travelling with the distribution. zlib's terms
say its notice may not be removed. Neither was shipping, and neither had
anything to do with the project's own license, which is why this is separate
from #573 rather than part of it: both were unmet under MIT-only too.

Both notices now live under `third-party/` and reach the release archives,
the `.deb`, the `.rpm`, the AUR package and the published crate. They are
taken from the crate source cargo actually built, not from the libraries'
upstream repositories, because those diverge: `libgit2-sys` vendors a pinned
tree while libgit2 `main` moves.

`third-party/README.md` records which crate version each came from, and that
record is checked against `Cargo.lock`. A dependency bump moves the vendored
library without touching a file anyone reads, so without the check the notice
would quietly go on describing a version the binary no longer contains.

### Changed

**The doc captures show what the binary actually prints**
([#575](https://github.com/kbrdn1/gwm-cli/issues/575)). #567 rewrote 165
strings gwm prints and the captures predate it, so several showed text the
binary no longer says. They are images, so nothing in CI could notice. 21
moved, and they were behind on a second count the same regeneration fixes:
#568's tilde compression. `palette.png` shows it best. Its `PATH` column
read five near-identical `/Users/kbrdn1/gwm-demo/...` rows clipped mid-path,
and now starts at `~/gwm-demo/`, so what survives the clip is the part that
differs per row.

Five captures came back byte-identical, which is the correct answer rather
than a miss: `cli-list` and `cli-agents` are CLI output, where paths stay
absolute by design, and none of the five carries a rewritten string.

Two tapes `generate.sh` does not run are now named in the script and the
capture README, because neither absence was reported and a run therefore
ended with a tick over a set that still held them stale. `demo.tape` is the
documented one and was run separately here. `github-linking.tape` is the
other, and it is the one capture in the set that nobody but the maintainer
can reproduce: it needs a repo with an open PR, which the demo fixture has
not, so it points at a hardcoded checkout and photographs whatever it is
doing. Both were re-run by hand for this cut, `github-linking.png` from the
release branch itself, which is the only state in which that pane has
anything to show. Making it deterministic stays a design question rather
than a regeneration.

**The version chip is what set the order of this release.** It comes from
`CARGO_PKG_VERSION`, so all 24 TUI tapes bake the version into the image,
and a set regenerated before the bump would have advertised 1.8.0 for the
whole 1.9.0 line. The cut therefore bumps first and regenerates after, on
one branch, rather than following the usual order of merging the work and
adding a release commit on top. Every capture published here reads
`gwm 1.9.0`.

**gwm is now dual-licensed under MIT OR Apache-2.0**
([#573](https://github.com/kbrdn1/gwm-cli/issues/573)). Nothing is taken
away: MIT stays, in full, under its own file. What is added is the option
of Apache-2.0, whose §3 is an express patent grant from every contributor.
MIT has no patent clause at all, and that gap is the one thing a corporate
legal review reliably stops on. It is also the ecosystem's default (rustc,
cargo, clap, serde, ratatui and git2 all ship this exact pair), so packagers
recognise the layout without asking.

`LICENSE.md`