ayder-cli 2.5.3__tar.gz → 2.5.4__tar.gz

{ayder_cli-2.5.3 → ayder_cli-2.5.4}/.gitignore

@@ -32,3 +32,4 @@ TODO
 .crush
 .gemini
 .vscode
+docs/superpowers/

{ayder_cli-2.5.3 → ayder_cli-2.5.4}/AGENTS.md

@@ -17,27 +17,33 @@ This document provides coding standards, tool configurations, and workflows for
 | Package | Purpose | Version |
 |---------|---------|---------|
 | **openai** | OpenAI-compatible API client for LLM calls | latest |
-| **textual** | Terminal User Interface (TUI) framework | >=0.50.0 |
+| **ollama** | Native Ollama API client (Ollama provider) | >=0.6.2 |
+| **loguru** | Logging backend (channel loggers, masking sinks) | >=0.7,<0.8 |
+| **httpx** | HTTP client for `fetch_web` | latest |
+| **mcp** | Model Context Protocol client (built-in MCP) | >=1.19,<2 |
 | **rich** | Rich text and beautiful formatting | >=13.0.0 |
-| **prompt-toolkit** | Interactive CLI prompts and auto-completion | latest |
+| **textual** | Terminal User Interface (TUI) framework | ==8.2.7 |
 | **python-dotenv** | Environment variable management | >=1.0.0 |
-| **httpx** | Async HTTP client (Ollama API, fetch_web) | latest |
+| **tiktoken** | Token counting for context management | >=0.7.0 |
+
+Optional extras: `anthropic`, `google` (google-genai), `qwen` (dashscope), `glm` (zhipuai>=2, with pydantic<2.14 because zhipuai holds mcp at 1.19.0), `all` (the four provider extras), `libcst` (for plugins that do CST code transforms); `mcp` is an empty compatibility extra.
 
 ### Development Dependencies
 
 | Package | Purpose | Version |
 |---------|---------|---------|
-| **pytest** | Testing framework | >=9.0.2 |
-| **pytest-xdist** | Parallel test execution | >=3.5.0 |
-| **pytest-timeout** | Test timeout protection | >=2.2.0 |
+| **pytest** | Testing framework | >=9.0.3 |
+| **pytest-cov** | Code coverage | >=7.1.0 |
+| **pytest-xdist** | Parallel test execution | >=3.8.0 |
+| **pytest-timeout** | Test timeout protection | >=2.4.0 |
 | **pytest-instafail** | Show failures immediately | >=0.5.0 |
-| **pytest-sugar** | Beautiful progress bar | >=1.0.0 |
-| **pytest-cov** | Code coverage | >=7.0.0 |
-| **ruff** | Fast Python linter | latest |
-| **mypy** | Static type checker | latest |
-| **pyright** | Static type checker (Microsoft) | >=1.1.0 |
-| **uv** | Fast Python package manager | >=0.10.0 |
-| **poethepoet** | Task runner | >=0.24.0 |
+| **pytest-asyncio** | Async test support | >=1.3.0 |
+| **poethepoet** | Task runner | >=0.44.0 |
+| **ruff** | Fast Python linter | >=0.15.12 |
+| **mypy** | Static type checker | >=1.20.2 |
+| **pyright** | Static type checker (Microsoft) | >=1.1.409 |
+
+The dev group also installs the optional provider SDKs (`anthropic`, `google-genai`, `dashscope`, `zhipuai>=2`) so their tests run.
 
 ### Build System
 
@@ -211,7 +217,7 @@ This project uses `uv` as the package manager with a pre-configured `.venv`:
 Poe the Poet is the preferred task runner. It automatically uses the `.venv`:
 
 ```bash
-# Run tests (excludes slow TUI tests) - uses pytest-timeout, instafail, sugar
+# Run tests (excludes slow TUI tests) - uses pytest-timeout
 uv run --active poe test
 
 # Run tests in parallel (fastest - uses pytest-xdist)
@@ -248,7 +254,7 @@ uv run poe --help
 **Pytest Plugins Used:**
 - **pytest-timeout** (30s) - Prevents tests from hanging
 - **pytest-instafail** - Shows failures immediately
-- **pytest-sugar** - Beautiful progress bar
+- **pytest-asyncio** - Async test support
 - **pytest-xdist** (-n auto) - Parallel execution (test-fast only)
 - **pytest-cov** - Coverage reporting (test-cov only)
 
@@ -343,10 +349,15 @@ uv run ruff check src/ --fix
 
 ### Ruff Standards
 
-- **F Rules**: Pyflakes (undefined names, unused imports)
-- **E/W Rules**: pycodestyle (formatting)
-- **I Rules**: isort (import sorting)
-- **N Rules**: pep8-naming (naming conventions)
+The rule set is `select` under `[tool.ruff.lint]` in pyproject.toml:
+
+- **E4, E7, E9**: pycodestyle import, statement and runtime-error rules (no formatting rules)
+- **F**: Pyflakes (undefined names, unused imports)
+- **TRY400, TRY401**: tryceratops `error-instead-of-exception` and `verbose-log-message`
+- **BLE001**: flake8-blind-except `blind-except`
+- **LOG, G**: flake8-logging and flake8-logging-format
+
+`tests/**/*.py` ignores `BLE001` and `G004`. `poe lint` checks `src/` only.
 
 **Before committing, ensure:**
 ```bash

