taskchef 1.0.2 → 3.0.0

package/SPEC.md

@@ -2,75 +2,56 @@
 
 ## Purpose
 
-TaskChef is an interactive Codex dispatcher. It turns a user request into
-independent assignments, creates real Codex tasks in the selected projects,
-records their latest reconciled state, and returns control immediately.
+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.
 
-TaskChef is not an agent runtime, scheduler, or background service.
+Codex tasks remain authoritative for their progress and results. TaskChef does
+not maintain a second lifecycle database.
 
 ## Core behavior
 
-1. The user opens the TaskChef workspace and submits a request.
-2. TaskChef splits the request into the smallest useful independent tasks.
-3. TaskChef classifies each assignment using configured project metadata and
-   validates every target against the configured project list.
-4. TaskChef creates one `task.json` record per delegated task with status
-   `pending`.
-5. TaskChef creates one independently openable Codex task in each target
-   project.
-6. TaskChef records the returned `threadId`, changes the status to `running`,
-   and returns immediately without waiting.
-7. The user may open and prompt any delegated task directly.
-8. When the user asks to refresh or fix outdated task states, TaskChef performs
-   one bounded reconciliation of active `running` and `blocked` threads.
-9. Reconciliation updates each task's current status and result, then returns
-   control without waiting for future activity. Ordinary delegation does not
-   trigger reconciliation first.
-
-Multiple ongoing tasks may target the same project.
+1. The user submits a request in the dispatcher workspace.
+2. TaskChef separates only outcomes that can proceed independently.
+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.
+7. When requested, TaskChef can read task entries, query the relevant Codex
+   tasks once, and present a live report without persisting the fetched state.
+
+Several active executors may target the same project.
 
 ## Workspace layout
 
 ```text
-taskchef-workspace/
+taskchef/
 ├── AGENTS.md
 ├── taskchef.json
-├── .agents/
-│   └── skills/
-│       ├── taskchef-bootstrap -> <TaskChef bootstrap skill>
-│       ├── taskchef-delegate -> <TaskChef delegate skill>
-│       └── taskchef-reconcile -> <TaskChef reconciliation skill>
-└── tasks/
-    └── <task-id>/
-        └── task.json
+└── tasks.jsonl
 ```
 
-The workspace contains TaskChef-managed dispatcher instructions, user
-configuration, and task data. TaskChef source, tests, reports, and
-implementation utilities remain in the source repository.
-
-## Dispatcher instructions
+`AGENTS.md` contains a marked block that routes setup and administration to
+`$taskchef-bootstrap`, actionable work to `$taskchef-delegate`, and explicit
+live report requests to `$taskchef-report`. Bootstrap preserves unrelated
+instructions and refreshes only the managed block.
 
