ConstructionProbe

Asks a booted house to build a routed controller, the way serving its route does. ── WHY EXECUTION AND NOT A READING OF THE CONSTRUCTOR (greenhouse decisions/0541) ────────────── Rod's first live run (evidence/1071) landed GREEN a controller whose constructor asked for `DIContainerInterface`; nothing registers it, and `GET /blog` went from 200 to 500. A reading would have to guess: an interface may be registered in some plugin's boot(), a concrete class may still refuse to build. The house's own act does not guess — `ContainerHandlerResolver` asks the container for the class a route names — so this runs that act in a child process ({@see self::SCRIPT}), on the root it is given, and reports what the container said. Only a class some route names is built: the house builds nothing else by name, and a judge that constructs what nothing constructs invents the use. A house that does not boot is left UNJUDGED and says so — the boot witness refuses a broken boot at the promotion (0512/0515); a second judge of the same fact would be a second authority.

public function __construct(?string $php = null):

Parameters

public function probe(string $root, string $class): array

What the house said about building `$class`. `unjudged` carries the reason nothing was built (no autoloader, a boot that failed, a child that answered nothing); otherwise `routes` lists the routes that name the class — empty when none does — and, when some does, `built` says whether the container gave it back, with `error` and `unresolvable` (parameter → type) when it did not. `operation` is there when the class is an operation the booted house offers (greenhouse evidence/1154): its name, whether the entry that lists it handed `run()` everything it works through, and — when it did not — each type it could not hand with what the house answered.

Parameters

public static function unhanded(string $pluginDir, string $plugin, string $class, string $fqcn, string $name, array $unhanded): string

The refusal a model corrects from when the house cannot hand an operation what its `run()` works through: what it asked for, what the house answered, why, and THE WAY with the order in which it lands. ── A REPOSITORY IS REACHED BY ITS ENTITY (greenhouse evidence/1154) ────────────────────────────────────────── `Milpa\Data\RepositoryInterface` is registered by nobody, and should not be: there is one repository per entity, under the id `make entity` gave it. What hands it to `run()` is the entry that lists the operation in its plugin — written with the entity when the operation was scaffolded with one, and by class when it was not. A real resident scaffolded with none, wrote `run()` against the repository, and nothing said a word until the first call. The fix is one exact edit of that entry, and it is written out here: with one entity in the plugin it names it; with several it leaves the name to whoever knows which. Anything else nobody registered is the defect a controller's constructor has, and takes the same fix: its type registered in the plugin's `boot()`.

Parameters

public static function refusal(string $plugin, string $class, array $routes, string $error, array $unresolvable): string

The refusal a model corrects from: which route asks, what could not be filled, the rule, and the ORDER in which the fix lands. ── WHY THE PARAMETER'S TYPE AND NOT THE BUILT CONTROLLER (greenhouse evidence/1075) ────────────── The first version said «register the built controller in boot()». A real resident followed it and hit a wall: `new BlogController($repository)` in the plugin is refused by static analysis while the live controller has no such constructor, and the controller is refused by THIS judge until something is registered. Registering the parameter's TYPE names no controller, so it lands on its own — and then the container fills the parameter and the controller lands.

Parameters