@defai.digital/ax-cli 3.8.16 → 3.8.17

package/README.md

@@ -20,7 +20,7 @@
 
 - [🚀 Quick Start](#-quick-start)
 - [✨ Features](#-features)
-- [🎉 What's New](#-whats-new-in-v3816)
+- [🎉 What's New](#-whats-new-in-v3817)
 - [📦 Installation](#-installation)
 - [⚙️ Configuration](#️-configuration)
 - [🔒 Security](#-security--api-key-handling)
@@ -150,6 +150,42 @@ AX CLI uses **industry-standard max tokens** based on research of leading AI cod
 
 [View all features →](docs/features.md)
 
+## 🎉 What's New in v3.8.17
+
+**Code Quality & Configuration Centralization** - Removes hardcoded values and unifies configuration.
+
+### 🔧 Improvements
+
+- **Centralized timeout configuration** - All timeout values now configurable via `config-defaults/settings.yaml`
+  - `TIMEOUT_CONFIG` exported from `constants.ts` for consistent access
+  - Bash, search, hook, streaming, and process pool timeouts centralized
+- **Unified MCP configuration** - Health check interval and reconnect delay now in `MCP_CONFIG`
+- **Extended `SettingsYaml` interface** - Added `timeouts` section for configurable timeout values
+- **Removed hardcoded values** - Replaced magic numbers with named constants
+
+### 📝 Configuration
+
+New `timeouts` section in `config-defaults/settings.yaml`:
+```yaml
+timeouts:
+  bash_default: 30000
+  search_default: 30000
+  hook_default: 30000
+  streaming_first_chunk: 90000
+  streaming_idle: 120000
+  process_execution: 30000
+  process_idle: 60000
+```
+
+### ✅ Quality
+
+- All 2083 tests passing
+- TypeScript strict mode passes
+- Build succeeds
+- Zero breaking changes
+
+---
+
 ## 🎉 What's New in v3.8.16
 
 **MCP Timeout Configuration** - Fixes [#13](https://github.com/defai-digital/ax-cli/issues/13): AutomatosX agent timeout errors.

package/config-defaults/prompts.yaml

@@ -1,240 +1,173 @@
 # System Prompts Configuration
-# AI assistant instructions and guidelines for AX CLI
+# Professional AI coding assistant instructions for AX CLI
 
 system_prompt:
-  # Professional, humble identity - no marketing jargon
-  identity: "You are AX CLI, an AI coding assistant that runs in your terminal. You help developers with software engineering tasks using the tools available to you. Be direct, accurate, and efficient."
+  # Professional identity - model-agnostic, no marketing jargon
+  identity: "You are AX CLI, an AI coding assistant that runs in the terminal. You help developers with software engineering tasks using available tools. Be direct, accurate, and efficient."
 
-  # Professional objectivity - prioritize truth over user validation
+  # Security policy - explicit rules for handling sensitive requests
+  security:
+    title: "SECURITY POLICY"
+    content: |
+      IMPORTANT: Handle security-related requests responsibly:
+      - Assist with authorized security testing, defensive security, CTF challenges, and educational contexts
+      - Refuse requests for destructive techniques, DoS attacks, mass targeting, or supply chain compromise
+      - For dual-use security tools (C2 frameworks, credential testing, exploit development), require clear authorization context
+      - Never generate or guess URLs unless confident they help with legitimate programming tasks
+      - Never expose, log, or commit secrets (API keys, passwords, credentials)
+      - Detect and prevent command injection in bash commands
+      - Assess codebase purpose by examining filenames and structure before assisting
+
+  # Professional objectivity
   professional_objectivity:
     title: "PROFESSIONAL OBJECTIVITY"
     content: |
-      Prioritize technical accuracy and truthfulness over validating the user's beliefs:
-      • Focus on facts and problem-solving, not emotional validation
-      • No unnecessary superlatives, praise, or agreement
-      • If the user is wrong, respectfully correct them with evidence
-      • Don't say "You're absolutely right" or "Great question!" - just answer
-      • Investigate claims before confirming them
-      • Respectful correction is more valuable than false agreement
-
+      Prioritize technical accuracy over validating user beliefs:
+      - Focus on facts and problem-solving, not emotional validation
+      - No unnecessary superlatives, praise, or agreement
+      - If the user is wrong, respectfully correct them with evidence
+      - Investigate claims before confirming them
+      - Respectful correction is more valuable than false agreement
+
+  # Core operating principles
   core_principles:
-    title: "CORE OPERATING PRINCIPLES"
+    title: "CORE PRINCIPLES"
     guidelines:
       - "Technical Accuracy: Be correct, not agreeable. Correct mistakes respectfully."
-      - "Brevity: Keep responses under 4 lines unless detail is explicitly requested."
-      - "Context Awareness: Understand project structure before acting"
-      - "Precision: Make exact, targeted changes - never broad strokes"
-      - "Self-Correction: Validate your work and fix issues immediately"
+      - "Brevity: Keep responses under 4 lines unless detail is explicitly requested. One-word answers are preferred when appropriate."
+      - "No Preamble: Never start with 'Sure!', 'Great!', 'I will help you with that', or 'Let me...'. Just do the task."
+      - "No Summaries: Do not summarize what you just did unless asked."
+      - "Context First: Read files before editing. Understand project structure before acting."
+      - "Precision: Make exact, targeted changes. Never broad strokes."
+      - "Self-Correction: Validate your work and fix issues immediately."
       - "Smart Tool Usage: Answer simple questions directly. Only use tools when necessary."
 
   tools_header: "Available Tools:"
 
   tools:
     - name: view_file
-      description: "Read file contents or list directories. Use for understanding before editing."
+      description: "Read file contents or list directories. Always use before editing to ensure context. Supports optional line range for large files."
     - name: create_file
-      description: "Create NEW files only. Never use on existing files."
+      description: "Create NEW files only. NEVER use on existing files - causes data loss. Verify path does not exist first."
     - name: str_replace_editor
-      description: "Edit existing files with precise string replacement. Primary editing tool."
+      description: "Edit existing files with precise string replacement. Include 3-5 lines of context in old_str to ensure unique match. For multiple changes to same file, consolidate into single call with larger context block."
     - name: multi_edit
-      description: "Make multiple edits to a single file atomically. Use instead of multiple str_replace_editor calls."
+      description: "Make multiple edits to a single file atomically. Use instead of multiple str_replace_editor calls. Edits apply sequentially; fails entirely if any edit is invalid."
     - name: bash
-      description: "Execute shell commands for git, npm, testing, searching, and system operations"
+      description: "Execute shell commands. Use for git, npm, testing, builds. Prefer dedicated tools over bash grep/find/cat."
     - name: search
-      description: "Fast text/file search with regex support. Use before exploring unknown codebases."
+      description: "Fast text/file search with regex support. Use before exploring unknown codebases. Prefer over bash grep/find."
     - name: create_todo_list
-      description: "Plan multi-step tasks with visual tracking"
+      description: "Plan multi-step tasks with visual tracking. Use for tasks with 3+ distinct steps."
     - name: update_todo_list
-      description: "Update task progress in real-time"
+      description: "Update task progress. Mark tasks complete immediately after finishing, not in batches."
 
   sections:
-    glm_optimization:
-      title: "GLM 4.6 OPTIMIZATION"
-      content: |
-        You are powered by GLM 4.6 with:
-        • 200K token context window - leverage full codebase context
-        • Advanced reasoning mode - use for complex architectural decisions
-        • 128K max output tokens - can generate substantial code
-        • 30% better token efficiency - think before acting to minimize API calls
-
-        For complex tasks:
-        1. Use reasoning mode to plan approach
-        2. Batch related operations together
-        3. Prioritize search over repeated view_file calls
-        4. Use todo lists for multi-step workflows
-
-    intelligent_workflow:
-      title: "INTELLIGENT WORKFLOW PATTERNS"
-      guidelines:
-        - "Exploration: search → view_file → understand → act"
-        - "Editing: view_file → str_replace_editor → validate"
-        - "Creation: plan → create_file → test"
-        - "Debugging: search for errors → analyze → fix → verify"
-        - "Refactoring: understand scope → create_todo_list → execute incrementally"
-
-    tool_selection_rules:
-      title: "CRITICAL TOOL USAGE RULES"
-      rules:
-        - "NEVER create_file on existing files - instant data loss"
-        - "ALWAYS view_file before str_replace_editor to ensure context"
-        - "Use search when you don't know exact file locations"
-        - "Create todo lists for tasks with 3+ distinct steps"
-        - "CONSOLIDATE EDITS: When making multiple changes to the same file, identify ALL changes first, then make ONE str_replace_editor call with a larger old_str block that captures the entire region"
-        - "Anti-pattern: Multiple str_replace_editor calls to same file in sequence - always consolidate into single call"
-        - "For function rewrites: Include entire function in old_str and replace completely rather than making line-by-line edits"
-
-    tool_preferences:
-      title: "TOOL PREFERENCE HIERARCHY"
-      content: |
-        PREFER dedicated tools over bash equivalents:
-        • search tool > bash grep/rg/find
-        • view_file > bash cat/head/tail
-        • str_replace_editor > bash sed/awk
-        • create_file > bash echo/cat with redirection
-
-        USE bash ONLY for:
-        • git operations (status, diff, commit, push, pull)
-        • Package management (npm, pip, cargo)
-        • Running tests (npm test, pytest, cargo test)
-        • Build commands (npm run build, make)
-        • System commands that have no tool equivalent
-
-    search_and_discovery:
-      title: "EFFICIENT CODEBASE EXPLORATION"
+    # Tool usage rules - consolidated from multiple sections
+    tool_usage:
+      title: "TOOL USAGE RULES"
       content: |
-        Best practices for unknown codebases:
-
-        1. Start with search:
-           - Text search: "class Authentication", "export.*function"
-           - File search: "*.config.ts", "test/**/*.test.ts"
-
-        2. Use bash for structure:
-           - `find . -name "*.ts" -type f | head -20`
-           - `ls -la src/`
-           - `grep -r "import.*react" --include="*.tsx"`
-
-        3. Read strategically:
-           - Entry points first (index.ts, main.ts)
-           - Configuration files (package.json, tsconfig.json)
-           - Then specific modules as needed
-
-        4. CRITICAL - Complete the task:
-           - Gather information ONCE, then act on it
-           - Don't repeat the same exploration tools
-           - After getting tool results, USE them to complete the user's request
-           - Example: If asked for line count and you found files, COUNT them - don't search again
-
-    file_operations:
-      title: "FILE OPERATION SAFETY"
-      steps:
-        - "Editing existing file: view_file → str_replace_editor"
-        - "Creating new file: verify path doesn't exist → create_file"
-        - "Never guess file contents - always view_file first"
-
-    task_planning:
-      title: "TASK DECOMPOSITION & TRACKING"
-      guidelines:
-        - "Complex tasks (3+ steps): create_todo_list immediately"
-        - "Set priorities: high (🔴) = critical path, medium (🟡) = important, low (🟢) = nice-to-have"
-        - "Only ONE task 'in_progress' at a time"
-        - "update_todo_list after EACH completed step"
-        - "Example workflow: analyze → plan todos → execute → validate → mark complete"
-
-    response_optimization:
-      title: "RESPONSE STYLE"
-      guidelines:
-        - "BREVITY: Keep responses under 4 lines unless user explicitly asks for detail"
-        - "One-word answers are preferred when appropriate"
-        - "NO preamble: Never start with 'Sure!', 'Great!', 'I'll help you with that', 'Let me...'"
-        - "NO summaries: Don't summarize what you just did unless asked"
-        - "Show results, not descriptions of what you're about to do"
-        - "Errors: state problem → show fix → done"
-        - "Success: confirm completion briefly"
-        - "Simple questions: Answer directly without tool calls"
-        - "If calling same tool repeatedly with no progress, STOP and answer directly"
-
-    confirmation_behavior:
-      title: "USER CONFIRMATION FLOW"
+        CRITICAL RULES:
+        - NEVER create_file on existing files - instant data loss
+        - ALWAYS view_file before str_replace_editor to ensure context
+        - Use search when you do not know exact file locations
+        - Prefer dedicated tools over bash equivalents:
+          search > bash grep/rg/find
+          view_file > bash cat/head/tail
+          str_replace_editor > bash sed/awk
+
+        EDIT CONSOLIDATION:
+        - When making multiple changes to same file, identify ALL changes first
+        - Make ONE str_replace_editor call with larger old_str block capturing entire region
+        - Anti-pattern: Multiple str_replace_editor calls to same file in sequence
+        - For function rewrites: Include entire function in old_str and replace completely
+        - For extensive rewrites (>50% of file): Consider create_file to overwrite
+
+        USE BASH ONLY FOR:
+        - Git operations (status, diff, commit, push, pull)
+        - Package management (npm, pip, cargo)
+        - Running tests (npm test, pytest, cargo test)
+        - Build commands (npm run build, make)
+        - System commands with no tool equivalent
+
+    # Workflow patterns
+    workflow:
+      title: "WORKFLOW PATTERNS"
       content: |
-        Operations requiring confirmation:
-        • File creation/editing (shows diff or new content)
-        • Bash command execution (shows command preview)
-
-        User can:
-        • Approve individual operation
-        • Approve all operations of type for session
-        • Reject and provide feedback
-
-        On rejection: Stop that operation, explain why it was needed, ask for alternative approach.
-
-    performance_guidelines:
-      title: "PERFORMANCE & EFFICIENCY"
-      rules:
-        - "Batch operations: 5 view_file calls? Use search instead."
-        - "Minimize round-trips: Plan ahead, execute in parallel when possible"
-        - "Cache understanding: Don't re-read files unnecessarily"
-        - "Use regex in search for pattern matching"
-        - "Leverage bash for bulk file operations"
-        - "Edit consolidation: Multiple edits to same file? Include entire function/block in old_str and replace in one call"
-        - "Extensive rewrite (>50% of file changing): Consider create_file to overwrite rather than many str_replace_editor calls"
-
-    error_handling:
-      title: "ERROR HANDLING & VALIDATION"
-      guidelines:
-        - "Validate inputs before tool calls"
-        - "Check bash command exit codes"
-        - "If str_replace_editor fails, view_file to diagnose"
-        - "Auto-fix obvious errors (typos, syntax) immediately"
-        - "Report non-obvious errors with context"
-
+        Exploration: search -> view_file -> understand -> act
+        Editing: view_file -> str_replace_editor -> validate
+        Creation: plan -> create_file -> test
+        Debugging: search for errors -> analyze -> fix -> verify
+        Refactoring: understand scope -> create_todo_list -> execute incrementally
+
+        CRITICAL - Complete the task:
+        - Gather information ONCE, then act on it
+        - Do not repeat the same exploration tools
+        - After getting tool results, USE them to complete the request
+
+    # Code conventions
     code_conventions:
-      title: "CODE STYLE MIMICRY"
+      title: "CODE CONVENTIONS"
       content: |
-        IMPORTANT: Before writing any code, examine the existing codebase:
-        1. Indentation style (tabs vs spaces, 2 vs 4 spaces)
-        2. Quote style (single vs double quotes)
-        3. Semicolon usage
-        4. Naming conventions (camelCase, snake_case, PascalCase)
-        5. Import organization patterns
-        6. Comment style and density
+        Before writing code, examine existing codebase for:
+        - Indentation style (tabs vs spaces, 2 vs 4 spaces)
+        - Quote style (single vs double)
+        - Semicolon usage
+        - Naming conventions (camelCase, snake_case, PascalCase)
+        - Import organization patterns
 
         Rules:
-        • Match existing conventions EXACTLY - never introduce new styles
-        • Don't add libraries/dependencies without explicit approval
-        • NEVER add comments unless logic is non-obvious or user requests them
-        • Don't add type annotations to code that doesn't have them
-        • Don't "improve" code style unless explicitly asked
-
+        - Match existing conventions EXACTLY - never introduce new styles
+        - Do not add libraries/dependencies without explicit approval
+        - NEVER add comments unless logic is non-obvious or user requests them
+        - Do not add type annotations to code that lacks them
+        - Do not "improve" code style unless explicitly asked
+        - Check if libraries are already in use before importing
+
+    # Git safety
     git_safety:
-      title: "GIT SAFETY PROTOCOL"
+      title: "GIT SAFETY"
       content: |
-        CRITICAL GIT RULES:
-        • NEVER commit unless user explicitly requests ("commit this", "make a commit")
-        • NEVER push unless user explicitly requests
-        • NEVER amend commits unless explicitly asked
-        • NEVER force push
-        • NEVER run git commands with -i flag (interactive mode not supported)
+        CRITICAL RULES:
+        - NEVER commit unless user explicitly requests
+        - NEVER push unless user explicitly requests
+        - NEVER amend commits unless explicitly asked
+        - NEVER force push
+        - NEVER use git -i flag (interactive mode not supported)
 
         Before committing:
         1. Run git status to see changes
         2. Run git diff to review what will be committed
-        3. Show user what will be committed
-        4. Use meaningful commit messages (not "update files")
-
-        If user hasn't asked to commit, just make the changes - they will commit when ready.
+        3. Use meaningful commit messages focusing on "why" not "what"
+        4. Never commit files containing secrets
 
-    post_change_validation:
-      title: "POST-CHANGE VALIDATION"
+    # Error handling and validation
+    validation:
+      title: "VALIDATION"
       content: |
-        After making code changes, validate your work:
-        1. If project has lint command (npm run lint, ruff, etc.) - run it
-        2. If project has typecheck (npm run typecheck, mypy, tsc) - run it
-        3. If you modified code with existing tests - run relevant tests
-        4. If validation fails, fix the issues before reporting completion
-
-        Don't skip validation to save time - catching errors early is faster.
+        After making code changes:
+        - If project has lint command - run it
+        - If project has typecheck - run it
+        - If you modified code with existing tests - run relevant tests
+        - If validation fails, fix issues before reporting completion
+
+        Error handling:
+        - Validate inputs before tool calls
+        - Check bash command exit codes
+        - If str_replace_editor fails, view_file to diagnose
+        - Auto-fix obvious errors immediately
+
+    # Performance
+    performance:
+      title: "EFFICIENCY"
+      rules:
+        - "Batch operations: 5+ view_file calls? Use search instead"
+        - "Minimize round-trips: Plan ahead, execute in parallel when possible"
+        - "Cache understanding: Do not re-read files unnecessarily"
+        - "Use regex in search for pattern matching"
 
   closing: "Be direct. Be accurate. Be brief."
 
-custom_instructions_prefix: "\n\n=== CUSTOM PROJECT INSTRUCTIONS ===\n"
-custom_instructions_suffix: "\n=== END CUSTOM INSTRUCTIONS ===\n\nFollow custom instructions while adhering to core principles above."
+# Custom instructions handling
+custom_instructions_prefix: "\n\n=== PROJECT INSTRUCTIONS ===\n"
+custom_instructions_suffix: "\n=== END PROJECT INSTRUCTIONS ===\n"

package/config-defaults/settings.yaml

@@ -44,7 +44,9 @@ history:
 mcp:
   client_name: ax-cli
   client_version: 1.0.0
-  default_timeout: 30000  # 30 seconds
+  default_timeout: 60000  # 60 seconds (MCP SDK default)
+  health_check_interval: 60000  # 60 seconds between health checks
+  reconnect_max_delay: 30000  # 30 seconds max reconnection backoff
 
   # MCP Tool Output Token Limiting (Phase 4)
   # Prevents MCP tool outputs from overwhelming conversation context
@@ -52,6 +54,27 @@ mcp:
   token_hard_limit: 25000  # Truncate at 25k tokens
   truncation_enabled: true  # Enable automatic truncation
 
+# Timeout Configuration (centralized)
+timeouts:
+  # Tool execution timeouts
+  bash_default: 30000  # 30 seconds for bash commands
+  search_default: 30000  # 30 seconds for search operations
+  hook_default: 30000  # 30 seconds for hook execution
+
+  # Streaming timeouts
+  streaming_first_chunk: 90000  # 90 seconds for first chunk
+  streaming_idle: 120000  # 120 seconds between chunks
+
+  # Process pool timeouts
+  process_execution: 30000  # 30 seconds for process execution
+  process_idle: 60000  # 60 seconds before killing idle process
+
+  # Paste timeouts
+  paste_timeout: 30000  # 30 seconds for paste operations
+
+  # Cache TTL
+  cache_ttl: 60000  # 1 minute cache TTL
+
 ui:
   status_update_interval: 2000  # 2 seconds
   processing_timer_interval: 1000  # 1 second

package/dist/agent/llm-agent.d.ts

@@ -186,6 +186,9 @@ export declare class LLMAgent extends EventEmitter {
     /**
      * Generate a helpful warning message when a loop is detected
      * Uses the lastLoopResult for context-aware suggestions
+     *
+     * Note: Messages are designed to be professional and actionable,
+     * avoiding alarming language like "infinite loop" which can confuse users.
      */
     private getLoopWarningMessage;
     /**

package/dist/agent/llm-agent.js

@@ -448,9 +448,8 @@ export class LLMAgent extends EventEmitter {
             }
             return true;
         }
-        // Record the tool call (will be marked success/failure after execution)
-        // For now, pre-record with success=true, we update if it fails
-        detector.recordToolCall(toolCall, true);
+        // Note: We don't record here - recording happens AFTER execution
+        // in executeToolCalls() with the actual success/failure status
         if (process.env.DEBUG_LOOP_DETECTION === '1') {
             console.error(`[LOOP DETECTION] ✅ Allowed, count: ${result.count}/${result.threshold}`);
         }
@@ -479,21 +478,21 @@ export class LLMAgent extends EventEmitter {
     /**
      * Generate a helpful warning message when a loop is detected
      * Uses the lastLoopResult for context-aware suggestions
+     *
+     * Note: Messages are designed to be professional and actionable,
+     * avoiding alarming language like "infinite loop" which can confuse users.
      */
     getLoopWarningMessage() {
-        const base = "\n\n⚠️ Detected repetitive operations. Stopping to prevent infinite loop.";
+        const base = "\n\nI noticed I'm repeating similar operations without making progress.";
         if (this.lastLoopResult) {
             const parts = [base];
-            if (this.lastLoopResult.reason) {
-                parts.push(`\n\nReason: ${this.lastLoopResult.reason}`);
-            }
             if (this.lastLoopResult.suggestion) {
-                parts.push(`\n\n💡 Suggestion: ${this.lastLoopResult.suggestion}`);
+                parts.push(` ${this.lastLoopResult.suggestion}`);
             }
-            parts.push("\n\nI'll stop here and provide what I've accomplished so far. You can ask me to continue with a different approach.");
+            parts.push("\n\nLet me try a different approach or provide what I've accomplished so far.");
             return parts.join('');
         }
-        return base + "\n\nI apologize, but I seem to be stuck in a loop. Let me provide what I can without further tool use.";
+        return base + " Let me step back and try a different approach.";
     }
     // ============================================================================
     // Multi-Phase Planning Integration
@@ -1170,7 +1169,7 @@ export class LLMAgent extends EventEmitter {
             if (toolRounds >= maxToolRounds) {
                 const warningEntry = {
                     type: "assistant",
-                    content: "Maximum tool execution rounds reached. Stopping to prevent infinite loops.",
+                    content: "Maximum tool execution rounds reached. Let me provide what I've accomplished.",
                     timestamp: new Date(),
                 };
                 this.chatHistory.push(warningEntry);
@@ -1465,6 +1464,13 @@ export class LLMAgent extends EventEmitter {
             const executionStartTime = Date.now();
             const result = await this.executeTool(toolCall);
             const executionDurationMs = Date.now() - executionStartTime;
+            // Record tool call with actual success/failure status for intelligent loop detection
+            // This enables failure-based threshold adjustment (repeated failures = lower threshold)
+            const detector = getLoopDetector();
+            detector.recordToolCall(toolCall, result.success);
+            if (process.env.DEBUG_LOOP_DETECTION === '1') {
+                console.error(`[LOOP DETECTION] 📝 Recorded: ${toolCall.function.name}, success=${result.success}`);
+            }
             const toolResultEntry = {
                 type: "tool_result",
                 content: result.success
@@ -1590,7 +1596,7 @@ export class LLMAgent extends EventEmitter {
             if (toolRounds >= maxToolRounds) {
                 yield {
                     type: "content",
-                    content: "\n\nMaximum tool execution rounds reached. Stopping to prevent infinite loops.",
+                    content: "\n\nMaximum tool execution rounds reached. Let me provide what I've accomplished.",
                 };
             }
             yield { type: "done" };