Keep the user's primary action and parent-reference maintenance as separate operations. Record the follow-up intent before the primary action where possible, but hold it until that action succeeds or its outcome can be verified. A failed parent update must not reverse a successful child publication. If persistence itself fails, warn the user rather than claiming the follow-up is safely queued.

Use the existing shared XState v5 implementation rather than adding another queue:

Persist job data and verified checkpoints, not running promises. After a restart, create fresh actors that inspect the current state. The coordinator runs one job at a time locally. Retryable failures receive an initial attempt plus three retries with backoff; exhausted or unsafe work becomes Needs attention. A delayed retry preserves ordering for its parent without preventing unrelated parents from progressing.

On desktop, the coordinator lives in the Electron main process and serves all renderer windows. On web, a root-mounted host starts recovery outside document routes; an exclusive Web Lock lets one tab drain the durable command inbox and queue at a time. Both recover per device/browser profile, not across devices, and neither executes while the app is closed.

An attempt follows an explicit sequence:

Verify the primary action. A held intent cannot change a parent until the child's publication, move, or deletion is confirmed. On recovery, require captured evidence such as the signed version or original redirect identity; finding a document at the path is not sufficient proof.

Load and plan. Read the current published parent and calculate the smallest required reference correction. Already-correct content produces no duplicate card or unnecessary edit. A missing parent ends that maintenance job without recreating the parent.

Publish and verify. Apply the reference-only change when needed, read back the parent, and record the verified publication version as a durable checkpoint.

Reconcile the draft. Bring any parent draft and live editor forward to that baseline while preserving local edits. If this fails after publication, retain the checkpoint: recovery must finish reconciliation rather than blindly publish the same change again.

Refresh and finish. Invalidate the affected document and draft caches and notify editors so completed work is visible without a manual reload.

Recover on failure. Return the attempt's error to the coordinator. It schedules another attempt or keeps the action available for user attention. Approved child-deletion jobs use their own revalidation and deletion path; a card-removal job never becomes permission to delete a document.

The persisted job includes its identity and operation, structured source/destination IDs, signing context, failure count, next retry deadline, last error, timestamps, and any verified parent-publication checkpoint. Destructive jobs also retain approval scope and the authorizing parent version. Capture the original document locations so a later retry cannot silently follow a moved child. Derive the hierarchical parent from those captured locations; store a separate container only when it is genuinely different.

These are eligibility deadlines, not exact execution times. Another job, a closed app, or unavailable storage can delay progress. The failure counter records failed attempts, not execution starts. Unsafe or unprovable outcomes may require attention without exhausting ordinary retries.

Desktop stores the queue in its local application store; web stores queue records and commands in browser storage and keeps drafts in the web draft database. On restart, restore records and deadlines, replace interrupted execution with fresh attempts, and re-read documents before acting. Dismissed records stay non-runnable. Browser storage clearing or a failed disk write is not recoverable merely because the workflow uses actors.

A self-query counts as a reference to all direct children, independently of its display limit, filters, or sorting. Replacing a card with that query must not propose deletion. Removing or retargeting the last published self-query requires examining its full direct-child scope and excluding children still referenced elsewhere in the parent's content. Adding and removing a never-published query alone does not authorize bulk deletion.

Deletion approval is tied to document identities, versions, and the reviewed subtree. Revalidate the authorizing parent, current references, and deletion scope before execution. Never follow a moved target or silently expand approval to new descendants. Restoring a dismissed destructive action requires fresh review and explicit consent.

Treat the published document and unpublished draft as separate layers:

Load the current published parent and calculate the reference-only correction.

Publish that correction against the published baseline, without including unrelated draft edits.

Verify and record the resulting parent version.

Rebase the draft's local changes onto that corrected baseline, preserving authored edits and reference-removal intent.

Save the rebased content, base blocks, dependencies, and maintenance revision together using the platform's concurrency checks. Clear block revision metadata when a block is changed.

Refresh parent and draft caches and notify mounted editors. Reconcile unsaved live edits rather than forcing a reload.

This is the logical equivalent of temporarily separating the draft edits, applying the correction, and restoring those edits—not a reason to destructively strip and rewrite the live draft on disk. If reconciliation is unsafe, preserve the user's work and surface the unresolved action.

For example, if a user deletes Child A's card in a parent draft and Child A is then renamed, the published parent must contain the corrected card while the draft must continue to omit it. Discarding the draft restores the card at the new path; publishing the draft instead requires reviewing Child A's deletion. The baseline and the draft express different, intentional states.

Invalidation is part of completion, not cosmetic cleanup. Refresh inactive web caches so back navigation loads the new parent, propagate changes across tabs/windows, and avoid hydrating a draft from cached content while its newer baseline is still loading. The document actor must accept a fresh parent version even while waiting for draft resolution.

This problem has a small number of explicit steps, asynchronous failures, partial completion, and restart boundaries. A state machine makes those transitions inspectable and testable: “parent published, draft still needs reconciliation” is a real checkpoint, not a boolean hidden in an exception handler. Job actors isolate individual attempts; the coordinator provides ordering and retry policy without a growing collection of timers and callbacks.

The important property is safe reconciliation on repeated attempts, not an exactly-once promise. Checking current references prevents duplicate cards. Publication checkpoints avoid unnecessarily repeating a successful parent update. Fresh validation keeps delayed retries from acting on stale destructive assumptions. Failures that cannot be resolved safely stop for review instead of being retried indefinitely.

A synchronous multi-document transaction would couple child publication to parent availability and does not match the current backend guarantees. A server-wide workflow platform would add infrastructure, cross-device ownership, and signing questions that local recovery does not need. Sharing a small coordinator and planners, while leaving I/O to adapters, is a proportionate fit for two apps that must apply the same rules under different storage and lifecycle constraints.