@roadmapperai/mcp 0.9.1 → 0.9.4

package/AGENTS.md

@@ -85,6 +85,13 @@ that's almost always what you actually want.
   CANDIDATE for `propose_capability` (human-confirmed) followed by
   `move_tasks`. Tune `minClusterSize` (default 3) / `fitThreshold`
   (default 0.2) to control sensitivity.
+- `detect_theme_sprawl` — the theme-level companion. Scores every
+  active theme against every other and flags pairs that overlap enough
+  to be consolidation candidates, each with a suggested merge
+  (`move_capabilities` the lighter theme's bets into the heavier, then
+  `archive_theme`). This is how you keep theme count in check now that
+  agents create themes autonomously (see `propose_theme`). Run it at
+  quarterly review. Tune `threshold` (default 0.34).
 - `get_agents_md` — re-read this contract on demand.
 
 **Multi-workspace addressing.** A single MCP install can talk to any
@@ -137,18 +144,37 @@ to "tell the human what I'd do"):
   succeeds (this is a nudge, not a gate — unlike `propose_capability`,
   which hard-blocks until you've done discovery). Surface the warning
   to the user.
+- `propose_tasks` — **bulk** create many tasks under ONE capability in
+  a single call. **This is the token-efficient path: prefer it over N
+  separate `propose_task` calls when filing a plan** — one request, one
+  compact `{id,title}` array back. Each task spec needs `title` +
+  `effort`; intra-batch dependencies work by giving a task a `ref` and
+  listing that ref in a sibling's `dependsOn` (refs are rewritten to
+  real ids after minting). A validation error fails the whole batch
+  before writing; once valid, per-row RPC failures are reported in
+  `tasks[].error` without sinking the rest.
 - `propose_capability` — create a new capability under an **existing**
   theme. Required: `name`, `pillarId`. Sensible defaults are applied
   (`reach: 100`, `impact: 1`, `confidence: 70`). Pass `outcome` and
   `specRef` whenever you have them — capabilities without an outcome
   rarely survive review. Pass `idempotencyKey`.
-- `propose_theme` — create a new theme. **Use sparingly.** Themes are
-  years-stable strategic categories; almost every plan fits under an
-  existing one. Only call this when the human explicitly asks for a
-  new theme or when the work genuinely doesn't fit any of the existing
-  ones from `list_themes`. Default rule: if you're tempted to create
-  a theme, file a capability under the closest existing theme instead
-  and let the human reorganize later.
+- `propose_theme` — create a new theme. **Theme-autonomy is ON by
+  default**, so you MAY create a theme without human confirmation when
+  the work genuinely needs a new years-stable pillar. You don't police
+  sprawl by asking a human every time — the server does it for you:
+  `propose_theme` returns `error: "too_similar"` (naming the match) if
+  your theme overlaps an existing one above the block bar, so you reuse
+  or `update_theme` that one instead. Still prefer the deepest existing
+  parent (new task > new capability > new theme); a theme is the rare
+  case. If a workspace turned autonomy OFF (Settings → Agent
+  automation), `propose_theme` returns `error: "confirmation_required"`
+  until you surface the new theme to the user and retry with
+  `confirm: true`. Use `force: true` only to override a `too_similar`
+  block that's a genuine false positive. Run `detect_theme_sprawl`
+  periodically to catch themes that have drifted into overlap.
+- `submit_acceptance_grades` — stamp `{ status: pass | fail, note? }`
+  per criterion index, after you've actually verified the work. The
+  server stamps `gradedAt` and `gradedBy: "mcp:agent"`.
 - `submit_acceptance_grades` — stamp `{ status: pass | fail, note? }`
   per criterion index, after you've actually verified the work. The
   server stamps `gradedAt` and `gradedBy: "mcp:agent"`.
@@ -223,6 +249,45 @@ disagrees with the cwd snapshot are refused — set
 `ROADMAPPER_ALLOW_CROSS_WORKSPACE=1` in the env to override.
 Reads can target any workspace freely.
 
