@massa-ai/cursor-plugin 1.23.0 → 1.24.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,5 +1,5 @@
1
1
  {
2
2
  "name": "massa-ai",
3
- "version": "1.23.0",
3
+ "version": "1.24.0",
4
4
  "description": "massa-ai — semantic code search, memory, and context compression for Cursor"
5
5
  }
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@massa-ai/cursor-plugin",
3
- "version": "1.23.0",
3
+ "version": "1.24.0",
4
4
  "description": "massa-ai plugin for Cursor — semantic code search, memory, and context compression",
5
5
  "files": [
6
6
  "agents",
@@ -19,6 +19,32 @@ The main agent is the orchestrator. It owns:
19
19
 
20
20
  Subagents do bounded work only. Do not delegate everything.
21
21
 
22
+ ## Orchestrator Working Memory
23
+
24
+ Tokens are spent once; context shapes every decision that follows. The orchestrator's
25
+ working memory is the asset every rule below protects — delegation exists to keep
26
+ disposable reasoning out of the main thread, not only to parallelize.
27
+
28
+ - **Never poll a running subagent for status, and never ingest a subagent's raw
29
+ transcript, JSONL, or intermediate reasoning — running or completed.** The
30
+ orchestrator consumes only the subagent's returned output contract (its completion
31
+ result). When lifecycle visibility helps the user, report the dispatch itself via
32
+ conversation-feedback labels, not by fetching agent state.
33
+ - **Wave cap: dispatch at most 4 concurrent subagents.** Before planning 5 or more,
34
+ run and record a consolidation check — can any two planned agents be merged? — then
35
+ dispatch in waves of at most 4. Fixed protocols smaller than the cap (e.g. a
36
+ 3-judge panel) are unaffected.
37
+ - **Cognitive locality:** overlapping file/module ownership or a shared knowledge
38
+ domain between planned subagents — read-only agents included — is a consolidation signal:
39
+ consolidate into one agent before spawning. Two agents independently reconstructing
40
+ the same mental model is waste; one agent holding it once is the cheaper and more
41
+ coherent shape.
42
+ - **Git safety for concurrent work:** no repository-wide git operations (`git stash`,
43
+ `git checkout`/`git switch` of shared state, `git reset`, `git clean`) inside any
44
+ concurrently-dispatched subagent's scope. Concurrent writers require disjoint git
45
+ worktrees. The Verifier's scratch-worktree discrimination sensor keeps its own
46
+ stricter isolation rules.
47
+
22
48
  ## Delegation Gates
23
49
 
24
50
  Delegate only when all base requirements are true and at least one dispatch trigger is true.
@@ -107,19 +133,27 @@ only, never a dispatch target.
107
133
 
108
134
  ## Capability Packet
109
135
 
136
+ **This section is the sole canonical Capability Packet definition.** `references/subagent-design.md` and the root `skills/AGENTS.md` registry defer to or mirror this list; `scripts/__tests__/capability-packet-parity.test.ts` fails when the `skills/AGENTS.md` mirror diverges. Bespoke packets (judge panel, FURPS analyst, phase-batch worker) are declared specializations that map onto these fields in their own workflow files.
137
+
138
+ **A subagent inherits nothing from the parent session** — no skills, no personas, no loaded references, no conversation history. Everything the subagent needs is named explicitly in the packet, including the exact reference file paths it must read itself.
139
+
110
140
  When dispatching a subagent, send a compact capability packet rather than a loose instruction. Include:
111
141
 
112
- - role and purpose for this workflow
113
- - trigger: why delegation is justified now
114
- - exact scope: files, modules, diff, report finding, task IDs, or artifact
115
- - permissions: read-only or write with disjoint ownership
116
- - inputs: recalled facts, source pointers, constraints, and exclusions
117
- - sensors: expected commands or concrete checks
118
- - output: the exact output contract
119
- - firewall: raw logs, diffs, snapshots, reports, or research that must be summarized
120
- - memory boundary: whether the subagent may suggest memories and who persists them
142
+ - `role`: the role name from the Agent Table of `skills/AGENTS.md`
143
+ - `purpose`: one sentence tied to this workflow
144
+ - `trigger`: why delegation is justified now
145
+ - `scope`: exact files, modules, diff, report finding, task IDs, or artifact
146
+ - `permissions`: read-only or write with disjoint ownership
147
+ - `inputs`: recalled facts, source pointers, constraints, and exclusions
148
+ - `sensors`: expected commands or concrete checks
149
+ - `output`: the exact output contract
150
+ - `firewall`: raw logs, diffs, snapshots, reports, or research that must be summarized
151
+ - `memory`: whether the subagent may suggest memories and who persists them
121
152
  - `persona`: optional. The cataloged persona id in effect for the parent conversation, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions. Pass the id alone, never the persona prompt.
