taskchef 3.0.1 → 3.0.3

package/node_modules/signal-exit/package.json

@@ -0,0 +1,38 @@
+{
+  "name": "signal-exit",
+  "version": "3.0.7",
+  "description": "when you want to fire an event no matter how a process exits.",
+  "main": "index.js",
+  "scripts": {
+    "test": "tap",
+    "snap": "tap",
+    "preversion": "npm test",
+    "postversion": "npm publish",
+    "prepublishOnly": "git push origin --follow-tags"
+  },
+  "files": [
+    "index.js",
+    "signals.js"
+  ],
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/tapjs/signal-exit.git"
+  },
+  "keywords": [
+    "signal",
+    "exit"
+  ],
+  "author": "Ben Coe <ben@npmjs.com>",
+  "license": "ISC",
+  "bugs": {
+    "url": "https://github.com/tapjs/signal-exit/issues"
+  },
+  "homepage": "https://github.com/tapjs/signal-exit",
+  "devDependencies": {
+    "chai": "^3.5.0",
+    "coveralls": "^3.1.1",
+    "nyc": "^15.1.0",
+    "standard-version": "^9.3.1",
+    "tap": "^15.1.1"
+  }
+}

package/node_modules/signal-exit/signals.js

@@ -0,0 +1,53 @@
+// This is not the set of all possible signals.
+//
+// It IS, however, the set of all signals that trigger
+// an exit on either Linux or BSD systems.  Linux is a
+// superset of the signal names supported on BSD, and
+// the unknown signals just fail to register, so we can
+// catch that easily enough.
+//
+// Don't bother with SIGKILL.  It's uncatchable, which
+// means that we can't fire any callbacks anyway.
+//
+// If a user does happen to register a handler on a non-
+// fatal signal like SIGWINCH or something, and then
+// exit, it'll end up firing `process.emit('exit')`, so
+// the handler will be fired anyway.
+//
+// SIGBUS, SIGFPE, SIGSEGV and SIGILL, when not raised
+// artificially, inherently leave the process in a
+// state from which it is not safe to try and enter JS
+// listeners.
+module.exports = [
+  'SIGABRT',
+  'SIGALRM',
+  'SIGHUP',
+  'SIGINT',
+  'SIGTERM'
+]
+
+if (process.platform !== 'win32') {
+  module.exports.push(
+    'SIGVTALRM',
+    'SIGXCPU',
+    'SIGXFSZ',
+    'SIGUSR2',
+    'SIGTRAP',
+    'SIGSYS',
+    'SIGQUIT',
+    'SIGIOT'
+    // should detect profiler and enable/disable accordingly.
+    // see #21
+    // 'SIGPROF'
+  )
+}
+
+if (process.platform === 'linux') {
+  module.exports.push(
+    'SIGIO',
+    'SIGPOLL',
+    'SIGPWR',
+    'SIGSTKFLT',
+    'SIGUNUSED'
+  )
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "taskchef",
-  "version": "3.0.1",
+  "version": "3.0.3",
   "description": "A non-blocking interactive dispatcher for visible Codex tasks.",
   "license": "MIT",
   "author": "Favo Yang",
@@ -41,5 +41,8 @@
   },
   "dependencies": {
     "proper-lockfile": "^4.1.2"
-  }
+  },
+  "bundleDependencies": [
+    "proper-lockfile"
+  ]
 }

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);