taskplane 0.28.7 → 0.28.8

package/dashboard/public/app.js

@@ -942,8 +942,11 @@ function renderLanesTasks(batch, sessions) {
         ? `<button class="viewer-eye-btn${isViewingStatus ? ' active' : ''}" onclick="viewStatusMd('${escapeHtml(task.taskId)}')" title="View STATUS.md">👁</button>`
         : '';
 
-      // #485: Show task title (from PROMPT.md `# Task: <ID> - <title>`) under
-      // the task-id when available. Falls back to just the ID when missing.
+      // #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>`
         : "";
@@ -951,11 +954,12 @@ function renderLanesTasks(batch, sessions) {
         <div class="task-row">
           <span class="task-icon"><span class="status-dot ${task.status}"></span></span>
           <span class="task-actions">${eyeHtml}</span>
-          <span class="task-id status-${task.status}"><div class="task-id-line">${escapeHtml(task.taskId)}${showRepos ? repoBadgeHtml(tRepo, "repo-badge-task") : ""}</div>${titleHtml}</span>
+          <span class="task-id status-${task.status}">${escapeHtml(task.taskId)}${showRepos ? repoBadgeHtml(tRepo, "repo-badge-task") : ""}</span>
           <span><span class="status-badge status-${task.status}"><span class="status-dot ${task.status}"></span> ${task.status}</span></span>
           <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,20 +628,19 @@ body {
   font-family: var(--font-mono);
   font-weight: 600;
   font-size: 0.85rem;
-  /* #485: task-id may now contain a stacked task-id-line + task-title-subtitle */
-  display: flex;
-  flex-direction: column;
-  gap: 2px;
-  min-width: 0; /* allow inner ellipsis to work */
-}
-
-.task-id-line {
-  /* The original TP-XXX line; preserves the previous single-line look */
-  white-space: nowrap;
+  /* #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: human-readable task title under the ID */
+  /* #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;
@@ -646,7 +648,8 @@ body {
   white-space: nowrap;
   overflow: hidden;
   text-overflow: ellipsis;
-  max-width: 100%;
+  /* Pull subtitle visually closer to the task-id row above. */
+  margin-top: -2px;
 }
 
 .task-duration {

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.7",
+  "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