prreviewbuddy 0.73.1 → 0.76.9

package/CHANGELOG.md

@@ -1,5 +1,237 @@
 # Changelog
 
+## 0.76.9
+
+**Extension 0.29.3: the update toast counts the findings to look at again.** An update whose only
+effect was to mark a finding for another look said "Nothing resolved, nothing new.", which on an
+update prompted by comments is often the whole of what it did. The toast now says "1 finding to look
+at again.", after what was resolved and before what was answered, as the workspace has always
+reported it ("1 to look at again").
+
+## 0.76.8
+
+**Extension 0.29.2: an update's notes and answers name a comment by its author, not by its id.** A
+question answered by a comment read "@ctamakloe in [IC_kwDOVFXbc88AAAABbNKUUA] confirmed…", because
+the update prompt asked the model to cite the thread id in the sentence the reviewer reads. The
+prompt now asks for the author and what the comment establishes there, and keeps ids for the
+structured evidence the harness checks. Same prompt in the workspace and the extension. Notes
+written by earlier updates keep the id they were written with.
+
+## 0.76.7
+
+**Extension 0.29.1: the update toast says what the update answered.** An update that answered an
+open question, with nothing resolved and nothing new among the findings, said "Reassessed against
+the new comments. Nothing resolved, nothing new." It now says "1 question answered.", and adds that
+sentence after any change to the findings. Extension updates began reassessing questions in 0.29.0,
+which is what made the gap reachable.
+
+## 0.76.6
+
+**Extension 0.29.0: updates and Chat read the pull request conversation, by the workspace's rules.**
+The extension now remembers the conversation each pull request's latest analysis was given, and
+offers an update when the comments change, not only when commits arrive ("There are new comments
+since your analysis", with "Reassess against comments"). An update on comments alone reassesses the
+findings and open questions against what changed in the conversation, with no diff and no fresh
+review of the code. A comment can resolve or reopen a finding only on the evidence it cites, exactly
+as in the workspace, because both now fold an update's answer through the same shared code. Open
+questions are reassessed too, as the workspace does. The toast says what the comments resolved or
+reopened apart from what the code did. Every update says what it has of the comments, even one
+made only for new commits, and a copy the page could not refresh is labelled possibly out of date.
+Chat fetches the comments again before each answer, waits at most three seconds, says when it had
+to answer from an older copy, and keeps a fetch that finishes late for the next answer (never
+letting an older fetch replace a newer one, and never counting it as analysed). It lists what is
+new since the analysis. A conversation the analysis was given only as a summary stays new to the
+next update. With "Use
+existing PR comments" switched off, nothing is shared and the model is told the comments were
+withheld, not that there are none, and the last conversation an analysis saw is kept for when they
+are switched back on. A review made before this has no record of what its analysis saw, so new
+comments alone do not raise the banner for it; an update started for new commits still reads the
+comments and is told it cannot know which are new. No change in behaviour for the workspace.
+
+## 0.76.5
+
+**Extension 0.28.3: the toast after "Analyse new changes" says what that run changed.** It counted
+where the findings stood, so from a review's second update on it announced a finding an earlier
+update had resolved as resolved again. It now counts against the review it updated, by the same
+rule the workspace's Update uses (0.76.2), which both now share. No change in behaviour for the
+workspace.
+
+## 0.76.4
+
+**A status says what the update was looking at.** A finding or question an update judged against the
+conversation alone no longer reads as judged against new commits. Its status explanation, the
+heading on its update note in Copy ("After the pull request conversation"), and the heading on an
+answer ("Answered by the pull request conversation") now name the conversation, and an update that
+read both names both. A verdict resting on a comment it cites is credited to the conversation.
+Reviews updated before this, and every update the extension makes, read as they did. (Extension
+0.28.2: no change in behaviour.)
+
+## 0.76.3
+
+**Update's progress no longer claims new commits that never came.** When only the conversation had
+changed, the steps read "Prepared a checkout of the new commits" and "Reassessed the review against
+the new commits". They now say "Prepared a checkout of the latest commit" and "Reassessed the review
+against what changed", which hold either way, and the closing message still says whether any commits
+arrived.
+
+## 0.76.2
+
+**An update says what it changed, not where the findings stand.** A finding resolved by an earlier
+update is no longer reported as fixed again by every update after it, and a question answered earlier
+is not counted as answered again. A finding reopened because the comment that resolved it changed is
+reported as reopened, where the update used to say it changed nothing. A finding a comment resolved
+is reported as resolved by the conversation, never as fixed. Both the update strip and the message
+the terminal prints follow this.
+
+## 0.76.1
+
+**A thread left out of the first analysis is shown to the next update.** On a busy pull request the
+review's prompt carries only the threads that fit. The review now records just those as taken into
+account, so Update reads the rest as new rather than as already considered, and runs even when
+nothing has been said since. It also records the conversation the analysis was actually given, not a
+newer copy re-read while it ran. (Extension 0.28.1: no change in behaviour.)
+
+## 0.76.0
+
+**Buddy AI reads the pull request conversation.** Every question you ask is answered with the PR's
+comments, reviews and threads in front of it, re-read just before it answers, and with what changed
+since the review was made listed as new. Ask what the new comments mean for the review and it
+answers from them. If the conversation could not be read, it says so plainly instead of suggesting
+commands for you to run.
+
+**Update review reassesses against new comments, not only new commits.** When the conversation has
+changed since the review was made, Update reconciles the review against it even when there are no new
+commits. A comment can settle a finding whose premise it shows to be wrong, mark one to look at
+again, or answer an open question, and the finding's note cites the comment. A comment saying a bug
+is fixed is not a fix: the code has to show it. When no commit moved, the update strip says
+"Reassessed against the conversation" rather than naming a commit.
+
+**A review knows which comments it has already taken into account.** Each analysis records the
+conversation it was given, so "new since the review" is measured from that, not from the last time
+anything re-read the pull request. A review made before this records it the first time it is
+re-read.
+
+**More of a busy pull request's conversation is read.** Edited comments are noticed, every review
+submission is kept rather than only each reviewer's latest, long threads include their newest
+replies, and top-level comments past the most recent 50 are read too. Where a pull request has more
+than PR Review Buddy fetches, the analysis is told so rather than shown a part as the whole. Re-check
+the conversation counts edits, deletions and new reviews as well. (Extension 0.28.0.)
+
+**A finding a comment resolved can be reopened when that comment changes.** If the comment that
+settled a finding is later edited or deleted, the next update asks for the finding to be judged
+again from the comment as it now reads. It can stay resolved, be reopened because the finding is
+valid again, or be marked for reassessment when it cannot be told either way. It is never reopened
+just because nothing was said about it. A finding the code resolved stays resolved, as before.
+
+**Every finding keeps a status history.** Each change of status is recorded with what it rested on
+(the new commits or the conversation), the reason given, and the comment it cited as that comment
+read at the time, so a later edit cannot rewrite why a finding was settled. A cited comment that is
+not in the conversation, or a resolution with no commits and nothing cited, is marked for
+reassessment rather than resolved. The history sits behind a Status history disclosure on the card,
+closed by default, and is included when you copy a finding. The closed pile says "Resolved by the
+conversation" when a comment, not a commit, is what resolved it. (Extension 0.28.0.)
+
+**Reading the conversation is quick, and never holds up an answer for long.** A re-read now takes
+well under a second on an ordinary pull request. Buddy AI waits at most three seconds for it; on a
+very large pull request that takes longer, it answers from the last copy, says so, and has the fresh
+one for your next question. A slow re-read that finishes after a newer one never puts the older
+conversation back.
+
+## 0.75.0
+
+**You can change a finding's grade.** An issue's severity and a question's importance are no longer
+fixed by the analysis. Click the grade on a card, pick another, and optionally say why. The card
+shows the grade you hold now and how it moved, for example `major → minor · Reassessed by you`, with
+a History disclosure listing every change, its reason and when it was made. The analysis itself is
+never rewritten, so the original grade is always there to compare against.
+
+**Buddy AI can suggest a grade change, and you decide.** Reassess, in a card's Ask Buddy menu, asks
+Buddy AI to judge the finding again. If it thinks the grade should move, the card shows the
+suggestion with its reason and the places it cites, which open their file. Accept it, keep the grade
+you have, or ask more. A suggestion made against an older state of the review, or against a grade
+you have since changed, is shown as out of date rather than applied.
+
+**Updates and investigations suggest grade changes instead of making them.** When new commits change
+how serious a finding is, the update suggests the new grade and the update strip says how many it
+suggested. A repository investigation in the extension used to overwrite an issue's severity; it now
+suggests it, and can suggest a question's importance too. A collapsed list of closed findings says
+how many suggestions are waiting in it.
+
+**Your grades carry forward.** Prompts for chat, updates and investigations state the grade you hold,
+not the analysis's, so the next round starts from your judgement. Copy includes the change and its
+reason. An update never erases a grade change, and neither does a Look closer run or an
+investigation that finishes while you work.
+
+**The extension keeps what you do while a run finishes.** A grade change, dismissal or answer made on
+a review just as an update, investigation or Look closer saves its result is carried to the new
+result, and the sidebar catches up with it. Two Look closer runs finishing together both keep their
+findings. A reply that arrives late never puts an older grade back on screen. (Extension 0.26.0.)
+
+## 0.74.1
+
+**`review --pr` now works for pull requests from forks.** Before, a pull request whose branch lives on
+the contributor's fork could not be reviewed unless its commit was already in your clone, and the
+error told you to fetch a branch that does not exist on your remote. Now the pull request's own head
+is fetched from the repository it was opened against, so pasting the URL is enough: no fork remote,
+no `gh pr checkout`, no manual fetch. Nothing in your checkout changes, and no branch is created.
+
+**It works when your `origin` is your own fork.** The repository the pull request belongs to is found
+among your remotes, or reached by its URL when none of them is it. Only the exact commit GitHub names
+is ever reviewed; a fetch that brings anything else is refused rather than reviewed.
+
+**Updating a pull request review follows the pull request, not a branch of the same name.** A fork's
+pull request from its own `main` used to be updated against your repository's `main`. Update now
+asks GitHub where the pull request is and fetches its base too, so a pull request that merged the
+latest base is not shown the base's changes as its own.
+
+## 0.74.0
+
+**Notifications is now Activity, a history of what happened across your reviews.** Every row says
+more than what kind of event it was. A branch or pull request that moved says where it moved from and
+to, whether it moved locally or on the pull request, and how far behind the review was. A finished
+review says how many issues and unanswered questions it left. An update says what it fixed, what is
+new, what is still open and which questions the new commits answered. A failure says why. Each row
+records what was true when it happened, so an older row never changes its meaning.
+
+Each kind of event has its own icon: a branch, a commit, a merge, a check, a refresh, a warning.
+Unread rows keep their dot and tint, so new activity still stands out first. Purple now means only
+unread: pull request merges, closes and reopenings are shown in blue.
+
+**A branch that moves twice keeps both moves.** Before, a second move deleted the first row while it
+was still unread, and an update that caught the review up deleted it too. Now every move stays in
+Activity. Only the newest move counts as unread, since that is the only head you can update to, and
+an older one says "replaced by a later move" or "replaced when the review caught up". Neither is
+counted as read: nobody saw them.
+
+**PR merge, close and reopen transitions are now recorded in Activity, including changes discovered
+after a review is Done.** A pull request that merged or closed after you marked its review Done, or
+that was noticed by the hourly check or by Check for updates, used to change the card and say
+nothing. It is now in Activity, noting when the review had already been marked Done. A reopened pull
+request is now recorded too. One known gap: a pull request closed, reopened and closed again without
+a new push shows the second close only on its card, not as a second row.
+
+**Activity and Settings keep the bell current.** The Activity page adds new rows and quietens rows
+you read elsewhere while it is on screen, and asks again the moment you switch back to it. The bell
+on Settings now updates as well. Toasts stay to one line, with at most one detail.
+
+**Activity says how much history it keeps.** It keeps the most recent 200 events for up to thirty
+days. On a busy machine the 200 is reached first, so the page now says both rather than promising
+thirty days.
+
+## 0.73.2
+
+**Notifications about a review are marked read while that review is on screen.** Until now,
+opening a review marked its notifications read once, when the page loaded, so anything that arrived
+while you stayed on it, such as "Branch updated" after a commit, kept the bell lit long after you
+had seen it. Now a review page marks its own notifications read whenever it is visible: when it
+loads in front of you, when a tab you left in the background becomes visible again, and as new
+ones arrive while you are looking at it. The bell and the rail update at the same moment.
+
+A review page that is not visible marks nothing. Opening a review in a background tab, or leaving
+one open behind other tabs, keeps its notifications unread until you switch to it. Notifications
+about other reviews are never marked by a review page. This works on a review opened straight from
+a terminal link, too.
+
 ## 0.73.1
 
 **A review's first update says how long updates take.** While an update runs, the page now