-TaskChef owns a marked block in the workspace `AGENTS.md`. The block tells
-Codex to use `$taskchef-bootstrap` for workspace setup and administration and
-`$taskchef-delegate` for actionable requests without completing delegated work
-in the dispatcher thread. The final instruction reserves `$taskchef-reconcile`
-for user-requested refreshes or repairs of outdated task states.
+`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.
 
-`workspace init` copies the canonical file when `AGENTS.md` does not exist. When it
-does exist, bootstrap preserves unrelated user content and adds or refreshes
-only the TaskChef managed block. Repeating the merge is idempotent. Malformed
-or duplicate TaskChef markers fail safely instead of overwriting the file.
-Initialization also installs all three TaskChef skill links. It is idempotent,
-takes no configuration input, creates `{ "schemaVersion": 1, "projects": [] }`
-when configuration is missing, and preserves existing configured projects.
+`doctor` validates configuration, project paths, the JSONL log, managed
+instructions, and the absence of legacy workspace structures without modifying
+the workspace.
 
-`doctor` diagnoses configuration, task storage, managed instructions, skill
-links, project paths, and task records without modifying the workspace.
+## Project configuration
 
-## Configuration
-
-`taskchef.json` is the only user-facing configuration file.
+`taskchef.json` is the user-facing routing configuration:
 
 ```json
 {
@@ -81,7 +62,7 @@ links, project paths, and task records without modifying the workspace.
       "path": "/workspace/payments-api",
       "isGitRepository": true,
       "githubRepo": "https://github.com/example/payments-api",
-      "description": "Owns payment authorization, capture, refunds, and provider integrations. Use for changes to the public payments API or its transaction lifecycle."
+      "description": "Owns payment authorization, capture, refunds, and provider integrations."
     },
     {
       "name": "local-data-tools",
@@ -94,219 +75,105 @@ links, project paths, and task records without modifying the workspace.
 ```
 
 - `schemaVersion` identifies the configuration format.
-- `projects` lists the local projects TaskChef may classify and manage.
-- `name` is the unique human-readable project identity. It is explicit even
-  when it matches the checkout directory name.
-- `path` is the exact canonical local project directory.
-- `isGitRepository` states whether the saved Codex project is a Git repository.
-  When true, `path` must be the exact Git root. When false, the project runs
-  directly in its canonical directory without Git assumptions.
-- `githubRepo` is the canonical GitHub repository URL, or `null` when the
-  project has no canonical GitHub remote. It may be `null` for either Git or
-  non-Git projects.
-- `description` is an optional semantic routing description. When present, it
-  explains the project's responsibilities and the kinds of requests that
-  should target it, similarly to a skill trigger description.
-
-Project paths must exist, resolve to canonical directories, and match the
-project selected for delegation. A Git project path must resolve to its exact
-repository root. A non-Git project must use `githubRepo: null`. Names and paths
-must be unique.
-
-TaskChef classifies a requested outcome against `name`, `githubRepo`, and the
-optional `description`. The path identifies the checkout but is not a
-classification signal. A description should be specific enough to distinguish
-the project from its neighbors; generic technology labels are insufficient.
-TaskChef selects a project only when the metadata yields one clear match; it
-asks the user when no project or several projects plausibly match. It must not
-guess solely from a directory name.
-
-Project configuration is managed through `project add`, `project import`,
-`project list`, and `project remove`. Add and import detect Git status, exact
-Git roots, and canonical GitHub origins. Import accepts a JSON array from a
-file or stdin, merges by canonical path, and preserves an existing name or
-description when omitted. `--replace` is the only replacement mode.
-
-The configuration does not store dispatcher identity, project-to-task
-assignments, execution modes, scheduling options, host information, or the
-workspace path. The directory containing `taskchef.json` is the workspace, and
-the currently open Codex task is the dispatcher.
-
-## Task record
-
-Each independent assignment has one `tasks/<task-id>/task.json` file.
-
-```json
-{
-  "schemaVersion": 1,
-  "id": "t1-echo-input-20260808",
-  "project": "/workspace/t1",
-  "title": "Echo user input",
-  "instruction": "Create echo_input.py so it reads one line from standard input and echoes it exactly. Test the script and report the result.",
-  "status": "finished",
-  "threadId": "019f9d46-f42c-7482-9707-3c107bf241ee",
-  "result": {
-    "message": "Created and tested echo_input.py.",
-    "githubPRs": [],
-    "githubIssues": []
-  },
-  "createdAt": "2026-08-08T10:00:00.000Z",
-  "updatedAt": "2026-08-08T10:05:00.000Z"
-}
-```
-
-### Fields
-
-- `schemaVersion`: task format version.
-- `id`: stable TaskChef task identifier.
-- `project`: exact configured project directory.
-- `title`: short human-readable task name.
-- `instruction`: complete task-specific instruction.
-- `status`: current reconciled lifecycle state.
-- `threadId`: independently openable Codex task ID, or `null` while pending.
-- `result`: latest meaningful report, or `null` when none exists.
-- `createdAt`: task creation time as an ISO 8601 timestamp.
-- `updatedAt`: latest task update time as an ISO 8601 timestamp.
+- `projects` lists the local routing targets.
+- `name` is the unique human-readable project identity.
+- `path` is the normalized, canonical local directory. A Git project must use
+  its repository root.
+- `isGitRepository` identifies Git and non-Git projects.
+- `githubRepo` is a canonical GitHub repository URL or `null`.
+- `description` is optional routing context.
 
-The task-specific instruction includes the requested outcome, constraints,
-expected testing, and reporting expectations. Task records have no separate acceptance or
-decision fields.
+TaskChef classifies work against `name`, `githubRepo`, and `description`. The
+path identifies the checkout but is not a routing hint. TaskChef asks the user
+when metadata does not produce one clear match.
 
-## Status model
+`project add` and `project import` detect Git status, exact Git roots, and
+canonical GitHub origins. Import merges by canonical path and preserves an
+existing name or description when omitted. `--replace` replaces the configured
+set. Removing or replacing a project does not alter historical task
+entries.
 
-TaskChef supports four statuses:
+The configuration does not store dispatcher identity, execution modes,
+schedules, task status, results, host information, or the workspace path.
 
-- `pending`: the record exists, but executor creation has not completed.
-- `running`: the executor thread exists and may be working.
-- `blocked`: progress requires user input, permission, credentials, or another
-  external condition.
-- `finished`: the executor concluded its current attempt and reported a result.
+## Task entry
 
-Typical transitions are:
-
-```text
-pending → running → finished
-                  ↘ blocked → running
-```
-
-`finished` describes the executor lifecycle. It does not guarantee that the
-goal was achieved. The result message explains success, partial completion,
-failure, or uncertainty. A finished task returns to `running` if the user gives
-its thread more work.
-
-## Result
-
-`result` is `null` until there is a meaningful report.
+`tasks.jsonl` contains one compact JSON object per line, in append order:
 
 ```json
-{
-  "result": null
-}
+{"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"}
 ```
 
-When present, it has exactly three fields:
+- `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.
+- `createdAt` is the dispatch time as an ISO 8601 timestamp.
 
-```json
-{
-  "result": {
-    "message": "Implemented the change and opened a pull request.",
-    "githubPRs": [
-      "https://github.com/example/t1/pull/12"
-    ],
-    "githubIssues": [
-      "https://github.com/example/t1/issues/8"
-    ]
-  }
-}
-```
-
-- `message` is a required concise outcome, progress report, or blocker.
-- `githubPRs` is a list of canonical GitHub pull-request URLs.
-- `githubIssues` is a list of canonical GitHub issue URLs.
+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.
 
-The URL lists are empty when no related resources exist. TaskChef does not store
-separate artifact, verification, commit, decision, or completion fields.
+The project snapshot preserves the route even if the project is renamed,
+moved, or removed later. Entries never contain status, result, transcript,
+hidden reasoning, `hostId`, or update timestamps.
 
 ## Dispatch workflow
 
-For each delegated task, TaskChef:
-
-1. classifies and validates the target against project metadata in
-   `taskchef.json`;
-2. writes `task.json` with `status: pending`, `threadId: null`, and
-   `result: null`;
-3. creates a real Codex task rooted at the exact project;
-4. records its `threadId` and changes the status to `running`;
-5. returns control after all requested tasks have been dispatched.
-
-TaskChef does not wait for delegated tasks to finish.
-
-## Reconciliation workflow
+For each assignment, `$taskchef-delegate`:
 
-When the user asks to refresh or fix outdated task states, TaskChef uses
-`$taskchef-reconcile` to perform one bounded pass:
+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.
 
-1. use `task reconcile-candidates --json` to load only `running` and `blocked`
-   task records with executor thread IDs;
-2. query each returned `threadId` once using an immediate native task snapshot;
-3. do not wait for future activity;
-4. update `status`, `result`, and `updatedAt` from the current thread state;
-5. report the concise current state and return control.
+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
+it was not recorded.
 
-The native Codex thread is the live source of truth between reconciliations.
-`task.json` is only the latest reconciled snapshot. It may still say `running`
-after the executor has finished and until the user explicitly requests a
-reconciliation pass.
+## Task history and live reports
 
-Reconciliation must be safe to repeat. TaskChef has no reconciliation timestamp,
-event cursor, event log, callback, or automatic workspace update.
-Finished records are excluded from normal reconciliation. An explicit full
-refresh uses `--include-finished` to detect a new attempt added directly to a
-finished executor thread.
+The CLI reads persisted history without contacting Codex:
 
-## Inspection workflow
+- `task show <id>` returns one entry.
+- `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 list` returns task records with optional repeated `--status` filters and
-an optional configured project name or path. `task summary` returns total and
-per-status counts. These commands only inspect persisted TaskChef state and do
-not query native executor threads.
+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.
 
 ## Boundaries
 
-TaskChef is local, interactive, task-focused, and asynchronous. It does not include:
-
-- `runs/` or records of the original broad prompt;
-- `events.jsonl` or lifecycle history;
-- hooks or automatic completion signals;
-- executor callbacks;
-- schedules, polling, daemons, heartbeats, or background reconciliation;
-- remote hosts or `hostId` storage;
-- project-to-current-task assignments;
-- one-active-task-per-project restrictions;
-- transcript or hidden-reasoning collection;
-- arbitrary Codex task discovery;
-- npm registry publication; the supported distribution is a GitHub-source
-  global install or a managed source checkout.
-
-See `BACKLOG.md` for deferred capabilities and experiments.
-
-## MVP acceptance test
-
-The MVP is successful when:
-
-1. `taskchef.json` describes two local projects with names, paths,
-   `isGitRepository`, GitHub repositories or explicit `null` values, and
-   optional routing descriptions; at least one acceptance fixture is non-Git.
-2. One request produces two task-specific `task.json` records.
-3. Two independently openable Codex tasks are created in the correct projects.
-4. Both `threadId` values are recorded.
-5. The dispatcher returns without waiting for execution.
-6. The user can open and prompt either delegated task directly.
-7. A user request to refresh outdated states reconciles each active thread once
-   without reading finished executor threads; ordinary delegation does not.
-8. Status and result snapshots are updated correctly.
-9. Two ongoing tasks may target the same project without data collisions.
-10. The workspace contains dispatcher instructions, configuration, task
-    records, and the three TaskChef skill links.
-11. Bootstrap creates or idempotently merges the TaskChef-managed `AGENTS.md`
-    block without overwriting unrelated instructions.
+TaskChef does not include:
+
+- lifecycle status or result persistence
+- task callbacks, hooks, polling, daemons, heartbeats, or schedules
+- arbitrary Codex task discovery
+- remote hosts or `hostId` storage
+- transcript or hidden-reasoning collection
+- one-active-task-per-project restrictions
+- batch cancellation or replay
+- bundled development runtimes in dispatcher workspaces.
+
+## Acceptance test
+
+1. Bootstrap creates `AGENTS.md`, `taskchef.json`, and `tasks.jsonl`, then
+   remains idempotent.
+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
+   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
+   files fail safely.

package/assets/taskchef-dispatcher-instructions.md

@@ -5,7 +5,7 @@ This repository is a TaskChef dispatcher workspace.
 
 - Use `$taskchef-bootstrap` when initializing or refreshing this workspace,
   changing or listing its configured projects, running TaskChef doctor,
-  repairing its managed instructions, or upgrading its TaskChef skill links.
+  or repairing its managed instructions.
 - For every actionable work request, use `$taskchef-delegate`
   automatically, even when the user does not explicitly say "delegate" or
   mention TaskChef.
@@ -13,6 +13,7 @@ This repository is a TaskChef dispatcher workspace.
 - Return immediately after dispatch, as required by `$taskchef-delegate`.
 - Answer directly only when the user explicitly asks about TaskChef itself or
   explicitly says not to delegate.
-- Use `$taskchef-reconcile` only when the user asks to refresh or fix outdated
-  TaskChef task states.
+- Use `$taskchef-report` only when the user asks for a live report about
+  delegated work. Reports query the recorded Codex tasks once and do not
+  write status or results to this workspace.
 <!-- taskchef:dispatcher-instructions:end -->

package/index.js

@@ -1,10 +1,8 @@
 export {
   addProject,
   buildTaskSummary,
-  buildReconciliationCandidates,
   canonicalDirectory,
   canonicalGitRoot,
-  createTask,
   doctorWorkspace,
   ensureWorkspaceInstructions,
   ensureWorkspaceSkills,
@@ -12,12 +10,11 @@ export {
   importProjects,
   initializeWorkspace,
   listProjects,
-  listTasks,
   readConfig,
+  listTasks,
   readTask,
+  recordTask,
   requireSafeId,
   removeProject,
-  updateTask,
   validateConfig,
-  validateResult,
 } from "./src/workspace.js";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "taskchef",
-  "version": "1.0.2",
+  "version": "3.0.0",
   "description": "A non-blocking interactive dispatcher for visible Codex tasks.",
   "license": "MIT",
   "author": "Favo Yang",
@@ -18,6 +18,7 @@
     "taskchef": "bin/taskchef.js"
   },
   "files": [
+    ".codex-plugin",
     "assets",
     "BACKLOG.md",
     "bin",
@@ -26,12 +27,19 @@
     "src",
     "skills/taskchef-bootstrap",
     "skills/taskchef-delegate",
-    "skills/taskchef-reconcile"
+    "skills/taskchef-report"
   ],
   "engines": {
     "node": ">=18"
   },
+  "devDependencies": {
+    "conventional-changelog-conventionalcommits": "^10.3.0",
+    "yaml": "^2.9.0"
+  },
   "scripts": {
     "test": "node --test tests/taskchef.test.js"
+  },
+  "dependencies": {
+    "proper-lockfile": "^4.1.2"
   }
 }

