Todo List

Todo List turns one goal into an ordered checklist and presents one task at a time. It is intentionally not a result ledger: it does not classify task outcomes, aggregate evidence, or produce a completion report.

Start the workflow

mcp__moira__start({ workflowId: "moira/todo-list", parentExecutionId: "none" })

The first step obtains 1–100 tasks. If the current user or caller context already contains a schema-valid ready list, its content stays the author’s: every item is submitted with its wording and scope unchanged, nothing is dropped, and no unrequested work is added. The order is the executor’s: items are placed where their prerequisites already hold, a remark that governs the whole job is attached to the items it constrains instead of being executed as one, and where the resulting order differs from the written one, the difference and the dependency behind it are visible to the author before any work starts. Otherwise the same step plans the list once from the current goal. Each task contains only:

• action: the self-contained work to perform;
• expected_result: the observable condition that proves completion.

Both strings are non-empty and limited to 1,000 characters. Array position is the task identity; the agent does not supply IDs, cursors, totals, statuses, or result codes.

Execution

Todo List owns a one-based cursor. It projects the current task, tells the agent its action and expected result, and waits. The agent performs the real work and verifies the expected result before calling step() with exactly one field:

{ "evidence": "The focused test command passed." }

evidence is a non-empty string of at most 500 characters. It is a concise acknowledgement for the current step, remains node-local, and is not copied into a workflow-global array or terminal report.

If the task is incomplete or blocked, the agent must not call step(). It reports the verified blocker to the user, so the cursor stays on the current task. A schema-valid acknowledgement advances the cursor exactly once. Exhausting the ordered array completes the workflow.

Revising the checklist mid-run

When the checklist itself turns out wrong — remaining tasks are obsolete, missing, or in the wrong order — the agent jumps to the revision node instead of finishing a list it knows is wrong:

mcp__moira__step({ processId, teleportTo: "teleport-revise-tasks" })

This is a jump target: no step leads into it, so a revision is always a deliberate decision. It is not an escape from a task that is merely hard, blocked, or failing — that case stays with the rule above.

The revision step asks for the complete corrected checklist and the position to continue from:

{
  "tasks": [
    { "action": "…already executed, unchanged…", "expected_result": "…" },
    { "action": "Repair the configuration the first task revealed as wrong", "expected_result": "The service starts with the corrected configuration" }
  ],
  "resume_from_task": 2
}

Already executed tasks keep their original positions, because position is task identity and the run resumes by position. Everything before resume_from_task is treated as done and is not executed again. The workflow recomputes the total from the submitted array — the agent never supplies counts or cursor arithmetic — and continues through the ordinary cursor check, so a position past the end of the new list simply completes the run.

Supplying an existing checklist

A caller starts Todo as a child workflow and includes its schema-valid ready task array in the child’s task context. The first Todo step then submits that array through the ordinary step() response:

{
  "tasks": [
    {
      "action": "Check the implemented requirement",
      "expected_result": "The caller's domain report contains the verified result"
    }
  ]
}

There is no separate supplied-task branch and no pre-start input mapping. The intake step preserves the content of a ready array rather than replanning it, orders it by dependency, and starts at the first item. Where two supplied items each need the other’s result, no order satisfies both, and that pair is named to the author rather than chosen silently. Keep domain results in the caller. For example, a requirements-coverage workflow should write its own report and own COVERED/GAP classifications instead of asking Todo List to transport them.

Completion contract

Todo List completes with an empty terminal output: {}. Completion means every supplied checklist item received a schema-valid acknowledgement after the agent performed and checked it. Per-item evidence remains in the execution interaction history; it is not promised as an accumulated output API.

A subgraph caller that needs domain data must produce and persist that data itself. The Todo success connection only indicates that the checklist reached its End node.