@massa-ai/cursor-plugin 1.43.0 → 1.45.0

package/.cursor-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "massa-ai",
-  "version": "1.43.0",
+  "version": "1.45.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.43.0",
+  "version": "1.45.0",
   "description": "massa-ai plugin for Cursor — semantic code search, memory, and context compression",
   "files": [
     "agents",

package/skills/massa-ai/references/implementation-delivery.md

@@ -20,6 +20,7 @@ human chose to merge it".
 | --- | --- | --- | --- |
 | 0 | Preflight | `git rev-parse --is-inside-work-tree`; `command -v gh`; `gh auth status` | Record which capabilities are absent and select the degraded path below |
 | 1 | Isolate | `git fetch origin <base> && git worktree add -b <type>/<slug> <path> origin/<base>` | Branch name taken → suffix `-2`. Worktree path taken → reuse it only if its branch matches |
+| 1.5 | Summarize | present the pre-implementation change summary (see Stage 1.5) | Summary skipped → stop and present it before the first mutation; a mutation made without it is a protocol violation to report, not to hide |
 | 2 | Implement | one task → gate → `git commit` | Gate red → fix before committing. Never commit through a failing gate |
 | 3 | Push | `git push -u origin <type>/<slug>` | Rejected non-fast-forward → `git fetch` + rebase, never force-push a shared branch |
 | 3.5 | Deliver specs | `bun skills/massa-ai/scripts/check_specs_delivered.ts <feature> [--root .]` | Non-zero → commit the missing `.specs/` updates (a `docs(specs):`-type commit is normal), push, re-run. Defensive fallback — should not fire when the close-out task already committed `.specs/` before the first push |
@@ -74,6 +75,36 @@ with its own sub-task key — the commit contract is owned by
 `workflows/commit.md`; do not restate it here. Non-phased work keeps the
 `<type>/<slug>` branch shape unchanged.
 
+### Stage 1.5 — summarize before you touch the tree
+
+Before the first implementation mutation, present one compact summary of the
+changes about to be made. Source it from the approved spec/design/tasks
+artifacts when they exist; otherwise from the plan or the conversation's
+logical work items. A single-item summary is valid — this stage applies to
+Quick mode too, not only spec-driven work.
+
+Format: one list, separated by tasks — `- T01`-style items with `--`
+sub-items, each a medium-length phrase, clear, direct, and objective. For
+example:
+
+```md
+- T01
+-- Button will be renamed to XXX
+-- Field YYY will be dropped
+-- Business rule ZZZ will be changed to WWW
+
+- T02
+-- New feature AAA will be implemented
+-- Backend behavior BBB will be implemented
+-- Frontend behavior CCC will be tied to that backend behavior BBB
+```
+
+**Anchor:** the summary is presented together with the feature's
+delivery-authorization ask (Stage 3, obtained before implementation begins) —
+it is not a new standalone gate and never adds a second prompt. Workflows
+with their own pre-implementation pause (e.g. spec-driven's sub-agent offer)
+attach the summary to that pause rather than inventing a separate one.
+
 ### Stage 2 — one commit per task
 
 Commit message content, staging rules, audit-report exclusions, and Jira

package/skills/massa-ai/references/spec-driven/discuss.md

@@ -88,9 +88,9 @@ Shared rules for every pace:
 
 1. Classify upcoming decisions as **independent** vs **dependent**.
 2. Low-stakes / safe-to-default → state the assumption and invite correction (no blocking question).
-3. Independent product decisions → ask **at most 2** in the same turn, each with options + recommended default.
+3. Independent product decisions → ask them together in the same turn — as many as the open decision set requires, each with options + recommended default.
 4. Dependent decisions → ask **exactly one**, wait, then continue (the earlier answer should prune later questions).
-5. Never dump 3+ questions in one turn. Never ask what the code already answers.
+5. Never dump unrelated questions as one bulk form. Never ask what the code already answers.
 6. Stop the area as soon as enough is decided.
 
 **Detailed:** Walk selected gray areas as a strict decision tree — one concrete question per turn, dependency order, wait for each answer before the next. Use when the user wants maximum control or the feature is highly ambiguous.
@@ -196,7 +196,7 @@ Discuss is done when every gray area is either resolved with the user, recorded
 ## Tips
 
 - **Pace is a user choice; Guided is the default** — Quick for speed, Guided for balance, Detailed for Socratic depth; honor mid-discussion switches
-- **Guided ≠ interrogation and ≠ form dump** — Assume-first when safe, ≤2 independent questions per turn, one-at-a-time only when answers depend on each other
+- **Guided ≠ interrogation and ≠ form dump** — no numeric cap on questions; ask as many as the open decisions require. Group independent questions naturally per turn, one-at-a-time only when answers depend on each other. Ask-first for important or uncertain decisions; only genuinely trivial, safe details may be assumed, and every assumption is recorded
 - **Look it up, don't ask** — Resolve anything discoverable from the code yourself; ask only genuine product decisions
 - **Decisions, not vision** — "Card-based layout with subtle shadows" is a decision. "Should feel modern" is not.
 - **Scope is sacred** — Deferred Ideas captures scope creep without losing ideas

package/skills/massa-ai/references/spec-driven/execute.md

@@ -11,7 +11,7 @@ Use for the required Execute phase. Implement ONE task at a time: surgical chang
 - `.specs/features/<slug>/tasks.md` when Tasks was included, otherwise the inline atomic step list from `workflows/spec-driven.md`.
 - Current `.specs/project/STATE.md`.
 - `references/spec-driven/coding-principles.md`.
-- `references/spec-driven/sub-agents.md` when a formal task plan has more than 3 tasks (the batch offer trigger — packing still uses ~7-task batches), or final validation needs the standalone verifier fallback.
+- `references/spec-driven/sub-agents.md` when a formal task plan has more than 3 tasks (the batch offer trigger — packing uses max-3-task batches, ideal 2), or final validation needs the standalone verifier fallback.
 
 Artifact-store evidence: active artifact key, version, and checksum after write (see `references/spec-driven/artifact-store.md`).
 
@@ -31,15 +31,15 @@ Do not proceed without stating these explicitly.
 
 ## Process
 
-**Batch worker context:** When this task is executed as part of a phase-batch sub-agent, the worker receives the task definitions for every phase in its batch, coding principles, the generated Test Coverage Matrix and Gate Check Commands from tasks.md, and relevant spec/design context. A batch is one or more consecutive whole phases packed to ~7 tasks. The worker executes ALL tasks in its assigned batch in order — finishing every task in one phase before starting the next phase in the batch — and each task follows every step below (implement → gate → atomic commit) before moving to the next. After all tasks in the batch are complete, the worker reports a compact summary (tasks done, commit hashes, test counts, deviations/blockers) to the orchestrator. See [sub-agents.md](sub-agents.md) for the full model.
+**Batch worker context:** When this task is executed as part of a phase-batch sub-agent, the worker receives the task definitions for every phase in its batch, coding principles, the generated Test Coverage Matrix and Gate Check Commands from tasks.md, and relevant spec/design context. A batch is one or more consecutive whole phases packed to max 3 tasks (ideal 2). The worker executes ALL tasks in its assigned batch in order — finishing every task in one phase before starting the next phase in the batch — and each task follows every step below (implement → gate → atomic commit) before moving to the next. After all tasks in the batch are complete, the worker reports a compact summary (tasks done, commit hashes, test counts, deviations/blockers) to the orchestrator. See [sub-agents.md](sub-agents.md) for the full model.
 
 ### Before implementing: assess sub-agent delegation (MANDATORY — before the first task)
 
-Before implementing anything, if a formal `.specs/features/<slug>/tasks.md` with an Execution Plan exists, **count its total tasks**. If the feature has **more than 3 tasks**, you MUST present the sub-agent offer to the user and wait for their choice before starting Execute — do not silently proceed inline. Packing itself still uses task-budgeted batches (~7 tasks per worker, whole phases — see [sub-agents.md](sub-agents.md)); a 4–8-task feature packs into a single batch and is still offered as one batch worker. If the feature has 3 or fewer tasks, or the user declines the offer, execute inline. Skip this check only when you are already a batch worker executing a delegated batch (the orchestrator already made the delegation decision).
+Before implementing anything, if a formal `.specs/features/<slug>/tasks.md` with an Execution Plan exists, **count its total tasks**. If the feature has **more than 3 tasks**, you MUST present the sub-agent offer to the user and wait for their choice before starting Execute — do not silently proceed inline. Packing itself still uses task-budgeted batches (max 3 tasks per worker, ideal 2, whole phases — see [sub-agents.md](sub-agents.md)); a triggered feature always packs into at least two workers and the offer is always presented. If any phase in `tasks.md` holds more than 3 tasks, that is a wrongly-sized Tasks artifact — stop and split the phase during Tasks (safety valve) before packing; never assign an over-budget worker. The offer message MUST begin with the pre-implementation change summary required by `references/implementation-delivery.md` Stage 1.5 — one list separated by tasks, derived from the approved spec/design/tasks artifacts — so the user sees what will change before choosing. If the feature has 3 or fewer tasks, or the user declines the offer, execute inline — the Stage 1.5 change summary is still presented before the first mutation, attached to the feature's delivery-authorization ask. Skip this check only when you are already a batch worker executing a delegated batch (the orchestrator already made the delegation decision).
 
 ### 0. List Atomic Steps (MANDATORY when Tasks phase was skipped)
 
-If there is no `tasks.md` for this feature, you MUST list atomic steps before writing any code. This is non-negotiable — it prevents the agent from losing focus and doing too many things at once.
+If there is no `tasks.md` for this feature, you MUST list atomic steps before writing any code. This is non-negotiable — it prevents the agent from losing focus and doing too many things at once. The listed steps double as the Stage 1.5 change summary (`references/implementation-delivery.md`): present them before the first mutation, attached to the delivery-authorization ask.
 
 ```
 ## Execution Plan

package/skills/massa-ai/references/spec-driven/specify.md

@@ -84,6 +84,8 @@ If needed:
 
 **Facts you look up; decisions you ask.** Anything discoverable by reading the environment (the codebase, config, docs, existing conventions) you resolve yourself through the Knowledge Verification Chain — do not spend the user's attention asking for it. Reserve questions for genuine decisions that are the user's to make: scope, priorities, product behavior, trade-offs. A question you could have answered by reading the code erodes trust and wastes a turn.
 
+**No limit on the number of clarifying questions.** Ask as many as the open decisions require — there is no numeric cap. When in doubt, unsure, or facing an important decision, ask rather than assume.
+
 **Challenge vagueness.** Never accept fuzzy answers. "Good" means what? "Users" means who? "Simple" means how? Make the abstract concrete: "Walk me through using this." "What does that actually look like?"
 
 **Know when to stop — then run the dimensions sweep.** When you understand what they're building, why, who it's for, and what done looks like, run a closing **implicit-requirement dimensions sweep** before offering to proceed:
@@ -129,7 +131,7 @@ Before Design, Tasks, or Execute — and before presenting the spec for confirma
 
 3. **Unambiguity + precision (hard).** Every AC must (a) have a single interpretation and (b) define a precise, spec-defined expected outcome. Any AC that fails either check: resolve with the user, split it, or log it as an explicit assumption with the chosen interpretation and rationale. No AC proceeds readable two ways or with an undefined outcome.
 
-4. **Open-questions / assumptions closure.** Each question must be either (a) resolved with the user OR (b) recorded as an **assumption** (chosen default + rationale) in the spec's Assumptions & Open Questions section. If the user accepts a default, record it as an accepted assumption with the affected requirement IDs. Nothing proceeds unmarked.
+4. **Open-questions / assumptions closure.** Each question must be either (a) resolved with the user OR (b) recorded as an **assumption** (chosen default + rationale) in the spec's Assumptions & Open Questions section. If the user accepts a default, record it as an accepted assumption with the affected requirement IDs. Nothing proceeds unmarked. Recording an assumption **without** asking is allowed only for genuinely trivial/safe details or questions the user explicitly deferred; important decisions — behavior, scope, data, security/privacy, compatibility, acceptance — are resolved by asking, never by silent default.
 
 5. **Declined gray areas become assumptions.** Any gray area the user declined to discuss or that went undiscussed is written to the spec's Assumptions & Open Questions section (agent's chosen default + rationale) — never silently dropped. Refused, deferred, or intentionally excluded areas go in the out-of-scope table. See [discuss.md](discuss.md).
 

package/skills/massa-ai/references/spec-driven/sub-agents.md

@@ -11,38 +11,38 @@ Use during Execute when formal task planning has more than 3 tasks, when the use
 
 Conflating the two (one worker per phase) is what fragments execution: a feature's dependency-layer count has nothing to do with the ideal per-worker workload. Batching by task budget separates the two concerns without breaking phases.
 
-**Trigger:** Count total tasks across all phases. If the feature has **more than 3 tasks**, offer the user phase-batch sub-agents before starting Execute — even when packing yields a single batch (a 4–8-task feature is offered as one batch worker). If the feature has 3 or fewer tasks, execute inline in the main window — no sub-agents spawned, no offer made.
+**Trigger:** Count total tasks across all phases. If the feature has **more than 3 tasks**, offer the user phase-batch sub-agents before starting Execute — under the **max 3 tasks per worker, ideal 2** budget, a triggered feature always packs into at least two workers, so the offer is never for a single batch. If the feature has 3 or fewer tasks, execute inline in the main window — no sub-agents spawned, no offer made.
 
-**Batching algorithm (task budget ≈ 7 tasks/worker, phase-aligned):**
+**Batching algorithm (task budget: max 3 tasks per worker, ideal 2, phase-aligned):**
 
-The benchmarked sweet spot is ~7 tasks of context per worker (~20 tasks → 3 workers). Pack whole phases into that budget:
+Pack whole phases into that budget, greedily, in phase order:
 
 1. Count total tasks `T`.
 2. If `T ≤ 3` → inline, no sub-agents, no offer.
-3. Otherwise (even for `T` as low as 4) offer sub-agents and walk phases **in order**, accumulating whole phases into the current batch. When the batch's running task count reaches ~7 **and** phases remain, close the batch and start the next.
+3. Otherwise offer sub-agents and walk phases **in order**, accumulating whole phases into the current batch. When adding the next phase would push the batch's running task count above 3 **and** phases remain, close the batch and start the next with that phase.
 4. **Never split a phase** across workers — the cut only ever lands on a phase boundary. This preserves dependency ordering and keeps a phase's tasks + shared context in one worker.
-5. If the final batch is a lone tail (1–2 tasks), fold it into the previous batch.
+5. A trailing batch under budget is expected and correct — it is not folded into the previous batch when that would push the previous batch over 3.
 
-Result ≈ `ceil(T / 7)` workers, scaling linearly. Unevenness is absorbed by greedy packing — phases never need to divide evenly. Worked examples (20 tasks):
+Result: at least `ceil(T / 3)` workers, ~`T / 2` typical once phases are sized to the ideal of 2. Unevenness is absorbed by greedy packing — phases never need to divide evenly. Example: 20 tasks → roughly 7–10 workers, depending on phase sizes. Worked examples:
 
-- Phases `[3,3,3,3,4,4]` → `{P1+P2=6, P3+P4=6, P5+P6=8}` = **3 workers**
-- Phases `[8,2,2,8]` → `{P1=8, P2+P3=4, P4=8}` = **3 workers** (no even split needed)
-- Phases `[5,5,5,5]` → `{P1+P2=10, P3+P4=10}` = **2 workers** (phases too coarse to hit 3 — see below)
+- Phases `[2,2,3]` → `{P1=2}, {P2=2}, {P3=3}` = **3 workers** (no neighbor has budget room left to combine into)
+- Phases `[3,3,3,3]` → `{P1=3}, {P2=3}, {P3=3}, {P4=3}` = **4 workers** (every phase already sits at the budget)
+- Phases `[1,2,2]` → `{P1+P2=3}, {P3=2}` = **2 workers** (small phases combine up to the budget)
 
-**Coarse-phase caveat:** Because the cut lands only on phase boundaries, very coarse phases limit how finely you can pack. If a single phase alone exceeds ~1.5× the budget (~10+ tasks), that is a Tasks-authoring smell — split it into real sub-phases during Tasks (at a genuine dependency/cohesion boundary), never at dispatch time.
+A phase larger than 3 tasks is a Tasks-authoring defect — split it during Tasks, never at dispatch time.
 
 **Offer-then-confirm (never auto-spawn):**
 
-> "This feature has [T] tasks across [N] phases. I can pack them into [K] sub-agents (~7 tasks each, whole phases per worker) — every worker runs its phases in order, reports a compact summary, and the orchestrator advances to the next batch. This keeps the main window lean without over-fragmenting. Want to proceed that way?"
+> "This feature has [T] tasks across [N] phases. I can pack them into [K] sub-agents (2–3 tasks each, whole phases per worker) — every worker runs its phases in order, reports a compact summary, and the orchestrator advances to the next batch. This keeps the main window lean without over-fragmenting. Want to proceed that way?"
 
-The user must explicitly accept. If they decline (or if the feature fits one batch), execute inline.
+The user must explicitly accept. If they decline, execute inline instead of dispatching sub-agents.
 
 **Execution model — one worker per task-budgeted batch, sequential:**
 
 ```
-Phases 1+2 (7 tasks)  ──→ Batch Worker 1 ──→ compact summary ──→ orchestrator updates tasks.md
-Phases 3+4 (6 tasks)  ──→ Batch Worker 2 ──→ compact summary ──→ orchestrator updates tasks.md
-Phase 5    (7 tasks)  ──→ Batch Worker 3 ──→ compact summary ──→ orchestrator updates tasks.md
+Phase 1 (3 tasks)  ──→ Batch Worker 1 ──→ compact summary ──→ orchestrator updates tasks.md
+Phase 2 (2 tasks)  ──→ Batch Worker 2 ──→ compact summary ──→ orchestrator updates tasks.md
+Phase 3 (3 tasks)  ──→ Batch Worker 3 ──→ compact summary ──→ orchestrator updates tasks.md
 ...
 ```
 
@@ -108,7 +108,7 @@ Delegated work returns through the compact summary contract above. Planning, tas
 
 **The orchestrating agent's role during Execute:**
 
-1. Count total tasks and pack phases into task-budgeted batches (~7 tasks each) — if that yields more than one batch, offer batch sub-agents and wait for the user to accept
+1. Count total tasks and pack phases into task-budgeted batches (max 3 tasks each, ideal 2) — offer batch sub-agents and wait for the user to accept
 2. Dispatch the next batch to a worker (or execute inline if not using sub-agents)
 3. Receive the compact summary
 4. Update `.specs/features/<slug>/tasks.md` with results
@@ -187,9 +187,9 @@ Judge the tier by the work in front of the role, not by the role's title:
 | Design phase | High ambiguity, hard-to-reverse structural decisions | `deep` |
 | Batch worker — core-domain or high-ambiguity phase | Non-obvious logic, tricky edge cases, novel integration | `deep` |
 | Batch worker — mechanical phase | Entities, DTOs, config, wiring, straightforward CRUD against a settled pattern | `light` / `standard` |
-| Verifier | Adversarial reasoning: designs mutations, re-derives coverage, judges outcome precision | `deep` (always — see below) |
+| Verifier | Adversarial reasoning: designs mutations, re-derives coverage, judges outcome precision | `deep` (always — per the Rules of thumb below) |
 | Specify / Tasks authoring | Structured but judgment-heavy | `standard` / `deep` |
-| Read-only specialist (audit-specialist, context-curator, furps-analyst, investigator, mobile-specialist, navigator, requirements-analyst, reviewer) | No write access — findings, investigation, or review quality is the entire deliverable, with no implementation pass downstream to catch a missed nuance | `deep` (always — see below) |
+| Read-only specialist (audit-specialist, context-curator, furps-analyst, investigator, mobile-specialist, navigator, requirements-analyst, reviewer) | No write access — findings, investigation, or review quality is the entire deliverable, with no implementation pass downstream to catch a missed nuance | `deep` (always — per the Rules of thumb below) |
 
 **Rules of thumb:**
 

package/skills/massa-ai/references/spec-driven/tasks.md

@@ -146,10 +146,9 @@ What MUST be done before this task can start?
 
 Group tasks into ordered phases. Each phase depends on the ones before it; tasks execute sequentially within a phase.
 
-**Size phases near the worker budget.** During Execute, phases are packed into task-budgeted batches (~7 tasks per sub-agent, whole phases — see `references/spec-driven/sub-agents.md`). Because a batch cut may only land on a phase boundary, a phase that is much larger than the budget forces an over-sized worker. Keep each phase from greatly exceeding the budget:
+**Size phases to the worker budget.** During Execute, phases are packed into task-budgeted batches (max 3 tasks per sub-agent, ideal 2, whole phases — see `references/spec-driven/sub-agents.md`). Because a batch cut may only land on a phase boundary, a phase over the budget forces an over-sized worker. Size each phase to **max 3 tasks, ideal 2**:
 
-- If a phase would hold **more than ~10 tasks (≈1.5× the budget)**, split it into cohesive sub-phases at a genuine dependency/cohesion seam — not at an arbitrary task index.
-- Only leave a phase over-sized when its tasks are one tight dependency chain that genuinely cannot be split. That is a legitimate (if fat) single-worker phase, not a smell.
+A phase that holds more than 3 tasks is wrongly sized — split it into cohesive sub-phases at a genuine dependency/cohesion seam, never at an arbitrary task index. There is no exception: even a phase whose tasks form one strict, seemingly unsplittable dependency sequence does not excuse it from the limit — split the sequence at its own internal cohesion seam instead.
 
 This keeps phase boundaries meaningful while letting the packing hit its target worker count.
 
@@ -354,12 +353,12 @@ Execution is strictly sequential — there is no intra-phase parallelism. A sing
 
 **How phase-based execution works:**
 
-At Execute, the agent counts total tasks and packs phases into **task-budgeted batches** (~7 tasks per worker, whole phases — the benchmarked sweet spot is ~20 tasks → ~3 workers). A **phase** is the semantic/dependency unit; a **batch** is one or more *consecutive whole phases* assigned to one worker. The cut only ever lands on a phase boundary — a phase is never split across workers. **The sub-agent offer fires whenever the feature has more than 3 tasks** — a 4–8-task feature still packs into a single batch and is offered as one batch worker; only a feature with 3 or fewer tasks executes inline with no offer. Batches run sequentially: each worker executes ALL its tasks in order, then reports a compact summary before the next batch starts. This right-sizes the worker count by workload instead of by phase count (one-per-phase is too fragmented; expensive and slow). See `references/spec-driven/sub-agents.md` for the full model — packing algorithm, offer-then-confirm, worker payload, compact summary contract, failure handling, and context sizing guidance.
+At Execute, the agent counts total tasks and packs phases into **task-budgeted batches** (max 3 tasks per worker, ideal 2, whole phases). A **phase** is the semantic/dependency unit; a **batch** is one or more *consecutive whole phases* assigned to one worker. The cut only ever lands on a phase boundary — a phase is never split across workers. **The sub-agent offer fires whenever the feature has more than 3 tasks** — under this budget, a triggered feature always packs into at least two workers, so the offer is never for a single batch; only a feature with 3 or fewer tasks executes inline with no offer. Batches run sequentially: each worker executes ALL its tasks in order, then reports a compact summary before the next batch starts. This right-sizes the worker count by workload instead of by phase count (one-per-phase is too fragmented; expensive and slow). See `references/spec-driven/sub-agents.md` for the full model — packing algorithm, offer-then-confirm, worker payload, compact summary contract, failure handling, and context sizing guidance.
 
 When the whole feature has 3 or fewer tasks, execution happens inline in the main window with no sub-agents spawned and no offer made.
 
 **The orchestrating agent's role during Execute:**
-1. Count total tasks — if more than 3, pack phases into ~7-task batches and offer batch sub-agents (even a single resulting batch is offered); wait for the user's choice
+1. Count total tasks — if more than 3, pack phases into max-3-task batches (ideal 2) and offer batch sub-agents; wait for the user's choice
 2. Dispatch the next batch (to a worker, or execute inline)
 3. Receive the compact batch summary
 4. Update tasks.md with results

package/skills/massa-ai/references/tdd/discovery-and-sizing.md

@@ -71,7 +71,7 @@ Do not use week-based project-size heuristics. Effort estimates are useful only
 
 Inspect first, ask second. Ask only when the answer changes architecture, scope, a public contract, safety, rollout, or acceptance.
 
-- Group at most three related questions per turn.
+- Group related questions naturally per turn — no numeric cap, ask as many as the open decisions require; when in doubt on an important decision, ask rather than assume.
 - Offer meaningful choices when alternatives are known; otherwise ask concise free-form questions.
 - Ask in the user's language.
 - Do not require owner, team, ticket, API, risk-count, or timeline fields merely to satisfy a template.

package/skills/massa-ai/references/ticket/intake-and-sources.md

@@ -16,7 +16,7 @@ Resolve inputs in this order:
 4. **Definition of Ready and Definition of Done**: ask whether the user wants to provide either source. Accept Jira or Confluence content through Atlassian MCP, explicitly supplied local files, or pasted text. Use built-in checklists when omitted.
 5. **Jira-required choices**: after metadata inspection, ask only for unresolved issue types, priorities, components, labels, ownership, versions, or custom fields that are required by Jira or material to the user's intent.
 
-Group related choices into at most three concise questions at a time. Reuse answers across the draft unless the user scopes a different value to a specific issue.
+Group related choices into concise questions asked together — as many as the open choices require, with no numeric cap. Reuse answers across the draft unless the user scopes a different value to a specific issue.
 
 ## Source Roles
 

package/skills/massa-ai/scripts/validate_tasks.ts

@@ -336,6 +336,40 @@ function parseDiagramOrder(lines: string[]): { positions: Map<string, number>; p
   return { positions, parsed: foundAnyArrow };
 }
 
+const MAX_TASKS_PER_PHASE = 3;
+
+/**
+ * Count tasks (TASK_RE headings) per phase (PHASE_HEADING_RE), scoped to the
+ * Task Breakdown section only - mirrors parsePhaseMembership's
+ * inTaskBreakdown gating so a phase heading appearing earlier in the
+ * Execution Plan diagram never seeds a count, and a task header encountered
+ * before any Phase heading inside Task Breakdown is not counted against a
+ * phase (unchanged behavior for phase-less breakdowns).
+ */
+function countTasksPerPhase(lines: string[]): Map<number, number> {
+  const counts = new Map<number, number>();
+  let inTaskBreakdown = false;
+  let currentPhase: number | null = null;
+  for (const ln of lines) {
+    const stripped = ln.trim();
+    if (TASK_BREAKDOWN_RE.test(stripped)) {
+      inTaskBreakdown = true;
+      continue;
+    }
+    if (!inTaskBreakdown) continue;
+    const pm = PHASE_HEADING_RE.exec(stripped);
+    if (pm) {
+      currentPhase = parseInt(pm[1]!, 10);
+      continue;
+    }
+    if (currentPhase === null) continue;
+    if (TASK_RE.test(stripped)) {
+      counts.set(currentPhase, (counts.get(currentPhase) ?? 0) + 1);
+    }
+  }
+  return counts;
+}
+
 function check(tasksPath: string): { errors: string[]; warnings: string[] } {
   const text = readFileSync(tasksPath, "utf-8");
   const lines = splitLines(text);
@@ -373,6 +407,15 @@ function check(tasksPath: string): { errors: string[]; warnings: string[] } {
     }
   }
 
+  // Per-phase task-count budget (WF-16, D14): a phase holding more than 3
+  // tasks is wrongly sized, not merely a smell - see D14 in design.md.
+  const phaseCounts = countTasksPerPhase(lines);
+  for (const [phase, count] of phaseCounts) {
+    if (count > MAX_TASKS_PER_PHASE) {
+      errors.push(`Phase ${phase} has ${count} tasks (max 3 per phase, ideal 2)`);
+    }
+  }
+
   // Forward-phase dependency. Iterates each task's deps Set in JS insertion
   // order - note Python's own iteration here is UNSORTED (`for dep in
   // t["deps"]`, a set) and its per-process order is hash-randomized, so a

package/skills/massa-ai/workflows/design.md

@@ -3,7 +3,7 @@ name: design
 description: "Implements or updates a concrete mobile UI from structured Figma evidence or screenshots when no saved audit report exists; route comparisons to mobile-figma-audit."
 license: MIT
 metadata:
-  version: "1.3.0"
+  version: "1.4.0"
 ---
 
 ### Design
@@ -23,7 +23,7 @@ Not for Flutter, React Native, web UI, generic Figma exploration, variable-only
 1. Resolve/reuse `workflowSessionId`: `design-[entity]`.
 2. Load `references/mobile-figma-matcher/repository-detection.md`, `references/mobile-figma-matcher/core.md`, `references/mobile-context.md`, `references/codebase-investigation.md`, `references/verification-ladder.md`, and `references/naming-standards.md` (before introducing or renaming identifiers, screens, components, attributes, or implementation-facing names — English-conversion rule applies). When Figma links or node IDs are provided, load `references/figma-pre-analysis.md` and run its two-stage sequential retrieval protocol before building the Figma Evidence Packet. Load `references/context-firewall.md` before large design/runtime artifacts and `references/synapse-policy.md` when repeated massa-ai searches are expected.
 3. `recall` -> load current component conventions, design-system rules, approved platform/accessibility deviations, prior Figma mappings, asset pipelines, and reusable render recipes. Memory is context, not proof.
-4. Require a concrete feature/module target plus at least one design source: readable Figma node/selection or supplied screenshots. Resolve required visual and interactive states plus a requirements source for behavior not represented in the design source. Ask only when target ownership, runtime platforms, platform-frame mappings, or screenshot authority stay ambiguous after source inspection.
+4. Require a concrete feature/module target plus at least one design source: readable Figma node/selection or supplied screenshots. Resolve required visual and interactive states plus a requirements source for behavior not represented in the design source. Ask whenever target ownership, runtime platforms, platform-frame mappings, screenshot authority, or any other important decision remains ambiguous or in doubt after source inspection.
 5. Follow `references/design-implementation.md` for the Target Surface Packet, the Figma Evidence / Screenshot Context Packet, the Design-To-Code Mapping Matrix, sizing and the verification recipe, coherent-slice implementation rules, per-slice verification, completion criteria, and the completion report — the single normative copy of this direction set, shared with `spec-driven`/`feature` under Figma ingestion.
 6. Persist only durable token/component mappings, approved deviations, source-set ownership rules, asset-pipeline rules, or reusable render recipes after Importance Calibration. Use `workflow:design` and required project/session/entity/memory tags.
 7. Complete `references/evidence-gate.md`. Model visual judgment alone cannot satisfy completion.

package/skills/massa-ai/workflows/spec-driven.md

@@ -3,7 +3,7 @@ name: spec-driven
 description: "Use this workflow for explicit spec-driven requests and broad, ambiguous, migration-heavy, or cross-boundary delivery needing requirements-through-verification control."
 license: MIT
 metadata:
-  version: "1.3.0"
+  version: "1.4.0"
 ---
 
 ### Spec-Driven
@@ -50,7 +50,7 @@ Complexity determines depth, not a fixed pipeline. Assess scope first, apply onl
 | Large | >10 tasks OR multi-component feature | Full spec + requirement IDs | Architecture + components | Full breakdown + deps | Implement + verify per task |
 | Complex | Ambiguity or new domain (unfamiliar vocabulary, no prior pattern) | Full spec + discuss gray areas | Research + architecture | Breakdown + phase plan | Implement + interactive UAT |
 
-A "Phase" is an ordered group of Tasks sharing a dependency boundary or a checkpoint commit — distinct from a single Task or atomic step. Report sizing in the uniform vocabulary: `1 Phase = X Tasks`; the whole plan is `Y Phases = Z Tasks`. The sub-agent offer fires when a formal `tasks.md` has more than 3 Tasks — packing itself still uses ~7-Task Phase groups; a 4–8-Task feature is offered as a single Phase-group worker.
+A "Phase" is an ordered group of Tasks sharing a dependency boundary or a checkpoint commit — distinct from a single Task or atomic step. Report sizing in the uniform vocabulary: `1 Phase = X Tasks`; the whole plan is `Y Phases = Z Tasks`. The sub-agent offer fires when a formal `tasks.md` has more than 3 Tasks — packing uses max-3-Task Phase groups (ideal 2); a feature over 3 Tasks always packs into at least two Phase-group workers.
 
 - Specify and Execute are always required.
 - Design is skipped when straightforward (no architectural decisions, no new patterns).
@@ -108,7 +108,7 @@ Quick artifacts live under `.specs/quick/NNN-slug/` with a `TASK.md` (one-line i
    - Run repo-rules discovery from `references/repo-rules-discovery.md` before the first repository mutation: record the harness sources loaded (or `repo-rules: none present`), and implement so every new or changed file conforms to the target repo's module layout, unit-test location, and testing-area conventions. A repo rule wins over a skill default for placement and gate commands; record any deviation with an explicit reason. Never fabricate rules or create `.claude/`/`.cursor/` directories the repo lacks.
    - Use the Test Coverage Matrix and Gate Check Commands from `tasks.md`, or state their inline equivalents when Tasks was skipped.
    - Ask the MCP and skill question in Tasks or inline Execute when tool choice can change correctness or verification.
-   - If a formal `tasks.md` has more than 3 Tasks, present the sub-agent offer from `references/spec-driven/sub-agents.md` before starting Execute — even when packing yields a single Phase group (a 4–8-Task feature is offered as one Phase-group worker).
+   - If a formal `tasks.md` has more than 3 Tasks, present the sub-agent offer from `references/spec-driven/sub-agents.md` before starting Execute — packing uses max 3 Tasks per worker (ideal 2), so a triggered feature always yields at least two Phase-group workers; the offer message begins with the Stage 1.5 change summary (see `references/implementation-delivery.md`).
    - Implement one atomic step or approved task at a time.
    - For long-running task sequences, use the checkpoint mechanism in `references/spec-driven/execute.md` (Pause / End of Session) so progress is resumable after interruption.
    - Use per-task commits when the environment and user permissions allow commits; otherwise record the skipped reason.

package/skills/massa-ai/workflows/tdd.md

@@ -3,7 +3,7 @@ name: tdd
 description: "Use this workflow to write a Technical Design Document once one product direction is selected and no unresolved API, data, security, or rollout decision blocks implementation."
 license: MIT
 metadata:
-  version: "1.1.0"
+  version: "1.2.0"
 ---
 
 ### TDD (Technical Design Document)
@@ -32,7 +32,7 @@ Load `references/project-context.md` (intake sweep) before the first substantive
      - external or cross-service integration → Dependencies and Security are mandatory.
 4. Resolve only material unknowns:
    - Reuse facts already available in source or approved documents.
-   - Ask at most three related questions at a time, in the user's language.
+   - Group related questions naturally, in the user's language — no numeric cap; ask as many as the open decisions require.
    - Distinguish verified facts, evidence-backed inferences, proposed decisions, and unresolved questions.
    - Never invent owners, links, APIs, schemas, vendors, dates, thresholds, estimates, approvals, or project facts to complete a template.
 5. Load `references/tdd/document-contract.md`, plus `references/naming-standards.md` when the design names proposed components, modules, states, events, schemas, or fields, and draft the smallest decision-complete TDD for the selected depth.