discovery(orchestration): dual AgentCapability definitions — Enum (orchestration) vs dataclass (agents.agent_orchestration) #6818

Discovered during

Audit of issue #4048 closure (orchestrator consolidation deep-audit, 2026-05-04).

Finding

Two completely different classes share the name `AgentCapability` in two packages:

These represent fundamentally different concepts: one is a tag/enum ("this task needs RESEARCH capability"), the other is a descriptor ("this agent has these specs"). Same name, different semantics, never reconciled.

The `enhanced_orchestration` package side-steps the collision by importing the Enum:

• enhanced_orchestration/types.py:21: `from orchestration.types import AgentCapability # single canonical definition (discovery(orchestration): two divergent AgentCapability enums — orchestration/types.py and enhanced_orchestration/types.py should be merged #6192)`
• The comment explicitly claims canonicality, but only relative to enhanced_orchestration. `agents.agent_orchestration` is unaware.

Evidence

grep -n "^class AgentCapability\|class AgentCapability(" \
  autobot-backend/orchestration/types.py \
  autobot-backend/agents/agent_orchestration/types.py \
  autobot-backend/enhanced_orchestration/types.py

Why it matters

A reader following `from … import AgentCapability` cannot tell which shape they're getting without checking the import path. Future refactors that move classes between packages risk silent semantic breakage.

Recommendation

Rename one of them to make intent unambiguous. Suggested:

• Keep `orchestration.types.AgentCapability` as the Enum (tag) — broadly imported.
• Rename `agents.agent_orchestration.types.AgentCapability` → `AgentCapabilityDescriptor` — it's an agent profile, not a capability tag.

Acceptance criteria

• Single class named `AgentCapability` in the codebase, OR both classes have explicitly distinct names
• All call sites updated
• `grep -rn '^class AgentCapability'` returns at most one definition

Priority

P2 — confusing but not actively broken.