Candidate Ambiguous Release Reconciliation Protocol

Candidate Ambiguous-Release Reconciliation Protocol

This is a candidate refinement of REQ-082 and REQ-084, not a selected authority, private schema, GitHub capability, or implementation. Reuse the earlier continuity contract's distinction between durable intent, exact transaction identity, and fencing of a separate remote operation: committing or fencing a record in one authority does not itself cancel or fence a request already accepted by GitHub.

Bind a unique operation ID to the complete intended request and its expected authority head in independently protected state. The logical contents include the repository identity, full tag ref, candidate commit, effect kind, managed draft ID where applicable, workflow run and attempt, proof and policy identities, and applicable expected prior state. Exact encoding, canonicalization, custody, authentication, and retention are still unselected. Reusing an operation ID with different contents must fail; an exact authority-side repeat must not create another authority transition. Neither property alone makes a GitHub side effect idempotent.

Candidate state	Necessary evidence and recovery behavior
PREPARED	The exact intent is independently durable and recoverable. If its preparation response is ambiguous, reconcile it before any GitHub request.
MAY_HAVE_BEEN_SENT	Durably record this conservative state before dispatch. A crash even before the actual network send leaves the request UNKNOWN unless non-dispatch is independently proven; a missing local journal is not proof of no send.
OBSERVED	Authenticate and retain a response or remote observation, but do not equate an HTTP response, object name, matching SHA, or current absence alone with the exact request's terminal outcome.
TERMINAL_COMMITTED	Prove the exact attributable effect and its terminality, independently retain the result, and verify any required tag binding. An observed object is insufficient if an additional late effect remains possible.
TERMINAL_NO_COMMIT	Prove that the request was not sent, or that the provider definitively ended it without the effect, and that no late commit is possible. A missing object, incomplete inventory, or later conflict alone is insufficient.
CONFLICT or UNKNOWN	Preserve the obligation, block writes whose independence is unproven and any success report, and signal the operator. A confirmed conflicting effect is FAIL; an unattributable or nonterminal one remains UNKNOWN.

A new attempt after a proven terminal result must revalidate current readiness and retain the prior history. Retrying an ambiguous request requires proven same-intent idempotency and fencing at the actual remote effect, not merely deduplication in the independent intent store. Do not silently convert an UNKNOWN outcome into TERMINAL_NO_COMMIT when a deadline expires or an authority-side lease ends.

Two possible reconciliation approaches need separate feasibility proof:

1. Exclusive writer and attributable observation. Independently prove that no other actor or earlier accepted operation can create or alter the relevant draft, tag, or release throughout the interval; then prove the observed effect and terminality belong to this intent. The proof must cover combined draft/tag effects and all ways a late request can change repository-wide release state. A matching object is not attribution if the exclusion has a gap.
2. Provider-side idempotency and fencing. Prove that the provider binds the exact operation ID and payload to at most one effect and exposes authoritative terminal status or an effective fence. A transactional outbox or idempotent intent store outside GitHub does not by itself establish these provider-side properties.

Neither approach has been demonstrated. The inspected sources do not establish a GitHub idempotency key or a terminal-cancellation mechanism for these effects. In particular, if a timed-out request may still commit and no applicable fence is proven, a complete current read showing absence remains UNKNOWN and can block future managed releases indefinitely. This is a feasibility constraint, not permission to retry, guess a timeout, or modify live policy.