gwm: baixar versions anteriors

# [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`