moooon
Motir
Vibe the project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.
- Vibe Project
- Open Source
- AI Agent
- AI Loop
- 6
- 需求
- 4
- 贊同
- 588
- 已規劃
- 5,392
- 已發布
- (motir-meta) The SKILL doors cite nine pack paths that no guard checks — `MIRROR.check.py` assertion 7 sweeps `prompts/*.md` non-recursively, so the corpus's new front entrance can point at a retired pack under a green gate
- (motir-core) The ONBOARDING fact never crosses the wire — a `plan` submit carries no `context.onboarding`, so motir-ai guesses it from an EMPTY TREE and a migrate onboarding over an imported backlog is planned as continued work
- An `acceptance*.spec.ts` that imports the PROMOTED shim produces no receipt, and passes — nothing detects the swap
- `PLAN_ALONG_THE_USER_JOURNEY` is a rule about STORIES delivered to every container lay cell — `lay/project` lays epics and `lay/story` lays subtasks, and both are told to sequence stories; the discharge test narrows `kind-container` to the one cell that proposes them
- (motir-meta) The runbook MIRROR of MOTIR-4719 — `kind-container.md` back to `phase = lay`, `kind-story.md` split per unit by the discharge test into a lay pack and the both-phase count rule, the boundary clause to `kind-story-author.md`, and `split.py`'s SELECTOR, the MANIFEST and the 3866 note follow; five guards green
- (motir-core) An agent CANNOT publish an acceptance receipt over MCP — the tool the ADR names does not exist, the `test` dispatch prompt never asks for one, and a missing receipt looks exactly like a successful run
- (motir-ai) The container kind packs are routed by KIND alone at AUTHOR — `kind-container`'s one unit and three of `kind-story`'s four are discharged only by LAY tools, yet `author/epic` and `author/story` receive them; route per unit by the discharge test, and move the vertical-slice unit's BOUNDARY clause to the author pack
- (motir-ai) TWO identities in one system message — "You are Motir planning Motir's customers' products" and, on three of four situations, "You are Motir's work-item-tree GENERATION / AUGMENTATION / plan REVISION planner" (retired job kinds as self-description); and the TREE the planner builds is never defined
- 23 (motir-core) A missing work item's 404 is INVISIBLE — the stock not-found sets body colour from `prefers-color-scheme` while the ground behind it follows the app's own `data-theme`
- Planning bug: MOTIR-4703 enumerated a field's READERS, concluded it was unwired, and prescribed a fix that contradicts the contract recorded at its WRITE site
- (motir-ai) A session reads the PLAN, not the TREE — an author session's level omits the COMMITTED siblings under the same parent, and a REVISION is grounded on its proposals alone with every committed work item refused, though a reviewer may ask for one to change
- (motir-ai) The REVISION arm never descends either — `readRevisePlanTarget` passes no `walk`, so a revision's one lay session is the project's TOP LEVEL whatever the plan holds, and `lay/story` · `lay/task` · `lay/bug` stay unreachable for it
- 3937.16 (motir-ai) A revision of ANY plan holding a `subtask` or `task` proposal THROWS — `PlanStateItem` carries no `type`, so `authorPending`'s per-proposal author session cannot compose `author/subtask`
- (motir-ai) The lay session's STEP 5 opens with a rule about DESCRIPTIONS it never sees — "if a later description invalidates an earlier sibling, go BACK and fix it" is a single-session leftover in `RUNBOOK_LAY_CLOSE`
- (motir-ai) The augment situation prompt is a second runbook — its operation-era STEP list collides with the FIVE STEPS (an author session is told "STEP 4 alone", then handed STEPS 1, 2 and 5), and its two CORE RULE boxes reach BOTH phases of EVERY anchored run and forbid the reconcile the lay session is told to perform
- (motir-ai) The LAY tier still speaks in ONBOARDING's voice — "THE ONBOARDING WORKFLOW", "the onboarding root rule" and "THE ONBOARDING GROUNDING" reach every lay session of every situation, though only the project-first row is onboarding
- (motir-core · design) `todo-list.mock.html` puts CSS escapes inside its `class` attributes, so 138 utilities never match — right by accident in light, and unreadable in its own dark panel
- A plan's TITLE and SUMMARY cannot be corrected after creation — the correction door reaches every proposal but never the plan, so one wrong sentence costs the whole plan
- (motir-ai) The MODE is a PASS-START SNAPSHOT stated as a fact about the plan — every `author` session in pass 1 is told "the plan is empty, nothing has been proposed on it yet" right after the level's titles were proposed; a session reads the tree before it starts, so the axis is a relic of the pass loop and should be retired (or read per session)
- (motir-ai) A LAY session cannot RE-TITLE a committed sibling — `title` is a body key owned by `author`, which left the lay surface, and a kept sibling never gets an author session; the `phase-lay` reconcile rule still promises "re-title … a `modify`" for a tool that no longer exists, so a `todo` item with a wrong title can only be archived and re-proposed