prreviewbuddy 0.14.1 → 0.18.0

package/CHANGELOG.md

@@ -0,0 +1,760 @@
+# 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
+  the Assistant were still answering a failed review with "No analysis
+  available.", which reads as an absence, while the Issues and Questions tabs
+  named the failure. One review told two stories depending on which tab was
+  open.
+- The Assistant no longer tells you an analysis is unavailable when you simply
+  have not run one yet.
+- The release notes now ship with the CLI, so `prreviewbuddy` carries a
+  CHANGELOG.md you can read where it is installed rather than only in a
+  repository you may not have.
+
+## 0.15.1
+
+- **A review that finds nothing now says so.** "No findings" with the analysis's own provenance
+  under it, rather than the same grey line a review with no analysis at all produced. A clean
+  review is a result, and it used to be rendered as an absence.
+- **An unusable response from a coding agent now reads as a failure.** It ran, exited cleanly and
+  returned something PR Review Buddy could not parse, which has no findings in it either. Those two
+  outcomes rendered identically, so the worst case looked like the best one. The failure is
+  recorded as `agent_output_invalid` rather than left unclassified beside a git error, which is
+  also what tells the two apart when deciding whether a retry is worth offering.
+- A review whose analysis failed no longer reports "Analysis in progress" forever. The session was
+  left mid-flight when its job died, so the tabs described a run that had already stopped.
+
+## 0.15.0
+
+*A command says what to review, and what to do to it.*
+
+```
+prreviewbuddy review --branch feat/foo            review a branch you are not standing on
+prreviewbuddy review --branch feat/foo --update   bring that branch's review up to date
+```
+
+Anything that names a target composes with anything that names an operation. `--branch` takes a
+branch, local or remote, and the review is made in a worktree of its own as always, so nothing
+touches your checkout and you do not have to leave the work you are in the middle of.
+
+**Three things break.**
+
+**The bare argument is gone.** `prreviewbuddy review <pr-url>` is `prreviewbuddy review --pr <url>`,
+and `prreviewbuddy review develop` is `prreviewbuddy review --base develop`. That second one is why
+the argument had to go rather than be extended: a bare word meant the base, so `review my-feature`
+reviewed the branch you were on, *against* `my-feature`. Adding `--branch my-feature`, which means
+review `my-feature`, would have put two spellings of one word in one command with opposite meanings.
+Both old spellings are refused by name and the message says which flag replaces it.
+
+**`prreviewbuddy update` is gone.** It is `prreviewbuddy review --update`, and `update --reanalyse`
+is `prreviewbuddy review --reanalyse`. Typing the old command tells you where it went. The gain is
+the reason it moved: `update` with no review took the newest review of the repository you were
+standing in, so two branches reviewed in a row from one directory could only be updated in the order
+they were made. An operation now acts on the review of the target it was given.
+
+**A review follows the ref it was made from.** This is the one nobody notices until it matters, and
+it is the reason it is written here. An update picks up commits you have not pushed, where before it
+waited for the push. It no longer follows somebody else's push to the same branch, where before it
+did. Those were not one behaviour: the freshness strip already read `refs/heads/<branch>` while the
+update button read `<branch>@{upstream}`, so each was wrong in the opposite direction and they could
+disagree with each other on the same page. They now answer the same question, and the shorthand
+means your local branch. `--branch origin/feat/foo` follows the remote ref instead, and keeps
+following it even if a local branch of that name appears later.
+
+Two refs are two reviews. `feat/foo` and `origin/feat/foo` get a review each, told apart in the
+listing by the ref each follows, because a review that follows one ref cannot honestly be handed
+back to somebody who asked for the other. Reviews made before this release follow their local
+branch, which is what they already did, so nothing you have is duplicated or lost.
+
+**Also fixed.** A pull request is compared against the branch it targets. A PR onto `develop` was
+diffed against `main`, which is not a missing feature but a wrong diff: it produced findings about
+code the pull request does not touch. A branch that exists only on the remote can now be reviewed,
+and the review can then be updated and can show its freshness, none of which worked before. And a
+`--base` that does not exist is refused before the worktree is built rather than tens of seconds
+later, as a job failure with a workspace already on disk.
+
+## 0.14.1
+
+- `prreviewbuddy agents` said "Run `prreviewbuddy agents <id>`" on its last line, and three other
+  messages about agents said `<id>` too. 0.13.1 fixed that placeholder in the help screen and
+  nowhere else, so the fix missed the place a person is most likely to be reading about agents when
+  they meet it. The guard now covers every string in the module rather than the help alone.
+
+## 0.14.0
+
+*PR Review Buddy is a command line tool. The Claude Code plugin is withdrawn.*
+
+The plugin reviewed the same branches, in the same way, through a second set of commands that had
+to be kept in step with the first. Everything it did is in the CLI:
+
+```
+npm install -g prreviewbuddy
+prreviewbuddy review
+```
+
+Nothing you have already reviewed is affected. Reviews live in `~/.prreviewbuddy` and are served by
+the same workspace server whichever way they were made. The plugin releases already published stay
+downloadable, and there will be no further ones.
+
+Release notes now live in `CHANGELOG.md` at the top of the repository. They were kept inside the
+plugin's packaging, which made the history of the whole product look like the history of one way of
+reaching it.
+
+## 0.13.1
+
+- The help screen no longer writes `<id>` for two different things. A review is `<review>`, a
+  coding agent is `<agent>`, and the agent lines name what may be typed rather than sending you to
+  another command to find out. The names come from the registry, so a new agent cannot leave the
+  help behind.
+- The help says where a review ID comes from, and that `update` does not usually need one.
+
+## 0.13.0
+
+*A review can be made by Claude Code, Codex or Gemini CLI, and says which one made it.*
+
+`prreviewbuddy agents` lists the coding agents this version can use and whether you have them.
+`prreviewbuddy review --agent codex` reviews with one by name, and `prreviewbuddy config set agent
+codex` remembers which to use when you do not. With several installed and nothing chosen, the
+command asks you once, and offers to remember your answer rather than saving it quietly.
+
+A review is not owned by an agent. It is a workspace that holds analyses, and each analysis names
+the agent that produced it: `prreviewbuddy update <id> --agent gemini --reanalyse` analyses the same
+commit again with a different agent, in the same review, and the analysis it replaces goes on saying
+who made it. "Reviewed with Codex" appears in Analysis details, on the workspace page and in the
+extension alike.
+
+An agent is only listed once it can be confined to reading. That is a condition of being offered at
+all rather than a setting: Codex runs under a read-only sandbox the operating system enforces and
+without the MCP servers configured on your machine; Gemini runs with every writing tool removed from
+the set the model is offered, and with a per-run token that blocks every MCP server, because Gemini's
+own "allow none" setting allows everything.
+
+Nothing here asks you for a credential, and there is still no account and no API key. Each agent uses
+the authentication it already has, which is also why `agents` says an agent is installed rather than
+saying it is signed in: finding out would mean spending your quota to draw a list.
+
+Two fixes worth naming. A question asked of a review whose job had been swept was answered by the
+default agent rather than by the agent that made the review, which on a Codex review meant Claude
+answering as though it were the review's own. And a run that failed because an agent was not signed
+in offered a Retry that would fail in exactly the same way, because a review keeps the profile it
+was created under; it now says what would actually change it.
+
+## 0.12.18
+
+*A review link from Claude Code now knows its way back to the list.*
+
+The reviews index is opened by a credential that no single review page is allowed to carry, and the
+only thing that puts that credential into your browser is arriving at the index with it once. A
+review started from the command line has handed you a link that does that since 0.12.2. A review
+started from Claude Code handed you a plain one, so "All reviews" in the left rail refused you on
+the first click, and whether it worked depended on which surface you happened to have started from.
+Every link the plugin gives you now carries the same way back.
+
+## 0.12.17
+
+*The packages say which version of Node they need.*
+
+Nothing in the product behaves differently. The published command has always declared that it needs
+Node 20, because the release script writes that into the package it ships, but the packages in the
+repository never said so themselves: someone building from source on an older Node got no warning at
+install and a confusing failure somewhere later instead. They now declare it in the one place a
+package manager reads. The version number moves with it so that what is on the registry and what is
+in the repository are the same release.
+
+## 0.12.16
+
+*Buddy AI can draw the change as a diagram, a question you have thought better of can be stopped,
+updating a review keeps it describing the same change, the counts tell you what is left rather than what was ever found, you can close a
+finding yourself, the notice about a moved branch appears only when that branch has moved and is a
+status line rather than a page of explanation, your reviews list is reachable from the review you
+are reading, and every way back is named for the product you installed.*
+
+**You can stop a question.** Asking Buddy AI something committed you to it: the field and the button
+went dead and there was no way out but reloading the page, for up to three minutes. **Ask** now
+becomes **Stop** while an answer is being worked on, and pressing it ends the work rather than
+merely the waiting: the question stops being read, the process reading it is signalled, and your
+subscription stops being spent on an answer you no longer want. The question stays in the panel
+marked `Stopped.` and its words go back into the box, so a question you meant to phrase differently
+takes one edit rather than retyping. Closing the tab or reloading mid-answer stops it too, for the
+same reason.
+
+**Buddy AI can draw the change.** Some things are faster to see than to read. **Show implementation
+diagram** on the Overview asks Buddy AI for a diagram of how the change works, and **Diagram this
+theme** on a theme does the same for one slice of it. The drawing opens in the main pane rather than
+in the assistant panel, so it is something to read the review beside rather than a message that
+scrolls away, and it is kept with the review: reopen the review tomorrow and it is still there.
+Buddy AI chooses the shape from the change itself, a flow, a set of modules, a sequence of calls.
+**Regenerate** asks for another whenever the first is not the one you wanted, and the one you have
+stays on screen until the new one arrives. Each diagram folds away from its title, so a review with
+several of them stays readable. Updating a review leaves its diagrams alone and says
+which commit each was drawn from, because a picture you asked for is not ours to delete.
+
+**A question keeps the shape you typed it in.** A question written over several lines, or with a
+pasted stack trace in it, came back in the panel as one run-on line: the line breaks were there in
+what was asked and in what was stored, and only the display of them collapsed. Your questions now
+read back exactly as you wrote them, live and after a reload.
+
+**The counts say what you still have to do.** A review whose fifteen findings had all been fixed and
+whose seven questions had all been answered still read `Issues 15 · Questions 7` in the sidebar, over
+a page where every card said RESOLVED or ANSWERED, and the Questions heading claimed "7 of 7
+unanswered" above seven answers. The sidebar now counts what is open, and shows a tick where nothing
+is: a theme whose findings are all fixed, a review with nothing left to read. Issues and Questions
+each split into the work still to do and, behind a disclosure below it, what has been dealt with, so
+nothing is thrown away and nothing has to be scrolled past. The Overview keeps both numbers, the open
+count and how many of the original findings were closed, because a review that fixed ten things did
+more than one that found none. On the reviews list, a review with every finding resolved says so.
+
+**You can dismiss a finding you have decided is fine.** Until now only a commit could close one, so
+a finding you had read, thought about and decided needed no action sat in your sidebar until the
+author happened to push something. Dismiss is on every finding, and a dismissed one stops counting
+and moves in with the ones the commits fixed. Which of the two closed it is kept: the pile is called
+"Resolved by the new commits" when they did all of it, "Dismissed by you" when you did, and "Dealt
+with" when it is both, and each card says which. Your decisions now survive an update, too, rather
+than coming back the next time you press Analyse new changes. The one thing that reopens a dismissal
+is the analysis reporting that the code underneath it has changed: the finding returns to your list
+marked "Changed since you dismissed this", with your decision still on it, and Dismiss again puts it
+back once you have looked. Questions work the same way and always have, and Mark answered now moves
+the question in with the answered ones rather than leaving it sitting among the open ones, taking the
+theme heading with it when it was the last question under it, and un-answering one puts it back
+under that heading rather than at the bottom of the tab. Answering the last one leaves a single
+divider above the answered pile instead of two with a gap between them.
+
+**The Files tab shows the code that was reviewed.** Opening a file said "That file is not in the
+working tree. This change may have deleted it." on a row badged ADDED, which is two claims that
+cannot both be true: the pane was reading your checkout, and a checkout on any other commit does not
+have the files the change created. The subtler half was worse, because nothing announced it. A file
+that still existed but had moved on since the review opened without complaint and showed you today's
+code under the review's line numbers. A review is a description of one commit, so the pane now reads
+that commit, says which version you are looking at, and reads your working tree only where that is
+what was reviewed: a review of uncommitted work, or a commit this repository no longer has. Open in
+editor still opens your own copy of the file, and where the two differ the pane says so, on that
+file, before you press it. Where your working folder has no such file the button is disabled rather
+than opening an empty buffer. A file the change really did delete is named as deleted.
+
+**Updating a review no longer swells it to the whole of your default branch.** A pull request of
+four files came back reporting three hundred after one update. The findings were right; everything
+around them described a different change, including the Files tab, the count in the header and the
+diff Buddy AI answers from. A review records what it was compared against by the name you would use
+for it, `main`, and rebuilding it looked that name up again in your own clone, where `main` is your
+local branch and is behind the remote from the first day you do not pull. Every upstream commit you
+had not fetched arrived in the comparison. A review now records the exact ref it was compared
+against and rebuilds against that one, and a review made before this release resolves the remote
+branch first, which is the one it was made from.
+
+**The freshness strip measures the branch your review is of, not whatever you have checked out.** A
+pull request is reviewed in a checkout of its own and you never stand on its branch, so the strip was
+comparing the review against some unrelated branch and announcing "Code rewritten", with a file count
+to match, about a review that was exactly current. It now reads the pull request's own branch as this
+repository last saw it, and a review of a local branch reads that branch by name, so wandering off to
+look at something else no longer makes a review look stale. More details says which branch it
+compared against, and where that is a copy fetched from the remote it says so, because Check review
+status re-runs the comparison against what you already have and only Update review goes and fetches
+a newer one. Where the branch is not in this repository at all, which is what a pull request from a fork
+looks like, it says it cannot compare rather than measuring against something else and calling that
+an answer.
+
+**Where your own working folder is checked out is no longer treated as review news.** The header
+said "Checkout differs" in amber over a review whose code was exactly current, and opening it showed
+a panel headed "Up to date", which is two parts of the same page disagreeing. It was also
+unanswerable: it compared the commit you personally have open against the pull request's, and
+reading a pull request from your own `main` puts you on an earlier commit by definition, so nothing
+you could press ever cleared it. The freshness panel is about the review now and says nothing about
+your working folder at all. The one moment the difference has a consequence is opening a file in
+your editor, and the Files tab answers that where it happens: it compares that one file, byte for
+byte, and says "your editor will show a different version" only when it is true of the file you are
+looking at. A folder on an earlier commit still holds an identical copy of everything the change did
+not touch, and there was never anything to say about those.
+
+**Re-checking the conversation no longer takes the panel with it.** The control is a phrase inside
+a sentence now, and while it ran it was replacing its own words, leaving "Checking... 1s to refresh
+comments and resolved threads" with the status message jammed onto the end of the line. The whole
+line becomes the progress message for as long as the re-check runs, and the panel that control was
+pressed in is open again when the page comes back, with its own fresh "Last checked".
+
+**Less furniture between you and the review.** The rule under the count line on Issues and
+Questions, and the one under the pull request title on PR context, are gone: the blocks below them
+were already visibly blocks, so the line was drawing a boundary the layout had drawn. On PR context
+the paragraph explaining Re-check the conversation now runs the full width of the view instead of
+stopping short of its own right edge. And where the note above the Issues list tells you to use
+Re-check the conversation, that phrase is now the control: it takes you to the view that holds it.
+
+**The freshness panel says what it means in the words you would use.** The status is **Review up to
+date**, because "Up to date" could have meant your local code was current when what is meant is that
+the review has read the newest commit on the pull request. Check again and Start fresh are **Check
+review status** and **Start a new review**, because the first checks whether the reviewed state
+still matches and the second makes a separate review rather than updating this one. More details
+lost the phrases that described our plumbing rather than your review: a branch "as current as your
+last fetch" is now the version you already have locally, and re-checking the conversation is one
+sentence with the control inside it rather than an explanation followed by a button repeating its
+own name. A review that is current has no More details at all: the two sentences that were behind it,
+the commit the review is of and when the conversation was last read, are simply on the panel, because
+a disclosure over two lines makes a healthy review look like it is holding something back. The
+summary stays where it earns its click, on a review that has changed, where it holds the explanation
+of Update review and the way to dismiss the warning. Every control in the panel is legible without
+being pointed at, Close is an icon at the end of the row rather than a word competing with the
+decisions beside it, More details stays where you clicked it instead of jumping to the next line as
+it opens, and the panel uses the width it has instead of stopping short of its own right edge.
+
+**The strip that tells you a branch has moved is a third of the size.** It had one thing to say and
+was taking five rows to say it: what happened, what that means, what you can do, a sentence about
+what the button does, and a block of footnotes about your checkout and the pull request
+conversation. All of that is still there. Only the first three lines are on the screen, ending in
+`More details`, and the rest is one click away when you want it. The heading is bigger, the lines
+are shorter, and the amber no longer runs the full width of the window.
+
+**"All reviews" works from a review page now.** The list of your reviews is opened by its own
+credential, separate from the ones that open a single review, and a browser is given that credential
+by opening the list once. Nobody using the command line was ever sent there, so the first click of
+that link refused them, every time. The link `prreviewbuddy review` prints now carries the browser
+through the list on its way to your review, so the way back is already there when you look for it.
+Nothing changed about what a review page can reach: it still holds only its own key.
+
+**If you do land on that refusal, it now explains itself.** It used to be a line of raw JSON in the
+address bar. It is a page, it says what happened, and it names the one command that fixes it.
+
+**The way back to your reviews is named for the product you are actually running.** Every place that
+told you how to reach your reviews again named a Claude Code slash command, including the places a
+command line user is most likely to end up: the refusal above, the bookmark page, the notice after
+you stop the server, and the confirmation before you stop it. Each of them now names the command
+that exists on your machine.
+
+## 0.12.1
+
+*Repositories with checkout hooks can be reviewed, and a failed review says why it failed.*
+
+**A repository with its own checkout hooks no longer fails every review.** Setting up the isolated
+checkout runs the same git machinery as switching branches, which meant your repository's
+`post-checkout` hook ran inside it. Husky's hook asks git a question that a freshly made checkout
+cannot answer, so it failed, and took the review down with it before any code was read.
+Those hooks are now switched off for the review's checkout. They were written for a person about to
+work in a directory, and nobody works in this one: it is read once and deleted.
+
+**A review that stops now tells you what stopped it.** The progress block redraws itself in place,
+and its last redraw was landing on top of the failure message and erasing most of it. What
+disappeared was exactly the useful part: the underlying error, the line saying the review can be
+resumed where it stopped, and the link to it. The block also miscounted its own height whenever a
+line was too long for the window, which is most windows, since one of those lines is the path to
+your repository.
+
+**A checkout that failed halfway no longer blocks the next attempt.** Some failures leave the
+directory behind, and the retry then failed on that instead, reporting a second problem that hid the
+first.
+
+## 0.12.0
+
+*Reviews read the pull request conversation now, and say why when they cannot.*
+
+**Pull request conversations are now actually included in reviews.** Fetching one used to take a
+little over four minutes against a budget of two, so it timed out every time, on every review, and
+the review was quietly assembled from the code alone. It now uses the GitHub CLI you are already
+signed in to, and comes back in about two seconds. Measured on four real pull requests: 1.5 to 2.1
+seconds, against 242 seconds before.
+
+That changes what a review can tell you. A finding can now say a colleague already raised this, and
+whether their thread is still open, because there is a conversation to check it against.
+
+**And it says so when it could not.** If the conversation is unavailable, the review now tells you
+why instead of silently looking complete. A repository with no pull request stays quiet, because
+nothing is missing from it.
+
+**A second GitHub account no longer reports you as signed out.** If another account in your keyring
+had an expired token, the check failed on that one, while the account it would really have used was
+working perfectly.
+
+**The freshness panel is one panel.** It was three warnings stacked, each with its own amber dot, so
+a rewritten branch and a checkout that is merely behind shouted equally loudly and the action was
+buried in the middle. It now reads as one thing: what the status is, one sentence on what that means
+for the findings below, then **Update review** as the only control wearing a colour. About a third
+shorter.
+
+**Following a theme no longer loses the page.** Clicking a theme in the left rail could scroll the
+header and the status banners off the top of the window, with no scrollbar to bring them back. The
+page is one screen tall now and the panes inside it scroll, which is what was always intended.
+
+**Reviewing a merged pull request explains itself.** It used to refuse with advice about switching
+branches and committing your work, which is not something a person who pasted a link can act on. It
+now says the request is already merged and there is nothing left to compare.
+
+Smaller things: scrollbars are thinner and no longer disappear on macOS until you touch them; the
+workspace and the terminal agree on what to call a paused review, a rewritten branch and starting
+fresh, having drifted into two words for each; and an authentication failure now names which tool
+could not sign in, since a review runs through two of them and only one is ever the problem.
+
+## 0.11.10
+
+*A list of reviews now says what tells two of them apart.*
+
+A review of a branch is titled by the subject of that branch's oldest commit, which is the
+convention a forge uses, and it means a branch cut from the tip of another inherits that branch's
+title. Two entries then read as one review listed twice. Reviewing a branch twice did the same
+thing, and so did two repositories on one machine. Each entry now names the repository, what the
+review was compared against, how big the change is, and which analysis of its branch it is, in the
+terminal and in the list a Claude Code session is handed. The browser index has shown these since
+it was rebuilt around branches; the two lists had not caught up.
+
+## 0.11.9
+
+*A release now carries only the files its own build produced.*
+
+The workspace page is the same on every surface, so every surface built it into one shared
+directory and copied the whole of that directory into its own release. Nothing in there could be
+cleared without one build deleting another's output, so a file left behind by an earlier build, or
+by a different surface, stayed and was shipped, and the workspace server serves whatever it finds
+beside it. Each copy is now built by one thing and cleared before it is written. The page itself is
+unchanged.
+
+## 0.11.8
+
+*Updates and re-reads use the account that made the review, and a refused prompt says where.*
+
+The same fix as the Ask panel had in 0.11.7, applied to the two places that still read the
+workspace server's own environment instead of the review's. Both put their result on the page under
+the review's name, so both owed the reader the review's own agent and account rather than whichever
+shell happened to start the server first. Reviews old enough to have lost their job record are
+unaffected and behave as before.
+
+A refused prompt now says where the problem is.
+
+A review is refused rather than sent if its prompt names the repository the isolated checkout exists
+to keep the agent away from. The refusal said that it had happened and nothing more, which left
+nowhere to look in a prompt of several hundred kilobytes. It now names the position and quotes the
+surrounding text, which is what says whether the path was written into the prompt or arrived quoted
+inside a pull request comment. The rule itself is unchanged: exactly the same prompts are refused.
+
+## 0.11.7
+
+*A failing agent no longer closes every open review, and the Ask panel uses the right account.*
+
+A review prompt is hundreds of kilobytes, and an agent that exits before reading it closes the pipe
+mid-write. That was an unhandled error in the workspace server, which is one long-lived process
+serving every review on the machine, so a single agent that could not start closed all of them. The
+failure now reports whatever the agent said on its way out, and everything else stays open.
+
+Questions in the Ask panel are answered by the account that made the review.
+
+Which Claude answers used to depend on which shell happened to start the workspace server first,
+because the panel read the environment from there rather than from the review. A review made under
+one account and asked about under another was answered by a Claude with different access, and
+nothing on the page said so. Older reviews whose job records have aged out are unaffected and
+behave as before.
+
+## 0.11.6
+
+*`--base` decides which review you get, not only which one is made.*
+
+`prreviewbuddy review --base develop` used to hand back the newest review of the branch whatever it
+had been compared against, and say a review of what you asked for already existed. A review is of a
+comparison rather than of a branch, so a base you name is now part of the question: you get the
+review made against that base, or a new one, and never somebody else's comparison under your
+branch's name.
+
+Every review now says what it was compared against, in the same line that says how old it is. That
+one is for the far commoner case, the plain command, where the comparison is the one thing about a
+review you cannot see from the outside.
+
+## 0.11.5
+
+*A finished review records what it actually covered.*
+
+The Overview of a review made by the isolated pipeline showed a plain file count, because the
+coverage, the pull request discussion counts and the time the analysis took were never written
+down. The code that knew how to work them out was only ever reached by a preview script. Reviews
+now carry all of it, so "50 of 482 files" reads as what it is, and a review that was given twelve
+unresolved threads says so instead of looking identical to one that was given none.
+
+"Update review" recounts the same facts against the change it just re-read, rather than carrying
+forward numbers that described the analysis it replaced.
+
+Older reviews are unaffected and keep rendering as they did; run a review again to get the fuller
+Overview.
+
+## 0.11.4
+
+*One review at a time, known to the machine rather than believed by each process.*
+
+A review that had been running quietly for over half an hour was recorded as stopped, which put
+Retry on the page. Pressing it started a second analysis in the checkout the first one was still
+reading. Both are now refused: a review being made holds a claim that every surface can see, and
+nothing offers to restart it while that claim is held. A review whose process really did stop
+releases it, and Retry works exactly as before.
+
+## 0.11.3
+
+*A review that had finished no longer shows as still being made.*
+
+**A finished review opens.** Reviews made by this version's isolated pipeline were stored complete
+but still marked as being made, so the workspace showed the right counts in the rail and "Analysis
+in progress" in every pane, on a review that had actually finished. If you have a review stuck like
+that, this version does not repair it: run the review again.
+
+## 0.11.2
+
+*The link printed at the end of a review is one that still works.*
+
+**The link at the end of a review is the one that works.** The command line printed the address it
+had been given when the review started, and a review takes minutes: if the workspace server had
+been restarted in between, that address no longer went anywhere. It is now worked out again at the
+moment it is printed, on the finished review and on one that stopped.
+
+## 0.11.1
+
+*Asking for a review while one is being made now says exactly that.*
+
+**Asking for a review while one is being made now says so.** Running the review command again on a
+branch whose review is still in progress used to report that a review already existed and offer to
+bring it up to date or start a fresh one. Neither of those is a thing you can do to an analysis
+that has not finished once. It now tells you it is being made right now, gives you the same link,
+and leaves it at that.
+
+## 0.11.0
+
+*Every review runs in a checkout of its own, made in the background, with a command line alongside.*
+
+**Every review now runs in a checkout of its own.** A worktree is made under
+`~/.prreviewbuddy/worktrees`, detached at exactly the commit being reviewed, and the analysis reads
+that and only that. Your own checkout is never read and never written while a review runs, so you
+can keep working, switch branch, rebase, or leave the tree dirty and none of it reaches the review.
+The assistant answers from that same pinned checkout, so its answers describe the code you are
+reviewing rather than whatever you happen to have open.
+
+**One command does the whole thing.** `/prreviewbuddy:review` resolves what to review, records the
+job and hands back a link, and the review is made in a separate process. Your session is free the
+moment you have the link. Pass a pull request number or a link to one to review that instead of the
+current branch, and use `/prreviewbuddy:fresh-review` to review a branch again alongside the review
+you already have.
+
+**A review that stops now says so.** If whatever was making a review goes away, a session you
+closed or a terminal you killed, the page used to sit on a spinner forever. It now tells you the
+review stopped, and offers Retry, which picks up from the step it had reached rather than starting
+over.
+
+**Nothing is left lying around.** The isolated checkouts are kept for six hours after a review
+finishes, because that is what the assistant reads while you are still asking questions, and are
+then removed. Your reviews themselves are untouched by this and are still kept for thirty days.
+
+**A command line, if you would rather not open Claude Code.** `prreviewbuddy review` makes the same
+review, through the same engine, into the same workspace, with no plugin loaded. There is still no
+account, no API key and no configuration: it runs through the agent you have already installed and
+signed in to.
+
+**Two things are gone on purpose.** Reviewing uncommitted changes has been removed: PR Review Buddy
+reviews committed code. And a dirty, diverged or detached checkout no longer blocks a review, since
+the review is not made from your checkout any more and there is nothing left for that check to
+protect.
+
+## 0.3.1
+
+*A way back into a review after the server restarts, conversation intact.*
+
+**Getting back into a review.** `/prreviewbuddy:start-server` starts the workspace server and lists
+your recent reviews with working links. Stopping the server never deleted anything — the reviews
+have always been on disk — but their links carry the port, and the server takes a new one each time
+it starts, so the old link pointed at nothing. Now there is a way back.
+
+**Your conversation comes back with it.** A reopened workspace shows the questions you already
+asked and the answers you got. They were always stored, and the assistant was already using them to
+ground new answers; the page simply was not showing them, which read as forgotten.
+
+**Stopping now asks properly.** A dialog that says what happens, instead of a button that relabels
+itself into a confirmation — that version could leave a stale label behind after the server had
+already stopped. `/prreviewbuddy:stop` is now `/prreviewbuddy:stop-server`, to pair with
+`start-server`.
+
+## 0.3.0
+
+*The Files tab becomes a browser, the assistant resizes, and the server can be stopped.*
+
+**The Files tab is now a file browser.** Every changed file, grouped under the theme that owns it,
+with a search box and the finding counts each file carries. Click any file to read it in place —
+the same viewer an issue or a question expands, because the point is that you can go and look at
+whatever you like, not only at what the review pointed to.
+
+**The assistant is resizable.** Drag its left edge; it remembers the width between sessions and
+across reviews. Arrow keys move it too, and double-clicking the edge puts it back. It starts wider
+than it used to, which is the honest position: it is a pane of the workspace, not a chat widget
+docked to the side.
+
+**A way to stop the workspace server.** It stays running after Claude Code closes, on purpose, so
+your workspace keeps working — but until now nothing ever ended it. **Stop server** in the header,
+or `/prreviewbuddy:stop` once the tab is closed.
+
+Smaller things: "Explain in simple terms" now uses the fuller wording the extension uses, analogy
+and all. The workspace has a favicon, so its tab is findable among twenty others.
+
+## 0.2.2
+
+*Stops instead of building a review of nothing.*
+
+**Says so when there is nothing to review.** Running the command on `main` straight after a pull
+compared the branch against itself, found no changes, and went ahead and built a review of nothing
+— a workspace with empty themes, or invented ones. It now stops and tells you what it compared:
+
+> No changes found to review — main is the base it would be compared against. Switch to the branch
+> containing your changes, or review uncommitted changes.
+
+To review work you have not committed yet, ask for it: *"review my uncommitted changes"*.
+
+## 0.2.1
+
+*Fixes the command name to `/prreviewbuddy:review`.*
+
+**Fixes the command name.** The documented `/prreviewbuddy` never worked: Claude Code namespaces
+plugin commands as `plugin:command`, so it answered `Unknown command`. The command is now
+`/prreviewbuddy:review`, which reads better than the `/prreviewbuddy:prreviewbuddy` the old file
+name would have produced.
+
+If you downloaded 0.2.0, this is the only thing that changes for you — the review itself is
+identical. Take 0.2.1 and use the new command.
+
+## 0.2.0 — first release
+
+*The first release, described by what it does rather than what changed.*
+
+> Shipped documenting the command as `/prreviewbuddy`, which does not resolve. Corrected below;
+> 0.2.1 renames it to `/prreviewbuddy:review`.
+
+The first build outside the workshop. Everything here is new to you, so this is what it does
+rather than what changed.
+
+**A review you work through, not a wall of text.** `/prreviewbuddy:review` in any git repository
+turns the current branch into a workspace: a suggested path through the change in the order
+worth reading it, findings that cite real lines, and questions worth putting to the author.
+Claude Code does the analysing and reads the surrounding repository, so a finding can rest on
+code the diff never showed.
+
+**Citations open in place.** Click a file on a theme, or an issue's location, and the code
+opens under it with the cited line marked. **Open in ...** hands it to your editor — VS Code
+by default, configurable.
+
+**An assistant that already has the context.** Ask about a finding without explaining the
+change first. It answers from the guide, the diff and the repository, and it keeps working
+after the Claude Code session that produced the review has closed.
+
+**Every changed file is accounted for.** Large changes are prioritised, never truncated: the
+review path says where to start, and the Files view lists everything else. On a big change not
+every diff travels inline, and the analysis reads those files from the repository instead.
+
+**Several reviews at once.** Two Claude Code sessions, or two worktrees, give you two
+independent workspaces. A workspace opened from a linked worktree names the checkout in its
+header and tab title, so near-identical branches stay tellable apart.
+
+**Nothing leaves your machine.** No account, no API key, no server of ours. Reviews live in
+`~/.prreviewbuddy/`, the workspace is served on `127.0.0.1` behind a per-review token, and the
+local usage log has no network path out of it at all — `PRB_TELEMETRY=off` if you'd rather it
+weren't written.
+
+### Known limits
+
+Worth knowing before you hit them:
+
+- **Stopping the workspace server** needs `pkill -f 'dist/server.js'`. There is no command yet.
+- **Built and tested on macOS.** Linux and Windows should work — the browser launch handles
+  all three — but neither has been run in anger. Reports welcome.
+- **The assistant needs `claude` on your `PATH`**, since it shells out to `claude -p`. If it
+  isn't there, the panel says so rather than failing quietly.
+- **Reviews are local and private, which also means unshareable.** There is no link to send a
+  colleague.
+- **The review path is a priority order, not a coverage claim.** A file it doesn't send you to
+  was not judged unimportant and was not hidden — it just isn't where you should start.
+
+### Feedback
+
+**Send feedback** in the workspace header. It carries the version and your OS, and not your
+repository, your code, or the review.