$target
$target : string
What a restore would do, subject by subject, before anything is written.
The document the confirm form prints and the audit log keeps. It exists because a rollback is not one decision but one per subject: some can be put back exactly, some only in part, some not at all, and an operator who is shown a single "restore 1,412 items" button is not being told which.
A plan is produced without writing anything and is the same plan the apply uses, so what is confirmed is what happens.
__construct(string $target, int $depth = 0, array$subjects = [], list $problems = [], bool $fillDegraded = false, float $seconds = 0.0, int $plannedAt = 0, bool $acceptConflicts = false) : mixed
Constructs a plan.
| string | $target | Commit the restore targets. |
| int | $depth | How many commits a replay covers to reach it, which is what the restore costs to compute. |
| array |
$subjects | Subject path keyed to what a replay produced for it. |
| list |
$problems | One line per subject that could not be planned at all. |
| bool | $fillDegraded | Whether the scope opted in to writing partial reconstructions. FALSE is the default and the only safe answer without a human saying otherwise. |
| float | $seconds | How long planning took. |
| int | $plannedAt | Unix microseconds the plan was built. What a concurrent edit is measured against: a subject written after this moment was written by somebody who had not seen the plan. |
| bool | $acceptConflicts | Whether the scope opted in to overwriting a subject somebody changed while the plan was waiting. FALSE by default: overwriting an edit nobody saw is a decision, not a detail. |