taskchef 5.11.2 → 6.0.0

package/skills/taskchef-delegate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: taskchef-delegate
-description: "Dispatch actionable requests through the per-user TaskChef workspace into independently openable Codex project tasks. Use automatically for actionable work received in the canonical TaskChef dispatcher workspace. From any other project, use only when the user explicitly asks to delegate or split separate work into Codex tasks; TaskChef-related subject matter alone is not delegation intent. Record before creation, resolve provisional identity by exact marker within a strict bound, and never wait for executor completion."
+description: "Dispatch actionable requests through the per-user TaskChef workspace into independently openable Codex project tasks. Use automatically for actionable work received in the canonical TaskChef dispatcher workspace. From any other project, use only when the user explicitly asks to delegate or split separate work into Codex tasks; TaskChef-related subject matter alone is not delegation intent. Record before creation, require executor self-linking, and never wait for executor completion."
 ---
 
 # TaskChef Delegate
@@ -12,154 +12,76 @@ and return immediately.
 
 A task whose initial structured `codexDelegation.input` starts with an exact
 `<!-- taskchef_id=<full UUID> -->` marker already owns that delegated
-assignment. Execute the assignment in the current task. Do not re-dispatch it
-merely because it concerns TaskChef or a configured project.
+assignment. Execute it in the current task. Do not re-dispatch it merely
+because it concerns TaskChef or a configured project. Explicit requests to
+delegate separate work remain valid.
 
-This does not prevent the task from using TaskChef later. Use this skill
-normally when the initial assignment explicitly asks to delegate separate
-work, or when the user later explicitly requests a new delegation.
-
-Use the bundled TaskChef `prepare_dispatch`, `record_task`, `resolve_task`, and `report_result`
-tools for deterministic workspace and task-record operations. Call them
-directly; never probe for them or fall back to shell CLI writes. If a required
-tool is unavailable, stop and report that the TaskChef plugin must be reloaded
-or reinstalled. Resolve the plugin root from this skill only when writing an
-explicitly requested benchmark artifact.
+Use the bundled `prepare_dispatch`, `record_task`, `link_task`, and
+`report_result` MCP tools directly. Never fall back to shell writes. If a
+required tool is unavailable, stop and report that the TaskChef plugin must be
+reloaded or installed.
 
 ## Boundaries
 
-- Keep implementation, tests, and reports in the TaskChef source repository.
-- Keep only `AGENTS.md`, `taskchef.json`, and `tasks.jsonl` in a dispatcher
+- Keep only `AGENTS.md`, `taskchef.json`, and `tasks.jsonl` in the dispatcher
   workspace.
 - Use real Codex tasks, never collaboration or subagent tools.
-- Use only TaskChef's `UserPromptSubmit` hook: after identity is separately
-  verified, it records the initial turn and provides read-only current-turn
-  context on follow-up prompts. Never infer
-  lifecycle state from hooks.
-- Never use schedules, daemons, background monitors, or indefinite polling.
-  The only permitted thread discovery is the bounded exact-marker resolution
-  after a provisional creation result.
-- Never wait for delegated work after executor creation.
-- Never collect transcripts or hidden reasoning.
+- Never use hooks, schedules, daemons, background monitors, recent-task
+  searches, transcripts, hidden reasoning, or polling for identity.
+- Never wait for delegated work after native creation.
+- Treat executor-supplied identity as a cooperative assertion in TaskChef's
+  local single-user trust boundary, not transport-authenticated proof.
 
 ## Dispatch
 
 1. Split the request into the smallest independently useful outcomes. Include
    constraints, expected testing, and reporting in every instruction.
