taskchef 8.7.1 → 9.0.1

package/.codex-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "taskchef",
-  "version": "8.7.1",
-  "description": "Dispatch work from a data-only workspace to visible Codex project tasks.",
+  "version": "9.0.1",
+  "description": "Native Codex dashboard with lightweight project delegation.",
   "author": {
     "name": "Favo Yang",
     "url": "https://github.com/favoyang"
@@ -11,16 +11,16 @@
   "license": "Apache-2.0",
   "keywords": [
     "codex",
-    "delegation",
-    "dispatcher",
+    "dashboard",
+    "usage",
     "tasks"
   ],
   "skills": "./skills/",
   "mcpServers": "./.mcp.json",
   "interface": {
     "displayName": "TaskChef",
-    "shortDescription": "Dispatch work to the right Codex project task.",
-    "longDescription": "Route work to visible Codex project tasks, monitor them in the dashboard, and get concise cached-first coordination briefs.",
+    "shortDescription": "See your Codex chats, usage, and pull requests.",
+    "longDescription": "A native dashboard for local Codex chats with usage estimates, pull request status, queued prompts, and schedules. Delegate work through native Codex project tools.",
     "developerName": "Favo Yang",
     "category": "Productivity",
     "capabilities": [
@@ -29,10 +29,7 @@
     ],
     "websiteURL": "https://github.com/favoyang/taskchef",
     "defaultPrompt": [
-      "$taskchef-bootstrap Set up TaskChef and index my local Codex projects.",
-      "$taskchef-delegate Do X in Y project.",
-      "$taskchef-dashboard Ensure and open the TaskChef dashboard.",
-      "$taskchef-copilot Summarize recent delegated work and tell me what needs attention."
+      "$taskchef:delegate Do X in Y project."
     ],
     "brandColor": "#D97706",
     "composerIcon": "./assets/taskchef.svg",

package/.mcp.json

@@ -2,9 +2,10 @@
   "mcpServers": {
     "taskchef": {
       "command": "node",
-      "args": ["./mcp/server.js"],
+      "args": [
+        "./mcp/server.js"
+      ],
       "cwd": ".",
-      "env_vars": ["TASKCHEF_WORKSPACE"],
       "tool_timeout_sec": 30
     }
   }

package/README.md

@@ -1,173 +1,50 @@
 # TaskChef
 
-**Less time managing tasks. More time moving them forward.**
+A native dashboard for your Codex chats. See running work, questions that need
+answers, queued prompts, usage estimates, schedules, and pull request status.
+Chats appear regardless of how they were started.
 
-When work spans several Codex projects, you have to choose the right project,
-find each conversation again, and check which tasks are waiting for you.
-TaskChef gives you one dispatcher conversation as a central place to talk to
-agents and delegate work across projects, plus a dashboard for seeing what
-needs your attention.
+## Install
 
-Give TaskChef a GitHub issue or a rough idea. It uses an explicit project name,
-the conversation's context, or saved repository mappings to choose a Codex
-project; if the destination is unclear, it asks you to choose. TaskChef creates
-separate, ordinary Codex tasks in those projects. Each has its own conversation
-and native tools, and tasks can run in parallel.
+Install **TaskChef** from the `favoyang-plugins` Codex marketplace. TaskChef uses
+a local Node.js MCP server; Node.js 22.18+, 23.2+, or 24+ is required. Open **TaskChef**
+from the Codex sidebar. No dispatcher workspace or project indexing is needed.
 
-You can keep using Codex as you do today. Start by delegating work where the
-project choice or follow-up is cumbersome, then bring more work into TaskChef
-as you go.
+Codex databases and logs stay on your computer and remain the source of truth.
+TaskChef keeps its own settings, manual Done marks, notification state, and
+rebuildable caches. Optional GitHub authentication provides live PR status;
+usage prices are API-equivalent estimates, not subscription billing.
 
-## What working with TaskChef looks like
+## Delegate
 
-Suppose you have indexed two Codex projects, **payments** and **recipe-book**,
-and saved a GitHub repository mapping for payments. In your TaskChef dispatcher
-conversation, paste a payments issue link and ask:
+From Codex's floating chat, use `$taskchef:delegate Do X in Y project.` The skill finds
+native projects and creates an ordinary Codex chat. It asks when the destination
+is unclear and returns the chat link. There is no executor skill or separate
+task database. Confirmed project aliases can be retained as small routing notes.
 
-```text
-Investigate this issue, fix the cause, and run the relevant tests: https://github.com/example/payments/issues/42
-```
-
-TaskChef uses the issue URL's repository to identify the mapped payments
-project. It then opens a separate Codex task there and returns its link. The
-task investigates the issue in its own conversation while other delegated
-tasks can work in recipe-book or other projects.
-
-In the same dispatcher conversation, start another task from a rough idea:
-
-```text
-In recipe-book, explore an idea for weekly meal planning. Discuss the approach with me before coding.
-```
-
-TaskChef selects recipe-book by name and opens a separate task there. Discuss
-the options in that task. If a written plan would help, ask it to save a
-Markdown plan, then ask it to implement the agreed approach in the same task.
-A plan file is created when you request one; it is not a required step for
-every task.
-
-The screenshots in this walkthrough use illustrative demo data. Open the
-dashboard beside TaskChef master to see both tasks across your projects.
-In Codex, call `open_taskchef_board` for the [TaskChef sidebar](docs/mcp-app.md).
-It reads local Codex data and groups chats as **Scheduled**, **Running**,
-**Waiting for input/review**, and **Done**. Interrupted chats stay in Waiting with an **Interrupted** tag. Empty board columns remain visible with a short message. Ambiguous records stay
-**Unverified**. Running follows the latest selected turn
-state; these labels do not prove task outcomes. Mark Done writes only TaskChef's separate local state. A new Codex turn
-resets that mark.
-The main dashboard's **Board** groups reported tasks by **Working**,
-**Needs input**, **Completed**, and **Failed** so you can see their status at a glance.
-
-![TaskChef master beside the dashboard board with recipe-book working and payments needing input](docs/images/readme-board.png)
-
-*Board gives an overview of task status across projects.*
-
-If the payments task needs a decision, it might ask, for example, whether to
-show a failed refund beside the original payment or in a separate list. Switch
-to **List** to see each task's request, latest result, and status in rows. Filter
-by **Needs input** to focus on the payments task's question.
-
-![TaskChef master beside the dashboard list filtered to Needs input, showing the payments request and result](docs/images/readme-list.png)
-
-*List shows the payments request and result in the Needs input queue.*
-
-Select the payments task and choose **Open chat** to answer in its original
-Codex conversation.
-
-![Payments task detail showing Open chat and the question in its activity timeline](docs/images/readme-needs-input.png)
-
-*Payments task details show the question and the Open chat action.*
-
-In that conversation, answer the question and ask the task to finish:
-
-```text
-Show failed refunds beside the original payment. Implement it and run the tests.
-```
-
-When the work finishes, its result appears on the dashboard; TaskChef does
-not post each result back into the dispatcher chat.
+## Upgrade from the dispatcher
 
-![Completed payments task detail showing the latest result and earlier question](docs/images/readme-completed.png)
+The dispatcher CLI, five old skills, task tracking tools, and web server are
+retired. Existing dispatcher workspaces and task logs are left untouched on
+disk; they are no longer live state. Native settings remain in their existing
+location. See the [native contract](docs/spec.md) and
+[storage notes](docs/taskchef-next-storage.md).
 
-*The completed task shows its latest result above the earlier question.*
-
-Keep the dashboard beside your conversation in Codex's built-in browser. It
-shows each task's latest request and result. Open a task to see its total
-reported work duration, token usage, and estimated cost, with the same figures
-for each turn in its activity timeline. Duration is reported wall-clock time
-spent on turns; cost is an API-equivalent estimate, not a bill. Token and cost
-figures can be unavailable when usage cannot be mapped to the Codex task.
-Task states normally come from the task's own reports; TaskChef does not
-automatically supervise execution.
-
-## Install and delegate your first task
-
-You need Node.js 18 or newer, Git, Codex desktop, and local access to the
-projects that will receive work. Install the plugin:
+## Development
 
 ```sh
-codex plugin marketplace add favoyang/codex-plugins
-codex plugin add taskchef@favoyang-plugins
-```
-
-For the first run, set up the TaskChef dispatcher and import your saved local
-Codex projects:
-
-```text
-$taskchef-bootstrap Set up TaskChef and index my local Codex projects.
-```
-
-After bootstrap, choose **New chat** in Codex and select the TaskChef dispatcher
-project at `~/.agents/taskchef`. We suggest renaming the new conversation
-**TaskChef master**, then pinning it for easy return. Bootstrap registers and
-opens the project; you create, rename, and pin the conversation yourself.
-Replace `<your-project>` with one of your indexed
-Codex project names and try a read-only first request:
-
-```text
-In <your-project>, explain how to run the app and tests. Do not change files.
+npm ci
+npm test
+npm run check:mcp-app
+npm run build:mcp-app
 ```
 
-TaskChef returns a link to the new Codex task. From then on, the dispatcher
-checks your saved Codex projects when you delegate, so you do not need to
-reindex after adding one. The local dashboard normally starts when the TaskChef
-plugin activates. Open the [dashboard link](http://127.0.0.1:3210/) from the
-end of each dispatcher response in Codex's side browser, beside your
-conversation. If the dashboard is unavailable, ask `$taskchef-dashboard` to
-ensure and open it. Use `$taskchef-bootstrap` to add repository mappings or
-refine project descriptions when routing needs more context. If the installed
-skills do not appear, activate or reload the TaskChef plugin in Codex and try
-again.
-
-## Choose models for each role
-
-In the dashboard's **Settings** page, choose a model and reasoning effort for
-the **Orchestrator**, **Planner**, **Implementer**, and **Reviewer** roles.
-TaskChef saves these preferences in native Codex agent files under
-`~/.codex/agents/` and applies them when it dispatches the corresponding work.
-Set them once for future tasks; a model choice you make explicitly for a task
-takes precedence over its role preference.
-
-![TaskChef Settings page with model and reasoning effort for four roles](docs/images/readme-roles.png)
-
-*Settings shows the model and reasoning effort selected for each role.*
-
-## More detail
-
-Read the [frequently asked questions](https://favoyang.com/taskchef/#faq) for
-answers about delegation, the dashboard, model roles, and local data.
-
-The [advanced guide](docs/advanced-guide.md) covers project indexing, routing,
-task reporting, dashboard behavior, recovery, updates, and development. The
-[specification](docs/spec.md) and [workflows](docs/workflows.md) describe the
-implementation contracts. TaskChef was inspired by
-[FirstMate](https://github.com/kunchenguid/firstmate); the
-[comparison](docs/firstmate-taskchef-comparison.md) explains their different
-approaches.
-
-## License
-
-Copyright 2026 Favo Yang. TaskChef is licensed under the
-[Apache License 2.0](LICENSE).
+Develop on a topic branch and update **TaskChef Dev** first. Keep **TaskChef**
+on the published release. After validation, independent review, merge, and a
+successful release workflow, update TaskChef from the released package when
+the merge publishes a release. Otherwise keep its existing published version.
+The Dev copy uses the separate `taskchef-next` plugin ID and **TaskChef Dev**
+name; apply that identity only to its local staging package. See
+[development packaging](docs/mcp-app.md#development-plugin-identity).
 
-Third-party dependencies retain their own licenses. The OpenAI Codex icons
-are excluded from TaskChef's license; see the
-[Codex asset notice](assets/CODEX_ASSET_NOTICE.md).
+[Native app guide](docs/mcp-app.md) · [GitHub setup](docs/taskchef-next-github.md)

package/docs/mcp-app.md

@@ -2,9 +2,9 @@
 
 The public app name is **TaskChef**. “TaskChef Next” remains the internal project name.
 
-TaskChef requires Node.js 22.18+, 23.2+, or 24+ for read-only SQLite connections. The rest of TaskChef continues to support the package's Node.js 18 minimum. An unsupported Node runtime produces a fatal version error before TaskChef opens a database.
+The native dashboard requires Node.js 22.18+, 23.2+, or 24+ for local Codex SQLite access.
 
-Call `open_taskchef_board` in Codex to open **TaskChef**. In a sidebar or fullscreen host view, it shows the read-only board, filters, and chat details. In an inline chat view, it shows a short recent-chat list with direct **Open chat** actions. The app uses local Codex metadata and does not modify the TaskChef dispatcher workspace.
+Call `open_taskchef_board` in Codex to open **TaskChef**. In a sidebar or fullscreen host view, it shows the read-only board, filters, and chat details. In an inline chat view, it shows a short recent-chat list with direct **Open chat** actions. The app uses local Codex metadata and does not require a dispatcher workspace.
 
 The server reads all eligible top-level chats from `~/.codex/state_5.sqlite` and their latest turn from `~/.codex/thread_history_1.sqlite`. Both SQLite connections are read-only. It excludes typed subagents and Guardian reviews, JSON subagent sources, known `thread_spawn_edges` children, chats with no turn record. Standalone `source=exec` and regular `source=cli` chats remain eligible in the collector, but the view hides them by default. The plugin details page has native switches for Show exec sessions, Show CLI sessions, and Show archived chats. The MCP server stores these choices in `~/.agents/taskchef-next/settings.json`, shared by all TaskChef views. Each visible poll reads the current settings, even when the database snapshot is unchanged. These choices apply to the board, counts, project choices, Details eligibility, and the compact inline view. Archived chats are hidden by default and use their own Archived column when shown. Details shows the recorded lifetime direct child count. Names and titles can contain user text; the app prefers name, then title, then a chat ID fallback.
 
@@ -49,7 +49,7 @@ Cards show the chat title, project, a plain two-line preview, activity time, and
 
 Details pairs the full recorded latest-turn request and response, each initially capped at three lines with independent Show more/Show less controls. Selected quotes render as Markdown quotes and file/image references as named attachments. Generated request headings and context metadata are hidden in the display. Recorded input remains unchanged. Raw HTML is ignored and relative file links appear as text.
 
-Time labels use compact relative dates by default, with calendar dates available in settings. Schedule and PR icons appear in the status line. Queue reasons and lifetime subagent counts remain in Details. See [dashboard UI](dashboard-ui.md) for the presentation contract.
+Time labels use compact relative dates by default, with calendar dates available in settings. Schedule and PR icons appear in the status line. Queue reasons and lifetime subagent counts remain in Details. See [the native contract](spec.md) for the product boundary.
 
 
 
@@ -181,8 +181,25 @@ visibly and is preserved for repair.
 ## Development plugin identity
 
 Keep the released **TaskChef** plugin and a separate **TaskChef Dev** plugin.
-The development copy must already use the plugin ID `taskchef-next`.
-Before installing it through a local marketplace, run:
+Use this order for every development change:
+
+1. Work in a topic branch/worktree. Build and validate the current source.
+2. Copy the current runtime, built UI, skill, and production dependencies into
+   a separate local staging package. Update **TaskChef Dev** from that package
+   and test it before merging. Never copy development changes into TaskChef's
+   released installation.
+3. Pass independent review and the pull request checks, then merge when authorized.
+4. If the merge publishes a release, wait for the complete release workflow,
+   including its marketplace update. Update **TaskChef** from the published
+   package and verify its version. If no release is published, leave TaskChef
+   on its existing published version.
+
+For a full Dev update, give the staging package a unique development version
+in both `package.json` and `.codex-plugin/plugin.json` (and package-lock metadata
+if present), such as `9.0.0-dev.1`. Set only the staging manifest's plugin name
+to `taskchef-next`; keep the source release manifest named `taskchef`.
+Before installing the staging package through the local development marketplace,
+run:
 
 ```sh
 node scripts/prepare-mcp-app-preview.js /path/to/staging/plugin
@@ -209,7 +226,7 @@ From the source checkout, run:
 npm run update:mcp-app-preview -- /path/to/the/running/taskchef-next/version
 ```
 
-The helper builds the UI, checks the target is TaskChef, and replaces only
+The helper builds the UI, checks the development plugin ID is `taskchef-next`, and replaces only
 `src/mcp-app/dist/index.html` atomically. It preserves the plugin version, server
 code, dependencies, and local data. It refuses missing or redirected HTML paths.
 Then right-click **TaskChef Dev** in the Codex sidebar and choose **Refresh**.