The task list and standing plan

While DataMind Oda works through a task with several steps, it keeps a task list: one item per step, marked as the work moves. The list belongs to the chat that recorded it, and the chat shows it as the plan while the work runs.

How an update works

Every update is the whole list. Oda sends the entire list with each update, and the update replaces the previous one. There are no partial updates and no per-item edits: to change one item, Oda sends the complete list again; to drop an item, it sends the list without it.
An item is its text and its state. Each item carries a short line naming the task, plus one of the three states below. Nothing else is recorded: there is no id, no priority and no other per-item field.
The text is trimmed first. Oda trims each item's text before the list is recorded.
Empty and repeated text are refused. An item whose text is empty once trimmed, or a list that names the same text twice, is refused, and nothing is recorded.
The latest update is the list. The list lives with the chat's record, and the most recent update is the list that counts, including after the chat is reopened.

The three states

State	Meaning
`pending`	Not started.
`in_progress`	Being worked on now.
`completed`	Finished.

Every item carries exactly one of the three, and each update states the state of every item in the list. In the chat they read Pending, In progress and Completed.

One task in progress, or several

How many items may be in progress at once depends on how DataMind Oda is set up: some setups allow several at once, for example when parts of the work run in parallel; others keep the list to one active task at a time.
With the one-active rule on, an update that marks two items as in progress is refused with Error: invalid todos: at most one task may be in_progress (got <n>), and nothing is recorded.
The rule is checked when an update is sent, and a list recorded under a different setting is kept as it is.

Who owns the list

One chat, one list. The list belongs to the chat that recorded it. Nothing is shared between chats, and each helper agent keeps its own list.
It stays with the chat. Close the chat and open it again, and the latest list is still there.
It needs a chat to record into. An update from a run with no chat behind it is refused with Error: todo_write requires an owning agent session before anything is recorded.

What you see in the chat

Every recorded update appears in the chat as a step row titled Update to-do list, holding the list that was sent.
While the list is current, the plan shows above the message box as a To-dos panel with the counts by state; expand it to read every item. Nothing shows before the first update.
When the next turn starts, the plan clears; after a turn ends, the finished checklist stays visible until then.
How the row and the plan read, including what changed between updates, is on Oda's to-do list; the chat around them is on Chat with Oda.

Messages an update can return

A recorded update answers with the counts of the whole list; a refusal arrives with an Error: prefix and leaves the list as it was.

Message	What it means
`Updated todo list: <pending> pending, <inProgress> in progress, <completed> completed.`	The update was recorded, and the counts describe the whole list.
Error: invalid todo: `content` must be a non-empty string	An item had no text left once it was trimmed.
`Error: invalid todos: duplicate content "<content>"`	The same task text appears twice in the list.
`Error: invalid todos: at most one task may be in_progress (got <n>)`	The one-active rule is on, and the update marks more than one item in progress.
`Error: todo_write requires an owning agent session`	The update came from a run with no chat to record into.

Questions, answered

Can a single task be edited on its own?

No. Every update sends the entire list and replaces the previous one, so there are no partial updates and no per-item edits: to change one task, Oda sends the complete list again, and to drop one, it sends the list without it.

What do the task states mean?

pending means the task has not started, in_progress means it is being worked on now, and completed means it is finished. Every item carries one of the three, and each update states the state of every item.

Why was my update refused for two tasks in progress?

The one-active rule is on in your setup: at most one item may be in progress at a time. An update that marks two is refused with Error: invalid todos: at most one task may be in_progress (got <n>), and nothing is recorded.

Why was a task refused for empty or repeated text?

Every task text must have real content once trimmed, and no text may appear twice in one list. An item with nothing left after trimming is refused with Error: invalid todo: `content` must be a non-empty string; a repeated text is refused with Error: invalid todos: duplicate content "<content>". In both cases nothing is recorded.

How long does the plan stay in the chat?

While the work runs and after a turn ends, the chat shows the plan from the latest update. When the next turn starts, the standing plan clears; every recorded update stays in the chat as its own row.

Can another chat or a helper agent see the list?

No. The list belongs to the chat that recorded it: nothing is shared between chats, and each helper agent keeps its own list.

What happens to the list when I reopen the chat?

The list stays with the chat's record, so reopening the chat brings the latest list back, and the most recent update is the list that counts.

Does every task get a list?

No. The list is for work with several steps; a task with one obvious step can run without one.

Where can I see what changed between two updates?

In the chat: expand the update row to read the list as it stood at that update, with what had changed since the previous one. Oda's to-do list covers what each row shows.