Skip to content
Corex

ModeChangeService

Corex\Config\Operations\ModeChangeService · class · Config layer

The rules for changing the operations mode, in one place (spec 101). They lived inside {@see OperationsModeController::handle()} while the Operations screen was the only way to change the mode. A command line that can change it too must be held to the same confirmations and write the same history, and two copies of a rule is how one of them stops being enforced. So the controller and the command both hand a {@see ModeChangeRequest} to this service and report what comes back; neither decides anything. The rules are the ones the controller already had, moved here unaltered: - an unknown mode is refused; - a mode a lock does not allow is refused (spec 113); - production is a launch — it needs its typed phrase and goes through {@see ProductionLaunchService}, which evaluates readiness and records the override; - a mode that needs an acknowledgement is not applied without one; - applying the mode already declared changes nothing and is reported as such; - leaving Coming soon, by any route, removes the preview link (spec 101, FR-012a). Capability and nonce are not here. They belong to whichever boundary received the request.

__construct(OperationsMode $modes, OperationsModeStore $store, ProductionReadinessSnapshotFactory $readiness, ProductionLaunchService $productionLaunch, PreviewAccess $preview)

Section titled “__construct(OperationsMode $modes, OperationsModeStore $store, ProductionReadinessSnapshotFactory $readiness, ProductionLaunchService $productionLaunch, PreviewAccess $preview)”

apply(ModeChangeRequest $request): ModeChangeResult

Section titled “apply(ModeChangeRequest $request): ModeChangeResult”