package/skills/taskchef-bootstrap/SKILL.md

@@ -1,32 +1,34 @@
 ---
 name: taskchef-bootstrap
-description: "Initialize, diagnose, or refresh TaskChef dispatcher workspaces, project configuration, managed AGENTS.md instructions, and TaskChef skill links. Use when creating a TaskChef workspace, adding, importing, listing, or removing configured projects, running TaskChef doctor, repairing dispatcher setup, or upgrading installed TaskChef skills. Do not dispatch user work or reconcile executor threads."
+description: "Initialize, diagnose, or refresh TaskChef dispatcher workspaces, project configuration, task history, and managed AGENTS.md instructions. Use when creating a TaskChef workspace, adding, importing, listing, or removing configured projects, running TaskChef doctor, or repairing dispatcher setup. Do not dispatch user work or report on executor threads."
 ---
 
 # TaskChef Bootstrap
 
 Initialize or refresh a data-only TaskChef dispatcher workspace.
 
-Resolve this linked skill with `realpath`. The TaskChef source root is two
-parents above the skill directory. Invoke `<source-root>/bin/taskchef.js` for
+Resolve this skill directory with `realpath`. The TaskChef plugin root is two
+parents above the skill directory. Invoke `<plugin-root>/bin/taskchef.js` for
 all deterministic workspace operations.
 
 ## Boundaries
 
 - Keep implementation, tests, and reports in the TaskChef source repository.
