@agent-plan/core 0.2.29 → 0.3.0

package/dist/task-order-context.js

@@ -0,0 +1,82 @@
+import { featureNumberOfPhase, formatPhaseRef } from "./naming.js";
+const TERMINAL_STATUSES = ["done", "canceled", "rejected"];
+function taskPriority(task) {
+    return task.priority ?? task.number;
+}
+function compareByPriority(left, right) {
+    return taskPriority(left) - taskPriority(right) || left.number - right.number;
+}
+function isTaskReady(task, statusById) {
+    if (task.status !== "planned")
+        return false;
+    return (task.dependsOn ?? []).every((id) => statusById.get(id) === "done");
+}
+/**
+ * Build the ordering context for one task. `allPhases` and `features` are
+ * needed (not just the task's own phase) because a dependency can name a
+ * task in a different phase (see PlanStore.addTaskDependency, which allows
+ * any project-wide target) and its composite ref/status must resolve
+ * project-wide, not just among siblings.
+ */
+export function buildTaskOrderContext(task, phase, allPhases, features) {
+    const statusById = new Map();
+    const refById = new Map();
+    for (const candidatePhase of allPhases) {
+        const phaseRef = formatPhaseRef(candidatePhase.number, featureNumberOfPhase(candidatePhase, features));
+        for (const candidateTask of candidatePhase.tasks ?? []) {
+            statusById.set(candidateTask.id, candidateTask.status);
+            refById.set(candidateTask.id, `${phaseRef}/T${String(candidateTask.number).padStart(3, "0")}`);
+        }
+    }
+    const siblings = phase.tasks ?? [];
+    const readySiblings = siblings.filter((sibling) => isTaskReady(sibling, statusById)).sort(compareByPriority);
+    const ordersApply = !TERMINAL_STATUSES.includes(task.status);
+    const readyAheadCount = ordersApply
+        ? readySiblings.filter((sibling) => sibling.id !== task.id && compareByPriority(sibling, task) < 0).length
+        : 0;
+    const topReady = readySiblings[0];
+    const nextByPriorityRef = ordersApply && topReady && topReady.id !== task.id
+        ? (refById.get(topReady.id) ?? null)
+        : null;
+    const dependsOn = (task.dependsOn ?? []).map((id) => ({
+        ref: refById.get(id) ?? id,
+        taskId: id,
+        status: statusById.get(id) ?? "planned",
+    }));
+    return {
+        priority: taskPriority(task),
+        ordersApply,
+        readyCount: readySiblings.length,
+        readyAheadCount,
+        nextByPriorityRef,
+        dependsOn,
+    };
+}
+/** One line for the human-readable channel of the full task view: the exact
+ * shape both adapters render, so the fact is never assembled twice. Bounded
+ * by construction — a count, a priority number and a short dependency list,
+ * never the entities themselves. */
+export function taskOrderContextLine(context, status) {
+    const depsText = context.dependsOn.length > 0
+        ? context.dependsOn.map((dependency) => `${dependency.ref} (${dependency.status})`).join(", ")
+        : "None";
+    if (!context.ordersApply) {
+        return `Priority ${context.priority} (${status}; ordering no longer applies). Depends on: ${depsText}.`;
+    }
+    const parts = [
+        `Priority ${context.priority}`,
+        `${context.readyCount} ready in phase`,
+        `${context.readyAheadCount} ready ahead of this one`,
+    ];
+    if (context.nextByPriorityRef)
+        parts.push(`next by priority: ${context.nextByPriorityRef}`);
+    return `${parts.join(" · ")}. Depends on: ${depsText}.`;
+}
+/** The fact a task-creation confirmation must state: where in the phase's
+ * priority order the planner placed the new task. Centralized so the two
+ * otherwise differently-worded adapter confirmations never diverge on how
+ * this fragment reads (see P104(F005)/T421 — eight tasks were created in
+ * this phase without a priority ever being shown). */
+export function taskCreatedPriorityFragment(priority) {
+    return `priority ${priority}`;
+}