-2. In parallel, list the native Codex projects once and call `prepare_dispatch`
-   exactly once for each outcome. Every preparation produces a distinct task
-   UUID and marker; never reuse either across executors. The preparation tool
-   resolves the canonical workspace, loads and validates the configured routing targets,
-   generates the lowercase full UUID task ID, and returns `preparedAt` plus the
-   exact first-line marker. Use
-   `$taskchef-bootstrap` if the workspace is missing or unhealthy.
-   The tool resolves an absolute (or `~/`-prefixed) `TASKCHEF_WORKSPACE`, then
-   `~/.agents/taskchef`; do not substitute the current project. Reject the
-   dispatcher workspace itself as a target. Never take a pre-creation thread
-   snapshot.
-3. Classify against configured `name`, every URL in the `githubRepos` list, and
-   `description`. Use `path` only as checkout identity. Managed `*-workspace`
-   projects advertise their child or sub-repositories in this list.
-   When the prompt contains a GitHub issue or pull-request URL, canonicalize
-   its case-insensitive owner/repository identity, ignoring `http` versus
-   `https`, an optional `www`, a trailing slash or `.git`, and the issue or PR
-   suffix. Check that identity against every repository URL of every configured
-   project. Route on this evidence only when exactly one configured project
-   matches. Ask instead of guessing when no project or several projects match.
-4. Resolve the selected configured path against the already-loaded native
-   projects and require an exact match. Do not list native projects again.
-5. For each outcome, use only its corresponding task ID, preparation time, and
-   marker returned by its own preparation call.
-   Prefix the complete executor instruction with
-   exactly `<!-- taskchef_id=<full UUID> -->` as the first line, followed by a
-   blank line, this executor-role paragraph, another blank line, the result
-   paragraph below, another blank line, and the instruction body:
+2. In parallel, list native Codex projects once and call `prepare_dispatch`
+   exactly once per outcome. Never reuse a task ID or marker. Do not take a
+   pre-creation thread snapshot.
+3. Route against configured project `name`, `description`, and canonical
+   `githubRepos`; use `path` only as checkout identity. Require exactly one
+   match and an exact native-project path. Ask instead of guessing.
+4. Prefix each executor instruction with the preparation's exact marker as the
+   first line, a blank line, and these required paragraphs before the body:
 
    > This task owns the delegated assignment. Execute it in this task; do not re-dispatch it merely because it concerns TaskChef or a configured project. Explicit requests to delegate separate work remain valid.
 
