taskchef 7.11.0 → 7.11.1

package/.codex-plugin/plugin.json

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

package/README.md

@@ -88,11 +88,11 @@ $taskchef-delegate In payments, add structured logs for failed retries and test
 
 TaskChef prepares a UUID and marker, persists the task before native creation,
 creates the executor, and returns its task link. New executor instructions keep
-the assignment visible from the first line, then place the correlation marker
-immediately before an explicit `$taskchef-executor` invocation. That skill
-reads the executor's own `CODEX_THREAD_ID`, self-links, and reports lifecycle
-state. Independent outcomes may become separate executors; dependent work
-should stay together.
+the assignment visible from the first line, then place an explicit
+`$taskchef-executor` invocation immediately before the final correlation
+marker. That skill reads the executor's own `CODEX_THREAD_ID`, self-links, and
+reports lifecycle state. Independent outcomes may become separate executors;
+dependent work should stay together.
 
 At the start of every dispatcher turn, the managed workspace instructions ask
 the MCP server to best-effort ensure the dashboard. A startup failure never
@@ -104,8 +104,8 @@ For example, TaskChef generates this shape:
 
 ```text
 Fix duplicate charges after a retry and add a regression test.
-<!-- taskchef_id=c0f010ff-84f2-4838-a69d-0ff1f5d721d7 -->
 Use $taskchef-executor to execute and report this delegated TaskChef assignment.
+<!-- taskchef_id=c0f010ff-84f2-4838-a69d-0ff1f5d721d7 -->
 ```
 
 ## Work with and report executors

package/docs/spec.md

@@ -18,7 +18,7 @@ is dated research, not contract.
 | **Delegated task** | One independently useful outcome represented by one TaskChef task UUID and snapshot. |
 | **Executor** | The native Codex task created to own and perform one delegated task. |
 | **Task record** | One complete JSON object in `tasks.jsonl`; it contains immutable intent/project fields and mutable identity/result fields. |
-| **Marker** | The exact correlation line `<!-- taskchef_id=<lowercase full UUID> -->`; new instructions place it after the complete assignment and immediately before the executor-skill invocation. |
+| **Marker** | The exact correlation line `<!-- taskchef_id=<lowercase full UUID> -->`; new instructions place it on the final line, immediately after the executor-skill invocation. |
 | **Record-before-create** | Persisting a link-pending task before asking Codex to create its executor. |
 | **Self-linking** | The executor's one-way registration of its own canonical Codex UUIDv7 from `CODEX_THREAD_ID`. |
 | **Link-pending** | A working task whose `threadId` is null and `updatedBy` is `dispatcher`. |
@@ -119,10 +119,10 @@ the final link, preserving the delegate skill's immediate-return contract.
 1. The dispatcher MUST call `prepare_dispatch` once per outcome.
 2. It MUST choose exactly one configured project and exact native-project path.
 3. It MUST build the instruction with the user's outcome beginning on line 1
-   and remaining uninterrupted, followed by exactly one newline, the returned
-   marker, one newline, and exactly one concise explicit `$taskchef-executor`
-   invocation on the final line. It MUST NOT place a blank line before or after
-   the marker or inline the executor protocol into a new instruction.
+   and remaining uninterrupted, followed by exactly one newline, exactly one
+   concise explicit `$taskchef-executor` invocation, one newline, and the
+   returned marker on the final line. It MUST NOT place blank lines around the
+   invocation or marker or inline the executor protocol into a new instruction.
 4. It MUST call `record_task` with `threadId: null` before native creation.
 5. It MUST create exactly one native Codex executor and return immediately.
 6. The executor MUST read its own `CODEX_THREAD_ID` and call `link_task`
@@ -141,16 +141,17 @@ If native creation fails after recording, the dispatcher MUST call
 A link failure MUST remain visible and retryable; the executor MUST report it
 visibly and MUST NOT continue substantive work.
 
