You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+7-5Lines changed: 7 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -213,16 +213,18 @@ The TaskManager now uses a direct tools interface with specific, purpose-built t
213
213
Tasks have a status field that can be one of:
214
214
-`not started`: Task has not been started yet
215
215
-`in progress`: Task is currently being worked on
216
-
-`done`: Task has been completed
216
+
-`done`: Task has been completed (requires `completedDetails`)
217
217
218
218
#### Status Transition Rules
219
+
219
220
The system enforces the following rules for task status transitions:
220
221
- Tasks follow a specific workflow with defined valid transitions:
221
222
- From `not started`: Can only move to `in progress`
222
223
- From `in progress`: Can move to either `done` or back to `not started`
223
224
- From `done`: Can move back to `in progress` if additional work is needed
224
-
- When a task is marked as "done", the `completedDetails` field should be provided to document what was completed
225
+
- When a task is marked as "done", the `completedDetails` field must be provided to document what was completed
225
226
- Approved tasks cannot be modified
227
+
- A project can only be approved when all tasks are both done and approved
226
228
227
229
These rules help maintain the integrity of task progress and ensure proper documentation of completed work.
228
230
@@ -243,7 +245,7 @@ A typical workflow for an LLM using this task manager would be:
243
245
244
246
#### Task Approval
245
247
246
-
Task approval is controlled exclusively by the human user through a CLI command:
248
+
Task approval is controlled exclusively by the human user through the CLI command:
247
249
248
250
```bash
249
251
npm run approve-task -- <projectId><taskId>
@@ -252,7 +254,7 @@ npm run approve-task -- <projectId> <taskId>
252
254
Options:
253
255
-`-f, --force`: Force approval even if the task is not marked as done
254
256
255
-
This command sets the `approved` field of a task to `true` after verifying that the task is marked as `done`. Only the human user can approve tasks, ensuring quality control.
257
+
Note: Tasks must be marked as "done" with completed details before they can be approved (unless using --force).
completedDetails:"Created repository at github.com/example/business-site and initialized with HTML5 boilerplate, CSS reset, and basic JS structure."
347
+
completedDetails:"Created repository at github.com/example/business-site and initialized with HTML5 boilerplate, CSS reset, and basic JS structure."// Required when marking as done
description: "Mark a project as complete after all tasks are done and approved.",
123
+
description: "Mark a project as complete. Can only be called when all tasks are both done and approved. This is typically the last step in a project workflow.",
description: "Modify a task's title, description, or status. Note: completedDetails are required when setting status to 'done'.",
202
+
description: "Modify a task's properties. Note: (1) completedDetails are required when setting status to 'done', (2) approved tasks cannot be modified, (3) status must follow valid transitions: not started → in progress → done.",
description: "Approve a completed task. Tasks must be marked as 'done' with completedDetails before approval. Note: This is a CLI-only operation that requires human intervention.",
description: "Get the next task to be done in a project.",
279
+
description: "Get the next task to be done in a project. Returns the first non-approved task in sequence, regardless of status. Use this to determine which task to work on next.",
0 commit comments