-- Keep only `AGENTS.md`, `taskchef.json`, `tasks/*/task.json`, and the three
-  TaskChef skill links in a dispatcher workspace.
-- Do not dispatch tasks or reconcile executor threads during bootstrap unless
+- Keep only `AGENTS.md`, `taskchef.json`, and `tasks.jsonl` in a dispatcher
+  workspace.
+- Do not dispatch tasks or report on executor threads during bootstrap unless
   the user separately requests those actions.
 - Never use collaboration agents, hooks, schedules, polling, or daemons.
 
 ## Initialize and repair
 
 1. Run `workspace init --json`. It takes no stdin, creates an empty
-   configuration when missing, and idempotently creates or refreshes the task
-   directory, managed instructions, and all three skill links.
+   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.
 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
+   workspace. Doctor is read-only. Rerun `workspace init --json` to repair the
    managed scaffold.
 3. Report the actions or failed checks. End without dispatching unless the user
    separately requested work.
@@ -38,7 +40,7 @@ all deterministic workspace operations.
    projects are outside the v1 contract.
 2. Add one project with `project add <path>`, normally supplying `--name` and a
    curated `--description`. The CLI detects Git status, exact Git root, and a
-   canonical GitHub `origin`; use `--no-github` or `--github-repo` only to
+   canonical GitHub `origin`. Use `--no-github` or `--github-repo` only to
    override detection.
 3. Bulk import with `project import <file|-> --json`. Input is a JSON array of
    objects containing `path` plus optional `name`, `description`, and
