Category: Code Smell / Architectural Issue
Problem
plugin-core contains 83 files spanning 8+ distinct domains. It's the catch-all for everything that isn't explicitly "scheduling," "knowledge," or "orchestration." Meanwhile, plugin-orchestration is a thin wrapper that delegates back to plugin-core.
Domain breakdown of plugin-core:
- Environment management:
environment-handlers.ts (295 lines), reconciliation
- Session lifecycle:
session-handlers.ts (1033 lines, 66+ functions!)
- Task dispatch:
task-handlers.ts (772 lines, 40+ functions)
- Workspace isolation:
workspace-handlers.ts (190 lines)
- Token management:
token-handlers.ts (93 lines)
- Agent management:
agent-handlers.ts (254 lines)
- Signal handling:
signals/ directory (escalation, orphan, sigchld)
- Channels:
channel-ingest.ts, channel-config.ts
- Plus: persona (195 lines), component (313 lines), escalation (81 lines), github-accounts (152 lines), codespace, docker, settings, resources, plugins, events, runtime-catalog
Comparison:
- plugin-scheduling: 1 plugin file + 5 handlers (well-scoped)
- plugin-knowledge: 1 plugin file + 11 files (domain-specific)
- plugin-orchestration: 1 plugin file + 0 handler files (just wraps plugin-core)
- plugin-core: 1 plugin file + 82 files (monolith)
Orchestration handlers in the wrong package:
Task, persona, escalation, and component handlers are implemented in plugin-core but serve orchestration. plugin-orchestration just re-exports them via createOrchestrationCollector(). If orchestration is disabled, these handlers still exist in plugin-core but aren't accessible over gRPC (weird state).
Proposed Fix
Phase 1: Move orchestration handlers (task, persona, escalation, component) from plugin-core into plugin-orchestration. plugin-core drops from ~83 to ~50 files. plugin-orchestration becomes a real plugin.
Phase 2: Consider further splits:
plugin-environments — environment handlers, reconciliationplugin-sessions — session spawn, stream, lifecycleplugin-agents — agent CRUD, heartbeat
Impact
High — unclear domain boundaries, single point of dependency, hard to test in isolation, unclear where new features should live.
Category: Code Smell / Architectural Issue
Problem
plugin-corecontains 83 files spanning 8+ distinct domains. It's the catch-all for everything that isn't explicitly "scheduling," "knowledge," or "orchestration." Meanwhile,plugin-orchestrationis a thin wrapper that delegates back to plugin-core.Domain breakdown of plugin-core:
environment-handlers.ts(295 lines), reconciliationsession-handlers.ts(1033 lines, 66+ functions!)task-handlers.ts(772 lines, 40+ functions)workspace-handlers.ts(190 lines)token-handlers.ts(93 lines)agent-handlers.ts(254 lines)signals/directory (escalation, orphan, sigchld)channel-ingest.ts,channel-config.tsComparison:
Orchestration handlers in the wrong package:
Task, persona, escalation, and component handlers are implemented in plugin-core but serve orchestration. plugin-orchestration just re-exports them via
createOrchestrationCollector(). If orchestration is disabled, these handlers still exist in plugin-core but aren't accessible over gRPC (weird state).Proposed Fix
Phase 1: Move orchestration handlers (task, persona, escalation, component) from plugin-core into plugin-orchestration. plugin-core drops from ~83 to ~50 files. plugin-orchestration becomes a real plugin.
Phase 2: Consider further splits:
plugin-environments— environment handlers, reconciliationplugin-sessions— session spawn, stream, lifecycleplugin-agents— agent CRUD, heartbeatImpact
High — unclear domain boundaries, single point of dependency, hard to test in isolation, unclear where new features should live.