Solver

Mechanism

The abstract Trait exposing the five-surface Solver Contract — Manifest (what can you do?), Execute (perform the Task), Consult (cost/quality/rationale), Verify (post-execution assurance), and Feedback (emits a typed PerformanceSignal — structured evaluation, or a FrameError escalation). Manifest and Execute are mandatory; Consult/Verify/Feedback are optional but strongly recommended at hard seams. Accepts a typed Task and yields a typed Solution. Solver is an interface, not a class: any Agent can take on the role of a Solver for the duration of a Task. The "[descriptor]Solver" naming convention is the library's construction pattern — DiagnosticSolver, PlanningSolver, ReduceSolver, PUREOptimizationSolver, and so on are all minted by appending "Solver" to a domain descriptor, each specialising the contract. The same agent can wear many solver roles simultaneously or sequentially; lightweight roles (Manifest + Execute only) scale up to permanent instances as tasks compound. Recursion follows naturally: when a Solver decomposes its Task, it becomes the root of a sub-tree whose children are themselves Solvers — the mechanism that gives the UniversalSolverTree its fractal shape.