Admin as plugin: reduce administration to a UI-serving plugin backed by config primitives #89

Overview

The end-state goal of the engine + admin decomposition work: administration is served as a plugin that primarily contributes its UI (the admin dashboard). All backend functionality is expressed through config-driven pipeline primitives — no custom Go handlers except for domain services that genuinely need runtime logic.

This is the north star. The phased issues below are the path to get here.

Current State

• Admin is a monolithic Go server (cmd/server/main.go) with 31+ fields on a god object
• 18 intermediate handler modules in admin/config.yaml that just delegate
• ~60 routes with meaningless name: forward step.delegate steps
• Many routes silently return 404 (missing DB tables, unhandled paths)
• Feature flag module already migrated to config+primitives pattern (PR Refactor serverApp god object into domain-scoped sub-structs with minimal interfaces; move admin wiring to config+primitives #56)

Target State

• Engine core (~400 lines) — YAML parsing, module lifecycle, service registry, plugin loading
• All module types provided by plugins via capability contracts
• Admin backend — 2 generic handlers, routes expressed as pipeline primitives where possible
• Admin UI — served as a plugin that contributes UI pages + a few domain-service delegates
• Domain services (Timeline, DLQ, AI, Components, etc.) — each a self-registering module type discoverable via service registry

Dependency Chain

Engine Decomposition (core → plugins)

1. Engine Decomposition: Capability contract system & plugin loader (Phase 1 Foundation) #81 — Phase 1: Capability contract system & plugin loader (Foundation)
2. Engine Decomposition: Extract HTTP & Observability plugins (Phase 2) #82 — Phase 2: Extract HTTP & Observability plugins (Proof of concept)
3. Engine Decomposition: Extract remaining 13 plugins (Phase 3) #83 — Phase 3: Extract remaining 13 plugins
4. Engine Decomposition: Clean core — eliminate BuildFromConfig switch & add workflow dependencies (Phase 4) #84 — Phase 4: Clean core — eliminate switch, add workflow dependencies

Admin Config Decomposition (monolith → primitives)

5. Admin Decomposition: Consolidate 18 handler modules into 2 generic handlers (Phase A) #85 — Phase A: Consolidate 18 handler modules → 2 generic handlers
6. Admin Decomposition: Decompose V1 CRUD routes into pipeline primitives (Phase B) #86 — Phase B: Decompose V1 CRUD routes → pipeline primitives
7. Admin Decomposition: Add missing DB tables & decompose broken routes (Phase C) #87 — Phase C: Add missing DB tables & decompose broken routes
8. Admin Decomposition: Rename delegate steps & add pre-processing for domain routes (Phase D) #88 — Phase D: Rename delegate steps for domain routes

Domain Service Module Types (new)

9. Each domain service (event store, timeline/replay, DLQ, execution tracker, runtime manager, backfill, billing) gets extracted into a self-registering module type following the feature flag pattern from PR Refactor serverApp god object into domain-scoped sub-structs with minimal interfaces; move admin wiring to config+primitives #56

The Feature Flag Template (PR #56, commit ab64254)

The pattern for each domain service migration:

1. Module already exists as a configurable primitive → declare it in admin/config.yaml instead of Go
2. Module self-registers its admin adapter in the service registry via ProvidesServices()
3. Server auto-discovers it without explicit wiring

Success Criteria

• Administration can run from admin/config.yaml + plugins — no hardcoded module wiring in Go
• Adding a new admin feature = adding config + optional UI plugin, not modifying server code
• Domain services are independently testable module types
• Admin UI is a plugin that can be enabled/disabled
• engine.go is ~400 lines with no module/handler imports