ayder-cli 1.8.3__tar.gz → 2.1.1__tar.gz

ayder_cli-2.1.1/CHANGELOG.md

@@ -0,0 +1,14 @@
+# Changelog
+
+## 2.0.0
+
+### Breaking
+- `anthropic` and `google-genai` are no longer installed by default. Install the
+  corresponding extra: `pip install ayder-cli[anthropic]` / `[google]`.
+- Default install now ships OpenAI + Ollama (+ DeepSeek, which reuses the OpenAI SDK).
+
+### Added
+- Optional extras: `[anthropic]`, `[google]`, `[qwen]`, `[glm]`, `[all]`.
+- Driver names `deepseek`, `qwen`/`dashscope`, `glm`/`zhipu` are now selectable.
+- Selecting an uninstalled driver fails fast with the exact `pip install` command
+  and a list of available drivers.

ayder_cli-1.8.3/README.md → ayder_cli-2.1.1/PKG-INFO

@@ -1,3 +1,43 @@
+Metadata-Version: 2.4
+Name: ayder-cli
+Version: 2.1.1
+Summary: AI agent for any LLMs
+Project-URL: Homepage, https://github.com/ayder/ayder-cli
+Project-URL: Repository, https://github.com/ayder/ayder-cli.git
+Project-URL: Issues, https://github.com/ayder/ayder-cli/issues
+Author-email: Sinan Alyuruk <sinan.alyuruk@gmail.com>
+License: MIT
+License-File: LICENSE
+Keywords: agent,ai,ayder,cli,llm,tui
+Classifier: Environment :: Console
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Programming Language :: Python :: 3
+Requires-Python: >=3.12
+Requires-Dist: httpx
+Requires-Dist: libcst>=1.0.0
+Requires-Dist: loguru
+Requires-Dist: ollama>=0.6.2
+Requires-Dist: openai
+Requires-Dist: python-dotenv>=1.0.0
+Requires-Dist: rich>=13.0.0
+Requires-Dist: textual<9.0.0,>=1.0.0
+Requires-Dist: tiktoken>=0.7.0
+Provides-Extra: all
+Requires-Dist: anthropic; extra == 'all'
+Requires-Dist: dashscope; extra == 'all'
+Requires-Dist: google-genai; extra == 'all'
+Requires-Dist: zhipuai; extra == 'all'
+Provides-Extra: anthropic
+Requires-Dist: anthropic; extra == 'anthropic'
+Provides-Extra: glm
+Requires-Dist: zhipuai; extra == 'glm'
+Provides-Extra: google
+Requires-Dist: google-genai; extra == 'google'
+Provides-Extra: qwen
+Requires-Dist: dashscope; extra == 'qwen'
+Description-Content-Type: text/markdown
+
 # ayder-cli
 
 A multi-provider AI agent chat client for your terminal. ayder supports Ollama, Anthropic Claude, OpenAI, Gemini,
@@ -5,6 +45,12 @@ or any OpenAI-compatible API and provides an autonomous coding assistant with fi
 
 ![ayder](docs/cc.png)
 
