prreviewbuddy 0.25.8 → 0.25.13

package/CHANGELOG.md

@@ -1,5 +1,91 @@
 # Changelog
 
+## 0.25.13
+
+**Two updates of the same review no longer run over each other.** Pressing **Update review** on the
+page while `prreviewbuddy review --update` was working on the same review started a second update
+alongside the first. Whichever finished last replaced the other's result without a word, after
+both had spent minutes of agent time.
+
+A second update is now refused while one is running, from wherever it was asked for. On the page,
+the review reloads onto the running update's steps. In the terminal, the command says the review
+is already being updated, gives the link where you can follow it, and exits without changing
+anything. An analysis, a KISS review or a question to the assistant does not block an update.
+
+## 0.25.12
+
+**An update shows what it is doing, in the terminal and on the review.** `prreviewbuddy review
+--update` printed nothing until the reassessment was over, usually minutes after you typed it, and
+the review page showed nothing either. Only the reviews list noticed, and it called the whole update
+"Preparing isolated checkout".
+
+The command now prints the link straight away and then draws the same step list a new review does:
+fetching the latest commits, re-reading the pull request conversation, preparing a checkout of the
+new commits, and reassessing the review, with the agent's own notes under the step that is running.
+Open the link while it works and those steps tick over above the review, which stays readable
+underneath until the update lands. The page refreshes onto the result when it finishes, and the
+reviews list names each step in the same words.
+
+An update that finds no new commits stops after the fetch and says so, without ticking steps it
+never ran. **Update review** on the page now shows the same live steps, where it used to show
+captions guessed from a timer.
+
+`--reanalyse` kept the terminal silent in the same way, for a whole analysis, and now draws its
+progress too.
+
+## 0.25.11
+
+**A review with nothing committed to read now says why, straight away.** Running
+`prreviewbuddy review` on `main` with a dozen edited files said "No changes found to review",
+which looked like a bug to anyone who could see the edits. It now says there are no *committed*
+changes, counts the uncommitted ones (new files included), and explains that PR Review Buddy
+reviews a fixed snapshot of your code, so work that is not committed yet is not included. Then
+it tells you what to do: commit on a branch, or just commit if you are already on one.
+
+The refusal also comes at once. It used to arrive after an isolated checkout had been prepared,
+reported as a paused review that would refuse again every time you tried to carry it on. Nothing
+is created now. A branch that has since been merged still opens the review it already has.
+
+## 0.25.10
+
+**The reviews list now shows what is happening, and keeps showing it.** A review being analysed
+right now, one whose analysis failed, and one that was never analysed all looked the same on the
+list: every card said "No standard review yet". Start a review, go back to the list, and you
+watched nothing happen for three minutes.
+
+A card now says which step an analysis has reached, in the same words the terminal prints, and says
+when one has stopped. It updates on its own, so a review that finishes while you are looking at the
+list fills in its summary, risk and counts without you touching anything. A review started in
+another terminal appears by itself too.
+
+Where a review already has results, they stay put while a new analysis runs over them: a KISS run
+no longer hides the issues you were reading.
+
+The list checks in about once a second while something is being made and once every fifteen when
+nothing is, and it waits rather than refreshing under you if you have rows ticked or are partway
+through typing a search.
+
+## 0.25.9
+
+**Marking a review reviewed shows up straight away on the reviews list.** It used to keep saying
+what it had said before, and catch up some minutes later on its own. Nothing was actually stale:
+the mark is written to disk before the button finishes repainting, and the list is rebuilt from
+those files on every request. The browser simply stopped asking. No page this server sends had
+ever carried a caching rule, so a browser was free to reuse the copy it already had, and pressing
+Back does not reload a page at all: it restores a frozen one from memory, JavaScript variables and
+all, without a single request.
+
+Both doors are shut now, and shut in one place rather than per page. Every response describing a
+review, HTML and JSON alike, says it must not be stored, and that is a property of the two helpers
+that write responses rather than something each route remembers. Every page now reloads itself
+when the browser restores it from history, because a restored page may be stale in any of its
+parts and not only the one that prompted this.
+
+Assets went the other way, which is the arrangement they should always have had. The bundles whose
+filenames carry a content hash, which are most of what a page downloads, may now be kept
+indefinitely: a new build asks for different names. The handful named plainly still check in every
+time, because those names survive an upgrade.
+
 ## 0.25.8
 
 **A review that fails says so, instead of reporting itself as ready.** An analysis that failed

