Conversation
|
|
||
| ### Plan Removal | ||
|
|
||
| Agent sends a `plan_removed` session update with the plan's `id` to dismiss it. This is a separate session update type from `plan_update`, keeping content updates and lifecycle events distinct. |
There was a problem hiding this comment.
I wonder if there is a way to null out the content like we do in some other areas rather than have another notification type?
Just a thought.
There was a problem hiding this comment.
I thought about this option, but then plan_remove event would also be typed — meaning that the agent needs to pass the correct entity type (file\markdown...). So I decided that providing just an id in a separate event is a simpler option. But we can change that
| | ---------- | ----------------------------------------------------- | ---------------------- | | ||
| | `items` | Structured entries (same semantics as today's `plan`) | `entries: PlanEntry[]` | | ||
| | `file` | Agent provides a file URI containing the plan | `uri: string` | | ||
| | `markdown` | Agent provides raw markdown text | `content: string` | |
There was a problem hiding this comment.
Can add this later, but is there a need for a label/description for some of these types?
There was a problem hiding this comment.
Do you mean like plan.name?
| "type": "items", | ||
| "id": "plan-1", | ||
| "entries": [ | ||
| { "content": "Step 1", "priority": "high", "status": "pending" } |
There was a problem hiding this comment.
What is the expectation of the client?
If I get multiple items updates, am I expected to render them all until they are removed?
And I assume the plan is "completed" not by being removed, but by all items being marked as done?
There was a problem hiding this comment.
If I get multiple items updates, am I expected to render them all until they are removed?
Plan update always updates the whole plan, each time you get it you should re-render all the entities.
And I assume the plan is "completed" not by being removed, but by all items being marked as done?
yes! Maybe we need something like plan.status in general, might be useful for file\markdown plan, but this can be added later
2 participants
No description provided.