taskchef 3.0.2 → 3.0.3

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "taskchef",
-  "version": "3.0.2",
+  "version": "3.0.3",
   "description": "Dispatch work from a data-only workspace to visible Codex project tasks.",
   "author": {
     "name": "Favo Yang",

package/BACKLOG.md

@@ -39,3 +39,18 @@ clear data model before implementation.
 - Evaluate automatic project discovery rules and exclusions.
 - Consider multiple executor threads for one logical assignment if a real
   workflow requires it.
+
+## Codex provisional thread lifecycle
+
+- Track [openai/codex#26861](https://github.com/openai/codex/issues/26861),
+  where worktree creation can return only a provisional `clientThreadId` or
+  `pendingWorktreeId` with no supported mapping to the durable `threadId`.
+- Prefer an official bounded operation such as
+  `wait_for_thread(clientThreadId, timeoutMs) -> { status, threadId? }` or
+  `resolve_client_thread(clientThreadId) -> { status, threadId? }`. Returning a
+  reserved durable ID from `create_thread`, or emitting a materialization event
+  containing it, would also close the lifecycle gap.
+- Re-evaluate TaskChef's sparse marker-discovery fallback when Codex exposes
+  one of these APIs. Keep exact marker verification before persisting the
+  returned durable ID unless the official contract provides equivalent
+  correlation guarantees.

package/README.md

@@ -117,9 +117,18 @@ the same project.
 Open an executor and prompt it like any other Codex task. Its thread is the
 live source of truth for progress, questions, and results.
 
-The dispatcher workspace keeps `tasks.jsonl`, an append-only history of
-successful delegations. It records what TaskChef sent, when it sent it, which
-project it selected, and which Codex task received the work.
+The dispatcher workspace keeps `tasks.jsonl`, a history of submitted
+delegations. New tasks are appended; the only later change allowed is filling
+an unresolved task's nullable thread ID. The log records what TaskChef sent,
+when it sent it, which project it selected, and which Codex task received the
+work.
+
+Every delegated instruction includes a unique `# taskchef_id=<UUID>` marker.
+If worktree creation does not return a thread ID immediately, TaskChef records
+the marked delegation as unresolved, then waits briefly for the durable task.
+It prefers a native Codex client-ID resolver when available and otherwise makes
+two exact-marker checks during a short bounded window. If it still cannot
+identify exactly one task, the recorded marker remains available for recovery.
 
 ### Ask for a live report
 
@@ -161,8 +170,9 @@ project metadata that TaskChef used when it delegated the work.
 
 - TaskChef is an interactive dispatcher. It is not a scheduler, daemon, hook
   service, or background worker.
-- Executors are visible Codex tasks. The dispatcher does not supervise them or
-  wait for them to finish.
+- Executors are visible Codex tasks. The dispatcher may wait briefly to resolve
+  a worktree task's thread ID, but it does not supervise executors or wait for
+  them to finish.
 - TaskChef routes only to projects on the same local execution host.
 - The task history contains successful delegations, not current task status or
   task results.
@@ -213,6 +223,7 @@ taskchef project import [<file> | -]
 taskchef project list
 taskchef project remove <name>
 taskchef task record
+taskchef task resolve <task-id> --thread-id <thread-id>
 taskchef task show <task-id>
 taskchef task list
 taskchef task summary
@@ -250,14 +261,24 @@ set.
 
 ### Task history
 
-`task record` reads one successful delegation from standard input. The
+`task record` reads one submitted delegation from standard input. The
 `project` value is the exact configured project path:
 
 ```sh
-printf '%s\n' '{"id":"t1","project":"/workspace/payments","title":"Add retry logs","instruction":"Add structured logs for failed retries and test them.","threadId":"019f..."}' |
+printf '%s\n' '{"id":"c0f010ff-84f2-4838-a69d-0ff1f5d721d7","project":"/workspace/payments","title":"Add retry logs","instruction":"# taskchef_id=c0f010ff-84f2-4838-a69d-0ff1f5d721d7\n\nAdd structured logs for failed retries and test them.","threadId":"019f..."}' |
   taskchef task record --json --workspace <workspace>
 ```
 
+If a task has `threadId: null`, Codex can later find its exact marker and pass
+the verified durable ID to the CLI. Resolution is atomic and only permits the
+one-way transition from null to one unique thread ID:
+
+```sh
+taskchef task resolve c0f010ff-84f2-4838-a69d-0ff1f5d721d7 \
+  --thread-id 019f9d46-f42c-7482-9707-3c107bf241ee \
+  --workspace <workspace>
+```
+
 Inspect the task history without querying Codex tasks:
 
 ```sh

package/SPEC.md

@@ -3,8 +3,9 @@
 ## Purpose
 
 TaskChef is an interactive Codex dispatcher. It routes independent assignments
-to real Codex tasks in configured local projects, records each successful
-delegation in an append-only task history, and returns immediately.
+to real Codex tasks in configured local projects, records each submitted
+delegation in a task history, and returns immediately. New tasks append; only a
+nullable thread ID may later transition to its durable value.
 
 Codex tasks remain authoritative for their progress and results. TaskChef does
 not maintain a second lifecycle database.
@@ -16,8 +17,10 @@ not maintain a second lifecycle database.
 3. It selects each target using configured project metadata and validates the
    selected local path.
 4. It creates an independently openable Codex task in that project.
-5. After creation returns a thread ID, it appends one task entry.
-6. It returns without waiting for the executor.
+5. It embeds a generated TaskChef UUID marker in the initial instruction before
+   creation. It appends one task entry as soon as creation returns, using
+   `threadId: null` while a provisional client ID is briefly resolved.
+6. It returns without waiting for executor work to complete.
 7. When requested, TaskChef can read task entries, query the relevant Codex
    tasks once, and present a live report without persisting the fetched state.
 
@@ -38,15 +41,11 @@ live report requests to `$taskchef-report`. Bootstrap preserves unrelated
 instructions and refreshes only the managed block.
 
 `workspace init` is idempotent. It creates an empty configuration and task
-log when missing, refreshes managed instructions, removes legacy TaskChef skill
-symlinks, and migrates legacy task records that contain executor thread IDs.
-It stops on a legacy pending record with no thread ID rather than discarding
-that record. If a legacy record refers to a project that was removed from the
-configuration, migration reconstructs its project snapshot from the existing
-local project path.
+log when missing, refreshes managed instructions, and removes legacy TaskChef
+skill symlinks.
 
 `doctor` validates configuration, project paths, the JSONL log, managed
-instructions, and the absence of legacy workspace structures without modifying
+instructions, and the absence of legacy TaskChef skill links without modifying
 the workspace.
 
 ## Project configuration
@@ -101,22 +100,30 @@ schedules, task status, results, host information, or the workspace path.
 `tasks.jsonl` contains one compact JSON object per line, in append order:
 
 ```json
-{"schemaVersion":1,"id":"d1-retry-logs","project":{"name":"payments-api","path":"/workspace/payments-api","isGitRepository":true,"githubRepo":"https://github.com/example/payments-api","description":"Owns payment authorization, capture, refunds, and provider integrations."},"title":"Add payment retry logs","instruction":"Add structured logs for failed payment retries and test them.","threadId":"019f9d46-f42c-7482-9707-3c107bf241ee","createdAt":"2026-08-08T10:00:00.000Z"}
+{"schemaVersion":1,"id":"c0f010ff-84f2-4838-a69d-0ff1f5d721d7","project":{"name":"payments-api","path":"/workspace/payments-api","isGitRepository":true,"githubRepo":"https://github.com/example/payments-api","description":"Owns payment authorization, capture, refunds, and provider integrations."},"title":"Add payment retry logs","instruction":"# taskchef_id=c0f010ff-84f2-4838-a69d-0ff1f5d721d7\n\nAdd structured logs for failed payment retries and test them.","threadId":"019f9d46-f42c-7482-9707-3c107bf241ee","createdAt":"2026-08-08T10:00:00.000Z"}
 ```
 
 - `schemaVersion` identifies the task entry format.
 - `id` is a unique TaskChef task identifier.
 - `project` is the complete configured project snapshot used for routing.
 - `title` is a short task name.
-- `instruction` is the complete executor instruction.
-- `threadId` identifies the created Codex task.
+- `instruction` is the complete executor instruction, including its first-line
+  `# taskchef_id=<full UUID>` correlation marker.
+- `threadId` identifies the created Codex task, or is `null` when creation was
+  accepted but bounded marker resolution did not find one durable task ID.
 - `createdAt` is the dispatch time as an ISO 8601 timestamp.
 
-Every entry has exactly these fields. IDs and thread IDs must be unique. The
-file is empty or newline terminated, with no blank lines. TaskChef rejects a
-malformed log instead of skipping bad entries. Writers replace the complete
-validated file atomically under a workspace lock, so an interrupted write
-leaves either the old history or the complete new history.
+Every entry has exactly these fields. IDs and non-null thread IDs must be
+unique; any number of unresolved entries may have `threadId: null`. The file is
+empty or newline terminated, with no blank lines. TaskChef rejects a malformed
+log instead of skipping bad entries. Writers replace the complete validated
+file atomically under a workspace lock, so an interrupted write leaves either
+the old history or the complete new history.
+
+Task creation appends entries. The only permitted mutation is an atomic,
+idempotent `task resolve` transition from `threadId: null` to one unique durable
+thread ID. Resolution requires the stored instruction's exact marker to match
+the task ID. A resolved or mismatched entry cannot be overwritten.
 
 The project snapshot preserves the route even if the project is renamed,
 moved, or removed later. Entries never contain status, result, transcript,
@@ -128,9 +135,41 @@ For each assignment, `$taskchef-delegate`:
 
 1. loads and validates configured projects
 2. selects one unambiguous target
-3. creates a real Codex task at the exact configured path
-4. appends a task entry only after receiving the task's thread ID
-5. returns the created task link without reading or waiting for that task.
+3. generates a full UUID and prefixes the instruction with its exact
+   `# taskchef_id=<UUID>` marker
+4. creates a real Codex task at the exact configured path
+5. appends a task entry immediately when creation returns a durable thread ID
+6. when creation returns only a provisional client ID, immediately appends the
+   marked entry with `threadId: null`, then prefers one native client-ID wait or
+   resolution call with a 30-second timeout when Codex exposes one
+7. when no native operation is available, takes at most two recent-thread
+   snapshots near 10 and 30 seconds after the provisional result, filters
+   candidates by available host/project/time/worktree metadata, uses title only
+   as an advisory ordering hint, and accepts only one thread whose structured
+   delegated input starts with the exact marker
+8. atomically fills the nullable thread ID after an exact match
+9. returns after recording or after reporting that bounded resolution was
+   unresolved, without waiting for executor work completion.
+
+The exact random marker makes a pre-creation thread snapshot unnecessary.
+Creation-time filtering allows five seconds of clock skew. Candidate reads run
+concurrently where the host permits and inspect only structured
+`codexDelegation.input`, never untrusted title, summary, preview, or plain-text
+marker echoes. A native resolver result is verified against the same structured
+marker before persistence. Zero exact matches time out unresolved; multiple
+exact matches are ambiguous. Snapshot, candidate-read, native-resolution, or
+task-resolution errors leave the already-recorded nullable entry intact. No
+snapshot, candidate read, marker verification, or task-resolution write starts
+after the 30-second deadline, so tool latency can reduce the number of attempts.
+A `clientThreadId`, `pendingWorktreeId`, or ID in the documented provisional
+`local:` namespace remains diagnostic context and is rejected from every path
+that could persist the canonical `threadId` field.
+
+Desktop thread tools are available to the Codex skill, not to the standalone
+Node CLI. The package therefore exposes testable marker/filter/orchestration
+helpers with injected thread-tool callbacks, while the skill owns the actual
+desktop-tool calls and the CLI remains responsible only for validated data
+operations.
 
 A failed executor creation produces no entry. If executor creation succeeds but
 the append fails, the executor remains valid and TaskChef tells the user that
@@ -144,19 +183,23 @@ The CLI reads persisted history without contacting Codex:
 - `task list` returns entries in append order, optionally filtered by
   historical project name or exact path.
 - `task summary` returns the total and per-project counts.
+- `task resolve <id> --thread-id <thread-id>` atomically fills one nullable
+  thread ID after Codex verifies the exact structured marker match.
 
-When the user requests current state or outcomes, `$taskchef-report` loads the
-relevant entries and queries every recorded Codex task exactly once, in batches
-of no more than eight. It reports the snapshot and discards it. The report does
-not update `tasks.jsonl`, poll, wait, or create a scheduled job.
+When the user requests current state or outcomes, `$taskchef-report` makes one
+marker-based discovery pass for nullable entries and uses `task resolve` only
+for a single exact match. It reports unmatched entries as unresolved and
+queries every durable thread ID exactly once, in batches of no more than eight.
+The report does not poll, wait, persist status or results, or create a scheduled
+job.
 
 ## Boundaries
 
 TaskChef does not include:
 
 - lifecycle status or result persistence
-- task callbacks, hooks, polling, daemons, heartbeats, or schedules
-- arbitrary Codex task discovery
+- task callbacks, hooks, indefinite polling, daemons, heartbeats, or schedules
+- arbitrary Codex task discovery beyond bounded marker-based creation recovery
 - remote hosts or `hostId` storage
 - transcript or hidden-reasoning collection
 - one-active-task-per-project restrictions
@@ -170,10 +213,13 @@ TaskChef does not include:
 2. Project metadata routes an unambiguous request to the correct local project.
 3. A successful delegation creates a visible Codex task and appends its thread
    ID with a project snapshot.
-4. The dispatcher returns without waiting for execution.
-5. Several independent assignments can create several entries, including
+4. A provisional creation with one exact marker match records its durable
+   thread ID; zero or multiple matches record `threadId: null` for later
+   recovery.
+5. The dispatcher returns without waiting for execution.
+6. Several independent assignments can create several entries, including
    multiple entries for the same project.
-6. Task history commands return deterministic entries and project counts.
-7. A live report queries each relevant task once and writes nothing.
-8. Malformed JSONL, duplicate IDs, duplicate thread IDs, and symlinked managed
+7. Task history commands return deterministic entries and project counts.
+8. A live report queries each relevant task once and writes nothing.
+9. Malformed JSONL, duplicate IDs, duplicate thread IDs, and symlinked managed
    files fail safely.

package/index.js

@@ -14,7 +14,25 @@ export {
   listTasks,
   readTask,
   recordTask,
+  resolveTask,
   requireSafeId,
   removeProject,
   validateConfig,
 } from "./src/workspace.js";
+
+export {
+  THREAD_RESOLUTION_CHECKPOINTS_MS,
+  THREAD_RESOLUTION_CLOCK_SKEW_MS,
+  THREAD_RESOLUTION_RECENT_LIMIT,
+  THREAD_RESOLUTION_TIMEOUT_MS,
+  createAndRecordDelegation,
+  filterThreadCandidates,
+  hasExactTaskChefMarker,
+  listThreadEntries,
+  isProvisionalThreadId,
+  normalizeDurableThreadId,
+  parseTaskChefMarker,
+  prepareDelegation,
+  structuredDelegatedInputs,
+  taskChefMarker,
+} from "./src/delegation.js";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "taskchef",
-  "version": "3.0.2",
+  "version": "3.0.3",
   "description": "A non-blocking interactive dispatcher for visible Codex tasks.",
   "license": "MIT",
   "author": "Favo Yang",

package/skills/taskchef-bootstrap/SKILL.md

@@ -24,9 +24,8 @@ all deterministic workspace operations.
 
 1. Run `workspace init --json`. It takes no stdin, creates an empty
    configuration when missing, creates the append-only task log, refreshes
-   managed instructions, and migrates legacy task records that have executor
-   thread IDs. The installed plugin provides all three TaskChef skills outside
-   the dispatcher workspace.
+   managed instructions, and removes legacy TaskChef skill links. The installed
+   plugin provides all three TaskChef skills outside the dispatcher workspace.
 2. Run `doctor --json` after setup or when the user asks to diagnose the
    workspace. Doctor is read-only. Rerun `workspace init --json` to repair the
    managed scaffold.

package/skills/taskchef-delegate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: taskchef-delegate
-description: "Dispatch actionable requests from an initialized TaskChef workspace into independently openable Codex project tasks. Use for ordinary work requests in a TaskChef workspace, explicit delegation, or splitting independent work across projects. Record successful dispatches, return immediately, and never use subagents, hooks, schedules, or foreground waiting."
+description: "Dispatch actionable requests from an initialized TaskChef workspace into independently openable Codex project tasks. Use for ordinary work requests in a TaskChef workspace, explicit delegation, or splitting independent work across projects. Preserve unresolved delegations for later marker-based recovery, and never use subagents, hooks, schedules, daemons, or executor-completion waiting."
 ---
 
 # TaskChef Delegate
@@ -17,7 +17,10 @@ for all deterministic workspace and task-record operations.
 - Keep only `AGENTS.md`, `taskchef.json`, and `tasks.jsonl` in a dispatcher
   workspace.
 - Use real Codex tasks, never collaboration or subagent tools.
-- Never use hooks, callbacks, schedules, polling, or daemons.
+- Never use hooks, callbacks, schedules, daemons, indefinite polling, or
+  background monitors.
+- Use only bounded provisional-ID resolution after `create_thread` returns a
+  provisional client ID. Prefer a native Codex wait or resolver when available.
 - Never wait for delegated work after executor creation.
 - Never collect transcripts or hidden reasoning.
 
@@ -33,16 +36,77 @@ for all deterministic workspace and task-record operations.
    `path` only as checkout identity. Ask when metadata does not produce one
    clear project match.
 4. Resolve native projects once and require the exact configured path.
-5. Create one real Codex task per assignment using the exact configured project
-   and a local environment on its executor host. Generate a unique task ID
-   before creation, but do not write anything yet.
-6. After executor creation returns a thread ID, immediately run
+5. Generate a lowercase full UUID task ID before creation. Prefix the complete
+   executor instruction with exactly `# taskchef_id=<full UUID>`, followed by a
+   blank line and the instruction body. Preserve this marked instruction for
+   recording, and note the creation time. Do not take a pre-creation thread
+   snapshot; the exact random marker is the correlation key.
+6. Create one real Codex task using the exact configured project, a local
+   environment on its executor host, the marked instruction, and a short title.
+7. When `create_thread` returns a durable `threadId`, immediately run
    `<plugin-root>/bin/taskchef.js task record --json --workspace <workspace>`.
    Send exactly `id`, `project`, `title`, `instruction`, and `threadId` as JSON
-   on stdin. Use the configured project path for `project`. Never persist
-   `hostId`, status, results, transcripts, or hidden reasoning.
-7. If executor creation fails, do not record a task. If recording fails
+   on stdin. Use the configured project path for `project`, and send the marked
+   instruction unchanged. Never persist a provisional `clientThreadId` or
+   `pendingWorktreeId` as `threadId`. Never persist `hostId`, status, results,
+   transcripts, or hidden reasoning.
+8. When creation returns only `clientThreadId` or `pendingWorktreeId`, keep it
+   only for the created-thread directive and diagnostic reporting. It is not a
+   durable ID and cannot be passed to thread tools or converted directly.
+   Immediately record the marked instruction with `threadId: null` using the
+   command from step 7, then resolve the durable ID with this bounded workflow:
+
+   - If the current Codex tool surface provides a dedicated operation that
+     accepts the provisional ID and waits for or resolves its durable thread
+     ID, call it exactly once with a timeout of at most 30 seconds. Do not invent
+     an operation or pass the provisional ID to tools that require `threadId`.
+   - When no native operation is available, take at most two `list_threads`
+     snapshots with limit 50, near 10 and 30 seconds after the provisional
+     result. Count tool latency against the 30-second deadline. Do not start a
+     snapshot, candidate read, marker verification, or task-resolution write
+     after it.
+   - Filter Codex candidates by the expected host, project, creation time
+     (allow five seconds of clock skew), and worktree environment whenever
+     those fields are present. Use the title only to prioritize reads; Codex
+     may normalize it, so never exclude a candidate because its title differs.
+   - Read every remaining candidate with `read_thread`, requesting one turn and
+     no command output. Read candidates concurrently when the tool surface
+     permits. Inspect only the structured
+     `userMessage.content[].codexDelegation.input`; do not trust titles,
+     summaries, previews, plain-text echoes, or assistant output as proof.
+   - Accept a candidate only when the structured input's first line is exactly
+     the task's `# taskchef_id=<full UUID>` marker and exactly one candidate
+     matches. Apply the same marker verification to a thread ID returned by a
+     native resolver. Reject any returned or discovered thread ID equal to the
+     provisional identifier or in its `local:` namespace. Then use
+     the task-resolution command under **Later resolution** to atomically fill
+     the nullable field.
+   - Treat native-resolution, snapshot, candidate-read, wait, and task-resolution
+     failures as indeterminate. If the workflow ends with zero exact matches,
+     multiple matches, or errors, leave the already-recorded `threadId: null`,
+     clearly report the unresolved reason and provisional diagnostic ID, and
+     never guess.
+
+9. If executor creation fails, do not record a task. If recording fails
    after creation, still return the created task and clearly say that it is not
    in the task log. Do not delete the executor.
-8. Return immediately with a created-thread directive for every success. Do
-   not read or wait for a newly created executor.
+10. Return immediately after immediate recording or the bounded ID-resolution
+    workflow. Emit the appropriate created-thread directive, but label a
+    client-thread directive as provisional when resolution failed. Treat a
+    nullable record as preserved but unresolved, not as a durable task link. Do
+    not read an executor for progress and never wait for executor work
+    completion.
+
+The package exports pure marker, candidate-filtering, and injected-adapter
+orchestration helpers from `src/delegation.js` for deterministic tests and
+hosts that can supply thread-tool callbacks. The standalone Node CLI cannot
+call desktop thread tools; perform the tool calls in Codex and use the CLI only
+for validated workspace data operations.
+
+## Later resolution
+
+When a later Codex workflow finds exactly one durable thread whose structured
+delegated input contains an unresolved task's exact marker, run
+`<plugin-root>/bin/taskchef.js task resolve <task-id> --thread-id <thread-id> --json --workspace <workspace>`.
+Never edit `tasks.jsonl` directly. The CLI permits only an idempotent one-way
+transition from `threadId: null` to one unique durable thread ID.

package/skills/taskchef-report/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: taskchef-report
-description: "Report the live state of Codex tasks recorded in a TaskChef task history. Use only when the user asks for status, outcomes, or a report about delegated work. Queries each relevant task once, never polls or waits, and never persists status or results."
+description: "Report the live state of Codex tasks recorded in a TaskChef task history. Use only when the user asks for status, outcomes, or a report about delegated work. Queries each relevant task once, may resolve a nullable thread ID from one exact marker match, never polls or waits, and never persists status or results."
 ---
 
 # TaskChef Report
@@ -23,16 +23,26 @@ all deterministic task-log operations.
      `<plugin-root>/bin/taskchef.js task list --json --workspace <workspace>`
      once, then select matching entries. Ask the user if the match is ambiguous.
    - Use the full list only when the user asks for an overview of the task history.
-2. Query every selected thread exactly once using immediate native snapshots,
-   with no more than eight targets per call.
-3. Summarize the live state and any reported outcome for each requested task.
+2. Separate entries whose `threadId` is `null`. For those entries, take one
+   `list_threads` snapshot with limit 50, filter by available project metadata,
+   and inspect candidate structured delegated inputs. Use title only to
+   prioritize candidates, never to exclude them. When exactly one candidate
+   starts with the task's exact marker, run
+   `<plugin-root>/bin/taskchef.js task resolve <task-id> --thread-id <thread-id> --json --workspace <workspace>`.
+   Do not resolve zero or multiple matches. Report unmatched entries as
+   recorded but unresolved and do not pass them to native thread tools.
+3. Query every resolved or previously durable thread exactly once using
+   immediate native snapshots, with no more than eight targets per call.
+4. Summarize the live state and any reported outcome for each requested task.
    Distinguish active work, requests for user input, completed work, and failed
    or partial attempts.
-4. Treat each Codex task as the source of truth. The task log proves that
-   TaskChef created the task, but it does not contain the task's current state.
-5. Never update `tasks.jsonl`. Never persist status, results, transcripts,
-   or hidden reasoning. Do not poll or wait for future activity.
+5. Treat each Codex task as the source of truth. The task log records what
+   TaskChef submitted, but it does not contain the task's current state.
+6. Never edit `tasks.jsonl` directly. Use `task resolve` only for one exact
+   marker match. Never persist status, results, transcripts, or hidden
+   reasoning. Do not poll or wait for future activity.
 
 If the task history is empty, say that TaskChef has not recorded any tasks. If
-a recorded task cannot be read, identify it by task ID and thread ID, then
-continue with the remaining entries.
+a task has no durable thread ID, identify it by task ID and say that its marker
+remains available for later recovery. If a recorded thread cannot be read,
+identify it by task ID and thread ID, then continue with the remaining entries.

package/src/cli.js

@@ -12,6 +12,7 @@ import {
   readTask,
   recordTask,
   removeProject,
+  resolveTask,
 } from "./workspace.js";
 
 async function readStdin() {
@@ -92,7 +93,6 @@ async function initialize(args) {
     `Workspace: ${value.workspace}`,
     `Configuration: ${value.config.action}`,
     `Task log: ${value.tasks.action}`,
-    `Legacy tasks: ${value.legacyTasks.action}`,
     `Instructions: ${value.instructions.action}`,
     `Legacy skill links removed: ${value.legacySkills.removed.length}`,
   ].join("\n"));
@@ -180,6 +180,22 @@ async function taskRecord(args) {
   return 0;
 }
 
+async function taskResolve(args) {
+  if (!args[2] || args[2].startsWith("--")) throw new Error("task resolve requires a task ID");
+  validateCommandArgs(args, 3, {
+    values: ["--thread-id", "--workspace"],
+    switches: ["--json"],
+  });
+  if (!args.includes("--thread-id")) throw new Error("task resolve requires --thread-id");
+  const task = await resolveTask(
+    workspaceRoot(args),
+    args[2],
+    option(args, "--thread-id"),
+  );
+  print(task, args, (value) => `Resolved ${value.id}: ${value.threadId}`);
+  return 0;
+}
+
 async function taskShow(args) {
   validateCommandArgs(args, 3, { values: ["--workspace"], switches: ["--json"] });
   print(await readTask(workspaceRoot(args), args[2]), args);
@@ -229,6 +245,7 @@ Usage:
   taskchef project list [--json] [--workspace <path>]
   taskchef project remove <name> [--json] [--workspace <path>]
   taskchef task record [--json] [--workspace <path>]
+  taskchef task resolve <task-id> --thread-id <thread-id> [--json] [--workspace <path>]
   taskchef task show <task-id> [--json] [--workspace <path>]
   taskchef task list [--project <name-or-path>] [--json] [--workspace <path>]
   taskchef task summary [--json] [--workspace <path>]
@@ -250,6 +267,7 @@ export async function runCli(args) {
   if (args[0] === "project" && args[1] === "list") return projectList(args);
   if (args[0] === "project" && args[1] === "remove") return projectRemove(args);
   if (args[0] === "task" && args[1] === "record") return taskRecord(args);
+  if (args[0] === "task" && args[1] === "resolve") return taskResolve(args);
   if (args[0] === "task" && args[1] === "show" && args[2]) return taskShow(args);
   if (args[0] === "task" && args[1] === "list") return taskList(args);
   if (args[0] === "task" && args[1] === "summary") return taskSummary(args);