122
- - exact next step: what the main agent should do with the result
153
+ - `next_use`: what the main agent will do with the result
154
+ - `lens`: conditional — `audit-specialist` dispatches only. One of `bugs | architecture | security | requirements | code-quality | performance`.
155
+
156
+ The named dispatch block that workflows embed (the quoted block whose header carries the prefixed agent name and role) is the block projection of this packet: `role` and `purpose` live in the block's header line, and `next_use` defaults to "the main agent synthesizes and continues the workflow" when absent. The remaining eight fields — `trigger, scope, permissions, inputs, sensors, output, firewall, memory` — appear as the block's body lines. The optional `persona` field appears there too.
123
157
 
124
158
  ## Prompt Contract
125
159
 
@@ -154,6 +188,11 @@ Subagents must summarize verbose research, logs, snapshots, diffs, search output
154
188
  and transcripts. The main agent should receive only evidence, findings, risk,
155
189
  skipped checks, memory suggestions when allowed, and the next step, not raw dumps.
156
190
 
191
+ **Default return bound: at most 40 lines of returned chat text.** A dispatch block's
192
+ `output:` field may override the bound with a stated reason. When a dispatch writes a
193
+ persisted report file, the chat return is the compact verdict only — never the file
194
+ body (dual-channel rule).
195
+
157
196
  ## Conversation Feedback
158
197
 
159
198
  Use `references/conversation-feedback.md` when subagent lifecycle visibility would help the user understand what is running. Keep status updates to 1-2 human-readable lines.
@@ -222,6 +261,8 @@ For delegated tasks that expect repeated searches:
222
261
 
223
262
  ## Guardrails
224
263
 
264
+ - No polling, no transcripts: never poll a running subagent and never ingest its
265
+ transcript or intermediate reasoning — see Orchestrator Working Memory.
225
266
  - No self-evaluation: claims need deterministic sensors or concrete source evidence.
226
267
  - No hidden scope expansion: subagents must not improve adjacent code.
227
268
  - No context dragging: send only task-specific source pointers and constraints, and receive compact summaries only.
@@ -29,6 +29,7 @@ Apply the firewall before bringing any of these raw artifacts into the main cont
29
29
  - Source, docs, logs, CSV, or reports over 200 lines or 20 KB.
30
30
  - Search, grep, MCP, or external research output over 50 hits.
31
31
  - Generated audit reports, screenshots, browser snapshots, crash/device logs, or raw NotebookLM/web research dumps.
32
+ - Running or completed subagent transcripts, JSONL session files, and intermediate agent reasoning — these never enter the main context at all; consume only the returned output contract.
32
33
  - Any subagent output, tool transcript, or diff where only counts, paths, representative snippets, or failing cases are needed for the next decision.
33
34
 
34
35
  ## Tool Output Discipline
@@ -53,7 +54,7 @@ The main agent receives only:
53
54
  - risks and skipped checks
54
55
  - exact next step
55
56
 
56
- Subagents should not return raw dumps. The main agent still owns memory recall, persistence, synthesis, and the final Evidence Gate.
57
+ Subagents should not return raw dumps. Never poll a running subagent for status and never read a subagent transcript — the returned output contract is the only channel back into the main context (canonical rules: `references/agent-orchestration.md`, Orchestrator Working Memory). The main agent still owns memory recall, persistence, synthesis, and the final Evidence Gate.
57
58
 
58
59
  ## Persistence Boundary
59
60
 
@@ -55,6 +55,16 @@ Batches run strictly sequentially: a batch never starts until the previous batch
55
55
  - `references/spec-driven/coding-principles.md`