{ayder_cli-2.5.3 → ayder_cli-2.5.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: ayder-cli
-Version: 2.5.3
+Version: 2.5.4
 Summary: AI agent for any LLMs
 Project-URL: Homepage, https://github.com/ayder/ayder-cli
 Project-URL: Repository, https://github.com/ayder/ayder-cli.git
@@ -27,10 +27,12 @@ Provides-Extra: all
 Requires-Dist: anthropic; extra == 'all'
 Requires-Dist: dashscope; extra == 'all'
 Requires-Dist: google-genai; extra == 'all'
+Requires-Dist: pydantic<2.14; extra == 'all'
 Requires-Dist: zhipuai>=2; extra == 'all'
 Provides-Extra: anthropic
 Requires-Dist: anthropic; extra == 'anthropic'
 Provides-Extra: glm
+Requires-Dist: pydantic<2.14; extra == 'glm'
 Requires-Dist: zhipuai>=2; extra == 'glm'
 Provides-Extra: google
 Requires-Dist: google-genai; extra == 'google'
@@ -83,7 +85,7 @@ LLMs on their own can only generate text. To be a useful coding assistant, the m
 Each tool has an OpenAI-compatible JSON schema so models that support function calling can use them natively. For models that don't, ayder-cli also parses a custom XML-like syntax (`<function=name><parameter=key>value</parameter></function>`) as a fallback.
 
 - **Path sandboxing**: All file operations are confined to the project root via `ProjectContext`. Path traversal attacks (`../`) and absolute paths outside the project are blocked. The one exception is the session scratch directory, `/tmp/ayder-<uid>/<project>-<hash>/<session>/` (mode 0700, one subdirectory per agent run), which the system prompt names as the place for temporary files and which the file tools accept. It is not cleaned up; the OS clears `/tmp`.
-- **Safe mode** (TUI): Blocks `file_editor`, `run_shell_command`, `run_background_process`, `kill_background_process`, and `fetch_web`.
+- **Safe mode** (TUI): Blocks `file_editor`, `bash`, `background_process`, and `fetch_web`.
 - Every tool call requires your confirmation before it runs -- you always stay in control. Use `-r`, `-w`, `-x` flags to auto-approve tool categories.
 - You may also prefer to run ayder-cli in a container for additional security.
 
@@ -203,9 +205,9 @@ provider = "openai"           # Active provider profile name
 editor = "vim"                # Editor for /task-edit command
 verbose = false               # Show file contents after write + LLM debug
 max_background_processes = 5  # Max concurrent background processes (1-20)
-max_iterations = 200          # LLM calls per message before the loop stops (0 = unlimited)
+max_iterations = 0            # LLM calls per message before the loop stops (default 0 = unlimited)
 max_output_tokens = 32768     # Max tokens in LLM response
-max_history_messages = 30     # Messages kept in history
+max_history_messages = 0      # Messages kept in history (default 0 = unlimited)
 prompt = "STANDARD"           # System prompt tier: MINIMAL, STANDARD, EXTENDED
 tool_tags = ["core", "metadata"]  # Enabled tool tags (see /plugin)
 # skills = ["development-workflow"]    # or "none"; default: the built-in skills
@@ -234,12 +236,6 @@ retention     = "7 days"
 enabled = true
 max_context_tokens = 8192
 
-[temporal]
-enabled = false
-host = "localhost:7233"
-namespace = "default"
-metadata_dir = ".ayder/temporal"
-
 # --- Provider Profiles ---
 
 [llm.my_local_ollama]
@@ -381,9 +377,9 @@ By default, every tool call requires user confirmation. Use permission flags to
 
 | Flag | Category | Built-in tools |
 | ---- | -------- | -------------- |
-| `-r` | Read | `file_explorer`, `read_file`, `search_codebase`, `get_project_structure`, `get_background_output`, `list_background_processes`, `list_tasks`, `show_task` |
-| `-w` | Write | `file_editor`, `context`, `create_note`, `manage_environment_vars` |
-| `-x` | Execute | `run_shell_command`, `run_background_process`, `kill_background_process` |
+| `-r` | Read | `file_explorer`, `read_file`, `search_codebase`, `get_project_structure`, `skill`, `agent` (when agents are configured) |
+| `-w` | Write | `file_editor`, `context`, `note`, `task`, `manage_environment_vars` |
+| `-x` | Execute | `bash`, `background_process` |
 | `--http` | Web/Network | `fetch_web` |
 
 Installed plugins extend these categories (e.g. `python_editor` → write, virtualenv tools → execute, `dbs_tool` → web).
@@ -463,7 +459,6 @@ You can also manually manage context with the `context` tool and its slash-comma
 | `/list-contexts` | List saved context slots |
 | `/context-stats` | Show current token and KV-cache usage |
 | `/archive-completed-tasks` | Move completed tasks to `.ayder/task_archive/` |
-| `/temporal` | Start/status Temporal queue worker |
 | `/agent list` | List configured agents and their current status |
 | `/agent <name> <task>` | Dispatch an agent to run a task in the background |
 | `/agent cancel <name>` | Cancel a running agent |
@@ -543,7 +538,7 @@ inside the Ollama summary.
 
 ayder-cli is optimized for both large and small (local) LLMs:
 
-- **Dynamic Tool Loading**: Only `core` and `metadata` tools are loaded by default. Use `/plugin` to enable specialized toolsets (venv, python, http, background, dbs, temporal, env) only when needed.
+- **Dynamic Tool Loading**: Only `core` and `metadata` tools are loaded by default. Use `/plugin` to enable specialized toolsets (venv, python, http, background, dbs, env) only when needed.
 - **Tiered Prompts**: Use `prompt = "MINIMAL"` in config for smaller models (7B-14B) to strip complex reasoning frameworks and improve follow-through.
 - **Automatic Context Bounding**: Conversation history is bounded based on `max_history_messages` to prevent context rot.
 - **Tool System Prompts**: Tool-specific prompt blocks (e.g., DBS instructions) are only injected when their tag is enabled, keeping the system prompt lean.
@@ -610,23 +605,24 @@ The tool system:
 - Supports tag-based filtering for dynamic enable/disable
 - Injects tool-specific system prompts when enabled
 
-**Built-in tools (16):**
+**Built-in tools (13):**
 
 | Category | Tools |
 |----------|-------|
 | **Filesystem** | `file_explorer`, `read_file`, `file_editor` |
 | **Search** | `search_codebase`, `get_project_structure` |
-| **Shell** | `run_shell_command` |
+| **Shell** | `bash` |
 | **Context** | `context` (save / load / list / stats / clear session context slots) |
-| **Notes** | `create_note` |
-| **Background Processes** | `run_background_process`, `get_background_output`, `kill_background_process`, `list_background_processes` |
-| **Tasks** | `list_tasks`, `show_task` |
+| **Notes** | `note` (create / read / update / list / delete) |
+| **Background Processes** | `background_process` (start / logs / stop / list / info) |
+| **Tasks** | `task` (create / list / show / status / update_status / update / update_dependencies) |
+| **Skills** | `skill` (list / load / read / unload) |
 | **Environment** | `manage_environment_vars` |
 | **Web** | `fetch_web` |
 
-When agents are configured, the `call_agent` tool is also registered so the main LLM can dispatch them (see [Multi-Agent System](#multi-agent-system)).
+When agents are configured, the `agent` tool is also registered so the main LLM can dispatch them (see [Multi-Agent System](#multi-agent-system)).
 
-**Plugin tools** — `python_editor`, `dbs_tool`, `temporal_workflow`, virtualenv tools, and MCP integrations ship as optional plugins in the [ayder/ayder-plugins](https://github.com/ayder/ayder-plugins) repo (see [Plugins](#plugins)). Once installed they are auto-discovered exactly like built-ins.
+**Plugin tools** — `python_editor`, `dbs_tool`, virtualenv tools, and MCP integrations ship as optional plugins in the [ayder/ayder-plugins](https://github.com/ayder/ayder-plugins) repo (see [Plugins](#plugins)). Once installed they are auto-discovered exactly like built-ins.
 
 ## Multi-Agent System
 
@@ -637,7 +633,7 @@ ayder-cli supports user-defined **specialized agents**: each agent is an indepen
 ```
 Main LLM (your conversation)
     │
-    ├─ calls `call_agent` tool  ─────────────────────────────────┐
+    ├─ calls `agent` tool  ──────────────────────────────────────┐
     │   OR you type `/agent <name> <task>`                       │
     │                                                            ▼
     │                                            AgentRunner (background asyncio task)
@@ -661,10 +657,10 @@ pre_iteration_hook drains queue
 
 Key properties:
 - **Separate context** — agents have no access to the main conversation history. They receive only their system prompt and the task description.
-- **Non-blocking** — dispatching an agent returns immediately. Both `/agent` and `call_agent` are fire-and-forget.
+- **Non-blocking** — dispatching an agent returns immediately. Both `/agent` and the `agent` tool are fire-and-forget.
 - **Concurrent** — multiple agents can run simultaneously, each in its own async task.
 - **Summary injection** — when an agent finishes, its structured `<agent-summary>` block is injected as a system message into the main LLM's context at the start of the next turn.
-- **Timeout** — agents are automatically cancelled after `agent_timeout` seconds (default: 300).
+- **Timeout** — agents are automatically cancelled after `agent_timeout` seconds (default: 600).
 
 ### Configuring Agents
 
@@ -733,14 +729,14 @@ Each agent field:
 
 **Via the main LLM (automatic):**
 
-When agents are configured, the main LLM is told about them via its system prompt and can call `call_agent` autonomously:
+When agents are configured, the main LLM is told about them via its system prompt and can call the `agent` tool autonomously:
 
 ```
 You: Review the authentication module and write tests for it.
 
 LLM: I'll dispatch two agents to handle this in parallel.
-     [calls call_agent: name="code-reviewer", task="Review src/auth.py..."]
-     [calls call_agent: name="test-writer", task="Write tests for src/auth.py..."]
+     [calls agent: action="call", name="code-reviewer", task="Review src/auth.py..."]
+     [calls agent: action="call", name="test-writer", task="Write tests for src/auth.py..."]
 
      Both agents are running in the background. I'll incorporate
      their findings when they complete.
@@ -816,7 +812,7 @@ built-in support; your existing `.ayder/mcp.json` continues to work. The legacy
 
 ## Plugins
 
-Official plugins (venv, python, dbs, temporal) are maintained in the **[ayder/ayder-plugins](https://github.com/ayder/ayder-plugins)** repository. Install any plugin directly from GitHub:
+Official plugins (venv, python, dbs) are maintained in the **[ayder/ayder-plugins](https://github.com/ayder/ayder-plugins)** repository. Install any plugin directly from GitHub:
 
 ```bash
 ayder install-plugin https://github.com/ayder/ayder-plugins/tree/main/venv-tools

{ayder_cli-2.5.3 → ayder_cli-2.5.4}/README.md

@@ -40,7 +40,7 @@ LLMs on their own can only generate text. To be a useful coding assistant, the m
 Each tool has an OpenAI-compatible JSON schema so models that support function calling can use them natively. For models that don't, ayder-cli also parses a custom XML-like syntax (`<function=name><parameter=key>value</parameter></function>`) as a fallback.
 
 - **Path sandboxing**: All file operations are confined to the project root via `ProjectContext`. Path traversal attacks (`../`) and absolute paths outside the project are blocked. The one exception is the session scratch directory, `/tmp/ayder-<uid>/<project>-<hash>/<session>/` (mode 0700, one subdirectory per agent run), which the system prompt names as the place for temporary files and which the file tools accept. It is not cleaned up; the OS clears `/tmp`.
-- **Safe mode** (TUI): Blocks `file_editor`, `run_shell_command`, `run_background_process`, `kill_background_process`, and `fetch_web`.
+- **Safe mode** (TUI): Blocks `file_editor`, `bash`, `background_process`, and `fetch_web`.
 - Every tool call requires your confirmation before it runs -- you always stay in control. Use `-r`, `-w`, `-x` flags to auto-approve tool categories.
 - You may also prefer to run ayder-cli in a container for additional security.
 
@@ -160,9 +160,9 @@ provider = "openai"           # Active provider profile name
 editor = "vim"                # Editor for /task-edit command
 verbose = false               # Show file contents after write + LLM debug
 max_background_processes = 5  # Max concurrent background processes (1-20)
-max_iterations = 200          # LLM calls per message before the loop stops (0 = unlimited)
+max_iterations = 0            # LLM calls per message before the loop stops (default 0 = unlimited)
 max_output_tokens = 32768     # Max tokens in LLM response
-max_history_messages = 30     # Messages kept in history
+max_history_messages = 0      # Messages kept in history (default 0 = unlimited)
 prompt = "STANDARD"           # System prompt tier: MINIMAL, STANDARD, EXTENDED
 tool_tags = ["core", "metadata"]  # Enabled tool tags (see /plugin)
 # skills = ["development-workflow"]    # or "none"; default: the built-in skills
@@ -191,12 +191,6 @@ retention     = "7 days"
 enabled = true
 max_context_tokens = 8192
 
-[temporal]
-enabled = false
-host = "localhost:7233"
-namespace = "default"
-metadata_dir = ".ayder/temporal"
-
 # --- Provider Profiles ---
 
 [llm.my_local_ollama]
@@ -338,9 +332,9 @@ By default, every tool call requires user confirmation. Use permission flags to
 
 | Flag | Category | Built-in tools |
 | ---- | -------- | -------------- |
-| `-r` | Read | `file_explorer`, `read_file`, `search_codebase`, `get_project_structure`, `get_background_output`, `list_background_processes`, `list_tasks`, `show_task` |
-| `-w` | Write | `file_editor`, `context`, `create_note`, `manage_environment_vars` |
-| `-x` | Execute | `run_shell_command`, `run_background_process`, `kill_background_process` |
+| `-r` | Read | `file_explorer`, `read_file`, `search_codebase`, `get_project_structure`, `skill`, `agent` (when agents are configured) |
+| `-w` | Write | `file_editor`, `context`, `note`, `task`, `manage_environment_vars` |
+| `-x` | Execute | `bash`, `background_process` |
 | `--http` | Web/Network | `fetch_web` |
 
 Installed plugins extend these categories (e.g. `python_editor` → write, virtualenv tools → execute, `dbs_tool` → web).
@@ -420,7 +414,6 @@ You can also manually manage context with the `context` tool and its slash-comma
 | `/list-contexts` | List saved context slots |
 | `/context-stats` | Show current token and KV-cache usage |
 | `/archive-completed-tasks` | Move completed tasks to `.ayder/task_archive/` |
-| `/temporal` | Start/status Temporal queue worker |
 | `/agent list` | List configured agents and their current status |
 | `/agent <name> <task>` | Dispatch an agent to run a task in the background |
 | `/agent cancel <name>` | Cancel a running agent |
@@ -500,7 +493,7 @@ inside the Ollama summary.
 
 ayder-cli is optimized for both large and small (local) LLMs:
 
-- **Dynamic Tool Loading**: Only `core` and `metadata` tools are loaded by default. Use `/plugin` to enable specialized toolsets (venv, python, http, background, dbs, temporal, env) only when needed.
+- **Dynamic Tool Loading**: Only `core` and `metadata` tools are loaded by default. Use `/plugin` to enable specialized toolsets (venv, python, http, background, dbs, env) only when needed.
 - **Tiered Prompts**: Use `prompt = "MINIMAL"` in config for smaller models (7B-14B) to strip complex reasoning frameworks and improve follow-through.
 - **Automatic Context Bounding**: Conversation history is bounded based on `max_history_messages` to prevent context rot.
 - **Tool System Prompts**: Tool-specific prompt blocks (e.g., DBS instructions) are only injected when their tag is enabled, keeping the system prompt lean.
@@ -567,23 +560,24 @@ The tool system:
 - Supports tag-based filtering for dynamic enable/disable
 - Injects tool-specific system prompts when enabled
 
-**Built-in tools (16):**
+**Built-in tools (13):**
 
 | Category | Tools |
 |----------|-------|
 | **Filesystem** | `file_explorer`, `read_file`, `file_editor` |
 | **Search** | `search_codebase`, `get_project_structure` |
-| **Shell** | `run_shell_command` |
+| **Shell** | `bash` |
 | **Context** | `context` (save / load / list / stats / clear session context slots) |
-| **Notes** | `create_note` |
-| **Background Processes** | `run_background_process`, `get_background_output`, `kill_background_process`, `list_background_processes` |
-| **Tasks** | `list_tasks`, `show_task` |
+| **Notes** | `note` (create / read / update / list / delete) |
+| **Background Processes** | `background_process` (start / logs / stop / list / info) |
+| **Tasks** | `task` (create / list / show / status / update_status / update / update_dependencies) |
+| **Skills** | `skill` (list / load / read / unload) |
 | **Environment** | `manage_environment_vars` |
 | **Web** | `fetch_web` |
 
-When agents are configured, the `call_agent` tool is also registered so the main LLM can dispatch them (see [Multi-Agent System](#multi-agent-system)).
+When agents are configured, the `agent` tool is also registered so the main LLM can dispatch them (see [Multi-Agent System](#multi-agent-system)).
 
-**Plugin tools** — `python_editor`, `dbs_tool`, `temporal_workflow`, virtualenv tools, and MCP integrations ship as optional plugins in the [ayder/ayder-plugins](https://github.com/ayder/ayder-plugins) repo (see [Plugins](#plugins)). Once installed they are auto-discovered exactly like built-ins.
+**Plugin tools** — `python_editor`, `dbs_tool`, virtualenv tools, and MCP integrations ship as optional plugins in the [ayder/ayder-plugins](https://github.com/ayder/ayder-plugins) repo (see [Plugins](#plugins)). Once installed they are auto-discovered exactly like built-ins.
 
 ## Multi-Agent System
 
@@ -594,7 +588,7 @@ ayder-cli supports user-defined **specialized agents**: each agent is an indepen
 ```
 Main LLM (your conversation)
     │
-    ├─ calls `call_agent` tool  ─────────────────────────────────┐
+    ├─ calls `agent` tool  ──────────────────────────────────────┐
     │   OR you type `/agent <name> <task>`                       │
     │                                                            ▼
     │                                            AgentRunner (background asyncio task)
@@ -618,10 +612,10 @@ pre_iteration_hook drains queue
 
 Key properties:
 - **Separate context** — agents have no access to the main conversation history. They receive only their system prompt and the task description.
-- **Non-blocking** — dispatching an agent returns immediately. Both `/agent` and `call_agent` are fire-and-forget.
+- **Non-blocking** — dispatching an agent returns immediately. Both `/agent` and the `agent` tool are fire-and-forget.
 - **Concurrent** — multiple agents can run simultaneously, each in its own async task.
 - **Summary injection** — when an agent finishes, its structured `<agent-summary>` block is injected as a system message into the main LLM's context at the start of the next turn.
-- **Timeout** — agents are automatically cancelled after `agent_timeout` seconds (default: 300).
+- **Timeout** — agents are automatically cancelled after `agent_timeout` seconds (default: 600).
 
 ### Configuring Agents
 
@@ -690,14 +684,14 @@ Each agent field:
 
 **Via the main LLM (automatic):**
 
-When agents are configured, the main LLM is told about them via its system prompt and can call `call_agent` autonomously:
+When agents are configured, the main LLM is told about them via its system prompt and can call the `agent` tool autonomously:
 
 ```
 You: Review the authentication module and write tests for it.
 
 LLM: I'll dispatch two agents to handle this in parallel.
-     [calls call_agent: name="code-reviewer", task="Review src/auth.py..."]
-     [calls call_agent: name="test-writer", task="Write tests for src/auth.py..."]
+     [calls agent: action="call", name="code-reviewer", task="Review src/auth.py..."]
+     [calls agent: action="call", name="test-writer", task="Write tests for src/auth.py..."]
 
      Both agents are running in the background. I'll incorporate
      their findings when they complete.
@@ -773,7 +767,7 @@ built-in support; your existing `.ayder/mcp.json` continues to work. The legacy
 
 ## Plugins
 
-Official plugins (venv, python, dbs, temporal) are maintained in the **[ayder/ayder-plugins](https://github.com/ayder/ayder-plugins)** repository. Install any plugin directly from GitHub:
+Official plugins (venv, python, dbs) are maintained in the **[ayder/ayder-plugins](https://github.com/ayder/ayder-plugins)** repository. Install any plugin directly from GitHub:
 
 ```bash
 ayder install-plugin https://github.com/ayder/ayder-plugins/tree/main/venv-tools

{ayder_cli-2.5.3 → ayder_cli-2.5.4}/docs/GATE.md

@@ -12,7 +12,7 @@ Input: the candidate SHA.
    gates and the test suite, and stops at the first failing task.
 4. Copy the final pytest summary line (`=== N passed, M skipped in …s ===`) verbatim.
 
-Last measured: `3026 passed, 2 skipped` on `feat/tui-tweaks` (2026-11-13, release 2.5.3).
+Last measured: `3042 passed, 2 skipped` on `fix/various-scopes` (2026-11-14, release 2.5.4).
 
 ## Report format
 

{ayder_cli-2.5.3 → ayder_cli-2.5.4}/docs/PROJECT_STRUCTURE.md

@@ -97,7 +97,7 @@ ayder-cli is an AI agent chat client with a modular, layered architecture:
 1. **Layered Architecture**: Clear separation between entry → app → service → core → tools
 2. **Protocol-Based**: `ChatCallbacks` protocol decouples the chat loop from UI concerns; `InteractionSink` decouples LLM providers from UI for debug events
 3. **Single Composition Root**: `application/runtime_factory.create_runtime()` assembles all dependencies — no duplicated wiring between CLI and TUI
-4. **Single Loop**: `ChatLoop` (in `loops/chat_loop.py`) owns the full async LLM + tool execution loop; both CLI and TUI route through it. A run ends on a text-only reply, a cancel, an error, `max_iterations` LLM calls (`[app]` 200, agents 100), or 3 reasoning-only replies in a row; from the 3rd identical tool call in a row, the result carries a `[harness]` note
+4. **Single Loop**: `ChatLoop` (in `loops/chat_loop.py`) owns the full async LLM + tool execution loop; both CLI and TUI route through it. A run ends on a text-only reply, a cancel, an error, `max_iterations` LLM calls when set (default 0 = unlimited; `[agents.<name>]` does not inherit `[app]`), or 3 reasoning-only replies in a row; from the 3rd identical tool call in a row, the result carries a `[harness]` note
 5. **Single Execution Path**: `ExecutionPolicy.execute_with_registry()` is the sole tool execution entry point; validation → permission → execute, no inline policy in loop code
 6. **Single Validation Path**: `ValidationAuthority → SchemaValidator` is the only validation stage; schema derived from live `TOOL_DEFINITIONS` registry (no hardcoded lists)
 7. **Sandboxed Paths**: All file operations go through `ProjectContext` for security (project root plus the session scratch directory from `new_scratch_dir`). Only a path outside the sandbox (`PathOutsideSandboxError`) is reported as a security error; other bad input, such as a binary file or a non-numeric line number, is a validation error
@@ -187,13 +187,13 @@ cli.py:main()
 | `agents/callbacks.py` | `AgentCallbacks` — `ChatCallbacks` for autonomous agents |
 | `agents/runner.py` | `AgentRunner` — wraps one `ChatLoop` per agent dispatch |
 | `agents/registry.py` | `AgentRegistry` — dispatch, cancel, status, capability prompts |
-| `agents/tool.py` | `call_agent` tool definition + handler factory |
+| `agents/tool.py` | `agent` tool definition (`action`: call / list / status / read_result) + handler factory |
 
 **Agent dispatch flow (Approach A — all non-blocking):**
 1. Config parsed → `AgentConfig` objects in `Config.agents`
 2. `AyderApp.__init__` creates `AgentRegistry` if agents configured
-3. LLM calls `call_agent` tool → `registry.dispatch()` (sync, fire-and-forget)
-4. User runs `/agent <name> <task>` → same `registry.dispatch()`
+3. LLM calls the `agent` tool with `action="call"` → `registry.create_run()` (sync, fire-and-forget)
+4. User runs `/agent <name> <task>` → same `registry.create_run()`
 5. Agent runs `ChatLoop` with isolated runtime + `AgentCallbacks` in background
 6. Summary parsed from `<agent-summary>` block → `AgentSummary` → `_summary_queue`
 7. `pre_iteration_hook` drains queue → injects summaries as system messages
@@ -274,9 +274,6 @@ drivers, the registry, or `OllamaProvider` are required.
 | `deepseek.py` | deepseek-r1/v3/coder `<function_calls><invoke>` format |
 | `minimax.py` | MiniMax-M1 namespaced `<minimax:tool_call>` format |
 
-See `docs/superpowers/specs/2026-05-02-ollama-chat-drivers-design.md` for
-the design rationale.
-
 ### Tool Modules
 
 | Module | Purpose | Key Classes/Functions |
@@ -295,12 +292,14 @@ the design rationale.
 | `tools/builtins/search.py` | Search tool impls | `search_codebase()`, `get_project_structure()` |
 | `tools/builtins/shell.py` | Shell execution impl: own session, closed stdin, prompts/pagers off (`GIT_TERMINAL_PROMPT=0`, `PAGER`/`GIT_PAGER=cat`; `environment` overrides), process-group kill on timeout with partial output, per-stream output bounds | `bash()` |
 | `tools/builtins/context.py` | Session context snapshots | `context` |
-| `tools/builtins/notes.py` | Note-taking tool | `create_note()` |
-| `tools/builtins/tasks.py` | Task-management tools | `list_tasks()`, `show_task()` |
+| `tools/builtins/note_tool.py` | `note` tool (`action`: create / read / update / list / delete) | `note()` |
+| `tools/builtins/notes.py` | Note file helpers used by the `note` tool | `write_note_file()`, `read_note_file()`, `update_note_file()`, `list_note_ids()`, `delete_note_file()` |
+| `tools/builtins/task_tool.py` | `task` tool (`action`: create / list / show / status / update_status / update / update_dependencies) | `task()` |
+| `tools/builtins/tasks.py` | Task file helpers used by the `task` tool and `TaskRunner` | `create_task()`, `list_tasks()`, `show_task()`, `resolve_task_path()` |
 | `tools/builtins/skill.py` | Skill tool impl | `skill()`, `discover_skills()` |
 | `tools/builtins/web.py` | HTTP fetch tool | `fetch_web()` |
 | `tools/builtins/utils_tools.py` | Misc utility tools | `manage_environment_vars()` |
-| `tools/builtins/*_definitions.py` | Per-domain tool definitions (9 files) | `TOOL_DEFINITIONS` tuples auto-discovered at import |
+| `tools/builtins/*_definitions.py` | Per-domain tool definitions (10 files) | `TOOL_DEFINITIONS` tuples auto-discovered at import |
 
 ### Feature Modules
 
@@ -653,18 +652,21 @@ Schema-driven tool definitions with auto-discovery:
 - **Schema generation**: `to_openai_schema()` returns the OpenAI function-calling dict
 - **Plugin loading**: `tools/plugin_manager.py` can augment `TOOL_DEFINITIONS` at runtime from local or GitHub-sourced plugins
 
-16 built-in tools across 9 definition files:
+13 built-in tools across 10 definition files:
 - Filesystem (3): `file_explorer`, `read_file`, `file_editor`
 - Search (2): `search_codebase`, `get_project_structure`
 - Shell (1): `bash`
-- Context (1): `context`
-- Notes (1): `create_note`
+- Context (1): `context` (action=save|load|list|stats|clear)
+- Notes (1): `note` (action=create|read|update|list|delete)
 - Background Process (1): `background_process` (action=start|logs|stop|list|info)
-- Tasks (2): `list_tasks`, `show_task`
+- Tasks (1): `task` (action=create|list|show|status|update_status|update|update_dependencies)
+- Skills (1): `skill` (action=list|load|read|unload)
 - Environment (1): `manage_environment_vars`
 - Web (1): `fetch_web`
 
-> The authoritative count comes from `len(TOOL_DEFINITIONS)`; run `python -c "from ayder_cli.tools.definition import TOOL_DEFINITIONS; print(len(TOOL_DEFINITIONS))"` to verify.
+Registered at run time, not counted above: `agent` (when agents are configured) and the tools of configured MCP servers.
+
+> The authoritative count comes from `len(_BUILTIN_DEFINITIONS)` (`TOOL_DEFINITIONS` also includes installed plugins); run `python -c "from ayder_cli.tools.definition import _BUILTIN_DEFINITIONS; print(len(_BUILTIN_DEFINITIONS))"` to verify.
 
 ---
 

{ayder_cli-2.5.3 → ayder_cli-2.5.4}/docs/README_AGENT_WORKFLOW.md

@@ -20,26 +20,29 @@ specialist agents, pass each one the right context, and move work through the
 pipeline. Keep your own messages short; let the agents do the heavy lifting.
 
 ### How to talk to an agent
-- `call_agent("<name>", task=…, task_id=…, branch_name=…)` → returns a **run id**
-  immediately. It does not block. Only `name` is required.
-- Dispatch independent tasks together (several `call_agent` calls), then poll
-  `agent_status()` to see what is `working` vs `done`.
-- Collect a finished one with `read_agent_result(<run_id>)`, or wait for a slow one
-  with `read_agent_result(<run_id>, wait=true, timeout_s=…)`.
+- `agent(action="call", name="<name>", task=…, task_id=…, branch_name=…, base_branch=…)`
+  → returns a **run id** immediately. It does not block. `action` and `name` are
+  required; `task` may be left out only when `task_id` is given. Use
+  `agent(action="list")` to discover the exact names.
+- Dispatch independent tasks together (several `agent(action="call")` calls), then
+  check `agent(action="status")` to see what is `working` vs `done`.
+- Collect a finished one with `agent(action="read_result", run_id=<run_id>)`, or wait
+  for a slow one with `agent(action="read_result", run_id=<run_id>, wait=true, timeout_s=…)`
+  instead of polling in a loop.
 - Each agent only sees the prompt you give it. **For task-file work, pass
   `task_id="TASK-NNN"` and `branch_name="agent/<slug>"`** — the harness resolves the
   id, **fails fast** if it doesn't exist, and embeds the task file itself in the
   agent's prompt. Do **not** read the task file and paste its body into `task`; use
   `task` only for extra steering (or as the whole instruction when there's no file).
 - **Don't write notes or summaries yourself.** Every agent auto-saves its full
-  deliverable to `.ayder/notes/`; collect it with `read_agent_result` (or `read_file`
-  its `note_path`). Re-summarizing an agent's output into your own note is wasted work.
+  deliverable to `.ayder/notes/`; collect it with `agent(action="read_result")` (or
+  `read_file` its `note_path`). Re-summarizing an agent's output into your own note is wasted work.
 - **Give pointers, not pasted content.** Agents share the working tree and have
   shell/read/search tools — they run their own `git diff` and read their own files.
   Hand a reviewer/QA/gate agent the branch, the base ref, the task id(s), and the
   paths; do **not** read source or diffs and paste them into `task`. Pasting wastes
   your context and is exactly what makes a review/QA dispatch stall.
-- **Never dispatch an empty task.** Every `call_agent` must carry a concrete
+- **Never dispatch an empty task.** Every `agent(action="call")` must carry a concrete
   instruction — a non-empty `task` and/or a `task_id` that resolves to a task file.
   If neither carries real content, you are not ready to dispatch — fix that first.
 
@@ -55,17 +58,14 @@ pipeline. Keep your own messages short; let the agents do the heavy lifting.
    which tasks are **parallel** and which are small/low-risk.
 4. **Task split (delegate it — don't split the work yourself).** Ask the
    `architect` to break the **approved plan** into task files in `.ayder/tasks/`,
-   one file per task, exactly like `/plan`. Hand it this format to `write_file`:
-   - Name each file `.ayder/tasks/TASK-<NNN>-<slug>.md` (zero-padded NNN;
-     `list_tasks` first, then increment past the highest existing number).
-   - Begin every file with this exact header, then the task in PRD form with its
-     acceptance criteria, the files it touches, and its `agent/<slug>` branch:
-     ```
-     ## Signature
-     - **ID:** TASK-<NNN>
-     - **Status:** pending
-     - **Created:** <YYYY-MM-DD HH:MM:SS>
-     ```
+   one file per task, exactly like `/plan`: one call per task,
+   `task(action="create", title=…, body=…, branch="agent/<slug>", dependencies="TASK-NNN,…")`.
+   - `body` is the task in PRD form: `## Goal`, `## Files`, `## Acceptance Criteria`
+     (as a checklist) and `## Notes`.
+   - The tool allocates the next `TASK-<NNN>` id, names the file, writes the
+     `## Signature` header (status `pending`) itself and returns the id. Do not
+     hand-format a header or compute the next number; use `task(action="list")` to
+     review the queue.
 5. **Task review.** `architect_review` checks the **whole task set against the
    approved plan**: full coverage (every plan item maps to a task), no scope
    creep, correct sizing/sequencing, consistent interfaces across tasks. Loop
@@ -73,13 +73,13 @@ pipeline. Keep your own messages short; let the agents do the heavy lifting.
    `/tasks` (○ pending · ◐ in_progress · ✓ done).
 6. **Delegate (isolated — see git rules below).** Work the queue task by task:
    - Flip the task's `**Status:**` to `in_progress`, then dispatch it with
-     `call_agent("senior_coder", task_id="TASK-NNN", branch_name="agent/<slug>")`
+     `agent(action="call", name="senior_coder", task_id="TASK-NNN", branch_name="agent/<slug>", base_branch="feat/<slug>")`
      (small, low-risk tasks → the single `junior_coder`, one at a time). The harness
      hands the agent the task file and the branch directive — you don't paste the
      task body. Each agent commits only to its own branch.
    - When you collect and accept the result, flip the task's `**Status:**` to `done`.
-   Update a status by rewriting the task file's `**Status:**` line (read it with
-   `show_task`, write it back with `write_file`). This keeps `/tasks` accurate so
+   Update a status with `task(action="update_status", identifier="TASK-NNN",
+   status="in_progress")` (or `status="done"`). This keeps `/tasks` accurate so
    the user always sees what is queued, in flight, and finished.
 7. **QA.** `qa_engineer` writes and runs the test suite, reports real pass/fail output.
    Give it the branch + task ids; it reads the code and runs the tests itself.
@@ -94,26 +94,26 @@ pipeline. Keep your own messages short; let the agents do the heavy lifting.
 
 ### Git rules — so agents don't step on each other
 
-The agents share one working directory, so two builders editing at once will
-collide. Isolate them with git:
+Agents without a branch share the main working directory, so two of them editing
+at once will collide. Give every builder a branch and the harness isolates it:
 
-- **One branch per task.** Name them `agent/<task-slug>`, branched off `feat/<slug>`.
-- **For true parallel builds, give each builder its own worktree** (a separate
-  folder) so their files never touch:
-  ```bash
-  git worktree add .ayder/worktrees/<task-slug> -b agent/<task-slug> feat/<slug>
-  ```
-  Tell the builder to work in that folder. If you'd rather keep it simple, skip
-  worktrees and run the builders **one at a time** on their branches instead.
+- **One branch per task.** Name them `agent/<task-slug>` and pass
+  `branch_name="agent/<task-slug>"` with `base_branch="feat/<slug>"` to
+  `agent(action="call")`.
+- **The harness makes the worktree.** A run with a `branch_name` works in its own
+  worktree at `.ayder/worktrees/<task-slug>`, forked from `base_branch` (default: the
+  repo's default branch; an existing branch is reused), and the worktree is removed
+  when the run ends. Parallel builders never touch each other's files. The project
+  must be a git repository, or the run fails.
 - **Builders commit only to their own branch.** They never touch `main`, `feat/<slug>`,
-  or another agent's branch.
+  or another agent's branch. Uncommitted work is lost with the worktree: a branch run
+  that makes no commit ends with status `error` ("no commit on branch"); re-dispatch it.
 - **Only the gate merges.** It integrates branches in dependency order:
   ```bash
   git switch feat/<slug>
   git merge --no-ff agent/<task-slug>     # repeat per approved branch; resolve conflicts
   # run the full suite + acceptance checks, then:
   git switch main && git merge --no-ff feat/<slug>
-  git worktree remove .ayder/worktrees/<task-slug>   # clean up
   ```
 
 ### Simple rules to keep it on the rails