v0.3.0

Changed

• OpenTUI 0.5.12.

Added

• Ctrl-s lists every row of the diff that matches what you type, grouped by file with a
  count per file, and Enter goes there. / answers "take me to the next one"; this
  answers "where does this appear at all", which used to mean pressing n and rebuilding
  the picture one match at a time.

• riff --demo — a review of a repository riff generates in TMPDIR: five files with a
  modification, an addition and a deletion over them, with no network call and nothing written
  into the repository it was launched from.

• riff reads files — riff ., riff src/ and riff src/app.ts open a path instead of
  a diff, drawn as a diff with no changes so folds, flash, /, tables, mermaid and the
  syntax highlighting all come with it. A directory opens folded. A path that exists wins
  over a revision of the same name; -r <rev> says you meant the revision. Commenting is
  refused for now — notes on a file are the next spec.

• Comments from nvim — riff comments add --file F --line N writes a comment from
  outside riff, body on stdin, and nvim/ ships a plugin that uses it: <leader>rc opens a
  markdown buffer on the current line or selection, and every commented line shows the start
  of what was said beside it. nvim keeps the navigation; riff keeps the comment.

• Notes never leave the machine — a comment written where no diff is showing is stored
  as one, and every publish path refuses it rather than losing it to a 422 at the API.

• c works on any line riff is showing — a file opened with riff ., context expanded
  outside a hunk, anywhere the cursor sits on code. The composer says Note … local only, never published before you type. A note appears only where riff has a row for it, so a
  pull request is not buried under remarks about the rest of the repository.

• riff comments is a queue an agent can be pointed at — --path narrows it to a file
  or a directory, every thread in the JSON says whether it is a note or a review comment,
  and every one says where its line is now: here, moved to a line it names, or lost.
  A note pinned to a worktree that keeps being edited no longer points at the wrong code
  without saying so.

• The nvim plugin shows what is there — a sign in the gutter on every commented line,
  :RiffShow to read the comments on a line, and :RiffToggle between the comment's
  opening text and a single dot for when the marks are in the way. Writing a comment on a
  line that already has one shows what was said above the composer.

• riff comments edit <id> — rewrite a comment's body from outside riff. The anchor is
  not touched: changing what a comment says is not changing which line it is about.

• One key in nvim — <leader>rc comments on a line, or opens the comment already on it
  on what it says. Ctrl-s saves from either mode, Esc abandons, and :w, :x and ZZ
  work as they do anywhere else. The separate viewer, editor and open-in-riff commands are
  gone: three doors onto one room.

• The review, in nvim — <leader>rp fetches the pull request for your bookmark or
  branch and draws its comments on the file, with who said what, in their own gutter sign;
  <leader>rP puts them away without touching your notes. Nothing polls and nothing
  fetches behind your back. A comment whose line has moved is drawn where the line is now,
  read out of the hunk GitHub sent; one whose code has since changed is not drawn, and
  you are told how many there were.

• riff comments fetch pulls a pull request's comments into .riff/ without opening
  riff, and riff comments --synced lists the review's own comments beside your notes.

• Every comment in the repository, from nvim — <leader>rl lists the open ones in
  snacks' picker (quickfix without it) and jumps to the line each is on now. <leader>rx
  marks one done. A gutter sign only ever told you about the file you already had open.

• One list, both kinds — riff comments --json --all is your notes and the comments
  on the pull request for your branch, in one report, each thread tagged and carrying the
  commands for the store it came from. <leader>rl uses it, so "where is there something
  to deal with" is one question again instead of two keys.

• riff on a branch with a pull request shows that review — riff already named the PR
  in the header and then showed none of it. Its comments now appear on the lines they are
  anchored to, for the lines this diff actually has. Nothing is fetched: riff pr and
  riff comments fetch are what put a review on disk.

• Delete a comment from nvim — <leader>rd, and Ctrl-x / Ctrl-d in the composer
  retire the comment it has open. Only ever your own: the review's comments are GitHub's.

• The composer shows what is already on the line, the review included — a line carrying
  someone's review comment opened a blank composer, as if riff had lost it.

• Toggling the comment display reaches the review too — :RiffToggle redrew only your
  own notes, so a pull request's comments stayed in whichever mode they were drawn in while
  the message said otherwise.

• i and a open the pull request the header names — in a local review on a branch
  that has one, the overview and the feed were keys that silently did nothing. They load it
  now, in place, and land where you asked — building the PR info panel a local review never
  had, without which the view switched onto nothing and looked stuck on the diff.

Fixed

• Ctrl-o and Ctrl-i know about every jump — the picker, the tree, flash, thread
  motion, links and the feed are all in the history, because one place records where you
  came from instead of twenty navigations each remembering to. Stepping and scrolling
  inside a file still are not jumps, and a jump now lands in the column it left.
• Going back no longer flickers — a jump painted the destination at the scroll position
  of where it came from and then moved it. One paint now, and the jump keeps your marks and
  your last search instead of rebuilding the cursor from scratch.
• The tree says which file you are reading — the file under the diff cursor is named in
  the accent colour, not only shaded, so ]f and [f are legible at a glance from the
  other panel.
• Sequence diagrams name their columns at both ends — participants are drawn at the
  foot as well as the head, the way mermaid draws them, so the bottom of a long exchange
  still says who is who.