taskchef 5.12.0 → 6.1.0

package/SPEC.md

@@ -2,383 +2,106 @@
 
 ## Purpose
 
-TaskChef is an interactive Codex dispatcher. It routes independent assignments
-to real Codex tasks in configured local projects, records each submitted
-delegation in a task history, and returns immediately. New tasks append; locked
-atomic updates may later resolve identity and replace the latest semantic result.
+TaskChef routes work from a data-only dispatcher workspace to visible Codex
+project tasks, stores exact child links, and caches explicit semantic results.
 
-Codex tasks remain authoritative for current activity. TaskChef stores only the
-latest useful semantic result, not a second lifecycle or event database.
+## Workspace
 
-## Core behavior
+The canonical workspace contains only:
 
-1. The user submits a request in the dispatcher workspace or explicitly invokes
-   the delegation skill from another Codex project. Work merely concerning the
-   TaskChef source code does not implicitly invoke delegation outside 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 embeds a generated TaskChef UUID marker, executor-ownership sentence, and
-   result-callback instruction, then records the task with `threadId: null`.
-5. It creates an independently openable Codex task. A durable returned ID is
-   resolved immediately; otherwise bounded recent-task checks accept exactly
-   one child whose structured initial input contains the exact marker.
-6. It returns without waiting for executor work to complete.
-7. Executors report `completed`, `needs_input`, or `failed` through MCP. Reports
-   filter old terminal entries, use one live metadata snapshot, and read only
-   tasks whose cached result may be stale.
+- `AGENTS.md`: managed dispatcher instructions plus user instructions.
+- `taskchef.json`: schema-versioned configured projects.
+- `tasks.jsonl`: append-on-create, atomic-rewrite-on-update task snapshots.
 
-A task created by TaskChef owns its delegated initial assignment. It executes
-that assignment in the current task and does not re-dispatch it merely because
-the subject is TaskChef or another configured project. The task may still use
-TaskChef when the initial assignment explicitly requests delegation of separate
-work or when the user later explicitly requests a new delegation.
+All workspace writes use one lock and atomic replacement. Task IDs and non-null
+thread IDs are globally unique.
 
-Several active executors may target the same project.
+## Task schema
 
-## Workspace layout
+New records use schema version 4 and contain:
 
-```text
-~/.agents/taskchef/
-├── AGENTS.md
-├── taskchef.json
-└── tasks.jsonl
-```
+- immutable `id`, project snapshot, title, instruction, and `createdAt`;
+- nullable `threadId` until executor self-linking succeeds;
+- `status`, nullable bounded `summary`, nullable `turnId`, `updatedAt`, and
+  `updatedBy`.
 
