Motir

The headline differentiator — an AI planning layer on the now-complete PM core (Epics 1–6). A chat / callout front door drafts discovery context, generates and augments the work-item tree in the PM core, and turns work items into agent-ready prompts dispatched to the user's own coding agent. This is the closed motir-ai layer the open core calls over a documented HTTP API. A team that never opens the AI still has a full Jira alternative; this epic makes Motir AI-native on top of it.

---

Structured along the USER JOURNEY — sequenced by dependency, not by feature and not by number

This epic is organised by the journey a user actually walks, not by feature bucket. The build order lives entirely in the blocked_by graph (the roadmap renders it) — there are no positional "7.x" numbers driving sequence; a story's key is just an identifier. The done / cancelled stories below are shipped history: they keep their original 7.x titles and the journeys are built around them (never re-opened, re-titled, or re-sequenced).

Foundations — shared motir-ai substrate every journey routes through

No home in an open PM tool; this is where the open-core line is drawn.

• Shared-context retrieval — the plan-tree graph + code graph every planner reads.
• Planning self-learning loop — the typed lesson store injected at plan time.
• Shipped substrate they build on (done): Core↔AI contract + persistence, AI infrastructure — gateway, metering, credit ledger, Plan substrate — proposal · review · materialize, Motir MCP server.

Journey — start fresh: from an idea to a reviewed, dispatchable backlog

The primary path. Arrive → onboard → make the plan.

• Start-fresh onboarding (done) established the idea→reviewed-backlog flow; on top of it the Onboarding entrance is the new-vs-existing front door, Design-system selection records the project's tokens, and Issue-tree generation is the engine that emits the work-item tree + its dependency DAG as a reviewable Plan. (These are a fan off the done onboarding foundation — genuinely parallel slices, not a forced chain.)

Journey A — onboard an EXISTING project: a repo and/or an imported backlog

Connect what already exists, then generate against it.

• GitHub integration / GitLab integration connect the repo + feed the code graph → Coding-convention + code-health audit derives the convention → Issue importer — Jira/Linear/GitHub/CSV pulls an external backlog → Migrate-existing-codebase onboarding folds it into the tiers and generates → WF3 orchestration ties BYOK + existing code + import together, end-to-end with verification.

Journey — evolve the plan after it exists (expand + re-plan)

Everything here reads the generation engine + the foundations, so it is gated on the plan already existing.

• Re-planning — augmentation, expansion & completion-aware is the producer that emits modify/remove/add proposals; Contextual planning from each work item is the per-item entry (chat on any item to expand/modify it); Cadence — auto-planning + AI sprint planning automates expansion when the ready set drains and packs short coding-agent sprints. (Expand and re-plan are two facets of the same stories — one "evolve" slice.)

Journey — the CLI: drive the work loop from the terminal

• Motir CLI — next / run / auto over the MCP (the done Motir MCP server is its contract).

Ask Motir — the cross-cutting assistant surfaces (reachable everywhere, outside the five journeys)

• The "M" AI callout is the floating orb → Plan · Ask · Help shell; it hosts Ask about this project (Q&A over plan, docs & work items) and Help with a task (item-scoped draft / summarise / assist).

---

Locked AI architecture

(The Epic-7 planning discussion with Yue, 2026-06-11; each story carries its slice.)

1. One-directional writes. motir-core is the system of record; the AI NEVER writes the tree. It GENERATEs a tree-delta, motir-core persists via the shipped workItemsService after human approval (Principle #3).
2. A tool-use SESSION, not a one-shot call. motir-ai HOSTS the planning agent and reads on demand; the whole tree is reachable every job, transmitted never. Context scales by the operation's blast radius.
3. Graph-traversal, not RAG. Two relational graphs walked over MCP, no vector store — the plan tree (motir-core: rollup + is_blocked_by + comments) and the code graph (motir-ai codegraph, GitHub/GitLab-read-fed, webhook-refreshed). The verified Atlassian-Rovo mirror (Teamwork Graph).
4. Async job model serving BOTH the chat/callout planners and the headless MCP/CLI planners over one API boundary — co-equal front doors.
5. motir-ai is STATEFUL (headless ≠ stateless): its own DB holds the context stores with no home in an open PM tool — direction docs, planning-lessons, code graph. This SHARPENS the open-core line (motir-core stays a complete, exportable Jira clone with zero AI tables).

Two project kinds: start-fresh (shipped first) and existing-project migration (Journey A).