prreviewbuddy 0.15.2 → 0.18.0

package/CHANGELOG.md

@@ -1,5 +1,100 @@
 # Changelog
 
+## 0.18.0
+
+*A pull request is compared against its own base, or not at all.*
+
+**A review of a two file pull request could report 433 files.** If your clone's `main` was behind
+the remote, and it is behind the remote from the first day nobody pulls, a pull request onto `main`
+was compared against your branch rather than the one the request was cut from. Nothing failed. The
+review named hundreds of files the author never touched, attributed other teams' already merged work
+to them, and recommended changes over it, and the only symptom anywhere was the numbers.
+
+The cause was one rule in two halves that disagreed. With no base named, PR Review Buddy preferred
+the remote copy. With a base named, it took the name as written, and a pull request always names its
+base. A short name now means the remote copy of it everywhere:
+
+```
+--base main              ->  origin/main
+--base refs/heads/main   ->  your own main, deliberately
+```
+
+Naming a ref in full still reaches exactly what you named, which is how you ask for your own branch
+on purpose.
+
+**A pull request's base is now the commit the forge names.** PR Review Buddy asks GitHub which
+commit the request is cut from and compares against that. Failing that it uses the remote-tracking
+copy of the base branch, and failing both it stops and asks you to run `git fetch` rather than
+comparing against a local branch that merely shares the name.
+
+**It also checks its own work.** The diff it builds is checked against the number of files the forge
+says the request touches, and a review whose counts disagree in either direction is refused rather
+than written. Too many files means something was dragged in; too few means something the request
+touches was never read, and nothing in a finished review would have said so.
+
+Reviews already on disk repair themselves. One made by an earlier version recorded the ambiguous
+name, and updating it reproduced the problem rather than curing it; updating or re-analysing one now
+resolves it the same way a new review would.
+
+## 0.17.0
+
+*Reviews you can get rid of, and an ID you can read.*
+
+```
+prreviewbuddy review --review <review> --delete
+```
+
+**Reviews can be deleted, from the terminal and from the list in your browser.** They were durable
+and permanent, which is only half a lifecycle: a bad run, an experiment, or the second review
+`--fresh` was asked for sat there for thirty days with nothing to do about it but uninstall the
+product. Deleting removes the review and the isolated checkouts it was made in, and touches neither
+your branch nor its commits.
+
+In the browser, the `...` menu on a review offers **Copy review ID** and **Delete review**, and the
+menu on a card deletes every review of that branch at once, naming the count and the ref it follows
+so the two cards for `feat/foo` and `origin/feat/foo` cannot be confused for one another. The
+confirmation happens in the menu, where you are already looking.
+
+**`prreviewbuddy open` now prints a review ID beside each review.** It was only ever findable as a
+fragment of a URL, which was tolerable while nothing required it: `--review` is a tiebreaker and
+`open` works without one. Deleting requires it, because after `--fresh` a branch names several
+reviews and picking the newest is a coin toss, so the ID had to stop being an implementation detail.
+
+Deleting refuses while a review is still being analysed, and there is no flag past that. Stopping an
+analysis and deleting its record are separate decisions, and only one of them is being asked for.
+`--yes` skips the confirmation and means nothing else.
+
+## 0.16.0
+
+*Installing this told you nothing, and removing it left something behind.*
+
+```
+prreviewbuddy uninstall                 remove everything this put on your machine
+prreviewbuddy uninstall --keep-reviews  keep your reviews and settings, clear the rest
+```
+
+**`prreviewbuddy uninstall` cleans up after itself, including the part you could not see.** Every
+review is made in an isolated checkout, and creating one writes an entry into the repository being
+reviewed. Deleting `~/.prreviewbuddy` by hand leaves those entries pointing at nothing, in
+repositories you had no reason to suspect, and finding them means running `git worktree list`
+somewhere you were not looking. This removes the checkouts through the same guard the product
+already used, clears the entries in the repositories that have any, and then removes the store.
+
+It stops the workspace server first, asks before it deletes anything, and refuses outright while a
+review is still being made, naming the branch rather than a process. `--yes` skips the
+confirmation; `--force` is a separate answer to a separate question, and means stopping work that
+is in progress. `--keep-reviews` clears the runtime state and leaves your reviews and settings
+where they are.
+
+It does not remove its own npm package. A running command deleting the install it is executing from
+depends on the package manager that put it there, so the last thing it prints is the line to type.
+
+**The first command you run now says where to look.** Two lines above whatever you asked for,
+naming `prreviewbuddy agents` and `prreviewbuddy --help`, and then never again on that machine.
+Installing left you to guess the first command, and the obvious fix of printing it after the
+install is not one: npm no longer runs install scripts unless you allow-list them, so the line
+would have reached almost nobody while adding a warning about install scripts to every install.
+
 ## 0.15.2
 
 - A review that could not be completed now says so on every tab. The Guide and

