In GDP, queueing and applying are separate facts. A queued patch has reached repository-scoped local intake after preflight, but local policy still decides whether material work waits for review or continues. Check fresh GDP and repository evidence before deciding what happened.
Know what queued means
The AI-facing submit_patch operation is an intake operation, not a direct file-write command. A normal accepted submission can report queued=true and applied=false. That means GDP accepted the candidate into repository-scoped local intake; it does not mean your working tree changed.
Patch Doctor preflight and queue admission are also different from apply. A candidate can be structurally safe enough to enter intake while still waiting for the local execution decision.
Queueing is not applying. A model message saying that the patch was sent or accepted is not proof that local files changed.
Check the local policy and exact repository
Confirm that the intended repository is still open in GDP Desktop and that you are looking at the same repository target that received the patch.
Inspect the incoming patch state for that repository instead of assuming the active tab is the original target.
Check the selected local policy. Active may leave material work waiting for direct review; eligible AFK, Custom, or Run Everything policy may continue only inside the permission envelope and safety rules that are actually enabled.
If the patch is still waiting, review or continue it through the local GDP workflow rather than resending the same change just to make the queue move.
Read evidence for the state that actually happened
Use fresh GDP state and current repository evidence to distinguish a waiting queue item from an applied patch or a failed attempt. Repository status and diff, patch/apply evidence, and any relevant check runs are stronger evidence than an earlier assistant message.
If preflight failed before intake, the result is a different state: queued=false, applied=false with diagnostic information. Fix or regenerate that patch instead of treating it as a waiting apply.
Waiting: the patch remains in intake and there is no fresh apply evidence.
Applied: fresh GDP/repository evidence shows the material change actually reached the working tree.
Verification pending or failed: the patch state and the check state are separate; read the relevant check-run evidence.
Uncertain: reconcile the exact operation before deciding whether a retry is safe.
Do not blindly submit the same mutation again
Network loss, delayed delivery, or an ambiguous result can make a material operation look unfinished from the AI side. GDP distinguishes safe-read replay from uncertain mutation recovery because repeating a mutation without reconciling its exact outcome can create duplicate or conflicting work.
When the outcome is uncertain, inspect the exact queue or operation evidence first. Continue from the first unproven step only after the previous attempt has been reconciled.
The safest recovery rule is not 'send it again.' It is 'find out what the exact previous operation did, then choose the next action from fresh evidence.'