@@ -46,5 +48,4 @@ all deterministic workspace operations.
    or description when omitted. Use `--replace` only when the user explicitly
    requests replacement.
 4. Inspect configured projects with `project list --json`. Remove by name with
-   `project remove`; require explicit user intent before `--force` when task
-   records reference the project.
+   `project remove`. Existing task entries keep their project snapshots.

package/skills/taskchef-delegate/SKILL.md

@@ -1,30 +1,30 @@
 ---
 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, splitting work across projects, or retrying pending executor creation. Dispatch must return immediately and must 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. Record successful dispatches, return immediately, and never use subagents, hooks, schedules, or foreground waiting."
 ---
 
 # TaskChef Delegate
 
 Create real Codex tasks from a TaskChef data workspace and return immediately.
 
-Resolve this linked skill with `realpath`. The TaskChef source root is two
+Resolve this skill directory with `realpath`. The TaskChef plugin root is two
 parents above the skill directory. Use the TaskChef executable under that root
 for all deterministic workspace and task-record operations.
 
 ## Boundaries
 
 - Keep implementation, tests, and reports in the TaskChef source repository.
-- Keep only `AGENTS.md`, `taskchef.json`, `tasks/*/task.json`, and the three
-  TaskChef skill links in a dispatcher workspace.
+- 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, daemons, or event logs.
+- Never use hooks, callbacks, schedules, polling, or daemons.
 - Never wait for delegated work after executor creation.
 - Never collect transcripts or hidden reasoning.
 
 ## Dispatch
 
 1. Run
-   `<source-root>/bin/taskchef.js project list --json --workspace <workspace>`
+   `<plugin-root>/bin/taskchef.js project list --json --workspace <workspace>`
    to load and validate the configured routing targets. Use
    `$taskchef-bootstrap` if the workspace is missing or unhealthy.
 2. Split the request into the smallest independently useful outcomes. Include
@@ -33,18 +33,16 @@ 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. For an explicit retry, require the exact task ID and run
-   `<source-root>/bin/taskchef.js task show <task-id> --json --workspace <workspace>`.
-   Reuse the record only when its status is `pending`; ask for the task ID when
-   it is missing and reject retries of non-pending records. For new work, run
-   `<source-root>/bin/taskchef.js task create --json --workspace <workspace>`
-   with the task record JSON on stdin before executor creation.
-6. Create one real Codex task per record using the exact saved project and a
-   local environment on its executor host.
-7. Immediately run
-   `<source-root>/bin/taskchef.js task update <task-id> --json --workspace <workspace>`
-   with the `running` status and returned `threadId` on stdin. Never persist
-   `hostId`.
-8. Leave a failed creation pending. Do not invent an ID or delete the record.
-9. Return immediately with a created-thread directive for every success. Do
+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
+   `<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
+   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.