jb/pi-todo-herdr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: strengthen task workflow and compaction recovery

Browse Source
This commit is contained in:
lesetong
2026-07-23 01:23:10 +08:00
parent fe05b278a4
commit 7d876735b2
13 changed files with 380 additions and 81 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+12 -8
View File
@@ -6,11 +6,12 @@ Hierarchical, session-local task tracking for [Pi](https://pi.dev), with atomic
## Features
- Five focused tools: `add_task`, `update_task`, `rm_task`, `list_task`, and `get_task`
- Parent/child task trees with generated, stable integer IDs
- Five focused tools: `set_tasks`, `update_task`, `rm_task`, `list_task`, and `get_task`
- Parent/child task trees with generated integer IDs and atomic append/replace modes
- Atomic batch mutations: every requested change succeeds or none of it is applied
- Four states: `pending`, `in-progress`, `blocked`, and `done`
- Session-branch persistence across reload, resume, fork, and tree navigation
- Session-branch persistence across reload, resume, fork, tree navigation, and context compaction
- A concise first-action workflow prompt plus a one-shot post-compaction recovery reminder
- Compact Pi widget with hierarchy, status colors, and an adaptive progress bar
- Optional Herdr metadata showing the current task in the agent sidebar
@@ -45,20 +46,23 @@ pi remove npm:pi-todo-herdr
## Usage
For complex work, Pi can create and maintain the task tree automatically. The extension adds one short prompt guideline encouraging task tracking for multi-step work without forcing it for trivial requests.
For large, multi-stage work, the extension instructs Pi to call `set_tasks` before exploration as the only tool in the first batch. Smaller work remains untracked. Pi then updates task states at each real transition instead of reconstructing progress at the end.
After automatic or manual context compaction, the extension sends one short hidden reminder only when unfinished tasks exist. Pi calls `list_task` to recover the authoritative current IDs and statuses; the full tree is not injected on every model call.
| Tool | Parameters | Behavior |
| --- | --- | --- |
| `add_task` | `{ tasks: [...] }` | Atomically adds multiple tasks. Nested `children` create descendants. |
| `set_tasks` | `{ mode, tasks, force? }` | `append` extends the tree; `replace` atomically installs a new tree or clears it with `[]`. Replacing unfinished work requires `force: true`. |
| `update_task` | `{ tasks: [...] }` | Atomically patches multiple tasks. `parentId: null` moves to the root; `position` is a zero-based sibling index. |
| `rm_task` | `{ ids: [...] }` | Removes multiple tasks. Removing a parent cascades through its descendants. |
| `rm_task` | `{ ids: [...], reason }` | Removes only mistaken, duplicate, or canceled tasks. Removing a parent cascades through its descendants. |
| `list_task` | `{}` | Returns the full tree as compact `id/status/name` lines. |
| `get_task` | `{ ids: [...] }` | Returns complete task details, including parent and child IDs. |
Example add call:
Example append call:
```json
{
"mode": "append",
"tasks": [
{
"name": "Implement authentication",
@@ -75,7 +79,7 @@ Example add call:
}
```
Task IDs are generated by the extension and never reused within a session branch. Multiple tasks may be `in-progress`. A parent can be marked `done` only when all of its descendants are also `done`.
Descriptions are optional, but useful scope, constraints, and done criteria improve recovery through `get_task`. IDs are not reused by append/remove operations; `replace` deliberately rebuilds IDs from `1`. Replace forbids `parentId`, so new hierarchy must use nested `children`. Multiple tasks may be `in-progress`. A parent can be marked `done` only when all descendants are also `done`.
## Pi Widget