@nguyenquangthai/pi-todo 0.3.3 → 0.3.5

package/CHANGELOG.md

@@ -1,118 +1,139 @@
-# Changelog
-
-## 0.3.3 (2026-07-16)
-
-### Changed
-
-- **Overlay heading**: Shows open, running, and completed counts. Completed
-  counts include only `completed` todos; `cancelled` todos remain excluded.
-- **Simplified status display**: Removed the ANSI progress bar and `done/total`
-  counter from the overlay.
-- **Documentation and screenshot**: Updated the README, screenshot PNG, and
-  screenshot HTML source to match the new heading.
-
-## 0.3.2 (2026-07-16)
-
-### Fixed
-
-- **Todo ID integrity**: Prevented id-less todos from taking IDs explicitly
-  retained by another todo during a full `todo_write` replacement.
-- **Diagnostics**: Added ID-integrity reporting and `repair_needed` status to
-  `todo_diagnose`.
-- **Mutation bounds**: Capped todo mutations and persisted snapshots at 200
-  items.
-
-## 0.3.1 (2026-07-15)
-
-### Fixed
-
-- **Durable `todo_update` replay**: Replays successful `todo_update` tool results
-  as a fallback when compaction retains tool messages but prunes older custom
-  state entries. Verified in a live Pi `write → update → /compact → /reload →
-  todo_diagnose` lifecycle.
-- **Completion reminders**: Completion and cadence reminders now direct agents
-  to patch known IDs with `todo_update`, rather than unnecessarily replacing
-  the full checklist. A successful update also clears pending intent nudges.
-- **Timeline overlay boundaries**: The overlay preserves checklist order,
-  pins an out-of-view active item, and never renders more than `maxLines`.
-
-## 0.3.0 (2026-07-15)
-
-- **ID invariant hardening**: `validateTodoWrite` rejects items with explicit `id`
-  that doesn't exist in current list. New items must omit `id` (auto-assign).
-- **`ensureTodoIds` tuple matching**: Matches by `(content+status+priority)` first,
-  then by unique content-only. Duplicate-content items get fresh UUIDs instead
-  of risking mis-assignment.
-- **`todo_update` atomicity**: Stale-ctx returns error, real errors propagate,
-  setTodos after appendEntry — matching todo_write guarantees.
-- **Status-first shared sort**: `statusPrioritySort()` extracted and shared by
-  `formatTodoListText` (tool output) and `selectOverlayLayout` (overlay) —
-  in_progress → pending → terminal, regardless of overflow.
-- **Fixed double-count bug**: Terminal items no longer counted in both `+N done`
-  AND `+N more` on overlay overflow.
-- **Lifecycle E2E test**: Write → update → tree → compact → shutdown → restart,
-  verifying stable IDs and status throughout.
-- **125 tests**, typecheck clean, CI green (Node 20 + 22).
-
-## 0.2.9 (2026-07-15)
-
-- **Atomic write ordering**: `setTodos()` happens *after* `pi.appendEntry()`
-  succeeds. If appendEntry throws (stale-ctx or persistence error), the in-memory
-  store is never mutated — no more desync between live state and durable state.
-- **Stale-ctx now returns error**: Instead of silently swallowing "stale after
-  session replacement", the tool returns an error so the LLM knows the write
-  was not committed.
-- **4 atomicity tests**: Mock appendEntry rejects with stale-ctx / persistence
-  errors and asserts store is unchanged. 102/102 tests passing.
-
-## 0.2.8 (2026-07-15)
-
-- **Replay**: revert broken timestamp-based hardening; Pi guarantees getBranch() is chronological, so original last-entry-wins algorithm is correct and simpler.
-- **appendEntry**: only swallow stale-ctx errors; real persistence/disk errors now propagate instead of being silently caught.
-- **Tests**: remove 6 broken mock-timestamp tests that never reflected Pi runtime (timestamp is ISO string, not number). Keep 9 correct persistence roundtrip tests.
-- **Tests**: 96/96 pass, typecheck clean.
-
-## 0.2.7 (2026-07-15)
-
-- Background-color progress bar using ANSI reverse video — theme-driven (accent/muted), no alignment issues.
-- Progress format: done/total with background-color bar.
-- 14 integration tests for write->read->overlay roundtrip.
-
-## 0.2.6 (2026-07-15)
-
-## 0.2.5 (2026-07-15)
-
-- Rework overlay heading: remove progress bar entirely, simplify to count-only.
-- Fix docstring examples to match new heading format.
-- README: update overlay section to remove progress bar mentions.
-
-## 0.2.4 (2026-07-15)
-
-- Priority sorting in overlay (high→medium→low).
-- Progress bar in heading (Unicode blocks).
-- Collapsible completed items (+N done).
-- CI: GitHub Actions (test + typecheck on push, Node 18/20/22).
-- README: npm version, license, CI badges.
-
-## 0.2.3 (2026-07-15)
-
-- Tool rename: todowrite → todo_write, todoread → todo_read (snake_case).
-- renderCall/renderResult polish: accent color for item count.
-- Overlay heading: "X open / Y total" instead of "N todo(s)".
-
-## 0.2.2 (2026-07-15)
-
-- Fix idle reminder text: "Open items still pending" instead of "0 open".
-- Reminder hides for all-terminal lists.
-- completion update reminder copy polish.
-
-## 0.2.1 (2026-07-15)
-
-- First usable release.
-- todo_write, todo_read tools.
-- Overlay with OpenCode-style markers.
-- Persistence via custom entry + toolResult details.
-- Cold start heuristics (multi-step, VI prompts, fix/polish/setup).
-- Completion nudge when user says done.
-- Idle reminder cadence every ~4 turns.
-- State-aware reminder with open items list.
+# Changelog
+
+## 0.3.5 (2026-07-17)
+
+### Fixed
+
+- **Root cause of intermittent `todo_update` ID errors**: LLMs frequently
+  mistype 36-char UUIDs even when IDs are visible in tool output. New todos
+  now get short sequential IDs (`t1`, `t2`, …) that are trivial to copy.
+- **Clearer mismatch errors**: `todo_update` lists current IDs when a patch
+  targets an unknown ID, so the model can self-correct without guessing.
+- Legacy UUID IDs in existing sessions remain valid; only newly assigned IDs
+  use the short format.
+
+## 0.3.4 (2026-07-17)
+
+### Fixed
+
+- **IDs visible in tool text**: `formatPlainTodoLine` and `todo_update` results
+  now include stable IDs so models can copy them for follow-up patches.
+- **`todo_update` guidance**: Description warns that IDs can change after
+  `todo_write`; always `todo_read` before patching when unsure.
+
+## 0.3.3 (2026-07-16)
+
+### Changed
+
+- **Overlay heading**: Shows open, running, and completed counts. Completed
+  counts include only `completed` todos; `cancelled` todos remain excluded.
+- **Simplified status display**: Removed the ANSI progress bar and `done/total`
+  counter from the overlay.
+- **Documentation and screenshot**: Updated the README, screenshot PNG, and
+  screenshot HTML source to match the new heading.
+
+## 0.3.2 (2026-07-16)
+
+### Fixed
+
+- **Todo ID integrity**: Prevented id-less todos from taking IDs explicitly
+  retained by another todo during a full `todo_write` replacement.
+- **Diagnostics**: Added ID-integrity reporting and `repair_needed` status to
+  `todo_diagnose`.
+- **Mutation bounds**: Capped todo mutations and persisted snapshots at 200
+  items.
+
+## 0.3.1 (2026-07-15)
+
+### Fixed
+
+- **Durable `todo_update` replay**: Replays successful `todo_update` tool results
+  as a fallback when compaction retains tool messages but prunes older custom
+  state entries. Verified in a live Pi `write → update → /compact → /reload →
+  todo_diagnose` lifecycle.
+- **Completion reminders**: Completion and cadence reminders now direct agents
+  to patch known IDs with `todo_update`, rather than unnecessarily replacing
+  the full checklist. A successful update also clears pending intent nudges.
+- **Timeline overlay boundaries**: The overlay preserves checklist order,
+  pins an out-of-view active item, and never renders more than `maxLines`.
+
+## 0.3.0 (2026-07-15)
+
+- **ID invariant hardening**: `validateTodoWrite` rejects items with explicit `id`
+  that doesn't exist in current list. New items must omit `id` (auto-assign).
+- **`ensureTodoIds` tuple matching**: Matches by `(content+status+priority)` first,
+  then by unique content-only. Duplicate-content items get fresh UUIDs instead
+  of risking mis-assignment.
+- **`todo_update` atomicity**: Stale-ctx returns error, real errors propagate,
+  setTodos after appendEntry — matching todo_write guarantees.
+- **Status-first shared sort**: `statusPrioritySort()` extracted and shared by
+  `formatTodoListText` (tool output) and `selectOverlayLayout` (overlay) —
+  in_progress → pending → terminal, regardless of overflow.
+- **Fixed double-count bug**: Terminal items no longer counted in both `+N done`
+  AND `+N more` on overlay overflow.
+- **Lifecycle E2E test**: Write → update → tree → compact → shutdown → restart,
+  verifying stable IDs and status throughout.
+- **125 tests**, typecheck clean, CI green (Node 20 + 22).
+
+## 0.2.9 (2026-07-15)
+
+- **Atomic write ordering**: `setTodos()` happens *after* `pi.appendEntry()`
+  succeeds. If appendEntry throws (stale-ctx or persistence error), the in-memory
+  store is never mutated — no more desync between live state and durable state.
+- **Stale-ctx now returns error**: Instead of silently swallowing "stale after
+  session replacement", the tool returns an error so the LLM knows the write
+  was not committed.
+- **4 atomicity tests**: Mock appendEntry rejects with stale-ctx / persistence
+  errors and asserts store is unchanged. 102/102 tests passing.
+
+## 0.2.8 (2026-07-15)
+
+- **Replay**: revert broken timestamp-based hardening; Pi guarantees getBranch() is chronological, so original last-entry-wins algorithm is correct and simpler.
+- **appendEntry**: only swallow stale-ctx errors; real persistence/disk errors now propagate instead of being silently caught.
+- **Tests**: remove 6 broken mock-timestamp tests that never reflected Pi runtime (timestamp is ISO string, not number). Keep 9 correct persistence roundtrip tests.
+- **Tests**: 96/96 pass, typecheck clean.
+
+## 0.2.7 (2026-07-15)
+
+- Background-color progress bar using ANSI reverse video — theme-driven (accent/muted), no alignment issues.
+- Progress format: done/total with background-color bar.
+- 14 integration tests for write->read->overlay roundtrip.
+
+## 0.2.6 (2026-07-15)
+
+## 0.2.5 (2026-07-15)
+
+- Rework overlay heading: remove progress bar entirely, simplify to count-only.
+- Fix docstring examples to match new heading format.
+- README: update overlay section to remove progress bar mentions.
+
+## 0.2.4 (2026-07-15)
+
+- Priority sorting in overlay (high→medium→low).
+- Progress bar in heading (Unicode blocks).
+- Collapsible completed items (+N done).
+- CI: GitHub Actions (test + typecheck on push, Node 18/20/22).
+- README: npm version, license, CI badges.
+
+## 0.2.3 (2026-07-15)
+
+- Tool rename: todowrite → todo_write, todoread → todo_read (snake_case).
+- renderCall/renderResult polish: accent color for item count.
+- Overlay heading: "X open / Y total" instead of "N todo(s)".
+
+## 0.2.2 (2026-07-15)
+
+- Fix idle reminder text: "Open items still pending" instead of "0 open".
+- Reminder hides for all-terminal lists.
+- completion update reminder copy polish.
+
+## 0.2.1 (2026-07-15)
+
+- First usable release.
+- todo_write, todo_read tools.
+- Overlay with OpenCode-style markers.
+- Persistence via custom entry + toolResult details.
+- Cold start heuristics (multi-step, VI prompts, fix/polish/setup).
+- Completion nudge when user says done.
+- Idle reminder cadence every ~4 turns.
+- State-aware reminder with open items list.

