@massa-ai/cursor-plugin 1.14.0 → 1.15.0

package/.cursor-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "massa-ai",
-  "version": "1.14.0",
+  "version": "1.15.0",
   "description": "massa-ai — semantic code search, memory, and context compression for Cursor"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@massa-ai/cursor-plugin",
-  "version": "1.14.0",
+  "version": "1.15.0",
   "description": "massa-ai plugin for Cursor — semantic code search, memory, and context compression",
   "files": [
     "agents",

package/skills/massa-ai/references/agent-orchestration.md

@@ -79,25 +79,31 @@ dispatch.
 
 Before adding a new reusable role, load `references/subagent-design.md` and write a bounded role charter. For one-off tasks, use an existing role plus the prompt contract below instead of inventing a new role.
 
-| Role | Host agent name | Use For | Read/Write | Charter |
-|---|---|---|---|---|
-| `investigator` | `massa-ai-investigator` | Trace code paths, find entry points, summarize current behavior | read-only | `skills/agents/investigator/SKILL.md` |
-| `navigator` | `massa-ai-navigator` | Answer "where is X / who calls Y" from the massa-ai index before reading files | read-only | `skills/agents/navigator/SKILL.md` |
-| `implementer` → `builder` | `massa-ai-builder` | Execute one atomic task with a disjoint write set | write | `skills/agents/builder/SKILL.md` |
-| `verifier` → `verification-agent` | `massa-ai-verification-agent` | Independently run sensors and inspect whether claims hold | read-only | `skills/agents/verification-agent/SKILL.md` |
-| `domain-mapper` → `architecture-specialist` | `massa-ai-architecture-specialist` | Identify subdomains, bounded contexts, language conflicts, cohesion | read-only | `skills/agents/architecture-specialist/SKILL.md` (lens: `domain`) |
-| `coupling-auditor` → `architecture-specialist` | `massa-ai-architecture-specialist` | Analyze strength, distance, volatility, and risky dependencies | read-only | `skills/agents/architecture-specialist/SKILL.md` (lens: `coupling`) |
-| `deepening-architect` → `architecture-specialist` | `massa-ai-architecture-specialist` | Find shallow modules and deepening opportunities | read-only | `skills/agents/architecture-specialist/SKILL.md` (lens: `deepening`) |
-| `audit-specialist` | `massa-ai-audit-specialist` | Findings-only audit through one selected `lens` | read-only | `skills/agents/audit-specialist/SKILL.md` |
-| `plan-critic` | `massa-ai-plan-critic` | Stress-test a constructed plan using The Fool mode and return bounded critique | read-only | `skills/agents/plan-critic/SKILL.md` |
-| `furps-analyst` | `massa-ai-furps-analyst` | Analyze one FURPS+ dimension of a PRD/ADR against the checklist and return structured findings | read-only | `skills/agents/furps-analyst/SKILL.md` |
-
-The remaining charters — `planner`, `reviewer`, `context-curator`,
-`requirements-analyst`, `test-engineer`, `documentation-agent`,
-`mobile-specialist` — follow the same `massa-ai-<role>` convention and are
-listed in the Agent Table of `skills/AGENTS.md`.
-
-**Role mapping:** `investigator`→`investigator` (identical); `implementer`→`builder` (renamed); `verifier`→`verification-agent` (renamed, centralizes Verification Ladder); `domain-mapper`+`coupling-auditor`+`deepening-architect`→`architecture-specialist` (three roles folded into one specialist; the `lens` input field selects the sub-mode). Workflows dispatch the new agent names via named dispatch blocks; the old role names above are kept for traceability only.
+## Roles
+
+**The roster lives in one place: the Agent Table of `skills/AGENTS.md`**, which names
+every shipped specialist with its purpose, trigger, permission, and charter path. Do not
+restate it here. A second roster in this file is what let `judge` and `meta-judge` go
+undocumented for a whole release with every gate green — the guard checked that the
+charter paths *mentioned* here resolve, which a charter that is never mentioned cannot
+fail.
+
+This file owns dispatch mechanics. The one roster fact it owns is the **legacy role
+vocabulary**: names earlier workflows dispatched by, kept so an old reference still
+resolves to a current agent.
+
+| Legacy role | Current agent | Note |
+|---|---|---|
+| `implementer` | `massa-ai-builder` | renamed |
+| `verifier` | `massa-ai-verification-agent` | renamed; also centralizes the Verification Ladder |
+| `domain-mapper` | `massa-ai-architecture-specialist` | folded in; `lens: domain` |
+| `coupling-auditor` | `massa-ai-architecture-specialist` | folded in; `lens: coupling` |
+| `deepening-architect` | `massa-ai-architecture-specialist` | folded in; `lens: deepening` |
+
+`investigator`, `plan-critic` and `furps-analyst` kept their own names; every other
+specialist is new and never had a legacy one. Workflows dispatch the current
+`massa-ai-<role>` name through a named dispatch block — the legacy column is traceability
+only, never a dispatch target.
 
 ## Capability Packet
 

package/skills/massa-ai/references/maestro/fact-ledger.md

@@ -7,7 +7,7 @@ Use this before making Maestro claims. It defines source authority, fact tags, l
 1. `official-doc`: current official Maestro documentation, preferably `.md` pages under `https://docs.maestro.dev/`.
 2. `live-help`: successful local CLI transcript from the installed Maestro binary, including command, exit code, stdout, and stderr.
 3. `repo-convention`: current repository flows, config, CI, scripts, report paths, and existing naming/tag patterns.
-4. `excluded/unverified`: NotebookLM answers, `/Users/luizmassa/Downloads/questions.md`, blog posts, memory, or assumptions that are not confirmed by the first three sources.
+4. `excluded/unverified`: NotebookLM answers, a user-supplied coverage checklist, blog posts, memory, or assumptions that are not confirmed by the first three sources.
 
 If sources conflict, prefer `official-doc` for product behavior and `live-help` for installed CLI syntax. Mention version drift when `live-help` differs from docs.
 
@@ -39,7 +39,7 @@ If PATH cannot resolve `maestro`, mark local CLI validation blocked. If the bina
 
 ## Coverage Checklist Handling
 
-Use `/Users/luizmassa/Downloads/questions.md` as a checklist to ask "did we cover this surface?" Never cite it as source truth.
+When the user supplies a coverage checklist, use it to ask "did we cover this surface?" Never cite it as source truth, and never assume one exists — if the user supplied none, this section imposes no requirement.
 
 Checklist-only facts that must stay non-normative unless independently verified:
 

package/skills/massa-ai/references/maestro.md

@@ -6,7 +6,7 @@ Use this small index from `workflows/maestro/maestro.md`, `workflows/maestro/mae
 
 Load `references/maestro/fact-ledger.md` before making any normative Maestro claim. Every Maestro claim must be tagged as `official-doc`, `live-help`, `repo-convention`, or `excluded/unverified`.
 
-Use `/Users/luizmassa/Downloads/questions.md` only as a coverage checklist. If a checklist item is not supported by official Maestro docs, live CLI help, or repository convention, quarantine it as `excluded/unverified`.
+Use a user-supplied coverage checklist, when the user provides one, only as a coverage checklist. If a checklist item is not supported by official Maestro docs, live CLI help, or repository convention, quarantine it as `excluded/unverified`.
 
 Official source anchors: