prreviewbuddy 0.92.0 → 0.95.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (17) hide show
  1. package/CHANGELOG.md +101 -0
  2. package/dist/main.js +597 -136
  3. package/dist/{mcp_tools-BKPpd9dN.js → mcp_tools-DDbcXys2.js} +1274 -571
  4. package/dist/server.js +317 -413
  5. package/package.json +1 -1
  6. package/static/{chunk-CIJm20ER.js → chunk-CQIPqX7U.js} +1 -1
  7. package/static/chunk-Cs33-tV3.js +1 -0
  8. package/static/{chunk-Ahis0VaG.js → chunk-Cum6sHaC.js} +1 -1
  9. package/static/{chunk-DMxtqzNj.js → chunk-D1LBeOJc.js} +1 -1
  10. package/static/help.js +1 -1
  11. package/static/notifications.js +1 -1
  12. package/static/reviews.js +1 -1
  13. package/static/runs.js +1 -1
  14. package/static/settings.js +1 -1
  15. package/static/shell.css +11 -0
  16. package/static/workspace.js +64 -64
  17. package/static/chunk-DRtin0n-.js +0 -1
package/CHANGELOG.md CHANGED
@@ -1,5 +1,106 @@
1
1
  # Changelog
2
2
 
3
+ ## 0.95.2
4
+
5
+ `review --no-wait` without `--json` no longer prints advice meant for MCP clients, such as tool
6
+ names, on a review it found rather than started. Whether a found review is still being made is now
7
+ read from the review itself. A resume with nothing to resume says why in its own words.
8
+
9
+ ## 0.95.1
10
+
11
+ `review --update --no-wait` without `--json` now says what happened to the update. An update that
12
+ ended before the command answered, most often because there was nothing new to reassess, is no
13
+ longer described as started and running in the background: it says how it ended, with the reason.
14
+ A review found already being made says so, and no longer tells you the terminal can be closed.
15
+
16
+ ## 0.95.0
17
+
18
+ **`review --no-wait` without `--json`.** `--no-wait` now says only whether `review` waits, and
19
+ `--json` only how it answers, so `--no-wait` no longer needs `--json`. On its own it starts the work
20
+ in the background and answers at once with what started, the review ID, the job's state and
21
+ `prreviewbuddy status <review>` to check on it. The analysis carries on after the command exits, so
22
+ the terminal can be closed. A review with a collection option is added to it as soon as the review
23
+ exists, before the analysis starts. `review`, `review --json` and `review --json --no-wait` behave as
24
+ they did. `--no-wait` covers starting, updating and resuming, and is refused with a lens,
25
+ `--reanalyse`, `--delete` and several pull requests at once. A batch with `--json --no-wait`, which
26
+ used to run and wait anyway, is now refused and says why.
27
+
28
+ ## 0.94.3
29
+
30
+ `review --pr <url> --json --no-wait` now works beside `--collection` and `--new-collection`. The
31
+ review is added as soon as it exists, and the answer comes at once, as `--no-wait` does without a
32
+ collection. Several pull requests still refuse `--no-wait`, now with the real reason: a batch runs
33
+ in the terminal until every review has ended.
34
+
35
+ ## 0.94.2
36
+
37
+ A single `--pr` with `--json` and a collection option that fails while following the analysis, after
38
+ its review was added, now reports that review and where it went, rather than `no_review`.
39
+
40
+ ## 0.94.1
41
+
42
+ **`--json` with collections.** `--collection` and `--new-collection` now take `--json`, with or
43
+ without `--also-queue`, for one `--pr` URL or several. The document names the collection (its id,
44
+ its name, and whether this command made it) and, for each pull request, how each destination went,
45
+ including one that ended before it had a review, so an agent can tell what a retry adds. A review
46
+ already there counts as added. The document is written even when a delivery missed and the command
47
+ exits non-zero. Without a collection option, `--json` writes what it did before. The fields are in
48
+ docs/agent-interface.md.
49
+
50
+ In New review, a collection deleted while its batch runs is now said to be deleted, with a pointer
51
+ to choose another collection, and Open collection is no longer offered for it. **Retry adding**
52
+ appears only when trying again can work: never for the deleted collection, and, when the queue
53
+ missed too, it adds to the queue alone. A queue that misses a deleted review now says the review
54
+ could not be found, rather than that the queue could not be saved. A collection name that is too
55
+ long is refused with "Use at most 60 characters", in the panel and the terminal.
56
+
57
+ ## 0.94.0
58
+
59
+ **Add a batch of reviews to a collection.** `prreviewbuddy review --pr <url> <url> …` takes
60
+ `--collection "Release review"` to add every review to a collection you have, or
61
+ `--new-collection "Friday batch"` to make the collection and add them to it. A collection is found
62
+ by its name, never by its id. Neither puts the reviews on your review queue; add `--also-queue` for
63
+ that. `--also-queue` needs one of the two, `--queue` beside either is refused with a pointer to
64
+ `--also-queue`, and every combination is checked before anything is reviewed or created. A batch
65
+ without them, or with `--queue` alone, prints and exits as it did. The same options work for a
66
+ single `--pr`.
67
+
68
+ New review (⌘P P) has **Add to**, in view under the pull requests: **Reviews list only** (as
69
+ before), **Review queue**, any of your collections, or **Create collection…**. For a collection,
70
+ **Also add to review queue** appears, unticked. The choice covers the whole batch. Each review is
71
+ added as soon as it exists, the result counts how many went in, and **Open collection** opens the
72
+ Reviews page on that collection with the new reviews in it. A collection deleted after the panel
73
+ listed it is refused before anything starts, and Add to is drawn again; one renamed meanwhile still
74
+ receives the batch, under its new name.
75
+
76
+ Retries are safe from both. A review already in the collection or on the queue counts as added, and
77
+ a retry adds only what is missing. When a review misses a destination, the result names it and the
78
+ destination, and why; in the panel, **Retry adding** tries again without running the review. A
79
+ collection the batch created is named in the result, so a retry goes to that same collection: from
80
+ the terminal, with `--collection` and its name. With `--collection` or `--new-collection`, a review
81
+ that missed a destination fails the command.
82
+
83
+ ## 0.93.0
84
+
85
+ **Re-check reconciles your findings with the PR discussion.** **Re-check in PR context** used to
86
+ fetch the latest comments and correct who raised what, and leave every issue and question as it
87
+ was until Update or a card's own Reassess ran. It now runs the same discussion pass as Update,
88
+ against the commit the review read: a comment that answers a question answers it, a comment that
89
+ settles an issue resolves it, and a concern a comment raises becomes a new issue once it is
90
+ confirmed in the reviewed code. A claim that something was fixed is never taken on trust, and a
91
+ thread resolved on the forge is not, by itself, a fix: either stays open for Update to check against
92
+ newer commits, which remain Update's job. Reassess on a single card is unchanged.
93
+
94
+ The steps show while it runs (fetching the discussion, preparing the reviewed code, reassessing
95
+ issues and questions), and Cancel stops it. The result says what happened: the findings that
96
+ changed, that no findings changed, or, when the comments were fetched but the reassessment failed,
97
+ that the discussion was refreshed and the findings were not, with **Try again**. When nothing in
98
+ the discussion is new since the findings were last assessed, no model is asked.
99
+
100
+ The discussion counts as analysed only once a Re-check or an Update has finished reassessing it,
101
+ and only as far as it read, so a comment that arrives during a Re-check is still new to the next
102
+ one. A Re-check never stands in for an Update, and the last update's outcome is left as it was.
103
+
3
104
  ## 0.92.0
4
105
 
5
106
  **Older issues catch up on Update.** An issue from an earlier review that is still outstanding now