ManagementPlan
in package
What {@see ManifestApi::plan()} produced: the ordered changes an apply would make.
A plan is a VALUE. Producing one writes nothing (§27.6) — it reads the tenant's current state and reports the difference, so it is safe to run against production, safe to print, and safe to diff between runs. That last property is why the ordering is derived and deterministic rather than dependent on hash iteration order: two runs against an unchanged tenant must produce the same plan, or nobody can tell a real change from noise.
Table of Contents
Properties
- $changes : array<string|int, mixed>
Methods
- __construct() : mixed
- describe() : array<int, string>
- The plan as lines of text, one per pending change — what an operator reads before approving an apply.
- isConverged() : bool
- True when the tenant already matches the manifest and an apply would send nothing.
- pending() : array<int, PlannedChange>
- Only the changes that would actually send a request.
Properties
$changes read-only
public
array<string|int, mixed>
$changes
Methods
__construct()
public
__construct(array<int, PlannedChange> $changes) : mixed
Parameters
- $changes : array<int, PlannedChange>
-
Every declared entity, in apply order — including the unchanged ones, so a reader can see what was considered and not only what moved.
describe()
The plan as lines of text, one per pending change — what an operator reads before approving an apply.
public
describe() : array<int, string>
Return values
array<int, string>isConverged()
True when the tenant already matches the manifest and an apply would send nothing.
public
isConverged() : bool
Return values
boolpending()
Only the changes that would actually send a request.
public
pending() : array<int, PlannedChange>