-   > Before ending, call the TaskChef report_result MCP tool with completed, needs_input, or failed and a concise summary. Use needs_input only for a semantic decision or information the user must provide; a native approval prompt is live Codex state, not a TaskChef result. Do not include secrets, transcripts, or raw command output.
-
-   Preserve this
-   marked instruction for recording, and note the creation time. The exact
-   random marker is the sole correlation proof.
-6. Before creating each executor, call `record_task` exactly once with `id`,
-   `project`, `title`, the marked `instruction`, and `threadId: null`. This
-   closes the hook race: the entry exists before the executor can submit its
-   initial prompt.
-7. Create one real Codex task using the exact configured project, a local
-   environment on its executor host, the marked instruction, and a short title.
-8. If creation returns a durable `threadId`, call `resolve_task` immediately.
-   If creation returns only `clientThreadId`, `pendingWorktreeId`, or a `local:`
-   ID, retain it only for the created-thread directive and run this one bounded
-   identity-resolution sequence:
-   - Check immediately, then at 10 and 30 seconds after creation. At each
-     checkpoint, call the native recent-task listing once.
-   - Restrict candidates to Codex tasks created no earlier than five seconds
-     before `preparedAt`, on the returned host and selected project when those
-     fields are available. Prefer the exact title only as an ordering hint.
-   - Read each remaining bounded candidate at most once per checkpoint and
-     accept only the single task whose structured initial
-     `codexDelegation.input` begins with this outcome's exact marker.
-   - Call `resolve_task` only for that one verified durable child ID. Never use
-     `session_id`, a source/parent ID, title similarity, or a provisional ID as
-     identity proof.
-   - Stop at 30 seconds. Zero matches remain unresolved; multiple exact matches
-     are an ambiguity and also remain unresolved. Never guess or continue
-     polling.
-
-   The initial hook may wait for this canonical record transition so it can
-   inject the verified child ID and current turn ID. Codex documents that
-   subagent hooks receive the parent `session_id`, so the hook must never write
-   that field into `threadId`.
-
-9. If executor creation fails, call `report_result` for the already-recorded
-   task with `failed`, null thread/turn IDs, and a concise creation error.
-10. Emit the appropriate created-thread directive and return after the bounded
-    identity step.
-    Treat a nullable record as preserved but not yet linked. Do not read an
-    executor for progress and never wait for executor work completion.
-
-The bundled structured tools are the only dispatch-time path to the canonical
-workspace. They reuse the same exact-field validation, locking, atomic writes,
-and one-way nullable resolution as the CLI without shell parsing, stdin, or
-per-command filesystem escalation. The package exports repository routing,
-marker, and record-before-create orchestration helpers for deterministic tests.
-Keep the CLI for bootstrap, manual inspection, and recovery outside delegation.
-
-## Later resolution
-
-The trusted initial hook never resolves identity from its `session_id`. It uses
-only the child ID already stored by immediate or bounded exact-marker
-resolution. For manual recovery, require one exact structured marker match,
-then call `resolve_task` once. Never edit `tasks.jsonl` directly. Resolution is
-an idempotent one-way transition from `threadId: null` to one unique durable
-child thread ID.
-
-## Legacy benchmark compatibility
-
-The schema-v1 benchmark fixtures below describe the removed snapshot resolver
-and remain only for historical-result validation. Do not use that resolver for
-new delegation benchmarks. A future benchmark schema should measure record,
-creation, bounded exact-marker resolution, and result callback without
-indefinite polling. The
-legacy fixture starts from
-`<plugin-root>/assets/e2e-benchmark-example.json`. Capture one ISO start/end
-interval for the parallel preparation/project-list operation, followed by
-sequential non-overlapping creation, recording, and optional provisional
-resolution stages. Follow the complete schema and workflow transitions in
-`<plugin-root>/SPEC.md`; the example is the durable-success starting shape.
-Omit later stages when an earlier operation stops the workflow.
-Fallback snapshot observations additionally require `recentTaskCount`,
-`candidateCount`, `exactMatchCount`, and `resolveWriteMs`. For each snapshot,
-also record `resolveWriteOutcome` as `not-attempted`, `succeeded`, or `failed`;
-a unique match whose atomic write fails remains unresolved. After the bounded
-workflow ends, verify the canonical task record once and, when resolved, read
-the task once to verify the requested output. A failed verification remains a
-false validation flag even when the corresponding operation succeeded. Feed
-one exact JSON value to
-`node <plugin-root>/scripts/e2e-benchmark.js write <output-directory>` on closed,
-non-interactive stdin. Keep timestamped results in the TaskChef source
-repository's ignored `reports/e2e-benchmarks/` directory. Never include hidden
-reasoning or transcripts. Use the script's `clean` command before establishing
-a replacement baseline. Mark candidate filtering effective only when the
-fallback snapshot narrows reads below the complete recent-task window.
+   > Before any other work, read this executor's own durable Codex thread ID from the current task's CODEX_THREAD_ID environment value and call the TaskChef link_task MCP tool with that thread ID and the marked TaskChef task ID. Never use CODEX_SESSION_ID or the parent or delegator thread ID. If linking fails, CODEX_THREAD_ID is unavailable, or the tool is unavailable, report the failure visibly and retry on a later turn; do not guess an identity or continue substantive work while the task is link-pending.
+
+   > Before ending, call the TaskChef report_result MCP tool with the marked task ID, this executor's self-linked thread ID, the current turn ID from an exact native read of that same thread, completed, needs_input, or failed, and a concise summary. Never reuse a prior turn ID after a follow-up. Use needs_input only for a semantic decision or information the user must provide; a native approval prompt is live Codex state, not a TaskChef result. Do not include secrets, transcripts, or raw command output.
+
+5. Before creating each executor, call `record_task` exactly once with `id`,
+   `project`, `title`, the exact marked `instruction`, and `threadId: null`.
+6. Create one real Codex task using the exact configured project, an appropriate
+   native environment, the marked instruction, and a short title.
+7. Return immediately. Preserve a returned provisional client ID only for the
+   created-thread directive. Do not call `link_task` from the dispatcher even
+   when creation returns a durable ID; the child must self-link.
+8. If creation fails after recording, call `report_result` with `failed`, null
+   thread/turn IDs, and a bounded summary before returning the failure.
+
+## Executor contract
+
+The executor must make `link_task(taskId, threadId)` its first TaskChef action.
+It obtains its own durable ID from the current task's `CODEX_THREAD_ID`, never
+from the delegation's `sourceThreadId`, `CODEX_SESSION_ID`, inherited session
+metadata, title matching, or a parent task.
+Identical retries are safe. A rejected link, unavailable tool, or interrupted
+initial turn leaves the record visibly link-pending and retryable; the executor
+must not guess or do substantive work first.
+
+For every semantic result, the executor supplies its linked thread ID and the
+current turn ID obtained by reading that exact thread. A follow-up must use the
+new turn ID. Do not reuse the initial turn ID. `needs_input` is only for a real
+user decision, not live approval UI.
+
+The filesystem watcher surfaces `link_task` and `report_result` writes to the
+dashboard. The linked child ID drives the exact Codex deep link.
+
+## Legacy recovery
+
+`taskchef task resolve` exists only for unresolved records created before the
+self-linking schema. Require an exact marker match and a unique durable child
+ID. The command rejects new self-linking records. Never edit `tasks.jsonl`
+directly.

