| list_projectsA | List every project misterdev currently knows about. Use when: you need to discover which projects are registered before calling
``status``, ``build``, or ``run`` on a specific one. Do NOT use when: the
project isn't registered yet — call ``scan`` first to register it. Related:
``scan`` (register projects), ``status`` (inspect one project). Takes no
parameters.
Side effects: none — read-only, calls no LLM, and returns the same result on
repeated calls (idempotent).
Returns a mapping of project id to an object with its registered ``path`` and
``name``; an empty mapping when nothing is registered.
|
| statusA | Show a project's tasks and their current state. Use when: you want to inspect what work exists and how far it has progressed,
e.g. before deciding whether to ``run`` pending tasks or ``build`` new work.
Do NOT use when: the project isn't registered — call ``scan`` first, or
``list_projects`` to find the right path. Related: ``list_projects``,
``run``, ``build``.
Side effects: none — read-only, calls no LLM, idempotent.
Returns the project's tasks, each with its id, title, and status.
|
| reportA | Return the latest build report, audit trail, and model performance. Use when: a ``build`` or ``run`` has finished (or was stopped) and you want
the outcome — which tasks completed/failed/deferred, per-file edits, failed
commands, governance escalations, unmet-goal gaps, token/cost totals, and
per-model success rates. This is misterdev's read-only equivalent of asking
"what did the last run find and do?". Do NOT use when: nothing has been
built yet — ``latest_report`` will be null. Related: ``status`` (live task
states), ``build``/``run`` (produce a report).
Side effects: none — reads only the project's ``.orchestrator`` artifacts,
calls no LLM, and returns the same result on repeated calls (idempotent).
Returns an object with ``latest_report`` (the most recent build's structured
summary, or null), ``audit`` (command/edit/governance counts), and
``models`` (per-model attempts, success rate, and average cost). Returns an
``error`` field instead when ``path`` is not an existing directory.
|
| scanA | Discover misterdev projects under a directory and add them to the registry. Use when: you have projects on disk that misterdev does not know about yet,
before calling ``status``, ``build``, or ``run`` on them. Do NOT use when:
the projects are already registered (call ``list_projects`` to check) — a
re-scan is harmless but redundant. Related: ``list_projects`` (see what is
registered), ``status`` (inspect a registered project).
Side effects: writes only to misterdev's project registry — it never reads,
edits, or executes any project code, and re-scanning the same directory is
idempotent (no duplicates).
Returns a short confirmation string naming the directory scanned.
|
| buildA | Autonomously plan AND execute a goal in a project, from scratch. Use when: you have a goal but no existing task plan — ``build`` analyzes the
project, decomposes ``goal`` into tasks, edits the code, and verifies each
change through build/test/lint/typecheck gates, reverting anything that
regresses. Do NOT use when: a task plan already exists and you just want to
execute it (use ``run``), or the working tree is dirty (commit/stash first).
Related: ``run`` (execute an existing plan), ``status`` (inspect tasks).
Pass ``reference_dir`` to port from an existing implementation: its
module/symbol map is extracted read-only and guides the plan.
Pass ``spec_text`` when you have already written the implementation spec
(e.g. in a Claude conversation) — misterdev skips its own planning phase
and executes your spec directly, making it Claude's execution backend.
DESTRUCTIVE side effects: edits files and makes git commits, and calls an
external LLM provider (open-world, non-idempotent). It refuses to run on a
dirty working tree. ``dry_run=True`` previews without changing anything;
``budget`` caps spend; ``max_tasks`` caps scope.
Returns a compact text report: what was done, per-gate results, and cost.
|
| runA | Execute a project's ALREADY-PLANNED pending tasks (a devplan). Use when: tasks already exist (from a prior ``plan`` or a devplan directory)
and you want to execute them. Do NOT use when: no plan exists and you are
starting from a goal — that is ``build``'s job (it analyzes and decomposes).
Related: ``build`` (plan + execute a goal), ``status`` (see the task ids).
Pass ``task_id`` to run a single task.
DESTRUCTIVE side effects: edits files and makes git commits, and calls an
external LLM provider (open-world, non-idempotent). ``dry_run=True`` previews
without changing anything.
Returns a short text summary of what was run or previewed.
|
| build_asyncA | Start an autonomous build in the BACKGROUND and return immediately. Use when: the build may run for minutes and you want to keep working — this
returns a ``run_id`` right away instead of blocking (as the synchronous
``build`` does) until the run finishes. Poll ``job_status`` with the
``run_id`` to watch progress, ``stop_job`` to cancel, ``list_jobs`` to see
everything running. Do NOT use for a quick preview — use ``build`` with
``dry_run=True``. Related: ``build`` (synchronous), ``report`` (final outcome).
DESTRUCTIVE side effects (once running): edits files, makes git commits, and
calls an external LLM provider. Refuses to start a second job for a project
that already has one running (one writer per project).
Returns ``{run_id, status}`` on success, or ``{error}`` when a job is already
running for this project.
|
| run_asyncA | Start executing a project's planned tasks in the BACKGROUND. Use when: a devplan exists and you want it executed without blocking — like
``run`` but returns a ``run_id`` immediately. Poll ``job_status``, cancel
with ``stop_job``. Do NOT use to plan from a goal — that is ``build_async``.
Related: ``run`` (synchronous), ``build_async``.
DESTRUCTIVE side effects (once running): edits files, makes git commits, and
calls an external LLM provider. Refuses a second job for a project that
already has one running.
Returns ``{run_id, status}``, or ``{error}`` when one is already running.
|
| job_statusA | Return a background job's current state. Use when: you started a job with ``build_async``/``run_async`` and want to
know whether it is still ``running`` or has ``succeeded``/``failed``/
``stopped`` — and, when finished, its report (``result``) or ``error``.
Read-only and idempotent. Related: ``list_jobs`` (all jobs), ``stop_job``.
Returns the job object (run_id, kind, project_path, status, result, error,
timestamps), or ``{error}`` when the run_id is unknown.
|
| stop_jobA | Request cooperative cancellation of a running background job. Use when: a ``build_async``/``run_async`` job should stop — it finishes any
in-flight task and starts no new work, then produces a partial report. Poll
``job_status`` afterward to confirm it reaches ``stopped``. Idempotent:
stopping a finished or already-stopped job is a harmless no-op. Related:
``job_status``, ``list_jobs``.
Returns ``{run_id, stopping: true}`` when a running job was signalled, or
``{run_id, stopping: false}`` when the id is unknown or already finished.
|
| list_jobsA | List every background job this server has started and their states. Use when: you want an overview of all ``build_async``/``run_async`` jobs —
running and finished — e.g. to find a lost run_id. Read-only, idempotent.
Related: ``job_status`` (one job), ``stop_job``.
Returns ``{jobs: [...]}``, each entry the same object ``job_status`` returns.
|
| propose_planA | Analyze the project and return ranked, UNAPPROVED work proposals. Use when: you want misterdev to recommend what to work on and let a human
approve a subset BEFORE any code is edited — the review gate. The proposals
are persisted, so ``get_plan`` re-reads them, ``approve_plan`` marks a
subset, and ``execute_plan`` builds the approved ones. The codebase is
analyzed in this process, so it never enters the client's context. Do NOT
use to execute immediately without review — that is ``build``. Related:
``get_plan``, ``approve_plan``, ``execute_plan``.
Side effects: spends LLM budget analyzing the project and writes the plan to
``.orchestrator/proposed_plan.json``; it edits NO source code.
Returns ``{items: [...]}`` — each item has an id, title, work_type,
rationale, and ``approved: false`` — or ``{error}`` on failure.
|
| get_planA | Return the persisted proposed plan and which items are approved. Use when: you want to review the proposals from ``propose_plan`` (and see
what has been approved so far) before approving or executing. Read-only and
idempotent. Related: ``propose_plan``, ``approve_plan``, ``execute_plan``.
Returns ``{items: [...]}`` (empty ``items`` when no plan has been proposed).
|
| approve_planA | Set the approval flags on the proposed plan, then persist. Use when: after ``propose_plan``/``get_plan`` you want to mark which items
should actually run. ``approve_all`` approves everything; otherwise
``approve_ids`` are approved and ``reject_ids`` un-approved (reject wins a
tie — the safer default). Idempotent. Then call ``execute_plan``. Related:
``propose_plan``, ``get_plan``, ``execute_plan``.
Side effects: rewrites ``.orchestrator/proposed_plan.json``; edits no code.
Returns ``{items: [...]}`` with updated flags, or ``{error}`` when no plan
exists to approve.
|
| execute_planA | Execute the APPROVED items from a previously proposed plan. Use when: ``propose_plan`` + ``approve_plan`` have selected the work and you
want it built — this composes a goal from the approved items and runs the
normal build pipeline (decompose, edit, verify, revert regressions). Do NOT
use before approving anything (it returns a no-op message). Related:
``propose_plan``, ``approve_plan``, ``build``.
DESTRUCTIVE side effects: edits files, makes git commits, and calls an
external LLM provider. Refuses a dirty working tree (like ``build``).
Returns a compact build report, or a message when nothing is approved.
|
