qatools-cli 1.2.0 → 1.2.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "qatools-cli",
-  "version": "1.2.0",
+  "version": "1.2.1",
   "description": "CLI for QA Tools — requirements, epics, sprints, sessions, App Context sync, project agenda. The companion to qa-tools.com.",
   "scripts": {
     "release": "npm version patch --no-git-tag-version && npm publish",

package/qatools.js

@@ -3190,6 +3190,7 @@ const MCP_INSTRUCTIONS = `qa-tools: requirements-driven QA. Rules that apply to
 - The backlog is signals (bug=AVV, requirement_gap=GAP, technical_defect=DEF, improvement=IMP), not a task list.
 - Backlog flow: open → in_progress → ready_for_test → resolved. Set ready_for_test when you believe a fix is done; resolved needs evidence (min 10 chars) and, except GAP, a prior ready_for_test.
 - Requirement status implemented/tested needs evidence: test output, file:line, expected vs actual, or "no test applies because <reason>".
+- Sprint planning: plan approved, functional requirements only (update_requirement sprintId), never backlog items; non-functional requirements are continuous and never go into sprints. Gather facts first (list_sprints, sprint_velocity, list_epics, list_requirements), respect epic dependsOn, present the plan as a table (sprint | requirement | reason) and change NOTHING until the user approves it in this conversation. If the user isn't here or wants to decide later, save it with propose_sprint_plan instead — they approve in qa-tools. Full procedure: prompt plan_sprints.
 - Every tool takes an optional projectId; without it the configured project (qatools setup) is used.`;
 
 const mcpStr = (description, extra = {}) => ({ type: "string", description, ...extra });
@@ -3379,6 +3380,59 @@ const mcpTools = [
       };
     },
   },
+  {
+    name: "propose_sprint_plan",
+    description: "Save a sprint plan as a PENDING proposal instead of applying it. A project member reviews it in qa-tools (Sprints → Plan proposals), selects rows and approves — Claude can never approve. Use when the user isn't in this conversation, or asks to decide later. Only approved, functional requirements; each row targets an existing sprintId OR a newSprintRef from newSprints. The whole proposal is refused if any row can't be planned.",
+    inputSchema: mcpSchema({
+      goal: mcpStr("What the plan optimises for, e.g. 'Release 4.0 by Nov 18'"),
+      summary: mcpStr("Short rationale: capacity used, dependency order, risks"),
+      items: {
+        type: "array",
+        description: "One row per requirement",
+        items: {
+          type: "object",
+          properties: {
+            requirementId: mcpStr("Requirement document ID"),
+            sprintId: mcpStr("Existing sprint ID (or use newSprintRef)"),
+            newSprintRef: mcpStr("ref of a sprint in newSprints"),
+            reason: mcpStr("Why this requirement goes in this sprint"),
+          },
+          required: ["requirementId", "reason"],
+          additionalProperties: false,
+        },
+      },
+      newSprints: {
+        type: "array",
+        description: "Sprints to create if the proposal is approved",
+        items: {
+          type: "object",
+          properties: {
+            ref: mcpStr("Your local reference, e.g. new-1"),
+            name: mcpStr("Sprint name"),
+            releaseDate: mcpStr("End date YYYY-MM-DD"),
+            startDate: mcpStr("Start date YYYY-MM-DD"),
+          },
+          required: ["ref", "name", "releaseDate"],
+          additionalProperties: false,
+        },
+      },
+      omitted: {
+        type: "array",
+        description: "Requirements deliberately left out, with why",
+        items: { type: "object", properties: { key: mcpStr("Requirement key"), reason: mcpStr("Why") }, required: ["key", "reason"], additionalProperties: false },
+      },
+    }, ["items"]),
+    run: async (a) => {
+      const r = await mcpCall("createPlanProposal", { projectId: a.projectId, ...mcpPick(a, ["goal", "summary", "items", "newSprints", "omitted"]) });
+      return { ...r, next: "Pending. A project member approves or rejects it in qa-tools under Sprints → Plan proposals." };
+    },
+  },
+  {
+    name: "list_plan_proposals",
+    description: "List sprint-plan proposals and their status (pending/approved/rejected), with who decided and what was applied.",
+    inputSchema: mcpSchema({ status: mcpStr("Filter by status", { enum: ["pending", "approved", "rejected"] }) }),
+    run: async (a) => (await mcpCall("listPlanProposals", { projectId: a.projectId, status: a.status || null })).proposals,
+  },
   {
     name: "get_sprint_items",
     description: "Everything planned in a sprint: its requirements (the planning unit) and the backlog signals linked to it.",
@@ -3523,14 +3577,15 @@ Follow these steps in order:
 
 1. Gather facts, don't guess: list_sprints, sprint_velocity, list_epics, list_requirements (status approved, plus anything already planned in open sprints).
 2. Draft a plan. Only requirements are planned — never create backlog items as tasks. Rules:
-   - Only status=approved requirements without a sprint are candidates. Never touch completed sprints or requirements already in one.
+   - Only status=approved, functional requirements without a sprint are candidates. Non-functional (compliance) requirements are continuous — never plan them. Never touch completed sprints or requirements already in one.
    - An epic's requirements never go into an earlier sprint than the requirements of the epics it dependsOn.
    - Order by priority (1 first), then epic priority.
    - Per sprint, plan roughly averageDonePerCompletedSprint requirements (from sprint_velocity), counting what is already planned there. If there is no history, say so and propose a conservative number.
    - If the requirements don't fit in the existing sprints, propose new sprints (name + end date) — don't create them yet.
 3. Present the proposal as a table: sprint | requirement key | title | reason (priority / epic dependency / capacity). Also list what you deliberately left out and why, and any dependency conflicts you found.
-4. STOP and wait for the user's approval. Change nothing before that. Apply any adjustments the user asks for and show the table again.
-5. After approval: create_sprint for any new sprints, then update_requirement with sprintId for each planned requirement. Report each change and any refusal verbatim — never retry a refused change in a different way.
+4. STOP and ask the user: approve here, or save it as a proposal to decide later in qa-tools? Change nothing before that. Apply any adjustments the user asks for and show the table again.
+   - If nobody is there to answer (an unattended run), or the user chooses "later": call propose_sprint_plan with the same rows, and report the result. Do not apply anything yourself.
+5. After approval in this conversation: create_sprint for any new sprints, then update_requirement with sprintId for each planned requirement. Report each change and any refusal verbatim — never retry a refused change in a different way.
 6. End with get_sprint_items for each affected sprint so the user can see the result.`,
   },
 ];