82f3140847
Complete architecture document set with multi-model review remediation: - Frozen interface contracts, runtime semantics, DB schemas - Event/tool/error/provider registries - Scheduler and main agent state machines - C4 module/code views, solution architecture, baseline V1 - Multi-model review reports and joint assessment - Phase-gate remediation complete (P0/P1/P2/UX resolved) - Implementation plan with T-000A through T-045 - Reference folders kept as placeholders only
22 lines
998 B
Markdown
22 lines
998 B
Markdown
# ADR-0007: Use ToolRegistry, PermissionEngine, And Capability Manifests
|
|
|
|
- Status: Accepted
|
|
- Date: 2026-05-27
|
|
|
|
## Context
|
|
|
|
AirCoding needs a growing tool surface across filesystem, shell, git, build, debug, GUI, network, memory, and future plugins. Tools must be extensible without bypassing safety boundaries.
|
|
|
|
## Decision
|
|
|
|
Use ToolRegistry for schema-validated tool execution, PermissionEngine for all side-effect decisions, and CapabilityRegistry for built-in/future tool bundles.
|
|
|
|
Capabilities declare dependencies and permissions. Doctor/setup detects and installs/fixes dependencies according to permission policy. Capability tools are not privileged above built-ins.
|
|
|
|
## Consequences
|
|
|
|
- All tool calls share lifecycle events, artifacts, errors, and evidence behavior.
|
|
- Plugin/capability extension is possible without opening a permission bypass.
|
|
- Doctor owns dependency installation rather than arbitrary plugin scripts.
|
|
- MVP tool names and schemas are frozen in `tool-registry-v1.md`.
|