Plan

Active

plan · v1.0.0

Free-form plan and runbook scenarios (PlanHub Plan equivalent). Markdown + optional concept wiki.

Schema Version:
1.0.0
Collection Type:
Campaign

Section Types

IDName
markdownMarkdown
wikiWiki
todomodules.plan.sectionTypes.todo

MCP Tools

NameDescription
plan_get_plan_markdownRetrieve a plan scenario rendered as markdown. Accepts the scenario id (cuid) or url slug. Walks sections in chapter reading order (chapter.order → section.order; chapter-less last), joins markdown sections with "\n\n---\n\n". CHUNKED for large plans (avoids MCP client timeout): pass chapterId to read one chapter, and/or offset+limit (default offset 0, limit 50) to page. Returns { scenarioId, slug, title, markdown, totalSections, offset, limit, returnedSections, hasMore, nextOffset }. Loop with nextOffset while hasMore is true. Errors if moduleId !== "plan".
plan_summarize_planGenerate a short summary of a plan. STUB today — returns a deterministic placeholder. Wired to a real LLM in Faz 6+ via the apps/web/lib/llm.ts provider abstraction.
plan_create_scenarioCreate a new plan scenario in DRAFT status with an initial markdown section. Returns { scenarioId, slug, title, sectionId }. Slug is generated from title (collision-suffixed). Tags optional, capped at 10. body optional — when omitted a starter markdown is used. Caller must be authenticated; the scenario is owned by ctx.user.
plan_add_sectionAppend a new markdown section to an existing plan scenario. Accepts scenarioId (cuid) or slug. Optional chapterId places the section in a chapter (must be same scenario; sections read in chapter.order → section.order). Returns { sectionId, key, order, versionId }. Validates the scenario is a plan (moduleId === "plan"). Auto-assigns next order; key defaults to "section-<order>" if omitted. NOTE: when authoring a multi-chapter scenario with parallel agents, split work by chapter (one writer per chapter) or use plan_add_sections to write a whole chapter atomically — that keeps section order correct. Caller must be authenticated.
plan_add_sectionsAppend MULTIPLE markdown sections to a plan scenario in ONE atomic call — the array order IS the reading order, so parallel agents cannot interleave even within the same chapter. Accepts scenarioId (cuid or slug) + optional chapterId (same scenario; ALL sections placed in that chapter) + sections[] (1-50, each { body, sectionTitle?, label?, key? }). Prefer one add_sections call per chapter when authoring a multi-chapter scenario. Returns { scenarioId, scenarioSlug, chapterId, sections: [{ sectionId, key, order, versionId }] }. Caller must be authenticated.
plan_create_collectionCreate a new Campaign-typed collection (plan module). Returns { collectionId, slug, title, type, itemCount, addedScenarioIds }. Slug auto-generated from title (collision-suffixed). Optionally pre-populate with caller-owned plan scenarios (scenarios: id or slug, max 50; non-owned or non-plan silently skipped). Caller must be authenticated; ownership = ctx.user.
plan_update_sectionUpdate a plan section's markdown content and/or label. Creates a new SectionVersion (git-commit pattern) when content changes, no-op when hash matches. Caller must own the parent scenario. Returns { sectionId, versionId, version, contentHash, contentChanged }. sectionTitle, body, label all optional; at least one must be provided. label:null removes the label.
plan_delete_sectionDelete a plan section and all its versions. Caller must own the parent scenario. Returns { deletedSectionId, scenarioId, scenarioSlug, deletedVersionCount }. Hard delete — irreversible. Use with care.
plan_update_scenarioUpdate a plan scenario's metadata (title/description/tags/status). At least one field required. tags is PUT semantics (full replace). description:null clears stored summary. status accepts DRAFT/PUBLISHED/ARCHIVED but use plan_publish_scenario for the canonical publish path (it also creates a ScenarioVersion snapshot). Caller must own the scenario. Returns updated row { scenarioId, slug, title, status, tags, description }.
plan_publish_scenarioPublish a plan scenario — creates a new ScenarioVersion snapshot (sectionManifest pointer list) and flips status to PUBLISHED. Re-publishing is allowed (version monotonically increments). Empty scenarios (no sections) are rejected. Caller must own the scenario. Returns { scenarioId, versionId, version, publishedAt, sectionCount }.
plan_add_to_collectionAdd a scenario to a plan-typed collection (type=Campaign). Caller must own the collection. Cross-module items allowed (the scenario may be language/film/etc — Collection.items[] is lax by design). Duplicate check: if the scenario is already in the collection the call fails. order optional — defaults to max(order)+1 (append). Returns { collectionId, scenarioId, itemId, order, scenarioModuleId }.
plan_remove_from_collectionRemove a scenario from a plan-typed collection (type=Campaign). Caller must own the collection. Returns { collectionId, scenarioId, removed:true }. If the scenario is not in the collection, throws. Other items keep their order (no compaction).
plan_add_wiki_sectionCreate a new EMPTY wiki section on a plan scenario. The section starts with zero concepts — call plan_wiki_add_concept for each glossary entry. Accepts scenarioId (cuid) or slug. Returns { sectionId, key, order, versionId, scenarioSlug }. Section label defaults to 'Kavramlar' when label omitted. Caller must own the scenario.
plan_wiki_add_conceptAppend a single concept card to a wiki section. The section must already exist (call plan_add_wiki_section first). slug must be unique within the section — duplicate slug rejects. definition is the 1-2 sentence summary shown when the accordion is collapsed; overview is the long body (markdown). examples and references default to empty arrays. Creates a new SectionVersion. Returns { sectionId, conceptSlug, versionId, version, conceptCount }.
plan_wiki_update_conceptPatch a single concept in a wiki section. Identified by slug (slug itself is immutable — to rename, remove + add). patch is a partial: any field omitted is unchanged. Pass examples: [] or references: [] to clear those arrays. Creates a new SectionVersion if content actually changed. Returns { sectionId, conceptSlug, versionId, version, contentChanged }.
plan_wiki_remove_conceptRemove a single concept from a wiki section by slug. The section itself stays (even if it becomes empty — drop the section via plan_delete_section). Creates a new SectionVersion. Returns { sectionId, removedSlug, versionId, version, conceptCount }.
plan_add_todo_sectionCreate a new todo (task list) section on a plan scenario. Optionally seed items (each { text, checked?, note?, id? } — id auto-derived from text when omitted). Accepts scenarioId cuid or slug. Returns { sectionId, key, order, versionId, scenarioSlug, itemIds }. Heading/label defaults to 'Yapılacaklar'. Caller must own the scenario. Opt-in: NOT created automatically — call this only when a task list is wanted.
plan_todo_getRead a plan scenario's todo sections WITH their stable item ids — the read path for todo_set_item / todo_update_item / todo_remove_item. Accepts scenarioId cuid or slug; optional sectionId narrows to one todo section. Caller must own the scenario. Returns { scenarioId, slug, todoSectionCount, todos: [{ sectionId, key, label, title, itemCount, items: [{ id, text, checked, note }] }] }. Call this first (e.g. in a new session) to recover item ids before toggling a checkbox — get_plan_markdown does NOT include todo sections.
plan_todo_applyApply MULTIPLE todo operations to one 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 (no text matching) — 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/plan into todo 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 with a per-op error). status<->checked kept in sync (status 'done' <-> checked true). Returns { sectionId, versionId, version, contentChanged, opsApplied, itemCount }.
plan_todo_reportRender a plan'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, todoSectionCount, markdown }. Same board, two audiences.
plan_todo_add_itemAppend one task item to a todo section. id auto-derived from text (slugified, collision-suffixed) when omitted — the returned itemId is used by todo_set_item / todo_update_item / todo_remove_item. checked defaults false. Creates a new SectionVersion. Returns { sectionId, itemId, versionId, version, itemCount }.
plan_todo_set_itemSet one todo item's checked state by id (the deterministic checkbox toggle — flips a single boolean server-side, no body rewrite, zero drift). No-op (no new version) if already in the requested state. Returns { sectionId, itemId, checked, versionId, version, contentChanged }.
plan_todo_update_itemPatch one todo item's text and/or note by id (id itself is immutable — to rename the id, remove + add). note:null clears the note. At least one of text / note must be provided. Creates a new SectionVersion if content changed. Returns { sectionId, itemId, versionId, version, contentChanged }.
plan_todo_remove_itemRemove one todo item by id. The section stays (even if it becomes empty — drop it via plan_delete_section). Creates a new SectionVersion. Returns { sectionId, removedItemId, versionId, version, itemCount }.
plan_replace_in_sectionSurgically replace exact text inside a markdown section's body WITHOUT rewriting the whole section (zero drift — everything outside the match stays byte-identical). `find` must occur exactly `count` times (default 1) or the edit errors without writing (fail-safe against ambiguous matches). replace may be empty to delete. Creates a new SectionVersion. Returns { sectionId, versionId, version, replacements, contentChanged }. Markdown sections only.
plan_append_to_sectionAppend text to the end of a markdown section's body WITHOUT rewriting it (zero drift — the existing body is preserved verbatim). separator (default '\n\n') is inserted between the old body and the new text. Use for adding a bullet, paragraph, or table row. Creates a new SectionVersion. Returns { sectionId, versionId, version, contentChanged }. Markdown sections only.

Usage Modes

IDName
reviewmodules.plan.usageModes.review

Example Scenarios