Apply All is an ordered local patch transaction, not a blind replay button. GDP checks the pending sequence first, prepares rollback protection before writes, journals each successful apply immediately, and preserves already-applied items as no-reapply recovery state when later work or verification activation fails.
Know what GDP checks before the first write
Apply All is available only for multiple queued patch items. ZIP imports stay outside the batch path, and every patch item must have usable content and safely isolatable selected paths.
Before patch execution, GDP blocks a batch containing terminal, conflicting, or unavailable rejection authority. It then runs an ordered dry-run across the entire pending patch sequence. If that ordered dry-run fails, no patch in the pending sequence is written.
A ZIP item must be reviewed and imported through its own local flow.
An item with no selected paths or unsafe path isolation blocks the batch before writes.
A rejected or authority-conflicted item blocks Apply All instead of being silently skipped.
Passing the ordered dry-run is preflight evidence, not proof that the batch was applied.
Use the batch rollback boundary
After the ordered dry-run and any required local confirmation, GDP prepares rollback protection for the patch sequence before applying the first pending patch. If rollback preparation fails, patch execution does not start.
GDP then applies pending items in order. Each successful item is written to Apply History immediately before the controller moves to later items, so a later failure does not erase evidence of earlier successful local writes.
One Apply All action can therefore end with earlier items applied and a later item failed. Read the exact status and Apply History instead of assuming the whole batch was all-or-nothing.
Do not reapply items that already succeeded
If a later patch fails after earlier items were applied, GDP attempts to persist those earlier successes as durable no-reapply recovery state. Rollback remains available for the protected sequence. If recovery-state persistence itself fails, GDP reports manual reconciliation instead of pretending the batch is safe to replay.
The same no-reapply rule protects verification activation. When a patch is already applied but its attached verification bundle could not be activated durably, the review item can remain queued with an activation-pending marker. A later Apply or Apply All retries verification activation; it must not apply that patch again.
patch_applied plus verification activation pending means recover verification, not patch bytes.
Already-applied recovery items with released verification can be cleared without reapplying the patch.
An applied recovery item with inconsistent durable identity or state requires manual reconciliation.
Do not resend the same mutation merely because its recovery item is still visible.
Reconcile the batch before continuing
Read the Apply All status to identify whether failure happened before writes, on the first patch, after earlier successful patches, or during verification activation.
Inspect current Git status/diff and the relevant Apply History entries for the repository.
If already-applied recovery items remain, let GDP recover their verification state without reapplying them.
Use Rollback History when you intentionally need to restore the protected pre-batch state; do not confuse rollback with retry.
Only after exact applied, failed, and recovery state is known should you fix the failing patch or verification command and continue from the first unproven step.
If GDP reports that durable recovery state could not be persisted, stop automatic retry and reconcile manually from Git state, Apply History, rollback evidence, and the exact queued items.
