taskplane 0.28.6 → 0.28.8

package/dashboard/public/app.js

@@ -616,7 +616,13 @@ function renderSummary(batch) {
       const isCurrent = i === waveIdx && (batch.phase === "executing" || batch.phase === "merging");
       const isMergingChip = i === waveIdx && batch.phase === "merging";
       const cls = isDone ? "done" : isMergingChip ? "current merging" : isCurrent ? "current" : "";
-      wavesHtml += `<span class="wave-chip ${cls}">W${i + 1} [${taskIds.join(", ")}]</span>`;
+      // #484: Show lane parallelization within each wave. Group taskIds by
+      // their assigned lane: tasks on the same lane render with `→` (serial),
+      // tasks on different lanes render with ` | ` (parallel). Tooltip shows
+      // the expanded lane breakdown.
+      const { compact, tooltip } = formatWaveLaneBreakdown(taskIds, batch.lanes || [], i + 1);
+      const titleAttr = tooltip ? ` title="${escapeHtml(tooltip)}"` : "";
+      wavesHtml += `<span class="wave-chip ${cls}"${titleAttr}>W${i + 1} [${compact}]</span>`;
     });
     $summaryWaves.innerHTML = wavesHtml;
   } else {
@@ -624,6 +630,84 @@ function renderSummary(batch) {
   }
 }
 