-Previously recorded instructions with the former blank line before a trailing
-marker, a first-line HTML marker, the older first-line
+Previously recorded instructions with the trailing marker before the
+invocation, with or without the former blank line before that marker; a
+first-line HTML marker; the older first-line
 `# taskchef_id=<full UUID>` heading, or the former blank line and inline
 executor protocol MUST remain marker-readable and executable. Their
 `report_result` calls MUST remain supported by the deprecated alias. New
-instructions MUST use the trailing marker and explicit executor skill contract
-above. A historical first-line instruction with an executor-skill invocation
-MUST contain exactly one invocation as its final line. A former inline-protocol
-instruction MUST retain non-whitespace task-specific content beyond its known
-lifecycle paragraphs.
+instructions MUST use the explicit executor invocation followed by the final
+trailing marker contract above. A historical first-line instruction with an
+executor-skill invocation MUST contain exactly one invocation as its final
+line. A former inline-protocol instruction MUST retain non-whitespace
+task-specific content beyond its known lifecycle paragraphs.
 
 `needs_input` MUST mean a semantic user decision or missing fact. A native
 approval prompt MUST remain live Codex state and MUST NOT be stored as

package/docs/workflows.md

@@ -107,8 +107,8 @@ Record-before-create makes native creation failure observable. Executor
 self-linking removes dispatcher-side polling, task search, title matching, and
 parent/child identity inference.
 
-The generated task begins with the complete assignment, then places its marker
-immediately before one explicit `$taskchef-executor` invocation. Older
+The generated task begins with the complete assignment, then places one explicit
+`$taskchef-executor` invocation immediately before its final marker. Older
 recorded tasks with first-line HTML or heading markers and former inline
 protocol remain readable; the deprecated `report_result` alias preserves their
 semantic callbacks.

package/package.json

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

package/skills/taskchef-delegate/SKILL.md

@@ -11,17 +11,18 @@ and return immediately.
 ## Invocation boundary
 
 A task whose initial structured `codexDelegation.input` contains either the
-exact new trailing TaskChef marker plus final `$taskchef-executor` invocation,
-an exact first-line HTML marker, or the historical first-line
+exact new trailing `$taskchef-executor` invocation plus final TaskChef marker,
+an accepted former trailing marker-plus-invocation scaffold, an exact
+first-line HTML marker, or the historical first-line
 `# taskchef_id=<full UUID>` heading already owns that delegated assignment.
 This includes former inline-protocol tasks that lack the skill invocation.
 An owned instruction must have exactly one accepted marker and a non-whitespace
 task-specific assignment. If it contains an executor-skill invocation, require
-exactly one as the final line. Marker-only, duplicate-marker, scaffold-only, or
-misplaced-invocation inputs are not valid delegated tasks. Execute a valid one
-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.
+exactly one adjacent to the marker in an accepted order. Marker-only,
+duplicate-marker, scaffold-only, or misplaced-invocation inputs are not valid
+delegated tasks. Execute a valid one 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.
 
 Use the bundled `prepare_dispatch`, `record_task`, and `report_state` MCP tools
 directly. Never fall back to shell writes. If a required tool is unavailable,
@@ -52,11 +53,12 @@ stop and report that the TaskChef plugin must be reloaded or installed.
 
    - Begin with the actual assignment on the first line and keep its complete
      body uninterrupted.
-   - After the assignment's final character, add exactly one newline and the
-     preparation's exact marker on its own line. Do not add a blank line before
-     or after the marker.
-   - Immediately after the marker, end the instruction with exactly:
+   - After the assignment's final character, add exactly one newline and this
+     invocation on its own line:
      `Use $taskchef-executor to execute and report this delegated TaskChef assignment.`
+   - Immediately after the invocation, end the instruction with one newline
+     and the preparation's exact marker on its own final line. Do not add blank
+     lines around the invocation or marker.
    - Include exactly one marker and exactly one executor-skill invocation.
    - Do not inline executor ownership, identity, linking, or result-reporting
      protocol. The explicitly invoked executor skill owns those mechanics.

