1 line
227 KiB
JSON
1 line
227 KiB
JSON
{"repo": "ayder/ayder-cli", "files": {"README.md": {"ece5c3845724d5316ccdff3dca15ad5de3711c55": {"t": 1785674595.8587356, "n": 26080, "h": "ab5c0f0e867661b9", "c": "# ayder-cli\n\nA multi-provider AI agent chat client for your terminal. ayder supports Ollama, Anthropic Claude, OpenAI, Gemini,\nor any OpenAI-compatible API and provides an autonomous coding assistant with file system tools and shell access.\n\n\n\n## What's New in 2.0\n\nProvider SDKs are now **optional**. The core install ships only OpenAI + Ollama (plus DeepSeek, which reuses the OpenAI SDK); Anthropic, Google, Qwen, and GLM are opt-in extras -- install only what you use. Selecting a driver whose package isn't installed fails fast with the exact `pip install` command and a list of the drivers available in your install. See [CHANGELOG.md](CHANGELOG.md) and [Installation](#installation).\n\n> **Upgrading from 1.x (breaking):** `anthropic` and `google` are no longer installed by default. Run `pip install ayder-cli[anthropic]` / `[google]` (or `[all]`) if you use them.\n\n## Supported LLM providers\n\n- [Ollama](https://ollama.com) (local or cloud)\n- [Anthropic Claude](https://www.anthropic.com)\n- [OpenAI](https://openai.com/)\n- [Gemini](https://gemini.google.com/)\n- [DeepSeek](https://deepseek.com/) (via OpenAI-compatible driver)\n- [Qwen](https://qwen.ai/) (via DashScope native driver)\n- [GLM / ChatGLM](https://open.bigmodel.cn/) (via ZhipuAI native driver)\n\n## Why ayder-cli?\n\nMost AI coding assistants require cloud APIs, subscriptions, or heavy IDE plugins. ayder-cli takes a different approach:\n\n- **Multi-provider** -- switch between Ollama, Anthropic Claude, Gemini, or any OpenAI-compatible API with a single `/provider` command. Each provider has its own config profile.\n- **7 native drivers** -- Ollama, OpenAI, Anthropic, Gemini, DeepSeek, Qwen (DashScope), and GLM (ZhipuAI). Each driver guarantees native tool calling and streaming support.\n- **Fully local or cloud** -- run locally with Ollama, or connect to any cloud provider.\n- **Agentic workflow** -- the LLM reads files, edits code, runs shell commands, and iterates autonomously with configurable iteration limits per message.\n- **Multi-agent** -- define specialized sub-agents in `config.toml`. Each agent runs independently with its own LLM, model, and context. Results are injected back into the main conversation when complete.\n- **Textual TUI** -- an inline terminal interface with chat view, tool panel, thinking block toggle, slash command auto-completion, permission toggles, and tool confirmation modals with diff previews.\n- **Batteries included** -- the OpenAI and Ollama SDKs ship with ayder-cli core. Anthropic, Google, Qwen, and GLM are optional extras (install only what you need). The terminal UI is built on Rich and Textual.\n\n### Tools\n\nLLMs on their own can only generate text. To be a useful coding assistant, the model needs to *act* on your codebase. ayder-cli ships 16 built-in tools that the model can call, plus optional plugin toolsets (see [Plugins](#plugins)):\n\nEach 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.\n\n- **Path sandboxing**: All file operations are confined to the project root via `ProjectContext`. Path traversal attacks (`../`) and absolute paths outside the project are blocked.\n- **Safe mode** (TUI): Blocks `file_editor`, `run_shell_command`, `run_background_process`, `kill_background_process`, and `fetch_web`.\n- Every tool call requires your confirmation before it runs -- you always stay in control. Use `-r`, `-w`, `-x` flags to auto-approve tool categories.\n- You may also prefer to run ayder-cli in a container for additional security.\n\n## Installation\n\nRequires Python 3.12+.\nWorks best with uv. If you don't have uv in your path, get it from\n[Astral uv](https://docs.astral.sh/uv/#highlights).\n\nCore install (OpenAI + Ollama, plus DeepSeek which reuses the OpenAI SDK):\n\n pip install ayder-cli\n\nOptional providers (install only what you use):\n\n pip install ayder-cli[anthropic] # Claude\n pip install ayder-cli[google] # Gemini\n pip install ayder-cli[qwen] # Qwen (dashscope)\n pip install ayder-cli[glm] # GLM (zhipuai)\n pip install ayder-cli[all] # everything\n\nIf you select a driver whose package isn't installed, ayder prints the exact\ninstall command and lists the drivers available in your install.\n\n```bash\n# Install to user environment (uv tool)\nuv tool install ayder-cli\n\n# Or for nightly / development builds:\ngit clone https://github.com/ayder/ayder-cli.git\ncd ayder-cli\n\n# Install in development mode\npython3.12 -m venv .venv\nsource .venv/bin/activate\nuv pip install -e .\n\n# Or as a uv tool (always on the path)\nuv tool install -e .\n```\n\n### Ollama setup (default provider)\n\n```bash\n# Make sure Ollama is running with a model\nollama pull qwen3-coder\nollama serve\n\n# Optional: optimize Ollama for your model\nexport OLLAMA_CONTEXT_LENGTH=65536\nexport OLLAMA_FLASH_ATTENTION=true\nexport OLLAMA_MAX_LOADED_MODELS=1\n```\n\n### Cloud providers\n\nAdd an API key to a profile in `~/.ayder/config.toml` (see Configuration\nbelow) and switch provider in the TUI:\n\n```bash\n/provider anthropic # or: openai, google, deepseek, qwen, glm\n```\n\nNote: `anthropic` and `google` require the corresponding optional extra\n(see Installation above). `openai`, `ollama`, and `deepseek` are included\nin the core install.\n\n### Configuration: Profiles and Drivers\n\nayder-cli uses a flexible profile-based configuration system. On the first run, it creates a config file at `~/.ayder/config.toml`.\n\n**Key Concepts:**\n- **Profile Name:** A custom named section (e.g., `[llm.my_ollama]`). You can define as many profiles as you want.\n- **Driver:** The underlying native SDK or adapter used by the profile (`ollama`, `openai`, `anthropic`, `google`, `deepseek`, `qwen`, or `glm`). Each driver guarantees full support for native tool calling and streaming.\n- **Active Provider:** The `provider` setting under `[app]` determines which profile is currently active.\n- **Chat Protocol:** By default, all drivers use native tool calling (`chat_protocol = \"ollama\"`). If you encounter a model that fails to trigger tools natively, you can set `chat_protocol = \"xml\"` in that profile to force an XML-based fallback.\n\n#### Example: Running the Same Model via Different Drivers\n\nBecause profiles are just names, you can configure the same model to run through different drivers:\n\n```toml\nconfig_version = \"2.0\"\n\n[app]\nprovider = \"qwen_local\" # <--- Currently using the local Ollama version\n\n# --- Profiles ---\n\n# 1. Local Qwen via Ollama driver\n[llm.qwen_local]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\nmodel = \"qwen2.5-coder:latest\"\nnum_ctx = 65536\n\n# 2. Cloud Qwen via OpenAI driver (e.g., DeepInfra, Together)\n[llm.qwen_cloud]\ndriver = \"openai\"\nbase_url = \"https://api.deepinfra.com/v1/openai\"\napi_key = \"sk-...\"\nmodel = \"Qwen/Qwen2.5-Coder-32B-Instruct\"\nnum_ctx = 65536\n```\n\nIn the TUI, typing `/provider qwen_cloud` seamlessly switches from your local GPU to the cloud endpoint.\n\n#### Full Configuration Reference\n\n```toml\nconfig_version = \"2.0\"\n\n[app]\nprovider = \"openai\" # Active provider profile name\neditor = \"vim\" # Editor for /task-edit command\nverbose = false # Show file contents after write + LLM debug\nmax_background_processes = 5 # Max concurrent background processes (1-20)\nmax_iterations = 10 # Max agentic iterations per message (1-100)\nmax_output_tokens = 4096 # Max tokens in LLM response\nmax_history_messages = 30 # Messages kept in history\nprompt = \"STANDARD\" # System prompt tier: MINIMAL, STANDARD, EXTENDED\ntool_tags = [\"core\", \"metadata\"] # Enabled tool tags (see /plugin)\nagent_timeout = 300 # Seconds before a background agent is cancelled\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n\n[context_manager]\nenabled = true\nmax_context_tokens = 8192\n\n[temporal]\nenabled = false\nhost = \"localhost:7233\"\nnamespace = \"default\"\nmetadata_dir = \".ayder/temporal\"\n\n# --- Provider Profiles ---\n\n[llm.my_local_ollama]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\nmodel = \"qwen3-coder:latest\"\nnum_ctx = 65536\n\n[llm.openai_cloud]\ndriver = \"openai\"\napi_key = \"sk-...\"\nmodel = \"gpt-4o\"\nnum_ctx = 128000\n\n[llm.anthropic]\ndriver = \"anthropic\"\napi_key = \"sk-ant-...\"\nmodel = \"claude-sonnet-4-5-20250929\"\nnum_ctx = 200000\n\n[llm.gemini]\ndriver = \"google\"\napi_key = \"AIza...\"\nmodel = \"gemini-3-pro\"\nnum_ctx = 1000000\n```\n\nPlease adjust `num_ctx` context size window according to your local computer RAM. If Ollama crashes, decrease the value.\n\n### Changing Models on the Fly (`/model`)\n\nYou do **not** need a separate profile for every model. The profile defines the *connection* (driver, base URL, API key).\n\nOnce a profile is active, use `/model` in the TUI to swap models on the fly:\n\n- **Interactive Picker:** `/model` with no arguments queries the active driver for available models and opens a picker.\n- **Direct Switch:** `/model <model-name>` immediately switches to that model.\n\nChanges made with `/model` apply to the current session only. To make a model the permanent default, update `model = \"...\"` in your `config.toml`.\n\n## Usage\n\n```bash\n# Start (launches TUI by default)\nayder\n\n# Or run as a module\npython3 -m ayder_cli\n```\n\n### Command Mode (Non-Interactive)\n\n```bash\n# Execute a single command and exit\nayder \"create a hello.py script\"\n\n# Pipe input (auto-detected, no flag needed)\necho \"create a test.py file\" | ayder\n\n# Read from file\nayder -f instructions.txt\n\n# Explicit stdin mode\nayder --stdin < prompt.txt\n\n# Override the main LLM system prompt with a file\n# (tool instructions + project structure are still appended)\nayder --system-prompt prompt-file.md \"refactor this code\"\n```\n\n### Task Commands (CLI Mode)\n\nExecute task-related commands directly without entering the TUI:\n\n```bash\n# List all tasks\nayder --tasks\n\n# Implement a specific task by ID or name\nayder --implement 1\nayder --implement auth\n\n# Implement all pending tasks sequentially\nayder --implement-all\n```\n\n### Tool Permissions (-r/-w/-x/--http)\n\nBy default, every tool call requires user confirmation. Use permission flags to auto-approve tool categories:\n\n| Flag | Category | Built-in tools |\n| ---- | -------- | -------------- |\n| `-r` | Read | `file_explorer`, `read_file`, `search_codebase`, `get_project_structure`, `get_background_output`, `list_background_processes`, `list_tasks`, `show_task` |\n| `-w` | Write | `file_editor`, `context`, `create_note`, `manage_environment_vars` |\n| `-x` | Execute | `run_shell_command`, `run_background_process`, `kill_background_process` |\n| `--http` | Web/Network | `fetch_web` |\n\nInstalled plugins extend these categories (e.g. `python_editor` → write, virtualenv tools → execute, `dbs_tool` → web).\n\n```bash\n# Auto-approve read-only tools\nayder -r\n\n# Auto-approve read and write tools\nayder -r -w\n\n# Auto-approve everything (fully autonomous)\nayder -r -w -x\n\n# Allow web tools without prompts\nayder -r --http\n\n# Combine with other flags\nayder -r -w \"refactor the login module\"\necho \"fix the bug\" | ayder -r -w -x\n```\n\n### Context Management\n\nayder-cli includes a context manager that automatically keeps your conversation within the model's token budget. The implementation is **driver-aware** — Ollama gets a specialized KV-cache-optimized manager, while cloud providers (Anthropic, OpenAI, Gemini) use a general-purpose tiered manager.\n\n**Ollama-specific optimizations** (automatic when `driver = \"ollama\"`):\n\n- **KV-cache-aware**: Messages are append-only and never reordered. The system prompt is frozen at session start. This preserves Ollama's KV-cache prefix between calls — subsequent prompts process only new tokens instead of recomputing everything.\n- **Real token counts**: Uses Ollama's `prompt_eval_count` and `eval_count` from native API responses instead of estimates. Compaction decisions are based on actual usage, not heuristics.\n- **Cache monitoring**: Tracks `prompt_eval_duration / prompt_eval_count` ratio to detect KV-cache hits (hot/warm/miss). When the cache is hot, compaction is delayed (threshold raised from 70% to 90%) to avoid invalidating it.\n- **Auto-detected context length**: On startup, queries `/api/show` to get the model's real context length instead of relying on `num_ctx`. Falls back to `num_ctx` if detection fails.\n- **Heuristic compaction**: When the context fills up, oldest message units are replaced with a text summary — no LLM call needed.\n- **Native SDK**: Uses `ollama.AsyncClient` directly (not the OpenAI compatibility layer) for full timing data, native thinking support, and `keep_alive=-1` to prevent model unloading.\n\n**General-purpose manager** (Anthropic, OpenAI, Gemini, and other drivers):\n\nEvery message is assigned an importance tier (system > recent user > recent assistant > tool results > old history). When the conversation approaches the token budget, old tool results are compressed (JSON structurally summarized, large text head/tail truncated) and the lowest-priority messages are pruned. Tool call + result pairs are kept as atomic units.\n\nThe context manager is configured under `[context_manager]` in `config.toml`:\n\n| Setting | Default | Description |\n|---------|---------|-------------|\n| `enabled` | `true` | Master switch. |\n| `max_context_tokens` | `8192` | Fallback token budget (Ollama auto-detects from model). |\n| `reserve_ratio` | `0.30` | Fraction reserved for the LLM response. |\n| `compaction_threshold` | `0.70` | Utilization ratio that triggers compaction. |\n| `tool_result_compress_age` | `5` | Tool results older than N messages are eligible for compression. |\n| `max_tool_result_length` | `2048` | Maximum character length for a compressed tool result. |\n| `compress_tool_results` | `true` | Enable automatic tool result compression. |\n\nYou can also manually manage context with the `context` tool and its slash-command shortcuts: `/save-context`, `/load-context`, `/list-contexts`, `/context-stats`, and `/compact`.\n\n### Slash Commands\n\n| Command | Description |\n| ------- | ----------- |\n| `/help` | Show available commands and keyboard shortcuts |\n| `/provider` | Switch LLM provider (interactive selector or direct name) |\n| `/model` | List available models or switch model (e.g., `/model qwen3-coder`) |\n| `/plugin` | Toggle tool plugins by tag (e.g., venv, http, background, python, dbs) |\n| `/tools` | List currently enabled tools and descriptions |\n| `/permission` | Toggle permission levels (r/w/x/http) interactively |\n| `/ask` | Ask a general question without using tools |\n| `/plan` | Analyze request and create implementation tasks |\n| `/tasks` | Browse and implement tasks from `.ayder/tasks/` |\n| `/implement [id]` | Interactive task picker, or implement by ID (e.g., `/implement 1`) |\n| `/notes` | Browse and edit markdown notes |\n| `/skill` | Activate a domain skill from `.ayder/skills/` via the shared `skill` tool backend |\n| `/verbose` | Toggle verbose mode |\n| `/logging` | Set log level for current session (NONE, ERROR, WARNING, INFO, DEBUG) |\n| `/compact` | Summarize conversation, save a context snapshot, clear, and reload |\n| `/save-context` | Summarize conversation and save it to a named context slot (no clear) |\n| `/load-context` | Load a saved context slot and restore it |\n| `/list-contexts` | List saved context slots |\n| `/context-stats` | Show current token and KV-cache usage |\n| `/archive-completed-tasks` | Move completed tasks to `.ayder/task_archive/` |\n| `/temporal` | Start/status Temporal queue worker |\n| `/agent list` | List configured agents and their current status |\n| `/agent <name> <task>` | Dispatch an agent to run a task in the background |\n| `/agent cancel <name>` | Cancel a running agent |\n\n### Logging\n\nThe LLM can also call `skill(action=\"list\" | \"load\" | \"unload\")`\nautomatically when a request clearly matches an available project skill.\n\n- Default: when logging is enabled, logs go to `.ayder/log/ayder.log` (not shown on screen).\n- TUI `/logging` changes are session-only and do not modify `config.toml`.\n- CLI `--verbose [LEVEL]` enables stdout logging for that run.\n\n### Keyboard Shortcuts\n\n| Shortcut | Action |\n| -------- | ------ |\n| `Ctrl+Q` | Quit |\n| `Ctrl+X` / `Ctrl+C` | Cancel current operation |\n| `Ctrl+L` | Clear chat |\n| `Ctrl+O` | Toggle tool panel |\n| `Ctrl+T` | Toggle thinking/reasoning blocks |\n| `PageUp` / `PageDown` | Scroll chat view |\n| `Tab` | Auto-complete slash commands |\n\n## Efficiency & Optimization\n\nayder-cli is optimized for both large and small (local) LLMs:\n\n- **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.\n- **Tiered Prompts**: Use `prompt = \"MINIMAL\"` in config for smaller models (7B-14B) to strip complex reasoning frameworks and improve follow-through.\n- **Automatic Context Bounding**: Conversation history is bounded based on `max_history_messages` to prevent context rot.\n- **Tool System Prompts**: Tool-specific prompt blocks (e.g., DBS instructions) are only injected when their tag is enabled, keeping the system prompt lean.\n\n## Operational Modes\n\n### Default Mode\n\nThe standard mode for general coding and chat. Uses the system prompt.\n\n```\n> create a fibonacci function\n```\n\nAvailable tools: file read/write, shell commands, search, context, notes, tasks.\n\n### Planning Mode (`/plan`)\n\nActivated with `/plan`. The AI breaks down requirements into tasks stored in `.ayder/tasks/`.\n\n```\n> /plan add user authentication to the app\n```\n\n### Task Mode (`/implement`)\n\nActivated with `/implement`. The AI implements tasks from the task list.\n\n```\n> /implement # Interactive task picker\n> /implement 1 # Implement TASK-001 directly\n```\n\n### Task Management\n\nayder-cli includes a built-in task system:\n\n1. **Plan** (`/plan`) -- Break down requirements into tasks\n2. **Implement** (`/implement`) -- Work through tasks one by one\n3. **Archive** (`/archive-completed-tasks`) -- Move done tasks to archive\n\nTasks are stored as markdown files in `.ayder/tasks/` using slug-based filenames (e.g., `TASK-001-add-auth-middleware.md`).\n\n```\n> /tasks # Interactive task browser\n> /task-edit 1 # Open TASK-001 in the in-app editor\n> /implement 1 # Implement TASK-001\n```\n\n### Pluggable Tool Architecture\n\nAdding a new tool is as simple as:\n\n1. **Create a definition file**: `src/ayder_cli/tools/builtins/mytool_definitions.py`\n2. **Implement the tool function**: Add your logic in a corresponding `.py` file\n3. **Done!** Auto-discovery registers the tool automatically\n\nThe tool system:\n- Discovers all `*_definitions.py` files automatically\n- Validates for duplicate names and required tools\n- Registers tools with the LLM via OpenAI-compatible schemas\n- Supports tag-based filtering for dynamic enable/disable\n- Injects tool-specific system prompts when enabled\n\n**Built-in tools (16):**\n\n| Category | Tools |\n|----------|-------|\n| **Filesystem** | `file_explorer`, `read_file`, `file_editor` |\n| **Search** | `search_codebase`, `get_project_structure` |\n| **Shell** | `run_shell_command` |\n| **Context** | `context` (save / load / list / stats / clear session context slots) |\n| **Notes** | `create_note` |\n| **Background Processes** | `run_background_process`, `get_background_output`, `kill_background_process`, `list_background_processes` |\n| **Tasks** | `list_tasks`, `show_task` |\n| **Environment** | `manage_environment_vars` |\n| **Web** | `fetch_web` |\n\nWhen agents are configured, the `call_agent` tool is also registered so the main LLM can dispatch them (see [Multi-Agent System](#multi-agent-system)).\n\n**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.\n\n## Multi-Agent System\n\nayder-cli supports user-defined **specialized agents**: each agent is an independent AI loop with its own LLM provider, model, system prompt, and context window. Agents run as background tasks — they never block the main conversation and their results are automatically injected back when they complete.\n\n### How Agents Work\n\n```\nMain LLM (your conversation)\n │\n ├─ calls `call_agent` tool ─────────────────────────────────┐\n │ OR you type `/agent <name> <task>` │\n │ ▼\n │ AgentRunner (background asyncio task)\n │ ┌─────────────────────────────────┐\n │ │ Isolated ChatLoop │\n │ │ • own LLM provider + model │\n │ │ • own context window │\n │ │ • own ToolRegistry │\n │ │ • auto-approves all tools │\n │ │ • produces <agent-summary> │\n │ └────────────────┬────────────────┘\n │ │ completes\n │ ▼\n │ AgentSummary → _summary_queue\n │\n ▼ (next main LLM turn)\npre_iteration_hook drains queue\n └─ injects AgentSummary as system message into main context\n └─ main LLM sees: \"[Agent 'reviewer' completed] FINDINGS: ...\"\n```\n\nKey properties:\n- **Separate context** — agents have no access to the main conversation history. They receive only their system prompt and the task description.\n- **Non-blocking** — dispatching an agent returns immediately. Both `/agent` and `call_agent` are fire-and-forget.\n- **Concurrent** — multiple agents can run simultaneously, each in its own async task.\n- **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.\n- **Timeout** — agents are automatically cancelled after `agent_timeout` seconds (default: 300).\n\n### Configuring Agents\n\nAdd `[agents.<name>]` sections to your `~/.ayder/config.toml`:\n\n```toml\n[app]\nprovider = \"ollama\"\nagent_timeout = 300 # Global timeout for all agents (seconds)\n\n[llm.ollama]\ndriver = \"ollama\"\nmodel = \"qwen3-coder:latest\"\nnum_ctx = 65536\n\n[llm.anthropic]\ndriver = \"anthropic\"\napi_key = \"sk-ant-...\"\nmodel = \"claude-sonnet-4-5-20250929\"\nnum_ctx = 200000\n\n# --- Agents ---\n\n[agents.code-reviewer]\nsystem_prompt = \"\"\"You are a senior code reviewer. Review the code for bugs,\nsecurity issues, and style violations. Be concise and actionable.\"\"\"\nprovider = \"anthropic\" # Optional: use a different provider than main\nmodel = \"claude-sonnet-4-5-20250929\" # Optional: use a different model\n\n[agents.test-writer]\nsystem_prompt = \"\"\"You are a test engineer. Write comprehensive pytest tests\nfor the code provided. Follow existing test patterns in the codebase.\"\"\"\n# No provider/model → inherits from [app] provider\n\n[agents.doc-writer]\nsystem_prompt = \"\"\"You are a technical writer. Write clear, concise docstrings\nand inline comments for the code provided.\"\"\"\n```\n\nEach agent field:\n\n| Field | Required | Description |\n|-------|----------|-------------|\n| `system_prompt` | Yes | The agent's role and instructions |\n| `provider` | No | LLM provider profile name (inherits from `[app]` if omitted) |\n| `model` | No | Model name override (inherits from provider profile if omitted) |\n\n### Using Agents\n\n**From the TUI (slash commands):**\n\n```\n# List configured agents and their status\n/agent list\n\n# Dispatch an agent to review your authentication module\n/agent code-reviewer Review src/auth.py for security issues\n\n# Dispatch the test writer for a specific module\n/agent test-writer Write tests for src/api/users.py\n\n# Cancel a running agent\n/agent cancel code-reviewer\n```\n\n**Via the main LLM (automatic):**\n\nWhen agents are configured, the main LLM is told about them via its system prompt and can call `call_agent` autonomously:\n\n```\nYou: Review the authentication module and write tests for it.\n\nLLM: I'll dispatch two agents to handle this in parallel.\n [calls call_agent: name=\"code-reviewer\", task=\"Review src/auth.py...\"]\n [calls call_agent: name=\"test-writer\", task=\"Write tests for src/auth.py...\"]\n\n Both agents are running in the background. I'll incorporate\n their findings when they complete.\n\n... (agents run independently) ...\n\nLLM: [next turn, after agents complete]\n The code-reviewer found 2 issues: ...\n The test-writer produced 8 new tests: ...\n```\n\n**Agent summary format:**\n\nAgents end their final response with a structured block that ayder-cli parses:\n\n```\n<agent-summary>\nFINDINGS: Found a SQL injection vulnerability in login() and missing input validation in register()\nFILES_CHANGED: none\nRECOMMENDATIONS: Parameterize all DB queries; add Pydantic validators to all endpoints\n</agent-summary>\n```\n\nThis summary is injected into the main LLM's context as a system message so the main agent can act on it, summarize it for you, or chain it to further work.\n\n## Plugins\n\nOfficial plugins (venv, python, dbs, mcp, temporal) are maintained in the **[ayder/ayder-plugins](https://github.com/ayder/ayder-plugins)** repository. Install any plugin directly from GitHub:\n\n```bash\nayder install-plugin https://github.com/ayder/ayder-plugins/tree/main/venv-tools\nayder install-plugin https://github.com/ayder/ayder-plugins/tree/main/python-tools\n```\n\nPlugins can also be hosted in any public GitHub repository — point `install-plugin` at any repo or subdirectory containing a `plugin.toml`.\n\n## License\n\nMIT\n"}}, "docs/config.toml.example": {"ece5c3845724d5316ccdff3dca15ad5de3711c55": {"t": 1785746801.9283578, "n": 20366, "h": "f69950765065276c", "c": "# =============================================================================\n# ayder-cli — Multi-Agent SDLC Harness (example config)\n# =============================================================================\n#\n# A 9-role software-delivery pipeline backed by Ollama Cloud models, plus one\n# local model. Roles are matched to model strengths: reasoning-optimized models\n# drive planning / review / gating; coding-optimized models do the writing and\n# testing.\n#\n# Pipeline (orchestrator dispatches agents in this order):\n#\n# pm_spec ──▶ pm_review ──▶ architect ──▶ architect_review\n# │\n# ┌────────────────────────────────────────┘\n# ▼\n# senior_coder ×2-3 (+ junior_coder for small local tasks, 1 instance)\n# │\n# ▼\n# qa_engineer ──▶ code_reviewer ──▶ acceptance_gate\n#\n# Model → role assignment (grounded in published SWE-bench data, June 2026):\n#\n# Role Model Why\n# ---------------- -------------------------------- --------------------------------\n# pm_spec glm-5.2:cloud strong, token-efficient reasoning + structured writing\n# pm_review deepseek-v4-pro:cloud apex reasoner (~80.6% SWE-bench Verified); diff family from pm_spec\n# architect deepseek-v4-pro:cloud hardest reasoning task: system design\n# architect_review kimi-k2.7-code:cloud independent reviewer; strong coder, cross-family from the architect (deepseek)\n# senior_coder glm-5.2:cloud code-strong, token-efficient code generation; strong agentic coder\n# qa_engineer minimax-m3:cloud long-context coder; holds implementation + criteria while authoring tests\n# junior_coder qwen3.6:35b-a3b-coding-nvfp4 LOCAL MoE coder (3B active, nvfp4); only ONE active (memory)\n# code_reviewer kimi-k2.7-code:cloud 1T coding specialist; cross-family from the coders (glm)\n# acceptance_gate minimax-m3:cloud long-context lineage; holds spec + criteria + diff + tests at once\n#\n# Review boundaries cross model families so a reviewer does not share the\n# author's blind spots (glm↔deepseek at PM, deepseek↔kimi at architecture,\n# glm↔kimi at code review, everything↔minimax at the final gate).\n#\n# gemma4:31b-cloud is the lightest dense model in your set. It is NOT wired to a\n# frontier gate on purpose (under-powering a gate defeats it); it is provided\n# below as a ready budget/throughput swap — see [llm.ollama_cloud_budget].\n#\n# AUTH — two ways to reach `:cloud` models (this file defaults to #1):\n# 1. Via the LOCAL daemon (recommended): base_url = \"http://localhost:11434\".\n# The daemon authenticates cloud models with ~/.ollama/id_ed25519 after a\n# one-time `ollama signin`. No env var needed. (Requires the daemon running.)\n# 2. Direct to cloud: base_url = \"https://ollama.com\" (no /v1) AND\n# `export OLLAMA_API_KEY=\"<key>\"`. The api_key config field is INERT on the\n# native path, so a missing env var ⇒ 401 Unauthorized.\n#\n# NOTE on `think`: on the native `ollama` driver, ayder defaults thinking ON\n# (think = true) and forwards either a boolean or Ollama's \"low\",\n# \"medium\", \"high\" levels. If a selected model rejects thinking mode,\n# ayder retries that request once with think=false. Set `think = false`\n# in an [llm.*] profile for known non-thinking models. The `openai`\n# driver sends no reasoning-effort parameter at all.\n#\n# NOTE on tuning knobs — which actually take effect depends on the DRIVER. These\n# agents run on the native `ollama` driver, which ignores most of them:\n# • temperature — forwarded by NO driver yet ⇒ no effect anywhere.\n# • max_output_tokens — NOT sent on the ollama path (Ollama sizes\n# generation itself); honored only by the\n# openai-family drivers as max_tokens. Default 4096.\n# • think — sent on the ollama path (default true; accepts\n# false or \"low\"/\"medium\"/\"high\"); openai sends\n# none.\n# • num_ctx — on ollama it is provisional only (the real window\n# is auto-detected from /api/show); on the openai\n# path it sizes the context-manager budget.\n# Default 65536.\n# The per-agent temperature / max_output_tokens values below are largely\n# INERT on this Ollama pipeline; per-agent `think` is applied when the\n# agent uses the native ollama driver.\n# =============================================================================\n\nconfig_version = \"2.0\"\n\n[app]\nprovider = \"ollama_cloud\" # active profile for the ORCHESTRATOR session (see [llm.ollama_cloud])\neditor = \"vim\"\nverbose = false\nprompt = \"STANDARD\" # MINIMAL | STANDARD | EXTENDED\nmax_background_processes = 5 # cap on concurrent background processes (e.g. test runs)\nmax_concurrent_agents = 5 # max agents running at once; extra dispatches queue (1-20)\nmax_output_tokens = 8192 # orchestrator response cap\n# Max conversation messages kept per turn. 0 = unlimited (default): the context\n# manager's token budget + compaction are the bound, so the model uses its real\n# window. A small fixed cap (the old default was 30) thrashes a tiny history\n# window on a large-context model and wastes most of it. Set a finite number\n# only if you want a hard message cap regardless of window size.\nmax_history_messages = 0\nagent_timeout = 1800 # seconds before a background agent is cancelled (30 min; reasoning+coding can be slow)\n# Tools the agents inherit. A coding harness needs file/shell/search (core),\n# tasks/notes (metadata), background process control for test suites\n# (background), and web fetch (http). See /plugin for the full tag list.\ntool_tags = [\"core\", \"metadata\", \"background\", \"http\"]\n\n[ui]\n# TUI layout (theme) — picks the chrome/layout:\n# \"ayder\" (default) — linux-console layout (tokenised), respects the terminal\n# by default and can overlay any palette (see below).\n# \"ayder-dark\" — \"ayder\" + default ANSI-dark palette.\n# \"ayder-light\" — \"ayder\" + default ANSI-light palette (light terminals).\n# \"claude\" — dark navy aesthetic with explicit RGB colors.\ntheme = \"ayder\"\n#\n# Palette — the colour palette the \"ayder\" layout is painted with (App.theme).\n# Ignored by the self-contained \"claude\" theme.\n# \"auto\" (default) — the layout's own ANSI palette: passthrough that respects\n# your terminal's background and palette on every terminal.\n# \"ansi-dark\"/\"ansi-light\" — force the ANSI passthrough palette explicitly.\n# \"monokai\", \"dracula\", \"nord\", \"gruvbox\", \"tokyo-night\", … — any Textual theme\n# overlays a fixed RGB palette on the ayder layout. NOTE:\n# these paint their OWN background and therefore do NOT\n# respect the terminal background — an opt-in trade-off.\n# e.g. theme = \"ayder\" + palette = \"monokai\" → \"ayder-monokai\".\npalette = \"auto\"\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n\n[context_manager]\nenabled = true\n# Destructive tool-result compression is OPT-IN and OFF by default. It summarizes\n# old tool results in place (lossy) and thrashes the KV cache, so leave it off\n# unless you specifically want it; eviction will replace it in a later release.\nenable_compression = false\n# max_context_tokens is OPTIONAL. When unset (recommended), the budget is derived\n# from the active model's num_ctx. It is read only on the openai/non-ollama path\n# (DefaultContextManager); the native Ollama path auto-detects the real window\n# from /api/show and ignores it. reserve_ratio + compaction_threshold ARE read on\n# both paths.\n# max_context_tokens = 131072\nreserve_ratio = 0.30\ncompaction_threshold = 0.80\n\n[retry]\nenabled = true\nmax_attempts = 3\ninitial_delay_seconds = 0.5\nmax_delay_seconds = 30.0\nbackoff_coefficient = 2.0\njitter = true\n\n# -----------------------------------------------------------------------------\n# Provider profiles\n# -----------------------------------------------------------------------------\n\n[llm.ollama_cloud]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\" # route :cloud models through the LOCAL daemon (auth via ~/.ollama/id_ed25519, one-time `ollama signin`)\nmodel = \"deepseek-v4-pro:cloud\" # orchestrator default; per-agent `model` overrides this\nnum_ctx = 131072\nthink = true # default; set false for known non-thinking models\n# To hit ollama.com directly instead, swap the line above for:\n# base_url = \"https://ollama.com\" # no /v1; then `export OLLAMA_API_KEY=<key>` (the api_key field is inert on this path)\n\n[llm.ollama_local]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\nnum_ctx = 32768 # keep modest: local VRAM is the constraint\nthink = true # default; set false if the selected model rejects thinking\n\n# Budget/throughput alternative — swap any cloud agent's `provider` to this, or\n# point a duplicate reviewer at it for cheap parallel passes.\n# [llm.ollama_cloud_budget]\n# driver = \"ollama\"\n# base_url = \"https://ollama.com\"\n# model = \"gemma4:31b-cloud\"\n# num_ctx = 131072\n\n# OpenAI-compatible driver. Unlike the `ollama` driver above, this one HONORS the\n# tuning knobs (defaults shown). Use it for api.openai.com, Azure, vLLM,\n# llama.cpp, LM Studio, or Ollama's own `/v1` endpoint. Point an agent at it with\n# `provider = \"openai\"`.\n# [llm.openai]\n# driver = \"openai\"\n# base_url = \"https://api.openai.com/v1\" # OpenAI-compatible endpoint\n# api_key = \"sk-...\" # your key (or \"ollama\"/\"none\" for local servers)\n# model = \"gpt-5.5\"\n# num_ctx = 65536 # sizes the context-manager budget (default 65536); NOT sent to the API\n# max_output_tokens = 8192 # -> max_tokens / max_completion_tokens (default 4096); keep WELL below num_ctx\n# stop_sequences = [] # -> stop (default [])\n# # temperature / think are NOT applied by the openai driver today (no-ops) — omitted on purpose.\n\n# =============================================================================\n# Agents\n# =============================================================================\n\n# --- Stage 1: Specification --------------------------------------------------\n\n[agents.pm_spec]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.4\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #1 — the requirements analyst and spec author.\n\nINPUT: a raw user request (and any clarifying context the orchestrator gives you).\nOUTPUT: a complete, testable specification. Do NOT include implementation detail\nor technology choices — that is the Architect's job.\n\nProduce, in this order:\n1. Problem & Goal — one paragraph: what outcome the user actually wants.\n2. Scope — explicit \"In scope\" and \"Out of scope\" bullet lists.\n3. Functional requirements — numbered, each a single observable behavior.\n4. Non-functional requirements — performance, security, compatibility, UX.\n5. Acceptance Criteria — a NUMBERED list (AC1, AC2, …). Every criterion MUST be\n objectively verifiable by an automated test or a concrete manual check.\n Use Given/When/Then phrasing where it adds precision. No vague words\n (\"fast\", \"robust\", \"user-friendly\") unless quantified.\n6. Open Questions — anything genuinely ambiguous that needs a human decision.\n\nRuthlessly apply YAGNI: do not invent features the user did not ask for.\nIf the request is too large for one spec, say so and propose a decomposition.\n\"\"\"\n\n[agents.pm_review]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.2\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #2 — the independent spec reviewer.\n\nINPUT: the original user request AND PM#1's specification.\nOUTPUT: a verdict plus findings.\n\nVerify, point by point:\n- Coverage: does every part of the user request map to a requirement?\n- Testability: is each Acceptance Criterion objectively verifiable? Flag any\n criterion that cannot be turned into a pass/fail check.\n- Clarity: any requirement open to two interpretations? Name both.\n- Scope: any requirement or AC that exceeds the user's actual ask (scope creep)?\n- Contradictions / gaps / missing non-functional requirements.\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED — if the spec is complete, testable, and in scope.\n VERDICT: CHANGES REQUIRED — otherwise.\nFollow it with a numbered findings list; each finding cites the spec item and\nstates the concrete change needed. Be specific and terse. No praise.\n\"\"\"\n\n# --- Stage 2: Architecture ---------------------------------------------------\n\n[agents.architect]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.3\nmax_output_tokens = 8192\nthink = \"high\"\nnum_ctx = 262144 # long window: hold the whole spec while splitting it into tasks (delays compaction)\nsystem_prompt = \"\"\"\nYou are the Architect — you turn an APPROVED spec into an implementation plan.\n\nINPUT: the approved specification.\nOUTPUT: a plan a competent engineer with zero prior context could execute.\n\nInclude:\n1. File structure — exact paths to create/modify, one responsibility each.\n2. Components & interfaces — names, signatures, parameter/return types, and how\n modules talk to each other. Make boundaries explicit and testable.\n3. Task breakdown — bite-sized tasks, each independently testable and tied to\n the spec's Acceptance Criteria it advances. Order them so each builds on the\n last. Note which tasks are parallelizable (for multiple senior_coder runs).\n4. Data flow & state ownership.\n5. Test strategy — what is unit-tested vs integration-tested, and how.\n6. Risks & mitigations.\n\nFollow existing codebase patterns; do not propose unrelated refactors. DRY,\nYAGNI, TDD. Every spec Acceptance Criterion must be covered by at least one task.\n\"\"\"\n\n[agents.architect_review]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Architecture Reviewer — independent of the Architect.\n\nINPUT: the approved spec AND the Architect's plan.\nOUTPUT: a verdict plus findings.\n\nCheck:\n- Spec coverage: does every Acceptance Criterion map to a planned task? List gaps.\n- Interface soundness: are the named signatures/types consistent across tasks?\n (A method called clearLayers() in one task and clearFullLayers() in another is a bug.)\n- Coupling & boundaries: any module doing too much, or leaky interfaces?\n- Test strategy: are the proposed tests real (asserting behavior), not vacuous?\n- Over-engineering: anything beyond what the spec requires (YAGNI violations)?\n- Task sizing & ordering: is each task independently testable and correctly sequenced?\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED\n VERDICT: CHANGES REQUIRED\nThen a numbered findings list, each citing the plan item and the required change.\n\"\"\"\n\n# --- Stage 3: Implementation -------------------------------------------------\n\n# Dispatch this agent 2-3 times in parallel, one well-scoped task each.\n[agents.senior_coder]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are a Senior Software Engineer implementing ONE well-scoped task from the plan.\n\nINPUT: a single task (with its interfaces and the Acceptance Criteria it serves).\nOUTPUT: working, tested code for THAT task only — do not wander into other tasks.\n\nWork TDD:\n1. Write the failing test(s) for the behavior.\n2. Run them; confirm they fail for the right reason.\n3. Write the minimal implementation to pass.\n4. Run the tests; confirm green. Run any adjacent tests your change could break.\n5. Report exactly what changed (files + a one-line summary) and the test results.\n\nMatch the surrounding code's style, naming, and patterns. DRY, YAGNI. If the\ntask is ambiguous or the plan's interface won't work, stop and say so precisely\nrather than guessing.\n\"\"\"\n\n[agents.qa_engineer]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are the QA Engineer — you build and run the test/QA suite.\n\nINPUT: the implemented code, the plan's test strategy, and the spec's Acceptance Criteria.\nOUTPUT: tests and a QA report.\n\nDo:\n1. Author the integration/end-to-end and edge-case tests the unit tests miss,\n following existing test patterns in the codebase.\n2. Run the full relevant suite (use the project's runner; run it in the background\n if long) and capture real output.\n3. Report: command run, pass/fail counts, and the actual failure output verbatim\n for anything red. Never claim green without showing the run.\n4. Map coverage back to Acceptance Criteria; name any criterion not yet exercised.\n\nReport failures faithfully. A skipped or flaky test is a finding, not a pass.\n\"\"\"\n\n# LOCAL agent — keep to ONE active instance (VRAM). Best for small, low-risk,\n# well-specified tasks: boilerplate, simple pure functions, mechanical edits.\n[agents.junior_coder]\nprovider = \"ollama_local\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\ntemperature = 0.2\nmax_output_tokens = 4096\nnum_ctx = 32768\nsystem_prompt = \"\"\"\nYou are a Junior Developer running on a LOCAL model. You take small, clearly\nspecified, low-risk tasks (boilerplate, simple functions, renames, mechanical\nedits, fixture data).\n\nINPUT: one small, unambiguous task.\nOUTPUT: the minimal code change plus the relevant test, run to green.\n\nRules:\n- Stay strictly within the task. Do not redesign or touch unrelated files.\n- Match existing patterns exactly.\n- If anything is ambiguous, risky, or larger than it first looked, STOP and\n escalate (\"BLOCKED: <reason>\") instead of guessing — a senior_coder will take it.\n- Always run the test covering your change and report the result.\n\"\"\"\n\n# --- Stage 4: Review & Gate --------------------------------------------------\n\n[agents.code_reviewer]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Code Reviewer. You review a diff for correctness and quality.\n\nINPUT: the diff (plus the plan/task it implements and the coding standards).\nOUTPUT: severity-tagged findings and a verdict.\n\nReview for:\n- Correctness & edge cases — logic errors, off-by-one, error handling, races.\n- Security — injection, unsafe input, secret handling, unsafe shell/file ops.\n- Tests — do they assert real behavior? Any vacuous or missing tests?\n- Spec/plan adherence — does the code do what the task required, no more (YAGNI)?\n- Readability & consistency with surrounding code.\n\nTag each finding Critical / Important / Minor, cite file:line, and give the fix.\nEnd with exactly one verdict line:\n VERDICT: APPROVED — no Critical/Important findings.\n VERDICT: CHANGES REQUIRED — otherwise.\nVerify before asserting; if you cannot tell from the diff, say so explicitly.\n\"\"\"\n\n[agents.acceptance_gate]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nnum_ctx = 262144 # long window: holds spec + all criteria + diff + test output at once\nsystem_prompt = \"\"\"\nYou are the Acceptance Gate — the final, independent check before \"done\".\n\nINPUT: the spec's Acceptance Criteria AND the final implementation + test results.\nOUTPUT: a per-criterion verdict and an overall gate decision.\n\nFor EACH Acceptance Criterion (AC1, AC2, …):\n- State PASS or FAIL.\n- Cite the concrete evidence: the test that proves it (and its result), or the\n code path, or the manual check. No evidence ⇒ FAIL.\n\nDo not re-review style or design — only whether the spec's criteria are met.\nBe strict: partial or unverifiable ⇒ FAIL. End with exactly one line:\n GATE: PASS — every Acceptance Criterion is PASS with evidence.\n GATE: FAIL — otherwise (list the failing AC numbers).\n\"\"\"\n"}, "5d99ae5547438064a6afe36c156099a874dfa1dc": {"t": 1785767758.861769, "n": 20366, "h": "f69950765065276c", "c": "# =============================================================================\n# ayder-cli — Multi-Agent SDLC Harness (example config)\n# =============================================================================\n#\n# A 9-role software-delivery pipeline backed by Ollama Cloud models, plus one\n# local model. Roles are matched to model strengths: reasoning-optimized models\n# drive planning / review / gating; coding-optimized models do the writing and\n# testing.\n#\n# Pipeline (orchestrator dispatches agents in this order):\n#\n# pm_spec ──▶ pm_review ──▶ architect ──▶ architect_review\n# │\n# ┌────────────────────────────────────────┘\n# ▼\n# senior_coder ×2-3 (+ junior_coder for small local tasks, 1 instance)\n# │\n# ▼\n# qa_engineer ──▶ code_reviewer ──▶ acceptance_gate\n#\n# Model → role assignment (grounded in published SWE-bench data, June 2026):\n#\n# Role Model Why\n# ---------------- -------------------------------- --------------------------------\n# pm_spec glm-5.2:cloud strong, token-efficient reasoning + structured writing\n# pm_review deepseek-v4-pro:cloud apex reasoner (~80.6% SWE-bench Verified); diff family from pm_spec\n# architect deepseek-v4-pro:cloud hardest reasoning task: system design\n# architect_review kimi-k2.7-code:cloud independent reviewer; strong coder, cross-family from the architect (deepseek)\n# senior_coder glm-5.2:cloud code-strong, token-efficient code generation; strong agentic coder\n# qa_engineer minimax-m3:cloud long-context coder; holds implementation + criteria while authoring tests\n# junior_coder qwen3.6:35b-a3b-coding-nvfp4 LOCAL MoE coder (3B active, nvfp4); only ONE active (memory)\n# code_reviewer kimi-k2.7-code:cloud 1T coding specialist; cross-family from the coders (glm)\n# acceptance_gate minimax-m3:cloud long-context lineage; holds spec + criteria + diff + tests at once\n#\n# Review boundaries cross model families so a reviewer does not share the\n# author's blind spots (glm↔deepseek at PM, deepseek↔kimi at architecture,\n# glm↔kimi at code review, everything↔minimax at the final gate).\n#\n# gemma4:31b-cloud is the lightest dense model in your set. It is NOT wired to a\n# frontier gate on purpose (under-powering a gate defeats it); it is provided\n# below as a ready budget/throughput swap — see [llm.ollama_cloud_budget].\n#\n# AUTH — two ways to reach `:cloud` models (this file defaults to #1):\n# 1. Via the LOCAL daemon (recommended): base_url = \"http://localhost:11434\".\n# The daemon authenticates cloud models with ~/.ollama/id_ed25519 after a\n# one-time `ollama signin`. No env var needed. (Requires the daemon running.)\n# 2. Direct to cloud: base_url = \"https://ollama.com\" (no /v1) AND\n# `export OLLAMA_API_KEY=\"<key>\"`. The api_key config field is INERT on the\n# native path, so a missing env var ⇒ 401 Unauthorized.\n#\n# NOTE on `think`: on the native `ollama` driver, ayder defaults thinking ON\n# (think = true) and forwards either a boolean or Ollama's \"low\",\n# \"medium\", \"high\" levels. If a selected model rejects thinking mode,\n# ayder retries that request once with think=false. Set `think = false`\n# in an [llm.*] profile for known non-thinking models. The `openai`\n# driver sends no reasoning-effort parameter at all.\n#\n# NOTE on tuning knobs — which actually take effect depends on the DRIVER. These\n# agents run on the native `ollama` driver, which ignores most of them:\n# • temperature — forwarded by NO driver yet ⇒ no effect anywhere.\n# • max_output_tokens — NOT sent on the ollama path (Ollama sizes\n# generation itself); honored only by the\n# openai-family drivers as max_tokens. Default 4096.\n# • think — sent on the ollama path (default true; accepts\n# false or \"low\"/\"medium\"/\"high\"); openai sends\n# none.\n# • num_ctx — on ollama it is provisional only (the real window\n# is auto-detected from /api/show); on the openai\n# path it sizes the context-manager budget.\n# Default 65536.\n# The per-agent temperature / max_output_tokens values below are largely\n# INERT on this Ollama pipeline; per-agent `think` is applied when the\n# agent uses the native ollama driver.\n# =============================================================================\n\nconfig_version = \"2.0\"\n\n[app]\nprovider = \"ollama_cloud\" # active profile for the ORCHESTRATOR session (see [llm.ollama_cloud])\neditor = \"vim\"\nverbose = false\nprompt = \"STANDARD\" # MINIMAL | STANDARD | EXTENDED\nmax_background_processes = 5 # cap on concurrent background processes (e.g. test runs)\nmax_concurrent_agents = 5 # max agents running at once; extra dispatches queue (1-20)\nmax_output_tokens = 8192 # orchestrator response cap\n# Max conversation messages kept per turn. 0 = unlimited (default): the context\n# manager's token budget + compaction are the bound, so the model uses its real\n# window. A small fixed cap (the old default was 30) thrashes a tiny history\n# window on a large-context model and wastes most of it. Set a finite number\n# only if you want a hard message cap regardless of window size.\nmax_history_messages = 0\nagent_timeout = 1800 # seconds before a background agent is cancelled (30 min; reasoning+coding can be slow)\n# Tools the agents inherit. A coding harness needs file/shell/search (core),\n# tasks/notes (metadata), background process control for test suites\n# (background), and web fetch (http). See /plugin for the full tag list.\ntool_tags = [\"core\", \"metadata\", \"background\", \"http\"]\n\n[ui]\n# TUI layout (theme) — picks the chrome/layout:\n# \"ayder\" (default) — linux-console layout (tokenised), respects the terminal\n# by default and can overlay any palette (see below).\n# \"ayder-dark\" — \"ayder\" + default ANSI-dark palette.\n# \"ayder-light\" — \"ayder\" + default ANSI-light palette (light terminals).\n# \"claude\" — dark navy aesthetic with explicit RGB colors.\ntheme = \"ayder\"\n#\n# Palette — the colour palette the \"ayder\" layout is painted with (App.theme).\n# Ignored by the self-contained \"claude\" theme.\n# \"auto\" (default) — the layout's own ANSI palette: passthrough that respects\n# your terminal's background and palette on every terminal.\n# \"ansi-dark\"/\"ansi-light\" — force the ANSI passthrough palette explicitly.\n# \"monokai\", \"dracula\", \"nord\", \"gruvbox\", \"tokyo-night\", … — any Textual theme\n# overlays a fixed RGB palette on the ayder layout. NOTE:\n# these paint their OWN background and therefore do NOT\n# respect the terminal background — an opt-in trade-off.\n# e.g. theme = \"ayder\" + palette = \"monokai\" → \"ayder-monokai\".\npalette = \"auto\"\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n\n[context_manager]\nenabled = true\n# Destructive tool-result compression is OPT-IN and OFF by default. It summarizes\n# old tool results in place (lossy) and thrashes the KV cache, so leave it off\n# unless you specifically want it; eviction will replace it in a later release.\nenable_compression = false\n# max_context_tokens is OPTIONAL. When unset (recommended), the budget is derived\n# from the active model's num_ctx. It is read only on the openai/non-ollama path\n# (DefaultContextManager); the native Ollama path auto-detects the real window\n# from /api/show and ignores it. reserve_ratio + compaction_threshold ARE read on\n# both paths.\n# max_context_tokens = 131072\nreserve_ratio = 0.30\ncompaction_threshold = 0.80\n\n[retry]\nenabled = true\nmax_attempts = 3\ninitial_delay_seconds = 0.5\nmax_delay_seconds = 30.0\nbackoff_coefficient = 2.0\njitter = true\n\n# -----------------------------------------------------------------------------\n# Provider profiles\n# -----------------------------------------------------------------------------\n\n[llm.ollama_cloud]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\" # route :cloud models through the LOCAL daemon (auth via ~/.ollama/id_ed25519, one-time `ollama signin`)\nmodel = \"deepseek-v4-pro:cloud\" # orchestrator default; per-agent `model` overrides this\nnum_ctx = 131072\nthink = true # default; set false for known non-thinking models\n# To hit ollama.com directly instead, swap the line above for:\n# base_url = \"https://ollama.com\" # no /v1; then `export OLLAMA_API_KEY=<key>` (the api_key field is inert on this path)\n\n[llm.ollama_local]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\nnum_ctx = 32768 # keep modest: local VRAM is the constraint\nthink = true # default; set false if the selected model rejects thinking\n\n# Budget/throughput alternative — swap any cloud agent's `provider` to this, or\n# point a duplicate reviewer at it for cheap parallel passes.\n# [llm.ollama_cloud_budget]\n# driver = \"ollama\"\n# base_url = \"https://ollama.com\"\n# model = \"gemma4:31b-cloud\"\n# num_ctx = 131072\n\n# OpenAI-compatible driver. Unlike the `ollama` driver above, this one HONORS the\n# tuning knobs (defaults shown). Use it for api.openai.com, Azure, vLLM,\n# llama.cpp, LM Studio, or Ollama's own `/v1` endpoint. Point an agent at it with\n# `provider = \"openai\"`.\n# [llm.openai]\n# driver = \"openai\"\n# base_url = \"https://api.openai.com/v1\" # OpenAI-compatible endpoint\n# api_key = \"sk-...\" # your key (or \"ollama\"/\"none\" for local servers)\n# model = \"gpt-5.5\"\n# num_ctx = 65536 # sizes the context-manager budget (default 65536); NOT sent to the API\n# max_output_tokens = 8192 # -> max_tokens / max_completion_tokens (default 4096); keep WELL below num_ctx\n# stop_sequences = [] # -> stop (default [])\n# # temperature / think are NOT applied by the openai driver today (no-ops) — omitted on purpose.\n\n# =============================================================================\n# Agents\n# =============================================================================\n\n# --- Stage 1: Specification --------------------------------------------------\n\n[agents.pm_spec]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.4\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #1 — the requirements analyst and spec author.\n\nINPUT: a raw user request (and any clarifying context the orchestrator gives you).\nOUTPUT: a complete, testable specification. Do NOT include implementation detail\nor technology choices — that is the Architect's job.\n\nProduce, in this order:\n1. Problem & Goal — one paragraph: what outcome the user actually wants.\n2. Scope — explicit \"In scope\" and \"Out of scope\" bullet lists.\n3. Functional requirements — numbered, each a single observable behavior.\n4. Non-functional requirements — performance, security, compatibility, UX.\n5. Acceptance Criteria — a NUMBERED list (AC1, AC2, …). Every criterion MUST be\n objectively verifiable by an automated test or a concrete manual check.\n Use Given/When/Then phrasing where it adds precision. No vague words\n (\"fast\", \"robust\", \"user-friendly\") unless quantified.\n6. Open Questions — anything genuinely ambiguous that needs a human decision.\n\nRuthlessly apply YAGNI: do not invent features the user did not ask for.\nIf the request is too large for one spec, say so and propose a decomposition.\n\"\"\"\n\n[agents.pm_review]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.2\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #2 — the independent spec reviewer.\n\nINPUT: the original user request AND PM#1's specification.\nOUTPUT: a verdict plus findings.\n\nVerify, point by point:\n- Coverage: does every part of the user request map to a requirement?\n- Testability: is each Acceptance Criterion objectively verifiable? Flag any\n criterion that cannot be turned into a pass/fail check.\n- Clarity: any requirement open to two interpretations? Name both.\n- Scope: any requirement or AC that exceeds the user's actual ask (scope creep)?\n- Contradictions / gaps / missing non-functional requirements.\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED — if the spec is complete, testable, and in scope.\n VERDICT: CHANGES REQUIRED — otherwise.\nFollow it with a numbered findings list; each finding cites the spec item and\nstates the concrete change needed. Be specific and terse. No praise.\n\"\"\"\n\n# --- Stage 2: Architecture ---------------------------------------------------\n\n[agents.architect]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.3\nmax_output_tokens = 8192\nthink = \"high\"\nnum_ctx = 262144 # long window: hold the whole spec while splitting it into tasks (delays compaction)\nsystem_prompt = \"\"\"\nYou are the Architect — you turn an APPROVED spec into an implementation plan.\n\nINPUT: the approved specification.\nOUTPUT: a plan a competent engineer with zero prior context could execute.\n\nInclude:\n1. File structure — exact paths to create/modify, one responsibility each.\n2. Components & interfaces — names, signatures, parameter/return types, and how\n modules talk to each other. Make boundaries explicit and testable.\n3. Task breakdown — bite-sized tasks, each independently testable and tied to\n the spec's Acceptance Criteria it advances. Order them so each builds on the\n last. Note which tasks are parallelizable (for multiple senior_coder runs).\n4. Data flow & state ownership.\n5. Test strategy — what is unit-tested vs integration-tested, and how.\n6. Risks & mitigations.\n\nFollow existing codebase patterns; do not propose unrelated refactors. DRY,\nYAGNI, TDD. Every spec Acceptance Criterion must be covered by at least one task.\n\"\"\"\n\n[agents.architect_review]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Architecture Reviewer — independent of the Architect.\n\nINPUT: the approved spec AND the Architect's plan.\nOUTPUT: a verdict plus findings.\n\nCheck:\n- Spec coverage: does every Acceptance Criterion map to a planned task? List gaps.\n- Interface soundness: are the named signatures/types consistent across tasks?\n (A method called clearLayers() in one task and clearFullLayers() in another is a bug.)\n- Coupling & boundaries: any module doing too much, or leaky interfaces?\n- Test strategy: are the proposed tests real (asserting behavior), not vacuous?\n- Over-engineering: anything beyond what the spec requires (YAGNI violations)?\n- Task sizing & ordering: is each task independently testable and correctly sequenced?\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED\n VERDICT: CHANGES REQUIRED\nThen a numbered findings list, each citing the plan item and the required change.\n\"\"\"\n\n# --- Stage 3: Implementation -------------------------------------------------\n\n# Dispatch this agent 2-3 times in parallel, one well-scoped task each.\n[agents.senior_coder]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are a Senior Software Engineer implementing ONE well-scoped task from the plan.\n\nINPUT: a single task (with its interfaces and the Acceptance Criteria it serves).\nOUTPUT: working, tested code for THAT task only — do not wander into other tasks.\n\nWork TDD:\n1. Write the failing test(s) for the behavior.\n2. Run them; confirm they fail for the right reason.\n3. Write the minimal implementation to pass.\n4. Run the tests; confirm green. Run any adjacent tests your change could break.\n5. Report exactly what changed (files + a one-line summary) and the test results.\n\nMatch the surrounding code's style, naming, and patterns. DRY, YAGNI. If the\ntask is ambiguous or the plan's interface won't work, stop and say so precisely\nrather than guessing.\n\"\"\"\n\n[agents.qa_engineer]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are the QA Engineer — you build and run the test/QA suite.\n\nINPUT: the implemented code, the plan's test strategy, and the spec's Acceptance Criteria.\nOUTPUT: tests and a QA report.\n\nDo:\n1. Author the integration/end-to-end and edge-case tests the unit tests miss,\n following existing test patterns in the codebase.\n2. Run the full relevant suite (use the project's runner; run it in the background\n if long) and capture real output.\n3. Report: command run, pass/fail counts, and the actual failure output verbatim\n for anything red. Never claim green without showing the run.\n4. Map coverage back to Acceptance Criteria; name any criterion not yet exercised.\n\nReport failures faithfully. A skipped or flaky test is a finding, not a pass.\n\"\"\"\n\n# LOCAL agent — keep to ONE active instance (VRAM). Best for small, low-risk,\n# well-specified tasks: boilerplate, simple pure functions, mechanical edits.\n[agents.junior_coder]\nprovider = \"ollama_local\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\ntemperature = 0.2\nmax_output_tokens = 4096\nnum_ctx = 32768\nsystem_prompt = \"\"\"\nYou are a Junior Developer running on a LOCAL model. You take small, clearly\nspecified, low-risk tasks (boilerplate, simple functions, renames, mechanical\nedits, fixture data).\n\nINPUT: one small, unambiguous task.\nOUTPUT: the minimal code change plus the relevant test, run to green.\n\nRules:\n- Stay strictly within the task. Do not redesign or touch unrelated files.\n- Match existing patterns exactly.\n- If anything is ambiguous, risky, or larger than it first looked, STOP and\n escalate (\"BLOCKED: <reason>\") instead of guessing — a senior_coder will take it.\n- Always run the test covering your change and report the result.\n\"\"\"\n\n# --- Stage 4: Review & Gate --------------------------------------------------\n\n[agents.code_reviewer]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Code Reviewer. You review a diff for correctness and quality.\n\nINPUT: the diff (plus the plan/task it implements and the coding standards).\nOUTPUT: severity-tagged findings and a verdict.\n\nReview for:\n- Correctness & edge cases — logic errors, off-by-one, error handling, races.\n- Security — injection, unsafe input, secret handling, unsafe shell/file ops.\n- Tests — do they assert real behavior? Any vacuous or missing tests?\n- Spec/plan adherence — does the code do what the task required, no more (YAGNI)?\n- Readability & consistency with surrounding code.\n\nTag each finding Critical / Important / Minor, cite file:line, and give the fix.\nEnd with exactly one verdict line:\n VERDICT: APPROVED — no Critical/Important findings.\n VERDICT: CHANGES REQUIRED — otherwise.\nVerify before asserting; if you cannot tell from the diff, say so explicitly.\n\"\"\"\n\n[agents.acceptance_gate]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nnum_ctx = 262144 # long window: holds spec + all criteria + diff + test output at once\nsystem_prompt = \"\"\"\nYou are the Acceptance Gate — the final, independent check before \"done\".\n\nINPUT: the spec's Acceptance Criteria AND the final implementation + test results.\nOUTPUT: a per-criterion verdict and an overall gate decision.\n\nFor EACH Acceptance Criterion (AC1, AC2, …):\n- State PASS or FAIL.\n- Cite the concrete evidence: the test that proves it (and its result), or the\n code path, or the manual check. No evidence ⇒ FAIL.\n\nDo not re-review style or design — only whether the spec's criteria are met.\nBe strict: partial or unverifiable ⇒ FAIL. End with exactly one line:\n GATE: PASS — every Acceptance Criterion is PASS with evidence.\n GATE: FAIL — otherwise (list the failing AC numbers).\n\"\"\"\n"}, "dae4b11ef2dddc3541260fd8846175329d8310c9": {"t": 1785767760.573032, "n": 20140, "h": "508ae122bbbe2e3d", "c": "# =============================================================================\n# ayder-cli — Multi-Agent SDLC Harness (example config)\n# =============================================================================\n#\n# A 9-role software-delivery pipeline backed by Ollama Cloud models, plus one\n# local model. Roles are matched to model strengths: reasoning-optimized models\n# drive planning / review / gating; coding-optimized models do the writing and\n# testing.\n#\n# Pipeline (orchestrator dispatches agents in this order):\n#\n# pm_spec ──▶ pm_review ──▶ architect ──▶ architect_review\n# │\n# ┌────────────────────────────────────────┘\n# ▼\n# senior_coder ×2-3 (+ junior_coder for small local tasks, 1 instance)\n# │\n# ▼\n# qa_engineer ──▶ code_reviewer ──▶ acceptance_gate\n#\n# Model → role assignment (grounded in published SWE-bench data, June 2026):\n#\n# Role Model Why\n# ---------------- -------------------------------- --------------------------------\n# pm_spec glm-5.2:cloud strong, token-efficient reasoning + structured writing\n# pm_review deepseek-v4-pro:cloud apex reasoner (~80.6% SWE-bench Verified); diff family from pm_spec\n# architect deepseek-v4-pro:cloud hardest reasoning task: system design\n# architect_review kimi-k2.7-code:cloud independent reviewer; strong coder, cross-family from the architect (deepseek)\n# senior_coder glm-5.2:cloud code-strong, token-efficient code generation; strong agentic coder\n# qa_engineer minimax-m3:cloud long-context coder; holds implementation + criteria while authoring tests\n# junior_coder qwen3.6:35b-a3b-coding-nvfp4 LOCAL MoE coder (3B active, nvfp4); only ONE active (memory)\n# code_reviewer kimi-k2.7-code:cloud 1T coding specialist; cross-family from the coders (glm)\n# acceptance_gate minimax-m3:cloud long-context lineage; holds spec + criteria + diff + tests at once\n#\n# Review boundaries cross model families so a reviewer does not share the\n# author's blind spots (glm↔deepseek at PM, deepseek↔kimi at architecture,\n# glm↔kimi at code review, everything↔minimax at the final gate).\n#\n# gemma4:31b-cloud is the lightest dense model in your set. It is NOT wired to a\n# frontier gate on purpose (under-powering a gate defeats it); it is provided\n# below as a ready budget/throughput swap — see [llm.ollama_cloud_budget].\n#\n# AUTH — two ways to reach `:cloud` models (this file defaults to #1):\n# 1. Via the LOCAL daemon (recommended): base_url = \"http://localhost:11434\".\n# The daemon authenticates cloud models with ~/.ollama/id_ed25519 after a\n# one-time `ollama signin`. No env var needed. (Requires the daemon running.)\n# 2. Direct to cloud: base_url = \"https://ollama.com\" (no /v1) AND\n# `export OLLAMA_API_KEY=\"<key>\"`. The api_key config field is INERT on the\n# native path, so a missing env var ⇒ 401 Unauthorized.\n#\n# NOTE on `think`: on the native `ollama` driver, ayder hardcodes thinking ON\n# (think=True) and does NOT forward the configured level — so a\n# `think = \"high\"` below documents intent, but the \"low/medium/high\"\n# granularity is not applied. The `openai` driver sends no reasoning-effort\n# parameter at all.\n#\n# NOTE on tuning knobs — which actually take effect depends on the DRIVER. These\n# agents run on the native `ollama` driver, which ignores most of them:\n# • temperature — forwarded by NO driver yet ⇒ no effect anywhere.\n# • max_output_tokens — NOT sent on the ollama path (Ollama sizes\n# generation itself); honored only by the\n# openai-family drivers as max_tokens. Default 4096.\n# • think — hardcoded ON for ollama (level ignored); openai\n# sends none.\n# • num_ctx — on ollama it is provisional only (the real window\n# is auto-detected from /api/show); on the openai\n# path it sizes the context-manager budget.\n# Default 65536.\n# The per-agent temperature / max_output_tokens / think values below are\n# therefore largely INERT on this Ollama pipeline — they are kept to\n# document intent and to carry over if you switch an agent to an `openai`\n# profile. To actually tune these, use the `openai` driver — see\n# [llm.openai] below.\n# =============================================================================\n\nconfig_version = \"2.0\"\n\n[app]\nprovider = \"ollama_cloud\" # active profile for the ORCHESTRATOR session (see [llm.ollama_cloud])\neditor = \"vim\"\nverbose = false\nprompt = \"STANDARD\" # MINIMAL | STANDARD | EXTENDED\nmax_background_processes = 5 # cap on concurrent background processes (e.g. test runs)\nmax_concurrent_agents = 5 # max agents running at once; extra dispatches queue (1-20)\nmax_output_tokens = 8192 # orchestrator response cap\n# Max conversation messages kept per turn. 0 = unlimited (default): the context\n# manager's token budget + compaction are the bound, so the model uses its real\n# window. A small fixed cap (the old default was 30) thrashes a tiny history\n# window on a large-context model and wastes most of it. Set a finite number\n# only if you want a hard message cap regardless of window size.\nmax_history_messages = 0\nagent_timeout = 1800 # seconds before a background agent is cancelled (30 min; reasoning+coding can be slow)\n# Tools the agents inherit. A coding harness needs file/shell/search (core),\n# tasks/notes (metadata), background process control for test suites\n# (background), and web fetch (http). See /plugin for the full tag list.\ntool_tags = [\"core\", \"metadata\", \"background\", \"http\"]\n\n[ui]\n# TUI layout (theme) — picks the chrome/layout:\n# \"ayder\" (default) — linux-console layout (tokenised), respects the terminal\n# by default and can overlay any palette (see below).\n# \"ayder-dark\" — \"ayder\" + default ANSI-dark palette.\n# \"ayder-light\" — \"ayder\" + default ANSI-light palette (light terminals).\n# \"claude\" — dark navy aesthetic with explicit RGB colors.\ntheme = \"ayder\"\n#\n# Palette — the colour palette the \"ayder\" layout is painted with (App.theme).\n# Ignored by the self-contained \"claude\" theme.\n# \"auto\" (default) — the layout's own ANSI palette: passthrough that respects\n# your terminal's background and palette on every terminal.\n# \"ansi-dark\"/\"ansi-light\" — force the ANSI passthrough palette explicitly.\n# \"monokai\", \"dracula\", \"nord\", \"gruvbox\", \"tokyo-night\", … — any Textual theme\n# overlays a fixed RGB palette on the ayder layout. NOTE:\n# these paint their OWN background and therefore do NOT\n# respect the terminal background — an opt-in trade-off.\n# e.g. theme = \"ayder\" + palette = \"monokai\" → \"ayder-monokai\".\npalette = \"auto\"\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n\n[context_manager]\nenabled = true\n# Destructive tool-result compression is OPT-IN and OFF by default. It summarizes\n# old tool results in place (lossy) and thrashes the KV cache, so leave it off\n# unless you specifically want it; eviction will replace it in a later release.\nenable_compression = false\n# max_context_tokens is OPTIONAL. When unset (recommended), the budget is derived\n# from the active model's num_ctx. It is read only on the openai/non-ollama path\n# (DefaultContextManager); the native Ollama path auto-detects the real window\n# from /api/show and ignores it. reserve_ratio + compaction_threshold ARE read on\n# both paths.\n# max_context_tokens = 131072\nreserve_ratio = 0.30\ncompaction_threshold = 0.80\n\n[retry]\nenabled = true\nmax_attempts = 3\ninitial_delay_seconds = 0.5\nmax_delay_seconds = 30.0\nbackoff_coefficient = 2.0\njitter = true\n\n# -----------------------------------------------------------------------------\n# Provider profiles\n# -----------------------------------------------------------------------------\n\n[llm.ollama_cloud]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\" # route :cloud models through the LOCAL daemon (auth via ~/.ollama/id_ed25519, one-time `ollama signin`)\nmodel = \"deepseek-v4-pro:cloud\" # orchestrator default; per-agent `model` overrides this\nnum_ctx = 131072\n# To hit ollama.com directly instead, swap the line above for:\n# base_url = \"https://ollama.com\" # no /v1; then `export OLLAMA_API_KEY=<key>` (the api_key field is inert on this path)\n\n[llm.ollama_local]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\nnum_ctx = 32768 # keep modest: local VRAM is the constraint\n\n# Budget/throughput alternative — swap any cloud agent's `provider` to this, or\n# point a duplicate reviewer at it for cheap parallel passes.\n# [llm.ollama_cloud_budget]\n# driver = \"ollama\"\n# base_url = \"https://ollama.com\"\n# model = \"gemma4:31b-cloud\"\n# num_ctx = 131072\n\n# OpenAI-compatible driver. Unlike the `ollama` driver above, this one HONORS the\n# tuning knobs (defaults shown). Use it for api.openai.com, Azure, vLLM,\n# llama.cpp, LM Studio, or Ollama's own `/v1` endpoint. Point an agent at it with\n# `provider = \"openai\"`.\n# [llm.openai]\n# driver = \"openai\"\n# base_url = \"https://api.openai.com/v1\" # OpenAI-compatible endpoint\n# api_key = \"sk-...\" # your key (or \"ollama\"/\"none\" for local servers)\n# model = \"gpt-5.5\"\n# num_ctx = 65536 # sizes the context-manager budget (default 65536); NOT sent to the API\n# max_output_tokens = 8192 # -> max_tokens / max_completion_tokens (default 4096); keep WELL below num_ctx\n# stop_sequences = [] # -> stop (default [])\n# # temperature / think are NOT applied by the openai driver today (no-ops) — omitted on purpose.\n\n# =============================================================================\n# Agents\n# =============================================================================\n\n# --- Stage 1: Specification --------------------------------------------------\n\n[agents.pm_spec]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.4\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #1 — the requirements analyst and spec author.\n\nINPUT: a raw user request (and any clarifying context the orchestrator gives you).\nOUTPUT: a complete, testable specification. Do NOT include implementation detail\nor technology choices — that is the Architect's job.\n\nProduce, in this order:\n1. Problem & Goal — one paragraph: what outcome the user actually wants.\n2. Scope — explicit \"In scope\" and \"Out of scope\" bullet lists.\n3. Functional requirements — numbered, each a single observable behavior.\n4. Non-functional requirements — performance, security, compatibility, UX.\n5. Acceptance Criteria — a NUMBERED list (AC1, AC2, …). Every criterion MUST be\n objectively verifiable by an automated test or a concrete manual check.\n Use Given/When/Then phrasing where it adds precision. No vague words\n (\"fast\", \"robust\", \"user-friendly\") unless quantified.\n6. Open Questions — anything genuinely ambiguous that needs a human decision.\n\nRuthlessly apply YAGNI: do not invent features the user did not ask for.\nIf the request is too large for one spec, say so and propose a decomposition.\n\"\"\"\n\n[agents.pm_review]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.2\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #2 — the independent spec reviewer.\n\nINPUT: the original user request AND PM#1's specification.\nOUTPUT: a verdict plus findings.\n\nVerify, point by point:\n- Coverage: does every part of the user request map to a requirement?\n- Testability: is each Acceptance Criterion objectively verifiable? Flag any\n criterion that cannot be turned into a pass/fail check.\n- Clarity: any requirement open to two interpretations? Name both.\n- Scope: any requirement or AC that exceeds the user's actual ask (scope creep)?\n- Contradictions / gaps / missing non-functional requirements.\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED — if the spec is complete, testable, and in scope.\n VERDICT: CHANGES REQUIRED — otherwise.\nFollow it with a numbered findings list; each finding cites the spec item and\nstates the concrete change needed. Be specific and terse. No praise.\n\"\"\"\n\n# --- Stage 2: Architecture ---------------------------------------------------\n\n[agents.architect]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.3\nmax_output_tokens = 8192\nthink = \"high\"\nnum_ctx = 262144 # long window: hold the whole spec while splitting it into tasks (delays compaction)\nsystem_prompt = \"\"\"\nYou are the Architect — you turn an APPROVED spec into an implementation plan.\n\nINPUT: the approved specification.\nOUTPUT: a plan a competent engineer with zero prior context could execute.\n\nInclude:\n1. File structure — exact paths to create/modify, one responsibility each.\n2. Components & interfaces — names, signatures, parameter/return types, and how\n modules talk to each other. Make boundaries explicit and testable.\n3. Task breakdown — bite-sized tasks, each independently testable and tied to\n the spec's Acceptance Criteria it advances. Order them so each builds on the\n last. Note which tasks are parallelizable (for multiple senior_coder runs).\n4. Data flow & state ownership.\n5. Test strategy — what is unit-tested vs integration-tested, and how.\n6. Risks & mitigations.\n\nFollow existing codebase patterns; do not propose unrelated refactors. DRY,\nYAGNI, TDD. Every spec Acceptance Criterion must be covered by at least one task.\n\"\"\"\n\n[agents.architect_review]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Architecture Reviewer — independent of the Architect.\n\nINPUT: the approved spec AND the Architect's plan.\nOUTPUT: a verdict plus findings.\n\nCheck:\n- Spec coverage: does every Acceptance Criterion map to a planned task? List gaps.\n- Interface soundness: are the named signatures/types consistent across tasks?\n (A method called clearLayers() in one task and clearFullLayers() in another is a bug.)\n- Coupling & boundaries: any module doing too much, or leaky interfaces?\n- Test strategy: are the proposed tests real (asserting behavior), not vacuous?\n- Over-engineering: anything beyond what the spec requires (YAGNI violations)?\n- Task sizing & ordering: is each task independently testable and correctly sequenced?\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED\n VERDICT: CHANGES REQUIRED\nThen a numbered findings list, each citing the plan item and the required change.\n\"\"\"\n\n# --- Stage 3: Implementation -------------------------------------------------\n\n# Dispatch this agent 2-3 times in parallel, one well-scoped task each.\n[agents.senior_coder]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are a Senior Software Engineer implementing ONE well-scoped task from the plan.\n\nINPUT: a single task (with its interfaces and the Acceptance Criteria it serves).\nOUTPUT: working, tested code for THAT task only — do not wander into other tasks.\n\nWork TDD:\n1. Write the failing test(s) for the behavior.\n2. Run them; confirm they fail for the right reason.\n3. Write the minimal implementation to pass.\n4. Run the tests; confirm green. Run any adjacent tests your change could break.\n5. Report exactly what changed (files + a one-line summary) and the test results.\n\nMatch the surrounding code's style, naming, and patterns. DRY, YAGNI. If the\ntask is ambiguous or the plan's interface won't work, stop and say so precisely\nrather than guessing.\n\"\"\"\n\n[agents.qa_engineer]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are the QA Engineer — you build and run the test/QA suite.\n\nINPUT: the implemented code, the plan's test strategy, and the spec's Acceptance Criteria.\nOUTPUT: tests and a QA report.\n\nDo:\n1. Author the integration/end-to-end and edge-case tests the unit tests miss,\n following existing test patterns in the codebase.\n2. Run the full relevant suite (use the project's runner; run it in the background\n if long) and capture real output.\n3. Report: command run, pass/fail counts, and the actual failure output verbatim\n for anything red. Never claim green without showing the run.\n4. Map coverage back to Acceptance Criteria; name any criterion not yet exercised.\n\nReport failures faithfully. A skipped or flaky test is a finding, not a pass.\n\"\"\"\n\n# LOCAL agent — keep to ONE active instance (VRAM). Best for small, low-risk,\n# well-specified tasks: boilerplate, simple pure functions, mechanical edits.\n[agents.junior_coder]\nprovider = \"ollama_local\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\ntemperature = 0.2\nmax_output_tokens = 4096\nnum_ctx = 32768\nsystem_prompt = \"\"\"\nYou are a Junior Developer running on a LOCAL model. You take small, clearly\nspecified, low-risk tasks (boilerplate, simple functions, renames, mechanical\nedits, fixture data).\n\nINPUT: one small, unambiguous task.\nOUTPUT: the minimal code change plus the relevant test, run to green.\n\nRules:\n- Stay strictly within the task. Do not redesign or touch unrelated files.\n- Match existing patterns exactly.\n- If anything is ambiguous, risky, or larger than it first looked, STOP and\n escalate (\"BLOCKED: <reason>\") instead of guessing — a senior_coder will take it.\n- Always run the test covering your change and report the result.\n\"\"\"\n\n# --- Stage 4: Review & Gate --------------------------------------------------\n\n[agents.code_reviewer]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Code Reviewer. You review a diff for correctness and quality.\n\nINPUT: the diff (plus the plan/task it implements and the coding standards).\nOUTPUT: severity-tagged findings and a verdict.\n\nReview for:\n- Correctness & edge cases — logic errors, off-by-one, error handling, races.\n- Security — injection, unsafe input, secret handling, unsafe shell/file ops.\n- Tests — do they assert real behavior? Any vacuous or missing tests?\n- Spec/plan adherence — does the code do what the task required, no more (YAGNI)?\n- Readability & consistency with surrounding code.\n\nTag each finding Critical / Important / Minor, cite file:line, and give the fix.\nEnd with exactly one verdict line:\n VERDICT: APPROVED — no Critical/Important findings.\n VERDICT: CHANGES REQUIRED — otherwise.\nVerify before asserting; if you cannot tell from the diff, say so explicitly.\n\"\"\"\n\n[agents.acceptance_gate]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nnum_ctx = 262144 # long window: holds spec + all criteria + diff + test output at once\nsystem_prompt = \"\"\"\nYou are the Acceptance Gate — the final, independent check before \"done\".\n\nINPUT: the spec's Acceptance Criteria AND the final implementation + test results.\nOUTPUT: a per-criterion verdict and an overall gate decision.\n\nFor EACH Acceptance Criterion (AC1, AC2, …):\n- State PASS or FAIL.\n- Cite the concrete evidence: the test that proves it (and its result), or the\n code path, or the manual check. No evidence ⇒ FAIL.\n\nDo not re-review style or design — only whether the spec's criteria are met.\nBe strict: partial or unverifiable ⇒ FAIL. End with exactly one line:\n GATE: PASS — every Acceptance Criterion is PASS with evidence.\n GATE: FAIL — otherwise (list the failing AC numbers).\n\"\"\"\n"}, "14d0cf47cf612b95ef7356ee61c2f91b15cd7e7e": {"t": 1785767761.933813, "n": 18916, "h": "b410283f38082981", "c": "# =============================================================================\n# ayder-cli — Multi-Agent SDLC Harness (example config)\n# =============================================================================\n#\n# A 9-role software-delivery pipeline backed by Ollama Cloud models, plus one\n# local model. Roles are matched to model strengths: reasoning-optimized models\n# drive planning / review / gating; coding-optimized models do the writing and\n# testing.\n#\n# Pipeline (orchestrator dispatches agents in this order):\n#\n# pm_spec ──▶ pm_review ──▶ architect ──▶ architect_review\n# │\n# ┌────────────────────────────────────────┘\n# ▼\n# senior_coder ×2-3 (+ junior_coder for small local tasks, 1 instance)\n# │\n# ▼\n# qa_engineer ──▶ code_reviewer ──▶ acceptance_gate\n#\n# Model → role assignment (grounded in published SWE-bench data, June 2026):\n#\n# Role Model Why\n# ---------------- -------------------------------- --------------------------------\n# pm_spec glm-5.2:cloud strong, token-efficient reasoning + structured writing\n# pm_review deepseek-v4-pro:cloud apex reasoner (~80.6% SWE-bench Verified); diff family from pm_spec\n# architect deepseek-v4-pro:cloud hardest reasoning task: system design\n# architect_review kimi-k2.7-code:cloud independent reviewer; strong coder, cross-family from the architect (deepseek)\n# senior_coder glm-5.2:cloud code-strong, token-efficient code generation; strong agentic coder\n# qa_engineer minimax-m3:cloud long-context coder; holds implementation + criteria while authoring tests\n# junior_coder qwen3.6:35b-a3b-coding-nvfp4 LOCAL MoE coder (3B active, nvfp4); only ONE active (memory)\n# code_reviewer kimi-k2.7-code:cloud 1T coding specialist; cross-family from the coders (glm)\n# acceptance_gate minimax-m3:cloud long-context lineage; holds spec + criteria + diff + tests at once\n#\n# Review boundaries cross model families so a reviewer does not share the\n# author's blind spots (glm↔deepseek at PM, deepseek↔kimi at architecture,\n# glm↔kimi at code review, everything↔minimax at the final gate).\n#\n# gemma4:31b-cloud is the lightest dense model in your set. It is NOT wired to a\n# frontier gate on purpose (under-powering a gate defeats it); it is provided\n# below as a ready budget/throughput swap — see [llm.ollama_cloud_budget].\n#\n# AUTH — two ways to reach `:cloud` models (this file defaults to #1):\n# 1. Via the LOCAL daemon (recommended): base_url = \"http://localhost:11434\".\n# The daemon authenticates cloud models with ~/.ollama/id_ed25519 after a\n# one-time `ollama signin`. No env var needed. (Requires the daemon running.)\n# 2. Direct to cloud: base_url = \"https://ollama.com\" (no /v1) AND\n# `export OLLAMA_API_KEY=\"<key>\"`. The api_key config field is INERT on the\n# native path, so a missing env var ⇒ 401 Unauthorized.\n#\n# NOTE on `think`: on the native `ollama` driver, ayder hardcodes thinking ON\n# (think=True) and does NOT forward the configured level — so a\n# `think = \"high\"` below documents intent, but the \"low/medium/high\"\n# granularity is not applied. The `openai` driver sends no reasoning-effort\n# parameter at all.\n#\n# NOTE on tuning knobs — which actually take effect depends on the DRIVER. These\n# agents run on the native `ollama` driver, which ignores most of them:\n# • temperature — forwarded by NO driver yet ⇒ no effect anywhere.\n# • max_output_tokens — NOT sent on the ollama path (Ollama sizes\n# generation itself); honored only by the\n# openai-family drivers as max_tokens. Default 4096.\n# • think — hardcoded ON for ollama (level ignored); openai\n# sends none.\n# • num_ctx — on ollama it is provisional only (the real window\n# is auto-detected from /api/show); on the openai\n# path it sizes the context-manager budget.\n# Default 65536.\n# The per-agent temperature / max_output_tokens / think values below are\n# therefore largely INERT on this Ollama pipeline — they are kept to\n# document intent and to carry over if you switch an agent to an `openai`\n# profile. To actually tune these, use the `openai` driver — see\n# [llm.openai] below.\n# =============================================================================\n\nconfig_version = \"2.0\"\n\n[app]\nprovider = \"ollama_cloud\" # active profile for the ORCHESTRATOR session (see [llm.ollama_cloud])\neditor = \"vim\"\nverbose = false\nprompt = \"STANDARD\" # MINIMAL | STANDARD | EXTENDED\nmax_background_processes = 5 # cap on concurrent background processes (e.g. test runs)\nmax_concurrent_agents = 5 # max agents running at once; extra dispatches queue (1-20)\nmax_output_tokens = 8192 # orchestrator response cap\n# Max conversation messages kept per turn. 0 = unlimited (default): the context\n# manager's token budget + compaction are the bound, so the model uses its real\n# window. A small fixed cap (the old default was 30) thrashes a tiny history\n# window on a large-context model and wastes most of it. Set a finite number\n# only if you want a hard message cap regardless of window size.\nmax_history_messages = 0\nagent_timeout = 1800 # seconds before a background agent is cancelled (30 min; reasoning+coding can be slow)\n# Tools the agents inherit. A coding harness needs file/shell/search (core),\n# tasks/notes (metadata), background process control for test suites\n# (background), and web fetch (http). See /plugin for the full tag list.\ntool_tags = [\"core\", \"metadata\", \"background\", \"http\"]\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n\n[context_manager]\nenabled = true\n# Destructive tool-result compression is OPT-IN and OFF by default. It summarizes\n# old tool results in place (lossy) and thrashes the KV cache, so leave it off\n# unless you specifically want it; eviction will replace it in a later release.\nenable_compression = false\n# max_context_tokens is OPTIONAL. When unset (recommended), the budget is derived\n# from the active model's num_ctx. It is read only on the openai/non-ollama path\n# (DefaultContextManager); the native Ollama path auto-detects the real window\n# from /api/show and ignores it. reserve_ratio + compaction_threshold ARE read on\n# both paths.\n# max_context_tokens = 131072\nreserve_ratio = 0.30\ncompaction_threshold = 0.80\n\n[retry]\nenabled = true\nmax_attempts = 3\ninitial_delay_seconds = 0.5\nmax_delay_seconds = 30.0\nbackoff_coefficient = 2.0\njitter = true\n\n# -----------------------------------------------------------------------------\n# Provider profiles\n# -----------------------------------------------------------------------------\n\n[llm.ollama_cloud]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\" # route :cloud models through the LOCAL daemon (auth via ~/.ollama/id_ed25519, one-time `ollama signin`)\nmodel = \"deepseek-v4-pro:cloud\" # orchestrator default; per-agent `model` overrides this\nnum_ctx = 131072\n# To hit ollama.com directly instead, swap the line above for:\n# base_url = \"https://ollama.com\" # no /v1; then `export OLLAMA_API_KEY=<key>` (the api_key field is inert on this path)\n\n[llm.ollama_local]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\nnum_ctx = 32768 # keep modest: local VRAM is the constraint\n\n# Budget/throughput alternative — swap any cloud agent's `provider` to this, or\n# point a duplicate reviewer at it for cheap parallel passes.\n# [llm.ollama_cloud_budget]\n# driver = \"ollama\"\n# base_url = \"https://ollama.com\"\n# model = \"gemma4:31b-cloud\"\n# num_ctx = 131072\n\n# OpenAI-compatible driver. Unlike the `ollama` driver above, this one HONORS the\n# tuning knobs (defaults shown). Use it for api.openai.com, Azure, vLLM,\n# llama.cpp, LM Studio, or Ollama's own `/v1` endpoint. Point an agent at it with\n# `provider = \"openai\"`.\n# [llm.openai]\n# driver = \"openai\"\n# base_url = \"https://api.openai.com/v1\" # OpenAI-compatible endpoint\n# api_key = \"sk-...\" # your key (or \"ollama\"/\"none\" for local servers)\n# model = \"gpt-5.5\"\n# num_ctx = 65536 # sizes the context-manager budget (default 65536); NOT sent to the API\n# max_output_tokens = 8192 # -> max_tokens / max_completion_tokens (default 4096); keep WELL below num_ctx\n# stop_sequences = [] # -> stop (default [])\n# # temperature / think are NOT applied by the openai driver today (no-ops) — omitted on purpose.\n\n# =============================================================================\n# Agents\n# =============================================================================\n\n# --- Stage 1: Specification --------------------------------------------------\n\n[agents.pm_spec]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.4\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #1 — the requirements analyst and spec author.\n\nINPUT: a raw user request (and any clarifying context the orchestrator gives you).\nOUTPUT: a complete, testable specification. Do NOT include implementation detail\nor technology choices — that is the Architect's job.\n\nProduce, in this order:\n1. Problem & Goal — one paragraph: what outcome the user actually wants.\n2. Scope — explicit \"In scope\" and \"Out of scope\" bullet lists.\n3. Functional requirements — numbered, each a single observable behavior.\n4. Non-functional requirements — performance, security, compatibility, UX.\n5. Acceptance Criteria — a NUMBERED list (AC1, AC2, …). Every criterion MUST be\n objectively verifiable by an automated test or a concrete manual check.\n Use Given/When/Then phrasing where it adds precision. No vague words\n (\"fast\", \"robust\", \"user-friendly\") unless quantified.\n6. Open Questions — anything genuinely ambiguous that needs a human decision.\n\nRuthlessly apply YAGNI: do not invent features the user did not ask for.\nIf the request is too large for one spec, say so and propose a decomposition.\n\"\"\"\n\n[agents.pm_review]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.2\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #2 — the independent spec reviewer.\n\nINPUT: the original user request AND PM#1's specification.\nOUTPUT: a verdict plus findings.\n\nVerify, point by point:\n- Coverage: does every part of the user request map to a requirement?\n- Testability: is each Acceptance Criterion objectively verifiable? Flag any\n criterion that cannot be turned into a pass/fail check.\n- Clarity: any requirement open to two interpretations? Name both.\n- Scope: any requirement or AC that exceeds the user's actual ask (scope creep)?\n- Contradictions / gaps / missing non-functional requirements.\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED — if the spec is complete, testable, and in scope.\n VERDICT: CHANGES REQUIRED — otherwise.\nFollow it with a numbered findings list; each finding cites the spec item and\nstates the concrete change needed. Be specific and terse. No praise.\n\"\"\"\n\n# --- Stage 2: Architecture ---------------------------------------------------\n\n[agents.architect]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.3\nmax_output_tokens = 8192\nthink = \"high\"\nnum_ctx = 262144 # long window: hold the whole spec while splitting it into tasks (delays compaction)\nsystem_prompt = \"\"\"\nYou are the Architect — you turn an APPROVED spec into an implementation plan.\n\nINPUT: the approved specification.\nOUTPUT: a plan a competent engineer with zero prior context could execute.\n\nInclude:\n1. File structure — exact paths to create/modify, one responsibility each.\n2. Components & interfaces — names, signatures, parameter/return types, and how\n modules talk to each other. Make boundaries explicit and testable.\n3. Task breakdown — bite-sized tasks, each independently testable and tied to\n the spec's Acceptance Criteria it advances. Order them so each builds on the\n last. Note which tasks are parallelizable (for multiple senior_coder runs).\n4. Data flow & state ownership.\n5. Test strategy — what is unit-tested vs integration-tested, and how.\n6. Risks & mitigations.\n\nFollow existing codebase patterns; do not propose unrelated refactors. DRY,\nYAGNI, TDD. Every spec Acceptance Criterion must be covered by at least one task.\n\"\"\"\n\n[agents.architect_review]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Architecture Reviewer — independent of the Architect.\n\nINPUT: the approved spec AND the Architect's plan.\nOUTPUT: a verdict plus findings.\n\nCheck:\n- Spec coverage: does every Acceptance Criterion map to a planned task? List gaps.\n- Interface soundness: are the named signatures/types consistent across tasks?\n (A method called clearLayers() in one task and clearFullLayers() in another is a bug.)\n- Coupling & boundaries: any module doing too much, or leaky interfaces?\n- Test strategy: are the proposed tests real (asserting behavior), not vacuous?\n- Over-engineering: anything beyond what the spec requires (YAGNI violations)?\n- Task sizing & ordering: is each task independently testable and correctly sequenced?\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED\n VERDICT: CHANGES REQUIRED\nThen a numbered findings list, each citing the plan item and the required change.\n\"\"\"\n\n# --- Stage 3: Implementation -------------------------------------------------\n\n# Dispatch this agent 2-3 times in parallel, one well-scoped task each.\n[agents.senior_coder]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are a Senior Software Engineer implementing ONE well-scoped task from the plan.\n\nINPUT: a single task (with its interfaces and the Acceptance Criteria it serves).\nOUTPUT: working, tested code for THAT task only — do not wander into other tasks.\n\nWork TDD:\n1. Write the failing test(s) for the behavior.\n2. Run them; confirm they fail for the right reason.\n3. Write the minimal implementation to pass.\n4. Run the tests; confirm green. Run any adjacent tests your change could break.\n5. Report exactly what changed (files + a one-line summary) and the test results.\n\nMatch the surrounding code's style, naming, and patterns. DRY, YAGNI. If the\ntask is ambiguous or the plan's interface won't work, stop and say so precisely\nrather than guessing.\n\"\"\"\n\n[agents.qa_engineer]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are the QA Engineer — you build and run the test/QA suite.\n\nINPUT: the implemented code, the plan's test strategy, and the spec's Acceptance Criteria.\nOUTPUT: tests and a QA report.\n\nDo:\n1. Author the integration/end-to-end and edge-case tests the unit tests miss,\n following existing test patterns in the codebase.\n2. Run the full relevant suite (use the project's runner; run it in the background\n if long) and capture real output.\n3. Report: command run, pass/fail counts, and the actual failure output verbatim\n for anything red. Never claim green without showing the run.\n4. Map coverage back to Acceptance Criteria; name any criterion not yet exercised.\n\nReport failures faithfully. A skipped or flaky test is a finding, not a pass.\n\"\"\"\n\n# LOCAL agent — keep to ONE active instance (VRAM). Best for small, low-risk,\n# well-specified tasks: boilerplate, simple pure functions, mechanical edits.\n[agents.junior_coder]\nprovider = \"ollama_local\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\ntemperature = 0.2\nmax_output_tokens = 4096\nnum_ctx = 32768\nsystem_prompt = \"\"\"\nYou are a Junior Developer running on a LOCAL model. You take small, clearly\nspecified, low-risk tasks (boilerplate, simple functions, renames, mechanical\nedits, fixture data).\n\nINPUT: one small, unambiguous task.\nOUTPUT: the minimal code change plus the relevant test, run to green.\n\nRules:\n- Stay strictly within the task. Do not redesign or touch unrelated files.\n- Match existing patterns exactly.\n- If anything is ambiguous, risky, or larger than it first looked, STOP and\n escalate (\"BLOCKED: <reason>\") instead of guessing — a senior_coder will take it.\n- Always run the test covering your change and report the result.\n\"\"\"\n\n# --- Stage 4: Review & Gate --------------------------------------------------\n\n[agents.code_reviewer]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Code Reviewer. You review a diff for correctness and quality.\n\nINPUT: the diff (plus the plan/task it implements and the coding standards).\nOUTPUT: severity-tagged findings and a verdict.\n\nReview for:\n- Correctness & edge cases — logic errors, off-by-one, error handling, races.\n- Security — injection, unsafe input, secret handling, unsafe shell/file ops.\n- Tests — do they assert real behavior? Any vacuous or missing tests?\n- Spec/plan adherence — does the code do what the task required, no more (YAGNI)?\n- Readability & consistency with surrounding code.\n\nTag each finding Critical / Important / Minor, cite file:line, and give the fix.\nEnd with exactly one verdict line:\n VERDICT: APPROVED — no Critical/Important findings.\n VERDICT: CHANGES REQUIRED — otherwise.\nVerify before asserting; if you cannot tell from the diff, say so explicitly.\n\"\"\"\n\n[agents.acceptance_gate]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nnum_ctx = 262144 # long window: holds spec + all criteria + diff + test output at once\nsystem_prompt = \"\"\"\nYou are the Acceptance Gate — the final, independent check before \"done\".\n\nINPUT: the spec's Acceptance Criteria AND the final implementation + test results.\nOUTPUT: a per-criterion verdict and an overall gate decision.\n\nFor EACH Acceptance Criterion (AC1, AC2, …):\n- State PASS or FAIL.\n- Cite the concrete evidence: the test that proves it (and its result), or the\n code path, or the manual check. No evidence ⇒ FAIL.\n\nDo not re-review style or design — only whether the spec's criteria are met.\nBe strict: partial or unverifiable ⇒ FAIL. End with exactly one line:\n GATE: PASS — every Acceptance Criterion is PASS with evidence.\n GATE: FAIL — otherwise (list the failing AC numbers).\n\"\"\"\n"}, "d64c02922f1433846f6ec01f4e4d394845ddf396": {"t": 1785767763.3549225, "n": 18820, "h": "c4b74ba455a00078", "c": "# =============================================================================\n# ayder-cli — Multi-Agent SDLC Harness (example config)\n# =============================================================================\n#\n# A 9-role software-delivery pipeline backed by Ollama Cloud models, plus one\n# local model. Roles are matched to model strengths: reasoning-optimized models\n# drive planning / review / gating; coding-optimized models do the writing and\n# testing.\n#\n# Pipeline (orchestrator dispatches agents in this order):\n#\n# pm_spec ──▶ pm_review ──▶ architect ──▶ architect_review\n# │\n# ┌────────────────────────────────────────┘\n# ▼\n# senior_coder ×2-3 (+ junior_coder for small local tasks, 1 instance)\n# │\n# ▼\n# qa_engineer ──▶ code_reviewer ──▶ acceptance_gate\n#\n# Model → role assignment (grounded in published SWE-bench data, June 2026):\n#\n# Role Model Why\n# ---------------- -------------------------------- --------------------------------\n# pm_spec glm-5.2:cloud strong, token-efficient reasoning + structured writing\n# pm_review deepseek-v4-pro:cloud apex reasoner (~80.6% SWE-bench Verified); diff family from pm_spec\n# architect deepseek-v4-pro:cloud hardest reasoning task: system design\n# architect_review kimi-k2.7-code:cloud independent reviewer; strong coder, cross-family from the architect (deepseek)\n# senior_coder glm-5.2:cloud code-strong, token-efficient code generation; strong agentic coder\n# qa_engineer minimax-m3:cloud long-context coder; holds implementation + criteria while authoring tests\n# junior_coder qwen3.6:35b-a3b-coding-nvfp4 LOCAL MoE coder (3B active, nvfp4); only ONE active (memory)\n# code_reviewer kimi-k2.7-code:cloud 1T coding specialist; cross-family from the coders (glm)\n# acceptance_gate minimax-m3:cloud long-context lineage; holds spec + criteria + diff + tests at once\n#\n# Review boundaries cross model families so a reviewer does not share the\n# author's blind spots (glm↔deepseek at PM, deepseek↔kimi at architecture,\n# glm↔kimi at code review, everything↔minimax at the final gate).\n#\n# gemma4:31b-cloud is the lightest dense model in your set. It is NOT wired to a\n# frontier gate on purpose (under-powering a gate defeats it); it is provided\n# below as a ready budget/throughput swap — see [llm.ollama_cloud_budget].\n#\n# AUTH — two ways to reach `:cloud` models (this file defaults to #1):\n# 1. Via the LOCAL daemon (recommended): base_url = \"http://localhost:11434\".\n# The daemon authenticates cloud models with ~/.ollama/id_ed25519 after a\n# one-time `ollama signin`. No env var needed. (Requires the daemon running.)\n# 2. Direct to cloud: base_url = \"https://ollama.com\" (no /v1) AND\n# `export OLLAMA_API_KEY=\"<key>\"`. The api_key config field is INERT on the\n# native path, so a missing env var ⇒ 401 Unauthorized.\n#\n# NOTE on `think`: on the native `ollama` driver, ayder hardcodes thinking ON\n# (think=True) and does NOT forward the configured level — so a\n# `think = \"high\"` below documents intent, but the \"low/medium/high\"\n# granularity is not applied. The `openai` driver sends no reasoning-effort\n# parameter at all.\n#\n# NOTE on tuning knobs — which actually take effect depends on the DRIVER. These\n# agents run on the native `ollama` driver, which ignores most of them:\n# • temperature — forwarded by NO driver yet ⇒ no effect anywhere.\n# • max_output_tokens — NOT sent on the ollama path (Ollama sizes\n# generation itself); honored only by the\n# openai-family drivers as max_tokens. Default 4096.\n# • think — hardcoded ON for ollama (level ignored); openai\n# sends none.\n# • num_ctx — on ollama it is provisional only (the real window\n# is auto-detected from /api/show); on the openai\n# path it sizes the context-manager budget.\n# Default 65536.\n# The per-agent temperature / max_output_tokens / think values below are\n# therefore largely INERT on this Ollama pipeline — they are kept to\n# document intent and to carry over if you switch an agent to an `openai`\n# profile. To actually tune these, use the `openai` driver — see\n# [llm.openai] below.\n# =============================================================================\n\nconfig_version = \"2.0\"\n\n[app]\nprovider = \"ollama_cloud\" # active profile for the ORCHESTRATOR session (see [llm.ollama_cloud])\neditor = \"vim\"\nverbose = false\nprompt = \"STANDARD\" # MINIMAL | STANDARD | EXTENDED\nmax_background_processes = 5 # cap on concurrent background processes (e.g. test runs)\nmax_output_tokens = 8192 # orchestrator response cap\n# Max conversation messages kept per turn. 0 = unlimited (default): the context\n# manager's token budget + compaction are the bound, so the model uses its real\n# window. A small fixed cap (the old default was 30) thrashes a tiny history\n# window on a large-context model and wastes most of it. Set a finite number\n# only if you want a hard message cap regardless of window size.\nmax_history_messages = 0\nagent_timeout = 1800 # seconds before a background agent is cancelled (30 min; reasoning+coding can be slow)\n# Tools the agents inherit. A coding harness needs file/shell/search (core),\n# tasks/notes (metadata), background process control for test suites\n# (background), and web fetch (http). See /plugin for the full tag list.\ntool_tags = [\"core\", \"metadata\", \"background\", \"http\"]\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n\n[context_manager]\nenabled = true\n# Destructive tool-result compression is OPT-IN and OFF by default. It summarizes\n# old tool results in place (lossy) and thrashes the KV cache, so leave it off\n# unless you specifically want it; eviction will replace it in a later release.\nenable_compression = false\n# max_context_tokens is OPTIONAL. When unset (recommended), the budget is derived\n# from the active model's num_ctx. It is read only on the openai/non-ollama path\n# (DefaultContextManager); the native Ollama path auto-detects the real window\n# from /api/show and ignores it. reserve_ratio + compaction_threshold ARE read on\n# both paths.\n# max_context_tokens = 131072\nreserve_ratio = 0.30\ncompaction_threshold = 0.80\n\n[retry]\nenabled = true\nmax_attempts = 3\ninitial_delay_seconds = 0.5\nmax_delay_seconds = 30.0\nbackoff_coefficient = 2.0\njitter = true\n\n# -----------------------------------------------------------------------------\n# Provider profiles\n# -----------------------------------------------------------------------------\n\n[llm.ollama_cloud]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\" # route :cloud models through the LOCAL daemon (auth via ~/.ollama/id_ed25519, one-time `ollama signin`)\nmodel = \"deepseek-v4-pro:cloud\" # orchestrator default; per-agent `model` overrides this\nnum_ctx = 131072\n# To hit ollama.com directly instead, swap the line above for:\n# base_url = \"https://ollama.com\" # no /v1; then `export OLLAMA_API_KEY=<key>` (the api_key field is inert on this path)\n\n[llm.ollama_local]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\nnum_ctx = 32768 # keep modest: local VRAM is the constraint\n\n# Budget/throughput alternative — swap any cloud agent's `provider` to this, or\n# point a duplicate reviewer at it for cheap parallel passes.\n# [llm.ollama_cloud_budget]\n# driver = \"ollama\"\n# base_url = \"https://ollama.com\"\n# model = \"gemma4:31b-cloud\"\n# num_ctx = 131072\n\n# OpenAI-compatible driver. Unlike the `ollama` driver above, this one HONORS the\n# tuning knobs (defaults shown). Use it for api.openai.com, Azure, vLLM,\n# llama.cpp, LM Studio, or Ollama's own `/v1` endpoint. Point an agent at it with\n# `provider = \"openai\"`.\n# [llm.openai]\n# driver = \"openai\"\n# base_url = \"https://api.openai.com/v1\" # OpenAI-compatible endpoint\n# api_key = \"sk-...\" # your key (or \"ollama\"/\"none\" for local servers)\n# model = \"gpt-5.5\"\n# num_ctx = 65536 # sizes the context-manager budget (default 65536); NOT sent to the API\n# max_output_tokens = 8192 # -> max_tokens / max_completion_tokens (default 4096); keep WELL below num_ctx\n# stop_sequences = [] # -> stop (default [])\n# # temperature / think are NOT applied by the openai driver today (no-ops) — omitted on purpose.\n\n# =============================================================================\n# Agents\n# =============================================================================\n\n# --- Stage 1: Specification --------------------------------------------------\n\n[agents.pm_spec]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.4\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #1 — the requirements analyst and spec author.\n\nINPUT: a raw user request (and any clarifying context the orchestrator gives you).\nOUTPUT: a complete, testable specification. Do NOT include implementation detail\nor technology choices — that is the Architect's job.\n\nProduce, in this order:\n1. Problem & Goal — one paragraph: what outcome the user actually wants.\n2. Scope — explicit \"In scope\" and \"Out of scope\" bullet lists.\n3. Functional requirements — numbered, each a single observable behavior.\n4. Non-functional requirements — performance, security, compatibility, UX.\n5. Acceptance Criteria — a NUMBERED list (AC1, AC2, …). Every criterion MUST be\n objectively verifiable by an automated test or a concrete manual check.\n Use Given/When/Then phrasing where it adds precision. No vague words\n (\"fast\", \"robust\", \"user-friendly\") unless quantified.\n6. Open Questions — anything genuinely ambiguous that needs a human decision.\n\nRuthlessly apply YAGNI: do not invent features the user did not ask for.\nIf the request is too large for one spec, say so and propose a decomposition.\n\"\"\"\n\n[agents.pm_review]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.2\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #2 — the independent spec reviewer.\n\nINPUT: the original user request AND PM#1's specification.\nOUTPUT: a verdict plus findings.\n\nVerify, point by point:\n- Coverage: does every part of the user request map to a requirement?\n- Testability: is each Acceptance Criterion objectively verifiable? Flag any\n criterion that cannot be turned into a pass/fail check.\n- Clarity: any requirement open to two interpretations? Name both.\n- Scope: any requirement or AC that exceeds the user's actual ask (scope creep)?\n- Contradictions / gaps / missing non-functional requirements.\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED — if the spec is complete, testable, and in scope.\n VERDICT: CHANGES REQUIRED — otherwise.\nFollow it with a numbered findings list; each finding cites the spec item and\nstates the concrete change needed. Be specific and terse. No praise.\n\"\"\"\n\n# --- Stage 2: Architecture ---------------------------------------------------\n\n[agents.architect]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.3\nmax_output_tokens = 8192\nthink = \"high\"\nnum_ctx = 262144 # long window: hold the whole spec while splitting it into tasks (delays compaction)\nsystem_prompt = \"\"\"\nYou are the Architect — you turn an APPROVED spec into an implementation plan.\n\nINPUT: the approved specification.\nOUTPUT: a plan a competent engineer with zero prior context could execute.\n\nInclude:\n1. File structure — exact paths to create/modify, one responsibility each.\n2. Components & interfaces — names, signatures, parameter/return types, and how\n modules talk to each other. Make boundaries explicit and testable.\n3. Task breakdown — bite-sized tasks, each independently testable and tied to\n the spec's Acceptance Criteria it advances. Order them so each builds on the\n last. Note which tasks are parallelizable (for multiple senior_coder runs).\n4. Data flow & state ownership.\n5. Test strategy — what is unit-tested vs integration-tested, and how.\n6. Risks & mitigations.\n\nFollow existing codebase patterns; do not propose unrelated refactors. DRY,\nYAGNI, TDD. Every spec Acceptance Criterion must be covered by at least one task.\n\"\"\"\n\n[agents.architect_review]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Architecture Reviewer — independent of the Architect.\n\nINPUT: the approved spec AND the Architect's plan.\nOUTPUT: a verdict plus findings.\n\nCheck:\n- Spec coverage: does every Acceptance Criterion map to a planned task? List gaps.\n- Interface soundness: are the named signatures/types consistent across tasks?\n (A method called clearLayers() in one task and clearFullLayers() in another is a bug.)\n- Coupling & boundaries: any module doing too much, or leaky interfaces?\n- Test strategy: are the proposed tests real (asserting behavior), not vacuous?\n- Over-engineering: anything beyond what the spec requires (YAGNI violations)?\n- Task sizing & ordering: is each task independently testable and correctly sequenced?\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED\n VERDICT: CHANGES REQUIRED\nThen a numbered findings list, each citing the plan item and the required change.\n\"\"\"\n\n# --- Stage 3: Implementation -------------------------------------------------\n\n# Dispatch this agent 2-3 times in parallel, one well-scoped task each.\n[agents.senior_coder]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are a Senior Software Engineer implementing ONE well-scoped task from the plan.\n\nINPUT: a single task (with its interfaces and the Acceptance Criteria it serves).\nOUTPUT: working, tested code for THAT task only — do not wander into other tasks.\n\nWork TDD:\n1. Write the failing test(s) for the behavior.\n2. Run them; confirm they fail for the right reason.\n3. Write the minimal implementation to pass.\n4. Run the tests; confirm green. Run any adjacent tests your change could break.\n5. Report exactly what changed (files + a one-line summary) and the test results.\n\nMatch the surrounding code's style, naming, and patterns. DRY, YAGNI. If the\ntask is ambiguous or the plan's interface won't work, stop and say so precisely\nrather than guessing.\n\"\"\"\n\n[agents.qa_engineer]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are the QA Engineer — you build and run the test/QA suite.\n\nINPUT: the implemented code, the plan's test strategy, and the spec's Acceptance Criteria.\nOUTPUT: tests and a QA report.\n\nDo:\n1. Author the integration/end-to-end and edge-case tests the unit tests miss,\n following existing test patterns in the codebase.\n2. Run the full relevant suite (use the project's runner; run it in the background\n if long) and capture real output.\n3. Report: command run, pass/fail counts, and the actual failure output verbatim\n for anything red. Never claim green without showing the run.\n4. Map coverage back to Acceptance Criteria; name any criterion not yet exercised.\n\nReport failures faithfully. A skipped or flaky test is a finding, not a pass.\n\"\"\"\n\n# LOCAL agent — keep to ONE active instance (VRAM). Best for small, low-risk,\n# well-specified tasks: boilerplate, simple pure functions, mechanical edits.\n[agents.junior_coder]\nprovider = \"ollama_local\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\ntemperature = 0.2\nmax_output_tokens = 4096\nnum_ctx = 32768\nsystem_prompt = \"\"\"\nYou are a Junior Developer running on a LOCAL model. You take small, clearly\nspecified, low-risk tasks (boilerplate, simple functions, renames, mechanical\nedits, fixture data).\n\nINPUT: one small, unambiguous task.\nOUTPUT: the minimal code change plus the relevant test, run to green.\n\nRules:\n- Stay strictly within the task. Do not redesign or touch unrelated files.\n- Match existing patterns exactly.\n- If anything is ambiguous, risky, or larger than it first looked, STOP and\n escalate (\"BLOCKED: <reason>\") instead of guessing — a senior_coder will take it.\n- Always run the test covering your change and report the result.\n\"\"\"\n\n# --- Stage 4: Review & Gate --------------------------------------------------\n\n[agents.code_reviewer]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Code Reviewer. You review a diff for correctness and quality.\n\nINPUT: the diff (plus the plan/task it implements and the coding standards).\nOUTPUT: severity-tagged findings and a verdict.\n\nReview for:\n- Correctness & edge cases — logic errors, off-by-one, error handling, races.\n- Security — injection, unsafe input, secret handling, unsafe shell/file ops.\n- Tests — do they assert real behavior? Any vacuous or missing tests?\n- Spec/plan adherence — does the code do what the task required, no more (YAGNI)?\n- Readability & consistency with surrounding code.\n\nTag each finding Critical / Important / Minor, cite file:line, and give the fix.\nEnd with exactly one verdict line:\n VERDICT: APPROVED — no Critical/Important findings.\n VERDICT: CHANGES REQUIRED — otherwise.\nVerify before asserting; if you cannot tell from the diff, say so explicitly.\n\"\"\"\n\n[agents.acceptance_gate]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nnum_ctx = 262144 # long window: holds spec + all criteria + diff + test output at once\nsystem_prompt = \"\"\"\nYou are the Acceptance Gate — the final, independent check before \"done\".\n\nINPUT: the spec's Acceptance Criteria AND the final implementation + test results.\nOUTPUT: a per-criterion verdict and an overall gate decision.\n\nFor EACH Acceptance Criterion (AC1, AC2, …):\n- State PASS or FAIL.\n- Cite the concrete evidence: the test that proves it (and its result), or the\n code path, or the manual check. No evidence ⇒ FAIL.\n\nDo not re-review style or design — only whether the spec's criteria are met.\nBe strict: partial or unverifiable ⇒ FAIL. End with exactly one line:\n GATE: PASS — every Acceptance Criterion is PASS with evidence.\n GATE: FAIL — otherwise (list the failing AC numbers).\n\"\"\"\n"}, "adf1d062c44c31afd8cb9bacb24ee6f1651240c2": {"t": 1785767764.6256218, "n": 18442, "h": "8c49a5b363a19378", "c": "# =============================================================================\n# ayder-cli — Multi-Agent SDLC Harness (example config)\n# =============================================================================\n#\n# A 9-role software-delivery pipeline backed by Ollama Cloud models, plus one\n# local model. Roles are matched to model strengths: reasoning-optimized models\n# drive planning / review / gating; coding-optimized models do the writing and\n# testing.\n#\n# Pipeline (orchestrator dispatches agents in this order):\n#\n# pm_spec ──▶ pm_review ──▶ architect ──▶ architect_review\n# │\n# ┌────────────────────────────────────────┘\n# ▼\n# senior_coder ×2-3 (+ junior_coder for small local tasks, 1 instance)\n# │\n# ▼\n# qa_engineer ──▶ code_reviewer ──▶ acceptance_gate\n#\n# Model → role assignment (grounded in published SWE-bench data, June 2026):\n#\n# Role Model Why\n# ---------------- -------------------------------- --------------------------------\n# pm_spec glm-5.2:cloud strong, token-efficient reasoning + structured writing\n# pm_review deepseek-v4-pro:cloud apex reasoner (~80.6% SWE-bench Verified); diff family from pm_spec\n# architect deepseek-v4-pro:cloud hardest reasoning task: system design\n# architect_review kimi-k2.7-code:cloud independent reviewer; strong coder, cross-family from the architect (deepseek)\n# senior_coder glm-5.2:cloud code-strong, token-efficient code generation; strong agentic coder\n# qa_engineer minimax-m3:cloud long-context coder; holds implementation + criteria while authoring tests\n# junior_coder qwen3.6:35b-a3b-coding-nvfp4 LOCAL MoE coder (3B active, nvfp4); only ONE active (memory)\n# code_reviewer kimi-k2.7-code:cloud 1T coding specialist; cross-family from the coders (glm)\n# acceptance_gate minimax-m3:cloud long-context lineage; holds spec + criteria + diff + tests at once\n#\n# Review boundaries cross model families so a reviewer does not share the\n# author's blind spots (glm↔deepseek at PM, deepseek↔kimi at architecture,\n# glm↔kimi at code review, everything↔minimax at the final gate).\n#\n# gemma4:31b-cloud is the lightest dense model in your set. It is NOT wired to a\n# frontier gate on purpose (under-powering a gate defeats it); it is provided\n# below as a ready budget/throughput swap — see [llm.ollama_cloud_budget].\n#\n# AUTH — two ways to reach `:cloud` models (this file defaults to #1):\n# 1. Via the LOCAL daemon (recommended): base_url = \"http://localhost:11434\".\n# The daemon authenticates cloud models with ~/.ollama/id_ed25519 after a\n# one-time `ollama signin`. No env var needed. (Requires the daemon running.)\n# 2. Direct to cloud: base_url = \"https://ollama.com\" (no /v1) AND\n# `export OLLAMA_API_KEY=\"<key>\"`. The api_key config field is INERT on the\n# native path, so a missing env var ⇒ 401 Unauthorized.\n#\n# NOTE on `think`: on the native `ollama` driver, ayder hardcodes thinking ON\n# (think=True) and does NOT forward the configured level — so a\n# `think = \"high\"` below documents intent, but the \"low/medium/high\"\n# granularity is not applied. The `openai` driver sends no reasoning-effort\n# parameter at all.\n#\n# NOTE on tuning knobs — which actually take effect depends on the DRIVER. These\n# agents run on the native `ollama` driver, which ignores most of them:\n# • temperature — forwarded by NO driver yet ⇒ no effect anywhere.\n# • max_output_tokens — NOT sent on the ollama path (Ollama sizes\n# generation itself); honored only by the\n# openai-family drivers as max_tokens. Default 4096.\n# • think — hardcoded ON for ollama (level ignored); openai\n# sends none.\n# • num_ctx — on ollama it is provisional only (the real window\n# is auto-detected from /api/show); on the openai\n# path it sizes the context-manager budget.\n# Default 65536.\n# The per-agent temperature / max_output_tokens / think values below are\n# therefore largely INERT on this Ollama pipeline — they are kept to\n# document intent and to carry over if you switch an agent to an `openai`\n# profile. To actually tune these, use the `openai` driver — see\n# [llm.openai] below.\n# =============================================================================\n\nconfig_version = \"2.0\"\n\n[app]\nprovider = \"ollama_cloud\" # active profile for the ORCHESTRATOR session (see [llm.ollama_cloud])\neditor = \"vim\"\nverbose = false\nprompt = \"STANDARD\" # MINIMAL | STANDARD | EXTENDED\nmax_background_processes = 5 # cap on concurrent background processes (e.g. test runs)\nmax_output_tokens = 8192 # orchestrator response cap\nmax_history_messages = 30\nagent_timeout = 1800 # seconds before a background agent is cancelled (30 min; reasoning+coding can be slow)\n# Tools the agents inherit. A coding harness needs file/shell/search (core),\n# tasks/notes (metadata), background process control for test suites\n# (background), and web fetch (http). See /plugin for the full tag list.\ntool_tags = [\"core\", \"metadata\", \"background\", \"http\"]\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n\n[context_manager]\nenabled = true\n# Destructive tool-result compression is OPT-IN and OFF by default. It summarizes\n# old tool results in place (lossy) and thrashes the KV cache, so leave it off\n# unless you specifically want it; eviction will replace it in a later release.\nenable_compression = false\n# max_context_tokens is OPTIONAL. When unset (recommended), the budget is derived\n# from the active model's num_ctx. It is read only on the openai/non-ollama path\n# (DefaultContextManager); the native Ollama path auto-detects the real window\n# from /api/show and ignores it. reserve_ratio + compaction_threshold ARE read on\n# both paths.\n# max_context_tokens = 131072\nreserve_ratio = 0.30\ncompaction_threshold = 0.80\n\n[retry]\nenabled = true\nmax_attempts = 3\ninitial_delay_seconds = 0.5\nmax_delay_seconds = 30.0\nbackoff_coefficient = 2.0\njitter = true\n\n# -----------------------------------------------------------------------------\n# Provider profiles\n# -----------------------------------------------------------------------------\n\n[llm.ollama_cloud]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\" # route :cloud models through the LOCAL daemon (auth via ~/.ollama/id_ed25519, one-time `ollama signin`)\nmodel = \"deepseek-v4-pro:cloud\" # orchestrator default; per-agent `model` overrides this\nnum_ctx = 131072\n# To hit ollama.com directly instead, swap the line above for:\n# base_url = \"https://ollama.com\" # no /v1; then `export OLLAMA_API_KEY=<key>` (the api_key field is inert on this path)\n\n[llm.ollama_local]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\nnum_ctx = 32768 # keep modest: local VRAM is the constraint\n\n# Budget/throughput alternative — swap any cloud agent's `provider` to this, or\n# point a duplicate reviewer at it for cheap parallel passes.\n# [llm.ollama_cloud_budget]\n# driver = \"ollama\"\n# base_url = \"https://ollama.com\"\n# model = \"gemma4:31b-cloud\"\n# num_ctx = 131072\n\n# OpenAI-compatible driver. Unlike the `ollama` driver above, this one HONORS the\n# tuning knobs (defaults shown). Use it for api.openai.com, Azure, vLLM,\n# llama.cpp, LM Studio, or Ollama's own `/v1` endpoint. Point an agent at it with\n# `provider = \"openai\"`.\n# [llm.openai]\n# driver = \"openai\"\n# base_url = \"https://api.openai.com/v1\" # OpenAI-compatible endpoint\n# api_key = \"sk-...\" # your key (or \"ollama\"/\"none\" for local servers)\n# model = \"gpt-5.5\"\n# num_ctx = 65536 # sizes the context-manager budget (default 65536); NOT sent to the API\n# max_output_tokens = 8192 # -> max_tokens / max_completion_tokens (default 4096); keep WELL below num_ctx\n# stop_sequences = [] # -> stop (default [])\n# # temperature / think are NOT applied by the openai driver today (no-ops) — omitted on purpose.\n\n# =============================================================================\n# Agents\n# =============================================================================\n\n# --- Stage 1: Specification --------------------------------------------------\n\n[agents.pm_spec]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.4\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #1 — the requirements analyst and spec author.\n\nINPUT: a raw user request (and any clarifying context the orchestrator gives you).\nOUTPUT: a complete, testable specification. Do NOT include implementation detail\nor technology choices — that is the Architect's job.\n\nProduce, in this order:\n1. Problem & Goal — one paragraph: what outcome the user actually wants.\n2. Scope — explicit \"In scope\" and \"Out of scope\" bullet lists.\n3. Functional requirements — numbered, each a single observable behavior.\n4. Non-functional requirements — performance, security, compatibility, UX.\n5. Acceptance Criteria — a NUMBERED list (AC1, AC2, …). Every criterion MUST be\n objectively verifiable by an automated test or a concrete manual check.\n Use Given/When/Then phrasing where it adds precision. No vague words\n (\"fast\", \"robust\", \"user-friendly\") unless quantified.\n6. Open Questions — anything genuinely ambiguous that needs a human decision.\n\nRuthlessly apply YAGNI: do not invent features the user did not ask for.\nIf the request is too large for one spec, say so and propose a decomposition.\n\"\"\"\n\n[agents.pm_review]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.2\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #2 — the independent spec reviewer.\n\nINPUT: the original user request AND PM#1's specification.\nOUTPUT: a verdict plus findings.\n\nVerify, point by point:\n- Coverage: does every part of the user request map to a requirement?\n- Testability: is each Acceptance Criterion objectively verifiable? Flag any\n criterion that cannot be turned into a pass/fail check.\n- Clarity: any requirement open to two interpretations? Name both.\n- Scope: any requirement or AC that exceeds the user's actual ask (scope creep)?\n- Contradictions / gaps / missing non-functional requirements.\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED — if the spec is complete, testable, and in scope.\n VERDICT: CHANGES REQUIRED — otherwise.\nFollow it with a numbered findings list; each finding cites the spec item and\nstates the concrete change needed. Be specific and terse. No praise.\n\"\"\"\n\n# --- Stage 2: Architecture ---------------------------------------------------\n\n[agents.architect]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.3\nmax_output_tokens = 8192\nthink = \"high\"\nnum_ctx = 262144 # long window: hold the whole spec while splitting it into tasks (delays compaction)\nsystem_prompt = \"\"\"\nYou are the Architect — you turn an APPROVED spec into an implementation plan.\n\nINPUT: the approved specification.\nOUTPUT: a plan a competent engineer with zero prior context could execute.\n\nInclude:\n1. File structure — exact paths to create/modify, one responsibility each.\n2. Components & interfaces — names, signatures, parameter/return types, and how\n modules talk to each other. Make boundaries explicit and testable.\n3. Task breakdown — bite-sized tasks, each independently testable and tied to\n the spec's Acceptance Criteria it advances. Order them so each builds on the\n last. Note which tasks are parallelizable (for multiple senior_coder runs).\n4. Data flow & state ownership.\n5. Test strategy — what is unit-tested vs integration-tested, and how.\n6. Risks & mitigations.\n\nFollow existing codebase patterns; do not propose unrelated refactors. DRY,\nYAGNI, TDD. Every spec Acceptance Criterion must be covered by at least one task.\n\"\"\"\n\n[agents.architect_review]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Architecture Reviewer — independent of the Architect.\n\nINPUT: the approved spec AND the Architect's plan.\nOUTPUT: a verdict plus findings.\n\nCheck:\n- Spec coverage: does every Acceptance Criterion map to a planned task? List gaps.\n- Interface soundness: are the named signatures/types consistent across tasks?\n (A method called clearLayers() in one task and clearFullLayers() in another is a bug.)\n- Coupling & boundaries: any module doing too much, or leaky interfaces?\n- Test strategy: are the proposed tests real (asserting behavior), not vacuous?\n- Over-engineering: anything beyond what the spec requires (YAGNI violations)?\n- Task sizing & ordering: is each task independently testable and correctly sequenced?\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED\n VERDICT: CHANGES REQUIRED\nThen a numbered findings list, each citing the plan item and the required change.\n\"\"\"\n\n# --- Stage 3: Implementation -------------------------------------------------\n\n# Dispatch this agent 2-3 times in parallel, one well-scoped task each.\n[agents.senior_coder]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are a Senior Software Engineer implementing ONE well-scoped task from the plan.\n\nINPUT: a single task (with its interfaces and the Acceptance Criteria it serves).\nOUTPUT: working, tested code for THAT task only — do not wander into other tasks.\n\nWork TDD:\n1. Write the failing test(s) for the behavior.\n2. Run them; confirm they fail for the right reason.\n3. Write the minimal implementation to pass.\n4. Run the tests; confirm green. Run any adjacent tests your change could break.\n5. Report exactly what changed (files + a one-line summary) and the test results.\n\nMatch the surrounding code's style, naming, and patterns. DRY, YAGNI. If the\ntask is ambiguous or the plan's interface won't work, stop and say so precisely\nrather than guessing.\n\"\"\"\n\n[agents.qa_engineer]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are the QA Engineer — you build and run the test/QA suite.\n\nINPUT: the implemented code, the plan's test strategy, and the spec's Acceptance Criteria.\nOUTPUT: tests and a QA report.\n\nDo:\n1. Author the integration/end-to-end and edge-case tests the unit tests miss,\n following existing test patterns in the codebase.\n2. Run the full relevant suite (use the project's runner; run it in the background\n if long) and capture real output.\n3. Report: command run, pass/fail counts, and the actual failure output verbatim\n for anything red. Never claim green without showing the run.\n4. Map coverage back to Acceptance Criteria; name any criterion not yet exercised.\n\nReport failures faithfully. A skipped or flaky test is a finding, not a pass.\n\"\"\"\n\n# LOCAL agent — keep to ONE active instance (VRAM). Best for small, low-risk,\n# well-specified tasks: boilerplate, simple pure functions, mechanical edits.\n[agents.junior_coder]\nprovider = \"ollama_local\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\ntemperature = 0.2\nmax_output_tokens = 4096\nnum_ctx = 32768\nsystem_prompt = \"\"\"\nYou are a Junior Developer running on a LOCAL model. You take small, clearly\nspecified, low-risk tasks (boilerplate, simple functions, renames, mechanical\nedits, fixture data).\n\nINPUT: one small, unambiguous task.\nOUTPUT: the minimal code change plus the relevant test, run to green.\n\nRules:\n- Stay strictly within the task. Do not redesign or touch unrelated files.\n- Match existing patterns exactly.\n- If anything is ambiguous, risky, or larger than it first looked, STOP and\n escalate (\"BLOCKED: <reason>\") instead of guessing — a senior_coder will take it.\n- Always run the test covering your change and report the result.\n\"\"\"\n\n# --- Stage 4: Review & Gate --------------------------------------------------\n\n[agents.code_reviewer]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Code Reviewer. You review a diff for correctness and quality.\n\nINPUT: the diff (plus the plan/task it implements and the coding standards).\nOUTPUT: severity-tagged findings and a verdict.\n\nReview for:\n- Correctness & edge cases — logic errors, off-by-one, error handling, races.\n- Security — injection, unsafe input, secret handling, unsafe shell/file ops.\n- Tests — do they assert real behavior? Any vacuous or missing tests?\n- Spec/plan adherence — does the code do what the task required, no more (YAGNI)?\n- Readability & consistency with surrounding code.\n\nTag each finding Critical / Important / Minor, cite file:line, and give the fix.\nEnd with exactly one verdict line:\n VERDICT: APPROVED — no Critical/Important findings.\n VERDICT: CHANGES REQUIRED — otherwise.\nVerify before asserting; if you cannot tell from the diff, say so explicitly.\n\"\"\"\n\n[agents.acceptance_gate]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nnum_ctx = 262144 # long window: holds spec + all criteria + diff + test output at once\nsystem_prompt = \"\"\"\nYou are the Acceptance Gate — the final, independent check before \"done\".\n\nINPUT: the spec's Acceptance Criteria AND the final implementation + test results.\nOUTPUT: a per-criterion verdict and an overall gate decision.\n\nFor EACH Acceptance Criterion (AC1, AC2, …):\n- State PASS or FAIL.\n- Cite the concrete evidence: the test that proves it (and its result), or the\n code path, or the manual check. No evidence ⇒ FAIL.\n\nDo not re-review style or design — only whether the spec's criteria are met.\nBe strict: partial or unverifiable ⇒ FAIL. End with exactly one line:\n GATE: PASS — every Acceptance Criterion is PASS with evidence.\n GATE: FAIL — otherwise (list the failing AC numbers).\n\"\"\"\n"}, "40f4b74434463f4d928daee85b05afa103bf4114": {"t": 1785767765.9729125, "n": 15913, "h": "95a8e7ab1abdf793", "c": "# =============================================================================\n# ayder-cli — Multi-Agent SDLC Harness (example config)\n# =============================================================================\n#\n# A 9-role software-delivery pipeline backed by Ollama Cloud models, plus one\n# local model. Roles are matched to model strengths: reasoning-optimized models\n# drive planning / review / gating; coding-optimized models do the writing and\n# testing.\n#\n# Pipeline (orchestrator dispatches agents in this order):\n#\n# pm_spec ──▶ pm_review ──▶ architect ──▶ architect_review\n# │\n# ┌────────────────────────────────────────┘\n# ▼\n# senior_coder ×2-3 (+ junior_coder for small local tasks, 1 instance)\n# │\n# ▼\n# qa_engineer ──▶ code_reviewer ──▶ acceptance_gate\n#\n# Model → role assignment (grounded in published SWE-bench data, June 2026):\n#\n# Role Model Why\n# ---------------- -------------------------------- --------------------------------\n# pm_spec glm-5.2:cloud strong, token-efficient reasoning + structured writing\n# pm_review deepseek-v4-pro:cloud apex reasoner (~80.6% SWE-bench Verified); diff family from pm_spec\n# architect deepseek-v4-pro:cloud hardest reasoning task: system design\n# architect_review kimi-k2.7-code:cloud independent reviewer; strong coder, cross-family from the architect (deepseek)\n# senior_coder glm-5.2:cloud code-strong, token-efficient code generation; strong agentic coder\n# qa_engineer minimax-m3:cloud long-context coder; holds implementation + criteria while authoring tests\n# junior_coder qwen3.6:35b-a3b-coding-nvfp4 LOCAL MoE coder (3B active, nvfp4); only ONE active (memory)\n# code_reviewer kimi-k2.7-code:cloud 1T coding specialist; cross-family from the coders (glm)\n# acceptance_gate minimax-m3:cloud long-context lineage; holds spec + criteria + diff + tests at once\n#\n# Review boundaries cross model families so a reviewer does not share the\n# author's blind spots (glm↔deepseek at PM, deepseek↔kimi at architecture,\n# glm↔kimi at code review, everything↔minimax at the final gate).\n#\n# gemma4:31b-cloud is the lightest dense model in your set. It is NOT wired to a\n# frontier gate on purpose (under-powering a gate defeats it); it is provided\n# below as a ready budget/throughput swap — see [llm.ollama_cloud_budget].\n#\n# AUTH — two ways to reach `:cloud` models (this file defaults to #1):\n# 1. Via the LOCAL daemon (recommended): base_url = \"http://localhost:11434\".\n# The daemon authenticates cloud models with ~/.ollama/id_ed25519 after a\n# one-time `ollama signin`. No env var needed. (Requires the daemon running.)\n# 2. Direct to cloud: base_url = \"https://ollama.com\" (no /v1) AND\n# `export OLLAMA_API_KEY=\"<key>\"`. The api_key config field is INERT on the\n# native path, so a missing env var ⇒ 401 Unauthorized.\n#\n# NOTE on `think`: value is model/driver-dependent. Recent Ollama accepts\n# true/false for most models and \"low\"|\"medium\"|\"high\" for reasoning\n# models like deepseek-v4-pro. Adjust per model if a value is rejected.\n# =============================================================================\n\nconfig_version = \"2.0\"\n\n[app]\nprovider = \"ollama_cloud\" # active profile for the ORCHESTRATOR session (see [llm.ollama_cloud])\neditor = \"vim\"\nverbose = false\nprompt = \"STANDARD\" # MINIMAL | STANDARD | EXTENDED\nmax_background_processes = 5 # cap on concurrent background processes (e.g. test runs)\nmax_output_tokens = 8192 # orchestrator response cap\nmax_history_messages = 30\nagent_timeout = 1800 # seconds before a background agent is cancelled (30 min; reasoning+coding can be slow)\n# Tools the agents inherit. A coding harness needs file/shell/search (core),\n# tasks/notes (metadata), background process control for test suites\n# (background), and web fetch (http). See /plugin for the full tag list.\ntool_tags = [\"core\", \"metadata\", \"background\", \"http\"]\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n\n[context_manager]\nenabled = true\n# On the native Ollama path, OllamaContextManager auto-detects the model's real\n# window from /api/show; max_context_tokens is ignored there and only matters on\n# the openai/non-ollama path. reserve_ratio + compaction_threshold ARE read.\nmax_context_tokens = 131072\nreserve_ratio = 0.30\ncompaction_threshold = 0.80\n\n[retry]\nenabled = true\nmax_attempts = 3\ninitial_delay_seconds = 0.5\nmax_delay_seconds = 30.0\nbackoff_coefficient = 2.0\njitter = true\n\n# -----------------------------------------------------------------------------\n# Provider profiles\n# -----------------------------------------------------------------------------\n\n[llm.ollama_cloud]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\" # route :cloud models through the LOCAL daemon (auth via ~/.ollama/id_ed25519, one-time `ollama signin`)\nmodel = \"deepseek-v4-pro:cloud\" # orchestrator default; per-agent `model` overrides this\nnum_ctx = 131072\n# To hit ollama.com directly instead, swap the line above for:\n# base_url = \"https://ollama.com\" # no /v1; then `export OLLAMA_API_KEY=<key>` (the api_key field is inert on this path)\n\n[llm.ollama_local]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\nnum_ctx = 32768 # keep modest: local VRAM is the constraint\n\n# Budget/throughput alternative — swap any cloud agent's `provider` to this, or\n# point a duplicate reviewer at it for cheap parallel passes.\n# [llm.ollama_cloud_budget]\n# driver = \"ollama\"\n# base_url = \"https://ollama.com\"\n# model = \"gemma4:31b-cloud\"\n# num_ctx = 131072\n\n# =============================================================================\n# Agents\n# =============================================================================\n\n# --- Stage 1: Specification --------------------------------------------------\n\n[agents.pm_spec]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.4\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #1 — the requirements analyst and spec author.\n\nINPUT: a raw user request (and any clarifying context the orchestrator gives you).\nOUTPUT: a complete, testable specification. Do NOT include implementation detail\nor technology choices — that is the Architect's job.\n\nProduce, in this order:\n1. Problem & Goal — one paragraph: what outcome the user actually wants.\n2. Scope — explicit \"In scope\" and \"Out of scope\" bullet lists.\n3. Functional requirements — numbered, each a single observable behavior.\n4. Non-functional requirements — performance, security, compatibility, UX.\n5. Acceptance Criteria — a NUMBERED list (AC1, AC2, …). Every criterion MUST be\n objectively verifiable by an automated test or a concrete manual check.\n Use Given/When/Then phrasing where it adds precision. No vague words\n (\"fast\", \"robust\", \"user-friendly\") unless quantified.\n6. Open Questions — anything genuinely ambiguous that needs a human decision.\n\nRuthlessly apply YAGNI: do not invent features the user did not ask for.\nIf the request is too large for one spec, say so and propose a decomposition.\n\"\"\"\n\n[agents.pm_review]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.2\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #2 — the independent spec reviewer.\n\nINPUT: the original user request AND PM#1's specification.\nOUTPUT: a verdict plus findings.\n\nVerify, point by point:\n- Coverage: does every part of the user request map to a requirement?\n- Testability: is each Acceptance Criterion objectively verifiable? Flag any\n criterion that cannot be turned into a pass/fail check.\n- Clarity: any requirement open to two interpretations? Name both.\n- Scope: any requirement or AC that exceeds the user's actual ask (scope creep)?\n- Contradictions / gaps / missing non-functional requirements.\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED — if the spec is complete, testable, and in scope.\n VERDICT: CHANGES REQUIRED — otherwise.\nFollow it with a numbered findings list; each finding cites the spec item and\nstates the concrete change needed. Be specific and terse. No praise.\n\"\"\"\n\n# --- Stage 2: Architecture ---------------------------------------------------\n\n[agents.architect]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.3\nmax_output_tokens = 8192\nthink = \"high\"\nnum_ctx = 262144 # long window: hold the whole spec while splitting it into tasks (delays compaction)\nsystem_prompt = \"\"\"\nYou are the Architect — you turn an APPROVED spec into an implementation plan.\n\nINPUT: the approved specification.\nOUTPUT: a plan a competent engineer with zero prior context could execute.\n\nInclude:\n1. File structure — exact paths to create/modify, one responsibility each.\n2. Components & interfaces — names, signatures, parameter/return types, and how\n modules talk to each other. Make boundaries explicit and testable.\n3. Task breakdown — bite-sized tasks, each independently testable and tied to\n the spec's Acceptance Criteria it advances. Order them so each builds on the\n last. Note which tasks are parallelizable (for multiple senior_coder runs).\n4. Data flow & state ownership.\n5. Test strategy — what is unit-tested vs integration-tested, and how.\n6. Risks & mitigations.\n\nFollow existing codebase patterns; do not propose unrelated refactors. DRY,\nYAGNI, TDD. Every spec Acceptance Criterion must be covered by at least one task.\n\"\"\"\n\n[agents.architect_review]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Architecture Reviewer — independent of the Architect.\n\nINPUT: the approved spec AND the Architect's plan.\nOUTPUT: a verdict plus findings.\n\nCheck:\n- Spec coverage: does every Acceptance Criterion map to a planned task? List gaps.\n- Interface soundness: are the named signatures/types consistent across tasks?\n (A method called clearLayers() in one task and clearFullLayers() in another is a bug.)\n- Coupling & boundaries: any module doing too much, or leaky interfaces?\n- Test strategy: are the proposed tests real (asserting behavior), not vacuous?\n- Over-engineering: anything beyond what the spec requires (YAGNI violations)?\n- Task sizing & ordering: is each task independently testable and correctly sequenced?\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED\n VERDICT: CHANGES REQUIRED\nThen a numbered findings list, each citing the plan item and the required change.\n\"\"\"\n\n# --- Stage 3: Implementation -------------------------------------------------\n\n# Dispatch this agent 2-3 times in parallel, one well-scoped task each.\n[agents.senior_coder]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are a Senior Software Engineer implementing ONE well-scoped task from the plan.\n\nINPUT: a single task (with its interfaces and the Acceptance Criteria it serves).\nOUTPUT: working, tested code for THAT task only — do not wander into other tasks.\n\nWork TDD:\n1. Write the failing test(s) for the behavior.\n2. Run them; confirm they fail for the right reason.\n3. Write the minimal implementation to pass.\n4. Run the tests; confirm green. Run any adjacent tests your change could break.\n5. Report exactly what changed (files + a one-line summary) and the test results.\n\nMatch the surrounding code's style, naming, and patterns. DRY, YAGNI. If the\ntask is ambiguous or the plan's interface won't work, stop and say so precisely\nrather than guessing.\n\"\"\"\n\n[agents.qa_engineer]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are the QA Engineer — you build and run the test/QA suite.\n\nINPUT: the implemented code, the plan's test strategy, and the spec's Acceptance Criteria.\nOUTPUT: tests and a QA report.\n\nDo:\n1. Author the integration/end-to-end and edge-case tests the unit tests miss,\n following existing test patterns in the codebase.\n2. Run the full relevant suite (use the project's runner; run it in the background\n if long) and capture real output.\n3. Report: command run, pass/fail counts, and the actual failure output verbatim\n for anything red. Never claim green without showing the run.\n4. Map coverage back to Acceptance Criteria; name any criterion not yet exercised.\n\nReport failures faithfully. A skipped or flaky test is a finding, not a pass.\n\"\"\"\n\n# LOCAL agent — keep to ONE active instance (VRAM). Best for small, low-risk,\n# well-specified tasks: boilerplate, simple pure functions, mechanical edits.\n[agents.junior_coder]\nprovider = \"ollama_local\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\ntemperature = 0.2\nmax_output_tokens = 4096\nnum_ctx = 32768\nsystem_prompt = \"\"\"\nYou are a Junior Developer running on a LOCAL model. You take small, clearly\nspecified, low-risk tasks (boilerplate, simple functions, renames, mechanical\nedits, fixture data).\n\nINPUT: one small, unambiguous task.\nOUTPUT: the minimal code change plus the relevant test, run to green.\n\nRules:\n- Stay strictly within the task. Do not redesign or touch unrelated files.\n- Match existing patterns exactly.\n- If anything is ambiguous, risky, or larger than it first looked, STOP and\n escalate (\"BLOCKED: <reason>\") instead of guessing — a senior_coder will take it.\n- Always run the test covering your change and report the result.\n\"\"\"\n\n# --- Stage 4: Review & Gate --------------------------------------------------\n\n[agents.code_reviewer]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Code Reviewer. You review a diff for correctness and quality.\n\nINPUT: the diff (plus the plan/task it implements and the coding standards).\nOUTPUT: severity-tagged findings and a verdict.\n\nReview for:\n- Correctness & edge cases — logic errors, off-by-one, error handling, races.\n- Security — injection, unsafe input, secret handling, unsafe shell/file ops.\n- Tests — do they assert real behavior? Any vacuous or missing tests?\n- Spec/plan adherence — does the code do what the task required, no more (YAGNI)?\n- Readability & consistency with surrounding code.\n\nTag each finding Critical / Important / Minor, cite file:line, and give the fix.\nEnd with exactly one verdict line:\n VERDICT: APPROVED — no Critical/Important findings.\n VERDICT: CHANGES REQUIRED — otherwise.\nVerify before asserting; if you cannot tell from the diff, say so explicitly.\n\"\"\"\n\n[agents.acceptance_gate]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nnum_ctx = 262144 # long window: holds spec + all criteria + diff + test output at once\nsystem_prompt = \"\"\"\nYou are the Acceptance Gate — the final, independent check before \"done\".\n\nINPUT: the spec's Acceptance Criteria AND the final implementation + test results.\nOUTPUT: a per-criterion verdict and an overall gate decision.\n\nFor EACH Acceptance Criterion (AC1, AC2, …):\n- State PASS or FAIL.\n- Cite the concrete evidence: the test that proves it (and its result), or the\n code path, or the manual check. No evidence ⇒ FAIL.\n\nDo not re-review style or design — only whether the spec's criteria are met.\nBe strict: partial or unverifiable ⇒ FAIL. End with exactly one line:\n GATE: PASS — every Acceptance Criterion is PASS with evidence.\n GATE: FAIL — otherwise (list the failing AC numbers).\n\"\"\"\n"}, "abf83a803dd1a8873b2b67dd78b6098c1863b852": {"t": 1785767767.5708246, "n": 15704, "h": "e8af5db8e7366aec", "c": "# =============================================================================\n# ayder-cli — Multi-Agent SDLC Harness (example config)\n# =============================================================================\n#\n# A 9-role software-delivery pipeline backed by Ollama Cloud models, plus one\n# local model. Roles are matched to model strengths: reasoning-optimized models\n# drive planning / review / gating; coding-optimized models do the writing and\n# testing.\n#\n# Pipeline (orchestrator dispatches agents in this order):\n#\n# pm_spec ──▶ pm_review ──▶ architect ──▶ architect_review\n# │\n# ┌────────────────────────────────────────┘\n# ▼\n# senior_coder ×2-3 (+ junior_coder for small local tasks, 1 instance)\n# │\n# ▼\n# qa_engineer ──▶ code_reviewer ──▶ acceptance_gate\n#\n# Model → role assignment (grounded in published SWE-bench data, June 2026):\n#\n# Role Model Why\n# ---------------- -------------------------------- --------------------------------\n# pm_spec glm-5.2:cloud strong, token-efficient reasoning + structured writing\n# pm_review deepseek-v4-pro:cloud apex reasoner (~80.6% SWE-bench Verified); diff family from pm_spec\n# architect deepseek-v4-pro:cloud hardest reasoning task: system design\n# architect_review gpt-oss:120b:cloud independent reviewer, tunable high reasoning effort; diff family\n# senior_coder kimi-k2.7-code:cloud 1T coding specialist; best agentic coder\n# qa_engineer deepseek-v4-flash:cloud fast distilled coder for high-throughput test authoring\n# junior_coder qwen3.6:35b-a3b-coding-nvfp4 LOCAL MoE coder (3B active, nvfp4); only ONE active (memory)\n# code_reviewer glm-5.2:cloud code-strong reasoner; diff family from the coders\n# acceptance_gate minimax-m3:cloud long-context lineage; holds spec + criteria + diff + tests at once\n#\n# Review boundaries deliberately cross model families so a reviewer does not\n# share the author's blind spots (glm↔deepseek, deepseek↔gpt-oss, kimi↔glm,\n# everything↔minimax at the final gate).\n#\n# gemma4:31b-cloud is the lightest dense model in your set. It is NOT wired to a\n# frontier gate on purpose (under-powering a gate defeats it); it is provided\n# below as a ready budget/throughput swap — see [llm.ollama_cloud_budget].\n#\n# AUTH — two ways to reach `:cloud` models (this file defaults to #1):\n# 1. Via the LOCAL daemon (recommended): base_url = \"http://localhost:11434\".\n# The daemon authenticates cloud models with ~/.ollama/id_ed25519 after a\n# one-time `ollama signin`. No env var needed. (Requires the daemon running.)\n# 2. Direct to cloud: base_url = \"https://ollama.com\" (no /v1) AND\n# `export OLLAMA_API_KEY=\"<key>\"`. The api_key config field is INERT on the\n# native path, so a missing env var ⇒ 401 Unauthorized.\n#\n# NOTE on `think`: value is model/driver-dependent. Recent Ollama accepts\n# true/false for most models and \"low\"|\"medium\"|\"high\" for reasoning\n# models like gpt-oss. Adjust per model if a value is rejected.\n# =============================================================================\n\nconfig_version = \"2.0\"\n\n[app]\nprovider = \"ollama_cloud\" # active profile for the ORCHESTRATOR session (see [llm.ollama_cloud])\neditor = \"vim\"\nverbose = false\nprompt = \"STANDARD\" # MINIMAL | STANDARD | EXTENDED\nmax_background_processes = 5 # cap on concurrent background processes (e.g. test runs)\nmax_output_tokens = 8192 # orchestrator response cap\nmax_history_messages = 30\nagent_timeout = 1800 # seconds before a background agent is cancelled (30 min; reasoning+coding can be slow)\n# Tools the agents inherit. A coding harness needs file/shell/search (core),\n# tasks/notes (metadata), background process control for test suites\n# (background), and web fetch (http). See /plugin for the full tag list.\ntool_tags = [\"core\", \"metadata\", \"background\", \"http\"]\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n\n[context_manager]\nenabled = true\n# On the native Ollama path, OllamaContextManager auto-detects the model's real\n# window from /api/show; max_context_tokens is ignored there and only matters on\n# the openai/non-ollama path. reserve_ratio + compaction_threshold ARE read.\nmax_context_tokens = 131072\nreserve_ratio = 0.30\ncompaction_threshold = 0.80\n\n[retry]\nenabled = true\nmax_attempts = 3\ninitial_delay_seconds = 0.5\nmax_delay_seconds = 30.0\nbackoff_coefficient = 2.0\njitter = true\n\n# -----------------------------------------------------------------------------\n# Provider profiles\n# -----------------------------------------------------------------------------\n\n[llm.ollama_cloud]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\" # route :cloud models through the LOCAL daemon (auth via ~/.ollama/id_ed25519, one-time `ollama signin`)\nmodel = \"deepseek-v4-pro:cloud\" # orchestrator default; per-agent `model` overrides this\nnum_ctx = 131072\n# To hit ollama.com directly instead, swap the line above for:\n# base_url = \"https://ollama.com\" # no /v1; then `export OLLAMA_API_KEY=<key>` (the api_key field is inert on this path)\n\n[llm.ollama_local]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\nnum_ctx = 32768 # keep modest: local VRAM is the constraint\n\n# Budget/throughput alternative — swap any cloud agent's `provider` to this, or\n# point a duplicate reviewer at it for cheap parallel passes.\n# [llm.ollama_cloud_budget]\n# driver = \"ollama\"\n# base_url = \"https://ollama.com\"\n# model = \"gemma4:31b-cloud\"\n# num_ctx = 131072\n\n# =============================================================================\n# Agents\n# =============================================================================\n\n# --- Stage 1: Specification --------------------------------------------------\n\n[agents.pm_spec]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.4\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #1 — the requirements analyst and spec author.\n\nINPUT: a raw user request (and any clarifying context the orchestrator gives you).\nOUTPUT: a complete, testable specification. Do NOT include implementation detail\nor technology choices — that is the Architect's job.\n\nProduce, in this order:\n1. Problem & Goal — one paragraph: what outcome the user actually wants.\n2. Scope — explicit \"In scope\" and \"Out of scope\" bullet lists.\n3. Functional requirements — numbered, each a single observable behavior.\n4. Non-functional requirements — performance, security, compatibility, UX.\n5. Acceptance Criteria — a NUMBERED list (AC1, AC2, …). Every criterion MUST be\n objectively verifiable by an automated test or a concrete manual check.\n Use Given/When/Then phrasing where it adds precision. No vague words\n (\"fast\", \"robust\", \"user-friendly\") unless quantified.\n6. Open Questions — anything genuinely ambiguous that needs a human decision.\n\nRuthlessly apply YAGNI: do not invent features the user did not ask for.\nIf the request is too large for one spec, say so and propose a decomposition.\n\"\"\"\n\n[agents.pm_review]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.2\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are Project Manager #2 — the independent spec reviewer.\n\nINPUT: the original user request AND PM#1's specification.\nOUTPUT: a verdict plus findings.\n\nVerify, point by point:\n- Coverage: does every part of the user request map to a requirement?\n- Testability: is each Acceptance Criterion objectively verifiable? Flag any\n criterion that cannot be turned into a pass/fail check.\n- Clarity: any requirement open to two interpretations? Name both.\n- Scope: any requirement or AC that exceeds the user's actual ask (scope creep)?\n- Contradictions / gaps / missing non-functional requirements.\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED — if the spec is complete, testable, and in scope.\n VERDICT: CHANGES REQUIRED — otherwise.\nFollow it with a numbered findings list; each finding cites the spec item and\nstates the concrete change needed. Be specific and terse. No praise.\n\"\"\"\n\n# --- Stage 2: Architecture ---------------------------------------------------\n\n[agents.architect]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-pro:cloud\"\ntemperature = 0.3\nmax_output_tokens = 8192\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Architect — you turn an APPROVED spec into an implementation plan.\n\nINPUT: the approved specification.\nOUTPUT: a plan a competent engineer with zero prior context could execute.\n\nInclude:\n1. File structure — exact paths to create/modify, one responsibility each.\n2. Components & interfaces — names, signatures, parameter/return types, and how\n modules talk to each other. Make boundaries explicit and testable.\n3. Task breakdown — bite-sized tasks, each independently testable and tied to\n the spec's Acceptance Criteria it advances. Order them so each builds on the\n last. Note which tasks are parallelizable (for multiple senior_coder runs).\n4. Data flow & state ownership.\n5. Test strategy — what is unit-tested vs integration-tested, and how.\n6. Risks & mitigations.\n\nFollow existing codebase patterns; do not propose unrelated refactors. DRY,\nYAGNI, TDD. Every spec Acceptance Criterion must be covered by at least one task.\n\"\"\"\n\n[agents.architect_review]\nprovider = \"ollama_cloud\"\nmodel = \"gpt-oss:120b:cloud\"\ntemperature = 0.2\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Architecture Reviewer — independent of the Architect.\n\nINPUT: the approved spec AND the Architect's plan.\nOUTPUT: a verdict plus findings.\n\nCheck:\n- Spec coverage: does every Acceptance Criterion map to a planned task? List gaps.\n- Interface soundness: are the named signatures/types consistent across tasks?\n (A method called clearLayers() in one task and clearFullLayers() in another is a bug.)\n- Coupling & boundaries: any module doing too much, or leaky interfaces?\n- Test strategy: are the proposed tests real (asserting behavior), not vacuous?\n- Over-engineering: anything beyond what the spec requires (YAGNI violations)?\n- Task sizing & ordering: is each task independently testable and correctly sequenced?\n\nEnd with exactly one verdict line:\n VERDICT: APPROVED\n VERDICT: CHANGES REQUIRED\nThen a numbered findings list, each citing the plan item and the required change.\n\"\"\"\n\n# --- Stage 3: Implementation -------------------------------------------------\n\n# Dispatch this agent 2-3 times in parallel, one well-scoped task each.\n[agents.senior_coder]\nprovider = \"ollama_cloud\"\nmodel = \"kimi-k2.7-code:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are a Senior Software Engineer implementing ONE well-scoped task from the plan.\n\nINPUT: a single task (with its interfaces and the Acceptance Criteria it serves).\nOUTPUT: working, tested code for THAT task only — do not wander into other tasks.\n\nWork TDD:\n1. Write the failing test(s) for the behavior.\n2. Run them; confirm they fail for the right reason.\n3. Write the minimal implementation to pass.\n4. Run the tests; confirm green. Run any adjacent tests your change could break.\n5. Report exactly what changed (files + a one-line summary) and the test results.\n\nMatch the surrounding code's style, naming, and patterns. DRY, YAGNI. If the\ntask is ambiguous or the plan's interface won't work, stop and say so precisely\nrather than guessing.\n\"\"\"\n\n[agents.qa_engineer]\nprovider = \"ollama_cloud\"\nmodel = \"deepseek-v4-flash:cloud\"\ntemperature = 0.2\nmax_output_tokens = 8192\nsystem_prompt = \"\"\"\nYou are the QA Engineer — you build and run the test/QA suite.\n\nINPUT: the implemented code, the plan's test strategy, and the spec's Acceptance Criteria.\nOUTPUT: tests and a QA report.\n\nDo:\n1. Author the integration/end-to-end and edge-case tests the unit tests miss,\n following existing test patterns in the codebase.\n2. Run the full relevant suite (use the project's runner; run it in the background\n if long) and capture real output.\n3. Report: command run, pass/fail counts, and the actual failure output verbatim\n for anything red. Never claim green without showing the run.\n4. Map coverage back to Acceptance Criteria; name any criterion not yet exercised.\n\nReport failures faithfully. A skipped or flaky test is a finding, not a pass.\n\"\"\"\n\n# LOCAL agent — keep to ONE active instance (VRAM). Best for small, low-risk,\n# well-specified tasks: boilerplate, simple pure functions, mechanical edits.\n[agents.junior_coder]\nprovider = \"ollama_local\"\nmodel = \"qwen3.6:35b-a3b-coding-nvfp4\"\ntemperature = 0.2\nmax_output_tokens = 4096\nnum_ctx = 32768\nsystem_prompt = \"\"\"\nYou are a Junior Developer running on a LOCAL model. You take small, clearly\nspecified, low-risk tasks (boilerplate, simple functions, renames, mechanical\nedits, fixture data).\n\nINPUT: one small, unambiguous task.\nOUTPUT: the minimal code change plus the relevant test, run to green.\n\nRules:\n- Stay strictly within the task. Do not redesign or touch unrelated files.\n- Match existing patterns exactly.\n- If anything is ambiguous, risky, or larger than it first looked, STOP and\n escalate (\"BLOCKED: <reason>\") instead of guessing — a senior_coder will take it.\n- Always run the test covering your change and report the result.\n\"\"\"\n\n# --- Stage 4: Review & Gate --------------------------------------------------\n\n[agents.code_reviewer]\nprovider = \"ollama_cloud\"\nmodel = \"glm-5.2:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nsystem_prompt = \"\"\"\nYou are the Code Reviewer. You review a diff for correctness and quality.\n\nINPUT: the diff (plus the plan/task it implements and the coding standards).\nOUTPUT: severity-tagged findings and a verdict.\n\nReview for:\n- Correctness & edge cases — logic errors, off-by-one, error handling, races.\n- Security — injection, unsafe input, secret handling, unsafe shell/file ops.\n- Tests — do they assert real behavior? Any vacuous or missing tests?\n- Spec/plan adherence — does the code do what the task required, no more (YAGNI)?\n- Readability & consistency with surrounding code.\n\nTag each finding Critical / Important / Minor, cite file:line, and give the fix.\nEnd with exactly one verdict line:\n VERDICT: APPROVED — no Critical/Important findings.\n VERDICT: CHANGES REQUIRED — otherwise.\nVerify before asserting; if you cannot tell from the diff, say so explicitly.\n\"\"\"\n\n[agents.acceptance_gate]\nprovider = \"ollama_cloud\"\nmodel = \"minimax-m3:cloud\"\ntemperature = 0.1\nmax_output_tokens = 4096\nthink = \"high\"\nnum_ctx = 262144 # long window: holds spec + all criteria + diff + test output at once\nsystem_prompt = \"\"\"\nYou are the Acceptance Gate — the final, independent check before \"done\".\n\nINPUT: the spec's Acceptance Criteria AND the final implementation + test results.\nOUTPUT: a per-criterion verdict and an overall gate decision.\n\nFor EACH Acceptance Criterion (AC1, AC2, …):\n- State PASS or FAIL.\n- Cite the concrete evidence: the test that proves it (and its result), or the\n code path, or the manual check. No evidence ⇒ FAIL.\n\nDo not re-review style or design — only whether the spec's criteria are met.\nBe strict: partial or unverifiable ⇒ FAIL. End with exactly one line:\n GATE: PASS — every Acceptance Criterion is PASS with evidence.\n GATE: FAIL — otherwise (list the failing AC numbers).\n\"\"\"\n"}, "76e130b529eb090ede7f15148bfa78f83fe1c61b": {"t": 1785767768.8482084, "n": 11530, "h": "5640d4921bdb9a15", "c": "# =============================================================================\n# ayder-cli Configuration (Schema v2.0)\n# =============================================================================\n#\n# Location: ~/.ayder/config.toml\n#\n# This file configures ayder-cli's LLM providers, agents, context management,\n# and application behavior. Copy this file to ~/.ayder/config.toml and\n# customize to your needs.\n#\n# Key concepts:\n# - \"provider\" selects which [llm.*] profile is active\n# - \"driver\" determines the SDK used (openai, ollama, anthropic, google)\n# - Agents can use different providers/models than the main config\n# - Context manager behavior adapts per driver (Ollama gets KV-cache awareness)\n\nconfig_version = \"2.0\"\n\n\n# =============================================================================\n# Application Settings\n# =============================================================================\n\n[app]\n# Which LLM profile to use (must match a key under [llm.*] below)\nprovider = \"openai\"\n\n# System editor for file editing operations\neditor = \"vim\"\n\n# Enable verbose debug output\nverbose = false\n\n# Maximum concurrent background tool processes (1-20)\nmax_background_processes = 5\n\n# Maximum conversation history messages (0 = unlimited)\nmax_history_messages = 30\n\n# Agent execution timeout in seconds\nagent_timeout = 300\n\n\n# =============================================================================\n# Logging\n# =============================================================================\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n# Optional: NONE, ERROR, WARNING, INFO, DEBUG\n# level = \"INFO\"\n\n\n# =============================================================================\n# LLM Provider Profiles\n# =============================================================================\n#\n# Each [llm.<name>] section defines a provider profile. Set [app].provider\n# to the profile name you want to use.\n#\n# driver may be: openai, ollama, deepseek (core, always available),\n# anthropic, google, qwen (or dashscope), glm (or zhipu).\n# Non-core drivers require their extra, e.g.:\n# pip install ayder-cli[anthropic]\n#\n# Required fields per profile:\n# driver - SDK backend: \"openai\", \"ollama\", \"anthropic\", \"google\",\n# \"deepseek\", \"qwen\", or \"glm\"\n# model - Model identifier\n#\n# Optional fields:\n# base_url - API endpoint (required for openai/ollama drivers)\n# api_key - Authentication key\n# num_ctx - Context window size in tokens\n# max_output_tokens - Maximum response length\n# chat_protocol - \"ollama\" (native tool calls) or \"xml\" (XML fallback)\n# stop_sequences - Custom stop tokens\n# tool_tags - Which tool groups to expose: [\"core\", \"metadata\"]\n\n\n# -----------------------------------------------------------------------------\n# Ollama (Local LLMs)\n# -----------------------------------------------------------------------------\n# Driver: \"ollama\" — uses native ollama SDK with full timing/cache observability\n#\n# Prerequisites:\n# 1. Install Ollama: https://ollama.com\n# 2. Pull a model: ollama pull qwen3-coder\n# 3. Ollama runs on localhost:11434 by default\n#\n# The \"ollama\" driver provides:\n# - KV-cache-aware context management (stable prefix, no reordering)\n# - Real token counts from prompt_eval_count (not estimates)\n# - Cache hit detection via timing data (prompt_eval_duration)\n# - Adaptive compaction that preserves hot cache\n# - Native thinking support (message.thinking field)\n# - keep_alive=-1 to prevent model unloading mid-session\n\n[llm.openai]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\napi_key = \"ollama\" # Ollama ignores this, but field is required\nmodel = \"qwen3-coder:latest\"\nnum_ctx = 65536 # Context window — match your model's max\nmax_output_tokens = 4096\nchat_protocol = \"ollama\" # \"ollama\" = native tool calls, \"xml\" = fallback\ntool_tags = [\"core\", \"metadata\"]\n\n# Alternative Ollama models:\n# model = \"deepseek-r1:14b\" # Strong reasoning, uses <think> tags\n# model = \"llama3.3:70b\" # Large, high quality\n# model = \"codellama:13b\" # Code-focused\n# model = \"qwen3:32b\" # Good balance of speed and quality\n# model = \"gemma3:27b\" # Google's open model\n\n\n# -----------------------------------------------------------------------------\n# OpenAI\n# -----------------------------------------------------------------------------\n# Driver: \"openai\" — standard OpenAI SDK\n#\n# Get your API key: https://platform.openai.com/api-keys\n# The openai driver also works with any OpenAI-compatible API (vLLM, LM Studio,\n# Together AI, Groq, etc.) — just change base_url.\n\n[llm.openai-cloud]\ndriver = \"openai\"\nbase_url = \"https://api.openai.com/v1\"\napi_key = \"sk-...\" # Your OpenAI API key\nmodel = \"gpt-4o\"\nnum_ctx = 128000\nmax_output_tokens = 4096\n\n# OpenAI-compatible endpoints (same driver, different base_url):\n#\n# [llm.deepseek]\n# driver = \"openai\"\n# base_url = \"https://api.deepseek.com/v1\"\n# api_key = \"sk-...\"\n# model = \"deepseek-chat\"\n# num_ctx = 65536\n#\n# [llm.together]\n# driver = \"openai\"\n# base_url = \"https://api.together.xyz/v1\"\n# api_key = \"...\"\n# model = \"meta-llama/Meta-Llama-3.1-70B-Instruct-Turbo\"\n# num_ctx = 131072\n#\n# [llm.groq]\n# driver = \"openai\"\n# base_url = \"https://api.groq.com/openai/v1\"\n# api_key = \"gsk_...\"\n# model = \"llama-3.3-70b-versatile\"\n# num_ctx = 131072\n#\n# [llm.lmstudio]\n# driver = \"openai\"\n# base_url = \"http://localhost:1234/v1\"\n# api_key = \"lm-studio\"\n# model = \"local-model\"\n# num_ctx = 32768\n\n\n# -----------------------------------------------------------------------------\n# Anthropic (Claude)\n# -----------------------------------------------------------------------------\n# Driver: \"anthropic\" — native Anthropic SDK with prompt caching\n#\n# Get your API key: https://console.anthropic.com/settings/keys\n# Claude models handle context management server-side (prompt caching,\n# 200K+ context windows), so the local context manager uses DefaultContextManager.\n\n[llm.anthropic]\ndriver = \"anthropic\"\napi_key = \"sk-ant-...\" # Your Anthropic API key\nmodel = \"claude-sonnet-4-5-20250929\"\nnum_ctx = 200000 # Claude supports up to 200K tokens\nmax_output_tokens = 8192\n\n# Other Claude models:\n# model = \"claude-opus-4-5-20250929\" # Most capable, highest cost\n# model = \"claude-haiku-4-5-20250929\" # Fastest, lowest cost\n\n\n# -----------------------------------------------------------------------------\n# Google (Gemini)\n# -----------------------------------------------------------------------------\n# Driver: \"google\" — native Google Generative AI SDK\n#\n# Get your API key: https://aistudio.google.com/apikey\n# Gemini models support very large context windows (1M+ tokens).\n\n[llm.gemini]\ndriver = \"google\"\napi_key = \"AIza...\" # Your Google AI API key\nmodel = \"gemini-2.5-flash\"\nnum_ctx = 1048576 # Gemini supports up to 1M tokens\nmax_output_tokens = 8192\n\n# Other Gemini models:\n# model = \"gemini-2.5-pro\" # Most capable\n# model = \"gemini-2.0-flash-lite\" # Fastest, lowest cost\n\n\n# =============================================================================\n# Context Manager\n# =============================================================================\n#\n# Controls how conversation history is managed within the context window.\n#\n# Behavior varies by driver:\n# - \"ollama\" driver → OllamaContextManager (KV-cache aware, stable prefix)\n# - All other drivers → DefaultContextManager (tiered trimming)\n#\n# The factory automatically selects the right implementation based on driver.\n\n[context_manager]\nenabled = true\nmax_context_tokens = 8192 # Fallback if provider doesn't report\nreserve_ratio = 0.30 # Reserve 30% for response generation\ncompaction_threshold = 0.70 # Trigger compaction at 70% utilization\ntool_result_compress_age = 5 # Compress tool results older than N turns\nmax_tool_result_length = 2048 # Max chars per tool result before truncation\ncompress_tool_results = true # Enable automatic tool result compression\n\n\n# =============================================================================\n# Agents\n# =============================================================================\n#\n# Agents are autonomous sub-tasks that can use different LLM providers/models.\n# Each agent inherits from [app].provider unless overridden.\n#\n# Fields:\n# provider - LLM profile name (optional, inherits from app)\n# model - Model override (optional, inherits from provider profile)\n# system_prompt - Agent-specific instructions (required)\n\n[agents.code-reviewer]\nprovider = \"anthropic\"\nmodel = \"claude-sonnet-4-5-20250929\"\nsystem_prompt = \"\"\"You are a senior code reviewer. Review the code for:\n- Correctness and edge cases\n- Security vulnerabilities (OWASP top 10)\n- Performance issues\n- Code style and readability\nProvide specific, actionable feedback with file:line references.\"\"\"\n\n[agents.test-writer]\n# Inherits provider and model from [app].provider\nsystem_prompt = \"\"\"You are a test engineer. Write comprehensive unit tests that:\n- Cover happy paths and edge cases\n- Use appropriate mocking for external dependencies\n- Follow the existing test patterns in the codebase\n- Include clear test names that describe the expected behavior\"\"\"\n\n[agents.doc-generator]\nprovider = \"gemini\"\nmodel = \"gemini-2.5-flash\"\nsystem_prompt = \"\"\"You generate clear technical documentation. Focus on:\n- API usage examples with realistic inputs/outputs\n- Architecture decisions and trade-offs\n- Setup and configuration instructions\nKeep documentation concise and scannable.\"\"\"\n\n[agents.quick-fix]\nprovider = \"openai\" # Uses the Ollama local profile\nmodel = \"qwen3-coder:latest\"\nsystem_prompt = \"\"\"You are a quick bug fixer. Given a bug report:\n1. Identify the root cause\n2. Propose a minimal fix\n3. Write the fix and a regression test\nStay focused — fix the bug, nothing else.\"\"\"\n\n# Example: Agent using a cloud OpenAI model\n# [agents.architect]\n# provider = \"openai-cloud\"\n# model = \"gpt-4o\"\n# system_prompt = \"You are a software architect...\"\n\n# Example: Agent using DeepSeek for reasoning-heavy tasks\n# [agents.researcher]\n# provider = \"deepseek\"\n# model = \"deepseek-reasoner\"\n# system_prompt = \"You research codebases and produce analysis reports...\"\n\n\n# =============================================================================\n# Temporal (Optional — Workflow Orchestration)\n# =============================================================================\n#\n# Temporal enables durable workflow execution for long-running agent tasks.\n# Requires a running Temporal server. Most users can skip this section.\n\n[temporal]\nenabled = false\nhost = \"localhost:7233\"\nnamespace = \"default\"\nmetadata_dir = \".ayder/temporal\"\n\n[temporal.timeouts]\nworkflow_schedule_to_close_seconds = 7200\nactivity_start_to_close_seconds = 900\nactivity_heartbeat_seconds = 30\n\n[temporal.retry]\ninitial_interval_seconds = 5\nbackoff_coefficient = 2.0\nmaximum_interval_seconds = 60\nmaximum_attempts = 3\n"}, "02a7721dadce96b5707ec7396e2587fb6de4f7e2": {"t": 1785767770.0497766, "n": 11662, "h": "2602f9e569318171", "c": "# =============================================================================\n# ayder-cli Configuration (Schema v2.0)\n# =============================================================================\n#\n# Location: ~/.ayder/config.toml\n#\n# This file configures ayder-cli's LLM providers, agents, context management,\n# and application behavior. Copy this file to ~/.ayder/config.toml and\n# customize to your needs.\n#\n# Key concepts:\n# - \"provider\" selects which [llm.*] profile is active\n# - \"driver\" determines the SDK used (openai, ollama, anthropic, google)\n# - Agents can use different providers/models than the main config\n# - Context manager behavior adapts per driver (Ollama gets KV-cache awareness)\n\nconfig_version = \"2.0\"\n\n\n# =============================================================================\n# Application Settings\n# =============================================================================\n\n[app]\n# Which LLM profile to use (must match a key under [llm.*] below)\nprovider = \"openai\"\n\n# System editor for file editing operations\neditor = \"vim\"\n\n# Enable verbose debug output\nverbose = false\n\n# Maximum concurrent background tool processes (1-20)\nmax_background_processes = 5\n\n# Maximum conversation history messages (0 = unlimited)\nmax_history_messages = 30\n\n# Agent execution timeout in seconds\nagent_timeout = 300\n\n\n# =============================================================================\n# Logging\n# =============================================================================\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n# Optional: NONE, ERROR, WARNING, INFO, DEBUG\n# level = \"INFO\"\n\n\n# =============================================================================\n# LLM Provider Profiles\n# =============================================================================\n#\n# Each [llm.<name>] section defines a provider profile. Set [app].provider\n# to the profile name you want to use.\n#\n# driver may be: openai, ollama, deepseek (core, always available),\n# anthropic, google, qwen (or dashscope), glm (or zhipu).\n# Non-core drivers require their extra, e.g.:\n# pip install ayder-cli[anthropic]\n#\n# Required fields per profile:\n# driver - SDK backend: \"openai\", \"ollama\", \"anthropic\", \"google\",\n# \"deepseek\", \"qwen\", or \"glm\"\n# model - Model identifier\n#\n# Optional fields:\n# base_url - API endpoint (required for openai/ollama drivers)\n# api_key - Authentication key\n# num_ctx - Context window size in tokens\n# max_output_tokens - Maximum response length\n# chat_protocol - \"ollama\" (native tool calls) or \"xml\" (XML fallback)\n# stop_sequences - Custom stop tokens\n# tool_tags - Which tool groups to expose: [\"core\", \"metadata\"]\n\n\n# -----------------------------------------------------------------------------\n# Ollama (Local LLMs)\n# -----------------------------------------------------------------------------\n# Driver: \"ollama\" — uses native ollama SDK with full timing/cache observability\n#\n# Prerequisites:\n# 1. Install Ollama: https://ollama.com\n# 2. Pull a model: ollama pull qwen3-coder\n# 3. Ollama runs on localhost:11434 by default\n#\n# The \"ollama\" driver provides:\n# - KV-cache-aware context management (stable prefix, no reordering)\n# - Real token counts from prompt_eval_count (not estimates)\n# - Cache hit detection via timing data (prompt_eval_duration)\n# - Adaptive compaction that preserves hot cache\n# - Native thinking support (message.thinking field)\n# - keep_alive=-1 to prevent model unloading mid-session\n\n[llm.openai]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\napi_key = \"ollama\" # Ollama ignores this, but field is required\nmodel = \"qwen3-coder:latest\"\nnum_ctx = 65536 # Context window — match your model's max\nmax_output_tokens = 4096\nchat_protocol = \"ollama\" # \"ollama\" = native tool calls, \"xml\" = fallback\ntool_tags = [\"core\", \"metadata\"]\n\n# Alternative Ollama models:\n# model = \"deepseek-r1:14b\" # Strong reasoning, uses <think> tags\n# model = \"llama3.3:70b\" # Large, high quality\n# model = \"codellama:13b\" # Code-focused\n# model = \"qwen3:32b\" # Good balance of speed and quality\n# model = \"gemma3:27b\" # Google's open model\n\n\n# -----------------------------------------------------------------------------\n# OpenAI\n# -----------------------------------------------------------------------------\n# Driver: \"openai\" — standard OpenAI SDK\n#\n# Get your API key: https://platform.openai.com/api-keys\n# The openai driver also works with any OpenAI-compatible API (vLLM, LM Studio,\n# Together AI, Groq, etc.) — just change base_url.\n\n[llm.openai-cloud]\ndriver = \"openai\"\nbase_url = \"https://api.openai.com/v1\"\napi_key = \"sk-...\" # Your OpenAI API key\nmodel = \"gpt-4o\"\nnum_ctx = 128000\nmax_output_tokens = 4096\n\n# OpenAI-compatible endpoints (same driver, different base_url):\n#\n# [llm.deepseek]\n# driver = \"openai\"\n# base_url = \"https://api.deepseek.com/v1\"\n# api_key = \"sk-...\"\n# model = \"deepseek-chat\"\n# num_ctx = 65536\n#\n# [llm.together]\n# driver = \"openai\"\n# base_url = \"https://api.together.xyz/v1\"\n# api_key = \"...\"\n# model = \"meta-llama/Meta-Llama-3.1-70B-Instruct-Turbo\"\n# num_ctx = 131072\n#\n# [llm.groq]\n# driver = \"openai\"\n# base_url = \"https://api.groq.com/openai/v1\"\n# api_key = \"gsk_...\"\n# model = \"llama-3.3-70b-versatile\"\n# num_ctx = 131072\n#\n# [llm.lmstudio]\n# driver = \"openai\"\n# base_url = \"http://localhost:1234/v1\"\n# api_key = \"lm-studio\"\n# model = \"local-model\"\n# num_ctx = 32768\n\n\n# -----------------------------------------------------------------------------\n# Anthropic (Claude)\n# -----------------------------------------------------------------------------\n# Driver: \"anthropic\" — native Anthropic SDK with prompt caching\n#\n# Get your API key: https://console.anthropic.com/settings/keys\n# Claude models handle context management server-side (prompt caching,\n# 200K+ context windows), so the local context manager uses DefaultContextManager.\n\n[llm.anthropic]\ndriver = \"anthropic\"\napi_key = \"sk-ant-...\" # Your Anthropic API key\nmodel = \"claude-sonnet-4-5-20250929\"\nnum_ctx = 200000 # Claude supports up to 200K tokens\nmax_output_tokens = 8192\n\n# Other Claude models:\n# model = \"claude-opus-4-5-20250929\" # Most capable, highest cost\n# model = \"claude-haiku-4-5-20250929\" # Fastest, lowest cost\n\n\n# -----------------------------------------------------------------------------\n# Google (Gemini)\n# -----------------------------------------------------------------------------\n# Driver: \"google\" — native Google Generative AI SDK\n#\n# Get your API key: https://aistudio.google.com/apikey\n# Gemini models support very large context windows (1M+ tokens).\n\n[llm.gemini]\ndriver = \"google\"\napi_key = \"AIza...\" # Your Google AI API key\nmodel = \"gemini-2.5-flash\"\nnum_ctx = 1048576 # Gemini supports up to 1M tokens\nmax_output_tokens = 8192\n\n# Other Gemini models:\n# model = \"gemini-2.5-pro\" # Most capable\n# model = \"gemini-2.0-flash-lite\" # Fastest, lowest cost\n\n\n# =============================================================================\n# Context Manager\n# =============================================================================\n#\n# Controls how conversation history is managed within the context window.\n#\n# Behavior varies by driver:\n# - \"ollama\" driver → OllamaContextManager (KV-cache aware, stable prefix)\n# - All other drivers → DefaultContextManager (tiered trimming)\n#\n# The factory automatically selects the right implementation based on driver.\n\n[context_manager]\nenabled = true\nmax_context_tokens = 8192 # Fallback if provider doesn't report\nreserve_ratio = 0.30 # Reserve 30% for response generation\ncompaction_threshold = 0.70 # Trigger compaction at 70% utilization\ntool_result_compress_age = 5 # Compress tool results older than N turns\nmax_tool_result_length = 2048 # Max chars per tool result before truncation\ncompress_tool_results = true # Enable automatic tool result compression\n\n# Per-model overrides (optional)\n# [context_manager.model_overrides.\"gpt-4o\"]\n# max_context_tokens = 128000\n# reserve_ratio = 0.20\n\n\n# =============================================================================\n# Agents\n# =============================================================================\n#\n# Agents are autonomous sub-tasks that can use different LLM providers/models.\n# Each agent inherits from [app].provider unless overridden.\n#\n# Fields:\n# provider - LLM profile name (optional, inherits from app)\n# model - Model override (optional, inherits from provider profile)\n# system_prompt - Agent-specific instructions (required)\n\n[agents.code-reviewer]\nprovider = \"anthropic\"\nmodel = \"claude-sonnet-4-5-20250929\"\nsystem_prompt = \"\"\"You are a senior code reviewer. Review the code for:\n- Correctness and edge cases\n- Security vulnerabilities (OWASP top 10)\n- Performance issues\n- Code style and readability\nProvide specific, actionable feedback with file:line references.\"\"\"\n\n[agents.test-writer]\n# Inherits provider and model from [app].provider\nsystem_prompt = \"\"\"You are a test engineer. Write comprehensive unit tests that:\n- Cover happy paths and edge cases\n- Use appropriate mocking for external dependencies\n- Follow the existing test patterns in the codebase\n- Include clear test names that describe the expected behavior\"\"\"\n\n[agents.doc-generator]\nprovider = \"gemini\"\nmodel = \"gemini-2.5-flash\"\nsystem_prompt = \"\"\"You generate clear technical documentation. Focus on:\n- API usage examples with realistic inputs/outputs\n- Architecture decisions and trade-offs\n- Setup and configuration instructions\nKeep documentation concise and scannable.\"\"\"\n\n[agents.quick-fix]\nprovider = \"openai\" # Uses the Ollama local profile\nmodel = \"qwen3-coder:latest\"\nsystem_prompt = \"\"\"You are a quick bug fixer. Given a bug report:\n1. Identify the root cause\n2. Propose a minimal fix\n3. Write the fix and a regression test\nStay focused — fix the bug, nothing else.\"\"\"\n\n# Example: Agent using a cloud OpenAI model\n# [agents.architect]\n# provider = \"openai-cloud\"\n# model = \"gpt-4o\"\n# system_prompt = \"You are a software architect...\"\n\n# Example: Agent using DeepSeek for reasoning-heavy tasks\n# [agents.researcher]\n# provider = \"deepseek\"\n# model = \"deepseek-reasoner\"\n# system_prompt = \"You research codebases and produce analysis reports...\"\n\n\n# =============================================================================\n# Temporal (Optional — Workflow Orchestration)\n# =============================================================================\n#\n# Temporal enables durable workflow execution for long-running agent tasks.\n# Requires a running Temporal server. Most users can skip this section.\n\n[temporal]\nenabled = false\nhost = \"localhost:7233\"\nnamespace = \"default\"\nmetadata_dir = \".ayder/temporal\"\n\n[temporal.timeouts]\nworkflow_schedule_to_close_seconds = 7200\nactivity_start_to_close_seconds = 900\nactivity_heartbeat_seconds = 30\n\n[temporal.retry]\ninitial_interval_seconds = 5\nbackoff_coefficient = 2.0\nmaximum_interval_seconds = 60\nmaximum_attempts = 3\n"}, "d235d0750ac96ea0d7d697aad8f40cc035011491": {"t": 1785767771.2655404, "n": 11243, "h": "323fb8cdbc82fdd2", "c": "# =============================================================================\n# ayder-cli Configuration (Schema v2.0)\n# =============================================================================\n#\n# Location: ~/.ayder/config.toml\n#\n# This file configures ayder-cli's LLM providers, agents, context management,\n# and application behavior. Copy this file to ~/.ayder/config.toml and\n# customize to your needs.\n#\n# Key concepts:\n# - \"provider\" selects which [llm.*] profile is active\n# - \"driver\" determines the SDK used (openai, ollama, anthropic, google)\n# - Agents can use different providers/models than the main config\n# - Context manager behavior adapts per driver (Ollama gets KV-cache awareness)\n\nconfig_version = \"2.0\"\n\n\n# =============================================================================\n# Application Settings\n# =============================================================================\n\n[app]\n# Which LLM profile to use (must match a key under [llm.*] below)\nprovider = \"openai\"\n\n# System editor for file editing operations\neditor = \"vim\"\n\n# Enable verbose debug output\nverbose = false\n\n# Maximum concurrent background tool processes (1-20)\nmax_background_processes = 5\n\n# Maximum conversation history messages (0 = unlimited)\nmax_history_messages = 30\n\n# Agent execution timeout in seconds\nagent_timeout = 300\n\n\n# =============================================================================\n# Logging\n# =============================================================================\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n# Optional: NONE, ERROR, WARNING, INFO, DEBUG\n# level = \"INFO\"\n\n\n# =============================================================================\n# LLM Provider Profiles\n# =============================================================================\n#\n# Each [llm.<name>] section defines a provider profile. Set [app].provider\n# to the profile name you want to use.\n#\n# Required fields per profile:\n# driver - SDK backend: \"openai\", \"ollama\", \"anthropic\", \"google\"\n# model - Model identifier\n#\n# Optional fields:\n# base_url - API endpoint (required for openai/ollama drivers)\n# api_key - Authentication key\n# num_ctx - Context window size in tokens\n# max_output_tokens - Maximum response length\n# chat_protocol - \"ollama\" (native tool calls) or \"xml\" (XML fallback)\n# stop_sequences - Custom stop tokens\n# tool_tags - Which tool groups to expose: [\"core\", \"metadata\"]\n\n\n# -----------------------------------------------------------------------------\n# Ollama (Local LLMs)\n# -----------------------------------------------------------------------------\n# Driver: \"ollama\" — uses native ollama SDK with full timing/cache observability\n#\n# Prerequisites:\n# 1. Install Ollama: https://ollama.com\n# 2. Pull a model: ollama pull qwen3-coder\n# 3. Ollama runs on localhost:11434 by default\n#\n# The \"ollama\" driver provides:\n# - KV-cache-aware context management (stable prefix, no reordering)\n# - Real token counts from prompt_eval_count (not estimates)\n# - Cache hit detection via timing data (prompt_eval_duration)\n# - Adaptive compaction that preserves hot cache\n# - Native thinking support (message.thinking field)\n# - keep_alive=-1 to prevent model unloading mid-session\n\n[llm.openai]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\napi_key = \"ollama\" # Ollama ignores this, but field is required\nmodel = \"qwen3-coder:latest\"\nnum_ctx = 65536 # Context window — match your model's max\nmax_output_tokens = 4096\nchat_protocol = \"ollama\" # \"ollama\" = native tool calls, \"xml\" = fallback\ntool_tags = [\"core\", \"metadata\"]\n\n# Alternative Ollama models:\n# model = \"deepseek-r1:14b\" # Strong reasoning, uses <think> tags\n# model = \"llama3.3:70b\" # Large, high quality\n# model = \"codellama:13b\" # Code-focused\n# model = \"qwen3:32b\" # Good balance of speed and quality\n# model = \"gemma3:27b\" # Google's open model\n\n\n# -----------------------------------------------------------------------------\n# OpenAI\n# -----------------------------------------------------------------------------\n# Driver: \"openai\" — standard OpenAI SDK\n#\n# Get your API key: https://platform.openai.com/api-keys\n# The openai driver also works with any OpenAI-compatible API (vLLM, LM Studio,\n# Together AI, Groq, etc.) — just change base_url.\n\n[llm.openai-cloud]\ndriver = \"openai\"\nbase_url = \"https://api.openai.com/v1\"\napi_key = \"sk-...\" # Your OpenAI API key\nmodel = \"gpt-4o\"\nnum_ctx = 128000\nmax_output_tokens = 4096\n\n# OpenAI-compatible endpoints (same driver, different base_url):\n#\n# [llm.deepseek]\n# driver = \"openai\"\n# base_url = \"https://api.deepseek.com/v1\"\n# api_key = \"sk-...\"\n# model = \"deepseek-chat\"\n# num_ctx = 65536\n#\n# [llm.together]\n# driver = \"openai\"\n# base_url = \"https://api.together.xyz/v1\"\n# api_key = \"...\"\n# model = \"meta-llama/Meta-Llama-3.1-70B-Instruct-Turbo\"\n# num_ctx = 131072\n#\n# [llm.groq]\n# driver = \"openai\"\n# base_url = \"https://api.groq.com/openai/v1\"\n# api_key = \"gsk_...\"\n# model = \"llama-3.3-70b-versatile\"\n# num_ctx = 131072\n#\n# [llm.lmstudio]\n# driver = \"openai\"\n# base_url = \"http://localhost:1234/v1\"\n# api_key = \"lm-studio\"\n# model = \"local-model\"\n# num_ctx = 32768\n\n\n# -----------------------------------------------------------------------------\n# Anthropic (Claude)\n# -----------------------------------------------------------------------------\n# Driver: \"anthropic\" — native Anthropic SDK with prompt caching\n#\n# Get your API key: https://console.anthropic.com/settings/keys\n# Claude models handle context management server-side (prompt caching,\n# 200K+ context windows), so the local context manager uses DefaultContextManager.\n\n[llm.anthropic]\ndriver = \"anthropic\"\napi_key = \"sk-ant-...\" # Your Anthropic API key\nmodel = \"claude-sonnet-4-5-20250929\"\nnum_ctx = 200000 # Claude supports up to 200K tokens\nmax_output_tokens = 8192\n\n# Other Claude models:\n# model = \"claude-opus-4-5-20250929\" # Most capable, highest cost\n# model = \"claude-haiku-4-5-20250929\" # Fastest, lowest cost\n\n\n# -----------------------------------------------------------------------------\n# Google (Gemini)\n# -----------------------------------------------------------------------------\n# Driver: \"google\" — native Google Generative AI SDK\n#\n# Get your API key: https://aistudio.google.com/apikey\n# Gemini models support very large context windows (1M+ tokens).\n\n[llm.gemini]\ndriver = \"google\"\napi_key = \"AIza...\" # Your Google AI API key\nmodel = \"gemini-2.5-flash\"\nnum_ctx = 1048576 # Gemini supports up to 1M tokens\nmax_output_tokens = 8192\n\n# Other Gemini models:\n# model = \"gemini-2.5-pro\" # Most capable\n# model = \"gemini-2.0-flash-lite\" # Fastest, lowest cost\n\n\n# =============================================================================\n# Context Manager\n# =============================================================================\n#\n# Controls how conversation history is managed within the context window.\n#\n# Behavior varies by driver:\n# - \"ollama\" driver → OllamaContextManager (KV-cache aware, stable prefix)\n# - All other drivers → DefaultContextManager (tiered trimming)\n#\n# The factory automatically selects the right implementation based on driver.\n\n[context_manager]\nenabled = true\nmax_context_tokens = 8192 # Fallback if provider doesn't report\nreserve_ratio = 0.30 # Reserve 30% for response generation\ncompaction_threshold = 0.70 # Trigger compaction at 70% utilization\ntool_result_compress_age = 5 # Compress tool results older than N turns\nmax_tool_result_length = 2048 # Max chars per tool result before truncation\ncompress_tool_results = true # Enable automatic tool result compression\n\n\n# =============================================================================\n# Agents\n# =============================================================================\n#\n# Agents are autonomous sub-tasks that can use different LLM providers/models.\n# Each agent inherits from [app].provider unless overridden.\n#\n# Fields:\n# provider - LLM profile name (optional, inherits from app)\n# model - Model override (optional, inherits from provider profile)\n# system_prompt - Agent-specific instructions (required)\n\n[agents.code-reviewer]\nprovider = \"anthropic\"\nmodel = \"claude-sonnet-4-5-20250929\"\nsystem_prompt = \"\"\"You are a senior code reviewer. Review the code for:\n- Correctness and edge cases\n- Security vulnerabilities (OWASP top 10)\n- Performance issues\n- Code style and readability\nProvide specific, actionable feedback with file:line references.\"\"\"\n\n[agents.test-writer]\n# Inherits provider and model from [app].provider\nsystem_prompt = \"\"\"You are a test engineer. Write comprehensive unit tests that:\n- Cover happy paths and edge cases\n- Use appropriate mocking for external dependencies\n- Follow the existing test patterns in the codebase\n- Include clear test names that describe the expected behavior\"\"\"\n\n[agents.doc-generator]\nprovider = \"gemini\"\nmodel = \"gemini-2.5-flash\"\nsystem_prompt = \"\"\"You generate clear technical documentation. Focus on:\n- API usage examples with realistic inputs/outputs\n- Architecture decisions and trade-offs\n- Setup and configuration instructions\nKeep documentation concise and scannable.\"\"\"\n\n[agents.quick-fix]\nprovider = \"openai\" # Uses the Ollama local profile\nmodel = \"qwen3-coder:latest\"\nsystem_prompt = \"\"\"You are a quick bug fixer. Given a bug report:\n1. Identify the root cause\n2. Propose a minimal fix\n3. Write the fix and a regression test\nStay focused — fix the bug, nothing else.\"\"\"\n\n# Example: Agent using a cloud OpenAI model\n# [agents.architect]\n# provider = \"openai-cloud\"\n# model = \"gpt-4o\"\n# system_prompt = \"You are a software architect...\"\n\n# Example: Agent using DeepSeek for reasoning-heavy tasks\n# [agents.researcher]\n# provider = \"deepseek\"\n# model = \"deepseek-reasoner\"\n# system_prompt = \"You research codebases and produce analysis reports...\"\n\n\n# =============================================================================\n# Temporal (Optional — Workflow Orchestration)\n# =============================================================================\n#\n# Temporal enables durable workflow execution for long-running agent tasks.\n# Requires a running Temporal server. Most users can skip this section.\n\n[temporal]\nenabled = false\nhost = \"localhost:7233\"\nnamespace = \"default\"\nmetadata_dir = \".ayder/temporal\"\n\n[temporal.timeouts]\nworkflow_schedule_to_close_seconds = 7200\nactivity_start_to_close_seconds = 900\nactivity_heartbeat_seconds = 30\n\n[temporal.retry]\ninitial_interval_seconds = 5\nbackoff_coefficient = 2.0\nmaximum_interval_seconds = 60\nmaximum_attempts = 3\n"}, "a54ce2649b549ecf4802ba84af73ec3f0c48bf3b": {"t": 1785767772.5472596, "n": 11375, "h": "f5603e7d282396a1", "c": "# =============================================================================\n# ayder-cli Configuration (Schema v2.0)\n# =============================================================================\n#\n# Location: ~/.ayder/config.toml\n#\n# This file configures ayder-cli's LLM providers, agents, context management,\n# and application behavior. Copy this file to ~/.ayder/config.toml and\n# customize to your needs.\n#\n# Key concepts:\n# - \"provider\" selects which [llm.*] profile is active\n# - \"driver\" determines the SDK used (openai, ollama, anthropic, google)\n# - Agents can use different providers/models than the main config\n# - Context manager behavior adapts per driver (Ollama gets KV-cache awareness)\n\nconfig_version = \"2.0\"\n\n\n# =============================================================================\n# Application Settings\n# =============================================================================\n\n[app]\n# Which LLM profile to use (must match a key under [llm.*] below)\nprovider = \"openai\"\n\n# System editor for file editing operations\neditor = \"vim\"\n\n# Enable verbose debug output\nverbose = false\n\n# Maximum concurrent background tool processes (1-20)\nmax_background_processes = 5\n\n# Maximum conversation history messages (0 = unlimited)\nmax_history_messages = 30\n\n# Agent execution timeout in seconds\nagent_timeout = 300\n\n\n# =============================================================================\n# Logging\n# =============================================================================\n\n[logging]\nfile_enabled = true\nfile_path = \".ayder/log/ayder.log\"\nrotation = \"10 MB\"\nretention = \"7 days\"\n# Optional: NONE, ERROR, WARNING, INFO, DEBUG\n# level = \"INFO\"\n\n\n# =============================================================================\n# LLM Provider Profiles\n# =============================================================================\n#\n# Each [llm.<name>] section defines a provider profile. Set [app].provider\n# to the profile name you want to use.\n#\n# Required fields per profile:\n# driver - SDK backend: \"openai\", \"ollama\", \"anthropic\", \"google\"\n# model - Model identifier\n#\n# Optional fields:\n# base_url - API endpoint (required for openai/ollama drivers)\n# api_key - Authentication key\n# num_ctx - Context window size in tokens\n# max_output_tokens - Maximum response length\n# chat_protocol - \"ollama\" (native tool calls) or \"xml\" (XML fallback)\n# stop_sequences - Custom stop tokens\n# tool_tags - Which tool groups to expose: [\"core\", \"metadata\"]\n\n\n# -----------------------------------------------------------------------------\n# Ollama (Local LLMs)\n# -----------------------------------------------------------------------------\n# Driver: \"ollama\" — uses native ollama SDK with full timing/cache observability\n#\n# Prerequisites:\n# 1. Install Ollama: https://ollama.com\n# 2. Pull a model: ollama pull qwen3-coder\n# 3. Ollama runs on localhost:11434 by default\n#\n# The \"ollama\" driver provides:\n# - KV-cache-aware context management (stable prefix, no reordering)\n# - Real token counts from prompt_eval_count (not estimates)\n# - Cache hit detection via timing data (prompt_eval_duration)\n# - Adaptive compaction that preserves hot cache\n# - Native thinking support (message.thinking field)\n# - keep_alive=-1 to prevent model unloading mid-session\n\n[llm.openai]\ndriver = \"ollama\"\nbase_url = \"http://localhost:11434\"\napi_key = \"ollama\" # Ollama ignores this, but field is required\nmodel = \"qwen3-coder:latest\"\nnum_ctx = 65536 # Context window — match your model's max\nmax_output_tokens = 4096\nchat_protocol = \"ollama\" # \"ollama\" = native tool calls, \"xml\" = fallback\ntool_tags = [\"core\", \"metadata\"]\n\n# Alternative Ollama models:\n# model = \"deepseek-r1:14b\" # Strong reasoning, uses <think> tags\n# model = \"llama3.3:70b\" # Large, high quality\n# model = \"codellama:13b\" # Code-focused\n# model = \"qwen3:32b\" # Good balance of speed and quality\n# model = \"gemma3:27b\" # Google's open model\n\n\n# -----------------------------------------------------------------------------\n# OpenAI\n# -----------------------------------------------------------------------------\n# Driver: \"openai\" — standard OpenAI SDK\n#\n# Get your API key: https://platform.openai.com/api-keys\n# The openai driver also works with any OpenAI-compatible API (vLLM, LM Studio,\n# Together AI, Groq, etc.) — just change base_url.\n\n[llm.openai-cloud]\ndriver = \"openai\"\nbase_url = \"https://api.openai.com/v1\"\napi_key = \"sk-...\" # Your OpenAI API key\nmodel = \"gpt-4o\"\nnum_ctx = 128000\nmax_output_tokens = 4096\n\n# OpenAI-compatible endpoints (same driver, different base_url):\n#\n# [llm.deepseek]\n# driver = \"openai\"\n# base_url = \"https://api.deepseek.com/v1\"\n# api_key = \"sk-...\"\n# model = \"deepseek-chat\"\n# num_ctx = 65536\n#\n# [llm.together]\n# driver = \"openai\"\n# base_url = \"https://api.together.xyz/v1\"\n# api_key = \"...\"\n# model = \"meta-llama/Meta-Llama-3.1-70B-Instruct-Turbo\"\n# num_ctx = 131072\n#\n# [llm.groq]\n# driver = \"openai\"\n# base_url = \"https://api.groq.com/openai/v1\"\n# api_key = \"gsk_...\"\n# model = \"llama-3.3-70b-versatile\"\n# num_ctx = 131072\n#\n# [llm.lmstudio]\n# driver = \"openai\"\n# base_url = \"http://localhost:1234/v1\"\n# api_key = \"lm-studio\"\n# model = \"local-model\"\n# num_ctx = 32768\n\n\n# -----------------------------------------------------------------------------\n# Anthropic (Claude)\n# -----------------------------------------------------------------------------\n# Driver: \"anthropic\" — native Anthropic SDK with prompt caching\n#\n# Get your API key: https://console.anthropic.com/settings/keys\n# Claude models handle context management server-side (prompt caching,\n# 200K+ context windows), so the local context manager uses DefaultContextManager.\n\n[llm.anthropic]\ndriver = \"anthropic\"\napi_key = \"sk-ant-...\" # Your Anthropic API key\nmodel = \"claude-sonnet-4-5-20250929\"\nnum_ctx = 200000 # Claude supports up to 200K tokens\nmax_output_tokens = 8192\n\n# Other Claude models:\n# model = \"claude-opus-4-5-20250929\" # Most capable, highest cost\n# model = \"claude-haiku-4-5-20250929\" # Fastest, lowest cost\n\n\n# -----------------------------------------------------------------------------\n# Google (Gemini)\n# -----------------------------------------------------------------------------\n# Driver: \"google\" — native Google Generative AI SDK\n#\n# Get your API key: https://aistudio.google.com/apikey\n# Gemini models support very large context windows (1M+ tokens).\n\n[llm.gemini]\ndriver = \"google\"\napi_key = \"AIza...\" # Your Google AI API key\nmodel = \"gemini-2.5-flash\"\nnum_ctx = 1048576 # Gemini supports up to 1M tokens\nmax_output_tokens = 8192\n\n# Other Gemini models:\n# model = \"gemini-2.5-pro\" # Most capable\n# model = \"gemini-2.0-flash-lite\" # Fastest, lowest cost\n\n\n# =============================================================================\n# Context Manager\n# =============================================================================\n#\n# Controls how conversation history is managed within the context window.\n#\n# Behavior varies by driver:\n# - \"ollama\" driver → OllamaContextManager (KV-cache aware, stable prefix)\n# - All other drivers → DefaultContextManager (tiered trimming)\n#\n# The factory automatically selects the right implementation based on driver.\n\n[context_manager]\nenabled = true\nmax_context_tokens = 8192 # Fallback if provider doesn't report\nreserve_ratio = 0.30 # Reserve 30% for response generation\ncompaction_threshold = 0.70 # Trigger compaction at 70% utilization\ntool_result_compress_age = 5 # Compress tool results older than N turns\nmax_tool_result_length = 2048 # Max chars per tool result before truncation\ncompress_tool_results = true # Enable automatic tool result compression\n\n# Per-model overrides (optional)\n# [context_manager.model_overrides.\"gpt-4o\"]\n# max_context_tokens = 128000\n# reserve_ratio = 0.20\n\n\n# =============================================================================\n# Agents\n# =============================================================================\n#\n# Agents are autonomous sub-tasks that can use different LLM providers/models.\n# Each agent inherits from [app].provider unless overridden.\n#\n# Fields:\n# provider - LLM profile name (optional, inherits from app)\n# model - Model override (optional, inherits from provider profile)\n# system_prompt - Agent-specific instructions (required)\n\n[agents.code-reviewer]\nprovider = \"anthropic\"\nmodel = \"claude-sonnet-4-5-20250929\"\nsystem_prompt = \"\"\"You are a senior code reviewer. Review the code for:\n- Correctness and edge cases\n- Security vulnerabilities (OWASP top 10)\n- Performance issues\n- Code style and readability\nProvide specific, actionable feedback with file:line references.\"\"\"\n\n[agents.test-writer]\n# Inherits provider and model from [app].provider\nsystem_prompt = \"\"\"You are a test engineer. Write comprehensive unit tests that:\n- Cover happy paths and edge cases\n- Use appropriate mocking for external dependencies\n- Follow the existing test patterns in the codebase\n- Include clear test names that describe the expected behavior\"\"\"\n\n[agents.doc-generator]\nprovider = \"gemini\"\nmodel = \"gemini-2.5-flash\"\nsystem_prompt = \"\"\"You generate clear technical documentation. Focus on:\n- API usage examples with realistic inputs/outputs\n- Architecture decisions and trade-offs\n- Setup and configuration instructions\nKeep documentation concise and scannable.\"\"\"\n\n[agents.quick-fix]\nprovider = \"openai\" # Uses the Ollama local profile\nmodel = \"qwen3-coder:latest\"\nsystem_prompt = \"\"\"You are a quick bug fixer. Given a bug report:\n1. Identify the root cause\n2. Propose a minimal fix\n3. Write the fix and a regression test\nStay focused — fix the bug, nothing else.\"\"\"\n\n# Example: Agent using a cloud OpenAI model\n# [agents.architect]\n# provider = \"openai-cloud\"\n# model = \"gpt-4o\"\n# system_prompt = \"You are a software architect...\"\n\n# Example: Agent using DeepSeek for reasoning-heavy tasks\n# [agents.researcher]\n# provider = \"deepseek\"\n# model = \"deepseek-reasoner\"\n# system_prompt = \"You research codebases and produce analysis reports...\"\n\n\n# =============================================================================\n# Temporal (Optional — Workflow Orchestration)\n# =============================================================================\n#\n# Temporal enables durable workflow execution for long-running agent tasks.\n# Requires a running Temporal server. Most users can skip this section.\n\n[temporal]\nenabled = false\nhost = \"localhost:7233\"\nnamespace = \"default\"\nmetadata_dir = \".ayder/temporal\"\n\n[temporal.timeouts]\nworkflow_schedule_to_close_seconds = 7200\nactivity_start_to_close_seconds = 900\nactivity_heartbeat_seconds = 30\n\n[temporal.retry]\ninitial_interval_seconds = 5\nbackoff_coefficient = 2.0\nmaximum_interval_seconds = 60\nmaximum_attempts = 3\n"}}}} |