taskchef 5.4.0 → 5.4.1

package/.codex-plugin/plugin.json

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

package/README.md

@@ -123,10 +123,10 @@ Every delegated instruction begins with a unique
 `<!-- taskchef_id=<UUID> -->` marker followed by a blank line. The valid HTML
 comment stays invisible in rendered Markdown.
 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.
+the marked delegation as unresolved, then makes at most two exact-marker checks
+during a short bounded window. Candidate reads use one programmatic batch per
+check. If the batch cannot execute or TaskChef cannot identify exactly one
+task, the recorded marker remains available for recovery.
 
 ### Ask for a live report
 

package/SPEC.md

@@ -179,11 +179,10 @@ cases.
 For each assignment, `$taskchef-delegate`:
 
 1. runs `dispatch prepare` and native Codex project discovery concurrently;
-   only when neither a native provisional-ID resolver nor programmatic tool
-   orchestration is available, it also takes one recent-thread baseline
-   snapshot in that parallel group. The preparation command resolves the
-   canonical workspace, loads and validates configured projects, and generates
-   the full UUID, preparation timestamp, and exact marker in one process
+   the preparation command resolves the canonical workspace, loads and
+   validates configured projects, and generates the full UUID, preparation
+   timestamp, and exact marker in one process; it never takes a pre-creation
+   thread snapshot
 2. selects one unambiguous configured target and matches its exact path against
    the already-loaded native projects
 3. prefixes the instruction with the prepared exact
@@ -195,33 +194,31 @@ For each assignment, `$taskchef-delegate`:
    temporary record file, and requests canonical-workspace write permission on
    the first attempt when the command sandbox does not allow that path
 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, excludes durable Codex IDs from the
-   successful pre-creation baseline, then takes at most two recent-thread
+   marked entry with `threadId: null`; the current supported Codex surface has
+   no provisional-ID resolver, so the skill performs no post-creation tool
+   availability inspection
+7. takes at most two recent-thread
    snapshots on a nominal 10- and 30-second schedule after the provisional
    result; a late first checkpoint runs immediately, and the second starts at
    least 20 seconds after the first actually started. It filters candidates by
    available host/project/time/worktree metadata, uses title only as an advisory
-   ordering hint, batches independent reads programmatically when supported,
-   and accepts only one thread whose structured delegated input starts with the
-   exact marker
+   ordering hint, issues all independent candidate reads in exactly one
+   programmatic batch per snapshot, and accepts only one thread whose structured
+   delegated input starts with the exact marker; inability to execute that
+   required batch leaves the nullable record unresolved instead of switching to
+   serial reads
 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 remains the sole correlation proof. A successful
-pre-creation snapshot is only a candidate-elimination baseline; its failure
-does not block creation or weaken the marker check. Creation-time filtering
-allows five seconds of clock skew. Candidate reads run concurrently where the
-host permits, use one programmatic batch when available, and inspect only
+The exact random marker remains the sole correlation proof. Creation-time
+filtering allows five seconds of clock skew. Candidate reads use exactly one
+programmatic batch per snapshot 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 remain unresolved; multiple exact
-matches are ambiguous. Snapshot, candidate-read, native-resolution, or
-task-resolution errors leave the already-recorded nullable entry intact. The
-fallback is bounded by two snapshots rather than an absolute wall-clock cutoff:
+plain-text marker echoes. Zero exact matches remain unresolved; multiple exact
+matches are ambiguous. Snapshot, candidate-read, or task-resolution errors
+leave the already-recorded nullable entry intact. The workflow is bounded by
+two snapshots rather than an absolute wall-clock cutoff:
 mandatory recording or tool latency can shift both attempts later, but cannot
 erase an attempt or reduce the minimum 20-second interval between their start
 times.

package/package.json

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

package/skills/taskchef-delegate/SKILL.md

@@ -21,27 +21,22 @@ for all deterministic workspace and task-record operations.
 - 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.
+  provisional client ID. Use the fixed marker-based workflow below.
 - Never wait for delegated work after executor creation.
 - Never collect transcripts or hidden reasoning.
 
 ## Dispatch
 