package/skills/taskchef-executor/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: taskchef-executor
-description: "Execute an assignment carrying either the new exact TaskChef marker-plus-invocation scaffold or an accepted historical first-line TaskChef marker or inline protocol. Includes executor ownership, self-linking, per-turn lifecycle reporting, identity safety, and final semantic state. Use when explicitly invoked by a new delegated instruction or when resuming the same new or historical executor task. Do not use to dispatch work or report on other TaskChef tasks."
+description: "Execute an assignment carrying either the new exact TaskChef invocation-plus-final-marker scaffold or an accepted historical first-line or marker-before-invocation protocol. Includes executor ownership, self-linking, per-turn lifecycle reporting, identity safety, and final semantic state. Use when explicitly invoked by a new delegated instruction or when resuming the same new or historical executor task. Do not use to dispatch work or report on other TaskChef tasks."
 ---
 
 # TaskChef Executor
@@ -10,12 +10,12 @@ re-dispatch it merely because it concerns TaskChef or a configured project.
 Explicit requests to delegate separate work remain valid.
 
 New instructions present the complete assignment first, followed by exactly one
-newline, the exact `<!-- taskchef_id=<full UUID> -->` marker, one newline, and
-the final explicit skill invocation. There is no blank line before or after the
-marker. Treat that UUID as the TaskChef task ID. The assignment is everything
-before the marker; the marker and invocation are lifecycle scaffolding, not
-part of the deliverable. Require exactly one marker and do not infer an ID from
-similar prose.
+newline, the explicit skill invocation, one newline, and the exact
+`<!-- taskchef_id=<full UUID> -->` marker on the final line. There are no blank
+lines around the invocation or marker. Treat that UUID as the TaskChef task ID.
+The assignment is everything before the invocation; the invocation and marker
+are lifecycle scaffolding, not part of the deliverable. Require exactly one
+marker and do not infer an ID from similar prose.
 
 ## Start every execution turn
 
@@ -77,9 +77,10 @@ Existing delegated tasks may include the former inline ownership, linking, and
 re-dispatching. Prefer `report_state` when available. If an older installed
 TaskChef exposes only `report_result`, follow its inline protocol; after an
 upgrade, the deprecated `report_result` alias remains available for exact
-legacy retries. Also accept historical instructions with the former blank line
-before a trailing marker, an exact HTML marker on the first line with or
-without the former blank line, or the older exact
+legacy retries. Also accept historical trailing instructions that place the
+marker before the invocation, with or without the former blank line before the
+marker; an exact HTML marker on the first line with or without the former blank
+line; or the older exact
 first-line `# taskchef_id=<full UUID>` heading. These compatibility forms do not
 change the identity or lifecycle rules above. For either first-line form, the
 assignment follows the marker. Ignore the final executor invocation and any

package/src/delegation.js

@@ -162,6 +162,16 @@ export function parseTaskChefMarker(instruction) {
     return hasHistoricalAssignment() ? id : null;
   }
   const executorSkillReferences = instruction.match(/\$taskchef-executor\b/gi) ?? [];
+  const isFinalMarkerScaffold = index === lines.length - 1
+    && index >= 2
+    && lines[0].trim().length > 0
+    && lines.at(-2) === EXECUTOR_SKILL_INVOCATION
+    && lines.at(-3).trim().length > 0
+    && hasTaskSpecificContent(lines.slice(0, index - 1))
+    && !lines.slice(0, index - 1).some((line) => HISTORICAL_EXECUTOR_SCAFFOLD_LINES.has(line))
+    && executorSkillReferences.length === 1;
+  if (isFinalMarkerScaffold) return id;
+
   const hasCompactBoundary = index >= 1
     && lines.at(index - 1).trim().length > 0;
   const hasHistoricalBlankBoundary = index >= 2
@@ -202,7 +212,7 @@ export function prepareDelegation(instruction, { taskId = randomUUID() } = {}) {
   const id = requireUuid(taskId);
   return {
     id,
-    instruction: `${body}\n${taskChefMarker(id)}\n${EXECUTOR_SKILL_INVOCATION}`,
+    instruction: `${body}\n${EXECUTOR_SKILL_INVOCATION}\n${taskChefMarker(id)}`,
   };
 }