+**Repo-link gate (write path).** If you're in a git repo that
+isn't mapped to a workspace, a mutator would silently land on the
+install's env-default workspace — almost never what you want. So
+the first such write is **refused** with a structured error:
+
+```json
+{
+  "error": "repo_unmapped",
+  "message": "\"owner/name\" isn't mapped to a workspace ...",
+  "fix": "link_repo()",
+  "alt": "<tool>({ workspaceId: \"<target>\", ... })"
+}
+```
+
+Resolve it one of two ways, then retry:
+- **`link_repo()`** — maps the repo you're in to your key's
+  workspace, so every future session resolves silently. This is
+  the right move when the repo *should* feed this workspace.
+- **Pass `workspaceId` explicitly** on the call — proceeds without
+  mapping the repo. This is the escape hatch when you're working
+  across **several repos in one session** and just want this write
+  to land on a specific existing workspace.
+
+The gate is repo-aware and only fires for a genuinely unmapped
+repo: an explicit `workspaceId`, an already-mapped repo (resolves
+via `repo_workspace_map`), or not being in a git repo at all
+pass straight through — a multi-repo chat is never bricked.
+Operators can disable the gate entirely with
+`ROADMAPPER_ALLOW_UNMAPPED_REPO=1`.
+
+This gate and the **seed-workspace guard** below are complementary,
+not redundant: the repo-link gate covers the *in a git repo but
+unmapped* case (and gives the more actionable `link_repo` fix),
+while the seed-workspace guard still catches a write that fell
+through to the bundled `"default"` workspace when you're **not** in
+any repo (nothing to link). A write can be refused by at most one of
+them; both protect the same env-default footgun from different
+angles.
+
 Authoring discipline:
 - Read first (`list_themes`, `list_capabilities`, `list_tasks`) before
   proposing anything, so you don't invent a new theme/capability that
@@ -402,12 +467,17 @@ Before writing anything:
    - **Top score 0.2–0.4**: weak overlap. The top match is still
      usually the right home; re-using a "close-enough" theme is
      almost always better than creating a duplicate.
-   - **Empty matches or top < 0.2**: no existing theme fits. Stop
-     and ask the user explicitly whether this represents a new
-     strategic direction worth a years-stable theme. Only call
-     `propose_theme` after the user confirms — themes are
-     years-stable, not per-feature.
-   The propose_theme tool enforces this discovery: skipping
+   - **Empty matches or top < 0.2**: no existing theme fits. With
+     theme-autonomy ON (the default), you may call `propose_theme`
+     directly when this is a genuinely new years-stable pillar — you
+     don't need to stop and ask. The server is the sprawl guard: it
+     refuses a near-duplicate (`error: "too_similar"`), so a theme that
+     gets created is one that doesn't already exist. With autonomy OFF,
+     `propose_theme` returns `error: "confirmation_required"` — surface
+     the theme to the user and retry with `confirm: true`. Either way,
+     prefer a capability under the closest theme when one is even
+     plausibly a fit; a new theme is the rare case.
+   The propose_theme tool enforces discovery: skipping
    `suggest_theme_for` (or `list_themes` / `get_roadmap_snapshot`)
    returns a `discovery_missing` error.
 2. **Decompose into Capabilities.** A Capability is "a quarterly
@@ -427,9 +497,18 @@ Before writing anything:
 
 ### What to emit (template)
 
-Return a single JSON block. The user will paste it into Roadmapper's
-import or read it manually; either way the field names must match
-exactly. IDs use the `__NEW__` placeholder prefix when you're
+**If the write tools are live (you can call `propose_capability` /
+`propose_tasks`), FILE DIRECTLY — do not also emit this JSON block.**
+Dumping the full plan as JSON *and* filing it via tools pays for the
+plan twice in tokens, and the tools are the canonical path anyway. Use
+`propose_capability` for the bet, then ONE `propose_tasks` call for all
+its tasks (not N `propose_task` calls), and report back a short summary
+with the returned ids — not the whole record set. The JSON block below
+is only for the **no-write-tools** case (seed/live-read tier), where
+the user pastes it into Roadmapper's import manually.
+
+When you do emit it: return a single JSON block. The field names must
+match exactly. IDs use the `__NEW__` placeholder prefix when you're
 proposing a new record — Roadmapper assigns the real `TH-NNNNNN` /
 `CAP-NNN` / `TK-NNNNNN` ID at import time.
 

package/README.md

@@ -134,6 +134,13 @@ the check with `ROADMAPPER_DISABLE_UPDATE_CHECK=1`.
 
 ### Recent changes
 
+- **0.9.3** — new `link_repo` tool: when `get_active_workspace` reports
+  `env_default`/`unresolved` and you're in a git repo, one call persists
+  the repo → workspace mapping so future sessions resolve silently (the
+  repo slug is derived server-side; your API key pins the workspace).
+- **0.9.2** — `get_active_workspace` returns an explicit status envelope
+  (`resolved` / `ambiguous` / `env_default` / `unresolved`) with a `next`
+  action, instead of prose; surfaces multi-repo ambiguity.
 - **0.9.1** — the server now self-reports its real version (was a stale
   hardcoded string in `serverInfo` and audit logs) and warns at boot
   when a newer package is published.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@roadmapperai/mcp",
-  "version": "0.9.1",
+  "version": "0.9.4",
   "description": "Roadmapper AI MCP server — exposes a planning surface (themes, capabilities, tasks, sprints, PRs) to coding agents via stdio JSON-RPC. Pairs with the Roadmapper AI workspace at dashboard.roadmapperai.com.",
   "keywords": [
     "mcp",