@quickchatai/quickreview 1.2.0 → 1.3.2

package/extensions/setup.ts

@@ -57,7 +57,12 @@ import {
 } from "@quickchatai/pi-quickreview/extensions/pi-tool.js";
 import { fileURLToPath } from "node:url";
 import { configHome, stateHome } from "../src/install.js";
-import { SetupEngine, type CutStatus, type CutView } from "../src/setup/engine.js";
+import { SetupEngine } from "../src/setup/engine.js";
+import {
+  renderCut,
+  renderDraft,
+  renderStatus,
+} from "@quickchatai/pi-quickreview/src/scan/cutrender.js";
 import type { HistoryTheme, HistoryThemesFile } from "../src/setup/history.js";
 import {
   HISTORY_SECTIONS,
@@ -154,75 +159,14 @@ export function renderFacts(facts: RepoFacts, head: string | null): string {
   ].join("\n\n");
 }
 
-export function renderCut(title: string, v: CutView): string {
-  const rows = v.units.map((u) => {
-    const split =
-      u.cases === null
-        ? " — case coverage UNKNOWN"
-        : u.cases.length > 1
-          ? ` — split into ${u.cases.length} cases (${u.cases.map((c) => `${c.id}: ${c.files}f/${c.lines}l`).join(", ")})`
-          : "";
-    const over = u.cases?.some((c) => c.over_budget)
-      ? " [a file alone exceeds one case — a scan reads it in line ranges]"
-      : "";
-    return `  - ${u.name} [${u.kind}] ${u.roots.map(displayRoot).join(", ")}: ${u.files ?? "UNKNOWN"} files, ${u.reviewable ?? "UNKNOWN"} reviewable, ${u.lines ?? "UNKNOWN"} lines${split}${over}${u.note ? ` — ${u.note}` : ""}`;
-  });
-  const lines = [`${title}:`, ...rows];
-  if (v.ignored.length > 0)
-    lines.push(`  ignored: ${v.ignored.join(", ")} (${v.ignored_files ?? "UNKNOWN"} files)`);
-  for (const e of v.errors) lines.push(`  ✗ ${e}`);
-  for (const b of v.blocking_save) lines.push(`  ! ${b}`);
-  return lines.join("\n");
-}
-
-/** How a rendering names the save that makes a draft the cut — the tool, or
- * the `qcr scan units` verb. */
-export interface CutVerbs {
-  save: string;
-}
-export const CUT_TOOL_VERBS: CutVerbs = { save: "setup_unit_cut_save" };
-export const CUT_CLI_VERBS: CutVerbs = { save: "qcr scan units save" };
-
-/** A stored or adjusted draft, and that it is not in use until saved. */
-export function renderDraft(
-  title: string,
-  draft: CutView,
-  verbs: CutVerbs = CUT_TOOL_VERBS,
-): string {
-  return `${renderCut(title, draft)}\n\nNot in use until ${verbs.save}.`;
-}
-
-export function renderStatus(s: CutStatus): string {
-  const out: string[] = [];
-  for (const p of s.problems) out.push(`✗ ${p}`);
-  if (s.saved) {
-    const stale =
-      s.saved.blocking_save.length > 0 ? " — STALE against the repo now, see the ! lines" : "";
-    out.push(
-      renderCut(
-        `Saved unit cut (saved ${s.saved.saved_at}${s.saved.head ? ` at ${s.saved.head.slice(0, 12)}` : ""})${stale}`,
-        s.saved,
-      ),
-    );
-  } else if (s.cut_file_unreadable) {
-    out.push(
-      "Saved unit cut: UNKNOWN — the cut file could not be read (see above); nothing will overwrite it.",
-    );
-  } else {
-    out.push("No saved unit cut yet.");
-  }
-  if (s.draft)
-    out.push(
-      renderCut(
-        `Draft (${s.draft.source}, updated ${s.draft.updated_at}) — not in use until saved`,
-        s.draft,
-      ),
-    );
-  if (s.has_previous)
-    out.push("The cut before the saved one is kept as `previous` in the state home.");
-  return out.join("\n\n");
-}
-
+export {
+  CUT_CLI_VERBS,
+  CUT_TOOL_VERBS,
+  renderCut,
+  renderDraft,
+  renderStatus,
+  type CutVerbs,
+} from "@quickchatai/pi-quickreview/src/scan/cutrender.js";
 export function renderThemes(themes: readonly HistoryTheme[]): string {
   return themes.length === 0
     ? "  (none — an empty history has no themes)"

package/extensions/vendor/openviking-pi/NOTICE

@@ -60,6 +60,11 @@ Changed by the quickreviewd maintainers, 2026-08-20:
  12. The extension is a factory over a configuration value; the process's
      environment, argv, working directory and home directory are read once, by
      a shim, and every hook runs under a deadline and a catch (2026-10-19).
+ 13. One turn sync runs at a time per session: a turn that ends while one
+     runs queues its branch, the running sync sends the queued branches in
+     order, each entry sent once by its pi entry id, and agent_end waits for
+     them under turn_end's deadline, so a hook deadline can no longer start a
+     second sync that re-sends the same messages (2026-10-29).
 
 Plus vendoring scaffolding: build-conformance fixes for this repo's stricter
 tsconfig (ambient type declarations while pi was not installed, retired once

package/extensions/vendor/openviking-pi/README.md

@@ -1,7 +1,7 @@
 # openviking-pi — vendored, patched fork
 
 The OpenViking pi extension our sessions load. Vendored, not depended on:
-upstream ships it as an `examples/` directory, not a package, and we need twelve
+upstream ships it as an `examples/` directory, not a package, and we need thirteen
 behaviour changes that upstream has no reason to make.
 
 | | |
@@ -20,7 +20,7 @@ fails on drift between the two.
 
 ## Why a fork rather than configuration
 
-Every one of the twelve patches was tried as configuration first and does not
+Every one of the thirteen patches was tried as configuration first and does not
 exist there. The evidence is a spike against a **running v0.4.15 server plus
 the pinned pi 0.84.1**, with transcripts, kept with the project's design
 records. The short version: several of its findings contradict the OpenViking
@@ -29,12 +29,13 @@ anything here.
 
 ## The patch series
 
-Twelve numbered behaviour patches, applied in order over the vendored upstream
+Thirteen numbered behaviour patches, applied in order over the vendored upstream
 files, plus two unnumbered build patches (0000 scaffolding, 0012 typing). They live in `patches/` as
 `git apply`-able diffs — verified by applying the first thirteen, in order, to a
 pristine `v0.4.15` extraction and diffing the result against this directory:
-byte-identical. (0013 is checked to apply on the tree the first thirteen
-produce; the full pristine-extraction replay has not been re-run with it.) (`patches/` and `upstream.json` are meta and are not themselves
+byte-identical. (0013 and 0014 are checked to apply on the tree the patches
+before them produce; the full pristine-extraction replay has not been re-run
+with them.) (`patches/` and `upstream.json` are meta and are not themselves
 part of the reproduced tree.) Every hunk they add carries a greppable marker:
 
 ```sh
@@ -488,6 +489,39 @@ Touches: `index.ts`, `config.ts`, `sync.ts`, `qcr-leaf.ts`, `qcr-shim.ts`
 (new), `qcr-hooks.ts` (new), `shared/pending-queue.mjs` and `.d.mts`, `NOTICE`,
 this README.
 
+### 0014 — one turn sync in flight per session (`[QCR PATCH 13]`)
+
+The `turn_end` hook runs under a deadline (`qcr-hooks.ts`), and a deadline
+that passes returns without cancelling the hook's work. Upstream's
+`syncBranch` then ran on in the background, and under a slow server the next
+turn started a second sync from the same watermark — which only advances once
+a whole sync has finished. One process sent the same messages to one OV
+session several times at once; the server takes a tree lock per session
+append, so they queued on it, timed out client-side (and were queued for
+replay), and the health probes queued behind them. On the bot it was measured
+at up to five appends in flight to one session from its one worker.
+
+`SyncManager.syncBranch` now runs one sync at a time. A turn that ends while
+one runs queues its branch, in memory and in order; the running sync then
+sends each queued branch in turn, so the process sends nothing twice and
+nothing at once, and a later turn (a branch switch included) never overwrites
+an earlier one. Upstream's watermark is a count of entries, so a queued branch
+as long as the one before it would read as sent; what was sent is now
+remembered by pi's entry ids, and only entries without ids fall back to the
+count. The offline queue on disk is
+not used for this: it is shared by every worker, it collapses identical
+payloads and replays by write time, all of which would reorder or drop turns.
+
+A bot worker disposes its session without `session_shutdown`, so the queued
+turns must go out before the prompt resolves: `agent_end` awaits
+`SyncManager.drain()`, and its deadline in `qcr-hooks.ts` is raised from 1 s
+to turn_end's 30 s. With nothing queued, `drain()` settles at once; with a
+slow server the prompt can resolve up to 30 s later than before. Turns still
+queued when that deadline passes are lost with the worker, as a running sync
+was before this patch; the pi transcript keeps them.
+
+Touches: `sync.ts`, `index.ts`, `qcr-hooks.ts`, `NOTICE`, this README.
+
 ## Rebasing onto a newer upstream
 
 ```sh

package/extensions/vendor/openviking-pi/index.ts

@@ -405,6 +405,10 @@ async function register(pi: ExtensionAPI, cfg: OpenVikingConfig): Promise<void>
   // --- agent_end ---
   pi.on("agent_end", guard("agent_end", async (_event, _ctx) => {
     recall.invalidate();
+    // [QCR PATCH 13] The turns queued behind a slow sync go out before the
+    // prompt resolves, under this hook's deadline: a worker disposes its
+    // session without session_shutdown, so this is the last chance.
+    await sync.drain();
   }));
 
   // ================================================================

package/extensions/vendor/openviking-pi/patches/0014-one-turn-sync-in-flight.patch

@@ -0,0 +1,239 @@
+diff --git a/extensions/vendor/openviking-pi/NOTICE b/extensions/vendor/openviking-pi/NOTICE
+index 15992e4a..1afc0e01 100644
+--- a/extensions/vendor/openviking-pi/NOTICE
++++ b/extensions/vendor/openviking-pi/NOTICE
+@@ -60,6 +60,11 @@ Changed by the quickreviewd maintainers, 2026-08-20:
+  12. The extension is a factory over a configuration value; the process's
+      environment, argv, working directory and home directory are read once, by
+      a shim, and every hook runs under a deadline and a catch (2026-10-19).
++ 13. One turn sync runs at a time per session: a turn that ends while one
++     runs queues its branch, the running sync sends the queued branches in
++     order, each entry sent once by its pi entry id, and agent_end waits for
++     them under turn_end's deadline, so a hook deadline can no longer start a
++     second sync that re-sends the same messages (2026-10-29).
+ 
+ Plus vendoring scaffolding: build-conformance fixes for this repo's stricter
+ tsconfig (ambient type declarations while pi was not installed, retired once
+diff --git a/extensions/vendor/openviking-pi/README.md b/extensions/vendor/openviking-pi/README.md
+index 670e38b2..ca289c2d 100644
+--- a/extensions/vendor/openviking-pi/README.md
++++ b/extensions/vendor/openviking-pi/README.md
+@@ -1,7 +1,7 @@
+ # openviking-pi — vendored, patched fork
+ 
+ The OpenViking pi extension our sessions load. Vendored, not depended on:
+-upstream ships it as an `examples/` directory, not a package, and we need twelve
++upstream ships it as an `examples/` directory, not a package, and we need thirteen
+ behaviour changes that upstream has no reason to make.
+ 
+ | | |
+@@ -20,7 +20,7 @@ fails on drift between the two.
+ 
+ ## Why a fork rather than configuration
+ 
+-Every one of the twelve patches was tried as configuration first and does not
++Every one of the thirteen patches was tried as configuration first and does not
+ exist there. The evidence is a spike against a **running v0.4.15 server plus
+ the pinned pi 0.84.1**, with transcripts, kept with the project's design
+ records. The short version: several of its findings contradict the OpenViking
+@@ -29,12 +29,13 @@ anything here.
+ 
+ ## The patch series
+ 
+-Twelve numbered behaviour patches, applied in order over the vendored upstream
++Thirteen numbered behaviour patches, applied in order over the vendored upstream
+ files, plus two unnumbered build patches (0000 scaffolding, 0012 typing). They live in `patches/` as
+ `git apply`-able diffs — verified by applying the first thirteen, in order, to a
+ pristine `v0.4.15` extraction and diffing the result against this directory:
+-byte-identical. (0013 is checked to apply on the tree the first thirteen
+-produce; the full pristine-extraction replay has not been re-run with it.) (`patches/` and `upstream.json` are meta and are not themselves
++byte-identical. (0013 and 0014 are checked to apply on the tree the patches
++before them produce; the full pristine-extraction replay has not been re-run
++with them.) (`patches/` and `upstream.json` are meta and are not themselves
+ part of the reproduced tree.) Every hunk they add carries a greppable marker:
+ 
+ ```sh
+@@ -488,6 +489,39 @@ Touches: `index.ts`, `config.ts`, `sync.ts`, `qcr-leaf.ts`, `qcr-shim.ts`
+ (new), `qcr-hooks.ts` (new), `shared/pending-queue.mjs` and `.d.mts`, `NOTICE`,
+ this README.
+ 
++### 0014 — one turn sync in flight per session (`[QCR PATCH 13]`)
++
++The `turn_end` hook runs under a deadline (`qcr-hooks.ts`), and a deadline
++that passes returns without cancelling the hook's work. Upstream's
++`syncBranch` then ran on in the background, and under a slow server the next
++turn started a second sync from the same watermark — which only advances once
++a whole sync has finished. One process sent the same messages to one OV
++session several times at once; the server takes a tree lock per session
++append, so they queued on it, timed out client-side (and were queued for
++replay), and the health probes queued behind them. On the bot it was measured
++at up to five appends in flight to one session from its one worker.
++
++`SyncManager.syncBranch` now runs one sync at a time. A turn that ends while
++one runs queues its branch, in memory and in order; the running sync then
++sends each queued branch in turn, so the process sends nothing twice and
++nothing at once, and a later turn (a branch switch included) never overwrites
++an earlier one. Upstream's watermark is a count of entries, so a queued branch
++as long as the one before it would read as sent; what was sent is now
++remembered by pi's entry ids, and only entries without ids fall back to the
++count. The offline queue on disk is
++not used for this: it is shared by every worker, it collapses identical
++payloads and replays by write time, all of which would reorder or drop turns.
++
++A bot worker disposes its session without `session_shutdown`, so the queued
++turns must go out before the prompt resolves: `agent_end` awaits
++`SyncManager.drain()`, and its deadline in `qcr-hooks.ts` is raised from 1 s
++to turn_end's 30 s. With nothing queued, `drain()` settles at once; with a
++slow server the prompt can resolve up to 30 s later than before. Turns still
++queued when that deadline passes are lost with the worker, as a running sync
++was before this patch; the pi transcript keeps them.
++
++Touches: `sync.ts`, `index.ts`, `qcr-hooks.ts`, `NOTICE`, this README.
++
+ ## Rebasing onto a newer upstream
+ 
+ ```sh
+diff --git a/extensions/vendor/openviking-pi/index.ts b/extensions/vendor/openviking-pi/index.ts
+index 8bdc65d9..1b60eeee 100644
+--- a/extensions/vendor/openviking-pi/index.ts
++++ b/extensions/vendor/openviking-pi/index.ts
+@@ -405,6 +405,10 @@ async function register(pi: ExtensionAPI, cfg: OpenVikingConfig): Promise<void>
+   // --- agent_end ---
+   pi.on("agent_end", guard("agent_end", async (_event, _ctx) => {
+     recall.invalidate();
++    // [QCR PATCH 13] The turns queued behind a slow sync go out before the
++    // prompt resolves, under this hook's deadline: a worker disposes its
++    // session without session_shutdown, so this is the last chance.
++    await sync.drain();
+   }));
+ 
+   // ================================================================
+diff --git a/extensions/vendor/openviking-pi/qcr-hooks.ts b/extensions/vendor/openviking-pi/qcr-hooks.ts
+index 8979e729..89d8281c 100644
+--- a/extensions/vendor/openviking-pi/qcr-hooks.ts
++++ b/extensions/vendor/openviking-pi/qcr-hooks.ts
+@@ -32,7 +32,9 @@ export const HOOK_TIMEOUT_MS: Readonly<Record<HookName, number>> = {
+   tool_call: 2_000,
+   turn_end: 30_000,
+   session_shutdown: 5_000,
+-  agent_end: 1_000,
++  // [QCR PATCH 13] agent_end drains the turn syncs queued behind a slow one,
++  // so it gets turn_end's deadline; with nothing queued it returns at once.
++  agent_end: 30_000,
+   command: 15_000,
+ };
+ 
+diff --git a/extensions/vendor/openviking-pi/sync.ts b/extensions/vendor/openviking-pi/sync.ts
+index 037d6306..ddfe651e 100644
+--- a/extensions/vendor/openviking-pi/sync.ts
++++ b/extensions/vendor/openviking-pi/sync.ts
+@@ -38,6 +38,14 @@ export class SyncManager {
+   private syncedEntryCount = 0;
+   private queue: PendingQueueConfig;
+   private debugLog: (message: string) => void;
++  // [QCR PATCH 13] One turn sync in flight per session. A turn that ends
++  // while one runs queues its branch here, in order; the running sync sends
++  // each in turn. `idle` settles when the queue is empty again.
++  private syncing = false;
++  private waiting: any[][] = [];
++  private idle: Promise<void> = Promise.resolve();
++  // [QCR PATCH 13] The ids of the entries already sent (see syncOnce).
++  private sentIds = new Set<string>();
+ 
+   constructor(client: OVClient, config: OVConfig, opts: SyncOptions = {}) {
+     this.client = client;
+@@ -52,6 +60,7 @@ export class SyncManager {
+   restoreWatermark(n: number): void {
+     const next = Math.max(0, Math.floor(Number(n) || 0));
+     this.syncedEntryCount = next;
++    this.sentIds.clear(); // [QCR PATCH 13] the next sync re-seeds from `next`
+   }
+ 
+   /**
+@@ -110,8 +119,54 @@ export class SyncManager {
+     return countUndeliveredForSession(pending, this.ovSessionId) === 0;
+   }
+ 
++  /**
++   * [QCR PATCH 13] The turn_end hook's deadline returns without cancelling
++   * this sync, so under a slow server the next turn used to start a second one
++   * from the same watermark: the same messages went to one session several
++   * times at once and queued on its lock. Now one sync runs at a time. A turn
++   * that ends while it runs queues its branch, and the running sync sends the
++   * queued branches one after another, each from the watermark the one before
++   * it left: nothing is sent twice or at once, and no turn is overwritten by a
++   * later one. `drain()` (awaited at agent_end) waits for the queue to empty.
++   */
+   async syncBranch(branch: any[]): Promise<SyncBranchResult> {
+     if (!this.ovSessionId) return { added: 0, tokens: 0, allDelivered: true };
++    if (this.syncing) {
++      this.waiting.push(branch);
++      return { added: 0, tokens: 0, allDelivered: false };
++    }
++    this.syncing = true;
++    let done!: () => void;
++    this.idle = new Promise<void>((resolve) => (done = resolve));
++    try {
++      const total = await this.syncOnce(branch);
++      for (let next = this.waiting.shift(); next; next = this.waiting.shift()) {
++        const r = await this.syncOnce(next);
++        total.added += r.added;
++        total.tokens += r.tokens;
++        total.allDelivered = total.allDelivered && r.allDelivered;
++      }
++      return total;
++    } finally {
++      this.syncing = false;
++      done();
++    }
++  }
++
++  /** [QCR PATCH 13] Settles once no sync runs and no turn waits for one. */
++  drain(): Promise<void> {
++    return this.idle;
++  }
++
++  private async syncOnce(branch: any[]): Promise<SyncBranchResult> {
++    // [QCR PATCH 13] A queued branch can be as long as the one sent before it
++    // and share none of its entries (a branch switch), so a length watermark
++    // would count its entries as sent. pi gives every entry an id: what was
++    // sent is remembered by id. The watermark below stays for entries without.
++    const ids = branch.map((entry) => entry?.id);
++    if (branch.length > 0 && ids.every((id) => typeof id === "string")) {
++      return this.syncById(branch, ids);
++    }
+ 
+     const extracted = extractBranchCapturePayloads(branch, this.syncedEntryCount, this.config);
+     if (extracted.resetWatermark) this.syncedEntryCount = 0;
+@@ -135,6 +190,31 @@ export class SyncManager {
+     return { added, tokens, allDelivered };
+   }
+ 
++  /** [QCR PATCH 13] Sends each entry of `branch` not sent before, in order. */
++  private async syncById(branch: any[], ids: string[]): Promise<SyncBranchResult> {
++    // A restored watermark counts the branch's first entries as sent.
++    if (this.sentIds.size === 0) {
++      for (const id of ids.slice(0, this.syncedEntryCount)) this.sentIds.add(id);
++    }
++    let added = 0;
++    let tokens = 0;
++    let allDelivered = true;
++    for (const [i, entry] of branch.entries()) {
++      const id = ids[i]!;
++      if (this.sentIds.has(id)) continue;
++      for (const payload of extractBranchCapturePayloads([entry], 0, this.config).payloads) {
++        const result = await this.addPayload(payload);
++        if (!result.accepted) return { added, tokens, allDelivered };
++        added++;
++        tokens += estimatePayloadTokens(payload);
++        allDelivered = allDelivered && result.delivered;
++      }
++      this.sentIds.add(id);
++    }
++    this.syncedEntryCount = branch.length;
++    return { added, tokens, allDelivered };
++  }
++
+   async addPayload(payload: any): Promise<AddPayloadResult> {
+     if (!this.ovSessionId) return { accepted: false, delivered: false };
+     const ok = await this.client.addMessagePayload(this.ovSessionId, payload);

package/extensions/vendor/openviking-pi/qcr-hooks.ts

@@ -32,7 +32,9 @@ export const HOOK_TIMEOUT_MS: Readonly<Record<HookName, number>> = {
   tool_call: 2_000,
   turn_end: 30_000,
   session_shutdown: 5_000,
-  agent_end: 1_000,
+  // [QCR PATCH 13] agent_end drains the turn syncs queued behind a slow one,
+  // so it gets turn_end's deadline; with nothing queued it returns at once.
+  agent_end: 30_000,
   command: 15_000,
 };
 

package/extensions/vendor/openviking-pi/sync.ts

@@ -38,6 +38,14 @@ export class SyncManager {
   private syncedEntryCount = 0;
   private queue: PendingQueueConfig;
   private debugLog: (message: string) => void;
+  // [QCR PATCH 13] One turn sync in flight per session. A turn that ends
+  // while one runs queues its branch here, in order; the running sync sends
+  // each in turn. `idle` settles when the queue is empty again.
+  private syncing = false;
+  private waiting: any[][] = [];
+  private idle: Promise<void> = Promise.resolve();
+  // [QCR PATCH 13] The ids of the entries already sent (see syncOnce).
+  private sentIds = new Set<string>();
 
   constructor(client: OVClient, config: OVConfig, opts: SyncOptions = {}) {
     this.client = client;
@@ -52,6 +60,7 @@ export class SyncManager {
   restoreWatermark(n: number): void {
     const next = Math.max(0, Math.floor(Number(n) || 0));
     this.syncedEntryCount = next;
+    this.sentIds.clear(); // [QCR PATCH 13] the next sync re-seeds from `next`
   }
 
   /**
@@ -110,8 +119,54 @@ export class SyncManager {
     return countUndeliveredForSession(pending, this.ovSessionId) === 0;
   }
 
+  /**
+   * [QCR PATCH 13] The turn_end hook's deadline returns without cancelling
+   * this sync, so under a slow server the next turn used to start a second one
+   * from the same watermark: the same messages went to one session several
+   * times at once and queued on its lock. Now one sync runs at a time. A turn
+   * that ends while it runs queues its branch, and the running sync sends the
+   * queued branches one after another, each from the watermark the one before
+   * it left: nothing is sent twice or at once, and no turn is overwritten by a
+   * later one. `drain()` (awaited at agent_end) waits for the queue to empty.
+   */
   async syncBranch(branch: any[]): Promise<SyncBranchResult> {
     if (!this.ovSessionId) return { added: 0, tokens: 0, allDelivered: true };
+    if (this.syncing) {
+      this.waiting.push(branch);
+      return { added: 0, tokens: 0, allDelivered: false };
+    }
+    this.syncing = true;
+    let done!: () => void;
+    this.idle = new Promise<void>((resolve) => (done = resolve));
+    try {
+      const total = await this.syncOnce(branch);
+      for (let next = this.waiting.shift(); next; next = this.waiting.shift()) {
+        const r = await this.syncOnce(next);
+        total.added += r.added;
+        total.tokens += r.tokens;
+        total.allDelivered = total.allDelivered && r.allDelivered;
+      }
+      return total;
+    } finally {
+      this.syncing = false;
+      done();
+    }
+  }
+
+  /** [QCR PATCH 13] Settles once no sync runs and no turn waits for one. */
+  drain(): Promise<void> {
+    return this.idle;
+  }
+
+  private async syncOnce(branch: any[]): Promise<SyncBranchResult> {
+    // [QCR PATCH 13] A queued branch can be as long as the one sent before it
+    // and share none of its entries (a branch switch), so a length watermark
+    // would count its entries as sent. pi gives every entry an id: what was
+    // sent is remembered by id. The watermark below stays for entries without.
+    const ids = branch.map((entry) => entry?.id);
+    if (branch.length > 0 && ids.every((id) => typeof id === "string")) {
+      return this.syncById(branch, ids);
+    }
 
     const extracted = extractBranchCapturePayloads(branch, this.syncedEntryCount, this.config);
     if (extracted.resetWatermark) this.syncedEntryCount = 0;
@@ -135,6 +190,31 @@ export class SyncManager {
     return { added, tokens, allDelivered };
   }
 
+  /** [QCR PATCH 13] Sends each entry of `branch` not sent before, in order. */
+  private async syncById(branch: any[], ids: string[]): Promise<SyncBranchResult> {
+    // A restored watermark counts the branch's first entries as sent.
+    if (this.sentIds.size === 0) {
+      for (const id of ids.slice(0, this.syncedEntryCount)) this.sentIds.add(id);
+    }
+    let added = 0;
+    let tokens = 0;
+    let allDelivered = true;
+    for (const [i, entry] of branch.entries()) {
+      const id = ids[i]!;
+      if (this.sentIds.has(id)) continue;
+      for (const payload of extractBranchCapturePayloads([entry], 0, this.config).payloads) {
+        const result = await this.addPayload(payload);
+        if (!result.accepted) return { added, tokens, allDelivered };
+        added++;
+        tokens += estimatePayloadTokens(payload);
+        allDelivered = allDelivered && result.delivered;
+      }
+      this.sentIds.add(id);
+    }
+    this.syncedEntryCount = branch.length;
+    return { added, tokens, allDelivered };
+  }
+
   async addPayload(payload: any): Promise<AddPayloadResult> {
     if (!this.ovSessionId) return { accepted: false, delivered: false };
     const ok = await this.client.addMessagePayload(this.ovSessionId, payload);

package/extensions/vendor/openviking-pi/upstream.json

@@ -43,6 +43,7 @@
     "0010-typed-lessons.patch",
     "0011-review-session-memory-boundary.patch",
     "0012-typecheck-against-the-real-pi.patch",
-    "0013-createopenviking-factory.patch"
+    "0013-createopenviking-factory.patch",
+    "0014-one-turn-sync-in-flight.patch"
   ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@quickchatai/quickreview",
-  "version": "1.2.0",
+  "version": "1.3.2",
   "private": false,
   "//private": "The root is the published `qcr` CLI: the whole app (TUI, daemon, companion, every verb), installed with npm, pnpm or bun. It depends on the pi plugin (packages/pi-plugin) at its exact version and on pi at the exact pins below. Publishing is a release step of its own, never part of a build.",
   "description": "A 24/7 AI code reviewer for GitHub: a deterministic daemon driving pi review sessions, with an operator TUI and a local qcr review",
@@ -94,11 +94,10 @@
     "prepack": "npm run build",
     "watch": "node scripts/tsc-watch.mjs -b --watch --preserveWatchOutput",
     "dev": "bash scripts/dev-tui.sh",
-    "onboard": "bash scripts/qcr onboard",
     "test": "vitest run",
     "//canary:pi": "The offline pi canaries (tests/pi-canary/): the real pi SDK at the pinned version on pi-ai's faux provider, so no network and no cost. They also run inside `npm test`; this is the named entry point CI requires whenever the pi dependencies change (a bump is gated by it).",
     "canary:pi": "vitest run tests/pi-canary",
-    "//canary:pi:range": "The same canaries on each pi version the plugin's peer range (packages/pi-plugin/package.json) should hold, refusing one outside it: no argument runs the installed pi; `-- --install 1.4.x` fetches another first (the registry: CI's pi-range matrix runs it in a fresh checkout). Needs the build.",
+    "//canary:pi:range": "The same canaries on each pi version the plugin's peer range (packages/pi-plugin/package.json) should hold, refusing one outside it: no argument runs the installed pi; `-- --install 1.4.x` fetches another first (the registry). Run it by hand before a version joins the peer range; CI runs only the installed pi's canaries. Needs the build.",
     "canary:pi:range": "node scripts/pi-canary-range.mjs",
     "//lint": "Deliberately NOT chained into `test` or `build`: scripts/dev-tui.sh blocks on the build before the TUI paints (ruling 5), and an ESLint pass there is seconds of blank terminal. CI runs it as its own step.",
     "lint": "node --max-old-space-size=4096 node_modules/eslint/bin/eslint.js .",
@@ -116,7 +115,7 @@
   },
   "dependencies": {
     "@earendil-works/pi-ai": "1.4.0",
-    "@quickchatai/pi-quickreview": "1.2.0",
+    "@quickchatai/pi-quickreview": "1.3.2",
     "@earendil-works/pi-coding-agent": "1.4.0",
     "better-sqlite3": "13.0.3",
     "smol-toml": "1.9.1"
@@ -132,6 +131,9 @@
     "vitest": "5.0.5",
     "yaml": "2.9.1"
   },
+  "overrides": {
+    "undici": "8.12.2"
+  },
   "qcrPi": {
     "//": "Named qcrPi, never `pi`: pi reads a package.json `pi` key as a package manifest, and this root is not a pi package (the plugin is packages/pi-plugin). pi and pi-ai are exact dependencies above (types for the extensions, and the VM boot's plain `npm ci` installs them beside the global CLI the image carries). This block is the mirror a bare checkout without config.toml reads: package and version must equal the dependencies, the lockfile, config.toml [pi], ansible group_vars and every Dockerfile ARG (tests/fences.test.ts [T12], tests/docker-daemon.test.ts). Lens sessions run through our own lens tools (src/engine/lens/), not a pi subagent extension, so no extra extension pin exists.",
     "package": "@earendil-works/pi-coding-agent",

package/prompts/onboarding.md

@@ -94,20 +94,21 @@ the own-account route: it is skipped there.
   `onboard_go_live` are marked "after setup": setup finishes without them. Do
   not run them here unless the person asks. Say plainly that the installation
   stays in dry-run (every intended GitHub write is recorded, nothing is
-  posted), and that going live is their decision later: re-run `qcr onboard`
-  and ask for it once a review on the board has shown them what it says.
+  posted), and that going live is their decision later, from the home
+  (Advanced → "Dry-run or live"), once a review has shown them what it says.
 
 ## Finishing
 
 When every setup step reports done (the "after setup" ones need not be), say
 that `finish_and_exit` will re-verify the whole checklist one last time and,
-only if all green, close this session and open the TUI on the board: there they
-select a pull request and press `R` to review it now. If it returns red checks, that is the answer: explain them, fix
+only if all green, close this session: the home then lists the repository's
+pull requests, and they select one and press `alt+r` to review it now. If it
+returns red checks, that is the answer: explain them, fix
 what can be fixed through the step tools, and try again. Never present
 onboarding as finished while anything is red, and never tell the operator to
 quit around a red check.
 
-Before `finish_and_exit`, pass on what comes next: the first review is `R` on
-a pull request on the board; then set up the repo with `qcr setup` (or `I` on
-the TUI board). Until then the reviewer knows nothing about this codebase. It is a
+Before `finish_and_exit`, pass on what comes next: the first review is `alt+r`
+on a pull request in the home; then tune the reviewer to the repository with
+the home's "Tune to this repo" (`t` on the panel). Until then the reviewer knows nothing about this codebase. It is a
 recommendation, once — never start it from here.