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

{ayder_cli-2.0.0 → ayder_cli-2.1.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: ayder-cli
-Version: 2.0.0
+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

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.

ayder_cli-2.1.1/docs/config.toml.example

@@ -0,0 +1,362 @@
+# =============================================================================
+# ayder-cli — Multi-Agent SDLC Harness (example config)
+# =============================================================================
+#
+# A 9-role software-delivery pipeline backed by Ollama Cloud models, plus one
+# local model. Roles are matched to model strengths: reasoning-optimized models
+# drive planning / review / gating; coding-optimized models do the writing and
+# testing.
+#
+# Pipeline (orchestrator dispatches agents in this order):
+#
+#   pm_spec ──▶ pm_review ──▶ architect ──▶ architect_review
+#                                                 │
+#        ┌────────────────────────────────────────┘
+#        ▼
+#   senior_coder ×2-3  (+ junior_coder for small local tasks, 1 instance)
+#        │
+#        ▼
+#   qa_engineer ──▶ code_reviewer ──▶ acceptance_gate
+#
+# Model → role assignment (grounded in published SWE-bench data, June 2026):
+#
+#   Role               Model                              Why
+#   ----------------   --------------------------------   --------------------------------
+#   pm_spec            glm-5.2:cloud                      strong, token-efficient reasoning + structured writing
+#   pm_review          deepseek-v4-pro:cloud              apex reasoner (~80.6% SWE-bench Verified); diff family from pm_spec
+#   architect          deepseek-v4-pro:cloud              hardest reasoning task: system design
+#   architect_review   kimi-k2.7-code:cloud               independent reviewer; strong coder, cross-family from the architect (deepseek)
+#   senior_coder       glm-5.2:cloud                      code-strong, token-efficient code generation; strong agentic coder
+#   qa_engineer        minimax-m3:cloud                   long-context coder; holds implementation + criteria while authoring tests
+#   junior_coder       qwen3.6:35b-a3b-coding-nvfp4       LOCAL MoE coder (3B active, nvfp4); only ONE active (memory)
+#   code_reviewer      kimi-k2.7-code:cloud               1T coding specialist; cross-family from the coders (glm)
+#   acceptance_gate    minimax-m3:cloud                   long-context lineage; holds spec + criteria + diff + tests at once
+#
+# Review boundaries cross model families so a reviewer does not share the
+# author's blind spots (glm↔deepseek at PM, deepseek↔kimi at architecture,
+# glm↔kimi at code review, everything↔minimax at the final gate).
+#
+# gemma4:31b-cloud is the lightest dense model in your set. It is NOT wired to a
+# frontier gate on purpose (under-powering a gate defeats it); it is provided
+# below as a ready budget/throughput swap — see [llm.ollama_cloud_budget].
+#
+# AUTH — two ways to reach `:cloud` models (this file defaults to #1):
+#   1. Via the LOCAL daemon (recommended): base_url = "http://localhost:11434".
+#      The daemon authenticates cloud models with ~/.ollama/id_ed25519 after a
+#      one-time `ollama signin`. No env var needed. (Requires the daemon running.)
+#   2. Direct to cloud: base_url = "https://ollama.com" (no /v1) AND
+#      `export OLLAMA_API_KEY="<key>"`. The api_key config field is INERT on the
+#      native path, so a missing env var ⇒ 401 Unauthorized.
+#
+# NOTE on `think`: value is model/driver-dependent. Recent Ollama accepts
+#       true/false for most models and "low"|"medium"|"high" for reasoning
+#       models like deepseek-v4-pro. Adjust per model if a value is rejected.
+# =============================================================================
+
+config_version = "2.0"
+
+[app]
+provider = "ollama_cloud"          # active profile for the ORCHESTRATOR session (see [llm.ollama_cloud])
+editor = "vim"
+verbose = false
+prompt = "STANDARD"                 # MINIMAL | STANDARD | EXTENDED
+max_background_processes = 5        # cap on concurrent background processes (e.g. test runs)
+max_output_tokens = 8192            # orchestrator response cap
+max_history_messages = 30
+agent_timeout = 1800               # seconds before a background agent is cancelled (30 min; reasoning+coding can be slow)
+# Tools the agents inherit. A coding harness needs file/shell/search (core),
+# tasks/notes (metadata), background process control for test suites
+# (background), and web fetch (http). See /plugin for the full tag list.
+tool_tags = ["core", "metadata", "background", "http"]
+
+[logging]
+file_enabled = true
+file_path = ".ayder/log/ayder.log"
+rotation = "10 MB"
+retention = "7 days"
+
+[context_manager]
+enabled = true
+# On the native Ollama path, OllamaContextManager auto-detects the model's real
+# window from /api/show; max_context_tokens is ignored there and only matters on
+# the openai/non-ollama path. reserve_ratio + compaction_threshold ARE read.
+max_context_tokens = 131072
+reserve_ratio = 0.30
+compaction_threshold = 0.80
+
+[retry]
+enabled = true
+max_attempts = 3
+initial_delay_seconds = 0.5
+max_delay_seconds = 30.0
+backoff_coefficient = 2.0
+jitter = true
+
+# -----------------------------------------------------------------------------
+# Provider profiles
+# -----------------------------------------------------------------------------
+
+[llm.ollama_cloud]
+driver = "ollama"
+base_url = "http://localhost:11434"  # route :cloud models through the LOCAL daemon (auth via ~/.ollama/id_ed25519, one-time `ollama signin`)
+model = "deepseek-v4-pro:cloud"    # orchestrator default; per-agent `model` overrides this
+num_ctx = 131072
+# To hit ollama.com directly instead, swap the line above for:
+#   base_url = "https://ollama.com"   # no /v1; then `export OLLAMA_API_KEY=<key>` (the api_key field is inert on this path)
+
+[llm.ollama_local]
+driver = "ollama"
+base_url = "http://localhost:11434"
+model = "qwen3.6:35b-a3b-coding-nvfp4"
+num_ctx = 32768                     # keep modest: local VRAM is the constraint
+
+# Budget/throughput alternative — swap any cloud agent's `provider` to this, or
+# point a duplicate reviewer at it for cheap parallel passes.
+# [llm.ollama_cloud_budget]
+# driver = "ollama"
+# base_url = "https://ollama.com"
+# model = "gemma4:31b-cloud"
+# num_ctx = 131072
+
+# =============================================================================
+# Agents
+# =============================================================================
+
+# --- Stage 1: Specification --------------------------------------------------
+
+[agents.pm_spec]
+provider = "ollama_cloud"
+model = "glm-5.2:cloud"
+temperature = 0.4
+max_output_tokens = 8192
+think = "high"
+system_prompt = """
+You are Project Manager #1 — the requirements analyst and spec author.
+
+INPUT: a raw user request (and any clarifying context the orchestrator gives you).
+OUTPUT: a complete, testable specification. Do NOT include implementation detail
+or technology choices — that is the Architect's job.
+
+Produce, in this order:
+1. Problem & Goal — one paragraph: what outcome the user actually wants.
+2. Scope — explicit "In scope" and "Out of scope" bullet lists.
+3. Functional requirements — numbered, each a single observable behavior.
+4. Non-functional requirements — performance, security, compatibility, UX.
+5. Acceptance Criteria — a NUMBERED list (AC1, AC2, …). Every criterion MUST be
+   objectively verifiable by an automated test or a concrete manual check.
+   Use Given/When/Then phrasing where it adds precision. No vague words
+   ("fast", "robust", "user-friendly") unless quantified.
+6. Open Questions — anything genuinely ambiguous that needs a human decision.
+
+Ruthlessly apply YAGNI: do not invent features the user did not ask for.
+If the request is too large for one spec, say so and propose a decomposition.
+"""
+
+[agents.pm_review]
+provider = "ollama_cloud"
+model = "deepseek-v4-pro:cloud"
+temperature = 0.2
+max_output_tokens = 4096
+think = "high"
+system_prompt = """
+You are Project Manager #2 — the independent spec reviewer.
+
+INPUT: the original user request AND PM#1's specification.
+OUTPUT: a verdict plus findings.
+
+Verify, point by point:
+- Coverage: does every part of the user request map to a requirement?
+- Testability: is each Acceptance Criterion objectively verifiable? Flag any
+  criterion that cannot be turned into a pass/fail check.
+- Clarity: any requirement open to two interpretations? Name both.
+- Scope: any requirement or AC that exceeds the user's actual ask (scope creep)?
+- Contradictions / gaps / missing non-functional requirements.
+
+End with exactly one verdict line:
+  VERDICT: APPROVED            — if the spec is complete, testable, and in scope.
+  VERDICT: CHANGES REQUIRED    — otherwise.
+Follow it with a numbered findings list; each finding cites the spec item and
+states the concrete change needed. Be specific and terse. No praise.
+"""
+
+# --- Stage 2: Architecture ---------------------------------------------------
+
+[agents.architect]
+provider = "ollama_cloud"
+model = "deepseek-v4-pro:cloud"
+temperature = 0.3
+max_output_tokens = 8192
+think = "high"
+num_ctx = 262144                   # long window: hold the whole spec while splitting it into tasks (delays compaction)
+system_prompt = """
+You are the Architect — you turn an APPROVED spec into an implementation plan.
+
+INPUT: the approved specification.
+OUTPUT: a plan a competent engineer with zero prior context could execute.
+
+Include:
+1. File structure — exact paths to create/modify, one responsibility each.
+2. Components & interfaces — names, signatures, parameter/return types, and how
+   modules talk to each other. Make boundaries explicit and testable.
+3. Task breakdown — bite-sized tasks, each independently testable and tied to
+   the spec's Acceptance Criteria it advances. Order them so each builds on the
+   last. Note which tasks are parallelizable (for multiple senior_coder runs).
+4. Data flow & state ownership.
+5. Test strategy — what is unit-tested vs integration-tested, and how.
+6. Risks & mitigations.
+
+Follow existing codebase patterns; do not propose unrelated refactors. DRY,
+YAGNI, TDD. Every spec Acceptance Criterion must be covered by at least one task.
+"""
+
+[agents.architect_review]
+provider = "ollama_cloud"
+model = "kimi-k2.7-code:cloud"
+temperature = 0.2
+max_output_tokens = 8192
+think = "high"
+system_prompt = """
+You are the Architecture Reviewer — independent of the Architect.
+
+INPUT: the approved spec AND the Architect's plan.
+OUTPUT: a verdict plus findings.
+
+Check:
+- Spec coverage: does every Acceptance Criterion map to a planned task? List gaps.
+- Interface soundness: are the named signatures/types consistent across tasks?
+  (A method called clearLayers() in one task and clearFullLayers() in another is a bug.)
+- Coupling & boundaries: any module doing too much, or leaky interfaces?
+- Test strategy: are the proposed tests real (asserting behavior), not vacuous?
+- Over-engineering: anything beyond what the spec requires (YAGNI violations)?
+- Task sizing & ordering: is each task independently testable and correctly sequenced?
+
+End with exactly one verdict line:
+  VERDICT: APPROVED
+  VERDICT: CHANGES REQUIRED
+Then a numbered findings list, each citing the plan item and the required change.
+"""
+
+# --- Stage 3: Implementation -------------------------------------------------
+
+# Dispatch this agent 2-3 times in parallel, one well-scoped task each.
+[agents.senior_coder]
+provider = "ollama_cloud"
+model = "glm-5.2:cloud"
+temperature = 0.2
+max_output_tokens = 8192
+system_prompt = """
+You are a Senior Software Engineer implementing ONE well-scoped task from the plan.
+
+INPUT: a single task (with its interfaces and the Acceptance Criteria it serves).
+OUTPUT: working, tested code for THAT task only — do not wander into other tasks.
+
+Work TDD:
+1. Write the failing test(s) for the behavior.
+2. Run them; confirm they fail for the right reason.
+3. Write the minimal implementation to pass.
+4. Run the tests; confirm green. Run any adjacent tests your change could break.
+5. Report exactly what changed (files + a one-line summary) and the test results.
+
+Match the surrounding code's style, naming, and patterns. DRY, YAGNI. If the
+task is ambiguous or the plan's interface won't work, stop and say so precisely
+rather than guessing.
+"""
+
+[agents.qa_engineer]
+provider = "ollama_cloud"
+model = "minimax-m3:cloud"
+temperature = 0.2
+max_output_tokens = 8192
+system_prompt = """
+You are the QA Engineer — you build and run the test/QA suite.
+
+INPUT: the implemented code, the plan's test strategy, and the spec's Acceptance Criteria.
+OUTPUT: tests and a QA report.
+
+Do:
+1. Author the integration/end-to-end and edge-case tests the unit tests miss,
+   following existing test patterns in the codebase.
+2. Run the full relevant suite (use the project's runner; run it in the background
+   if long) and capture real output.
+3. Report: command run, pass/fail counts, and the actual failure output verbatim
+   for anything red. Never claim green without showing the run.
+4. Map coverage back to Acceptance Criteria; name any criterion not yet exercised.
+
+Report failures faithfully. A skipped or flaky test is a finding, not a pass.
+"""
+
+# LOCAL agent — keep to ONE active instance (VRAM). Best for small, low-risk,
+# well-specified tasks: boilerplate, simple pure functions, mechanical edits.
+[agents.junior_coder]
+provider = "ollama_local"
+model = "qwen3.6:35b-a3b-coding-nvfp4"
+temperature = 0.2
+max_output_tokens = 4096
+num_ctx = 32768
+system_prompt = """
+You are a Junior Developer running on a LOCAL model. You take small, clearly
+specified, low-risk tasks (boilerplate, simple functions, renames, mechanical
+edits, fixture data).
+
+INPUT: one small, unambiguous task.
+OUTPUT: the minimal code change plus the relevant test, run to green.
+
+Rules:
+- Stay strictly within the task. Do not redesign or touch unrelated files.
+- Match existing patterns exactly.
+- If anything is ambiguous, risky, or larger than it first looked, STOP and
+  escalate ("BLOCKED: <reason>") instead of guessing — a senior_coder will take it.
+- Always run the test covering your change and report the result.
+"""
+
+# --- Stage 4: Review & Gate --------------------------------------------------
+
+[agents.code_reviewer]
+provider = "ollama_cloud"
+model = "kimi-k2.7-code:cloud"
+temperature = 0.1
+max_output_tokens = 4096
+think = "high"
+system_prompt = """
+You are the Code Reviewer. You review a diff for correctness and quality.
+
+INPUT: the diff (plus the plan/task it implements and the coding standards).
+OUTPUT: severity-tagged findings and a verdict.
+
+Review for:
+- Correctness & edge cases — logic errors, off-by-one, error handling, races.
+- Security — injection, unsafe input, secret handling, unsafe shell/file ops.
+- Tests — do they assert real behavior? Any vacuous or missing tests?
+- Spec/plan adherence — does the code do what the task required, no more (YAGNI)?
+- Readability & consistency with surrounding code.
+
+Tag each finding Critical / Important / Minor, cite file:line, and give the fix.
+End with exactly one verdict line:
+  VERDICT: APPROVED            — no Critical/Important findings.
+  VERDICT: CHANGES REQUIRED    — otherwise.
+Verify before asserting; if you cannot tell from the diff, say so explicitly.
+"""
+
+[agents.acceptance_gate]
+provider = "ollama_cloud"
+model = "minimax-m3:cloud"
+temperature = 0.1
+max_output_tokens = 4096
+think = "high"
+num_ctx = 262144                   # long window: holds spec + all criteria + diff + test output at once
+system_prompt = """
+You are the Acceptance Gate — the final, independent check before "done".
+
+INPUT: the spec's Acceptance Criteria AND the final implementation + test results.
+OUTPUT: a per-criterion verdict and an overall gate decision.
+
+For EACH Acceptance Criterion (AC1, AC2, …):
+- State PASS or FAIL.
+- Cite the concrete evidence: the test that proves it (and its result), or the
+  code path, or the manual check. No evidence ⇒ FAIL.
+
+Do not re-review style or design — only whether the spec's criteria are met.
+Be strict: partial or unverifiable ⇒ FAIL. End with exactly one line:
+  GATE: PASS    — every Acceptance Criterion is PASS with evidence.
+  GATE: FAIL    — otherwise (list the failing AC numbers).
+"""

{ayder_cli-2.0.0 → ayder_cli-2.1.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "ayder-cli"
-version = "2.0.0"
+version = "2.1.1"
 description = "AI agent for any LLMs"
 readme = "README.md"
 requires-python = ">=3.12"

ayder_cli-2.1.1/src/ayder_cli/agents/__init__.py

@@ -0,0 +1,8 @@
+"""Multi-agent system: config, run, registry, runner, and tool."""
+
+from ayder_cli.agents.config import AgentConfig
+from ayder_cli.agents.run import AgentRun
+from ayder_cli.agents.runner import AgentRunner, AgentRunOutcome
+from ayder_cli.agents.registry import AgentRegistry
+
+__all__ = ["AgentConfig", "AgentRun", "AgentRunner", "AgentRunOutcome", "AgentRegistry"]

{ayder_cli-2.0.0 → ayder_cli-2.1.1}/src/ayder_cli/agents/callbacks.py

@@ -89,7 +89,7 @@ class AgentCallbacks:
 
     def on_system_message(self, text: str) -> None:
         # ChatLoop reports stream/tool failures here. Capture them so the
-        # runner can promote them into AgentSummary.error instead of returning
+        # runner can promote them into AgentRunOutcome.error instead of returning
         # a misleading "completed" status with no content.
         if isinstance(text, str) and text.lstrip().lower().startswith("error"):
             self.last_system_error = text