Upload missing Gitea release assets

docs/integrations/gitea.md

@@ -1,9 +1,9 @@
 # Gitea release pages
 
-ReleaseKit's internal Gitea client verifies a hosted source tag and finds or
-creates its stable release page. The public delivery facade and CLI workflow
-are planned separately; this integration guide describes the implemented
-internal operation.
+ReleaseKit's internal Gitea client verifies a hosted source tag, finds or
+creates its stable release page, inspects existing assets, and uploads missing
+assets. The public delivery facade and CLI workflow are planned separately;
+this guide describes the implemented internal operations.
 
 The caller supplies the Gitea base URL, owner, repository name, and token
 explicitly. The client does not read ambient credentials. The token is sent in
@@ -43,8 +43,20 @@ not missing. Unrelated attachments are returned separately and are preserved.
 
 Attachment downloads and same-origin redirects carry authorization only when
 their scheme, host, and port match the configured Gitea service. Cross-origin
-URLs and redirects are left unrequested and reported as unverifiable. Inspection
-uses GET requests only; uploads are a later delivery operation.
+URLs and redirects are left unrequested and reported as unverifiable.
+
+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
+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.
+
+Uploads use the configured service origin and the same explicit token header.
+Source-only page delivery supplies no binary assets and creates no manifest.
 
 The integration tests use a local HTTP fixture and assert request paths,
 payloads, authorization, streaming comparisons, manifest handling, and failure

docs/internal/overview.md

@@ -16,8 +16,8 @@ Implemented internal packages:
   overlays.
 - `internal/build` compiles explicit Go targets with shared version injection,
   verifies native version output, and returns generated file digests.
-- `internal/gitea` verifies hosted source tags, finds or creates matching stable
-  release pages, and inspects existing attachments through the Gitea REST API.
+- `internal/gitea` verifies hosted source tags, manages matching stable release
+  pages, and inspects and uploads declared attachments through the Gitea REST API.
 - `internal/candidate` captures and validates one clean local candidate, checks
   its committed release note and local tag state, runs validation once, and
   rechecks mutable repository state.

docs/roadmap/implementation.md

@@ -1,6 +1,6 @@
 # ReleaseKit staged implementation plan
 
-Status: In progress. Stages 1–13 are complete; later stages remain pending.
+Status: In progress. Stages 1–14 are complete; later stages remain pending.
 
 Date: 2026-10-05
 
@@ -775,7 +775,7 @@ by inspection tests.
 
 ## Stage 14: Upload missing assets and report partial delivery
 
-Status: Pending. Depends on Stage 13.
+Status: Complete. Depends on Stage 13.
 
 1. Add multipart uploads for missing binaries in filename order, followed by a
    missing manifest. Record completed work and pending asset identities.

docs/roadmap/releasekit.md

@@ -2,9 +2,9 @@
 
 This is a proposal based on a review of PromptKit, ConfigKit, Audita, Notarius,
 Narratio, and Scriptorium on 2026-09-29. The implementation plan records the
-current implemented boundary; the internal Gitea page and asset-inspection
-client is implemented, while asset delivery, facade/CLI integration, and
-broader integrations remain planned. The public facade architecture is
+current implemented boundary; the internal Gitea page and asset-delivery
+client is implemented, while facade/CLI integration and broader integrations
+remain planned. The public facade architecture is
 accepted in [ADR 0001](../adr/0001-public-facade.md) and is implemented for
 runtime version, candidate validation, and source publication.
 The [implementation plan](implementation.md) owns ordered stages, execution
@@ -56,9 +56,9 @@ cleanup.
 The [architecture policy](../policy/architecture.md) owns the adopted
 responsibility and dependency rules, including the runtime version boundary.
 The root `releasekit` package provides the public facade for candidate
-validation, source publication, and selected-target builds. The internal
-Gitea page and asset-inspection client is implemented; delivery orchestration
-remains planned. The separate public `buildinfo` package provides lightweight
+validation, source publication, and selected-target builds. Internal Gitea
+page and asset-delivery operations are implemented; facade and CLI orchestration
+remain planned. The separate public `buildinfo` package provides lightweight
 runtime version access.
 
 Each facade owns its public named types and documented contracts. Public