prreviewbuddy 0.19.1 → 0.25.6

package/CHANGELOG.md

@@ -1,5 +1,292 @@
 # Changelog
 
+## 0.25.6
+
+**A review you open while it is still running now looks like one that is running.** Following the
+link the moment it is printed used to show the finished layout with most of it missing: a two line
+status strip, the KISS card, a screen of white below it, and an empty column down the right where
+the assistant would go. It read as a page that had failed to draw rather than as a review being
+made.
+
+There is now a **Review in progress** page, and it is what a running review opens on. It lists the
+steps of the run, ticks them off as they finish, and marks the one going with the note the agent is
+writing as it works:
+
+```
+✓ Prepared isolated checkout
+✓ Read what changed
+✓ Read pull request conversation
+● Analysing the change
+    Reading packages/alerts/src/ede/adapter.ts
+```
+
+Those are the same step names the terminal prints while you wait, so switching between the two
+shows one operation rather than two descriptions of it. The elapsed time counts in seconds while it
+is under a minute, because a number that does not move is no evidence that anything is happening.
+
+**The changed files open before the review is finished.** They are known minutes before anything
+has been concluded about them, so once the change has been read the page offers them, and the Files
+tab works exactly as it does on a finished review. You can start reading the code while the model
+is still thinking about it. The findings, questions and assistant stay behind until they exist,
+since an empty Issues tab cannot be told apart from a review that found nothing.
+
+Going into Files while it runs keeps you there. The page refreshes itself only when it has
+something new to show you, not on every step.
+
+**A run that stopped says which step it stopped on.** The message and **Retry** used to sit in the
+strip, which had room to say a review had paused but not where. The failure now sits under the same
+checklist, with the step that broke marked and the ones after it left unclaimed, so what failed is
+a thing you read rather than a thing you infer.
+
+**KISS is no longer where you land by accident.** A change whose standard review had not finished
+opened on the KISS run form, because it was the only page with anything on it. It is a peer review
+type, not the fallback for whichever review is busy, and it is still one click away in the sidebar.
+
+**Locations under a KISS recommendation fit the page.** A repository path is one long unbreakable
+word, and the buttons holding them grew wider than the document, cutting off the end of the path,
+which is the half naming the file. They now wrap the way the standard review's file rows always
+have: a quiet directory line above a filename that wraps.
+
+The **Main** badge on those rows is gone. It was our word for a flag in the data, worn as a label,
+so it read as a fact about the file and left you to work out what it was for. The rows now sit
+under **Start here** and **Also relevant**, which say what to do instead of what we call it. Both
+headings are dropped where a recommendation cites a single file.
+
+**"Show more of this file" shows more of the file.** Under a finding at line 804 it used to jump to
+the top of the file and then do nothing at all when pressed again, because it meant "the first 600
+lines" rather than "more". Each press now widens the window around the line you arrived at, and the
+button is only there while there is more to show.
+
+**Your own saved prompts no longer look unavailable.** In the selection menu they appeared greyed
+out, under a dividing rule, from the first one you saved. A rule written when "Ask a question" was
+the last item in the menu was landing on the last saved prompt instead. They now sit under a **Your
+prompts** heading, in the same words the assistant panel uses for the same set, and read as the
+most available thing in the menu rather than the least.
+
+## 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.*