package/LICENSE

@@ -0,0 +1,11 @@
+Copyright © 2026 KloLabs. All rights reserved.
+
+PR Review Buddy is proprietary software. It is licensed for use, not sold.
+
+No licence to copy, modify, distribute, sublicense or create derivative works is
+granted by the availability of this source or of any published package. Use of
+the software is governed solely by the Terms of Service at
+https://prreviewbuddy.com/terms.
+
+Third-party components distributed with the software remain under their own
+licences, which are unaffected by this notice.

package/README.md

@@ -29,12 +29,16 @@ prreviewbuddy review --reanalyse        analyse the same commit again, for a fre
 prreviewbuddy review --fresh            review the target again, keeping the existing review
 prreviewbuddy review --review <review> --update
                                         act on one review by its review ID
+prreviewbuddy review --review <review> --delete
+                                        delete one review and the checkouts it was made in
 
 prreviewbuddy open                      list your reviews and open the index
 prreviewbuddy open <review>             open one review
 
 prreviewbuddy agents                    which coding agents you have
 prreviewbuddy config set agent <agent>  remember which to use when you do not name one
+
+prreviewbuddy uninstall                 remove everything this put on your machine
 ```
 
 The two halves go together: `prreviewbuddy review --branch feat/foo --update` brings the review of
@@ -44,6 +48,28 @@ Run it from inside the repository you want reviewed. `--branch` takes a branch,
 `--branch origin/feat/foo` reviews what is on the remote rather than what is in your clone. A review
 follows the ref it was made from and keeps following it.
 
+## Which base a review is compared against
+
+A base named by its short name resolves to the remote copy of it, and a base named in full resolves
+to exactly what was named.
+
+```
+--base main              ->  origin/main
+--base refs/heads/main   ->  your own main, deliberately
+```
+
+A local branch is behind the remote from the first day nobody pulls, and it is usually an ancestor
+of the branch under review, so git accepts it as a merge base without complaint and every upstream
+commit you have not pulled lands in the review. There is no error, only a much larger diff and
+findings about code the author never touched. Naming the ref in full is how you say you meant your
+own branch.
+
+A pull request is stricter, because its base is not something you typed. PR Review Buddy asks the
+forge which commit the request is cut from and uses that; failing that, the remote-tracking copy of
+the base branch; and failing both it refuses and asks you to run `git fetch`. It also checks the
+diff it built against the number of files the forge says the request touches, and refuses if the two
+disagree.
+
 ## What you need
 
 - **Node 20 or newer**, and **git**.
@@ -78,6 +104,44 @@ the terminal that started it, taking a new port each time it starts, so bookmark
 The isolated checkout a review was made in is kept for six hours after it finishes, because that is
 what the assistant reads when you ask it questions, and is then removed.
 
+## Deleting a review
+
+```
+prreviewbuddy review --review <review> --delete
+```
+
+Reviews are kept for thirty days, and `--fresh` exists so you can review the same branch twice on
+purpose, so a bad run or an experiment is worth being able to clear out. Deleting removes the
+review and the isolated checkouts it was made in, and touches neither your branch nor its commits.
+It asks first; `--yes` skips that. It refuses while the review is still being analysed, and there is
+no flag past that: stopping an analysis and deleting its record are different decisions.
+
+The ID is the one `prreviewbuddy open` prints beside each review. It is required, because a branch
+can name several reviews once you have used `--fresh`.
+
+You can also delete from the list in your browser: the `...` menu on a review offers **Copy review
+ID** and **Delete review**, and the menu on a card deletes every review of that branch at once.
+
+## Uninstall
+
+```
+prreviewbuddy uninstall
+npm rm -g prreviewbuddy
+```
+
+The first line is the one worth knowing about. A review is made in an isolated checkout, and
+creating one writes an entry into the repository being reviewed, so deleting `~/.prreviewbuddy`
+yourself leaves entries pointing at nothing in repositories you had no reason to suspect.
+`uninstall` removes the checkouts, clears those entries in the repositories that have any, and then
+removes the store. It asks first, and it refuses while a review is still being made.
+
+`prreviewbuddy uninstall --keep-reviews` clears the runtime state and leaves your reviews and
+settings in `~/.prreviewbuddy`. `--yes` skips the confirmation, and `--force` stops a review that is
+still being made rather than refusing over it.
+
+Removing the package itself is the second line, and it is yours to run: a command that deleted the
+install it was running from would depend on whichever package manager put it there.
+
 ## Also available
 
 As a [Claude Code](https://claude.com/claude-code) plugin, and as a Chrome extension that reviews