@trygentic/agentloop 0.15.1-alpha.11 → 0.16.0-alpha.11

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trygentic/agentloop",
-  "version": "0.15.1-alpha.11",
+  "version": "0.16.0-alpha.11",
   "description": "AI-powered autonomous coding agent",
   "bin": {
     "agentloop": "./bin/agentloop"
@@ -9,8 +9,8 @@
     "postinstall": "node ./scripts/postinstall.mjs"
   },
   "optionalDependencies": {
-    "@trygentic/agentloop-darwin-arm64": "0.15.1-alpha.11",
-    "@trygentic/agentloop-linux-x64": "0.15.1-alpha.11"
+    "@trygentic/agentloop-darwin-arm64": "0.16.0-alpha.11",
+    "@trygentic/agentloop-linux-x64": "0.16.0-alpha.11"
   },
   "engines": {
     "node": ">=18.0.0"

package/templates/agents/engineer/engineer.bt.json

@@ -509,6 +509,21 @@
           "call": "GitPush",
           "comment": "Push the branch to remote so QA and CI can access the changes"
         },
+        {
+          "type": "llm-action",
+          "name": "PrepareCompletionComment",
+          "prompt": "Generate a completion comment for this task. The comment MUST include a [TASK_FILES] block listing all files created or modified.\n\nTask: {{taskDescription}}\nImplementation: {{implementation}}\nPre-Commit Validation: {{preCommitValidation}}\nProject Info: {{projectInfo}}\n\nFormat the comment as:\n1. A brief summary of what was implemented\n2. A [TASK_FILES] block with one file path per line:\n[TASK_FILES]\npath/to/file1.ts\npath/to/file2.ts\n[/TASK_FILES]\n\nAlso include a [TEST_SETUP] block if tests were run or the project has non-standard test configuration:\n[TEST_SETUP]\ntestDirectory: <relative path to the directory where tests should be run, e.g., \"frontend\" — omit if root>\ntestCommand: <the exact test command that works, e.g., \"npx jest --transform='{}' src/__tests__/\">\nprojectType: <expo, node, bun, etc.>\npackageManager: <npm, yarn, pnpm, bun>\n[/TEST_SETUP]\n\nThis helps QA run the correct test command from the correct directory.\n\nExtract file paths from the implementation changes array. Include ALL files that were created, modified, or deleted.",
+          "contextKeys": ["taskDescription", "implementation", "preCommitValidation", "projectInfo"],
+          "outputSchema": {
+            "type": "object",
+            "properties": {
+              "comment": { "type": "string", "description": "The full completion comment including [TASK_FILES] and [TEST_SETUP] blocks" }
+            },
+            "required": ["comment"]
+          },
+          "outputKey": "completionComment",
+          "temperature": 0.3
+        },
         {
           "type": "action",
           "call": "AddCompletionComment"
@@ -586,6 +601,7 @@
     "gitRepoInitialized": false,
     "gitCommitHash": null,
     "projectInfo": null,
+    "completionComment": null,
     "preCommitValidation": null,
     "validationFailed": false,
     "maxRetries": 3,

package/templates/agents/engineer/engineer.md

@@ -235,6 +235,22 @@ Every implementation MUST include tests. This is non-negotiable.
 - Place tests near the code they test (e.g., `src/utils/__tests__/helper.test.ts`)
 - Match existing test file naming: if the project uses `.test.ts`, use that; if it uses `.spec.ts`, use that
 
+## Expo / React Native Projects
+
+When working on Expo or React Native projects:
+
+**Testing conventions:**
+- Tests typically use `jest-expo` preset with Jest
+- Run tests with `npx jest` from the project directory (NOT `npm test` unless a valid test script exists)
+- Follow the existing test patterns in the project — if tests use `--transform='{}'` for pure logic tests, maintain that pattern
+- Do NOT introduce `@testing-library/react-native` rendering tests if existing tests use pure logic patterns
+- Common test file locations: `src/__tests__/`, `__tests__/`, `tests/`
+
+**Monorepo awareness:**
+- If the project has subdirectories like `frontend/`, `backend/`, `web/`, ensure you run tests from the correct subdirectory
+- Check the root `package.json` test script — it may delegate to a subdirectory (e.g., `cd frontend && npx jest`)
+- When writing completion comments, always specify the test directory in the [TEST_SETUP] block
+
 ## Root Cause Analysis
 
 When fixing bugs or addressing QA feedback, understand the ROOT CAUSE before implementing.

package/templates/agents/product-manager/product-manager.bt.json

@@ -21,10 +21,10 @@
         {
           "type": "llm-action",
           "name": "PlanAndCreateTasks",
-          "prompt": "You are a product manager agent. Your job is to break down a high-level feature request into actionable AGILE tasks with proper DAG dependencies.\n\n## Feature Request\nTitle: {{taskTitle}}\nDescription: {{taskDescription}}\n\n## Your Workflow\n\n### Step 0 - Create or Reuse Subproject (MANDATORY FIRST ACTION)\nBefore creating ANY tasks, check if a subproject already exists for this work:\n1. Call `mcp__agentloop__list_subprojects` to check for existing ones\n2. If the delegation message included a subprojectId, reuse that subproject\n3. If no relevant subproject exists, call `mcp__agentloop__create_subproject` with a descriptive name\n4. Save the subprojectId for ALL subsequent create_task calls\n\n### Step 1 - Check Existing Tasks\nCall `mcp__agentloop__list_tasks` with `limit: 100, status: \"all\"` to see what already exists.\nIf tasks already cover this work, report that instead of creating duplicates.\n\n### Step 2 - Analyze Complexity\nDetermine task count based on ACTUAL complexity:\n- Simple (1-5 tasks): \"add hello world endpoint\" -> 1-2 tasks\n- Medium (5-15 tasks): \"add user authentication\" -> 8-12 tasks  \n- Large (20-30 tasks): \"build payment system\" -> 25-30 tasks\n\nDO NOT inflate task counts artificially.\n\n### Step 3 - Create Tasks\nFor each task, call `mcp__agentloop__create_task` with:\n- title, description, priority, tags, sequence, subprojectId\n- Record all returned task IDs\n\n### Step 4 - Build DAG Dependencies (MANDATORY)\nCall `mcp__agentloop__add_task_dependency` for EACH dependency relationship.\nMaximize parallelism - engineers work in isolated worktrees.\n\n### Step 5 - Validate\nCall `mcp__agentloop__validate_dag` then `mcp__agentloop__visualize_dag`.\n\n## Critical Rules\n- You are a PLANNER, not an implementer. NEVER write code or create files.\n- ALWAYS create tasks using mcp__agentloop__create_task\n- ALWAYS build DAG dependencies using mcp__agentloop__add_task_dependency\n- ALWAYS include subprojectId in every create_task call\n- Engineers work in project root (.) - NEVER include commands that create subdirectories\n- Explicitly specify tech stack in task descriptions\n\nProvide a summary when done.",
+          "prompt": "You are a product manager agent. Your job is to break down a high-level feature request into actionable AGILE tasks with proper DAG dependencies.\n\n## Feature Request\nTitle: {{taskTitle}}\nDescription: {{taskDescription}}\n\n## CRITICAL: Maximize Parallel Tool Calls\nYou MUST minimize the number of LLM turns by batching independent tool calls into the SAME response.\nEvery extra turn adds ~5-10 seconds of latency. Batch aggressively.\n\n## Your Workflow\n\n### Turn 1 — Gather Context (parallel reads)\nCall BOTH of these tools in a SINGLE response:\n- `mcp__agentloop__list_subprojects` — check for existing subprojects\n- `mcp__agentloop__list_tasks` with `limit: 100, status: \"all\"` — check existing tasks\n\n### Turn 2 — Create Subproject (if needed)\nIf the delegation message included a subprojectId, reuse it. Otherwise call `mcp__agentloop__create_subproject`.\nIf a subproject already exists for this work, skip creation.\nSave the subprojectId for ALL subsequent create_task calls.\nIf tasks already cover this work, report that instead of creating duplicates and stop.\n\n### Turn 3 — Analyze & Create ALL Tasks (SINGLE response)\nDetermine task count based on ACTUAL complexity:\n- Simple (1-5 tasks): \"add logout button\" -> 1-2 tasks\n- Medium (5-15 tasks): \"add user authentication\" -> 8-12 tasks\n- Large (20-30 tasks): \"build payment system\" -> 25-30 tasks\n\nDO NOT inflate task counts artificially.\n\n**IMPORTANT: Call ALL `mcp__agentloop__create_task` tools in a SINGLE response as parallel tool_use blocks.**\nDo NOT create tasks one at a time across multiple turns. Include all of them in one message.\nEach call needs: title, description, priority, tags, sequence, subprojectId.\nRecord all returned task IDs from the results.\n\n### Turn 4 — Add ALL Dependencies (SINGLE response)\n**IMPORTANT: Call ALL `mcp__agentloop__add_task_dependency` tools in a SINGLE response as parallel tool_use blocks.**\nDo NOT add dependencies one at a time across multiple turns.\nUse the task IDs returned from Turn 3. Maximize parallelism — engineers work in isolated worktrees.\n\n### Turn 5 — Validate (parallel reads)\nCall BOTH in a SINGLE response:\n- `mcp__agentloop__validate_dag`\n- `mcp__agentloop__visualize_dag`\n\n## Critical Rules\n- You are a PLANNER, not an implementer. NEVER write code or create files.\n- ALWAYS create tasks using mcp__agentloop__create_task\n- ALWAYS build DAG dependencies using mcp__agentloop__add_task_dependency\n- ALWAYS include subprojectId in every create_task call\n- Engineers work in project root (.) - NEVER include commands that create subdirectories\n- Explicitly specify tech stack in task descriptions\n- NEVER make sequential tool calls when they can be parallel. This is a performance-critical agent.\n\nProvide a summary when done.",
           "contextKeys": ["taskTitle", "taskDescription", "taskComments"],
           "subagent": "product-manager",
-          "maxTurns": 80,
+          "maxTurns": 25,
           "outputSchema": {
             "type": "object",
             "properties": {

package/templates/agents/product-manager/product-manager.md

@@ -49,7 +49,7 @@ mcp:
           Use the `subprojectId` parameter to assign every task to the active subproject.
 
           Sizing guide:
-          - Simple (1-5 tasks): "add hello world endpoint" → 1-2 tasks
+          - Simple (1-5 tasks): "add logout button" → 1-2 tasks
           - Medium (5-15 tasks): "add user auth" → 8-12 tasks
           - Large (20-30 tasks): "build payment system" → 25-30 tasks
 
@@ -124,7 +124,7 @@ If you find yourself about to write code or run commands, STOP and create a task
 
 | Complexity | Tasks | Example |
 |------------|-------|---------|
-| Simple | 1-5 | "add hello world endpoint" → 1-2 tasks |
+| Simple | 1-5 | "add logout button" → 1-2 tasks |
 | Medium | 5-15 | "add user authentication" → 8-12 tasks |
 | Large | 20-30 | "build payment system" → 25-30 tasks |
 

package/templates/agents/qa-tester/qa-tester.bt.json

@@ -137,12 +137,12 @@
                                 {
                                   "type": "llm-action",
                                   "name": "DetermineTestCommand",
-                                  "prompt": "Determine the correct test command for this project.\n\nProject Info: {{projectInfo}}\n\nCRITICAL: Check the runtime/package manager FIRST before choosing a test command.\n\nRuntime detection priority (check in this order):\n1. If projectInfo.primaryType is 'bun' OR detectedFiles include 'bun.lockb', 'bun.lock', or 'bunfig.toml' OR packageManager is 'bun': this is a BUN project. Use 'bun test'. Set projectType to 'bun'.\n2. If detectedFiles include 'yarn.lock': use 'yarn test'. Set projectType to 'node-yarn'.\n3. If detectedFiles include 'pnpm-lock.yaml': use 'pnpm test'. Set projectType to 'node-pnpm'.\n4. If only 'package.json' is detected with no specific lock file: use 'npm test'. Set projectType to 'node'.\n\nOther project types:\n- Rust (Cargo.toml): cargo test\n- Python (pyproject.toml, setup.py): pytest\n- Go (go.mod): go test ./...\n\nDo NOT default to 'npm test' when Bun indicators are present. A project with bun.lock or bun.lockb is a Bun project, not a Node.js project.",
-                                  "contextKeys": ["projectInfo", "testFilesFound"],
+                                  "prompt": "Determine the correct test command for this project.\n\nProject Info: {{projectInfo}}\n\nEngineer Test Setup (from engineer's completion comment): {{engineerTestSetup}}\n\nIMPORTANT: If engineerTestSetup is provided by the engineer, PREFER using their testCommand and testDirectory. The engineer already verified these work. Only override if you detect an obvious error.\n\nIf engineerTestSetup.testDirectory is set (e.g., \"frontend\"), the test command must be run from that subdirectory. Prefix with: cd <testDirectory> && <testCommand>\n\nCRITICAL: Check the runtime/package manager FIRST before choosing a test command.\n\nRuntime detection priority (check in this order):\n1. If projectInfo.primaryType is 'bun' OR detectedFiles include 'bun.lockb', 'bun.lock', or 'bunfig.toml' OR packageManager is 'bun': this is a BUN project. Use 'bun test'. Set projectType to 'bun'.\n2. If detectedFiles include 'yarn.lock': use 'yarn test'. Set projectType to 'node-yarn'.\n3. If detectedFiles include 'pnpm-lock.yaml': use 'pnpm test'. Set projectType to 'node-pnpm'.\n4. If only 'package.json' is detected with no specific lock file: use 'npm test'. Set projectType to 'node'.\n5. If projectInfo.primaryType is 'expo' OR detectedFiles include 'app.json' with 'expo' key, 'app.config.js', 'app.config.ts', OR package.json has 'expo' dependency: this is an EXPO/React Native project. Set projectType to 'expo'.\n   - If package.json has a 'test' script that is valid (not a placeholder), use that (e.g., 'npm test' or 'jest')\n   - If jest-expo is in dependencies/devDependencies, use 'npx jest'\n   - If @testing-library/react-native is present, use 'npx jest'\n   - If no test runner is found, use 'npx jest --passWithNoTests'\n\nOther project types:\n- Rust (Cargo.toml): cargo test\n- Python (pyproject.toml, setup.py): pytest\n- Go (go.mod): go test ./...\n\nDo NOT default to 'npm test' when Bun indicators are present. A project with bun.lock or bun.lockb is a Bun project, not a Node.js project.\nDo NOT default to 'npm test' for Expo projects that have no test script. Use 'npx jest' instead.",
+                                  "contextKeys": ["projectInfo", "testFilesFound", "engineerTestSetup"],
                                   "outputSchema": {
                                     "type": "object",
                                     "properties": {
-                                      "projectType": { "type": "string", "enum": ["bun", "node", "node-yarn", "node-pnpm", "rust", "python", "go", "java-maven", "java-gradle", "ruby", "php", "elixir", "other"] },
+                                      "projectType": { "type": "string", "enum": ["bun", "node", "node-yarn", "node-pnpm", "expo", "rust", "python", "go", "java-maven", "java-gradle", "ruby", "php", "elixir", "other"] },
                                       "testCommand": { "type": "string" },
                                       "reasoning": { "type": "string" }
                                     },
@@ -180,12 +180,12 @@
                                           {
                                             "type": "llm-action",
                                             "name": "AnalyzeTestResults",
-                                            "prompt": "Analyze the test results in the context of what files were changed.\n\nTest Output: {{testResults}}\nTest Command: {{testCommandInfo}}\nGit Diff (files changed by engineer): {{gitDiff}}\nTask Files: {{taskFiles}}\nChange Analysis: {{changeAnalysis}}\n\nYour job is to determine if the engineer's changes CAUSED any test failures. You MUST distinguish between:\n\n1. **Task-related failures**: Tests that fail because of code the engineer changed or added. These are in files listed in the git diff or task files, or test files that directly import/test those changed modules. These are legitimate failures.\n\n2. **Pre-existing/unrelated failures**: Tests that fail in modules the engineer did NOT touch. These failures existed BEFORE the engineer's changes and are NOT the engineer's responsibility. Do NOT count these as failures.\n\n3. **Environment issues**: Test runner not found (exit code 127), dependencies not installed, 'command not found' errors, missing optional dependencies (@rollup/rollup-*, @esbuild/*), module resolution errors. These are QA environment issues, NOT code issues.\n\nIMPORTANT: If ONLY environment issues occurred (no tests actually ran), set 'passed' to false and classify failures as 'environment'.\n\nSet 'passed' to true ONLY if:\n- Tests actually executed AND\n- There are NO task-related failures\n\nSet 'passed' to false if:\n- Environment issues prevented tests from running, OR\n- There are task-related failures\n\nFor each failure, classify it as 'task-related', 'pre-existing', or 'environment' in the classification field.",
-                                            "contextKeys": ["testResults", "testCommandInfo", "changeAnalysis", "gitDiff", "taskFiles"],
+                                            "prompt": "Analyze the test results in the context of what files were changed.\n\nTest Output: {{testResults}}\nTest Command: {{testCommandInfo}}\nGit Diff (files changed by engineer): {{gitDiff}}\nTask Files: {{taskFiles}}\nChange Analysis: {{changeAnalysis}}\n\nYour job is to determine if the engineer's changes CAUSED any test failures. You MUST distinguish between:\n\n1. **Task-related failures**: Tests that fail because of code the engineer changed or added. These are in files listed in the git diff or task files, or test files that directly import/test those changed modules. These are legitimate failures.\n\n2. **Pre-existing/unrelated failures**: Tests that fail in modules the engineer did NOT touch. These failures existed BEFORE the engineer's changes and are NOT the engineer's responsibility. Do NOT count these as failures.\n\n3. **Environment issues**: Test runner not found (exit code 127), dependencies not installed, 'command not found' errors, missing optional dependencies (@rollup/rollup-*, @esbuild/*), module resolution errors. These are QA environment issues, NOT code issues.\n\nIMPORTANT: If ONLY environment issues occurred and there are NO indications of task-related failures (taskRelatedFailures is 0 or null), set 'passed' to true — the engineer's code is not at fault for environment problems. Classify failures as 'environment'.\n\nSet 'passed' to true if:\n- Tests actually executed AND there are NO task-related failures, OR\n- Tests did NOT execute due to environment issues AND there are NO task-related failures detected\n\nSet 'passed' to false if:\n- There are task-related failures (regardless of whether other environment issues exist)\n\nFor each failure, classify it as 'task-related', 'pre-existing', or 'environment' in the classification field.",
+                                            "contextKeys": ["testResults", "testCommandInfo", "changeAnalysis", "gitDiff", "taskFiles", "engineerTestSetup"],
                                             "outputSchema": {
                                               "type": "object",
                                               "properties": {
-                                                "passed": { "type": "boolean", "description": "true ONLY if tests actually ran and no task-related failures exist. false if env issues prevented execution." },
+                                                "passed": { "type": "boolean", "description": "true if no task-related failures exist (even if tests did not run due to environment issues). false only if there are task-related failures." },
                                                 "testsActuallyRan": { "type": "boolean", "description": "true if tests actually executed, false if blocked by environment issues" },
                                                 "totalTests": { "type": ["number", "null"] },
                                                 "passedTests": { "type": ["number", "null"] },
@@ -296,10 +296,10 @@
                                         {
                                           "type": "llm-condition",
                                           "name": "TestsPassed",
-                                          "prompt": "Based on the analyzed test results, did the engineer's changes pass QA?\n\nTest Results: {{analyzedTestResults}}\nGit Diff: {{gitDiff}}\nTask Files: {{taskFiles}}\nEnvironment Retry Count: {{envRetryCount}}\n\nReturn true if the engineer's changes did NOT introduce any new test failures AND tests actually executed.\n\nCRITICAL RULES:\n1. If 'passed' is true in analyzedTestResults AND tests actually ran, return true.\n2. If 'taskRelatedFailures' is 0 or null AND tests ran, return true — even if there are pre-existing failures.\n3. Pre-existing failures (tests failing in code the engineer did NOT touch) do NOT count as the engineer's fault. Return true.\n4. ONLY return false if:\n   - There are failures directly caused by the engineer's changes (classification: 'task-related'), OR\n   - Tests did NOT actually execute (environment issues prevented them from running even after retries)\n5. If 'testsActuallyRan' is false or all failures are 'environment' type, return false - we need to see actual test results.\n6. Environment issues that could not be fixed after retries should result in false (tests didn't run).",
+                                          "prompt": "Based on the analyzed test results, did the engineer's changes pass QA?\n\nTest Results: {{analyzedTestResults}}\nGit Diff: {{gitDiff}}\nTask Files: {{taskFiles}}\nEnvironment Retry Count: {{envRetryCount}}\n\nReturn true if the engineer's changes did NOT introduce any new test failures. Environment issues alone should NOT cause rejection.\n\nCRITICAL RULES:\n1. If 'passed' is true in analyzedTestResults, return true.\n2. If 'taskRelatedFailures' is 0 or null, return true — even if there are pre-existing failures or environment issues. The engineer's code is not at fault.\n3. Pre-existing failures (tests failing in code the engineer did NOT touch) do NOT count as the engineer's fault. Return true.\n4. ONLY return false if there are actual task-related failures (classification: 'task-related') — failures directly caused by the engineer's changes.\n5. If 'testsActuallyRan' is false AND 'taskRelatedFailures' is 0 or null, return true — environment issues that prevented tests from running are NOT the engineer's fault. The task should be approved.\n6. If 'testsActuallyRan' is false AND there ARE task-related failures detected, return false.",
                                           "contextKeys": ["analyzedTestResults", "gitDiff", "taskFiles", "envRetryCount"],
                                           "confidenceThreshold": 0.8,
-                                          "fallbackValue": false
+                                          "fallbackValue": true
                                         },
                                         {
                                           "type": "llm-action",
@@ -650,6 +650,7 @@
     "environmentFixAttempted": false,
     "environmentFixResults": null,
     "projectInfo": null,
+    "engineerTestSetup": null,
     "testCommandInfo": null,
     "testExitCode": null,
     "requestedStatus": null,

package/templates/agents/qa-tester/qa-tester.md

@@ -111,6 +111,45 @@ If you encounter "command not found" (exit code 127) or missing dependency error
 - Module resolution errors for packages the engineer did not change
 - Flaky tests that fail intermittently and are unrelated to the changes
 
+## Expo / React Native Projects
+
+Expo and React Native projects require special handling:
+
+**How to identify them:**
+- `app.json` with an `"expo"` key at root level
+- `app.config.js` or `app.config.ts` in project root
+- `metro.config.js` (React Native bundler config) in project root
+- `expo` listed as a dependency in `package.json`
+- `jest-expo` or `@testing-library/react-native` in devDependencies
+
+**Test commands:**
+- The typical test command is `npx jest` (NOT `npm test` unless a valid test script exists)
+- If `jest-expo` is in devDependencies, use `npx jest` -- the preset handles React Native transforms
+- If no test runner or test files are found, use `npx jest --passWithNoTests`
+- Some projects use `npx expo test` but `npx jest` is more reliable
+
+**Environment notes:**
+- Missing `expo` CLI globally is an environment issue, NOT a code issue -- do not reject for this
+- Expo projects use `npm install` or `yarn install` for dependencies (same as Node.js projects)
+- The `jest-expo` preset must be installed as a devDependency for tests to run
+
+## Monorepo / Multi-Directory Projects
+
+Many projects have subdirectory structures where the main application and tests live in a subdirectory:
+
+**Common patterns:**
+- `frontend/` — React/React Native/Expo app with its own `package.json`
+- `backend/` — API server (Django, Express, etc.)
+- `packages/*/` — npm/yarn workspaces
+- `apps/*/` — monorepo app directories
+
+**How to handle:**
+- Check the root `package.json` test script — it may delegate: `cd frontend && npx jest`
+- If the engineer provided a `[TEST_SETUP]` block in their completion comment, USE IT — it contains the verified test directory and command
+- If no test setup was provided, check immediate subdirectories for `package.json` with test scripts
+- Always run tests from the correct subdirectory — DO NOT assume tests run from root
+- `node_modules` may be in the subdirectory, not at root — check both locations
+
 ## Testing Approach
 
 1. **Identify the project's test framework** (jest, vitest, pytest, go test, cargo test, etc.)