56
56
  - Relevant `spec.md`, `context.md`, and `design.md` sections for the feature (not all specs)
57
57
 
58
+ This worker payload is a specialization of the canonical Capability Packet in
59
+ `references/agent-orchestration.md`: the task definitions and spec/design sections are
60
+ its `scope` + `inputs`, the Gate Check Commands are its `sensors`, the structured
61
+ return contract below is its `output`, and write permission is scoped to the batch's
62
+ disjoint task files. Workers inherit nothing from the parent session — every needed
63
+ reference is listed above by path. Inside a worker, repository-wide git operations
64
+ (`git stash`, shared-state `git checkout`/`switch`, `git reset`, `git clean`) are
65
+ prohibited; the only git surface a worker touches is the defined task cycle's atomic
66
+ commits in the feature worktree.
67
+
58
68
  **What a batch worker does:**
59
69
 
60
70
  Executes ALL tasks in its assigned batch **in order** — finishing every task in one phase before starting the next phase in the batch — following the `references/spec-driven/execute.md` cycle for each task (implement → gate → atomic commit). It does NOT spawn further sub-agents. After completing all tasks in the batch, the worker reports a **compact summary** to the orchestrator using the structured return contract:
@@ -76,6 +86,12 @@ No raw logs, no full test output — only the above fields keep the main context
76
86
 
77
87
  **No nesting:** Batch workers execute their tasks themselves. They never spawn sub-sub-agents. Execution is strictly sequential within and across batches — there is no intra-phase or intra-batch parallelism.
78
88
 
89
+ **Orchestrator context discipline:** the orchestrator consumes only the compact
90
+ summary above. It must never read a worker's transcript, JSONL, or intermediate
91
+ reasoning, and must never poll a running worker for status — the summary at batch
92
+ completion is the only channel back (see `references/agent-orchestration.md`,
93
+ Orchestrator Working Memory).
94
+
79
95
  ## Delegation Activity Table
80
96
 
81
97
  The batching trigger above governs **when** batch workers are offered. This table governs **what** may be delegated at all. Delegation is activity-scoped, not blanket.
@@ -118,6 +134,12 @@ Delegated work returns through the compact summary contract above. Planning, tas
118
134
  - The test files in scope
119
135
  - `references/spec-driven/validate.md` as its operating checklist
120
136
 
137
+ This payload is a specialization of the canonical Capability Packet
138
+ (`references/agent-orchestration.md`): spec + diff + tests are its `scope`/`inputs`,
139
+ `validate.md` is its `sensors` source, the compact verdict + `validation.md` report
140
+ below are its dual-channel `output`, and `permissions` are read-only outside the
141
+ scratch sensor state.
142
+
121
143
  **What the Verifier does (full process in `validate.md`):**
122
144
 
123
145
  1. **Spec-anchored coverage check** — re-derives coverage evidence-or-zero: every AC traced to `file:line` + assertion expression. For each covered criterion, confirms the test's asserted value matches the **spec-defined expected outcome** (not just that an assertion exists). Where the spec does not define a precise outcome, flags a **spec-precision gap** rather than passing silently.
@@ -91,19 +91,24 @@ Memory boundary:
91
91
 
92
92
  ## Capability Packet
93
93
 