package/skills/taskchef-report/SKILL.md

@@ -47,11 +47,12 @@ all deterministic task-log operations.
 4. Treat `updatedBy: mcp`, `status: failed`, and null thread/turn IDs as a fresh
    executor-creation failure. No live read is possible or needed; report the
    stored failure summary, not unresolved. Otherwise, only a snapshot with
-   `updatedBy: mcp` is a cached semantic result. A
-   dispatcher- or hook-written `working` snapshot has no semantic callback and
-   requires one live task query when selected; if the task is inactive and no
-   callback exists, report the outcome as unknown rather than treating
-   `working` as fresh. When identity is certain and metadata says the thread is
+   `updatedBy: mcp`, a result status, a non-null summary, and a non-null turn ID
+   is a cached semantic result. Any `working` snapshot has no semantic
+   callback, including a self-linked `updatedBy: mcp` snapshot, and requires
+   one live task query when selected; if the task is inactive and no callback
+   exists, report the outcome as unknown rather than treating `working` as
+   fresh. When identity is certain and metadata says the thread is
    inactive, trust the latest MCP result by default in a broad overview. Do not
    read every idle terminal task in an overview merely because native
    `updatedAt` is later: callbacks normally run before Codex finalizes the same
@@ -74,9 +75,12 @@ all deterministic task-log operations.
    completed, failed, unresolved, or unknown. Show the cached summary when it
    remains fresh. If a newer turn exists without a callback, describe the live
    state and label the cached result stale rather than overwriting it.
-6. Never edit `tasks.jsonl` directly during reporting. The initial hook normally
-   resolves null identity; manual recovery may call `task resolve` only after
-   one exact structured marker match. Never persist inferred status,
+6. Never edit `tasks.jsonl` directly during reporting. The task API preserves
+   each record's persisted `schemaVersion`: a schema 4 null identity is executor
+   link-pending and must be retried by that executor, while a schema 1-3 null
+   identity is a legacy recovery candidate. Manual recovery may call
+   `task resolve` only for the latter after one exact structured marker match.
+   Never persist inferred status,
    transcripts, prose classifications, or hidden reasoning. Do not poll or wait.
 
 If the task history is empty, say that TaskChef has not recorded any tasks. If

package/src/cli.js

@@ -464,12 +464,13 @@ Usage:
   taskchef project remove <name> [--json] [--workspace <path>]
   taskchef dispatch prepare [--json] [--workspace <path>]
   taskchef task record [--json] [--workspace <path>]
-  taskchef task resolve <task-id> --thread-id <thread-id> [--json] [--workspace <path>]
+  taskchef task resolve <legacy-task-id> --thread-id <thread-id> [--json] [--workspace <path>]
   taskchef task show <task-id-or-8-character-prefix> [--json] [--workspace <path>]
   taskchef task list [--project <name-or-path>] [--ascending] [--full-id] [--json] [--workspace <path>]
   taskchef task summary [--json] [--workspace <path>]
 
 Task record reads one JSON value from closed, non-interactive standard input.
+Task resolve is a legacy migration command and rejects self-linking task records.
 Task show accepts a full task ID or the exact 8-character ID printed by task list.
 Task show prints human-readable details by default; --json prints the complete task object.
 Project import reads a JSON

package/src/dashboard/actions.js

@@ -0,0 +1,17 @@
+export async function openTaskFromControl(event, taskId, {
+  fetchAction = globalThis.fetch,
+  showMessage,
+} = {}) {
+  event.stopPropagation();
+  const control = event.currentTarget;
+  control.disabled = true;
+  try {
+    const response = await fetchAction(`/api/tasks/${encodeURIComponent(taskId)}/open-codex`, {
+      method: "POST",
+    });
+    const result = await response.json();
+    showMessage(result.message);
+  } finally {
+    control.disabled = false;
+  }
+}

