Make delivery asset outcomes disjoint

docs/cli.md

@@ -105,7 +105,14 @@ build, or manifest. `deliver` never runs candidate checks or publishes a tag.
 The command returns 0 for complete delivery, 1 for a known failure, conflict,
 or partial delivery, 2 for usage, profile, or missing-credential errors, and 3
 when a remote write remains uncertain. The result lists matching, uploaded,
-pending, conflicting, and uncertain assets as available. Retry the same version
-with the same tagged source and destination; matching content is kept and only
-missing assets are added. See the [delivery consumer guide](consumers/delivery.md)
-and [Gitea integration guide](integrations/gitea.md).
+pending, conflicting, and uncertain assets as disjoint current observations;
+early failures may leave some declared assets unreported. On failure, the CLI
+prints state-based recovery guidance. Fix local or preflight failures before
+retrying; fix the reported cause before retrying partial delivery; resolve an
+unknown remote state before retrying; and investigate conflicts, using a new
+version if the source or published contents need correction. If rebuilding
+could change asset bytes already on the server, retain the original build
+artifacts and retry with `--assets DIR`. Matching content is kept and only
+known missing assets are added. See the
+[delivery consumer guide](consumers/delivery.md) and
+[Gitea integration guide](integrations/gitea.md).

docs/consumers/delivery.md

@@ -46,9 +46,19 @@ settings, and file hashes before making a remote request.
 
 The result reports `complete`, `partial`, `conflict`, `unknown`, or
 `not_attempted`, along with matching, uploaded, pending, conflicting, and
-uncertain assets when known. Exit status 3 means a remote write could not be
-resolved; inspect the same version and retry only after the remote state is
-understood. The command does not run candidate checks or publish tags.
+uncertain assets when known. These are disjoint current observations: an asset
+appears in at most one category, and early failures may leave some declared
+assets unreported. `Matching` means existing content matches; `Uploaded` means
+an upload was confirmed during this invocation; `Pending` means known missing
+work; `Conflicting` means different hosted content was found; `Uncertain` means
+the remote state could not be resolved.
+
+Fix local or preflight failures before retrying. For partial delivery, fix the
+reported cause and retry the same version. Resolve an unknown remote outcome
+before retrying. Investigate conflicts and use a new version if the source or
+published content needs correction. If rebuilding could change bytes already
+on the server, retain the original build output and retry with `--assets DIR`.
+The command does not run candidate checks or publish tags.
 
 ## Go API
 

docs/integrations/gitea.md

@@ -55,11 +55,14 @@ The upload operation accepts only an inspection result without conflicts or
 unverifiable assets. It uploads missing binaries in filename order and then the
 missing `SHA256SUMS`, using multipart field `attachment` and the filename query
 parameter `name`. Matching attachments are retained; unrelated and existing
-attachments are never overwritten or deleted. Results keep matching, uploaded,
-pending, conflicting, and uncertain identities separate. After an ambiguous
+attachments are never overwritten or deleted. Results use disjoint current
+observations: matching, uploaded, pending, conflicting, and uncertain. An asset
+moved from known missing work to another category is removed from `pending`;
+later known-missing assets can remain pending when an earlier upload stops the
+operation. Early failures may leave declarations unreported. After an ambiguous
 upload or an upload name conflict, the client performs one list and content
 check. It does not repeat the POST when the result is missing or cannot be
-verified, so a caller can retry with a new inspection.
+verified, so a caller can resolve the remote state before retrying.
 
 Uploads use the configured service origin and the same explicit token header.
 Source-only page delivery supplies no binary assets and creates no manifest.

docs/roadmap/implementation.md

@@ -1,6 +1,6 @@
 # ReleaseKit audit implementation plan
 
-Status: Stages 1–4 complete; Stage 5 not started.
+Status: Stages 1–5 complete; Stage 6 next.
 Baseline: `e4be7fa` (2026-10-06). The [audit](audit.md) records the evidence,
 product goals, and selected direction. This document owns implementation order
 and completion criteria for that work.
@@ -277,6 +277,14 @@ pending assets. Assert category exclusivity and meaningful overall state at the
 upload boundary. CLI tests verify recovery meaning and exit classification
 without freezing full diagnostic wording.
 
+**Completed:** Delivery asset categories now contain disjoint current
+observations, with later known-missing assets retained when an earlier upload
+stops work. CLI failures include state-based recovery guidance, while GoDoc and
+the delivery and Gitea guides describe category meaning and incomplete early
+observations. Upload and CLI tests cover reconciliation outcomes, recovery
+classification, and category exclusivity. The full offline suite, API boundary
+check, and documentation whitespace checks pass.
+
 ## Stage 6 — Give the facade ownership of build-and-deliver
 
 **Covers:** F5. **Primary owners:** `delivery.go`, `internal/delivery/`,