prreviewbuddy 0.19.0 → 0.25.0

package/CHANGELOG.md

@@ -1,5 +1,253 @@
 # Changelog
 
+## 0.25.0
+
+**PR Review Buddy no longer guesses which `main` you meant.** A repository usually holds two
+branches by that name, your own and `origin/main`, and they are the same commit until somebody
+commits without pushing or pushes from somewhere else. Whichever of the two is stale is still an
+ancestor of your branch, so the comparison succeeds and the review is quietly of the wrong thing:
+one report was a 107 file review of a 23 file change.
+
+When the two are different commits, the review now stops before it starts and says so, showing both
+commits, how far apart they are, and the two commands that pick one:
+
+```
+prreviewbuddy review --base refs/heads/main
+prreviewbuddy review --base origin/main
+```
+
+It stops for `--base main` and for a plain `prreviewbuddy review` alike, since the default base is
+worked out the same way. A base you have already been specific about is never questioned:
+`origin/main`, `refs/heads/main` and `refs/remotes/origin/main` each mean exactly what they say, and
+a commit, a tag or `HEAD~3` is passed to git as it always was.
+
+There is deliberately no rule picking the newer one, or the local one, or the one with fewer files.
+Any of those is still a guess, and a review of the wrong base is worse than being asked which base
+you meant.
+
+**A file the review read is no longer reported as one it invented.** The review runs inside a real
+checkout, so it reads beyond the diff: the caller of a changed function, the interface a changed
+class implements. Naming one of those used to produce an amber correction box saying the path could
+not be found and had been removed, and the finding that rested on it lost its location.
+
+Those files are now kept. They appear under **Referenced files** at the foot of the Files tab, with
+the sections that brought them in, and they open in the code viewer like anything else. They are
+deliberately not mixed into the changed-file groups and are not counted as files in this change,
+because the pull request did not touch them.
+
+A finding that rests on one now reads **Related file: path · not changed** rather than showing no
+location at all.
+
+The correction box now only reports a path that is in neither the change nor the reviewed version
+of the repository, and says the removal and the finding it cost in one sentence rather than two
+bullets that read as two problems.
+
+**A KISS review keeps the files it read, too.** The same fix as above, for the other review type.
+A recommendation about complexity that lives partly outside the diff, in the interface a new class
+implements or the caller that already did this, used to lose every location it had and be shown as
+having nowhere to look. Those locations are kept now, marked **not changed** on the row so they
+cannot be read as part of the pull request, and they open like any other.
+
+The KISS correction box now reports only a path that is in neither the change nor the reviewed
+version of the repository.
+
+**A review id no longer has to be typed in full.** `--review a8a9a058` finds the review that id
+starts, in `open`, in `--update` and in `--delete`. A shorthand that matches two reviews is refused
+with both ids and what each is of, rather than one of them being picked for you.
+
+**Analysis details moved to the top of the review.** It now sits opposite the pane's title, on
+**Review overview** and on **KISS review**, as a small **Analysis details** button that opens a
+panel under itself rather than a strip across the page. Nothing moves when you open it, and it
+shuts on Escape or a click elsewhere.
+
+It describes the whole analysis: which commit, which model, how much of the change it saw. Those
+are the things you want before deciding how much to trust the verdict, and they were at the bottom
+of the page, after it.
+
+A KISS review now names its audience the way you chose it. **Reviewing my code** and **Reviewing
+someone else's code**, in the words on the buttons that start a run, rather than "Written for the
+author of this change", which asked you to work out whether you were that author.
+
+## 0.24.0
+
+**A failed review now shows what the agent actually said.** When a run fails because the reply
+could not be used, the reply is kept with the run and folded away under **What the agent replied**
+on the failure panel, for both standard and KISS reviews.
+
+"Could not be parsed as JSON" is the same sentence whether the model ignored the schema or wrote a
+paragraph in front of a perfectly good answer, and until now the reply that would settle it was
+discarded. It is kept whole, deleted with the review like everything else, and never sent anywhere.
+
+## 0.23.1
+
+**A review is no longer lost to a sentence in front of it.** If the agent answered with a paragraph
+before its JSON and no code fence around it, the whole review was discarded as unparseable. This
+happens when your own Claude Code configuration asks for a particular style of reply, which the
+review has no way to switch off. The answer is now cut out of whatever surrounds it, for both
+standard and KISS reviews.
+
+## 0.23.0
+
+**Act on several reviews at once.** The reviews list has a **Select** button beside its count.
+Pressing it puts a checkbox on every row, and ticking rows brings up a bar with three things to do
+with them: **Mark reviewed**, **Mark in progress**, and **Delete**.
+
+A selection survives searching, filtering and turning the page, so you can gather rows from
+anywhere in the list. When some of what you have ticked is not on screen, the bar says so
+("5 selected · 2 not shown") before you act on it.
+
+Deleting takes the whole branch: a row is a branch and holds every review of it, so the question
+names both counts before anything goes. A branch that is being analysed right now is refused by
+name, and everything else in the selection is still deleted.
+
+The button inside a review now reads **Mark reviewed** rather than "Mark review complete", so the
+list and the review say the same thing about the same act.
+
+## 0.22.1
+
+**A way out of Settings.** The settings page had one link back to the reviews list, sitting in the
+top right among the version number and the feedback link, where it read as page furniture rather
+than as navigation. It is now a proper control at the top left of the page, above the first setting.
+
+When you reached Settings from the rail of a review, it takes you back to that review rather than to
+the list.
+
+## 0.22.0
+
+*The reviews page is a list you can work through, not a wall of tiles.*
+
+**One column.** Every review was a card in a two-up grid, which meant each one had about 420px to
+hold a title, a summary, a repository, a branch, an author, a risk, a size, what was outstanding and
+how long ago you were last there. The title ellipsed, the branch ellipsed, and the measurements
+stacked four rows deep, while the page kept empty space down both sides. The same content is now one
+row per branch: the summary has room to be read, everything measured sits on a single line, and the
+ages line up down the right edge so a screenful can be scanned rather than read.
+
+**Pages.** Fifteen reviews at a time, with ordinary numbered pagination. These are saved pieces of
+work rather than a feed, and a page you can return to is worth more here than a scroll position you
+cannot. Searching and filtering still cover everything stored, not just the page in front of you.
+
+**Where you were is in the address.** Search text, the filter and the page are all in the URL, so
+refreshing keeps them, Back out of a review returns to the page you opened it from, and a link to a
+search is a link to that search.
+
+**Pull request numbers.** A review of a pull request shows its number, and you can find it by typing
+either `#412` or `412`.
+
+## 0.21.0
+
+*Your workspace has an address now, and a place to change it.*
+
+**PR Review Buddy lives at http://localhost:7726.** It used to take whatever port the machine had
+spare, which was free by construction and useless by consequence: every link into a review died the
+next time the server started. So a review was something you had to go and find again rather than
+something you could keep a link to. The port is fixed, review addresses do not move, and a link to a
+review is worth bookmarking.
+
+7726 is P-R-B on a telephone keypad. It is not 4173, which is what `vite preview` takes, and
+choosing a port a developer's own tools already want would have made the collision the common case
+rather than the rare one.
+
+**Nothing moves quietly.** If something else is already on that port, PR Review Buddy says so and
+names both ways out. It does not try 7727. An address that shifts whenever it is inconvenienced is
+not an address, and finding an available port would have cost the one property this is for.
+
+**Settings, in the workspace.** A page at the level of the product rather than a tab inside a
+review, holding the workspace port, the coding agent used when a review does not name one, and
+whether anonymous usage counts are sent. All three already existed and were already settable from
+the command line; what was missing was anywhere to see them.
+
+They are three interfaces over one file, not three stores. `prreviewbuddy config set port 7726`, the
+field on the settings page, and editing `~/.prreviewbuddy/config.json` by hand all write the same
+key, and `prreviewbuddy config path` prints where that file is.
+
+**A change of port says when it takes effect.** A workspace that is already running keeps the port
+it started on, so the page tells you both: the one you are reading this on, and the one the next
+start will use. Claiming the change had already happened would be sending you to an address nothing
+is answering at.
+
+**A port it cannot use is an error, not a shrug.** A hand-edited `70000` used to be the kind of
+thing a program quietly ignores in favour of its default, which makes a configuration file look like
+it is not being read. It now names the file, the value and the range. A missing setting still means
+the default, because not saying anything is different from saying something impossible.
+
+**Saved links survive a restart.** The credential that opens your list of reviews used to be minted
+fresh on every start, so a browser that had been authorised yesterday was not authorised today. It
+is generated once and kept, which means the browser you already use keeps working across restarts.
+A review link was always the stronger case and still is: it carries its own credential, so it opens
+anywhere.
+
+That retires `~/.prreviewbuddy/reviews.html`, the page that existed only to be an address that did
+not move, rewritten on every start and stop because nothing else stayed still. There is a real one
+now.
+
+## 0.20.0
+
+*A second question you can ask of the same change: is all this machinery necessary?*
+
+**A review lens.** `prreviewbuddy review --lens kiss` runs a review that asks something the standard
+one only ever answers by accident: not whether the change is correct, but whether the complexity it
+introduces is justified, or whether the same requirements could be met with materially less
+machinery. It runs against everything the ordinary command reviews, a branch, another branch, or a
+pull request, and it needs no standard review to have been made first.
+
+It is a review of its own rather than a mode of the standard one. Its own prompt, its own run, its
+own result, its own staleness, and its own section in the left rail sitting beside `Review` rather
+than under it. Run both and you get two readings of one change in one workspace, at one link, on
+one card in your list of reviews.
+
+**Every run says who it is for, and is never guessed.** `--audience author` writes to the person
+who wrote the code, before they ask anyone to look: direct, specific, what to collapse or remove or
+defer, with enough of the trade-off that nothing load-bearing gets flattened. `--audience reviewer`
+writes for somebody reading another person's work, and adds the question a reviewer actually has,
+which is not whether an observation is true but whether it is worth spending a comment on. Where
+one is, it drafts the comment, and the draft can be copied as the Markdown it was written as.
+
+Nothing infers this from what you are reviewing, because there is nothing to infer it from: a
+reviewer checks out somebody else's branch and an author reviews their own pull request. In a
+terminal it asks. Anywhere else, leaving it out is a refusal that names both values rather than a
+default that writes comments about somebody else's work to its author.
+
+**A run that finds nothing is an answer.** "No material simplifications were identified" is a
+result the page states plainly, not an empty list. The rubric asks just as hard for complexity that
+is doing a job, and says so: transaction boundaries, permission checks, an adapter at a real
+external seam. A review that could only ever come back with something to change would be worth
+nothing when it came back with something to change.
+
+**Every recommendation points at the code it is about.** The files and lines are on the
+recommendation itself, and open the diff where you are reading, so there is no separate index to
+consult for a list that fits on one screen. A path the analysis named that is not in the change is
+withdrawn and disclosed rather than quietly rendered as a link to nothing.
+
+**Running it again keeps the answer it gave before.** Each run is kept whole, with the commit it was
+made from, the audience it was written for and the version of the prompt that produced it. New
+commits mark a run stale on its own terms, so bringing one up to date says nothing about the other,
+and dismissing that notice on one leaves the other's alone.
+
+## 0.19.1
+
+*An answer worth keeping can now be taken out whole.*
+
+**Every Buddy AI answer carries a copy control.** It sits under the answer, and it copies the
+Markdown the assistant actually wrote, not the text on the screen: the backticks, the fenced
+blocks and the lists survive, so an answer pasted into a pull request comment arrives formatted
+rather than flattened into one run of prose. The question above it does not get one, because the
+question is yours and you still have it.
+
+Per-block copy is unchanged and still there. The two answer different questions: that one lifts a
+snippet out of an answer, this one lifts the answer.
+
+If the clipboard is unavailable, the control says so and does nothing else. It deliberately does
+not fall back to selecting the answer on the page and asking you to press ⌘C, because what that
+would put on the clipboard is the rendered text, which is the one thing this control exists to
+avoid handing you.
+
+**The strips at the top of a review use the whole width of the page.** The notice that you are
+reading an older review, the list of the other reviews of that branch, and the sentence that says
+new commits have landed were each capped part-way across, so on a wide window they stopped
+two-thirds of the way along a band that visibly carried on. They now run to the edge of the
+section they sit in, which puts each row's `Open review` where the eye already expects it.
+
 ## 0.19.0
 
 *It asks before it sends anything, and the npm page stops reading like a manual.*