@locusai/cli 0.9.16 → 0.9.17

package/bin/agent/worker.js

@@ -24976,7 +24976,8 @@ var ApiResponseSchema = exports_external.object({
   meta: exports_external.object({
     pagination: PaginationMetaSchema.optional(),
     timestamp: exports_external.string(),
-    path: exports_external.string()
+    path: exports_external.string(),
+    requestId: exports_external.string().optional()
   }).optional()
 });
 var SuccessResponseSchema = exports_external.object({

package/bin/locus.js

@@ -36693,7 +36693,8 @@ var init_common = __esm(() => {
     meta: exports_external.object({
       pagination: PaginationMetaSchema.optional(),
       timestamp: exports_external.string(),
-      path: exports_external.string()
+      path: exports_external.string(),
+      requestId: exports_external.string().optional()
     }).optional()
   });
   SuccessResponseSchema = exports_external.object({
@@ -40588,7 +40589,10 @@ function parseSprintPlanFromAI(raw, directive) {
   if (jsonMatch) {
     jsonStr = jsonMatch[1]?.trim() || "";
   }
-  const parsed = JSON.parse(jsonStr);
+  let parsed = JSON.parse(jsonStr);
+  if (parsed.revisedPlan) {
+    parsed = parsed.revisedPlan;
+  }
   const now = new Date().toISOString();
   const id = `plan-${Date.now()}`;
   const tasks2 = (parsed.tasks || []).map((t, i) => ({
@@ -40801,10 +40805,25 @@ Review and refine the Tech Lead's breakdown:
 
 1. **Ordering** — Order tasks so that foundational work comes first. Tasks that produce outputs consumed by later tasks must appear earlier in the list. Foundation tasks (schemas, config, shared code) must be listed before tasks that build on them. The array index IS the execution order.
 2. **Risk Assessment** — Flag tasks that are risky, underestimated, or have unknowns.
-3. **Task Splitting** — If a task is too large (would take more than a day), split it.
-4. **Task Merging** — If two tasks are trivially small and related, merge them.
-5. **Complexity Scoring** — Rate each task 1-5 (1=trivial, 5=very complex).
-6. **Missing Tasks** — Add any tasks the Tech Lead missed (database migrations, configuration, testing, etc.).
+3. **Task Merging** — If two tasks are trivially small and related, merge them.
+4. **Complexity Scoring** — Rate each task 1-5 (1=trivial, 5=very complex).
+5. **Missing Tasks** — Add any tasks the Tech Lead missed (database migrations, configuration, testing, etc.).
+
+## CRITICAL: Task Isolation & Overlap Detection
+
+Tasks are executed by INDEPENDENT agents on SEPARATE git branches that get merged together. Each agent has NO knowledge of what other agents are doing. You MUST enforce these rules:
+
+1. **Detect overlapping file modifications.** For each task, mentally list the files it will touch. If two tasks modify the same file (especially config files like app.module.ts, configuration.ts, package.json, or shared modules), they WILL cause merge conflicts. You must either:
+   - **Merge them** into a single task, OR
+   - **Move the shared file changes** into one foundational task that runs and merges first
+
+2. **Detect duplicated work.** If two tasks both introduce the same environment variable, config field, dependency, helper function, or module registration — that is duplicated work. Consolidate it into ONE task.
+
+3. **Do NOT split tasks that share code changes.** Even if a task is large, do NOT split it if the subtasks would both need to modify the same files. A single larger self-contained task is far better than two smaller conflicting tasks. Only split tasks when the parts are truly independent (touch completely different files and modules).
+
+4. **Validate self-containment.** Each task must include ALL changes it needs to function: config, schema, module registration, implementation, and tests. A task must NOT assume another concurrent task will provide something it needs.
+
+5. **Flag high-conflict zones.** In your risk assessment, specifically call out any remaining cases where tasks might touch the same files, and explain why it's unavoidable and how merge conflicts can be minimized.
 
 ## Output Format
 
@@ -40834,6 +40853,116 @@ Respond with ONLY a JSON object (no markdown code blocks, no explanation):
   return prompt;
 }
 
+// ../sdk/src/planning/agents/cross-task-reviewer.ts
+function buildCrossTaskReviewerPrompt(input) {
+  let prompt = `# Role: Cross-Task Reviewer (Architect + Engineer + Planner)
+
+You are a combined Architect, Senior Engineer, and Sprint Planner performing a FINAL review of a sprint plan. Your sole focus is ensuring that tasks are fully isolated and will not conflict when executed by independent agents on separate git branches.
+
+## Context
+
+In this system, each task is executed by an independent AI agent that:
+- Works on its own git branch (worktree)
+- Has NO knowledge of what other agents are working on
+- Cannot see changes made by other concurrent agents
+- Its branch will be merged into main after completion
+
+This means that if two tasks modify the same file, add the same dependency, or introduce the same config variable — they WILL cause merge conflicts and duplicated code.
+
+## CEO Directive
+> ${input.directive}
+`;
+  if (input.feedback) {
+    prompt += `
+## CEO Feedback on Previous Plan
+> ${input.feedback}
+
+IMPORTANT: Ensure the reviewed plan still addresses this feedback.
+`;
+  }
+  prompt += `
+## Project Context
+${input.projectContext || "No project context available."}
+
+## Sprint Plan to Review
+${input.sprintOrganizerOutput}
+
+## Your Review Checklist
+
+Go through EACH pair of tasks and check for:
+
+### 1. File Overlap Analysis
+For each task, list the files it will likely modify. Then check:
+- Do any two tasks modify the same file? (e.g., app.module.ts, configuration.ts, package.json, shared DTOs)
+- If yes: MERGE those tasks or move shared changes to a foundational task
+
+### 2. Duplicated Work Detection
+Check if multiple tasks:
+- Add the same environment variable or config field
+- Install or configure the same dependency
+- Register the same module or provider
+- Create the same helper function, guard, interceptor, or middleware
+- Add the same import to a shared file
+If yes: consolidate into ONE task
+
+### 3. Self-Containment Validation
+For each task, verify:
+- Does it include ALL config/env changes it needs?
+- Does it include ALL module registrations it needs?
+- Does it include ALL dependency installations it needs?
+- Can it be completed without ANY output from concurrent tasks?
+
+### 4. Merge Conflict Risk Zones
+Identify the highest-risk files (files that multiple tasks might touch) and ensure only ONE task modifies each.
+
+## Output Format
+
+Respond with ONLY a JSON object (no markdown code blocks, no explanation):
+
+{
+  "hasIssues": true | false,
+  "issues": [
+    {
+      "type": "file_overlap" | "duplicated_work" | "not_self_contained" | "merge_conflict_risk",
+      "description": "string describing the specific issue",
+      "affectedTasks": ["Task Title 1", "Task Title 2"],
+      "resolution": "string describing how to fix it (merge, move, consolidate)"
+    }
+  ],
+  "revisedPlan": {
+    "name": "string (2-4 words)",
+    "goal": "string (1 paragraph)",
+    "estimatedDays": 3,
+    "tasks": [
+      {
+        "title": "string",
+        "description": "string",
+        "assigneeRole": "BACKEND | FRONTEND | QA | PM | DESIGN",
+        "priority": "CRITICAL | HIGH | MEDIUM | LOW",
+        "labels": ["string"],
+        "acceptanceCriteria": ["string"],
+        "complexity": 3
+      }
+    ],
+    "risks": [
+      {
+        "description": "string",
+        "mitigation": "string",
+        "severity": "low | medium | high"
+      }
+    ]
+  }
+}
+
+IMPORTANT:
+- If hasIssues is true, the revisedPlan MUST contain the corrected task list with issues resolved (tasks merged, duplicated work consolidated, etc.)
+- If hasIssues is false, the revisedPlan should be identical to the input plan (no changes needed)
+- The revisedPlan is ALWAYS required — it becomes the final plan
+- When merging tasks, combine their acceptance criteria and update descriptions to cover all consolidated work
+- Prefer fewer, larger, self-contained tasks over many small conflicting ones`;
+  return prompt;
+}
+
 // ../sdk/src/planning/agents/sprint-organizer.ts
 function buildSprintOrganizerPrompt(input) {
   let prompt = `# Role: Sprint Organizer
@@ -40872,6 +41001,15 @@ Guidelines:
 - Ensure acceptance criteria are specific and testable
 - Keep the sprint focused — if it's too large (>12 tasks), consider reducing scope
 
+## CRITICAL: Task Isolation Validation
+
+Before finalizing, validate that EVERY task is fully self-contained and conflict-free:
+
+1. **No two tasks should modify the same file.** If they do, merge them or restructure so shared changes live in one foundational task.
+2. **No duplicated work.** Each env var, config field, dependency, module import, or helper function must be introduced by exactly ONE task.
+3. **Each task is independently executable.** An agent working on task N must be able to complete it without knowing what tasks N-1 or N+1 are doing. The only exception is foundational tasks that are merged BEFORE dependent tasks start.
+4. **Prefer fewer, larger self-contained tasks over many small overlapping ones.** Do not split a task if the parts would conflict with each other.
+
 ## Output Format
 
 Respond with ONLY a JSON object (no markdown code blocks, no explanation):
@@ -40943,6 +41081,16 @@ Think about:
 - What the right granularity is (not too big, not too small)
 - What risks or unknowns exist
 
+## CRITICAL: Task Isolation Rules
+
+Tasks will be executed by INDEPENDENT agents on SEPARATE git branches that get merged together. Each agent has NO knowledge of what other agents are doing. Therefore:
+
+1. **No shared work across tasks.** If two tasks both need the same config variable, helper function, database migration, or module setup, that shared work MUST be consolidated into ONE task (or placed into a dedicated foundational task that runs first and is merged before others start).
+2. **Each task must be fully self-contained.** A task must include ALL the code changes it needs to work — from config to implementation to tests. It should NOT assume that another task in the same sprint will create something it depends on.
+3. **Do NOT split tasks if they share code changes.** If implementing feature A and feature B both require modifying the same file or adding the same dependency/config, they should be ONE task — even if that makes the task larger. A bigger self-contained task is better than two smaller conflicting tasks.
+4. **Think about file-level conflicts.** Two tasks modifying the same file (e.g., app.module.ts, configuration.ts, package.json) will cause git merge conflicts. Minimize this by bundling related changes together.
+5. **Environment variables, configs, and shared modules are high-conflict zones.** If a task introduces a new env var, config schema field, or module import, NO other task should touch that same file unless absolutely necessary.
+
 ## Output Format
 
 Respond with ONLY a JSON object (no markdown code blocks, no explanation):
@@ -40980,7 +41128,7 @@ class PlanningMeeting {
   async run(directive, feedback) {
     const projectContext = this.getProjectContext();
     const codebaseIndex = this.getCodebaseIndex();
-    this.log("Phase 1/3: Tech Lead analyzing directive...", "info");
+    this.log("Phase 1/4: Tech Lead analyzing directive...", "info");
     const techLeadPrompt = buildTechLeadPrompt({
       directive,
       projectContext,
@@ -40989,7 +41137,7 @@ class PlanningMeeting {
     });
     const techLeadOutput = await this.aiRunner.run(techLeadPrompt);
     this.log("Tech Lead phase complete.", "success");
-    this.log("Phase 2/3: Architect refining task breakdown...", "info");
+    this.log("Phase 2/4: Architect refining task breakdown...", "info");
     const architectPrompt = buildArchitectPrompt({
       directive,
       projectContext,
@@ -40998,7 +41146,7 @@ class PlanningMeeting {
     });
     const architectOutput = await this.aiRunner.run(architectPrompt);
     this.log("Architect phase complete.", "success");
-    this.log("Phase 3/3: Sprint Organizer finalizing plan...", "info");
+    this.log("Phase 3/4: Sprint Organizer finalizing plan...", "info");
     const sprintOrganizerPrompt = buildSprintOrganizerPrompt({
       directive,
       architectOutput,
@@ -41006,7 +41154,16 @@ class PlanningMeeting {
     });
     const sprintOrganizerOutput = await this.aiRunner.run(sprintOrganizerPrompt);
     this.log("Sprint Organizer phase complete.", "success");
-    const plan = parseSprintPlanFromAI(sprintOrganizerOutput, directive);
+    this.log("Phase 4/4: Cross-Task Review checking for conflicts and overlaps...", "info");
+    const crossTaskReviewerPrompt = buildCrossTaskReviewerPrompt({
+      directive,
+      projectContext,
+      sprintOrganizerOutput,
+      feedback
+    });
+    const crossTaskReviewOutput = await this.aiRunner.run(crossTaskReviewerPrompt);
+    this.log("Cross-Task Review phase complete.", "success");
+    const plan = parseSprintPlanFromAI(crossTaskReviewOutput, directive);
     if (feedback) {
       plan.feedback = feedback;
     }
@@ -41015,7 +41172,8 @@ class PlanningMeeting {
       phaseOutputs: {
         techLead: techLeadOutput,
         architect: architectOutput,
-        sprintOrganizer: sprintOrganizerOutput
+        sprintOrganizer: sprintOrganizerOutput,
+        crossTaskReview: crossTaskReviewOutput
       }
     };
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@locusai/cli",
-  "version": "0.9.16",
+  "version": "0.9.17",
   "description": "CLI for Locus - AI-native project management platform",
   "type": "module",
   "bin": {
@@ -32,7 +32,7 @@
   "author": "",
   "license": "MIT",
   "dependencies": {
-    "@locusai/sdk": "^0.9.16"
+    "@locusai/sdk": "^0.9.17"
   },
   "devDependencies": {}
 }