GovernedAct

RUNS ONE NAMED OPERATION THROUGH THE PANEL'S DOOR — the shape both governed buttons share. The panel has two: installing a capability and applying a newer framework. They are the same act with a different name — a scoped, consent-demanding operation, projected over HTTP, behind the gate the section pages already carry. Written twice they would drift, and the half that drifted would be the refusal, which is the part a person reads (greenhouse decisions/0297). ── THE ROUTE NAME TRICK, AND WHY IT IS HERE ──────────────────────────────────────────────────────── `HttpProjector` resolves which operation a request is for from the MATCHED ROUTE'S NAME. The panel's routes carry their own names so they can never collide with a host that also exposes the same operation through `config/http.php`, so the operation's name is handed over here — the one place that knows both. ── AND A NAMEABLE REFUSAL IS NOT AN EXCEPTION ────────────────────────────────────────────────────── 🚨 Measured in a browser on fresh cattle: the install button answered `internal_error`, and only the app's log said why — «exige los scopes […] y este host no cableó una OperationHttpPolicy». The framework names that same condition at BOOT when an app lists the operation in `config/http.php`; letting it escape here turns a sentence somebody can act on into a stack trace (decisions/0289). 501 and not 403: the caller is not being denied, and nothing about them would change the answer. This app has not implemented a way to judge the act at all.

public static function run(object $projector, string $operation, Psr\Http\Message\ServerRequestInterface $request, Psr\Http\Message\ResponseFactoryInterface $responses, string $noJudge): Psr\Http\Message\ResponseInterface

Projects the request as `$operation` and answers what the ceremony answers.

Parameters