docs(milestone): split advanced-concepts and tui docs into sub-documents

Split docs/advanced-concepts.md (554 lines) into four sub-documents under docs/advanced-concepts/ and docs/tui.md (634 lines) into four sub-documents under docs/tui/, each under the 500-line limit per CONTRIBUTING.md. Advanced Concepts sub-documents: - docs/advanced-concepts/index.md: Overview, context strategies, LLM backends - docs/advanced-concepts/resource-types.md: Resource types, A2A rename - docs/advanced-concepts/container-tools.md: Container tools, scope chain, budgets, safety - docs/advanced-concepts/e2e-tests-and-plugins.md: E2E tests, code review, plugins TUI sub-documents: - docs/tui/index.md: Overview, getting started, main screen layout - docs/tui/sidebar-and-personas.md: Sidebar states, persona system - docs/tui/input-and-sessions.md: Reference/command input, session management - docs/tui/configuration-and-integration.md: Config, key bindings, theme, integration Updated mkdocs.yml navigation to reflect new sub-document structure. Updated CONTRIBUTORS.md with contribution entry for PR #9903. ISSUES CLOSED: #10533
2026-04-25 00:26:18 +00:00
parent e8548ceae2
commit dde71cf8e2
10 changed files with 1316 additions and 3 deletions
@@ -0,0 +1,248 @@
+# Advanced Concepts: Container Tools, Scope Chain, Budgets & Safety (v3.6.0)
+
+> **Milestone:** v3.6.0 — M7: Advanced Concepts & Deferred Features
+> **Parent:** [Advanced Concepts Overview](index.md)
+
+---
+
+## Container Tool Execution
+
+v3.6.0 adds first-class support for executing tools inside containers, building on the
+container resource types introduced in ADR-039.
+
+### Overview
+
+Container tool execution allows actors to run tools in isolated container environments rather
+than directly on the host. This provides:
+
+- **Stronger isolation** — tool side effects are contained within the container
+- **Reproducible environments** — tools run in a known, versioned environment
+- **Language-agnostic tools** — tools can be written in any language supported by the container
+- **Parallel execution** — multiple containers can run simultaneously for independent tool calls
+
+### Container Tool Configuration
+
+Tools declare their container requirements in their YAML definition:
+
+```yaml
+name: my-org/python-linter
+type: container-tool
+image: "python:3.12-slim"
+command: ["python", "-m", "pylint"]
+mounts:
+  - source: "{{resource.git_dir.path}}"
+    target: "/workspace"
+    readonly: true
+environment:
+  PYTHONPATH: "/workspace/src"
+timeout: 60
+```
+
+### Execution Model
+
+Container tools follow the same `ToolRuntime` interface as host tools. The
+`ContainerToolExecutor` handles:
+
+1. **Image resolution** — pulls the image if not cached locally
+2. **Mount binding** — maps resource paths to container mount points
+3. **Execution** — runs the container with the specified command and arguments
+4. **Output capture** — streams stdout/stderr back to the `ToolResult`
+5. **Cleanup** — removes the container after execution (configurable)
+
+### Devcontainer Integration
+
+When a project has a `.devcontainer/devcontainer.json`, CleverAgents can use the devcontainer
+as the execution environment for all tools in that project. This is configured via the
+`devcontainer-instance` resource type (ADR-043):
+
+```yaml
+resources:
+  - name: dev_env
+    type: devcontainer-instance
+    devcontainer_path: ".devcontainer/devcontainer.json"
+    use_for_tools: true
+```
+
+---
+
+## Pluggable Scope Chain Resolution Extensions
+
+The scope chain resolution system determines which projects, plans, and resources are in scope
+for a given actor invocation. v3.6.0 makes this system extensible via a plugin interface.
+
+### Scope Chain Resolution Protocol
+
+The `ScopeChainResolver` interface defines a single method:
+
+```python
+class ScopeChainResolver(Protocol):
+    def resolve(
+        self,
+        base_scope: Scope,
+        context: ResolutionContext,
+    ) -> Scope:
+        """
+        Extend or modify the base scope based on the resolution context.
+
+        Args:
+            base_scope: The scope as determined by the persona and explicit @ references.
+            context: The current resolution context (session, plan, actor, prompt).
+
+        Returns:
+            The resolved scope, which may add, remove, or reorder items from base_scope.
+        """
+        ...
+```
+
+### Built-in Resolvers
+
+| Resolver | Description |
+|----------|-------------|
+| `PersonaScopeResolver` | Adds persona-scoped projects and plans (always active) |
+| `ReferenceResolver` | Adds explicitly `@`-referenced resources (always active) |
+| `DependencyGraphResolver` | Automatically includes resources that are dependencies of in-scope resources |
+| `RecentlyModifiedResolver` | Adds recently modified files from in-scope projects |
+| `TestCoverageResolver` | Adds test files that cover in-scope source files |
+
+### Custom Resolver Registration
+
+Custom resolvers are registered via the plugin system:
+
+```python
+from cleveragents.scope import ScopeChainResolver, register_resolver
+
+@register_resolver(name="my-org/git-blame-resolver", priority=50)
+class GitBlameResolver:
+    def resolve(self, base_scope, context):
+        # Add files recently modified by the current git user
+        ...
+```
+
+---
+
+## Cost and Session Budgets
+
+v3.6.0 introduces comprehensive cost tracking and budget enforcement across sessions and plans.
+
+### Cost Tracking
+
+Every LLM invocation is tracked with:
+
+- **Input tokens** and **output tokens** (provider-reported)
+- **Cost in USD** (computed from provider pricing tables, updated monthly)
+- **Model used** (for multi-provider fallback chains)
+- **Session ID** and **plan ID** for attribution
+
+Cost data is stored in the SQLite database and queryable via:
+
+```bash
+agents session cost                    # Total cost for current session
+agents session cost --all              # All sessions with costs
+agents plan cost <plan-id>             # Cost breakdown for a specific plan
+agents config get billing.total_spent  # Lifetime total
+```
+
+### Budget Configuration
+
+Budgets are configured at multiple levels (plan > action > project > global):
+
+```toml
+[billing]
+max_cost_per_session = 5.00     # USD; hard limit per session
+max_cost_per_plan = 2.00        # USD; hard limit per plan
+max_total_cost = 100.00         # USD; lifetime hard limit
+warn_at_percent = 80            # Warn when 80% of any budget is consumed
+```
+
+These settings correspond to the `SafetyProfile` fields defined in ADR-041:
+
+| Config Key | SafetyProfile Field |
+|-----------|-------------------|
+| `max_cost_per_plan` | `SafetyProfile.max_cost_per_plan` |
+| `max_total_cost` | `SafetyProfile.max_total_cost` |
+
+### Budget Enforcement
+
+When a budget limit is reached:
+
+1. The current LLM invocation is **not** started (pre-flight check)
+2. A `BudgetExceededError` is raised with the budget type, limit, and current spend
+3. The plan transitions to `PAUSED` state with `pause_reason = "budget_exceeded"`
+4. The user is notified via the CLI output or TUI notification system
+5. The user can increase the budget via `agents config set billing.max_cost_per_plan <new_limit>`
+   and resume the plan with `agents plan resume <plan-id>`
+
+---
+
+## Safety Profiles
+
+Safety profiles (ADR-041) provide fine-grained control over what actions an actor is permitted
+to take. v3.6.0 completes the safety profile implementation with full enforcement in the plan
+lifecycle.
+
+### SafetyProfile Fields
+
+| Field | Type | Default | Description |
+|-------|------|---------|-------------|
+| `require_sandbox` | `bool` | `True` | Require sandbox isolation for all file writes |
+| `require_checkpoints` | `bool` | `True` | Require checkpoints before destructive operations |
+| `allow_unsafe_tools` | `bool` | `False` | Allow tools marked as `unsafe: true` |
+| `require_human_approval` | `bool` | `False` | Require human approval before each action step |
+| `allowed_skill_categories` | `list[str]` | `[]` (all) | Restrict to specific skill categories |
+| `max_cost_per_plan` | `float or None` | `None` | Maximum cost per plan in USD |
+| `max_total_cost` | `float or None` | `None` | Maximum lifetime cost in USD |
+| `max_retries_per_step` | `int` | `3` | Maximum retries per action step (0-100) |
+
+### Built-in Safety Profiles
+
+v3.6.0 ships with named safety profiles that can be referenced by name:
+
+| Profile | Description |
+|---------|-------------|
+| `strict` | All safety flags enabled; no unsafe tools; human approval required |
+| `standard` | Sandbox and checkpoints required; unsafe tools blocked; no human approval |
+| `permissive` | Sandbox required; checkpoints optional; unsafe tools allowed |
+| `read-only` | No file writes permitted; all tools restricted to read operations |
+| `cost-capped-1usd` | Standard safety + $1.00 per-plan cost cap |
+| `cost-capped-5usd` | Standard safety + $5.00 per-plan cost cap |
+
+### Applying Safety Profiles
+
+Safety profiles can be applied at multiple levels:
+
+```bash
+# Global default
+agents config set safety.profile strict
+
+# Per-project
+agents project set-safety my-project --profile standard
+
+# Per-plan (at creation time)
+agents plan use my-action --safety-profile permissive
+```
+
+```yaml
+# action.yaml
+name: my-action
+safety_profile:
+  require_sandbox: true
+  allow_unsafe_tools: false
+  max_cost_per_plan: 2.00
+```
+
+---
+
+## Related ADRs
+
+| ADR | Title | Relevance |
+|-----|-------|-----------|
+| [ADR-039](../adr/ADR-039-container-resource-types.md) | Container Resource Types | Container tool execution |
+| [ADR-041](../adr/ADR-041-safety-profile-extraction.md) | Safety Profile Extraction | Safety profiles and cost budgets |
+| [ADR-043](../adr/ADR-043-devcontainer-integration.md) | Devcontainer Integration | Devcontainer tool execution |
+
+---
+
+*Documentation for v3.6.0 — IN PROGRESS. Features described here reflect the planned scope
+as of 2026-04-15. Some features may be adjusted as implementation progresses.*
+
+*Generated by [AUTO-DOCS-5] — CleverAgents Documentation Bot*
@@ -0,0 +1,138 @@
+# Advanced Concepts: E2E Tests, Code Review Examples & Plugin Architecture (v3.6.0)
+
+> **Milestone:** v3.6.0 — M7: Advanced Concepts & Deferred Features
+> **Parent:** [Advanced Concepts Overview](index.md)
+
+---
+
+## End-to-End Workflow Specification Tests
+
+v3.6.0 introduces a new category of tests: **E2E workflow specification tests**. These tests
+verify complete multi-step workflows from the user's perspective, exercising the full stack
+from CLI input through plan execution to file output.
+
+### Test Categories
+
+| Category | Description | Framework |
+|----------|-------------|-----------|
+| `e2e/workflow` | Full plan lifecycle: create to strategize to execute to apply | Robot Framework |
+| `e2e/multi-project` | Workflows spanning multiple projects | Robot Framework |
+| `e2e/provider` | Provider-specific behavior (rate limits, fallback, cost tracking) | Behave |
+| `e2e/safety` | Safety profile enforcement under various conditions | Behave |
+| `e2e/budget` | Budget enforcement and plan pause/resume | Behave |
+
+### Running E2E Tests
+
+```bash
+nox -s e2e                          # Run all E2E tests
+nox -s e2e -- --tags workflow       # Run only workflow tests
+nox -s e2e -- --tags provider       # Run only provider tests
+```
+
+E2E tests require a configured LLM provider. Set `E2E_PROVIDER=anthropic` (or another
+supported provider) in your environment before running.
+
+---
+
+## Code Review Tool Examples
+
+v3.6.0 ships a set of example actors and skills specifically designed for code review
+workflows. These serve as both functional tools and reference implementations for the actor
+and skill systems.
+
+### Included Examples
+
+| Example | Location | Description |
+|---------|----------|-------------|
+| `code-reviewer` | `examples/actors/code-reviewer.yaml` | Full code review actor with diff analysis, style checking, and security scanning |
+| `pr-summarizer` | `examples/actors/pr-summarizer.yaml` | Summarizes pull request changes for review |
+| `test-generator` | `examples/actors/test-generator.yaml` | Generates BDD test scenarios from source code |
+| `doc-writer` | `examples/actors/doc-writer.yaml` | Generates and updates documentation from code |
+| `security-scanner` | `examples/skills/security-scanner.yaml` | Skill that runs security analysis tools |
+| `style-checker` | `examples/skills/style-checker.yaml` | Skill that runs linting and formatting checks |
+
+### Using the Code Reviewer
+
+```bash
+# Register the example actor
+agents actor register examples/actors/code-reviewer.yaml
+
+# Create a code review plan
+agents plan use code-review \
+  --project local/my-project \
+  --arg diff_source=git \
+  --arg base_branch=main
+```
+
+---
+
+## Plugin Architecture Extensions
+
+v3.6.0 formalizes and extends the plugin architecture, making it easier to add custom
+resource types, tool executors, scope resolvers, and LLM providers.
+
+### Plugin Entry Points
+
+Plugins are registered via Python package entry points:
+
+```toml
+# pyproject.toml
+[project.entry-points."cleveragents.plugins"]
+my-plugin = "my_package.plugin:MyPlugin"
+
+[project.entry-points."cleveragents.resource_types"]
+my-resource = "my_package.resources:MyResourceType"
+
+[project.entry-points."cleveragents.tool_executors"]
+my-executor = "my_package.executors:MyToolExecutor"
+
+[project.entry-points."cleveragents.scope_resolvers"]
+my-resolver = "my_package.resolvers:MyScopeResolver"
+
+[project.entry-points."cleveragents.providers"]
+my-provider = "my_package.providers:MyLLMProvider"
+```
+
+### Plugin Security
+
+The `PluginLoader` (hardened in v3.5.0) enforces:
+
+- **Module allowlist** — only modules from registered, trusted packages may be loaded
+- **Entry point validation** — entry point targets are parsed and validated before import
+- **Sandbox isolation** — plugins run in a restricted execution environment
+- **Capability declaration** — plugins must declare their required capabilities at registration
+
+See ADR-037 (Tool Reachability & Access Projection) for the full security model.
+
+### Plugin Development Guide
+
+A plugin development guide is available at `docs/development/plugin-development.md` (added
+in v3.6.0). It covers:
+
+1. Creating a minimal plugin package
+2. Registering resource types, tool executors, and scope resolvers
+3. Testing plugins with the CleverAgents test harness
+4. Publishing plugins to PyPI
+
+---
+
+## Related ADRs
+
+The following Architecture Decision Records are directly relevant to v3.6.0 features:
+
+| ADR | Title | Relevance |
+|-----|-------|-----------|
+| [ADR-008](../adr/ADR-008-resource-system.md) | Resource System | Foundation for additional resource types |
+| [ADR-036](../adr/ADR-036-resource-dag-operational-semantics.md) | Resource DAG Operational Semantics | DAG model for new resource types |
+| [ADR-039](../adr/ADR-039-container-resource-types.md) | Container Resource Types | Container tool execution |
+| [ADR-041](../adr/ADR-041-safety-profile-extraction.md) | Safety Profile Extraction | Safety profiles and cost budgets |
+| [ADR-042](../adr/ADR-042-resource-type-inheritance.md) | Resource Type Inheritance | Custom resource type extensions |
+| [ADR-043](../adr/ADR-043-devcontainer-integration.md) | Devcontainer Integration | Devcontainer tool execution |
+| [ADR-047](../adr/ADR-047-acp-standard-adoption.md) | A2A Standard Adoption | ACP to A2A rename |
+
+---
+
+*Documentation for v3.6.0 — IN PROGRESS. Features described here reflect the planned scope
+as of 2026-04-15. Some features may be adjusted as implementation progresses.*
+
+*Generated by [AUTO-DOCS-5] — CleverAgents Documentation Bot*
@@ -0,0 +1,117 @@
+# Advanced Concepts (v3.6.0)
+
+> **Milestone:** v3.6.0 — M7: Advanced Concepts & Deferred Features
+> **Status:** In Progress (~33% complete as of 2026-04-15)
+> **Goal:** Advanced capabilities that extend beyond the core MVP without requiring the TUI (M8) or Server (M9).
+
+---
+
+## Overview
+
+v3.6.0 builds on the stable foundation established by v3.0.0–v3.5.0 to introduce advanced
+capabilities that were intentionally deferred from the MVP. These features enrich the
+CleverAgents platform for power users and production deployments: richer context strategies,
+broader LLM provider support, additional resource types, a standardized A2A protocol, container
+tool execution, extensible scope chain resolution, cost and safety budgets, end-to-end workflow
+tests, and a plugin architecture.
+
+None of these features require the TUI (v3.7.0) or the Server (v3.9.0) — they are fully
+usable from the CLI and programmatic API.
+
+**Sub-sections:**
+
+- [Context Strategies & LLM Backends](index.md) — this page
+- [Resource Types & A2A Rename](resource-types.md)
+- [Container Tools, Scope Chain, Budgets & Safety](container-tools.md)
+- [E2E Tests, Code Review Examples & Plugin Architecture](e2e-tests-and-plugins.md)
+
+---
+
+## Advanced Context Strategies
+
+The ACMS (Adaptive Context Management System) introduced in v3.4.0–v3.5.0 provides a
+four-stage pipeline: **Gather → Prioritize → Assemble → Deliver**. v3.6.0 extends this
+pipeline with advanced strategies for large-scale and multi-project workloads.
+
+### Beyond the Basic ACMS Pipeline
+
+The basic pipeline assembles context from a single project's resources using a fixed priority
+order. Advanced strategies add:
+
+| Strategy | Description |
+|----------|-------------|
+| **Cross-project context merging** | Assembles context from multiple projects simultaneously, respecting per-project budgets and cross-project relevance scores |
+| **Incremental context updates** | Sends only the diff of context changes between turns rather than re-assembling the full context on every prompt |
+| **Semantic deduplication** | Detects and removes semantically equivalent fragments before assembly, reducing token waste |
+| **Adaptive tier promotion** | Automatically promotes frequently-accessed warm/cold fragments to hot tier based on access patterns across a session |
+| **Resource-type-aware budgeting** | Allocates context budget by resource type (e.g., 40% source code, 30% tests, 20% docs, 10% config) rather than a flat priority queue |
+
+### Context Request Protocol (CRP) Extensions
+
+The CRP (defined in ADR-014) is extended with new directive types:
+
+- `focus_path` — elevates a specific file path to the highest priority tier, overriding all
+  other budget constraints
+- `exclude_pattern` — excludes files matching a glob pattern from context assembly
+- `max_fragment_size` — caps the size of any single fragment to prevent one large file from
+  consuming the entire budget
+- `semantic_group` — groups related fragments so they are either all included or all excluded
+  (prevents partial inclusion of tightly coupled files)
+
+---
+
+## Additional LLM Backends
+
+v3.6.0 adds first-class support for additional LLM providers beyond the Anthropic and OpenAI
+backends available in v3.5.0.
+
+### Supported Providers (v3.6.0 additions)
+
+| Provider | Actor Namespace | Notes |
+|----------|----------------|-------|
+| **Google Gemini** | `google/gemini-*` | Gemini 1.5 Pro and Flash; supports long-context (1M tokens) |
+| **Mistral AI** | `mistral/*` | Mistral Large, Codestral; strong code generation |
+| **Ollama (local)** | `ollama/*` | Any model served by a local Ollama instance |
+| **LM Studio** | `lmstudio/*` | OpenAI-compatible local inference |
+| **Azure OpenAI** | `azure/*` | Azure-hosted OpenAI models with enterprise auth |
+| **AWS Bedrock** | `bedrock/*` | Anthropic, Meta, and Mistral models via AWS |
+| **Groq** | `groq/*` | Ultra-fast inference for Llama and Mixtral models |
+
+### Provider Configuration
+
+All providers are configured in `~/.config/cleveragents/config.toml` under the `[providers]`
+section. Each provider supports a common set of base arguments (`temperature`, `max_tokens`,
+`thinking_effort` where applicable) plus provider-specific extensions.
+
+```toml
+[providers.google]
+api_key = "${GOOGLE_API_KEY}"
+default_model = "gemini-1.5-pro"
+
+[providers.ollama]
+base_url = "http://localhost:11434"
+default_model = "llama3.2"
+```
+
+### Provider Fallback Chains
+
+A new `provider_fallback` configuration allows defining ordered fallback chains for resilience:
+
+```toml
+[actor.default]
+provider_fallback = [
+  "anthropic/claude-4-sonnet",
+  "google/gemini-1.5-pro",
+  "ollama/llama3.2",
+]
+```
+
+When the primary provider fails (rate limit, outage, or cost budget exceeded), the system
+automatically retries with the next provider in the chain.
+
+---
+
+*Documentation for v3.6.0 — IN PROGRESS. Features described here reflect the planned scope
+as of 2026-04-15. Some features may be adjusted as implementation progresses.*
+
+*Generated by [AUTO-DOCS-5] — CleverAgents Documentation Bot*
@@ -0,0 +1,112 @@
+# Advanced Concepts: Resource Types & A2A Rename (v3.6.0)
+
+> **Milestone:** v3.6.0 — M7: Advanced Concepts & Deferred Features
+> **Parent:** [Advanced Concepts Overview](index.md)
+
+---
+
+## Additional Resource Types
+
+v3.6.0 extends the resource type system (ADR-008, ADR-036, ADR-039, ADR-042) with new
+resource types for cloud infrastructure, databases, and virtual/composite resources.
+
+### Cloud Infrastructure Resources
+
+| Type | Description | Key Properties |
+|------|-------------|----------------|
+| `aws-s3-bucket` | Amazon S3 bucket | `bucket_name`, `region`, `prefix` |
+| `aws-lambda-function` | AWS Lambda function | `function_name`, `region`, `runtime` |
+| `gcp-storage-bucket` | Google Cloud Storage bucket | `bucket_name`, `project_id` |
+| `azure-blob-container` | Azure Blob Storage container | `account_name`, `container_name` |
+| `terraform-workspace` | Terraform workspace (state + config) | `workspace_dir`, `backend_type` |
+| `pulumi-stack` | Pulumi stack | `stack_name`, `project_dir` |
+
+### Database Resources
+
+| Type | Description | Key Properties |
+|------|-------------|----------------|
+| `postgres-schema` | PostgreSQL schema (tables, views, functions) | `connection_string`, `schema_name` |
+| `mysql-database` | MySQL database | `connection_string`, `database_name` |
+| `sqlite-file` | SQLite database file | `file_path` |
+| `mongodb-collection` | MongoDB collection | `connection_string`, `database`, `collection` |
+| `redis-keyspace` | Redis keyspace | `connection_string`, `key_prefix` |
+
+### Virtual Resource Types
+
+Virtual resources do not correspond to a physical storage location — they are computed
+aggregates or logical groupings:
+
+| Type | Description |
+|------|-------------|
+| `virtual-aggregate` | A named union of other resources, treated as a single context source |
+| `virtual-diff` | The diff between two resource snapshots (e.g., before/after a plan apply) |
+| `virtual-search-index` | A pre-built semantic search index over a set of resources |
+| `virtual-dependency-graph` | The dependency graph of a codebase (imports, calls, inheritance) |
+
+### Resource Type Inheritance
+
+The resource type inheritance system (ADR-042) allows custom resource types to extend built-in
+types. v3.6.0 adds the `@extends` directive in resource YAML:
+
+```yaml
+type: my-org/custom-git-repo
+extends: git-checkout
+properties:
+  ci_config_path:
+    type: string
+    default: ".github/workflows"
+  deploy_branch:
+    type: string
+    default: "main"
+```
+
+---
+
+## ACP to A2A Module Rename and Symbol Standardization
+
+v3.6.0 completes the rename of the internal `acp` module to `a2a`, aligning the codebase with
+the adopted A2A standard (ADR-047).
+
+### What Changed
+
+| Before (ACP) | After (A2A) |
+|-------------|------------|
+| `cleveragents.acp` | `cleveragents.a2a` |
+| `AcpClient` | `A2AClient` |
+| `AcpMessage` | `A2AMessage` |
+| `AcpTask` | `A2ATask` |
+| `AcpEvent` | `A2AEvent` |
+| `acp_server_url` config key | `a2a_server_url` config key |
+
+### Migration Guide
+
+Existing code that imports from `cleveragents.acp` will continue to work via a compatibility
+shim until v4.0.0. A deprecation warning is emitted on first import. To migrate:
+
+```python
+# Before
+from cleveragents.acp import AcpClient, AcpMessage
+
+# After
+from cleveragents.a2a import A2AClient, A2AMessage
+```
+
+The CLI commands are unaffected — they use the public API which was already A2A-named.
+
+---
+
+## Related ADRs
+
+| ADR | Title | Relevance |
+|-----|-------|-----------|
+| [ADR-008](../adr/ADR-008-resource-system.md) | Resource System | Foundation for additional resource types |
+| [ADR-036](../adr/ADR-036-resource-dag-operational-semantics.md) | Resource DAG Operational Semantics | DAG model for new resource types |
+| [ADR-042](../adr/ADR-042-resource-type-inheritance.md) | Resource Type Inheritance | Custom resource type extensions |
+| [ADR-047](../adr/ADR-047-acp-standard-adoption.md) | A2A Standard Adoption | ACP to A2A rename |
+
+---
+
+*Documentation for v3.6.0 — IN PROGRESS. Features described here reflect the planned scope
+as of 2026-04-15. Some features may be adjusted as implementation progresses.*
+
+*Generated by [AUTO-DOCS-5] — CleverAgents Documentation Bot*