EPIC: Queen/Bee capability registry, T27 domains, and tool routing contract #1665

Goal

Define a single T27-native capability contract that lets Queen select domain skills and permitted tools for each Bee task without duplicating utilities or creating 27 permanent worker processes.

Boundary

This epic designs and validates the registry and routing contract against existing Queen/Bee behavior. It does not create a parallel queue, worker registry, lease database, task state machine, or review pipeline. Preserve deployed behavior and reuse existing CLI/API/runtime tools through explicit adapters when necessary.

User Scenarios & Testing

• Queen receives a compiler bug task and selects the compiler domain plus only relevant tools and verification skills.
• A tool can be reused by multiple domains without duplicating its implementation.
• A Bee is denied a tool outside its granted capabilities and returns evidence of actions and results.
• A missing T27-native capability is reported explicitly rather than prompting an untracked Python script.

Requirements

• Audit existing domain roster, tool registry, skills, CLI utilities, Queen dispatch, Bee execution, leases, retries, cancellation, evidence, and review contracts before designing changes.
• Define separate T27 contracts for domain, skill, tool/capability, worker assignment, and verification result.
• Each tool contract specifies stable identifier, input/output schema, permissions, side effects, timeout/retry behavior, and evidence emitted.
• Each domain references capabilities and skills; it does not copy their implementations.
• Queen routing must be dynamic and task-specific; 27 domains are specializations, not a requirement for 27 always-running agents.
• Add compatibility/differential tests before any production cutover.
• Keep external CLI/API/browser constraints as narrow, documented boundaries; do not pretend wrappers make external code T27-native.

Success Criteria

• Current implementation is mapped to the proposed contracts with concrete source paths.
• T27 domain/tool/skill contracts validate with the existing toolchain or a documented minimal prerequisite issue.
• A representative task routes to a minimal domain/tool set and emits auditable evidence.
• Shared tools are referenced rather than duplicated.
• Permission-denial, timeout, retry, cancellation, and verifier cases are covered by tests.
• No parallel queue/lease/review architecture is introduced.
• Any migration is staged behind parity tests and a rollback path.