prreviewbuddy 0.93.0 → 0.96.0

package/CHANGELOG.md

@@ -1,5 +1,115 @@
 # Changelog
 
+## 0.96.0
+
+**Quick Review.** Press Space on a review in the Reviews list, or choose Quick Review from its menu
+or above the list, to read its brief in a window over the list: why the change exists, how things
+work today and what changes, what it depends on and what depends on it, its issues and questions by
+impact, what needs your decision, and the commit it describes with whether newer commits have
+arrived. J and K scroll, H and L (or the arrow keys) go to the previous and next review in the list
+as filtered and sorted, M opens the review's menu, and Escape returns to the list where you left it.
+Opening a brief calls no model and marks nothing as read or reviewed. The review menu on the list
+moves from Space to M, which the first Quick Review says once, and each control shows its key. Deleting a
+review from its menu in Quick Review keeps Quick Review open on the next review.
+
+**Your outcome.** Record Reviewed: no concerns, Needs changes, Needs a decision / answer, Needs
+deeper review or Later, kept in this workspace only and never sent to the forge. The first three
+also mark the review Reviewed and set the point that "Since your last review" is measured from:
+the new commits, which findings were addressed in code or marked resolved through discussion, what
+is new and what is still open. Needs deeper review and Later are shown beside your verdict and never
+replace it. An outcome recorded on an earlier commit or an earlier analysis of
+the same commit is shown as such, and one recorded against a brief that has since changed is
+refused and the brief refreshed.
+
+**Dependencies.** Stacked pull requests are detected from the base and head repository and branch,
+with unclear cases offered as "Possibly stacked". You can link one review to another, and a
+description that says it depends on a reviewed pull request is offered as a suggestion to confirm
+or dismiss. A stacked branch can be marked Not a dependency, kept on view with what was detected
+and undone, and detected afresh if either branch changes.
+
+**Before and after.** New analyses and updates describe how the code behaves at the base and how
+it behaves after the change. Earlier reviews say this isn't available rather than guessing.
+
+## 0.95.2
+
+`review --no-wait` without `--json` no longer prints advice meant for MCP clients, such as tool
+names, on a review it found rather than started. Whether a found review is still being made is now
+read from the review itself. A resume with nothing to resume says why in its own words.
+
+## 0.95.1
+
+`review --update --no-wait` without `--json` now says what happened to the update. An update that
+ended before the command answered, most often because there was nothing new to reassess, is no
+longer described as started and running in the background: it says how it ended, with the reason.
+A review found already being made says so, and no longer tells you the terminal can be closed.
+
+## 0.95.0
+
+**`review --no-wait` without `--json`.** `--no-wait` now says only whether `review` waits, and
+`--json` only how it answers, so `--no-wait` no longer needs `--json`. On its own it starts the work
+in the background and answers at once with what started, the review ID, the job's state and
+`prreviewbuddy status <review>` to check on it. The analysis carries on after the command exits, so
+the terminal can be closed. A review with a collection option is added to it as soon as the review
+exists, before the analysis starts. `review`, `review --json` and `review --json --no-wait` behave as
+they did. `--no-wait` covers starting, updating and resuming, and is refused with a lens,
+`--reanalyse`, `--delete` and several pull requests at once. A batch with `--json --no-wait`, which
+used to run and wait anyway, is now refused and says why.
+
+## 0.94.3
+
+`review --pr <url> --json --no-wait` now works beside `--collection` and `--new-collection`. The
+review is added as soon as it exists, and the answer comes at once, as `--no-wait` does without a
+collection. Several pull requests still refuse `--no-wait`, now with the real reason: a batch runs
+in the terminal until every review has ended.
+
+## 0.94.2
+
+A single `--pr` with `--json` and a collection option that fails while following the analysis, after
+its review was added, now reports that review and where it went, rather than `no_review`.
+
+## 0.94.1
+
+**`--json` with collections.** `--collection` and `--new-collection` now take `--json`, with or
+without `--also-queue`, for one `--pr` URL or several. The document names the collection (its id,
+its name, and whether this command made it) and, for each pull request, how each destination went,
+including one that ended before it had a review, so an agent can tell what a retry adds. A review
+already there counts as added. The document is written even when a delivery missed and the command
+exits non-zero. Without a collection option, `--json` writes what it did before. The fields are in
+docs/agent-interface.md.
+
+In New review, a collection deleted while its batch runs is now said to be deleted, with a pointer
+to choose another collection, and Open collection is no longer offered for it. **Retry adding**
+appears only when trying again can work: never for the deleted collection, and, when the queue
+missed too, it adds to the queue alone. A queue that misses a deleted review now says the review
+could not be found, rather than that the queue could not be saved. A collection name that is too
+long is refused with "Use at most 60 characters", in the panel and the terminal.
+
+## 0.94.0
+
+**Add a batch of reviews to a collection.** `prreviewbuddy review --pr <url> <url> …` takes
+`--collection "Release review"` to add every review to a collection you have, or
+`--new-collection "Friday batch"` to make the collection and add them to it. A collection is found
+by its name, never by its id. Neither puts the reviews on your review queue; add `--also-queue` for
+that. `--also-queue` needs one of the two, `--queue` beside either is refused with a pointer to
+`--also-queue`, and every combination is checked before anything is reviewed or created. A batch
+without them, or with `--queue` alone, prints and exits as it did. The same options work for a
+single `--pr`.
+
+New review (⌘P P) has **Add to**, in view under the pull requests: **Reviews list only** (as
+before), **Review queue**, any of your collections, or **Create collection…**. For a collection,
+**Also add to review queue** appears, unticked. The choice covers the whole batch. Each review is
+added as soon as it exists, the result counts how many went in, and **Open collection** opens the
+Reviews page on that collection with the new reviews in it. A collection deleted after the panel
+listed it is refused before anything starts, and Add to is drawn again; one renamed meanwhile still
+receives the batch, under its new name.
+
+Retries are safe from both. A review already in the collection or on the queue counts as added, and
+a retry adds only what is missing. When a review misses a destination, the result names it and the
+destination, and why; in the panel, **Retry adding** tries again without running the review. A
+collection the batch created is named in the result, so a retry goes to that same collection: from
+the terminal, with `--collection` and its name. With `--collection` or `--new-collection`, a review
+that missed a destination fails the command.
+
 ## 0.93.0
 
 **Re-check reconciles your findings with the PR discussion.** **Re-check in PR context** used to