| todo_create_scenario | Create a new todo board scenario (DRAFT) with one initial todo section. Optionally seed the board with items (each { text, checked?, plain?, note?, id? } — id auto-derived from text when omitted). RECOMMENDED: for every item also set `plain` — a one-sentence, jargon-free plain-language explanation that sits UNDER the technical `text`, so a non-technical stakeholder understands what the item means and why it matters. Especially when turning a technical report/analysis into a board, give each item a `plain`. Returns { scenarioId, slug, title, sectionId, itemIds, moduleId }. Slug auto-generated from title (collision-suffixed). The board section heading defaults to 'Yapılacaklar'. Caller must be authenticated; the scenario is owned by ctx.user. Use this to start a fresh task board (meeting actions, project tasks, a service job list). | — |
| todo_get | Read a todo board scenario's sections WITH their stable item ids — the read path for todo_apply (you address items by id). Accepts scenarioId (cuid or slug); optional sectionId narrows to one board. Caller must own the scenario. Returns { scenarioId, slug, boardCount, boards: [{ sectionId, key, label, title, itemCount, summary: { total, done, needsAttention, unaddressedHumanNotes, status, attention }, items: [{ id, text, checked, status, attention, plain, result, note, notes, ... }] }] }. Call this first to recover ids before applying ops. | — |
| todo_apply | Apply MULTIPLE todo operations to one board section in a SINGLE atomic write (one SectionVersion → no version race, no per-op round-trips). The workhorse for bulk updates / reconciling a board against reality. ops[] (1-100), each one of: { op:'add', text, plain?, status?, result?, attention?, due?, assignee?, priority?, tags?, note?, id? } | { op:'check', id, checked, result? } | { op:'update', id, text?/plain?/status?/attention(null clears)?/due?/assignee?/priority?/tags?/note? } | { op:'remove', id } | { op:'note', id, text, author? }. id-based only — read ids first via todo_get. RECOMMENDED: on every 'add' (and 'update' where missing) also set `plain` — a one-sentence, jargon-free explanation under the technical `text` for non-technical readers; especially when converting a technical report into board items, give each item a `plain`. To add an ALREADY-RESOLVED item in one shot, pass `status:'done'` together with `result` (the resolving commit/outcome, e.g. '✓ abc1234 — fix'); no separate 'check' op needed. ATOMIC: if any referenced id is missing, NOTHING is written (whole batch rejected). status<->checked kept in sync. Returns { sectionId, versionId, version, contentChanged, opsApplied, itemCount }. | — |
| todo_report | Render a board's todo sections as a markdown progress report. mode 'technical' (default) = full detail (text + status/attention/priority/assignee/due + plain + result + notes); mode 'plain' = stakeholder-facing simple language (uses each item's plain text + result only). Accepts scenarioId (cuid or slug) + optional sectionId. Caller must own the scenario. Returns { scenarioId, slug, mode, boardCount, markdown }. Same board, two audiences. | — |
| todo_add_board | Add another todo section (board) to an existing todo scenario — a scenario can hold several boards (e.g. 'Bu hafta', 'Backlog', 'Beklemede'). Optionally seed items (each { text, checked?, plain?, note?, id? }). RECOMMENDED: for every item also set `plain` — a one-sentence, jargon-free explanation under the technical `text` for non-technical readers. Accepts scenarioId (cuid or slug). Returns { sectionId, key, order, versionId, scenarioSlug, itemIds }. Heading/label defaults to 'Yapılacaklar'. Caller must own the scenario. | — |
| todo_delete_board | Delete a whole todo board (section) and ALL its versions from a todo scenario. Caller must own the scenario. Returns { deletedSectionId, scenarioId, scenarioSlug, deletedVersionCount }. Hard delete — irreversible. (To CLEAR a board but keep it, send { op:"remove" } items via todo_apply instead.) | — |