package/src/dashboard/app.js

@@ -7,6 +7,7 @@ import {
   taskStatusLabel,
   taskWithinDateFilter,
 } from "./state.js";
+import { openTaskFromControl } from "./actions.js";
 
 const state = {
   tasks: [],
@@ -161,7 +162,18 @@ function taskCard(task) {
   const time = document.createElement("time");
   time.dateTime = task.meaningfulUpdatedAt ?? task.updatedAt ?? task.createdAt;
   time.textContent = `Updated ${formatTime(time.dateTime)}`;
-  article.append(heading, project, summary, time);
+  const footer = document.createElement("div");
+  footer.className = "task-footer";
+  const openTask = document.createElement("button");
+  openTask.type = "button";
+  openTask.className = "secondary-button task-open";
+  openTask.textContent = "Open task";
+  openTask.setAttribute("aria-label", `Open ${task.title} in Codex`);
+  openTask.addEventListener("click", (event) => openTaskFromControl(event, task.id, {
+    showMessage,
+  }));
+  footer.append(time, openTask);
+  article.append(heading, project, summary, footer);
   return article;
 }
 
@@ -251,16 +263,7 @@ elements.copyThreadId.addEventListener("click", async () => {
     showMessage("Clipboard access is unavailable. Copy the thread ID from the metadata below.");
   }
 });
-elements.openProject.addEventListener("click", async () => {
+elements.openProject.addEventListener("click", async (event) => {
   if (!state.selectedTask) return;
-  elements.openProject.disabled = true;
-  try {
-    const response = await fetch(`/api/tasks/${encodeURIComponent(state.selectedTask.id)}/open-codex`, {
-      method: "POST",
-    });
-    const result = await response.json();
-    showMessage(result.message);
-  } finally {
-    elements.openProject.disabled = false;
-  }
+  await openTaskFromControl(event, state.selectedTask.id, { showMessage });
 });

package/src/dashboard/index.html

@@ -12,7 +12,7 @@
     <header class="site-header">
       <div>
         <p class="eyebrow">TaskChef</p>
-        <h1>Task dashboard</h1>
+        <h1>TaskChef dashboard</h1>
         <p class="subtitle">Latest delegated work, updated as TaskChef reports change.</p>
       </div>
       <div class="connection" role="status" aria-live="polite">

package/src/dashboard/styles.css

@@ -74,6 +74,8 @@ select { min-width: 180px; padding: 9px 34px 9px 11px; border: 1px solid var(--b
 .task-project { margin: 3px 0 12px; font-size: 0.86rem; }
 .task-summary { max-width: 78ch; margin-bottom: 14px; }
 time { font-size: 0.78rem; }
+.task-footer { display: flex; align-items: center; justify-content: space-between; gap: 16px; }
+.task-open { flex: none; }
 
 .status { flex: none; padding: 4px 9px; border-radius: 999px; background: var(--surface-muted); color: var(--muted); font-size: 0.72rem; font-weight: 750; text-transform: capitalize; }
 .status-completed { background: var(--accent-soft); color: var(--accent); }
@@ -122,6 +124,8 @@ pre { max-height: 280px; margin: 0; padding: 14px; overflow: auto; border-radius
   .toolbar label, .toolbar select { width: 100%; }
   .task-count { margin: 0; }
   .task-heading { align-items: flex-start; }
+  .task-footer { align-items: flex-start; flex-direction: column; }
+  .task-open { width: 100%; }
   .dialog-actions { align-items: stretch; flex-direction: column; }
   .metadata { grid-template-columns: 1fr; }
   .metadata dt { padding-bottom: 0; border-bottom: 0; }

package/src/dashboard.js

@@ -37,6 +37,7 @@ const CONTENT_SECURITY_POLICY = [
 
 const STATIC_FILES = new Map([
   ["/", ["index.html", "text/html; charset=utf-8"]],
+  ["/actions.js", ["actions.js", "text/javascript; charset=utf-8"]],
   ["/app.js", ["app.js", "text/javascript; charset=utf-8"]],
   ["/state.js", ["state.js", "text/javascript; charset=utf-8"]],
   ["/styles.css", ["styles.css", "text/css; charset=utf-8"]],