package/dist/task-selection.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"task-selection.d.ts","sourceRoot":"","sources":["../src/task-selection.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,OAAO,EAAE,KAAK,EAAE,IAAI,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAEvE,MAAM,MAAM,uBAAuB,GAAG,gBAAgB,GAAG,UAAU,GAAG,UAAU,GAAG,cAAc,CAAC;AAClG,MAAM,MAAM,yBAAyB,GAAG,UAAU,GAAG,aAAa,GAAG,kBAAkB,GAAG,kBAAkB,GAAG,SAAS,GAAG,kBAAkB,CAAC;AAE9I,MAAM,WAAW,mBAAmB;IAClC,IAAI,EAAE,uBAAuB,CAAC;IAC9B,MAAM,EAAE,yBAAyB,CAAC;IAClC,GAAG,EAAE,MAAM,CAAC;IACZ,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB;AAED,MAAM,WAAW,6BAA6B;IAC5C,YAAY,EAAE,MAAM,CAAC;IACrB,SAAS,EAAE,MAAM,CAAC;IAClB,iEAAiE;IACjE,WAAW,EAAE,OAAO,CAAC;CACtB;AAED,MAAM,WAAW,qCAAqC;IACpD,YAAY,EAAE,MAAM,CAAC;IACrB,SAAS,EAAE,MAAM,CAAC;IAClB,MAAM,EAAE,MAAM,CAAC;CAChB;AAED,MAAM,WAAW,sBAAsB;IACrC,QAAQ,CAAC,EAAE,6BAA6B,EAAE,CAAC;IAC3C,gBAAgB,CAAC,EAAE,qCAAqC,EAAE,CAAC;CAC5D;AAED,MAAM,MAAM,sBAAsB,GAAG,QAAQ,GAAG,QAAQ,GAAG,UAAU,GAAG,UAAU,GAAG,MAAM,CAAC;AAE5F,MAAM,WAAW,aAAa;IAC5B,OAAO,EAAE,OAAO,GAAG,SAAS,CAAC;IAC7B,KAAK,EAAE,KAAK,CAAC;IACb,IAAI,EAAE,IAAI,CAAC;CACZ;AAED,MAAM,WAAW,WAAW;IAC1B,EAAE,EAAE,MAAM,CAAC;IACX,MAAM,EAAE,MAAM,CAAC;IACf,QAAQ,EAAE,MAAM,CAAC;IACjB,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;CAChB;AAED,MAAM,WAAW,sBAAsB;IACrC,SAAS,EAAE,kBAAkB,CAAC;IAC9B,UAAU,EAAE,WAAW,GAAG,IAAI,CAAC;IAC/B,WAAW,EAAE,WAAW,GAAG,IAAI,CAAC;IAChC,SAAS,EAAE,WAAW,GAAG,IAAI,CAAC;IAC9B,QAAQ,EAAE,WAAW,GAAG,IAAI,CAAC;IAC7B,MAAM,EAAE,mBAAmB,EAAE,CAAC;CAC/B;AAED,MAAM,WAAW,kBAAkB;IACjC,IAAI,EAAE,sBAAsB,CAAC;IAC7B,SAAS,CAAC,EAAE,aAAa,CAAC;IAC1B,iEAAiE;IACjE,gBAAgB,CAAC,EAAE,aAAa,EAAE,CAAC;IACnC,8EAA8E;IAC9E,SAAS,CAAC,EAAE,aAAa,CAAC;IAC1B,MAAM,EAAE,MAAM,CAAC;CAChB;AAED,mFAAmF;AACnF,MAAM,WAAW,4BAA4B;IAC3C,QAAQ,EAAE,OAAO,CAAC;IAClB,MAAM,EAAE,MAAM,CAAC;CAChB;AAwHD;;;;GAIG;AACH,wBAAgB,sBAAsB,CACpC,QAAQ,EAAE,OAAO,EAAE,EACnB,MAAM,EAAE,KAAK,EAAE,EACf,MAAM,EAAE,MAAM,EACd,UAAU,GAAE,aAAa,EAAO,GAC/B,4BAA4B,CA+B9B;AAED;;;;GAIG;AACH,wBAAgB,iBAAiB,CAC/B,QAAQ,EAAE,OAAO,EAAE,EACnB,MAAM,EAAE,KAAK,EAAE,EACf,UAAU,GAAE,aAAa,EAAO,EAChC,cAAc,SAAK,EACnB,SAAS,SAAK,GACb,kBAAkB,CA0FpB;AAED,wBAAgB,iBAAiB,CAC/B,QAAQ,EAAE,OAAO,EAAE,EACnB,MAAM,EAAE,KAAK,EAAE,EACf,UAAU,GAAE,aAAa,EAAO,EAChC,cAAc,SAAK,EACnB,SAAS,SAAK,EACd,QAAQ,GAAE,sBAA2B,GACpC,sBAAsB,CA0BxB;AAED;;;;GAIG;AACH,MAAM,WAAW,sBAAsB;IACrC,MAAM,EAAE,MAAM,CAAC;IACf,cAAc,EAAE,MAAM,CAAC;IACvB,WAAW,EAAE,MAAM,CAAC;CACrB;AAED;;;;;;GAMG;AACH,MAAM,WAAW,sBAAsB;IACrC,IAAI,EAAE,MAAM,CAAC;IACb,UAAU,EAAE;QACV,MAAM,EAAE,MAAM,CAAC;QACf,OAAO,EAAE,MAAM,CAAC;QAChB,QAAQ,EAAE,sBAAsB,GAAG,IAAI,CAAC;KACzC,CAAC;CACH;AAED;;;;GAIG;AACH,wBAAgB,2BAA2B,CAAC,MAAM,EAAE;IAClD,GAAG,EAAE,MAAM,CAAC;IACZ,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,OAAO,EAAE,MAAM,CAAC;IAChB,QAAQ,EAAE,sBAAsB,GAAG,IAAI,CAAC;CACzC,GAAG,sBAAsB,CAuBzB"}
+{"version":3,"file":"task-selection.d.ts","sourceRoot":"","sources":["../src/task-selection.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,OAAO,EAAE,KAAK,EAAE,IAAI,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAEvE,MAAM,MAAM,uBAAuB,GAAG,gBAAgB,GAAG,UAAU,GAAG,UAAU,GAAG,cAAc,CAAC;AAClG,MAAM,MAAM,yBAAyB,GAAG,UAAU,GAAG,aAAa,GAAG,kBAAkB,GAAG,kBAAkB,GAAG,SAAS,GAAG,kBAAkB,CAAC;AAE9I,MAAM,WAAW,mBAAmB;IAClC,IAAI,EAAE,uBAAuB,CAAC;IAC9B,MAAM,EAAE,yBAAyB,CAAC;IAClC,GAAG,EAAE,MAAM,CAAC;IACZ,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,SAAS,CAAC,EAAE,MAAM,CAAC;CACpB;AAED,MAAM,WAAW,6BAA6B;IAC5C,YAAY,EAAE,MAAM,CAAC;IACrB,SAAS,EAAE,MAAM,CAAC;IAClB,iEAAiE;IACjE,WAAW,EAAE,OAAO,CAAC;CACtB;AAED,MAAM,WAAW,qCAAqC;IACpD,YAAY,EAAE,MAAM,CAAC;IACrB,SAAS,EAAE,MAAM,CAAC;IAClB,MAAM,EAAE,MAAM,CAAC;CAChB;AAED,MAAM,WAAW,sBAAsB;IACrC,QAAQ,CAAC,EAAE,6BAA6B,EAAE,CAAC;IAC3C,gBAAgB,CAAC,EAAE,qCAAqC,EAAE,CAAC;CAC5D;AAED,MAAM,MAAM,sBAAsB,GAAG,QAAQ,GAAG,QAAQ,GAAG,UAAU,GAAG,UAAU,GAAG,MAAM,CAAC;AAE5F,MAAM,WAAW,aAAa;IAC5B,OAAO,EAAE,OAAO,GAAG,SAAS,CAAC;IAC7B,KAAK,EAAE,KAAK,CAAC;IACb,IAAI,EAAE,IAAI,CAAC;CACZ;AAED,MAAM,WAAW,WAAW;IAC1B,EAAE,EAAE,MAAM,CAAC;IACX,MAAM,EAAE,MAAM,CAAC;IACf,QAAQ,EAAE,MAAM,CAAC;IACjB,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;CAChB;AAED,MAAM,WAAW,sBAAsB;IACrC,SAAS,EAAE,kBAAkB,CAAC;IAC9B,UAAU,EAAE,WAAW,GAAG,IAAI,CAAC;IAC/B,WAAW,EAAE,WAAW,GAAG,IAAI,CAAC;IAChC,SAAS,EAAE,WAAW,GAAG,IAAI,CAAC;IAC9B,QAAQ,EAAE,WAAW,GAAG,IAAI,CAAC;IAC7B,MAAM,EAAE,mBAAmB,EAAE,CAAC;CAC/B;AAED,MAAM,WAAW,kBAAkB;IACjC,IAAI,EAAE,sBAAsB,CAAC;IAC7B,SAAS,CAAC,EAAE,aAAa,CAAC;IAC1B,iEAAiE;IACjE,gBAAgB,CAAC,EAAE,aAAa,EAAE,CAAC;IACnC,8EAA8E;IAC9E,SAAS,CAAC,EAAE,aAAa,CAAC;IAC1B,MAAM,EAAE,MAAM,CAAC;CAChB;AAED,mFAAmF;AACnF,MAAM,WAAW,4BAA4B;IAC3C,QAAQ,EAAE,OAAO,CAAC;IAClB,MAAM,EAAE,MAAM,CAAC;CAChB;AAuHD;;;;GAIG;AACH,wBAAgB,sBAAsB,CACpC,QAAQ,EAAE,OAAO,EAAE,EACnB,MAAM,EAAE,KAAK,EAAE,EACf,MAAM,EAAE,MAAM,EACd,UAAU,GAAE,aAAa,EAAO,GAC/B,4BAA4B,CAwB9B;AAED;;;;GAIG;AACH,wBAAgB,iBAAiB,CAC/B,QAAQ,EAAE,OAAO,EAAE,EACnB,MAAM,EAAE,KAAK,EAAE,EACf,UAAU,GAAE,aAAa,EAAO,EAChC,cAAc,SAAK,EACnB,SAAS,SAAK,GACb,kBAAkB,CAkGpB;AAED,wBAAgB,iBAAiB,CAC/B,QAAQ,EAAE,OAAO,EAAE,EACnB,MAAM,EAAE,KAAK,EAAE,EACf,UAAU,GAAE,aAAa,EAAO,EAChC,cAAc,SAAK,EACnB,SAAS,SAAK,EACd,QAAQ,GAAE,sBAA2B,GACpC,sBAAsB,CA0BxB;AAED;;;;GAIG;AACH,MAAM,WAAW,sBAAsB;IACrC,MAAM,EAAE,MAAM,CAAC;IACf,cAAc,EAAE,MAAM,CAAC;IACvB,WAAW,EAAE,MAAM,CAAC;CACrB;AAED;;;;;;GAMG;AACH,MAAM,WAAW,sBAAsB;IACrC,IAAI,EAAE,MAAM,CAAC;IACb,UAAU,EAAE;QACV,MAAM,EAAE,MAAM,CAAC;QACf,OAAO,EAAE,MAAM,CAAC;QAChB,QAAQ,EAAE,sBAAsB,GAAG,IAAI,CAAC;KACzC,CAAC;CACH;AAED;;;;GAIG;AACH,wBAAgB,2BAA2B,CAAC,MAAM,EAAE;IAClD,GAAG,EAAE,MAAM,CAAC;IACZ,KAAK,EAAE,MAAM,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,OAAO,EAAE,MAAM,CAAC;IAChB,QAAQ,EAAE,sBAAsB,GAAG,IAAI,CAAC;CACzC,GAAG,sBAAsB,CAuBzB"}

package/dist/task-selection.js

@@ -1,4 +1,3 @@
-const unavailable = new Set(["blocked", "waiting", "deferred", "canceled", "rejected"]);
 const hardUnavailable = new Set(["blocked", "deferred", "canceled", "rejected"]);
 const terminal = new Set(["done", "canceled", "rejected"]);
 const priority = (entity) => entity.priority != null ? entity.priority : Number.MAX_SAFE_INTEGER;
@@ -116,11 +115,6 @@ export function checkExplicitTaskStart(features, phases, taskId, deviations = []
         return { eligible: false, reason: "Requested task no longer exists." };
     const isTemporaryOverride = deviations.some((deviation) => (deviation.state === "approved" || deviation.state === "active")
         && deviation.temporaryTaskId === taskId);
-    const isPreservedResumeTarget = deviations.some((deviation) => (deviation.state === "approved"
-        || deviation.state === "active"
-        || deviation.state === "resume-required"
-        || deviation.state === "resolved")
-        && deviation.resumeTaskId === taskId);
     const startableStatus = candidate.task.status === "planned"
         || (candidate.task.status === "waiting" && isTemporaryOverride);
     if (!startableStatus)
@@ -160,18 +154,26 @@ export function recommendNextTask(features, phases, deviations = [], currentPhas
     const newestFirst = (left, right) => right.createdAt.localeCompare(left.createdAt);
     const resumable = (candidate) => candidate
         && (candidate.task.status === "planned" || candidate.task.status === "waiting");
-    const open = deviations
+    // "resolved" is a legacy synonym for "resume-required": both mean the
+    // temporary work has ended and the preserved task must be returned to.
+    // No live code path writes "resolved" anymore (setWorkDeviationState only
+    // ever sets "resume-required" / "resumed" / "canceled"), but every reader
+    // of persisted deviations still treats the two states identically (see
+    // recap.ts, plan-mcp/src/index.ts, plan-server/src/serve.ts, and
+    // pi-adapter/src/index.ts). Naming the pair here keeps that equivalence
+    // explicit instead of two bare string literals that look like an
+    // accidental inclusion of a "closed" state in an "open" list.
+    const returnRequiredStates = new Set(["resume-required", "resolved"]);
+    const liveDeviations = deviations
         .filter((deviation) => deviation.state === "approved"
         || deviation.state === "active"
-        || deviation.state === "resume-required"
-        || deviation.state === "resolved")
+        || returnRequiredStates.has(deviation.state))
         .sort(newestFirst);
-    const top = open[0];
+    const top = liveDeviations[0];
     if (top) {
         const temporary = byTaskId.get(top.temporaryTaskId);
         const resume = byTaskId.get(top.resumeTaskId);
-        const returnIsRequired = top.state === "resume-required"
-            || top.state === "resolved"
+        const returnIsRequired = returnRequiredStates.has(top.state)
             || (temporary && terminal.has(temporary.task.status));
         if (returnIsRequired && resume && resumable(resume)) {
             return { kind: "resume", candidate: resume, deviation: top, reason: "Resume required: return to the task preserved by the most recent deviation." };

package/dist/task-start-outcome.d.ts

@@ -1,3 +1,4 @@
+import type { ContextReadEligibility, ProjectGuidelinesReadState, RequiredContextRead } from "./read-tracking.js";
 export declare const TASK_START_ERROR_CODES: readonly ["PLAN_NOT_FOUND", "TASK_NOT_FOUND", "TASK_DONE", "PROJECT_GUIDELINES_READ_REQUIRED", "CONTEXT_READ_REQUIRED", "REQUIREMENTS_READ_REQUIRED", "START_NOT_ALLOWED", "ACTIVE_TASK_CONFLICT", "PERSISTENCE_VERIFICATION_FAILED"];
 export type TaskStartErrorCode = (typeof TASK_START_ERROR_CODES)[number];
 export interface TaskStartDeniedOutcome {
@@ -20,4 +21,29 @@ export declare function taskStartDenied(errorCode: TaskStartErrorCode, message:
     requirementIds?: string[];
 }): TaskStartDeniedOutcome;
 export declare function taskStartSucceeded(taskId: string, alreadyStarted?: boolean): TaskStartSucceededOutcome;
+/**
+ * Advisory-only readiness summary for `task_start` / `planner-task-start`,
+ * built from the exact same three checks the lifecycle gate itself runs
+ * (Project Guidelines, task/phase/feature context reads, linked
+ * requirements). `planner-task-show` / `task_get` with `full=true` attaches
+ * this so a caller sees, in the same call that reads the task, whether
+ * anything else is still outstanding before starting it — the read gate's
+ * requirements made discoverable up front instead of learned from a denial.
+ *
+ * This is read-only reporting, never enforcement: `task_start` recomputes
+ * eligibility itself at call time and stays the sole authority on whether
+ * work may begin. A `ready: true` report is not a status change and does
+ * not shortcut the gate; it can still go stale between this read and the
+ * next `task_start` call, which is exactly the edge case the gate itself
+ * (not this summary) is responsible for catching.
+ */
+export interface TaskStartGateState {
+    ready: boolean;
+    projectGuidelinesReadState: ProjectGuidelinesReadState;
+    missingReads: RequiredContextRead[];
+    missingRequirementIds: string[];
+}
+export declare function taskStartGateState(contextEligibility: ContextReadEligibility, requirementEligibility: ContextReadEligibility, projectGuidelinesReadState: ProjectGuidelinesReadState): TaskStartGateState;
+/** One line for the human-readable channel: what, if anything, `task_start` still needs. */
+export declare function taskStartGateStateLine(gate: TaskStartGateState): string;
 //# sourceMappingURL=task-start-outcome.d.ts.map

package/dist/task-start-outcome.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"task-start-outcome.d.ts","sourceRoot":"","sources":["../src/task-start-outcome.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,sBAAsB,uOAUzB,CAAC;AAEX,MAAM,MAAM,kBAAkB,GAAG,CAAC,OAAO,sBAAsB,CAAC,CAAC,MAAM,CAAC,CAAC;AAEzE,MAAM,WAAW,sBAAsB;IACrC,OAAO,EAAE,KAAK,CAAC;IACf,SAAS,EAAE,kBAAkB,CAAC;IAC9B,OAAO,EAAE,MAAM,CAAC;IAChB,WAAW,EAAE,MAAM,EAAE,CAAC;IACtB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,cAAc,CAAC,EAAE,MAAM,EAAE,CAAC;CAC3B;AAED,MAAM,WAAW,yBAAyB;IACxC,OAAO,EAAE,IAAI,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,MAAM,EAAE,aAAa,CAAC;IACtB,cAAc,EAAE,OAAO,CAAC;CACzB;AAED,MAAM,MAAM,gBAAgB,GAAG,sBAAsB,GAAG,yBAAyB,CAAC;AAElF,wBAAgB,eAAe,CAC7B,SAAS,EAAE,kBAAkB,EAC7B,OAAO,EAAE,MAAM,EACf,WAAW,EAAE,MAAM,EAAE,EACrB,OAAO,GAAE;IAAE,MAAM,CAAC,EAAE,MAAM,CAAC;IAAC,cAAc,CAAC,EAAE,MAAM,EAAE,CAAA;CAAO,GAC3D,sBAAsB,CASxB;AAED,wBAAgB,kBAAkB,CAAC,MAAM,EAAE,MAAM,EAAE,cAAc,UAAQ,GAAG,yBAAyB,CAEpG"}
+{"version":3,"file":"task-start-outcome.d.ts","sourceRoot":"","sources":["../src/task-start-outcome.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,sBAAsB,EAAE,0BAA0B,EAAE,mBAAmB,EAAE,MAAM,oBAAoB,CAAC;AAElH,eAAO,MAAM,sBAAsB,uOAUzB,CAAC;AAEX,MAAM,MAAM,kBAAkB,GAAG,CAAC,OAAO,sBAAsB,CAAC,CAAC,MAAM,CAAC,CAAC;AAEzE,MAAM,WAAW,sBAAsB;IACrC,OAAO,EAAE,KAAK,CAAC;IACf,SAAS,EAAE,kBAAkB,CAAC;IAC9B,OAAO,EAAE,MAAM,CAAC;IAChB,WAAW,EAAE,MAAM,EAAE,CAAC;IACtB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,cAAc,CAAC,EAAE,MAAM,EAAE,CAAC;CAC3B;AAED,MAAM,WAAW,yBAAyB;IACxC,OAAO,EAAE,IAAI,CAAC;IACd,MAAM,EAAE,MAAM,CAAC;IACf,MAAM,EAAE,aAAa,CAAC;IACtB,cAAc,EAAE,OAAO,CAAC;CACzB;AAED,MAAM,MAAM,gBAAgB,GAAG,sBAAsB,GAAG,yBAAyB,CAAC;AAElF,wBAAgB,eAAe,CAC7B,SAAS,EAAE,kBAAkB,EAC7B,OAAO,EAAE,MAAM,EACf,WAAW,EAAE,MAAM,EAAE,EACrB,OAAO,GAAE;IAAE,MAAM,CAAC,EAAE,MAAM,CAAC;IAAC,cAAc,CAAC,EAAE,MAAM,EAAE,CAAA;CAAO,GAC3D,sBAAsB,CASxB;AAED,wBAAgB,kBAAkB,CAAC,MAAM,EAAE,MAAM,EAAE,cAAc,UAAQ,GAAG,yBAAyB,CAEpG;AAED;;;;;;;;;;;;;;;GAeG;AACH,MAAM,WAAW,kBAAkB;IACjC,KAAK,EAAE,OAAO,CAAC;IACf,0BAA0B,EAAE,0BAA0B,CAAC;IACvD,YAAY,EAAE,mBAAmB,EAAE,CAAC;IACpC,qBAAqB,EAAE,MAAM,EAAE,CAAC;CACjC;AAED,wBAAgB,kBAAkB,CAChC,kBAAkB,EAAE,sBAAsB,EAC1C,sBAAsB,EAAE,sBAAsB,EAC9C,0BAA0B,EAAE,0BAA0B,GACrD,kBAAkB,CASpB;AAED,4FAA4F;AAC5F,wBAAgB,sBAAsB,CAAC,IAAI,EAAE,kBAAkB,GAAG,MAAM,CAWvE"}

package/dist/task-start-outcome.js

@@ -22,3 +22,26 @@ export function taskStartDenied(errorCode, message, nextActions, details = {}) {
 export function taskStartSucceeded(taskId, alreadyStarted = false) {
     return { started: true, taskId, status: "in-progress", alreadyStarted };
 }
+export function taskStartGateState(contextEligibility, requirementEligibility, projectGuidelinesReadState) {
+    const projectGuidelinesReady = projectGuidelinesReadState === "valid" || projectGuidelinesReadState === "not-required";
+    return {
+        ready: projectGuidelinesReady && contextEligibility.eligible && requirementEligibility.eligible,
+        projectGuidelinesReadState,
+        missingReads: contextEligibility.requiredReads ?? [],
+        missingRequirementIds: (requirementEligibility.requiredReads ?? []).map((read) => read.id),
+    };
+}
+/** One line for the human-readable channel: what, if anything, `task_start` still needs. */
+export function taskStartGateStateLine(gate) {
+    if (gate.ready)
+        return "task_start readiness: ready.";
+    const outstanding = [];
+    if (gate.projectGuidelinesReadState !== "valid" && gate.projectGuidelinesReadState !== "not-required") {
+        outstanding.push(`Project Guidelines (${gate.projectGuidelinesReadState})`);
+    }
+    outstanding.push(...gate.missingReads.map((read) => `${read.kind} ${read.id} (${read.state})`));
+    if (gate.missingRequirementIds.length > 0) {
+        outstanding.push(`${gate.missingRequirementIds.length} linked requirement(s)`);
+    }
+    return `task_start readiness: not ready — still needed: ${outstanding.join(", ")}.`;
+}

package/dist/text-bounds.d.ts

@@ -0,0 +1,32 @@
+/**
+ * Shared text-truncation primitive. Lives in its own module, with no
+ * dependency on handoff-context.ts or task-context.ts, because both of
+ * those files need it and importing it from either one into the other
+ * would create a cycle (handoff-context.ts already imports buildPhaseWorkMap
+ * from task-context.ts).
+ *
+ * This is the one place that decides where an oversized string breaks. Three
+ * call sites each carried their own raw `slice(0, maxChars)` before this
+ * existed — handoff prose, mutation-reply echoes, and the Accepted Decision
+ * context — and a raw slice cuts mid-word ("Ownershi|p") or mid-list-item.
+ * A fourth independent copy is not an option; every caller that needs to
+ * bound arbitrary prose for transport imports this.
+ */
+/**
+ * Truncate `value` to at most `maxChars`, cutting at the nearest paragraph
+ * break, then line break, then word boundary before the limit — never
+ * mid-word and never mid-list-item. Falls back to a hard cut at `maxChars`
+ * only when no boundary exists before it (e.g. one word longer than the
+ * limit), so the result is never empty when `maxChars > 0`.
+ */
+export declare function truncateAtSafeBoundary(value: string, maxChars: number): string;
+/** Truncate `content` to at most `maxChars` at a safe boundary (see
+ * truncateAtSafeBoundary) and report whether a cut happened. Callers append
+ * their own contextual continuation message — this stays message-agnostic
+ * so every caller shares one truncation rule without sharing wording that
+ * fits only one of them. */
+export declare function boundedContentForTransport(content: string, maxChars: number): {
+    content: string;
+    truncated: boolean;
+};
+//# sourceMappingURL=text-bounds.d.ts.map

package/dist/text-bounds.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"text-bounds.d.ts","sourceRoot":"","sources":["../src/text-bounds.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAEH;;;;;;GAMG;AACH,wBAAgB,sBAAsB,CAAC,KAAK,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,MAAM,CAS9E;AAED;;;;4BAI4B;AAC5B,wBAAgB,0BAA0B,CAAC,OAAO,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG;IAAE,OAAO,EAAE,MAAM,CAAC;IAAC,SAAS,EAAE,OAAO,CAAA;CAAE,CAGrH"}

package/dist/text-bounds.js

@@ -0,0 +1,43 @@
+/**
+ * Shared text-truncation primitive. Lives in its own module, with no
+ * dependency on handoff-context.ts or task-context.ts, because both of
+ * those files need it and importing it from either one into the other
+ * would create a cycle (handoff-context.ts already imports buildPhaseWorkMap
+ * from task-context.ts).
+ *
+ * This is the one place that decides where an oversized string breaks. Three
+ * call sites each carried their own raw `slice(0, maxChars)` before this
+ * existed — handoff prose, mutation-reply echoes, and the Accepted Decision
+ * context — and a raw slice cuts mid-word ("Ownershi|p") or mid-list-item.
+ * A fourth independent copy is not an option; every caller that needs to
+ * bound arbitrary prose for transport imports this.
+ */
+/**
+ * Truncate `value` to at most `maxChars`, cutting at the nearest paragraph
+ * break, then line break, then word boundary before the limit — never
+ * mid-word and never mid-list-item. Falls back to a hard cut at `maxChars`
+ * only when no boundary exists before it (e.g. one word longer than the
+ * limit), so the result is never empty when `maxChars > 0`.
+ */
+export function truncateAtSafeBoundary(value, maxChars) {
+    if (maxChars <= 0)
+        return "";
+    if (value.length <= maxChars)
+        return value;
+    const slice = value.slice(0, maxChars);
+    const paragraphBreak = slice.lastIndexOf("\n\n");
+    const lineBreak = slice.lastIndexOf("\n");
+    const wordBreak = slice.lastIndexOf(" ");
+    const cut = paragraphBreak >= 0 ? paragraphBreak : lineBreak >= 0 ? lineBreak : wordBreak >= 0 ? wordBreak : maxChars;
+    return slice.slice(0, cut).trimEnd();
+}
+/** Truncate `content` to at most `maxChars` at a safe boundary (see
+ * truncateAtSafeBoundary) and report whether a cut happened. Callers append
+ * their own contextual continuation message — this stays message-agnostic
+ * so every caller shares one truncation rule without sharing wording that
+ * fits only one of them. */
+export function boundedContentForTransport(content, maxChars) {
+    if (content.length <= maxChars)
+        return { content, truncated: false };
+    return { content: truncateAtSafeBoundary(content, maxChars), truncated: true };
+}

package/dist/write-coordination.d.ts

@@ -19,8 +19,8 @@ export declare class PlanWriterBusyError extends Error {
 }
 /**
  * Serialize one logical planner mutation across processes for a planner root.
- * Nested writes in the same async transaction are re-entrant. Reads never take
- * this lock, so secondary processes remain available for inspection.
+ * Nested writes in the same async transaction are re-entrant. Reads never
+ * take this lock, so secondary processes remain available for inspection.
  */
 export declare function withPlanRootWriteLock<T>(root: string, fn: () => Promise<T>): Promise<T>;
 export {};

package/dist/write-coordination.js

@@ -203,8 +203,8 @@ async function acquirePlanRootLock(planRoot) {
 }
 /**
  * Serialize one logical planner mutation across processes for a planner root.
- * Nested writes in the same async transaction are re-entrant. Reads never take
- * this lock, so secondary processes remain available for inspection.
+ * Nested writes in the same async transaction are re-entrant. Reads never
+ * take this lock, so secondary processes remain available for inspection.
  */
 export async function withPlanRootWriteLock(root, fn) {
     const planRoot = resolve(root);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-plan/core",
-  "version": "0.2.29",
+  "version": "0.3.0",
   "private": false,
   "description": "Harness-agnostic core for Agent Plan: schemas, persistence, ordering, status rollups, and markdown rendering.",
   "license": "MIT",

package/planner-skill.md

@@ -13,6 +13,7 @@ This is the canonical, project-local operating guide for Agent Plan. A managed c
 - Starting only the dashboard does not enable planner context. Pi uses `planner-web`; MCP uses `planner-web`.
 - Stop Pi planner context and its dashboard with `/planner stop`, `planner-stop`, or `/planner disable`. For MCP, `planner-disable` explains how to disable the server.
 - `.planner/` is the operational source of truth. Keep feature, phase, task, requirement, decision, checklist, handoff, and Project Guidelines state synchronized with completed work.
+- Explicit planner load (`/planner load`, `planner-load`) delivers the complete project-level context in one attested read: description, goal, scope, out-of-scope, technologies, tools, language preferences, Project Guidelines, every Requirement, and every project Accepted Decision. Check the result's `contextComplete`/`loaded` field; only `true` proves the project-level context was actually delivered — a bounded response, an omitted field, or a truncated first chunk never proves a full read. If `false`, follow the returned `nextActions` (retry with a larger `maxChars`) before relying on it. `task_start` / `planner-task-start` stays scoped to feature/phase/task context and does not redeliver project-level context; if it changed since your last planner load, task start returns a non-blocking project-context advisory telling you to reload.
 - Planner metadata operations are not code edits. Code, configuration, repository, dependency, or environment changes still require the project’s own approval rules.
 - The Web UI is a human-supervisor surface. It may bypass agent-only governance or motivation gates. Agents must not imitate its source header or treat its exemptions as an agent bypass.
 
@@ -31,24 +32,26 @@ Discover before mutating:
 1. List features, phases, or tasks using compact list tools.
 2. Follow the lowest visible ready priority unless the automatic recommendation or an approved deviation says otherwise.
 3. Use `task_recommend` / `planner-task-recommend` when choosing the next task. Treat its `claims` as bounded evidence: priority is a policy signal, a handoff is actionable only when persisted `resumeReady=true`, and Markdown prose or terminal archives never create an action claim.
-4. Read the exact entity with its full-detail show/get surface when full context is needed.
-5. Never infer an ambiguous bare reference. Ask for the exact composite reference.
-6. Never claim that no task is active from counts, feature summaries, or omitted task detail. Use an explicit `activeTaskState`/`activeTasks` result from `plan_get`, `planner-show`, or the lifecycle recommendation. Only `activeTaskState: none` (verified from all persisted task statuses) proves absence; `conflict` means multiple active tasks must be reconciled.
+4. A task that comes up in conversation is not the next task. Discussing a subject, describing a capability, or naming a task is not an instruction to work on it: the recommendation decides what is next, and a task already in progress stays in progress. When the conversation suggests other work is more valuable, propose it as an explicit deviation with its reason and wait for a decision, or record the change through `task_switch` / `task_deviation`. Being told directly to work on something is an instruction — follow it, and it needs no ceremony.
+5. Read the exact entity with its full-detail show/get surface when full context is needed.
+6. Never infer an ambiguous bare reference. Ask for the exact composite reference.
+7. Never claim that no task is active from counts, feature summaries, or omitted task detail. Use an explicit `activeTaskState`/`activeTasks` result from `plan_get`, `planner-show`, or the lifecycle recommendation. Only `activeTaskState: none` (verified from all persisted task statuses) proves absence; `conflict` means multiple active tasks must be reconciled.
 
 Feature and phase statuses are derived from their children. Do not write their status directly; update the relevant child tasks. A `DERIVED_STATUS_READ_ONLY` result is a non-success result.
 
 ## Lifecycle-first context protocol
 
-Before touching code, call `task_start` / `planner-task-start`, or use `task_switch` / `planner-task-switch` when another task is already active. The lifecycle tool may deny the transition and return typed diagnostics.
+Read before you call the lifecycle tool; do not use a denial to discover what to read. Before touching code:
 
-When denied:
+1. Read the exact task with `task_get` / `planner-task-show` (`full=true`). Its response reports `taskStartGateState` and, when anything is still outstanding, `taskStartNextActions` — the same checks `task_start` itself runs, seen up front instead of from a rejection.
+2. Perform the reads that state still lists as outstanding: the parent phase with `full=true`; the parent feature with `full=true`, when there is one; `project_guidelines_show` / `planner-project-guidelines-show`, when Project Guidelines are listed; and `requirement_list` / `planner-requirement-list` with the exact `phaseRef` given, when linked requirements are listed — a broad unscoped inventory does not attest that every requirement was read. Reads may be completed in any order, and fresh unchanged feature, phase, and linked-requirement reads may be reused across sibling tasks in the same session, so this is usually few or none of these, not a fixed list per task. A full feature/phase/task read is complete only when it delivers all canonical Accepted Decision fields (`id`, `title`, `decision`, `rationale`, `implementationNotes`, `acceptedAt`); title-only summaries never satisfy the read gate.
+3. Use the phase's task list or the task's own sibling refs to review sibling task goals, dependencies, statuses, and remaining capability ownership. Before proposing or creating work, reread the canonical phase and the relevant sibling task full view; never duplicate a capability already owned by another task.
+4. Call `task_start` / `planner-task-start`, or `task_switch` / `planner-task-switch` when another task is already active.
+
+`task_start` still checks every read itself at call time and denies the transition with typed diagnostics if anything is missing or has gone stale since — this is the enforcement, and it is a safety net for a stale or skipped read, not the step that is supposed to teach you what to read. If it denies:
 
 1. Confirm `started` is `false` and read `errorCode` plus `nextActions`.
-2. Perform only the missing or stale reads listed in `nextActions`. Reads may be completed in any order within the current session.
-3. If Project Guidelines are listed, call `project_guidelines_show` or `planner-project-guidelines-show` and retain the content while working.
-4. Read each task on every start or resume. Fresh unchanged feature, phase, and linked-requirement reads may be reused across sibling tasks in the same session. When linked requirements are requested, call `requirement_list` or `planner-requirement-list` with the exact `phaseRef` from `nextActions`; a broad unscoped inventory does not attest that every requirement was read. A full feature/phase/task read is complete only when it delivers all canonical Accepted Decision fields (`id`, `title`, `decision`, `rationale`, `implementationNotes`, `acceptedAt`); title-only summaries never satisfy the read gate.
-5. Use the returned priority-ordered phase work map to review sibling task refs, goals, dependencies, statuses, and remaining capability ownership. Before proposing or creating work, reread the canonical phase and the relevant sibling task full view; never duplicate a capability already owned by another task.
-6. Retry the lifecycle operation. Only `started: true` proves work is active.
+2. Perform only the missing or stale reads listed in `nextActions`, then retry. Only `started: true` proves work is active.
 
 Do not convert a denial into a planner status change merely to bypass the gate. Common typed denials include `PROJECT_GUIDELINES_READ_REQUIRED`, `CONTEXT_READ_REQUIRED`, `REQUIREMENTS_READ_REQUIRED`, `START_NOT_ALLOWED`, `ACTIVE_TASK_CONFLICT`, `TASK_DONE`, and persistence verification failures.
 
@@ -63,6 +66,16 @@ Do not convert a denial into a planner status change merely to bypass the gate.
 - Explicit planner load automatically and atomically deduplicates legacy `globalRules`, textual `workflowRules`, and project `decisions` into canonical Project Guidelines and Accepted Decisions before recap/context delivery. Ordinary entity reads remain non-mutating. `project_context_migrate` and `planner-project-context-migrate` remain manual preview/recovery diagnostics; repeated applications are idempotent.
 - The Web UI may display the section for the human supervisor, but guideline-read enforcement applies to agents.
 
+## Accepted Decision ownership
+
+A decision has exactly one owner: the project when it is project-wide, a feature when it is feature-wide, a phase when it is phase-specific, or a task when the decision is genuinely local to that task's work and will not outlive it. Never record the same decision on more than one owner — there is no default that duplicates a decision across scopes.
+
+- Record every new decision or user-agreed modification with `accepted_decision_create` / `planner-accepted-decision-create` on that single owner, choosing `targetType` (`project`, `feature`, `phase`, or `task`) by where the decision actually belongs, not by where the discussion happened to take place. A project-wide decision discovered while a task is active still goes to the project, not the task.
+- `accepted_decision_update` / `planner-accepted-decision-update` and `accepted_decision_delete` / `planner-accepted-decision-delete` (confirmation-required) mutate one decision on its existing owner in place; they never move a decision to a different owner or replace the full array.
+- `decision_record` (Pi) is a deprecated, write-disabled compatibility tool. It performs no write and no longer duplicates a decision across a feature and a phase; it resolves the given feature/phase and returns guidance to call `accepted_decision_create` with the correct single owner instead.
+- The legacy free-form `decisions` array (project, phase, task) is read-only history. Supplying it to an update tool is rejected (`LEGACY_DECISIONS_ARRAY_READ_ONLY`); it is not decision authority and is never treated as satisfying a decision-record requirement. The same applies to a description, notes, a status log, or a handoff completion summary — any of these may reference a canonical decision's id, but none of them is the record itself.
+- A completed or archived owner still shows its Accepted Decisions on read; completion never hides them. A decision recorded against a task that is later deleted is deleted with it — record project/feature/phase-durable decisions on an owner that will outlive the task.
+
 ## Task execution
 
 - Create rich feature, phase, and task descriptions with current state, concrete goals, relevant systems, file/symbol references, behaviors to preserve, and edge cases.
@@ -101,8 +114,12 @@ The resume-critical content is: exact focus and resume point; current/partial st
 
 Write the canonical handoff as a compact resume capsule targeting at most 8,000 inline characters (24,000 remains only as an absolute compatibility ceiling). Keep inline only the exact focus, current/partial state, decisions or constraints, relevant verification, blockers, and ordered resume steps. Put extended detail in `.planner/docs/` only when the next agent genuinely needs it; externalization is automatic and does not require a manual inventory.
 
+The `supportingDocuments` manifest is optional and usually unnecessary: content above the target length is externalized automatically, and the planner appends that entry itself. Only pass `supportingDocuments` to link a `.planner/docs/` file you created yourself. If you already know that manifest before drafting, pass it to `handoff_prepare` / `planner-handoff-prepare` too — every defect that does not depend on the drafted body (bad path, missing file, symlink, duplicate, empty file) then fails before a token is issued and before any content is transmitted, instead of costing a full resend at write time. The write-time check remains the authority (it also catches a document deleted after prepare), and any `HANDOFF_SUPPORTING_DOCUMENT_INVALID` failure names dropping the field as a valid retry.
+
 Then call `handoff_write` / `planner-handoff-write` once with the preparation token, structured `reason`, compact capsule, optional supporting-document manifest, and reconciled task/phase/feature context. Missing preflight/reason, unresolved placeholders, invalid documents, or failed persistence read-back are typed failures and must never be reported as success.
 
+If a write fails for any reason, the planner retains the exact capsule you submitted against that phase and preparation token. **Do not redraft or resend `content`/`markdown_content` on the retry** — fix only what the error named (a missing field, a stale token needs a fresh `handoff_prepare`, a corrected supporting-document manifest, etc.) and call `handoff_write` again with the same `expectedHandoffUpdatedAt`, omitting `content`; the retained capsule is reused automatically. Only pass `content` again if you are deliberately changing the body — the new one replaces the retained one. Omitting it when nothing was ever retained for that exact phase + token (a first attempt, an aged-out draft, or a phase that has since gone terminal) is itself a typed failure (`HANDOFF_RETAINED_CONTENT_NOT_FOUND`) naming the fix. A stale token is still refused even when a capsule is retained for it — retention makes the retry cheap, it never lets outdated content overwrite newer state.
+
 A successful write persists only a **handoff candidate** and returns `resumeReady: false`. Immediately call `handoff_show` / `planner-handoff-show` with the exact phase reference and read the persisted capsule. If the capsule omits resume-critical context, rewrite it; otherwise call `handoff_verify` / `planner-handoff-verify` with the content hash. Source reviews and omission lists are optional legacy evidence; the planner derives them when omitted. Only a successful verification result with `resumeReady: true` authorizes telling the user that the handoff is resume-ready.
 
 `handoff_list` is a compact paginated index of active handoffs and exposes whether each is resume-ready. Use `handoff_show` for one bounded active body and its metadata; after phase completion/rejection/cancellation, the same exact phase-scoped show call returns the latest terminal archive so its closeout and `.planner/docs/` references remain discoverable. Clear/archive only after explicit intent or when phase completion makes the handoff non-operational.
@@ -167,6 +184,7 @@ Supported interactive command paths:
 - `/planner task delete <P00x(F00x)/T00x>`
 - `/planner task start <P00x(F00x)/T00x>`
 - `/planner task complete <P00x(F00x)/T00x>`
+- `/planner task recommend`
 - `/planner task checklist-add <task> <title>`
 - `/planner task checklist-remove <task> <C{n}|id|title>`
 - `/planner task checklist-toggle <task> <C{n}|id|title> [on|off]`
@@ -178,7 +196,7 @@ Supported interactive command paths:
 
 `handoff_verify` is an agent tool rather than an interactive command; call it only after `handoff_show` completes the separate persisted read-back.
 
-Pause, switch, deviation, recommendation, requirement, and decision operations are available through the registered Pi tools below rather than every interactive `/planner` path.
+Pause, switch, deviation, requirement, and decision operations are available through the registered Pi tools below rather than every interactive `/planner` path. Recommendation has both: `/planner task recommend` for a person at the command line, `task_recommend` for an agent.
 
 ### Dashboard, export, and guard
 
@@ -210,7 +228,7 @@ The Pi adapter registers these tools:
 - Project and requirements: `project_set_language_preferences`, `project_update`, `project_guidelines_show`, `project_guidelines_update`, `project_context_migrate`, `accepted_decision_create`, `accepted_decision_update`, `accepted_decision_delete`, `requirement_list`, `requirement_create`, `requirement_update`, `requirement_delete`.
 - Plan: `plan_init`, `plan_get`, `description_freshness`, `plan_render`, `plan_repair`, `plan_cleanup_orphan_phases`, `plan_authorize_bypass`, `plan_clear_bypass`.
 - Features: `feature_list`, `feature_get`, `feature_create`, `feature_discuss`, `feature_update`, `feature_delete`.
-- Phases and decisions: `phase_list`, `phase_get`, `phase_create`, `phase_discuss`, `phase_update`, `phase_delete`, `decision_record`.
+- Phases: `phase_list`, `phase_get`, `phase_create`, `phase_discuss`, `phase_update`, `phase_delete`, `decision_record` (deprecated, write-disabled compatibility redirect — see Accepted Decision ownership).
 - Tasks: `task_list`, `task_get`, `task_create`, `task_update`, `task_dependency_add`, `task_dependency_delete`, `task_delete`, `task_recommend`, `task_deviation`, `task_pause`, `task_switch`, `task_start`, `task_reopen`, `task_complete`, `task_checklist_toggle`, `task_checklist_add`, `task_checklist_remove`.
 - Handoffs: `handoff_list`, `handoff_show`, `handoff_prepare`, `handoff_write`, `handoff_verify`, `handoff_clear`.
 - Dashboard and lifecycle: `planner-web`, `planner-load`, `planner-stop`.