Inspect hosted assets against build manifests

docs/integrations/gitea.md

@@ -28,6 +28,24 @@ lookup cannot determine the result after a possibly successful write, the
 client returns an unknown outcome. Other HTTP failures retain their structured
 failure kind and status code.
 
+For a binary-producing release, the client can build a deterministic
+`SHA256SUMS` file from the declared artifact names and SHA-256 digests. Entries
+are sorted by filename and use the standard two-space separator. A source-only
+release produces no manifest.
+
+Asset inspection lists the release attachments, streams each declared existing
+file, and compares its SHA-256 digest. It reports each asset as matching,
+missing, conflicting, or unverifiable. Same-name attachments with different
+bytes are conflicts even when their reported size matches. An existing
+`SHA256SUMS` must exactly match the complete expected manifest; a subset or
+different manifest is a conflict. An unreadable attachment is unverifiable,
+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.
+
 The integration tests use a local HTTP fixture and assert request paths,
-payloads, authorization, and failure handling. They do not contact a live Gitea
-service or use real credentials.
+payloads, authorization, streaming comparisons, manifest handling, and failure
+handling. They do not contact a live Gitea service or use real credentials.

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 and finds or creates matching
-  stable release pages through the Gitea REST API.
+- `internal/gitea` verifies hosted source tags, finds or creates matching stable
+  release pages, and inspects existing 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–12 are complete; later stages remain pending.
+Status: In progress. Stages 1–13 are complete; later stages remain pending.
 
 Date: 2026-10-05
 
@@ -758,7 +758,7 @@ request paths, payloads, and authentication without using real credentials.
 
 ## Stage 13: Inspect asset and manifest content
 
-Status: Pending. Depends on Stage 12.
+Status: Complete. Depends on Stage 12.
 
 1. Generate the expected binary manifest from the declared build result. Add
    attachment discovery and streaming hash comparison of existing assets.

docs/roadmap/releasekit.md

@@ -2,11 +2,11 @@
 
 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 client is implemented,
-while asset delivery, 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.
+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
+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
 instructions, acceptance checks, and progress toward this target state.
 
@@ -57,8 +57,9 @@ 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 client is implemented; delivery orchestration remains planned. The
-separate public `buildinfo` package provides lightweight runtime version access.
+Gitea page and asset-inspection client is implemented; delivery orchestration
+remains planned. The separate public `buildinfo` package provides lightweight
+runtime version access.
 
 Each facade owns its public named types and documented contracts. Public
 operations, inputs, outcomes, errors, and callbacks express deliberately