Worked example — active re-consent

A material change to the core of the contract still requires active agreement, with the full grace period and a hard gate at the deadline:

php artisan legal-consent:publish terms de --active \
    --announce-at=2026-07-01 --enforce-at=2026-09-01

Both dates are validated

You cannot smuggle a short lead by omitting --announce-at, and the minimum period is per regime (§ 675g's two months is hard).

Nor by backdating it. The period runs from the first day a notice can go out, and nothing is sent before the version is published, so an --announce-at on a day already past is measured as today. The date is still stored as given, and the notice goes out with the next dispatch.

Since 0.19.0 the order itself is checked as well, before any mode or regime rule runs: an --announce-at that falls after --enforce-at is refused rather than frozen. A change cannot take effect before it was announced, and the stored notice_period_days can no longer be negative.

An --enforce-at in the past with no --announce-at is unaffected — that is the documented immediate gate, and it now freezes a period of 0 rather than a negative number.

Use a future --enforce-at: the lead-time guard only runs while the effective date is still ahead, so an already-past date publishes an immediate gate with no grace. The dates above are illustrative — pick your own.

What happens at the deadline

From enforce_from, the middleware blocks the subject until they re-accept the new major version.

A SHA-256 hash detects any text change; a human classifies it (the notice mode) at publish time; the gate compares major_version only.

Which subjects the gate blocks at all is configurable — see gate.subject_filter in the configuration reference — and the route it redirects to is routes.consent_name.