package/README.md

@@ -6,7 +6,7 @@
 
 OpenCode-style session todo checklist for the [pi coding agent](https://pi.dev).
 
-Adds `todo_write` / `todo_update` / `todo_read` / `todo_diagnose`, a live `# Todos` overlay above the editor (`[ ]` / `[•]` / `[✓]` / `[×]`), and branch-replay persistence (survives `/reload`, tree nav, and custom-entry durability across compaction).
+Adds `todo_write` / `todo_update` / `todo_read` / `todo_diagnose`, a live `# Todos` overlay above the editor (`[ ]` / `[•]` / `[✓]` / `[×]`), and branch-replay persistence (survives `/reload`, tree nav, and custom-entry durability across compaction).
 
 ## Install
 
@@ -45,35 +45,35 @@ Rules enforced by the tool:
 - Exactly **one** `in_progress` allowed (hard reject if more)
 - `content` required (non-empty after sanitize); max **500** chars (longer values truncated)
 - `priority` required: `high` | `medium` | `low`
-- Status: `pending` | `in_progress` | `completed` | `cancelled`
-- **ID rule:** omit `id` for a new item; the system assigns it. Only include an ID returned by `todo_read` when retaining an existing item. Never invent an ID. Replacing the list does not inherently reset IDs: matching existing items can retain them.
-- For changed, repeated, or long/truncated content, include the exact existing ID rather than relying on automatic content matching.
-- Do not call `todo_write` and a `todo_update` that needs its IDs in the same parallel batch. Wait for the write result, then use returned IDs or call `todo_read`.
-- A mutation can contain at most **200** todos/updates.
-- Array order is the workflow timeline. Keep existing positions when statuses change; only add or reorder items intentionally.
+- Status: `pending` | `in_progress` | `completed` | `cancelled`
+- **ID rule:** omit `id` for a new item; the system assigns a short sequential ID (`t1`, `t2`, …). Only include an ID returned by `todo_read` when retaining an existing item. Never invent an ID. Replacing the list does not inherently reset IDs: matching existing items can retain them.
+- For changed, repeated, or long/truncated content, include the exact existing ID rather than relying on automatic content matching.
+- Do not call `todo_write` and a `todo_update` that needs its IDs in the same parallel batch. Wait for the write result, then use returned IDs or call `todo_read`.
+- A mutation can contain at most **200** todos/updates.
+- Array order is the workflow timeline. Keep existing positions when statuses change; only add or reorder items intentionally.
 - Tool text echo caps at **40** lines (`+N more` in the text body; full list still in `details` / JSON)
 
-### `todo_update`
-
-Patch existing todos by stable ID without replacing the list or changing its order. `id` is required, must be a non-empty string, and must match a current todo; use `todo_read` first to obtain it. This tool never deletes items.
-
-If an older session returns a todo without `id`, it cannot be patched with `todo_update`. Call `todo_write` with that item but omit `id` to assign one, then use `todo_update` normally.
-
-```json
-{
-  "updates": [
-    { "id": "existing-todo-id", "status": "completed" }
-  ]
-}
-```
-
-### `todo_read`
-
-Returns the current list as text + JSON. Prefer the overlay for at-a-glance status; use it to obtain stable IDs before `todo_update`, and avoid calling it in the same parallel batch as a todo mutation.
-
-### `todo_diagnose`
-
-Read-only persistence check for suspected reload, tree-navigation, or compaction drift. It compares the live in-memory snapshot against a replay of the durable session branch and reports `consistent`, `mismatch`, or `repair_needed` when duplicate/missing IDs are found; it never changes todos.
+### `todo_update`
+
+Patch existing todos by short stable ID (`t1`, `t2`, …) without replacing the list or changing its order. `id` is required, must be a non-empty string, and must match a current todo exactly; use `todo_read` (or the IDs shown in the last write/update text) first. This tool never deletes items.
+
+If an older session returns a todo without `id`, it cannot be patched with `todo_update`. Call `todo_write` with that item but omit `id` to assign one, then use `todo_update` normally.
+
+```json
+{
+  "updates": [
+    { "id": "t1", "status": "completed" }
+  ]
+}
+```
+
+### `todo_read`
+
+Returns the current list as text + JSON. Prefer the overlay for at-a-glance status; use it to obtain stable IDs before `todo_update`, and avoid calling it in the same parallel batch as a todo mutation.
+
+### `todo_diagnose`
+
+Read-only persistence check for suspected reload, tree-navigation, or compaction drift. It compares the live in-memory snapshot against a replay of the durable session branch and reports `consistent`, `mismatch`, or `repair_needed` when duplicate/missing IDs are found; it never changes todos.
 
 ## Overlay
 
@@ -81,16 +81,16 @@ Shown above the editor while any **open** todo remains (`pending` / `in_progress
 
 Hidden when the list is empty or every item is `completed` / `cancelled`.
 
-Heading shows open, running, and completed counts, e.g. `# Todos (3 open, 1 running, 1 completed)`:
-
-- **open** = `pending` + `in_progress`
-- **running** = `in_progress` only (0 or 1 after a valid write)
-- **completed** = `completed` only; `cancelled` todos are not counted
-
-Items always stay in the array's workflow order; status changes only their marker/color.
-When space is tight, the overlay shows the earliest checklist items and `+N more`. If the active item is outside that prefix, it is repeated as `Active: [•] …` rather than moved ahead of earlier work.
-A blank line separates the heading from the first todo row for visual breathing room.
-Successful `todo_write` and `todo_update` results display `✓ Saved`, meaning the durable checkpoint was accepted before the in-memory snapshot was updated.
+Heading shows open, running, and completed counts, e.g. `# Todos (3 open, 1 running, 1 completed)`:
+
+- **open** = `pending` + `in_progress`
+- **running** = `in_progress` only (0 or 1 after a valid write)
+- **completed** = `completed` only; `cancelled` todos are not counted
+
+Items always stay in the array's workflow order; status changes only their marker/color.
+When space is tight, the overlay shows the earliest checklist items and `+N more`. If the active item is outside that prefix, it is repeated as `Active: [•] …` rather than moved ahead of earlier work.
+A blank line separates the heading from the first todo row for visual breathing room.
+Successful `todo_write` and `todo_update` results display `✓ Saved`, meaning the durable checkpoint was accepted before the in-memory snapshot was updated.
 
 ## Development
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nguyenquangthai/pi-todo",
-  "version": "0.3.3",
+  "version": "0.3.5",
   "description": "OpenCode-like session todo checklist for the pi coding agent — todowrite/todoread with a live TUI overlay",
   "type": "module",
   "author": "QuangThai",

package/src/format.ts

@@ -1,8 +1,8 @@
 import type { Theme } from "@earendil-works/pi-coding-agent";
 import { truncateToWidth } from "@earendil-works/pi-tui";
-import type { TodoItem, TodoStatus } from "./types.js";
-import { MAX_OVERLAY_LINES, MAX_RESULT_LINES } from "./types.js";
-import { countCompletedTodos, countOpenTodos, countRunningTodos, hasOpenTodos } from "./validate.js";
+import type { TodoItem, TodoStatus } from "./types.js";
+import { MAX_OVERLAY_LINES, MAX_RESULT_LINES } from "./types.js";
+import { countCompletedTodos, countOpenTodos, countRunningTodos, hasOpenTodos } from "./validate.js";
 
 
 export function getTodoMarker(status: TodoStatus): string {
@@ -19,22 +19,23 @@ export function getTodoMarker(status: TodoStatus): string {
 }
 
 export function formatPlainTodoLine(todo: TodoItem): string {
-  return `${getTodoMarker(todo.status)} ${todo.content}`;
+  const prefix = todo.id ? `${todo.id} ` : "";
+  return `${getTodoMarker(todo.status)} ${prefix}${todo.content}`;
 }
 
 /** Compact checklist for tool responses; caps lines to keep LLM context small. */
 export function formatTodoListText(todos: readonly TodoItem[], summary: string): string {
   if (todos.length === 0) return summary;
 
-  // The list is a workflow timeline. Never reshuffle completed work after the
-  // next task just because its status changed.
-  const ordered = [...todos];
+  // The list is a workflow timeline. Never reshuffle completed work after the
+  // next task just because its status changed.
+  const ordered = [...todos];
 
   if (todos.length <= MAX_RESULT_LINES) {
-    return [summary, ...ordered.map(formatPlainTodoLine)].join("\n");
+    return [summary, ...ordered.map(formatPlainTodoLine)].join("\n");
   }
-  const shown = ordered.slice(0, MAX_RESULT_LINES);
-  const hidden = ordered.length - MAX_RESULT_LINES;
+  const shown = ordered.slice(0, MAX_RESULT_LINES);
+  const hidden = ordered.length - MAX_RESULT_LINES;
   return [
     summary,
     ...shown.map(formatPlainTodoLine),
@@ -58,58 +59,58 @@ export function shouldShowOverlay(todos: readonly TodoItem[]): boolean {
   return hasOpenTodos(todos);
 }
 
-export interface OverlayLayout {
-  visible: TodoItem[];
-  /** Active item repeated below the timeline when it is outside the visible prefix. */
-  pinnedActive?: TodoItem;
-  hiddenCount: number;
-  /** Retained for consumers of the layout API; terminal items are no longer regrouped. */
-  terminalCount: number;
-}
-
-/**
- * Fit the checklist timeline into the overlay without sorting by status or
- * priority. When the active task falls outside the visible prefix, repeat it
- * as a pinned "Active:" row rather than moving it ahead of earlier work.
- */
+export interface OverlayLayout {
+  visible: TodoItem[];
+  /** Active item repeated below the timeline when it is outside the visible prefix. */
+  pinnedActive?: TodoItem;
+  hiddenCount: number;
+  /** Retained for consumers of the layout API; terminal items are no longer regrouped. */
+  terminalCount: number;
+}
+
+/**
+ * Fit the checklist timeline into the overlay without sorting by status or
+ * priority. When the active task falls outside the visible prefix, repeat it
+ * as a pinned "Active:" row rather than moving it ahead of earlier work.
+ */
 export function selectOverlayLayout(
   todos: readonly TodoItem[],
-  maxLines: number = MAX_OVERLAY_LINES,
-): OverlayLayout {
-  if (!shouldShowOverlay(todos)) {
-    return { visible: [], hiddenCount: 0, terminalCount: 0 };
+  maxLines: number = MAX_OVERLAY_LINES,
+): OverlayLayout {
+  if (!shouldShowOverlay(todos)) {
+    return { visible: [], hiddenCount: 0, terminalCount: 0 };
+  }
+
+  const bodyBudget = Math.max(1, maxLines - 1);
+  if (todos.length <= bodyBudget) {
+    // All fit — show the canonical checklist sequence unchanged.
+    return { visible: [...todos], hiddenCount: 0, terminalCount: 0 };
   }
 
-  const bodyBudget = Math.max(1, maxLines - 1);
-  if (todos.length <= bodyBudget) {
-    // All fit — show the canonical checklist sequence unchanged.
-    return { visible: [...todos], hiddenCount: 0, terminalCount: 0 };
-  }
-
-  const active = todos.find((todo) => todo.status === "in_progress");
-  // Reserve one row for the overflow summary. If the active task lies outside
-  // the timeline prefix, reserve another row to pin it without reordering.
-  let visibleCapacity = Math.max(0, bodyBudget - 1);
-  let visible = todos.slice(0, visibleCapacity);
-  let pinnedActive = active && !visible.includes(active) ? active : undefined;
-
-  if (pinnedActive) {
-    visibleCapacity = Math.max(0, bodyBudget - 2);
-    visible = todos.slice(0, visibleCapacity);
-    pinnedActive = active;
-  }
-
-  const hiddenCount = todos.length - visible.length - (pinnedActive ? 1 : 0);
-  return { visible, pinnedActive, hiddenCount, terminalCount: 0 };
+  const active = todos.find((todo) => todo.status === "in_progress");
+  // Reserve one row for the overflow summary. If the active task lies outside
+  // the timeline prefix, reserve another row to pin it without reordering.
+  let visibleCapacity = Math.max(0, bodyBudget - 1);
+  let visible = todos.slice(0, visibleCapacity);
+  let pinnedActive = active && !visible.includes(active) ? active : undefined;
+
+  if (pinnedActive) {
+    visibleCapacity = Math.max(0, bodyBudget - 2);
+    visible = todos.slice(0, visibleCapacity);
+    pinnedActive = active;
+  }
+
+  const hiddenCount = todos.length - visible.length - (pinnedActive ? 1 : 0);
+  return { visible, pinnedActive, hiddenCount, terminalCount: 0 };
 }
 
 export interface RenderOverlayOptions {
   maxLines?: number;
 }
 
-/**
- * The overlay is hidden when no work remains open.
- */
+/**
+ * The overlay is hidden when no work remains open.
+ */
 export function renderOverlayLines(
   todos: readonly TodoItem[],
   theme: Theme,
@@ -118,33 +119,33 @@ export function renderOverlayLines(
 ): string[] {
   if (!shouldShowOverlay(todos)) return [];
 
-  const maxLines = Math.max(1, options.maxLines ?? MAX_OVERLAY_LINES);
-  const truncate = (line: string) => truncateToWidth(line, width, "…");
-  const open = countOpenTodos(todos);
-  const running = countRunningTodos(todos);
-  const completed = countCompletedTodos(todos);
-  const heading = truncate(
-    theme.fg("accent", theme.bold("# Todos")) +
-      theme.fg("dim", ` (${open} open, ${running} running, ${completed} completed)`),
-  );
-
+  const maxLines = Math.max(1, options.maxLines ?? MAX_OVERLAY_LINES);
+  const truncate = (line: string) => truncateToWidth(line, width, "…");
+  const open = countOpenTodos(todos);
+  const running = countRunningTodos(todos);
+  const completed = countCompletedTodos(todos);
+  const heading = truncate(
+    theme.fg("accent", theme.bold("# Todos")) +
+      theme.fg("dim", ` (${open} open, ${running} running, ${completed} completed)`),
+  );
+
   // Small gap between heading and first row — budget -1 to account for the blank line
   const layout = selectOverlayLayout(todos, Math.max(3, maxLines - 1));
   const lines: string[] = [heading, ""];
 
-  for (const todo of layout.visible) {
-    lines.push(truncate(formatThemedTodoLine(todo, theme)));
-  }
-  if (layout.pinnedActive) {
-    lines.push(
-      truncate(theme.fg("warning", `Active: ${formatPlainTodoLine(layout.pinnedActive)}`)),
-    );
-  }
+  for (const todo of layout.visible) {
+    lines.push(truncate(formatThemedTodoLine(todo, theme)));
+  }
+  if (layout.pinnedActive) {
+    lines.push(
+      truncate(theme.fg("warning", `Active: ${formatPlainTodoLine(layout.pinnedActive)}`)),
+    );
+  }
   if (layout.hiddenCount > 0) {
     lines.push(truncate(theme.fg("dim", `+${layout.hiddenCount} more`)));
   }
-  lines.push("");
-  // Layout reserves content rows, but the heading and trailing spacer are
-  // rendered here. Enforce the public maxLines contract at the final boundary.
-  return lines.slice(0, maxLines);
-}
+  lines.push("");
+  // Layout reserves content rows, but the heading and trailing spacer are
+  // rendered here. Enforce the public maxLines contract at the final boundary.
+  return lines.slice(0, maxLines);
+}

package/src/prompt.ts

@@ -1,86 +1,86 @@
-export const TODOWRITE_DESCRIPTION = `Create and maintain a structured task list for the current coding session. Tracks progress, organizes multi-step work, and surfaces status in an overlay above the editor.
-
-## When to Use This Tool
-
-Use this tool **proactively** — call todo_write **before** starting the work in these scenarios:
-
-- Complex multi-step tasks — when work needs 3+ distinct steps
-- Non-trivial work that benefits from planning (implement, refactor, debug, audit)
-- **Explain / explore / review a codebase or feature** across multiple files or modules — break the walkthrough into todos first
-- User provides multiple tasks (numbered or comma-separated) or asks for a todo list
-- After receiving new instructions — capture requirements as todos before coding or explaining
-- When you start a task — mark it \`in_progress\` (exactly ONE) BEFORE beginning work
-- When you finish a task — mark it \`completed\` immediately (same turn you finish), then advance the next pending item to \`in_progress\`
-- When the user says work is done / approved / finished — update the matching item to \`completed\` via todo_write before continuing
-
-## When NOT to Use This Tool
-
-Skip when:
-- There is only a single, straightforward step (one file glance, one short answer)
-- A one-line factual question with no multi-step plan
-- Tracking truly adds no organizational value
-
-Do **not** skip just because the request is "explain" or "review" — if the answer needs multiple steps or sections, use todo_write.
-
-## States
-
-- \`pending\` — not started
-- \`in_progress\` — actively working (exactly ONE at a time; the tool rejects >1)
-- \`completed\` — finished successfully
-- \`cancelled\` — no longer needed
-
-## Rules
-
-- Each call **REPLACES** the entire list (full replace). Always pass the complete todos array.
-  - **ID rule:** omit \`id\` for every new item — the system assigns it. Only preserve an \`id\` returned by \`todo_read\` for an item that already exists; never invent an ID. For changed, repeated, or long/truncated content, preserve the exact existing ID instead of relying on content matching. Full replacement does not inherently reset IDs: matching existing items can retain them.
-  - Do not call \`todo_write\` and a dependent \`todo_update\` in the same parallel batch. Complete the write, then use its returned IDs (or \`todo_read\`) for the update.
-- Update status in real time; don't batch completions across multiple finished steps.
-- Mark \`completed\` only after the work is actually done (including verification) — never on intent alone.
-- Keep exactly one \`in_progress\` while actively working. Never leave a stale \`in_progress\` after that step is finished.
-- When using \`todo_write\`, after marking an item \`completed\`, set the next actionable item to \`in_progress\` in the same full-replace call when you are continuing.
-- Array order is the workflow timeline. Preserve existing item positions as statuses change; add or reorder items only deliberately.
-- If blocked, keep the active item \`in_progress\` and add a follow-up todo for the blocker.
-- Items should be specific and actionable.
-- Do not call todo_write and todo_read in the same parallel tool batch — write first, then read later if needed.
-- Prefer the live overlay for status; use todo_read only when you need the JSON snapshot.`;
-
-export const TODOREAD_DESCRIPTION =
-  "Read the current session todo list. Returns JSON of all todos with status, priority, and stable IDs. Prefer the overlay for at-a-glance status; call after todo_write settles (not in the same parallel batch). A legacy item without an ID cannot be patched by todo_update; rewrite it with todo_write and omit id to assign one.";
-
-export const TODODIAGNOSE_DESCRIPTION =
-  "Read-only persistence diagnostic. Compares the current in-memory todo snapshot with the durable session-branch replay. Use only to investigate suspected reload, tree-navigation, or compaction state drift; it never changes todos.";
-
-export const TODOWRITE_GUIDELINES = [
-  "For multi-step work (3+ steps), codebase explain/explore/review, or when the user gives a list of tasks, call todo_write BEFORE starting — do not skip tracking.",
-  "Pass the full list every todo_write call (full replace). Keep exactly one todo in_progress; mark completed immediately when a step finishes — never leave a stale in_progress.",
-  "ID rule: for todo_write, omit id for new items so the system assigns one. Supply an id only to preserve an existing item, using the exact ID from todo_read; never invent IDs. For changed, repeated, or long/truncated content, preserve that exact ID rather than relying on content matching. For todo_update, id is required and must match a current todo.",
-  "Never call todo_write and a todo_update that depends on its IDs in the same parallel batch. Wait for todo_write to finish, then use its returned IDs or call todo_read. If todo_read shows a legacy item without id, rewrite it with todo_write and omit id to assign one before using todo_update.",
-  "When finishing a step or when the user confirms done, use todo_update for an ID-based patch when possible; use todo_write only when replacing the full checklist. Advance the next pending item in the same mutation if work continues.",
-  "Treat todo array order as the workflow timeline: preserve positions when updating statuses, and only add or reorder items intentionally.",
-  "Use todo_write for full replacement and todo_update for ID-based patches; todo_read exposes IDs and todo_diagnose is read-only troubleshooting.",
-  "Do not call todo_write and todo_read in the same parallel tool batch.",
-];
-
-/**
- * Appended to the system prompt on every agent start (pi-todotools pattern).
- * Fixes cold-start: tool description alone is easy for models to ignore.
- * Keep short — token cost every turn.
- */
-export const TASK_MANAGEMENT_SECTION = `
-<Task_Management>
-todo_write/todo_update/todo_read are the coordination layer for multi-step work. Use todo_write for the initial/full checklist and todo_update for a targeted patch by stable ID. In todo_write, omit id for new items; only retain an exact ID returned by todo_read for an existing item. In todo_update, id is required and must match a current todo. Do not call a write and an update that depends on its IDs in the same parallel batch: wait for the write result first. The TUI overlay only appears after a todo mutation — without it the user cannot see plan/progress.
-
-Required cold start: for explain/explore/review/implement/refactor/audit/debug/fix/polish/setup of a codebase, feature, UI, or multi-file ask — your FIRST tool call must be todo_write with a short checklist (WHAT/WHERE), exactly one in_progress, then continue. Do not start with read/bash/search alone on those asks.
-
-Ongoing: mark completed immediately when a step finishes; use todo_update for a targeted ID-based patch or todo_write for a full replacement. Advance the next pending item in the same mutation; when the user says done/approved, update that turn.
-
-Skip only single trivial Q&A (one short fact, greeting). Multi-step Vietnamese or English asks (giải thích, chỉnh, bổ sung, help me, …) still need todos first.
-</Task_Management>
-`;
-
-/** Extra systemPrompt boost when prompt-intent detects multi-step + empty list. */
-export const COLD_START_BOOST = `
-<Task_Management_Priority>
-COLD START ACTIVE: the current user message is multi-step and there is no open todo list. Call todo_write before any other tool. Prefer 3–8 concrete checklist items. Keep exactly one in_progress.
-</Task_Management_Priority>
-`;
+export const TODOWRITE_DESCRIPTION = `Create and maintain a structured task list for the current coding session. Tracks progress, organizes multi-step work, and surfaces status in an overlay above the editor.
+
+## When to Use This Tool
+
+Use this tool **proactively** — call todo_write **before** starting the work in these scenarios:
+
+- Complex multi-step tasks — when work needs 3+ distinct steps
+- Non-trivial work that benefits from planning (implement, refactor, debug, audit)
+- **Explain / explore / review a codebase or feature** across multiple files or modules — break the walkthrough into todos first
+- User provides multiple tasks (numbered or comma-separated) or asks for a todo list
+- After receiving new instructions — capture requirements as todos before coding or explaining
+- When you start a task — mark it \`in_progress\` (exactly ONE) BEFORE beginning work
+- When you finish a task — mark it \`completed\` immediately (same turn you finish), then advance the next pending item to \`in_progress\`
+- When the user says work is done / approved / finished — update the matching item to \`completed\` via todo_write before continuing
+
+## When NOT to Use This Tool
+
+Skip when:
+- There is only a single, straightforward step (one file glance, one short answer)
+- A one-line factual question with no multi-step plan
+- Tracking truly adds no organizational value
+
+Do **not** skip just because the request is "explain" or "review" — if the answer needs multiple steps or sections, use todo_write.
+
+## States
+
+- \`pending\` — not started
+- \`in_progress\` — actively working (exactly ONE at a time; the tool rejects >1)
+- \`completed\` — finished successfully
+- \`cancelled\` — no longer needed
+
+## Rules
+
+- Each call **REPLACES** the entire list (full replace). Always pass the complete todos array.
+  - **ID rule:** omit \`id\` for every new item — the system assigns a short ID (\`t1\`, \`t2\`, …). Only preserve an \`id\` returned by \`todo_read\` for an item that already exists; never invent an ID. For changed, repeated, or long/truncated content, preserve the exact existing ID instead of relying on content matching. Full replacement does not inherently reset IDs: matching existing items can retain them.
+  - Do not call \`todo_write\` and a dependent \`todo_update\` in the same parallel batch. Complete the write, then use its returned IDs (or \`todo_read\`) for the update.
+- Update status in real time; don't batch completions across multiple finished steps.
+- Mark \`completed\` only after the work is actually done (including verification) — never on intent alone.
+- Keep exactly one \`in_progress\` while actively working. Never leave a stale \`in_progress\` after that step is finished.
+- When using \`todo_write\`, after marking an item \`completed\`, set the next actionable item to \`in_progress\` in the same full-replace call when you are continuing.
+- Array order is the workflow timeline. Preserve existing item positions as statuses change; add or reorder items only deliberately.
+- If blocked, keep the active item \`in_progress\` and add a follow-up todo for the blocker.
+- Items should be specific and actionable.
+- Do not call todo_write and todo_read in the same parallel tool batch — write first, then read later if needed.
+- Prefer the live overlay for status; use todo_read only when you need the JSON snapshot.`;
+
+export const TODOREAD_DESCRIPTION =
+  "Read the current session todo list. Returns JSON of all todos with status, priority, and stable IDs. Prefer the overlay for at-a-glance status; call after todo_write settles (not in the same parallel batch). A legacy item without an ID cannot be patched by todo_update; rewrite it with todo_write and omit id to assign one.";
+
+export const TODODIAGNOSE_DESCRIPTION =
+  "Read-only persistence diagnostic. Compares the current in-memory todo snapshot with the durable session-branch replay. Use only to investigate suspected reload, tree-navigation, or compaction state drift; it never changes todos.";
+
+export const TODOWRITE_GUIDELINES = [
+  "For multi-step work (3+ steps), codebase explain/explore/review, or when the user gives a list of tasks, call todo_write BEFORE starting — do not skip tracking.",
+  "Pass the full list every todo_write call (full replace). Keep exactly one todo in_progress; mark completed immediately when a step finishes — never leave a stale in_progress.",
+  "ID rule: for todo_write, omit id for new items so the system assigns a short ID (t1, t2, …). Supply an id only to preserve an existing item, using the exact ID from todo_read; never invent IDs. For changed, repeated, or long/truncated content, preserve that exact ID rather than relying on content matching. For todo_update, id is required and must match a current todo.",
+  "Never call todo_write and a todo_update that depends on its IDs in the same parallel batch. Wait for todo_write to finish, then use its returned IDs or call todo_read. If todo_read shows a legacy item without id, rewrite it with todo_write and omit id to assign one before using todo_update.",
+  "When finishing a step or when the user confirms done, use todo_update for an ID-based patch when possible; use todo_write only when replacing the full checklist. Advance the next pending item in the same mutation if work continues.",
+  "Treat todo array order as the workflow timeline: preserve positions when updating statuses, and only add or reorder items intentionally.",
+  "Use todo_write for full replacement and todo_update for ID-based patches; todo_read exposes IDs and todo_diagnose is read-only troubleshooting.",
+  "Do not call todo_write and todo_read in the same parallel tool batch.",
+];
+
+/**
+ * Appended to the system prompt on every agent start (pi-todotools pattern).
+ * Fixes cold-start: tool description alone is easy for models to ignore.
+ * Keep short — token cost every turn.
+ */
+export const TASK_MANAGEMENT_SECTION = `
+<Task_Management>
+todo_write/todo_update/todo_read are the coordination layer for multi-step work. Use todo_write for the initial/full checklist and todo_update for a targeted patch by stable ID. In todo_write, omit id for new items (system assigns t1, t2, …); only retain an exact ID returned by todo_read for an existing item. In todo_update, id is required and must match a current todo. Do not call a write and an update that depends on its IDs in the same parallel batch: wait for the write result first. The TUI overlay only appears after a todo mutation — without it the user cannot see plan/progress.
+
+Required cold start: for explain/explore/review/implement/refactor/audit/debug/fix/polish/setup of a codebase, feature, UI, or multi-file ask — your FIRST tool call must be todo_write with a short checklist (WHAT/WHERE), exactly one in_progress, then continue. Do not start with read/bash/search alone on those asks.
+
+Ongoing: mark completed immediately when a step finishes; use todo_update for a targeted ID-based patch or todo_write for a full replacement. Advance the next pending item in the same mutation; when the user says done/approved, update that turn.
+
+Skip only single trivial Q&A (one short fact, greeting). Multi-step Vietnamese or English asks (giải thích, chỉnh, bổ sung, help me, …) still need todos first.
+</Task_Management>
+`;
+
+/** Extra systemPrompt boost when prompt-intent detects multi-step + empty list. */
+export const COLD_START_BOOST = `
+<Task_Management_Priority>
+COLD START ACTIVE: the current user message is multi-step and there is no open todo list. Call todo_write before any other tool. Prefer 3–8 concrete checklist items. Keep exactly one in_progress.
+</Task_Management_Priority>
+`;

package/src/tools/todoupdate.ts

@@ -1,43 +1,55 @@
-import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";
-import { Text } from "@earendil-works/pi-tui";
-import { TodoUpdateParams } from "../schema.js";
-import { getTodos, setTodos, withStoreLock } from "../store.js";
-import type { TodoWriteDetails } from "../types.js";
-import { TODO_STATE_ENTRY_TYPE, TOOL_UPDATE } from "../types.js";
-import { ensureTodoIds, validateTodoUpdate } from "../validate.js";
-
-export function registerTodoUpdateTool(pi: ExtensionAPI, options: { onCommit?: () => void }): void {
-  pi.registerTool({
-    name: TOOL_UPDATE,
-    label: "Todo Update",
-    description: "Patch existing todos by stable ID. Use todo_read first to obtain IDs. This never deletes items.",
-    promptSnippet: "Patch one or more existing todos by ID without replacing the full list",
-    parameters: TodoUpdateParams,
-    async execute(_toolCallId, params) {
-      return withStoreLock(() => {
-        const current = getTodos();
-        const result = validateTodoUpdate(params.updates, current);
-        if (!result.ok) return { content: [{ type: "text", text: `Error: ${result.error}` }], details: { todos: current, error: result.error } as TodoWriteDetails };
-        const todos = ensureTodoIds(result.todos, current);
-        if (!result.unchanged) {
-          try { pi.appendEntry(TODO_STATE_ENTRY_TYPE, { todos }); }
-          catch (e) {
-            if (/stale after session replacement/i.test(String(e))) {
-              return { content: [{ type: "text", text: "Error: session was replaced — state not committed. Please retry todo_update." }], details: { todos: current, error: "stale session replacement" } as TodoWriteDetails };
-            }
-            throw e;
-          }
-        }
-        setTodos(todos);
-        options.onCommit?.();
-        return { content: [{ type: "text", text: result.unchanged ? "No change" : `Updated ${params.updates.length} todo(s)` }], details: { todos, ...(result.unchanged ? { unchanged: true } : {}) } as TodoWriteDetails };
-      });
-    },
-    renderCall(args, theme) { return new Text(theme.fg("toolTitle", theme.bold("todo_update ")) + theme.fg("accent", `${Array.isArray(args.updates) ? args.updates.length : 0} patch(es)`), 0, 0); },
-    renderResult(result, _opts, theme) {
-      const details = result.details as TodoWriteDetails | undefined;
-      if (details?.error) return new Text(theme.fg("error", `Error: ${details.error}`), 0, 0);
-      return new Text(theme.fg("success", details?.unchanged ? "No change" : "✓ Saved"), 0, 0);
-    },
-  });
-}
+import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";
+import { Text } from "@earendil-works/pi-tui";
+import { formatTodoListText } from "../format.js";
+import { TodoUpdateParams } from "../schema.js";
+import { getTodos, setTodos, withStoreLock } from "../store.js";
+import type { TodoWriteDetails } from "../types.js";
+import { TODO_STATE_ENTRY_TYPE, TOOL_UPDATE } from "../types.js";
+import { countOpenTodos, ensureTodoIds, validateTodoUpdate } from "../validate.js";
+
+export function registerTodoUpdateTool(pi: ExtensionAPI, options: { onCommit?: () => void }): void {
+  pi.registerTool({
+    name: TOOL_UPDATE,
+    label: "Todo Update",
+    description:
+      "Patch existing todos by short stable ID (t1, t2, …) without replacing the full list. " +
+      "id is required and must match a current todo exactly — copy it from todo_read / the previous tool result; " +
+      "never invent or approximate an ID. This tool never deletes items.\n\n" +
+      "Note: always call todo_read (or use IDs from the last write/update text) before todo_update.",
+    promptGuidelines: [
+      "Copy the exact short ID (t1, t2, …) from todo_read or the last todo_write/todo_update text. Never invent, truncate, or approximate IDs.",
+    ],
+    promptSnippet: "Patch one or more existing todos by ID without replacing the full list",
+    parameters: TodoUpdateParams,
+    async execute(_toolCallId, params) {
+      return withStoreLock(() => {
+        const current = getTodos();
+        const result = validateTodoUpdate(params.updates, current);
+        if (!result.ok) return { content: [{ type: "text", text: `Error: ${result.error}` }], details: { todos: current, error: result.error } as TodoWriteDetails };
+        const todos = ensureTodoIds(result.todos, current);
+        if (!result.unchanged) {
+          try { pi.appendEntry(TODO_STATE_ENTRY_TYPE, { todos }); }
+          catch (e) {
+            if (/stale after session replacement/i.test(String(e))) {
+              return { content: [{ type: "text", text: "Error: session was replaced — state not committed. Please retry todo_update." }], details: { todos: current, error: "stale session replacement" } as TodoWriteDetails };
+            }
+            throw e;
+          }
+        }
+        setTodos(todos);
+        options.onCommit?.();
+        const open = countOpenTodos(todos);
+        const text = result.unchanged
+          ? "No change"
+          : `Updated ${params.updates.length} todo(s)\n\n${formatTodoListText(todos, `${open} open / ${todos.length} total`)}`;
+        return { content: [{ type: "text", text }], details: { todos, ...(result.unchanged ? { unchanged: true } : {}) } as TodoWriteDetails };
+      });
+    },
+    renderCall(args, theme) { return new Text(theme.fg("toolTitle", theme.bold("todo_update ")) + theme.fg("accent", `${Array.isArray(args.updates) ? args.updates.length : 0} patch(es)`), 0, 0); },
+    renderResult(result, _opts, theme) {
+      const details = result.details as TodoWriteDetails | undefined;
+      if (details?.error) return new Text(theme.fg("error", `Error: ${details.error}`), 0, 0);
+      return new Text(theme.fg("success", details?.unchanged ? "No change" : "✓ Saved"), 0, 0);
+    },
+  });
+}

package/src/validate.ts

@@ -1,8 +1,20 @@
 import { sanitizeTodoText } from "./sanitize.js";
-import { randomUUID } from "node:crypto";
 import type { TodoItem, TodoPriority, TodoStatus } from "./types.js";
 import { MAX_CONTENT_LENGTH, MAX_TODO_ITEMS, TODO_PRIORITIES, TODO_STATUSES } from "./types.js";
 
+/** Short sequential IDs (`t1`, `t2`, …) — easy for LLMs to copy; avoids UUID typos. */
+export function nextShortTodoId(used: ReadonlySet<string>): string {
+  let n = 1;
+  while (used.has(`t${n}`)) n += 1;
+  return `t${n}`;
+}
+
+function formatAvailableIds(current: readonly TodoItem[]): string {
+  const ids = current.map((t) => t.id).filter((id): id is string => typeof id === "string" && id.length > 0);
+  if (ids.length === 0) return "(none)";
+  return ids.join(", ");
+}
+
 export type ValidateOk = { ok: true; todos: TodoItem[]; unchanged: boolean };
 export type ValidateErr = { ok: false; error: string };
 export type ValidateResult = ValidateOk | ValidateErr;
@@ -117,13 +129,16 @@ export function validateTodoWrite(
  *   an ID that another incoming item explicitly preserves.
  * - Items without `id` try to match a prior item: first by full tuple
  *   (content+status+priority), then by unique content.  If ambiguous (multiple
- *   same-content items) or no prior match, a new UUID is generated.
+ *   same-content items) or no prior match, a new short ID (`tN`) is generated.
  */
 export function ensureTodoIds(todos: readonly TodoItem[], current: readonly TodoItem[]): TodoItem[] {
   // Reserve every explicit ID up front. Incoming order must not decide whether an
   // id-less item steals an ID that a later item explicitly retains.
   const reserved = new Set(todos.flatMap((todo) => todo.id ? [todo.id] : []));
   const claimed = new Set<string>();
+  // Avoid reusing any current ID in this pass — a later id-less item may still
+  // match it by tuple/content. Freed IDs become reusable on the next write.
+  const currentIds = new Set(current.flatMap((todo) => todo.id ? [todo.id] : []));
 
   // Pre-index content uniqueness: content that appears only once in `current`
   // is safe for content-only fallback.
@@ -154,10 +169,11 @@ export function ensureTodoIds(todos: readonly TodoItem[], current: readonly Todo
           if (byContent) id = byContent.id;
         }
       }
-      // 3. No match or ambiguous → fresh ID
-        if (!id) {
-          do id = randomUUID(); while (reserved.has(id) || claimed.has(id));
-        }
+      // 3. No match or ambiguous → fresh short sequential ID
+      if (!id) {
+        const used = new Set([...reserved, ...claimed, ...currentIds]);
+        id = nextShortTodoId(used);
+      }
     }
     claimed.add(id);
     return { ...todo, id };
@@ -197,7 +213,12 @@ export function validateTodoUpdate(rawUpdates: unknown, current: readonly TodoIt
     if (seen.has(rec.id)) return { ok: false, error: `updates[${i}].id is duplicated` };
     seen.add(rec.id);
     const target = next.find((todo) => todo.id === rec.id);
-    if (!target) return { ok: false, error: `updates[${i}].id does not match an existing todo` };
+    if (!target) {
+      return {
+        ok: false,
+        error: `updates[${i}].id "${rec.id}" does not match an existing todo; current IDs: ${formatAvailableIds(current)}`,
+      };
+    }
     if (rec.content === undefined && rec.status === undefined && rec.priority === undefined) {
       return { ok: false, error: `updates[${i}] must change content, status, or priority` };
     }