taskchef 5.3.0 → 5.4.1

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "taskchef",
-  "version": "5.3.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

@@ -181,7 +181,8 @@ For each assignment, `$taskchef-delegate`:
 1. runs `dispatch prepare` and native Codex project discovery concurrently;
    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
+   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
@@ -193,28 +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, 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, 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 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 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:
+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. 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.3.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,7 +21,7 @@ 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.
 
@@ -35,7 +35,8 @@ for all deterministic workspace and task-record operations.
    `$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.
+   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
@@ -54,9 +55,8 @@ for all deterministic workspace and task-record operations.
    Prefix the complete executor instruction with
    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.
-   Do not take a pre-creation thread snapshot; the exact random marker is the
-   correlation key.
+   marked instruction for recording, and note the creation time. The exact
+   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
@@ -77,12 +77,11 @@ 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 `list_threads`
-     snapshots with limit 50. The nominal schedule is 10 and 30 seconds after
+   - 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
      the first snapshot immediately. Start the second snapshot no sooner than
@@ -95,21 +94,23 @@ 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. Inspect only the structured
+     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.
    - 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. 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