prreviewbuddy 0.25.8 → 0.27.2

package/CHANGELOG.md

@@ -1,5 +1,169 @@
 # Changelog
 
+## 0.27.2
+
+**Choose the model a review runs under.** `prreviewbuddy review --model <model>` asks the agent for
+a particular model instead of whichever one it normally uses. It works with any agent:
+`--agent codex --model gpt-5.3-codex`, or `--model opus` for Claude Code, with `--lens kiss` as well
+as with the standard review, and with several pull requests at once. The name is passed straight
+through, so anything your agent
+accepts works here, including one released after this version of PR Review Buddy.
+`prreviewbuddy --help` says where to find the names each agent takes, and a name the agent does not
+know is answered by the agent itself, in its own words, along with where to look for one that
+works.
+
+**A review keeps the model it was pinned to.** Every agent call a review makes asks for the model
+that review was pinned to: updating it, re-analysing it, running `--lens kiss` on it, asking the
+assistant a question about it, and drawing a diagram of it. Only starting a new analysis changes
+that, with `prreviewbuddy review --reanalyse --model <model>`. A review that never named a model
+stays that way, and will not silently acquire one.
+
+**Reviews now say which model made them, and only when they can.** Analysis details record what was
+asked for and, where the agent reports it, what actually answered. Those are shown as separate
+facts, because asking for a model is not proof of having got one: Codex never states which model it
+used, so a Codex review says so rather than repeating the request back as though it were confirmed.
+A review that pinned nothing still reads as it always did, naming just the agent. Those two facts
+describe the run that last worked on the review, so bringing a review up to date re-states them
+from the run that did the updating rather than carrying the earlier analysis's answers forward.
+What the review asked for is not a fact about one run and survives, which is what keeps a pinned
+review pinned.
+
+## 0.26.0
+
+**Review several pull requests with one command.** `prreviewbuddy review --pr <url> <url> ...`
+starts a review of each one. Every pull request gets an ordinary review of its own, with its own
+link, exactly as if you had named it on its own. Two run at a time by default; `--concurrency <n>`
+changes that. The link to all your reviews is printed as soon as the batch starts, so you can watch
+the reviews appear there while they are being made, and one line per pull request shows the step
+each has reached. At the end every pull request is listed with its own link. A pull request that
+fails does not stop the others, and the command exits with 1 if any of them failed.
+
+**Ctrl-C stops a review rather than failing it.** Pressing Ctrl-C during a batch stops the reviews
+that are running and starts no more. A stopped review now says **Review stopped** on its page, with
+a **Carry on** button, and **Analysis stopped** in the list of reviews. A review that genuinely went
+wrong now says **Analysis failed** there instead. Running the same command again carries on from
+where each review got to.
+
+**Two pull requests from the same branch name are no longer mixed up.** Pull requests from two forks
+that share a head branch name (such as `patch-1`) used to be handed each other's review. A review now
+records its pull request number and is only handed back for that number. One consequence: a pull
+request reviewed before this version, without its conversation attached, has no recorded number and
+gets a fresh review the next time you ask for it.
+
+## 0.25.15
+
+**Buddy AI answers one question at a time.** While Buddy AI was answering, a suggested question
+or **Explain in simple terms** still started a second one. The conversation briefly showed two
+questions, and then the page reloaded.
+
+Those controls are now greyed out while a question is being answered, and nothing new starts until
+it finishes or you press **Stop**. If you stop a question while something is already in the ask
+field, that draft is kept. Diagrams are unchanged and can still be drawn while a question is being
+answered.
+
+After you press **Stop**, you can ask again right away. Before, a question asked in the moment
+after Stop could be refused as a second one while the stopped question was still winding down, and
+the page reloaded. The same applies to stopping a diagram and drawing another.
+
+## 0.25.14
+
+**A question keeps being answered after you leave the review.** If you asked Buddy AI something
+and then went to the reviews list or opened another review, the answer was thrown away. Coming
+back showed an empty assistant, and your question had gone too. Drawing a diagram had the same
+problem.
+
+A question or a diagram now keeps going until it finishes, whichever page you are on. If you come
+back while it is still working, the review shows your question with its progress, and the answer
+appears when it is ready. **Stop** is the only thing that ends one early, and it works from any
+page that has the review open. Anything you did on the review in the meantime, such as marking it
+reviewed, is kept when the answer arrives.
+
+## 0.25.13
+
+**Two updates of the same review no longer run over each other.** Pressing **Update review** on the
+page while `prreviewbuddy review --update` was working on the same review started a second update
+alongside the first. Whichever finished last replaced the other's result without a word, after
+both had spent minutes of agent time.
+
+A second update is now refused while one is running, from wherever it was asked for. On the page,
+the review reloads onto the running update's steps. In the terminal, the command says the review
+is already being updated, gives the link where you can follow it, and exits without changing
+anything. An analysis, a KISS review or a question to the assistant does not block an update.
+
+## 0.25.12
+
+**An update shows what it is doing, in the terminal and on the review.** `prreviewbuddy review
+--update` printed nothing until the reassessment was over, usually minutes after you typed it, and
+the review page showed nothing either. Only the reviews list noticed, and it called the whole update
+"Preparing isolated checkout".
+
+The command now prints the link straight away and then draws the same step list a new review does:
+fetching the latest commits, re-reading the pull request conversation, preparing a checkout of the
+new commits, and reassessing the review, with the agent's own notes under the step that is running.
+Open the link while it works and those steps tick over above the review, which stays readable
+underneath until the update lands. The page refreshes onto the result when it finishes, and the
+reviews list names each step in the same words.
+
+An update that finds no new commits stops after the fetch and says so, without ticking steps it
+never ran. **Update review** on the page now shows the same live steps, where it used to show
+captions guessed from a timer.
+
+`--reanalyse` kept the terminal silent in the same way, for a whole analysis, and now draws its
+progress too.
+
+## 0.25.11
+
+**A review with nothing committed to read now says why, straight away.** Running
+`prreviewbuddy review` on `main` with a dozen edited files said "No changes found to review",
+which looked like a bug to anyone who could see the edits. It now says there are no *committed*
+changes, counts the uncommitted ones (new files included), and explains that PR Review Buddy
+reviews a fixed snapshot of your code, so work that is not committed yet is not included. Then
+it tells you what to do: commit on a branch, or just commit if you are already on one.
+
+The refusal also comes at once. It used to arrive after an isolated checkout had been prepared,
+reported as a paused review that would refuse again every time you tried to carry it on. Nothing
+is created now. A branch that has since been merged still opens the review it already has.
+
+## 0.25.10
+
+**The reviews list now shows what is happening, and keeps showing it.** A review being analysed
+right now, one whose analysis failed, and one that was never analysed all looked the same on the
+list: every card said "No standard review yet". Start a review, go back to the list, and you
+watched nothing happen for three minutes.
+
+A card now says which step an analysis has reached, in the same words the terminal prints, and says
+when one has stopped. It updates on its own, so a review that finishes while you are looking at the
+list fills in its summary, risk and counts without you touching anything. A review started in
+another terminal appears by itself too.
+
+Where a review already has results, they stay put while a new analysis runs over them: a KISS run
+no longer hides the issues you were reading.
+
+The list checks in about once a second while something is being made and once every fifteen when
+nothing is, and it waits rather than refreshing under you if you have rows ticked or are partway
+through typing a search.
+
+## 0.25.9
+
+**Marking a review reviewed shows up straight away on the reviews list.** It used to keep saying
+what it had said before, and catch up some minutes later on its own. Nothing was actually stale:
+the mark is written to disk before the button finishes repainting, and the list is rebuilt from
+those files on every request. The browser simply stopped asking. No page this server sends had
+ever carried a caching rule, so a browser was free to reuse the copy it already had, and pressing
+Back does not reload a page at all: it restores a frozen one from memory, JavaScript variables and
+all, without a single request.
+
+Both doors are shut now, and shut in one place rather than per page. Every response describing a
+review, HTML and JSON alike, says it must not be stored, and that is a property of the two helpers
+that write responses rather than something each route remembers. Every page now reloads itself
+when the browser restores it from history, because a restored page may be stale in any of its
+parts and not only the one that prompted this.
+
+Assets went the other way, which is the arrangement they should always have had. The bundles whose
+filenames carry a content hash, which are most of what a page downloads, may now be kept
+indefinitely: a new build asks for different names. The handful named plainly still check in every
+time, because those names survive an upgrade.
+
 ## 0.25.8
 
 **A review that fails says so, instead of reporting itself as ready.** An analysis that failed