GraphResolver

The engine — a pure function from a materialized {@see ResolutionInput} to a {@see ResolutionReport}. It runs the algorithm of spec §11 pasos 2-5: resolve required contracts against the implementations declared by installed packages (semver-checked, legacy-aware), resolve required and suggested capabilities against the available providers (constraint-checked, priority-ordered per spec §3.1, honouring `oneOf` and detecting `exclusive` conflicts), resolve each active surface's requirements, and classify the whole graph as `valid`, `bootable_with_warnings`, `legacy_compatible`, or `blocked`. Error codes travel as plain strings on the report entries; milpa/resolver's learnable-error catalog is layered on top of them. The report also ORDERS the boot: `loadOrder[]` is the topological sort of the version manifests (Kahn's algorithm, absorbed from the legacy `Milpa\Plugin\ContractResolver`) over the exact-string capability/contract ids they provide and require. A dependency cycle has no possible boot order — nobody can go first — so it blocks as a learnable `conflicts[]` entry (`MILPA_DEPENDENCY_CYCLE`) instead of throwing. Purity is a hard invariant: the engine reads only its input — no filesystem, no network, no clock, no randomness — so the same input always yields a byte-identical report. Every report list is sorted by a total key order for that determinism — except `loadOrder[]`, whose order is the payload itself (still deterministic: a pure function of the input order).

public function __construct(Milpa\Services\CapabilityMatcher $matcher = new CapabilityMatcher()):

Parameters

public function resolve(Milpa\Resolver\Input\ResolutionInput $input): Milpa\Resolver\Report\ResolutionReport

Resolve the architecture described by the input into a report.

Parameters