Queued, delivered, policy-blocked, pending, failed, skipped, and completed are different Suggested Check states. Read the exact bundle and material run evidence before deciding whether the problem is the command, target repository, local policy, environment, or code under test.
Start with the Suggested Check bundle, not the last message
Read Suggested Check metadata for the exact repository. GDP can show bundle status, counts by check state, the first pending check, latest run identity, and latest exit code without executing anything.
A delivered bundle can remain active after one check fails while later checks are still pending. When the remaining tail resolves, the final bundle can become failed while preserving individual passed, failed, and skipped results.
pending means runnable or manually reviewable work remains.
failed means at least one material check recorded a non-success result.
skipped is not the same as passed and cannot prove patch verification success.
completed can include a check closed without a material run; inspect its run evidence before treating it as a passing test.
Read the exact run when a command actually executed
Use last_run_id or the relevant check-run identity to read the exact GDP-recorded result. Compact list views intentionally bound and privacy-mask output; the detailed run view exposes the stored stdout and stderr for a command the local GDP user already ran, subject to privacy masking.
Interpret exit code and output together. A nonzero result can represent a product or test failure, missing executable, malformed command, guard failure, or another environment problem; the bundle label alone does not diagnose which one.
A newer successful run can make the latest outcome green while GDP retains an earlier failure for history. Distinguish current failure from a prior failure instead of treating any historical red run as current truth.
If it did not Auto-Run, inspect policy and target state
Submitting Suggested Checks through the bridge queues structured verification work for GDP Desktop; it does not execute commands remotely. Safe headless verification patterns can Auto-Run under eligible local policy, while unknown, network-required, file-modifying, higher-risk, or foreground-only checks can remain manual or blocked from AFK Auto-Run.
Delivery is repository-scoped. If the intended repository is not open in GDP, Desktop does not silently execute the check against another repository. Reopen or select the exact target and refresh current bundle state instead of guessing a path.
A policy block can leave a check pending and visible for explicit Run or Run All.
A duplicate pending check with the same command and cwd can be skipped instead of being added twice.
Changing command or cwd means the result is no longer the same planned check for normal matching purposes.
Foreground-only checks stay user-controlled even under broader automation.
Fix the right layer, then verify with a fresh run
If the command is malformed or the environment is missing a dependency, correct the command or environment. If the command is valid and its output demonstrates a real test or compile failure, fix the code. If the issue is stale or duplicate check state, reconcile the current bundle instead of repeatedly submitting the same suggestion.
After the corrective step, run the exact intended check again and read the new run ID, exit code, and output. Do not infer success merely because a check disappeared from the pending list or a newer bundle was delivered.
For patch-attached verification, failed, skipped, pending, or otherwise non-terminal material work cannot be promoted to verified patch evidence.