+/**
+ * Compute lane parallelization for a wave's tasks (#484).
+ *
+ * Returns:
+ *   - `compact`: a string like "TP-165 → TP-166 | TP-168 | TP-167" suitable
+ *     for the wave-chip body. Tasks on the same lane are joined by ` → `
+ *     (in lane execution order, not just appearance order); separate lanes
+ *     are joined by ` | `.
+ *   - `tooltip`: a multi-line string like
+ *     "W1\n  L1: TP-165 → TP-166\n  L2: TP-168\n  L3: TP-167" suitable for
+ *     the chip's `title` attribute. Empty string when no lane data is
+ *     available (future waves not yet provisioned).
+ *
+ * When lane data is missing for one or more tasks (e.g., the wave has not
+ * yet been provisioned, or task hasn't been assigned), unassigned tasks
+ * are shown with the previous flat formatting and no tooltip is generated
+ * — this preserves backward compatibility with future-wave display.
+ */
+function formatWaveLaneBreakdown(taskIds, lanes, waveNumber) {
+  if (!Array.isArray(taskIds) || taskIds.length === 0) {
+    return { compact: "", tooltip: "" };
+  }
+  // Build taskId → laneNumber map for the lanes that have any of these tasks.
+  const taskToLane = new Map();
+  for (const lane of lanes) {
+    if (!lane || !Array.isArray(lane.taskIds)) continue;
+    for (const tid of lane.taskIds) {
+      // First lane to claim a task wins (lanes shouldn't overlap, but be defensive).
+      if (!taskToLane.has(tid)) taskToLane.set(tid, lane.laneNumber);
+    }
+  }
+  // If no task in this wave has lane data, fall back to flat display.
+  const hasAnyLaneData = taskIds.some((t) => taskToLane.has(t));
+  if (!hasAnyLaneData) {
+    return { compact: taskIds.join(", "), tooltip: "" };
+  }
+  // Group taskIds by lane. Preserve appearance order across lanes.
+  // Within a lane, preserve the lane's own taskIds order so `→` reflects
+  // execution order, not the order taskIds happens to appear here.
+  const laneOrder = []; // lane numbers in order they first appear in taskIds
+  const laneToTasks = new Map(); // laneNumber → ordered taskIds for this wave
+  const unassigned = []; // taskIds not in any lane (shouldn't happen but be defensive)
+  for (const tid of taskIds) {
+    const ln = taskToLane.get(tid);
+    if (ln === undefined) {
+      unassigned.push(tid);
+      continue;
+    }
+    if (!laneToTasks.has(ln)) {
+      laneToTasks.set(ln, []);
+      laneOrder.push(ln);
+    }
+    laneToTasks.get(ln).push(tid);
+  }
+  // Sort each lane's tasks by their position in the lane.taskIds array
+  // so `→` always reflects execution order on that lane.
+  for (const ln of laneOrder) {
+    const lane = lanes.find((l) => l && l.laneNumber === ln);
+    if (lane && Array.isArray(lane.taskIds)) {
+      const orderIndex = new Map(lane.taskIds.map((t, idx) => [t, idx]));
+      laneToTasks.get(ln).sort((a, b) => (orderIndex.get(a) ?? 0) - (orderIndex.get(b) ?? 0));
+    }
+  }
+  // Build compact representation.
+  const laneSegments = laneOrder.map((ln) => laneToTasks.get(ln).join(" → "));
+  if (unassigned.length > 0) laneSegments.push(unassigned.join(", "));
+  const compact = laneSegments.join(" | ");
+  // Build tooltip representation.
+  const tooltipLines = [`W${waveNumber}`];
+  for (const ln of laneOrder) {
+    tooltipLines.push(`  L${ln}: ${laneToTasks.get(ln).join(" → ")}`);
+  }
+  if (unassigned.length > 0) {
+    tooltipLines.push(`  (unassigned): ${unassigned.join(", ")}`);
+  }
+  return { compact, tooltip: tooltipLines.join("\n") };
+}
+
 // ─── Render: Lanes + Tasks (integrated) ─────────────────────────────────────
 
 function renderLanesTasks(batch, sessions) {
@@ -858,6 +942,14 @@ function renderLanesTasks(batch, sessions) {
         ? `<button class="viewer-eye-btn${isViewingStatus ? ' active' : ''}" onclick="viewStatusMd('${escapeHtml(task.taskId)}')" title="View STATUS.md">👁</button>`
         : '';
 
+      // #485 (revised): Show task title on a second grid row spanning task-id
+      // through progress (cols 3–6), giving ~5× more horizontal space than the
+      // original task-id-only width. Stops before col 7 (task-step + telemetry)
+      // so the step info and worker stats stay visible alongside the title.
+      // Falls back to no subtitle row when taskTitle is missing.
+      const titleHtml = task.taskTitle
+        ? `<div class="task-title-subtitle">${escapeHtml(task.taskTitle)}</div>`
+        : "";
       html += `
         <div class="task-row">
           <span class="task-icon"><span class="status-dot ${task.status}"></span></span>
@@ -867,6 +959,7 @@ function renderLanesTasks(batch, sessions) {
           <span class="task-duration">${dur}</span>
           <span>${progressHtml}</span>
           <span class="task-step">${stepHtml}${workerHtml}</span>
+          ${titleHtml}
         </div>`;
       html += reviewerRowHtml;
     }

package/dashboard/public/style.css

@@ -607,8 +607,11 @@ body {
 .task-row {
   display: grid;
   grid-template-columns: 36px 24px 100px 90px 80px 200px 1fr;
+  /* #485 (revised): row 1 holds the primary cells; row 2 (auto, collapses to
+   * 0 when empty) holds the optional task-title-subtitle spanning cols 3–6. */
+  grid-template-rows: auto auto;
   align-items: center;
-  gap: 8px;
+  gap: 8px 8px;
   padding: 8px 14px;
   border-bottom: 1px solid var(--border-subtle);
   transition: background 0.15s;
@@ -625,6 +628,28 @@ body {
   font-family: var(--font-mono);
   font-weight: 600;
   font-size: 0.85rem;
+  /* #485 (revised): task-id is back to a single inline cell. The optional
+   * title-subtitle is now a separate grid item placed in row 2 — it spans
+   * cols 3–6 (task-id through progress) for ~5× more horizontal space than
+   * the previous nested-subtitle approach. */
+}
+
+.task-title-subtitle {
+  /* #485 (revised): human-readable task title placed on row 2 of the task-row
+   * grid, spanning cols 3–6 (task-id, status, duration, progress) and
+   * stopping before col 7 (task-step + telemetry). Auto row 2 collapses to
+   * 0 height when this element is absent (no title for the task). */
+  grid-column: 3 / 7;
+  grid-row: 2;
+  font-family: var(--font-sans, inherit);
+  font-weight: 400;
+  font-size: 0.72rem;
+  color: var(--text-muted);
+  white-space: nowrap;
+  overflow: hidden;
+  text-overflow: ellipsis;
+  /* Pull subtitle visually closer to the task-id row above. */
+  margin-top: -2px;
 }
 
 .task-duration {

package/dashboard/server.cjs

@@ -160,6 +160,52 @@ function resolveTaskFolder(task, state) {
   return task.taskFolder;
 }
 
+/**
+ * Read the task title from a task folder's PROMPT.md.
+ *
+ * Extracts the human-readable title from the first `# Task:` heading. The
+ * heading format is `# Task: <ID> - <title>` per the create-taskplane-task
+ * skill's prompt template. Returns null when PROMPT.md is missing, the
+ * pattern doesn't match, or any read error occurs.
+ *
+ * Cached per-folder for the lifetime of this server process: PROMPT.md is
+ * immutable above the `---` divider so the title never changes mid-batch.
+ * Cache is keyed by absolute task folder path. (#485)
+ */
+const _taskTitleCache = new Map();
+function parseTaskTitle(taskFolder) {
+  if (!taskFolder) return null;
+  const cacheKey = path.resolve(taskFolder);
+  if (_taskTitleCache.has(cacheKey)) return _taskTitleCache.get(cacheKey);
+
+  // Look at both the canonical folder and the archive fallback (matches
+  // parseStatusMd's two-candidate strategy).
+  const candidates = [taskFolder];
+  const taskId = path.basename(taskFolder);
+  const archiveBase = taskFolder.replace(/[/\\]tasks[/\\][^/\\]+$/, "/tasks/archive/" + taskId);
+  if (archiveBase !== taskFolder) candidates.push(archiveBase);
+
+  for (const folder of candidates) {
+    const promptPath = path.join(folder, "PROMPT.md");
+    try {
+      const content = fs.readFileSync(promptPath, "utf-8");
+      // Match `# Task: <ID> - <title>` (the canonical first-line heading).
+      const match = content.match(/^# Task:\s*\S+\s*[-\u2014\u2013]\s*(.+?)\s*$/m);
+      if (match) {
+        const title = match[1].trim();
+        _taskTitleCache.set(cacheKey, title);
+        return title;
+      }
+    } catch {
+      // PROMPT.md missing or unreadable in this candidate — try the next.
+      continue;
+    }
+  }
+  // Cache the negative result too, so we don't re-attempt on every poll.
+  _taskTitleCache.set(cacheKey, null);
+  return null;
+}
+
 function parseStatusMd(taskFolder) {
   const candidates = [taskFolder];
   const taskId = path.basename(taskFolder);
@@ -1102,13 +1148,17 @@ function buildDashboardState() {
   const tasks = (state.tasks || []).map((task) => {
     const effectiveFolder = resolveTaskFolder(task, state);
     let statusData = null;
+    let taskTitle = null;
     if (effectiveFolder) {
       statusData = parseStatusMd(effectiveFolder);
+      // #485: read the human-readable title from PROMPT.md once, surface
+      // alongside taskId so the dashboard can show it as a subtitle.
+      taskTitle = parseTaskTitle(effectiveFolder);
     }
     if (!task.doneFileFound && effectiveFolder) {
       task.doneFileFound = checkDoneFile(effectiveFolder);
     }
-    return { ...task, statusData };
+    return { ...task, statusData, taskTitle };
   });
 
   // TP-107: Load Runtime V2 data when available

package/extensions/taskplane/worktree.ts

@@ -3,7 +3,7 @@
  * @module orch/worktree
  */
 import { existsSync, mkdirSync, readdirSync, realpathSync, rmdirSync, rmSync } from "fs";
-import { execSync } from "child_process";
+import { execSync, execFileSync } from "child_process";
 import { join, basename, resolve } from "path";
 
 import { execLog } from "./execution.ts";
@@ -639,6 +639,57 @@ export function isRetriableRemoveError(stderr: string): boolean {
 	return false;
 }
 
+/**
+ * Detect Windows MAX_PATH ("Filename too long") errors from `git worktree remove`.
+ *
+ * On Windows with default `core.longpaths = false`, git refuses to delete
+ * paths that exceed MAX_PATH (260 characters). Deep `node_modules` trees
+ * commonly trip this. Native `cmd` `rd /s /q` uses a different deletion
+ * code path (NT object namespace, longer path tolerance) and usually
+ * succeeds where git fails.
+ *
+ * @param stderr - Error output from `git worktree remove`
+ * @returns true if the failure looks like the Windows MAX_PATH case
+ * @since TP-188 (#543)
+ */
+export function isWindowsMaxPathError(stderr: string): boolean {
+	if (process.platform !== "win32") return false;
+	return /filename too long/i.test(stderr);
+}
+
+/**
+ * Run `cmd /c rd /s /q <path>` to recursively delete a directory on Windows.
+ *
+ * Used as a fallback after `git worktree remove` fails with the Windows
+ * MAX_PATH ("Filename too long") error. Caller must ensure platform is win32
+ * and the path is absolute. Path separators are normalized to backslashes
+ * because cmd's `rd` is more reliable with native Windows paths.
+ *
+ * @param absolutePath - Absolute path to remove (forward or back slashes accepted)
+ * @returns { ok, stdout, stderr }
+ * @since TP-188 (#543)
+ */
+export function runWindowsCmdRd(
+	absolutePath: string,
+): { ok: boolean; stdout: string; stderr: string } {
+	const winPath = absolutePath.replace(/\//g, "\\");
+	try {
+		const stdout = execFileSync("cmd", ["/c", "rd", "/s", "/q", winPath], {
+			encoding: "utf-8",
+			timeout: 60_000,
+			stdio: ["pipe", "pipe", "pipe"],
+		}).toString().trim();
+		return { ok: true, stdout, stderr: "" };
+	} catch (err: unknown) {
+		const e = err as { stdout?: string; stderr?: string; message?: string };
+		return {
+			ok: false,
+			stdout: (e.stdout ?? "").toString().trim(),
+			stderr: (e.stderr ?? e.message ?? "unknown error").toString().trim(),
+		};
+	}
+}
+
 /**
  * Remove a git worktree and clean up its associated branch.
  *
@@ -733,6 +784,50 @@ export function removeWorktree(
 
 		lastError = removeResult.stderr;
 
+		// ── Windows MAX_PATH fallback (#543) ────────────────────────
+		// On Windows, `git worktree remove` fails with "Filename too long"
+		// when the worktree contains deep `node_modules` trees (most
+		// non-trivial Node projects) and `core.longpaths = false` (default).
+		// `cmd /c rd /s /q <path>` uses a different deletion code path
+		// that tolerates long paths better. Try it ONCE before classifying
+		// the error as terminal/retriable so other error classes still
+		// surface unchanged.
+		if (isWindowsMaxPathError(lastError)) {
+			execLog(
+				"cleanup",
+				"worktree",
+				`Windows MAX_PATH detected — falling back to cmd "rd /s /q"`,
+				{ path: worktreePath, attempt },
+			);
+			const fallback = runWindowsCmdRd(worktreePath);
+			if (fallback.ok) {
+				execLog(
+					"cleanup",
+					"worktree",
+					`cmd "rd /s /q" fallback succeeded; pruning git worktree state`,
+					{ path: worktreePath },
+				);
+				// The on-disk tree is gone; git's bookkeeping still has a
+				// stale entry. Prune so isRegisteredWorktree() returns false
+				// during post-removal verification below.
+				runGit(["worktree", "prune"], repoRoot);
+				break;
+			}
+			// Fallback also failed — enrich error so the operator sees both
+			// attempts, then fall through to the existing terminal/retry
+			// classification (which will throw because "Filename too long"
+			// is non-retriable per isRetriableRemoveError).
+			execLog(
+				"cleanup",
+				"worktree",
+				`cmd "rd /s /q" fallback failed`,
+				{ path: worktreePath, error: fallback.stderr.slice(0, 200) },
+			);
+			lastError =
+				`git worktree remove failed: ${lastError}; ` +
+				`cmd rd /s /q fallback failed: ${fallback.stderr}`;
+		}
+
 		// Check if error is terminal (non-retriable)
 		if (!isRetriableRemoveError(lastError)) {
 			throw new WorktreeError(

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "taskplane",
-  "version": "0.28.6",
+  "version": "0.28.8",
   "description": "AI agent orchestration for pi — parallel task execution with checkpoint discipline",
   "keywords": [
     "pi-package",

package/templates/agents/task-reviewer.md

@@ -50,6 +50,74 @@ You handle a single review request and then exit.
 Do NOT just respond with text — the orchestrator reads the OUTPUT FILE to get
 your verdict. If you don't write the file, your review is lost.
 
+## Quality-check verification (code reviews only)
+
+**This section applies to code reviews only.** For plan reviews, skip this
+section entirely — there is no code to type-check or lint yet.
+
+Before returning a code-review verdict, run the project's declared
+typecheck / lint / format-check commands against the post-change tree. A
+behavioural-correctness APPROVE is **invalidated** by failing quality checks.
+
+The reviewer's tool allowlist already includes `bash`, so you can invoke these
+commands directly — no special tooling is required.
+
+### How to discover the commands
+
+1. **Project config first.** Read `.pi/taskplane-config.json` (or the legacy
+   `.pi/task-runner.yaml` / `.pi/task-runner.json` fallbacks) and look at
+   `taskRunner.testing.commands` — a `Record<string, string>` mapping a
+   command name (e.g. `typecheck`, `lint`, `format:check`) to a
+   shell command. Run any command whose key matches one of
+   `typecheck` / `tsc` / `types` / `lint` / `format:check`.
+   **Prefer `format:check` over `format`** — the latter typically rewrites
+   files in place, which would mutate the working tree the reviewer is
+   evaluating. If only a mutating `format` script is available in either
+   source, skip it and note this in the Summary; do not run mutating
+   commands from the reviewer.
+2. **Fallback to `package.json` scripts.** If step 1 did not yield any
+   relevant commands — either because `taskRunner.testing.commands` is
+   absent OR because it exists but contains no keys matching the
+   typecheck/lint/format-check set — read `package.json` and run any of
+   these scripts that exist, in this order:
+   `npm run typecheck`, `npm run lint`, `npm run format:check`.
+   Skip a script if `package.json#scripts` does not declare it — do not
+   invent commands.
+3. **Skip silently** if neither source yields a relevant command. Do not fail
+   the review just because the project has no quality-check pipeline
+   configured. Note this in the Summary so the operator knows quality checks
+   were not exercised.
+
+Do NOT run the project's full test suite from this section — that is the
+worker's Testing & Verification step. The quality checks here are
+**fast static checks** (typecheck, lint, format) that are cheap to run and
+high-signal for catching regressions the behavioural diff review would miss.
+
+### What to do with the results
+
+- **All quality checks pass** → proceed to behavioural code review as normal.
+- **A quality check fails** → surface each failing command as an entry in
+  **Issues Found** with severity `important`. Include:
+  - The command that failed (e.g. `npm run typecheck`)
+  - The first few lines of the failing output (file/line locations are
+    most useful)
+  - A concrete suggested fix where the failure makes one obvious
+- **Verdict downgrade rule:** If quality checks fail, the verdict is
+  **REVISE** — even if the behavioural code review would otherwise have
+  been APPROVE. Quality-check failures are blocking by definition: they
+  would surface at the worker's Testing & Verification step and force a
+  redo of the entire review cycle, so it is strictly cheaper to surface
+  them here.
+
+### Worked example (Issues Found entry)
+
+```
+1. **[npm run typecheck:1] [important]** — 5 strict-mode errors in
+   tests/foo.test.ts. Sample: "Argument of type 'undefined' is not
+   assignable to parameter of type 'string'" at line 42. Fix: narrow
+   `getThing()` return type or assert non-null at call site.
+```
+
 ## Verdict Criteria
 
 - **APPROVE** — Step will achieve its stated outcomes. Minor suggestions belong