-1. In parallel, run `<plugin-root>/bin/taskchef.js dispatch prepare --json`,
-   list the native Codex projects once, and, only when neither a dedicated
-   provisional-ID resolver nor programmatic tool orchestration is available,
-   take one pre-creation `list_threads` snapshot with limit 50. Do not add this
-   snapshot when candidate reads can be issued in one programmatic batch. The
-   prepare command resolves the
+1. In parallel, run `<plugin-root>/bin/taskchef.js dispatch prepare --json`
+   and list the native Codex projects once. The prepare command 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 CLI resolves `--workspace`, then `TASKCHEF_WORKSPACE`, then
    `~/.agents/taskchef`; do not substitute the current project. Reject the
-   dispatcher workspace itself as a target. From the pre-creation snapshot,
-   retain only durable Codex thread IDs as a candidate-elimination baseline.
-   Snapshot failure must not block creation; continue without a baseline.
+   dispatcher workspace itself as a target. Never take a pre-creation thread
+   snapshot.
 2. Split the request into the smallest independently useful outcomes. Include
    constraints, expected testing, and reporting in every instruction.
 3. Classify against configured `name`, every URL in the `githubRepos` list, and
@@ -61,8 +56,7 @@ for all deterministic workspace and task-record operations.
    exactly `<!-- taskchef_id=<full UUID> -->` as the first line, followed by a
    blank line and the instruction body. Preserve this
    marked instruction for recording, and note the creation time. The exact
-   random marker remains the sole correlation proof; the pre-creation IDs only
-   eliminate threads that already existed.
+   random marker is the sole correlation proof.
 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
@@ -83,13 +77,10 @@ for all deterministic workspace and task-record operations.
    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 post-creation
-     `list_threads` snapshots with limit 50. Exclude every durable Codex ID from
-     the successful pre-creation baseline before reading candidates. The
+   - The supported Codex surface has no provisional-ID resolver. Do not inspect
+     the tool surface for one after creation and do not pass the provisional ID
+     to tools that require `threadId`.
+   - Take at most two post-creation `list_threads` snapshots with limit 50. The
      nominal schedule is 10 and 30 seconds after
      the provisional result. Treat the first checkpoint as due, not expired: if
      nullable recording or other required work finishes after 10 seconds, take
@@ -103,9 +94,11 @@ for all deterministic workspace and task-record operations.
      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; when programmatic tool orchestration is available, issue the
-     independent reads together in one programmatic batch. Inspect only the
+     no command output. Issue all independent reads together in exactly one
+     programmatic batch per snapshot. Do not probe for batching support and do
+     not fall back to serial tool-call round trips. When the required batch
+     cannot be executed, preserve the nullable record as unresolved. Inspect
+     only the
      structured
      `userMessage.content[].codexDelegation.input`; do not trust titles,
      summaries, previews, plain-text echoes, or assistant output as proof.
@@ -113,13 +106,11 @@ for all deterministic workspace and task-record operations.
      the task's `<!-- taskchef_id=<full UUID> -->` marker and exactly one
      candidate matches. Require an immediately following blank line. Reject old
      heading-style markers, malformed comments, missing blank separators, and
-     marker-like text anywhere else. 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
+     marker-like text anywhere else. Reject any 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
+   - Treat 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

package/src/delegation.js

@@ -250,7 +250,6 @@ export async function createAndRecordDelegation({
   recordTask,
   resolveRecordedTask = null,
   resolveProvisionalThread = null,
-  baselineThreadIds = new Set(),
   taskId = randomUUID(),
   checkpointsMs = THREAD_RESOLUTION_CHECKPOINTS_MS,
   timeoutMs = THREAD_RESOLUTION_TIMEOUT_MS,
@@ -275,9 +274,6 @@ export async function createAndRecordDelegation({
   if (resolveRecordedTask !== null && typeof resolveRecordedTask !== "function") {
     throw new Error("resolveRecordedTask must be a function or null");
   }
-  if (!(baselineThreadIds instanceof Set)) {
-    throw new Error("baselineThreadIds must be a Set");
-  }
   validateResolutionSchedule(checkpointsMs, timeoutMs);
 
   const prepared = prepareDelegation(instruction, { taskId });
@@ -511,7 +507,6 @@ export async function createAndRecordDelegation({
     try {
       const snapshot = await listThreads({ limit: recentLimit });
       candidates = filterThreadCandidates(snapshot, {
-        baselineThreadIds,
         excludedThreadIds: provisionalIds,
         hostId: expected.hostId ?? null,
         projectId: expected.projectId ?? target.projectId ?? null,