-`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.
-
-`workspace init` is idempotent. It creates an empty configuration and task
-log when missing, refreshes managed instructions, and removes legacy TaskChef
-skill symlinks.
-
-Every command resolves one workspace in this precedence order:
-
-1. explicit `--workspace <path>`
-2. `TASKCHEF_WORKSPACE`
-3. `~/.agents/taskchef`
-
-`TASKCHEF_WORKSPACE` must be absolute or start with `~/`; this prevents the
-hook, MCP server, and CLI from resolving one relative override against
-different process directories. The current directory is never an implicit
-workspace. `workspace path` exposes
-the resolved absolute path and its source. Bootstrap compares this canonical
-path with native Codex projects, and when absent invokes the validated
-`codex app <path>` command before verifying the native list again. It never
-uses `codex add` or a hard-coded application bundle path.
-
-`doctor` validates configuration, project paths, the JSONL log, managed
-instructions, and the absence of legacy TaskChef skill links without modifying
-the workspace.
-
-Neither the workspace nor any directory containing it can be configured as a
-delegation project. All project configuration and task-history mutations share
-one cross-process workspace lock. Writers reread and validate state while
-holding that lock and publish complete files by atomic replacement.
-
-## Project configuration
-
-`taskchef.json` is the user-facing routing configuration:
-
-```json
-{
-  "schemaVersion": 2,
-  "projects": [
-    {
-      "name": "payments-api",
-      "path": "/workspace/payments-api",
-      "isGitRepository": true,
-      "githubRepos": [
-        "https://github.com/example/payments-api",
-        "https://github.com/example/payments-sdk"
-      ],
-      "description": "Owns payment authorization, capture, refunds, and provider integrations."
-    },
-    {
-      "name": "local-data-tools",
-      "path": "/workspace/local-data-tools",
-      "isGitRepository": false,
-      "githubRepos": []
-    }
-  ]
-}
-```
-
-- `schemaVersion` identifies the configuration format.
-- `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.
-- `githubRepos` is a deduplicated list of canonical GitHub repository URLs. Use
-  `[]` when the project advertises no repositories. A managed `*-workspace`
-  project lists each child or sub-repository that should route to it.
-- `description` is optional routing context.
-
-TaskChef classifies work against `name`, every URL in `githubRepos`, and
-`description`. The path identifies the checkout but is not a routing hint. For
-a GitHub issue or pull-request URL, TaskChef compares canonical,
-case-insensitive owner/repository identities across every configured list. It
-ignores the issue or PR suffix, `http` versus `https`, optional `www`, trailing
-slashes, and trailing `.git`. It routes only when one configured project
-matches; ambiguous and unmatched URLs are never guessed.
-
-`project add` and `project import` detect Git status, exact Git roots, and
-canonical GitHub origins. `--github-repo` is repeatable. Import merges by
-canonical path, preserves an existing name or description when omitted, and
-unions existing and imported repository lists without duplicates. `--replace`
-replaces the configured set. Removing or replacing a project does not alter
-historical task entries.
-
-Schema version 2 replaces the string-or-null `githubRepo` field with the
-list-valued `githubRepos` field. Schema-version-1 configurations remain
-compatible: reads normalize a legacy string to one canonical list item and
-legacy `null` to `[]`; `workspace init` persists the migration atomically, and
-any later configuration write emits version 2.
-
-The configuration does not store dispatcher identity, execution modes,
-schedules, task state, host information, or the workspace path.
-
-## Task entry
-
-`tasks.jsonl` contains one compact JSON object per line, in append order:
-
-```json
-{"schemaVersion":3,"id":"c0f010ff-84f2-4838-a69d-0ff1f5d721d7","project":{"name":"payments-api","path":"/workspace/payments-api","isGitRepository":true,"githubRepos":["https://github.com/example/payments-api","https://github.com/example/payments-sdk"],"description":"Owns payment authorization, capture, refunds, and provider integrations."},"title":"Add payment retry logs","instruction":"<!-- taskchef_id=c0f010ff-84f2-4838-a69d-0ff1f5d721d7 -->\n\nThis task owns the delegated assignment. Execute it in this task; do not re-dispatch it merely because it concerns TaskChef or a configured project. Explicit requests to delegate separate work remain valid.\n\nBefore ending, call the TaskChef report_result MCP tool with completed, needs_input, or failed and a concise summary. Use needs_input only for a semantic decision or information the user must provide; a native approval prompt is live Codex state, not a TaskChef result. Do not include secrets, transcripts, or raw command output.\n\nAdd structured logs for failed payment retries and test them.","threadId":"019f9d46-f42c-7482-9707-3c107bf241ee","createdAt":"2026-08-08T10:00:00.000Z","status":"completed","summary":"Added structured retry logs and regression coverage.","turnId":"019f9d47-result-turn","updatedAt":"2026-08-08T10:08:00.000Z","updatedBy":"mcp"}
-```
-
-- `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, including its first-line
-  `<!-- taskchef_id=<full UUID> -->` correlation marker, executor-ownership
-  paragraph, and assignment body.
-- `threadId` identifies the created Codex task, or is `null` when creation was
-  accepted but its initial identity has not yet been linked.
-- `createdAt` is the dispatch time as an ISO 8601 timestamp.
-- `status` is `working`, `needs_input`, `completed`, or `failed`; legacy
-  entries normalize it to `null`.
-- `summary` is a nullable, bounded latest-result summary.
-- `turnId` identifies the initial hook turn or latest reported result turn. An
-  MCP result for a linked executor requires it; null is allowed only for a
-  failed creation before any durable thread exists.
-- `updatedAt` is the server-side update time.
-- `updatedBy` is `dispatcher`, `hook`, or `mcp`.
-
-Schema-version-3 entries have exactly these fields. IDs and non-null thread IDs must be
-unique; any number of unresolved entries may have `threadId: null`. 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.
-
-Task creation appends entries. Identity resolution and result callbacks acquire
-the same cross-process lock, reread and validate the complete log, patch one
-matching entry, and atomically replace the file. Resolution is idempotent and
-one-way from null to one unique durable thread ID. Result callbacks must match
-the recorded task/thread and replace only the latest result snapshot; they do
-not append events.
-
-The project snapshot preserves the route even if the project is renamed,
-moved, or removed later. Entries never contain transcripts, hidden reasoning,
-`hostId`, or an event history.
-
-New task entries use schema version 3. Version 1 and 2 entries remain readable
-and normalize to version 3 in API and CLI output with nullable result fields.
-Historical task entries with the
-old heading-style marker also remain readable. New nullable records, candidate
-matching, and resolution require the exact HTML-comment marker; TaskChef never
-uses an old marker to correlate a thread. Direct records that already have a
-durable thread ID remain marker-independent because they do not use recovery.
-TaskChef does not eagerly rewrite legacy history solely for these compatibility
-cases.
+New unresolved records require the exact first-line HTML marker followed by a
+blank line. Schema 1-3 records and historical `updatedBy: hook` values remain
+readable without eager migration, and task read/list APIs expose their persisted
+schema version so reporting can distinguish legacy recovery from schema 4
+executor link-pending state.
 
 ## Dispatch workflow
 
-For each assignment, `$taskchef-delegate`:
-
-1. calls the structured `prepare_dispatch` tool and native Codex project
-   discovery concurrently; the preparation tool 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
-   `<!-- taskchef_id=<UUID> -->` marker as the first line, followed by a blank
-   line, the executor-ownership sentence, result-callback sentence, and
-   assignment body
-4. appends a `working` task entry with `threadId: null` through `record_task`
-   before executor creation
-5. creates a real Codex task at the exact configured path
-6. calls `resolve_task` when creation returns a durable thread ID; otherwise it
-   checks at 10 and 30 seconds and resolves only one recent task whose
-   structured initial input contains the exact marker
-7. records executor-creation failure as a `failed` semantic result on the
-   already-existing entry
-8. returns after the bounded identity check without waiting for executor work.
-
-Recording first closes the creation/hook race. On the exact marked prompt, the
-hook waits for the separately verified canonical identity, then writes only the
-initial turn plus `working`. It never persists the hook `session_id`, because a
-subagent hook can receive its parent's session ID. On later prompts whose
-session ID matches a recorded executor,
-the same `UserPromptSubmit` hook reads the task history and supplies the current
-turn ID as callback context without writing. No permission, tool, stop,
-notification, or session hook writes task lifecycle state. A provisional
-`local:` ID is diagnostic only and can never be persisted as `threadId`.
-
-The plugin bundles a local stdio MCP server with focused `prepare_dispatch`,
-`record_task`, `resolve_task`, and `report_result` tools. It accepts no workspace path from the
-model and resolves only an absolute (or `~/`-prefixed) `TASKCHEF_WORKSPACE` or the canonical
-`~/.agents/taskchef` default. The write tools reuse the public workspace APIs,
-so structured calls cannot bypass exact-field validation, locking, atomic
-replacement, unique IDs, or one-way nullable resolution. They are closed-world
-local mutations and never create Codex tasks. Desktop thread tools remain
-available only to the Codex skill; the standalone CLI remains available for
-bootstrap, manual inspection, and recovery.
-
-### Legacy end-to-end benchmark results
-
-Schema-v1 benchmark fixtures below validate historical bounded-resolver
-artifacts only. New benchmarks must measure record-before-create, initial-hook
-identity, and result callbacks without using the removed snapshot resolver.
-
-An explicitly requested live benchmark writes one ignored, timestamped JSON
-artifact through `scripts/e2e-benchmark.js`. Schema version 1 contains:
-
-- benchmark name, TaskChef version, run ID, and wall-clock start/end
-- project, title, and exact unmarked workload prompt
-- TaskChef task ID, nullable durable/client IDs, recording state, resolution,
-  and attempt count
-- ISO start/end, derived duration, and outcome for preparation/project listing,
-  task creation, recording, and optional provisional resolution
-- boolean record, marker, executor-output, and candidate-filter-effectiveness
-  validation results
-- derived total wall time, measured stage time, orchestration overhead,
-  resolution state, and attempt count
-
-Stage outcomes are `success|failed` for preparation,
-`durable|provisional|failed` for creation, `recorded|failed` for recording, and
-`native|discovered|unresolved|failed` for provisional resolution. `failed`
-distinguishes a terminal resolver error from a completed no-match checkpoint,
-which must proceed to the second fallback attempt. Task resolution is
-`immediate|native|discovered|unresolved`. Preparation failure has only the
-preparation stage and a null task ID; creation failure stops after creation;
-recording failure stops before provisional resolution. The committed example
-shows the durable success shape, while these transition rules define the
-shorter failure and longer provisional shapes.
-The writer derives `taskchefVersion` from the running package instead of
-trusting template input. Raw executor output and transcripts are never stored;
-`outputVerified` records only whether the requested output was verified.
-
-The writer rejects missing required stages, duplicate or unknown stages,
-invalid timestamps, contradictory workflow outcomes, overlapping stages,
-unknown fields, and overwriting an existing run. Later stages are omitted when
-preparation or creation fails, and provisional resolution is omitted when task
-recording fails. Fallback snapshot observations include the complete recent
-task count plus the filtered candidate and exact-match counts, from which
-candidate-filter effectiveness is checked. Each snapshot records
-`resolveWriteOutcome` as `not-attempted`, `succeeded`, or `failed`, so a unique
-match followed by an atomic write failure remains an honest unresolved result.
-A compact valid starting document is committed as
-`assets/e2e-benchmark-example.json`. Filenames use
-`<startedAt-with-colons-replaced>-taskchef-delegate-e2e.json`. Its cleanup
-operation removes only files matching the full generated filename grammar in
-the selected results directory.
-
-`task record` rejects an interactive TTY before reading because its protocol is
-exactly one JSON value followed by EOF. Workspace-lock contention is retried for
-up to seven seconds, while permanent permission failures such as `EPERM` or
-`EACCES` fail immediately so the caller can request the required permission
-without paying the contention retry budget.
-
-A failed executor creation normally leaves its pre-created entry with `failed`.
-The exported orchestration helper attaches `taskChefTaskId` and
-`taskChefResultReporting` (`recorded`, `failed`, or `unavailable`) to a thrown
-creation error so callers can recover the entry if failure reporting itself was
-not available. A failed pre-creation record stops before executor creation, so
-there is no untracked executor.
-
-## Task history and live reports
-
-The CLI reads persisted history without contacting Codex:
-
-- `task show <id-or-8-character-prefix>` returns one entry. By default it emits
-  labeled human-readable lines for title, project, status, summary, creation and
-  update metadata, task/thread/turn IDs, and instruction. A null ID renders as `-`.
-  Carriage returns and newlines in labeled values render as `\\r` and `\\n`.
-  The instruction starts on the line after `Instruction:` and retains its stored
-  line breaks and indentation. `--json` returns the unchanged complete task
-  object. The short form is the exact ID text printed by the default
-  human-readable `task list` output and succeeds only when it identifies
-  exactly one recorded task. Missing, ambiguous, malformed, shorter, and
-  wrong-case prefixes fail without selecting a task.
-- `task list` returns entries newest-first by creation time, optionally filtered
-  by historical project name or exact path. `--ascending` returns oldest-first.
-  Human rows include status, update time, task ID, and thread ID, abbreviating UUID-shaped IDs
-  to their first eight-character section unless `--full-id` is passed. Null
-  thread IDs display as `-`. ID formatting does not alter JSON values, and the
-  selected order applies to both human rows and the JSON `tasks` array.
-- `task summary` returns the total and per-project counts.
-- `task resolve <id> --thread-id <thread-id>` atomically fills one nullable
-  thread ID after Codex verifies the exact structured marker match.
-
-When the user requests an overview, `$taskchef-report` includes working,
-needs-input, unresolved, legacy, and terminal tasks updated during the last
-seven days. It omits older terminal entries unless explicitly requested or a
-single recent-thread metadata snapshot shows that they are active or awaiting
-approval. That one snapshot is a broad contradiction check: active or awaiting-
-approval metadata overrides a cached result immediately, without one detailed
-read per task. An inactive state does not prove semantic completion; in a broad
-overview it permits an `updatedBy: mcp` result to stand by default.
-Dispatcher- or hook-written `working` snapshots have no semantic callback and
-trigger a live read when selected; an inactive task without an MCP callback has
-an unknown outcome. An MCP-written `failed` snapshot with null thread/turn IDs
-is a fresh executor-creation failure and requires no live lookup. For a focused
-task, title, or project report, any newer matched metadata timestamp triggers at
-most one targeted read per selected inactive task. This distinguishes normal
-same-turn finalization from a quick newer turn by comparing structured turn IDs
-and native turn state. Missing callbacks, uncertain or contradictory identity
-or metadata, and explicitly fully-live requests also trigger one targeted read.
-Reads are batched in groups of eight. Broad overviews do not fan out reads over
-idle terminal tasks solely because their timestamps are newer. Reporting never
-persists inferred live state and does not poll, wait, or schedule work.
-
-## Boundaries
-
-TaskChef does not include:
-
-- lifecycle event history or hook-inferred completion
-- lifecycle event types beyond `UserPromptSubmit`
-- indefinite polling, daemons, heartbeats, dispatcher wakeups, 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 delegation records `working` before creating a visible Codex task.
-4. A durable creation resolves immediately; a provisional creation is linked
-   only after bounded discovery verifies one exact structured-marker match.
-5. The dispatcher returns without waiting for execution.
-6. Several independent assignments can create several entries, including
-   multiple entries for the same project.
-7. Task history commands return deterministic entries and project counts.
-8. MCP callbacks replace the latest needs-input, completed, or failed snapshot.
-9. A report skips old terminal tasks by default, checks live metadata once,
-   overrides active or approval-waiting tasks directly, and reads only anomalous
-   candidates without writing inferred state.
-10. Malformed JSONL, duplicate IDs, duplicate thread IDs, and symlinked managed
-   files fail safely.
+1. `prepare_dispatch` validates the workspace and returns one fresh lowercase
+   UUID, exact marker, timestamp, and routing targets.
+2. The marked instruction contains the executor ownership paragraph, mandatory
+   first-action `link_task` paragraph, result callback paragraph, and task body.
+3. `record_task` writes schema 4 with `threadId: null` before creation.
+4. Native task creation runs once.
+5. The dispatcher returns immediately, including for a provisional worktree
+   client ID. It does not list or read tasks, search markers, wait, poll, or
+   link the record.
+6. Creation failure writes a terminal `failed` result with null identities and
+   a concise bounded summary.
+
+## Executor self-linking
+
+The executor obtains its own durable native thread ID and calls
+`link_task(taskId, threadId)` before substantive work. The operation:
+
+- accepts only schema 4 records;
+- rejects unknown task IDs, malformed/provisional IDs, exact-marker mismatch,
+  thread reuse, and conflicting retries;
+- atomically changes only `null` to one durable ID under the workspace lock;
+- is idempotent for the same task and ID;
+- leaves rejected, unavailable, interrupted, or cancelled links visibly
+  pending and retryable.
+
+The executor must never use a parent/delegator ID, inherited session identity,
+title match, or provisional client ID. This is a cooperative local assertion,
+not transport-authenticated caller identity.
+
+## Semantic results
+
+`report_result` accepts `completed`, `needs_input`, or `failed` with a concise
+summary. Linked tasks require an exact stored thread-ID match and a non-null
+current turn ID. Self-linked schema 4 journeys require canonical, time-ordered
+Codex UUID turn IDs; each changed semantic result must use an ID newer than the
+stored turn, while an identical same-turn retry is idempotent. Creation failure
+is the sole null-identity result. Follow-up turns must self-read the exact
+thread and submit the new turn ID. Atomic writes preserve one JSONL line per
+task.
+
+## Legacy resolver
+
+The CLI-only `taskchef task resolve` command accepts unresolved schema 1-3
+records after an operator establishes one exact marker match. It rejects schema
+4 records. There is no public `resolve_task` MCP tool.
+
+## Dashboard and reports
+
+The existing file watcher observes `link_task` and result rewrites in real
+time. "Open task in Codex" uses only the self-linked child ID. Reports treat
+`updatedBy: mcp` terminal or needs-input snapshots as semantic cache and may
+compare them with one native metadata snapshot. Reporting never mutates task
+history or infers completion from hooks.
+
+## Packaging
+
+The plugin ships its skills, MCP server, CLI, dashboard, and source modules. It
+contains no hooks configuration, hook executable, hook runtime, or hook trust
+requirement.
+
+## Acceptance
+
+- Record-before-create and exact-marker guarantees remain mandatory.
+- Creation returns without post-create waiting, polling, task search, or reads.
+- A provisional-path executor self-links its exact durable child ID before
+  substantive work.
+- Parent/delegator and provisional IDs cannot be accidentally substituted.
+- Link and result retries are idempotent; conflicts cannot corrupt JSONL.
+- Link failures remain visible and retryable; creation failures are terminal.
+- Current-turn freshness is retained across needs-input, follow-up, and final
+  completion.
+- The plugin installs and runs without hook configuration or approval.

package/assets/e2e-benchmark-example.json

@@ -1,46 +1,50 @@
 {
-  "schemaVersion": 1,
-  "benchmark": "taskchef-delegate-e2e",
+  "schemaVersion": 2,
+  "benchmark": "taskchef-executor-self-link-e2e",
+  "taskchefVersion": "0.0.0",
   "runId": "replace-with-run-id",
-  "startedAt": "2026-08-13T06:30:00.000Z",
-  "completedAt": "2026-08-13T06:30:05.000Z",
+  "startedAt": "2026-08-24T10:00:00.000Z",
+  "completedAt": "2026-08-24T10:01:00.000Z",
   "workload": {
     "project": "example-project",
-    "title": "Example workload",
-    "prompt": "Return the requested example output."
+    "title": "Provisional self-link example",
+    "prompt": "Pause for approval, then complete the requested work."
   },
   "task": {
     "taskId": "00000000-0000-4000-8000-000000000000",
     "threadId": "00000000-0000-7000-8000-000000000000",
-    "clientThreadId": null,
+    "clientThreadId": "local:replace-with-provisional-id",
     "recorded": true,
-    "resolution": "immediate",
-    "resolutionAttempts": 0
+    "linked": true
+  },
+  "turns": {
+    "needsInput": "00000000-0001-7000-8000-000000000000",
+    "completion": "00000000-0002-7000-8000-000000000000"
+  },
+  "events": {
+    "preparedAt": "2026-08-24T10:00:00.000Z",
+    "recordedAt": "2026-08-24T10:00:01.000Z",
+    "createdAt": "2026-08-24T10:00:02.000Z",
+    "linkedAt": "2026-08-24T10:00:05.000Z",
+    "needsInputAt": "2026-08-24T10:00:20.000Z",
+    "followedUpAt": "2026-08-24T10:00:40.000Z",
+    "completedAt": "2026-08-24T10:01:00.000Z"
   },
-  "stages": [
-    {
-      "name": "prepare-and-list-projects",
-      "startedAt": "2026-08-13T06:30:00.000Z",
-      "completedAt": "2026-08-13T06:30:00.200Z",
-      "outcome": "success"
-    },
-    {
-      "name": "create-thread",
-      "startedAt": "2026-08-13T06:30:01.000Z",
-      "completedAt": "2026-08-13T06:30:01.100Z",
-      "outcome": "durable"
-    },
-    {
-      "name": "record-task",
-      "startedAt": "2026-08-13T06:30:02.000Z",
-      "completedAt": "2026-08-13T06:30:04.000Z",
-      "outcome": "recorded"
-    }
-  ],
   "validation": {
-    "recordVerified": true,
-    "markerVerified": true,
-    "outputVerified": false,
-    "candidateFilterEffective": false
+    "exactMarkerCorrelated": true,
+    "noDispatcherPostCreateReads": true,
+    "childIdentityVerified": true,
+    "parentIdentityRejected": true,
+    "linkRetryVerified": true,
+    "needsInputVerified": true,
+    "followUpTurnFresh": true,
+    "dashboardDeepLinkVerified": true,
+    "outputVerified": true
+  },
+  "summary": {
+    "totalWallMs": 60000,
+    "provisionalPath": true,
+    "linked": true,
+    "freshFollowUp": true
   }
 }

package/assets/taskchef-dark.svg

@@ -0,0 +1,9 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48" viewBox="0 0 48 48" fill="none">
+  <rect x="2" y="2" width="44" height="44" rx="11" fill="#F59E0B"/>
+  <path d="M15 37V27.5C11.9 26.3 10 23.6 10 20.5C10 16.4 13.4 13 17.5 13C19 10 21.2 8.5 24 8.5C26.8 8.5 29 10 30.5 13C34.6 13 38 16.4 38 20.5C38 23.6 36.1 26.3 33 27.5V37H15Z" fill="#FFFBEB"/>
+  <path d="M19 24L22 27L28.5 20.5" stroke="#78350F" stroke-width="3" stroke-linecap="round" stroke-linejoin="round"/>
+  <path d="M24 28V32M24 32H19M24 32H29" stroke="#78350F" stroke-width="3" stroke-linecap="round" stroke-linejoin="round"/>
+  <circle cx="19" cy="32" r="2" fill="#78350F"/>
+  <circle cx="29" cy="32" r="2" fill="#78350F"/>
+  <path d="M15 37H33" stroke="#78350F" stroke-width="3" stroke-linecap="round"/>
+</svg>

package/assets/taskchef.svg

@@ -0,0 +1,9 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="48" height="48" viewBox="0 0 48 48" fill="none">
+  <rect x="2" y="2" width="44" height="44" rx="11" fill="#D97706"/>
+  <path d="M15 37V27.5C11.9 26.3 10 23.6 10 20.5C10 16.4 13.4 13 17.5 13C19 10 21.2 8.5 24 8.5C26.8 8.5 29 10 30.5 13C34.6 13 38 16.4 38 20.5C38 23.6 36.1 26.3 33 27.5V37H15Z" fill="#FFF7ED"/>
+  <path d="M19 24L22 27L28.5 20.5" stroke="#7C2D12" stroke-width="3" stroke-linecap="round" stroke-linejoin="round"/>
+  <path d="M24 28V32M24 32H19M24 32H29" stroke="#7C2D12" stroke-width="3" stroke-linecap="round" stroke-linejoin="round"/>
+  <circle cx="19" cy="32" r="2" fill="#7C2D12"/>
+  <circle cx="29" cy="32" r="2" fill="#7C2D12"/>
+  <path d="M15 37H33" stroke="#7C2D12" stroke-width="3" stroke-linecap="round"/>
+</svg>