Engine Decomposition: Capability contract system & plugin loader (Phase 1 Foundation)

[intel352]

Overview

Create the plugin contract system and engine plugin loader — the foundation that all subsequent plugin extractions depend on.

Reference: docs/PLAN_ENGINE_DECOMPOSITION.md — Phase 1

What This Enables

Today, all 50+ module types are hardcoded in engine.go's BuildFromConfig switch statement (~550 lines of config parsing). This phase creates the registration machinery that plugins will use to contribute module factories, step factories, triggers, workflow handlers, and schemas at load time — without touching engine.go.

Tasks

Capability Package (capability/)

• contract.go — Contract type with name, description, interface type, required methods
• registry.go — Registry for registering/querying capability providers
• detect.go — Auto-detect required capabilities from YAML config (scan module types used)
• Unit tests for all of the above

Engine Plugin Interface (plugin/)

• engine_plugin.go — EnginePlugin interface: ModuleFactories(), StepFactories(), TriggerFactories(), WorkflowHandlers(), WiringHooks(), ModuleSchemas(), Capabilities()
• loader.go — Plugin loader that accepts []EnginePlugin, calls registration methods, populates registries
• engine_plugin_manager.go — Extends PluginManager with engine-plugin lifecycle (topological sort, dependency resolution)
• resolver.go — Workflow dependency resolution (check requires against capability registry)
• Extend manifest.go with capability, module type, step type, trigger type, workflow type declarations
• Unit tests for all of the above

Engine Integration

• Add LoadPlugin() method to StdEngine in engine.go
• Add wiring hook runner to engine.go (executes plugin-provided hooks after module init)
• BuildFromConfig checks plugin-registered factories before the built-in switch (backward compatible)

Schema Integration

• Make KnownModuleTypes() in schema/schema.go delegate to a dynamic registry
• Allow runtime schema registration in schema/module_schema.go

Config Extension

• Add requires section to WorkflowConfig in config/config.go

Key Design Decisions (from docs)

• Plugins introduce capability categories, not the core
• Workflows depend on capabilities (requires: [http-server]), not plugins
• First plugin to register a capability defines its interface contract
• Core provides registration machinery only

Files to Create

capability/contract.go, capability/registry.go, capability/registry_test.go, capability/detect.go, capability/detect_test.go, plugin/engine_plugin.go, plugin/engine_plugin_manager.go, plugin/engine_plugin_manager_test.go, plugin/loader.go, plugin/loader_test.go, plugin/resolver.go, plugin/resolver_test.go

Files to Modify

engine.go, config/config.go, plugin/manifest.go, schema/schema.go, schema/module_schema.go

[intel352]

All requirements for Phase 1 are fully implemented: capability/ package (contract, registry, detect), plugin/ package (engine_plugin, loader, manager, resolver), engine integration (LoadPlugin, wiring hooks, BuildFromConfig with plugin factory priority), schema integration (dynamic registry), and config extensions (requires section). No outstanding work.