94
- When a workflow dispatches a reusable role, send a capability packet rather than a loose instruction. The packet should include:
95
-
96
- - `role`: the role name from `agent-orchestration.md`
97
- - `purpose`: one sentence tied to this workflow
98
- - `trigger`: why delegation is justified now
99
- - `scope`: exact files, modules, diff, report finding, or task IDs
100
- - `permissions`: read-only or write with disjoint write set
101
- - `inputs`: recalled facts, source pointers, task/report IDs, constraints, and exclusions
102
- - `sensors`: commands or concrete checks expected
103
- - `output`: the exact output contract
104
- - `firewall`: raw logs, diffs, snapshots, or research that must be summarized
105
- - `memory`: whether the subagent may suggest memory and who persists it
106
- - `persona`: optional. The cataloged persona id in effect for the parent conversation, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions. Pass the id alone, never the persona prompt.
94
+ **The packet field list lives in one place: `references/agent-orchestration.md`,
95
+ §Capability Packet.** Do not restate it here — a second copy is what let the field
96
+ sets drift into three diverging shapes before the canonical section existed. When a
97
+ workflow dispatches a reusable role, send that canonical packet rather than a loose
98
+ instruction.
99
+
100
+ The one field this reference still names on its own is `persona`, because a
101
+ persona-agent-boundary guard (`.specs/features/persona-agent-boundary/spec.md`)
102
+ checks its clause byte-for-byte in every packet-defining file, this one included:
103
+
104
+ `persona`: optional. The cataloged persona id in effect for the parent conversation, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions. Pass the id alone, never the persona prompt.
105
+
106
+ Design-time additions this reference owns: a new role's charter must be expressible
107
+ as that packet (if a role needs fields the canonical list cannot carry, the role is
108
+ mis-scoped — split it or fix the charter, do not grow a bespoke packet silently), and
109
+ any deliberate bespoke specialization (judge panel, FURPS analyst, phase-batch
110
+ worker) must declare itself a specialization in its own workflow file and map its
111
+ fields onto the canonical ones from `agent-orchestration.md`.
107
112
 
108
113
  ## Quality Checklist
109
114
 
@@ -63,6 +63,21 @@ the capability, per-slot diversity activates automatically with no harness edit.
63
63
  Dispatch `massa-ai-meta-judge` (read-only) with the task description, artifact type, context,
64
64
  and artifact paths. Model request: `kimi-k3` (see Step 0.5).
65
65
 
66
+ > **Dispatch: `massa-ai-meta-judge`** (role: `meta-judge`) — charter `skills/agents/meta-judge/SKILL.md`
67
+ > - trigger: judge-with-debate Step 1; runs exactly once per evaluation
68
+ > - scope: the artifact under evaluation (paths supplied), task description, artifact type
69
+ > - permissions: read-only
70
+ > - inputs: task description, artifact type, context, artifact paths, model request per Step 0.5; inherits nothing — every needed path is named here
71
+ > - sensors: two-stage validation below (syntactic YAML, weights sum 1.0 ± 0.001, semantic shape)
72
+ > - output: the evaluation-specification YAML, returned verbatim for all rounds; nothing else
73
+ > - firewall: no artifact body quotes beyond what the rubric anchors need; no raw dumps
74
+ > - memory: suggest-only; main agent persists
75
+ > - persona: optional — the active route's cataloged id only, never the persona prompt, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions; omit when no persona is routed
76
+
77
+ This packet is a specialization of the canonical Capability Packet
78
+ (`references/agent-orchestration.md`): the spec YAML is its `output` contract; the
79
+ two-stage validation is its `sensors`.
80
+
66
81
  Validate the returned evaluation specification in two stages, in order; a retry names the
67
82
  **first failed check** and nothing else:
68
83
 
@@ -83,8 +98,24 @@ then `🤖 [Agent Done]` or `🤖 [Agent Blocked]` with the one-line reason.
83
98
 
84
99
  Dispatch three `massa-ai-judge` agents **in parallel** (round 0), one per judge number, each
85
100
  with: the verbatim specification YAML, task description, artifact paths, its own report path,
86
- `round: 0`, and its model request (Step 0.5). Each judge writes its own
87
- `audits/judge/<...> judge-N.md` per the report contract and returns the reply block:
101
+ `round: 0`, and its model request (Step 0.5). The fixed panel of 3 sits inside the wave cap of
102
+ 4 concurrent subagents (`references/agent-orchestration.md`, Orchestrator Working Memory).
103
+ Each judge writes its own `audits/judge/<...> judge-N.md` per the report contract and returns
104
+ the reply block:
105
+
106
+ > **Dispatch: `massa-ai-judge`** (role: `judge`) — charter `skills/agents/judge/SKILL.md` — 3 per panel, rounds 0..3
107
+ > - trigger: judge-with-debate Steps 2 and 4; panel of exactly 3, never more
108
+ > - scope: the artifact under evaluation, the verbatim specification YAML, own report path; debate rounds add all three report paths as peer paths and `round: R`
109
+ > - permissions: read-only except appending to its own judge-N report file
110
+ > - inputs: verbatim spec YAML, task description, artifact paths, own report path, round number, model request; debate rounds add peer report paths; inherits nothing — judges read peer reports from the filesystem paths supplied
111
+ > - sensors: reply-block shape below (malformed or missing `scores` counts as `contest`; same judge malformed twice → Blocked)
112
+ > - output: the YAML reply block below (strengths/weaknesses capped at ≤3 items); report file is the persisted channel — dual-channel rule, the chat return never carries the report body
113
+ > - firewall: quoted evidence snippets only; no artifact or peer-report dumps in the reply
114
+ > - memory: suggest-only; main agent persists
115
+ > - persona: optional — the active route's cataloged id only, never the persona prompt, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions; omit when no persona is routed
116
+
117
+ This packet is a specialization of the canonical Capability Packet
118
+ (`references/agent-orchestration.md`); the per-round additions are its `inputs` deltas.
88
119
 
