Handle a timeout without blindly retrying a write

A timeout tells you that the caller did not receive a complete response. It does not establish whether the provider accepted the operation. Treat the outcome as uncertain until you inspect evidence. Creating a fresh request immediately can obscure the relationship between the original authorization and the resulting provider state.

Keep the exact original request identifier, repository, unique branch name, and existing commit SHA. Preserve the time of the attempt and the non-sensitive error context. Do not put access tokens, authorization headers, or private repository content into a public issue or shared worksheet.

First inspect Gated’s request status and available execution evidence through the supported preview workflow. Then inspect GitHub independently for the exact branch reference and commit. Use the same reviewed inputs for both checks, so a similarly named branch does not get mistaken for the requested result.

If the branch exists at the requested SHA, record that provider observation and reconcile it with the receipt. If it points elsewhere, preserve the discrepancy and ask the pilot owner to investigate before continuing. If it is absent or unreadable, that observation still needs to be reconciled with request status and any execution record.

• Record what Gated reports about the original request.
• Record the independent provider result and when it was checked.
• Classify the outcome as matched, mismatched, absent, or still unknown.
• Assign an owner before any further write attempt.

Gated’s verified staging evidence includes replay of an exact request returning the same execution. That evidence concerns the supported Gated request path. It is not a guarantee that every GitHub operation, client, network failure, or fresh request has generic provider idempotency.

When the supported workflow permits a retry, retain the original request and follow its replay behavior. Do not change the branch name, commit, or repository merely to get past an uncertain result. Changed inputs describe a new operation and require their own review. Do not blindly retry after a timeout.

Separate a simulated safe-mode result from a live GitHub result in the incident record. Runtime rehearsals can exercise the request and review flow, but they do not prove live writes from that runtime. The current controlled pilot covers one branch creation in a selected non-critical repository.

Close the record only when the pilot owner can explain the evidence and any remaining gap. An unresolved case is useful evaluation data. Count it in the pilot scorecard and document the next investigation step rather than reporting a successful execution from approval alone.