Skip to content
docsv0.34.0

FrameworkApplier

TAKES THE FILES A NEWER FRAMEWORK CHANGED — the panel's second governed button. The same shape as {@see CapabilityInstaller}, which is why both run through {@see GovernedAct}: a scoped, consent-demanding operation projected over HTTP behind the panel's own door. What differs is only the operation's name and the sentence it refuses with. ── WHAT THE OPERATION ITSELF GUARANTEES, SO THIS ROUTE NEED NOT ──────────────────────────────────── `framework:apply` writes only what the reconciliation calls `offered` or `added` — never a file the house customized, and never one whose birth bytes were not recorded. And it refuses outright unless git can be the way back: not a repository, an untracked target, or an uncommitted edit each stop it with a sentence. None of that is repeated here, and repeating it is exactly what would let the two drift (greenhouse decisions/0295, 0297). So this class carries no judgement of its own. It hands the request to the ceremony and returns what the ceremony answered.

FrameworkApplier::__construct()

public function __construct(Milpa\Console\Http\HttpProjector $projector, Psr\Http\Message\ResponseFactoryInterface $responses = new Psr17Factory()):

Parameters

Parameters of __construct()
NameTypeDescription
$projectorMilpa\Console\Http\HttpProjector
$responsesPsr\Http\Message\ResponseFactoryInterface

FrameworkApplier::handle()

public function handle(Psr\Http\Message\ServerRequestInterface $request): Psr\Http\Message\ResponseInterface

Runs the apply through the operation's own HTTP ceremony: policy, confirm token, execute.

Parameters

Parameters of handle()
NameTypeDescription
$requestPsr\Http\Message\ServerRequestInterface