89
120
  ```yaml
90
121
  status: Complete | Partial | Blocked
@@ -33,7 +33,20 @@ This workflow is findings-only. Do not edit the PRD/ADR unless the user separate
33
33
  - Dispatch six `massa-ai-furps-analyst` sub-agents: F, U, R, P, S, X (X = FURPS+ Extensions).
34
34
  - Each receives its `checklist.md` section, the bounded document packet, the DoR, and the Fool summary.
35
35
  - Each returns per check-item status (`covered|partial|missing|unclear`), `FR-<letter>-<N>` findings, and contributions to Open Questions / Suggestions / Insights / Risks / DoR-gaps.
36
- - Run in parallel; batch if a concurrency cap applies. Each gets its own ephemeral Synapse session only if it performs >=2 searches.
36
+ - Dispatch the six dimensions in waves of at most 4 concurrent analysts (e.g. 4 then 2), per the wave cap in `references/agent-orchestration.md` (Orchestrator Working Memory). Dimension analyses are order-independent, so wave order does not matter. Each gets its own ephemeral Synapse session only if it performs >=2 searches.
37
+
38
+ > **Dispatch: `massa-ai-furps-analyst`** (role: `furps-analyst`) — charter `skills/agents/furps-analyst/SKILL.md` — 6 dispatches, one per dimension, waves of ≤4
39
+ > - trigger: furps-refinement step 5; one analyst per FURPS+ dimension (F, U, R, P, S, X)
40
+ > - scope: exactly one dimension's `checklist.md` section against the bounded document packet
41
+ > - permissions: read-only
42
+ > - inputs: the dimension's checklist section, bounded document packet, DoR, Fool summary; inherits nothing — the packet names every artifact
43
+ > - sensors: per check-item status must be one of `covered|partial|missing|unclear`; findings carry `FR-<letter>-<N>` IDs
44
+ > - output: per check-item statuses, findings, and Open Questions / Suggestions / Insights / Risks / DoR-gap contributions — compact structured return, no document quotes beyond evidence snippets
45
+ > - firewall: document bodies summarized; no raw section dumps in the return
46
+ > - memory: suggest-only; main agent persists
47
+ > - persona: optional — the active route's cataloged id only, never the persona prompt, passed as advisory framing only — it never overrides the agent's charter Restrictions, scope, or permissions; omit when no persona is routed
48
+
49
+ This packet is a specialization of the canonical Capability Packet (`references/agent-orchestration.md`); the per-dimension checklist section is its `scope` delta.
37
50
  6. Synthesis (main):
38
51
  - Collect the six dimension analyses and the Fool summary.
39
52
  - Deduplicate, cross-check, and reconcile cross-dimension concerns (e.g., error flows span F3+R2+U1; components span F2+S2).
@@ -55,7 +68,7 @@ This workflow is findings-only. Do not edit the PRD/ADR unless the user separate
55
68
  | Sub-agent spawning unavailable | Run dimensions sequentially in the main agent; record the skipped-delegation reason |
56
69
  | DoR not supplied | Use the built-in fallback; mark DoR-gaps explicitly |
57
70
  | Document too large | context-firewall: section summaries plus pointers to sub-agents |
58
- | Concurrency cap on six FURPS agents | Batch dispatch; preserve order-independence |
71
+ | Host concurrency cap tighter than the wave cap of 4 | Smaller waves; preserve order-independence |
59
72
 
60
73
  ## Examples
61
74