package/dist/main.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import { $ as allJobs, B as BUILD_VERSION, Bt as STORE_ROOT, C as statedWorkspacePort, E as updateReview, F as startJob, Ft as agentIdOf, G as forgeResolver, Gt as detectAgents, Ht as DEFAULT_AGENT_ID, J as MANAGED_ROOT, L as record, Lt as readAgentPreference, Mt as resolveTarget, N as reanalyseReview, Nt as displayRef, P as runJob, Pt as git, Q as checkFreshness, R as recordTelemetryUploadConsent, Rt as writeAgentPreference, St as summarise, Ut as agentById, V as PACKAGE_NAME, Vt as AGENT_IDS, X as removeWorktree, Y as readMarker, a as liveJobsFor, at as progressSteps, b as MIN_WORKSPACE_PORT, bt as reviewedRepositories, ct as followedRefName, dt as lineageKeyFor, f as ensureServer, g as workspaceUrl, h as stopServer, ht as positionInLineage, it as PHASES, j as recordKissRun, l as readIndexToken, lt as groupByLineage, m as reviewsUrl, mt as matchingWorkspaceIds, nt as loadJob, o as wasBlocked, ot as clearClaim, pt as loadWorkspace, r as deleteReview$1, s as runningJobs, st as isClaimed, t as relativeTime, tt as isTerminal, u as bootstrapUrl, v as DEFAULT_WORKSPACE_PORT, vt as recentWorkspaces, w as writePortPreference, x as parseWorkspacePort, xt as saveWorkspace, y as MAX_WORKSPACE_PORT, z as telemetryUploadConsent, zt as CONFIG_PATH } from "./relative_time-D760FOL9.js";
+import { A as liveUpdateFor, B as recordTelemetryUploadConsent, Bt as displayRef, C as writePortPreference, Ct as recentWorkspaces, Dt as summarise, Et as saveWorkspace, F as reanalyseReview, Gt as writeAgentPreference, H as BUILD_VERSION, Ht as agentIdOf, I as runJob, Jt as AGENT_IDS, Kt as CONFIG_PATH, L as startJob, N as recordKissRun, Q as removeWorktree, Qt as detectAgents, S as statedWorkspacePort, T as updateReview, Tt as reviewedRepositories, U as PACKAGE_NAME, V as telemetryUploadConsent, Vt as git, Wt as readAgentPreference, X as MANAGED_ROOT, Xt as agentById, Yt as DEFAULT_AGENT_ID, Z as readMarker, _ as DEFAULT_WORKSPACE_PORT, a as liveJobsFor, at as loadJob, b as parseWorkspacePort, bt as positionInLineage, c as readIndexToken, d as ensureServer, dt as clearClaim, et as checkFreshness, ft as isClaimed, gt as lineageKeyFor, h as workspaceUrl, it as isTerminal, j as runningJobs, k as UpdateAlreadyRunningError, l as bootstrapUrl, lt as progressSteps, m as stopServer, mt as groupByLineage, o as wasBlocked, p as reviewsUrl, pt as followedRefName, q as forgeResolver, qt as STORE_ROOT, r as deleteReview$1, st as PHASES, t as relativeTime, tt as allJobs, ut as purposeOf, v as MAX_WORKSPACE_PORT, vt as loadWorkspace, y as MIN_WORKSPACE_PORT, yt as matchingWorkspaceIds, z as record, zt as resolveTarget } from "./relative_time-vn8Ex9E8.js";
 import { basename, dirname, join, resolve } from "node:path";
 import { spawn } from "node:child_process";
 import { existsSync, mkdirSync, readdirSync, realpathSync, rmSync, statSync, writeFileSync } from "node:fs";
@@ -1267,6 +1267,19 @@ function agentUnusedByResume(agentId) {
 * link. Not rephrased here: an update that stopped early has a specific reason and the reviewer
 * gets the same reason whichever surface asked for it.
 */
+/**
+* Said before the update starts, so the command answers at once and the link is there to open while
+* it works. The same label the creation path uses, because it is the same offer.
+*
+* Not "continues if this terminal closes", which the creation path can say and this cannot: the
+* update runs in this process, so closing the terminal stops it.
+*/
+function startedUpdate(url, acted) {
+	return `${subjectLine(acted)}\nOpen workspace now  ${url}`;
+}
+function updateAlreadyRunning(url, acted) {
+	return `${subjectLine(acted)}\nThis review is already being updated. Follow it here  ${url}`;
+}
 function updateFinished(outcome, url, acted) {
 	return `${subjectLine(acted)}\n${outcome.message}\n${url}`;
 }
@@ -1572,10 +1585,10 @@ var GREEN = "\x1B[32m";
 var RED = "\x1B[31m";
 var RESET = "\x1B[0m";
 /** The header above the phases: what is being reviewed, and the facts about how. */
-function header(target, colour) {
+function header(target, colour, purpose = "review") {
 	const meta = `${target.sha.slice(0, 7)} · isolated checkout · ${target.originRepoPath}`;
 	return [
-		`Reviewing ${target.branch}`,
+		`${purpose === "update" ? "Updating" : "Reviewing"} ${target.branch}`,
 		colour ? `${DIM}${meta}${RESET}` : meta,
 		""
 	];
@@ -1638,7 +1651,7 @@ function followJob(jobId, target, options = {}) {
 	const paint = () => {
 		const job = read(jobId);
 		if (!job) return;
-		const lines = [...header(target, colour), ...phaseLines(job, colour)];
+		const lines = [...header(job.target ?? target, colour, purposeOf(job)), ...phaseLines(job, colour)];
 		const block = lines.join("\n");
 		if (block === last) return;
 		if (inPlace && drawn > 0) stream.write(`\u001b[${drawn}A\u001b[0J`);
@@ -1851,13 +1864,38 @@ async function operate(command, workspace) {
 	if (command.operation === "reanalyse") {
 		const agent = await chooseFor(command, workspace);
 		if (!agent) return 1;
-		await reanalyseReview(workspace.id, agent.id);
+		let stopReanalysis;
+		try {
+			await reanalyseReview(workspace.id, agent.id, (jobId) => {
+				stopReanalysis = follow(jobId);
+			});
+		} finally {
+			stopReanalysis?.();
+		}
 		const port = await ensureServer();
 		out(reanalysed(agent.displayName, linkTo(port, workspace.id, workspace.token), actedOn(workspace)));
 		return 0;
 	}
 	if (command.agentId) err(agentUnusedByUpdate(command.agentId));
-	const outcome = await updateReview(workspace);
+	const url = linkTo(await ensureServer(), workspace.id, workspace.token);
+	if (liveUpdateFor(workspace.id)) {
+		out(updateAlreadyRunning(url, actedOn(workspace)));
+		return 1;
+	}
+	out(startedUpdate(url, actedOn(workspace)));
+	let stopUpdate;
+	let outcome;
+	try {
+		outcome = await updateReview(workspace, { onStarted: (jobId) => {
+			stopUpdate = follow(jobId);
+		} });
+	} catch (error) {
+		if (!(error instanceof UpdateAlreadyRunningError)) throw error;
+		out(updateAlreadyRunning(url, actedOn(workspace)));
+		return 1;
+	} finally {
+		stopUpdate?.();
+	}
 	workspace.lastUpdate = outcome;
 	saveWorkspace(workspace);
 	record({
@@ -1872,10 +1910,23 @@ async function operate(command, workspace) {
 		newIssues: outcome.counts?.newIssues ?? 0,
 		questionsAnswered: outcome.counts?.questionsAnswered ?? 0
 	});
-	out(updateFinished(outcome, linkTo(await ensureServer(), workspace.id, workspace.token), actedOn(workspace)));
+	out(updateFinished(outcome, url, actedOn(workspace)));
 	return 0;
 }
 /**
+* Draw a job's progress block, from what the job itself records about its target.
+*
+* From the record rather than the caller, for the reason `drive` gives: the job knows what it is
+* working on, and a second copy assembled here could disagree with it.
+*/
+function follow(jobId) {
+	return followJob(jobId, loadJob(jobId)?.target ?? {
+		branch: "",
+		sha: "",
+		originRepoPath: ""
+	});
+}
+/**
 * What to call the review an operation acted on.
 *
 * Read off the record rather than off the command, because the two are not the same question. The