Skip to content
Motir
Start free

moooon

Motir

Vibe your whole 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
1
requests
0
upvotes
145
planned
1,361
shipped
Follow  — continues on app.motir.co
Request a featureAtom feed

← Motir · Work items

MOTIR-3324Done

Only an AGENT-fired re-plan files a planning bug — a user changing their own plan is not a planner defect

A re-plan is not evidence of a planning mistake. Two very different things reach the same handler:

  • The coding agent found the card wrong at execution time — mis-scoped, an unverified precondition, a contradiction. That IS a planner defect: the plan said something that did not survive contact with the repo.
  • The user changed their mind. Scope moved, priorities shifted, they learned something. The original plan was correct for what was known. Nothing was done wrong and no bug should be filed.

Today nothing separates them. log_planning_bug is a tool the planner LLM decides to call (treeGeneration.ts, offered in the tool set and instructed alongside log_planning_mistake), and replan.ts carries no trigger, actor or origin field — so the judgement rests entirely on the model's read of a situation whose cause it cannot see.

Filing on a user-driven re-plan is not a harmless false positive. It pollutes the planner-bug home with non-defects, and once this story lands it will reset lesson clocks and revive retired lessons on evidence that no mistake occurred — teaching the corpus from the user's change of mind.

Give the re-plan job its trigger, and gate the bug on it.

  1. The re-plan envelope carries who fired it — the coding agent finding a card wrong, or a person re-planning.
  2. log_planning_bug is only offered/instructed on the agent-fired path. A user-fired re-plan does the re-plan and files nothing.
  3. log_planning_mistake follows the same gate: a lesson is captured from a defect, not from a scope change.

If the envelope has to change in motir-core, that half is a named sibling card, not a second repo on this one. Read the envelope first and say which it is in the PR.

Acceptance criteria

  • The re-plan job carries the trigger, and its legal values distinguish an agent-found-card-wrong re-plan from a user-initiated one.
  • log_planning_bug and log_planning_mistake are unavailable — not merely discouraged — on the user-initiated path.
  • An agent-fired re-plan still files exactly as it does today, asserted against the existing suite.
  • A user-fired re-plan files no bug and captures no lesson, asserted.
  • Where the trigger is absent or unknown, the behaviour is stated and defended in the code — defaulting to "file" pollutes the corpus, defaulting to "don't" loses real defects, and picking silently is the failure.
  • If the envelope change lands in motir-core, the PR names the sibling card that owns it.

Context refs

  • motir-ai src/jobs/handlers/replan.ts — the handler, today with no trigger field.
  • motir-ai src/llm/treeGeneration.ts — log_planning_bug in the tool set, logBugExecutor, and the instruction pairing it with log_planning_mistake.
  • motir-ai src/jobs/handlers/generateTree.ts — the only caller of filePlanningBug.
  • motir-ai src/services/lessonService.ts — filePlanningBug, captureMistake.