+## What's New in 2.0
+
+Provider 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).
+
+> **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.
+
 ## Supported LLM providers
 
 - [Ollama](https://ollama.com) (local or cloud)
@@ -25,7 +71,7 @@ Most AI coding assistants require cloud APIs, subscriptions, or heavy IDE plugin
 - **Agentic workflow** -- the LLM reads files, edits code, runs shell commands, and iterates autonomously with configurable iteration limits per message.
 - **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.
 - **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.
-- **Batteries included** -- the OpenAI, Anthropic, Google, and Ollama SDKs all ship with ayder-cli, so every provider works out of the box. The terminal UI is built on Rich and Textual.
+- **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.
 
 ### Tools
 
@@ -41,17 +87,29 @@ Each tool has an OpenAI-compatible JSON schema so models that support function c
 ## Installation
 
 Requires Python 3.12+.
-Works best with uv tool. If you don't have uv in your path, get it from
- [Astral uv](https://docs.astral.sh/uv/#highlights)
+Works best with uv. If you don't have uv in your path, get it from
+[Astral uv](https://docs.astral.sh/uv/#highlights).
+
+Core install (OpenAI + Ollama, plus DeepSeek which reuses the OpenAI SDK):
+
+    pip install ayder-cli
+
+Optional providers (install only what you use):
+
+    pip install ayder-cli[anthropic]   # Claude
+    pip install ayder-cli[google]      # Gemini
+    pip install ayder-cli[qwen]        # Qwen (dashscope)
+    pip install ayder-cli[glm]         # GLM (zhipuai)
+    pip install ayder-cli[all]         # everything
+
+If you select a driver whose package isn't installed, ayder prints the exact
+install command and lists the drivers available in your install.
 
 ```bash
-# Install to user environment
+# Install to user environment (uv tool)
 uv tool install ayder-cli
 
-# or install from PyPI
-pip install ayder-cli
-
-# For nightly builds:
+# Or for nightly / development builds:
 git clone https://github.com/ayder/ayder-cli.git
 cd ayder-cli
 
@@ -77,16 +135,19 @@ export OLLAMA_FLASH_ATTENTION=true
 export OLLAMA_MAX_LOADED_MODELS=1
 ```
 
-### Cloud providers (Anthropic, OpenAI, Gemini)
+### Cloud providers
 
-The Anthropic, OpenAI, and Google SDKs ship with ayder-cli — no extra installs.
-Just add an API key to a profile in `~/.ayder/config.toml` (see Configuration
+Add an API key to a profile in `~/.ayder/config.toml` (see Configuration
 below) and switch provider in the TUI:
 
 ```bash
-/provider anthropic   # or: openai, gemini
+/provider anthropic   # or: openai, google, deepseek, qwen, glm
 ```
 
+Note: `anthropic` and `google` require the corresponding optional extra
+(see Installation above). `openai`, `ollama`, and `deepseek` are included
+in the core install.
+
 ### Configuration: Profiles and Drivers
 
 ayder-cli uses a flexible profile-based configuration system. On the first run, it creates a config file at `~/.ayder/config.toml`.

ayder_cli-1.8.3/PKG-INFO → ayder_cli-2.1.1/README.md

@@ -1,32 +1,3 @@
-Metadata-Version: 2.4
-Name: ayder-cli
-Version: 1.8.3
-Summary: AI agent for any LLMs
-Project-URL: Homepage, https://github.com/ayder/ayder-cli
-Project-URL: Repository, https://github.com/ayder/ayder-cli.git
-Project-URL: Issues, https://github.com/ayder/ayder-cli/issues
-Author-email: Sinan Alyuruk <sinan.alyuruk@gmail.com>
-License: MIT
-License-File: LICENSE
-Keywords: agent,ai,ayder,cli,llm,tui
-Classifier: Environment :: Console
-Classifier: Intended Audience :: Developers
-Classifier: License :: OSI Approved :: MIT License
-Classifier: Programming Language :: Python :: 3
-Requires-Python: >=3.12
-Requires-Dist: anthropic
-Requires-Dist: google-genai
-Requires-Dist: httpx
-Requires-Dist: libcst>=1.0.0
-Requires-Dist: loguru
-Requires-Dist: ollama>=0.6.2
-Requires-Dist: openai
-Requires-Dist: python-dotenv>=1.0.0
-Requires-Dist: rich>=13.0.0
-Requires-Dist: textual<9.0.0,>=1.0.0
-Requires-Dist: tiktoken>=0.7.0
-Description-Content-Type: text/markdown
-
 # ayder-cli
 
 A multi-provider AI agent chat client for your terminal. ayder supports Ollama, Anthropic Claude, OpenAI, Gemini,
@@ -34,6 +5,12 @@ or any OpenAI-compatible API and provides an autonomous coding assistant with fi
 
 ![ayder](docs/cc.png)
 
+## What's New in 2.0
+
+Provider 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).
+
+> **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.
+
 ## Supported LLM providers
 
 - [Ollama](https://ollama.com) (local or cloud)
@@ -54,7 +31,7 @@ Most AI coding assistants require cloud APIs, subscriptions, or heavy IDE plugin
 - **Agentic workflow** -- the LLM reads files, edits code, runs shell commands, and iterates autonomously with configurable iteration limits per message.
 - **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.
 - **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.
-- **Batteries included** -- the OpenAI, Anthropic, Google, and Ollama SDKs all ship with ayder-cli, so every provider works out of the box. The terminal UI is built on Rich and Textual.
+- **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.
 
 ### Tools
 
@@ -70,17 +47,29 @@ Each tool has an OpenAI-compatible JSON schema so models that support function c
 ## Installation
 
 Requires Python 3.12+.
-Works best with uv tool. If you don't have uv in your path, get it from
- [Astral uv](https://docs.astral.sh/uv/#highlights)
+Works best with uv. If you don't have uv in your path, get it from
+[Astral uv](https://docs.astral.sh/uv/#highlights).
+
+Core install (OpenAI + Ollama, plus DeepSeek which reuses the OpenAI SDK):
+
+    pip install ayder-cli
+
+Optional providers (install only what you use):
+
+    pip install ayder-cli[anthropic]   # Claude
+    pip install ayder-cli[google]      # Gemini
+    pip install ayder-cli[qwen]        # Qwen (dashscope)
+    pip install ayder-cli[glm]         # GLM (zhipuai)
+    pip install ayder-cli[all]         # everything
+
+If you select a driver whose package isn't installed, ayder prints the exact
+install command and lists the drivers available in your install.
 
 ```bash
-# Install to user environment
+# Install to user environment (uv tool)
 uv tool install ayder-cli
 
-# or install from PyPI
-pip install ayder-cli
-
-# For nightly builds:
+# Or for nightly / development builds:
 git clone https://github.com/ayder/ayder-cli.git
 cd ayder-cli
 
@@ -106,16 +95,19 @@ export OLLAMA_FLASH_ATTENTION=true
 export OLLAMA_MAX_LOADED_MODELS=1
 ```
 
-### Cloud providers (Anthropic, OpenAI, Gemini)
+### Cloud providers
 
-The Anthropic, OpenAI, and Google SDKs ship with ayder-cli — no extra installs.
-Just add an API key to a profile in `~/.ayder/config.toml` (see Configuration
+Add an API key to a profile in `~/.ayder/config.toml` (see Configuration
 below) and switch provider in the TUI:
 
 ```bash
-/provider anthropic   # or: openai, gemini
+/provider anthropic   # or: openai, google, deepseek, qwen, glm
 ```
 
+Note: `anthropic` and `google` require the corresponding optional extra
+(see Installation above). `openai`, `ollama`, and `deepseek` are included
+in the core install.
+
 ### Configuration: Profiles and Drivers
 
 ayder-cli uses a flexible profile-based configuration system. On the first run, it creates a config file at `~/.ayder/config.toml`.

ayder_cli-2.1.1/docs/README_AGENT_WORKFLOW.md

@@ -0,0 +1,132 @@
+## Domain
+Driving the multi-agent software-delivery harness defined in `config.toml.example`:
+a 9-role pipeline (spec → review → plan → review → task-split → task-review →
+build → QA → review → gate). After the plan is approved, the **architect** splits
+it into task files in `.ayder/tasks/` (the same format `/plan` produces) and
+**architect_review** checks the task set, so the user can follow the queue with
+`/tasks`; parallel builders are isolated by git branches and the gate agent
+collects and merges. This skill tells YOU — the main orchestrator LLM — how to run it.
+
+## Trigger
+A non-trivial software task ("build / implement / add feature X") where the
+configured agents (`pm_spec`, `pm_review`, `architect`, `architect_review`,
+`senior_coder`, `qa_engineer`, `junior_coder`, `code_reviewer`, `acceptance_gate`)
+are available. For tiny one-file edits, just do it yourself — don't spin up the harness.
+
+## Guidelines
+
+You are the **orchestrator**. You do not write the feature yourself — you dispatch
+specialist agents, pass each one the right context, and move work through the
+pipeline. Keep your own messages short; let the agents do the heavy lifting.
+
+### How to talk to an agent
+- `call_agent("<name>", task=…, task_id=…, branch_name=…)` → returns a **run id**
+  immediately. It does not block. Only `name` is required.
+- Dispatch independent tasks together (several `call_agent` calls), then poll
+  `agent_status()` to see what is `working` vs `done`.
+- Collect a finished one with `read_agent_result(<run_id>)`, or wait for a slow one
+  with `read_agent_result(<run_id>, wait=true, timeout_s=…)`.
+- Each agent only sees the prompt you give it. **For task-file work, pass
+  `task_id="TASK-NNN"` and `branch_name="agent/<slug>"`** — the harness resolves the
+  id, **fails fast** if it doesn't exist, and embeds the task file itself in the
+  agent's prompt. Do **not** read the task file and paste its body into `task`; use
+  `task` only for extra steering (or as the whole instruction when there's no file).
+- **Don't write notes or summaries yourself.** Every agent auto-saves its full
+  deliverable to `.ayder/notes/`; collect it with `read_agent_result` (or `read_file`
+  its `note_path`). Re-summarizing an agent's output into your own note is wasted work.
+- **Give pointers, not pasted content.** Agents share the working tree and have
+  shell/read/search tools — they run their own `git diff` and read their own files.
+  Hand a reviewer/QA/gate agent the branch, the base ref, the task id(s), and the
+  paths; do **not** read source or diffs and paste them into `task`. Pasting wastes
+  your context and is exactly what makes a review/QA dispatch stall.
+- **Never dispatch an empty task.** Every `call_agent` must carry a concrete
+  instruction — a non-empty `task` and/or a `task_id` that resolves to a task file.
+  If neither carries real content, you are not ready to dispatch — fix that first.
+
+### The pipeline (run in order)
+
+1. **Branch off.** Create one integration branch for the feature:
+   `git switch -c feat/<slug>`. All harness work happens off this branch; `main`
+   is only touched by the final merge.
+2. **Spec.** `pm_spec` writes the spec + acceptance criteria → `pm_review` checks it.
+   Loop until `pm_review` returns `VERDICT: APPROVED`.
+3. **Plan.** `architect` turns the approved spec into a development plan →
+   `architect_review` checks it. Loop until `VERDICT: APPROVED`. The plan marks
+   which tasks are **parallel** and which are small/low-risk.
+4. **Task split (delegate it — don't split the work yourself).** Ask the
+   `architect` to break the **approved plan** into task files in `.ayder/tasks/`,
+   one file per task, exactly like `/plan`. Hand it this format to `write_file`:
+   - Name each file `.ayder/tasks/TASK-<NNN>-<slug>.md` (zero-padded NNN;
+     `list_tasks` first, then increment past the highest existing number).
+   - Begin every file with this exact header, then the task in PRD form with its
+     acceptance criteria, the files it touches, and its `agent/<slug>` branch:
+     ```
+     ## Signature
+     - **ID:** TASK-<NNN>
+     - **Status:** pending
+     - **Created:** <YYYY-MM-DD HH:MM:SS>
+     ```
+5. **Task review.** `architect_review` checks the **whole task set against the
+   approved plan**: full coverage (every plan item maps to a task), no scope
+   creep, correct sizing/sequencing, consistent interfaces across tasks. Loop
+   split↔review until `VERDICT: APPROVED`. The user can now follow the queue with
+   `/tasks` (○ pending · ◐ in_progress · ✓ done).
+6. **Delegate (isolated — see git rules below).** Work the queue task by task:
+   - Flip the task's `**Status:**` to `in_progress`, then dispatch it with
+     `call_agent("senior_coder", task_id="TASK-NNN", branch_name="agent/<slug>")`
+     (small, low-risk tasks → the single `junior_coder`, one at a time). The harness
+     hands the agent the task file and the branch directive — you don't paste the
+     task body. Each agent commits only to its own branch.
+   - When you collect and accept the result, flip the task's `**Status:**` to `done`.
+   Update a status by rewriting the task file's `**Status:**` line (read it with
+   `show_task`, write it back with `write_file`). This keeps `/tasks` accurate so
+   the user always sees what is queued, in flight, and finished.
+7. **QA.** `qa_engineer` writes and runs the test suite, reports real pass/fail output.
+   Give it the branch + task ids; it reads the code and runs the tests itself.
+8. **Review.** Tell `code_reviewer` WHERE, not the diff — the branch, the base ref, and
+   the task ids (e.g. "review `feat/x` vs `main` for TASK-003..007; run `git diff` yourself").
+   It gathers the diff and reads the files from the working tree. Send `CHANGES REQUIRED`
+   findings back to the coder, then re-review.
+9. **Gate + merge.** `acceptance_gate` collects the approved branches, merges them
+   into `feat/<slug>`, resolves conflicts, runs the full suite, and checks every
+   acceptance criterion. `GATE: PASS` → merge `feat/<slug>` into `main`.
+   `GATE: FAIL` → send the failing criteria back to the relevant stage.
+
+### Git rules — so agents don't step on each other
+
+The agents share one working directory, so two builders editing at once will
+collide. Isolate them with git:
+
+- **One branch per task.** Name them `agent/<task-slug>`, branched off `feat/<slug>`.
+- **For true parallel builds, give each builder its own worktree** (a separate
+  folder) so their files never touch:
+  ```bash
+  git worktree add .ayder/worktrees/<task-slug> -b agent/<task-slug> feat/<slug>
+  ```
+  Tell the builder to work in that folder. If you'd rather keep it simple, skip
+  worktrees and run the builders **one at a time** on their branches instead.
+- **Builders commit only to their own branch.** They never touch `main`, `feat/<slug>`,
+  or another agent's branch.
+- **Only the gate merges.** It integrates branches in dependency order:
+  ```bash
+  git switch feat/<slug>
+  git merge --no-ff agent/<task-slug>     # repeat per approved branch; resolve conflicts
+  # run the full suite + acceptance checks, then:
+  git switch main && git merge --no-ff feat/<slug>
+  git worktree remove .ayder/worktrees/<task-slug>   # clean up
+  ```
+
+### Simple rules to keep it on the rails
+- Don't skip a review gate. `pm_review`, `architect_review`, and `code_reviewer`
+  exist to catch problems early — loop until each approves.
+- Keep `junior_coder` to **one instance at a time** (local memory limit). Don't fan it out.
+- Keep task statuses current: `pending` → `in_progress` (on dispatch) → `done`
+  (on accepted result), so `/tasks` always reflects reality for the user.
+- Never call an agent with an empty task string — no concrete task, no dispatch.
+- A reviewer is always a different model family than the author it checks — trust
+  that independent second opinion; don't override it without a reason.
+- If an agent fails or times out, handle that task yourself or hand it to a
+  `senior_coder` — don't re-dispatch the same failed agent in a loop.
+- Tell the user the verdict at each gate; don't merge to `main` until `GATE: PASS`.
+
+See `config.toml.example` for which model backs each role and why.