Add Gitea release page transport

docs/integrations/gitea.md

@@ -0,0 +1,33 @@
+# 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.
+
+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
+the `Authorization: token …` request header and is not included in errors or
+results. The base URL must use HTTP or HTTPS and cannot contain URL credentials,
+a query, or a fragment.
+
+For version `vMAJOR.MINOR.PATCH`, the client first reads
+`/api/v1/repos/{owner}/{repo}/tags/{tag}` and requires the hosted tag's commit
+SHA to equal the captured source commit. It then reads
+`/api/v1/repos/{owner}/{repo}/releases/tags/{tag}`. A matching existing page
+must have that tag, the complete committed release note as its body, and stable
+non-draft state. Its existing title is retained. ReleaseKit does not edit a
+conflicting page.
+
+If the page is absent, the client posts to `/api/v1/repos/{owner}/{repo}/releases`
+with the selected tag and commit, the release note's H1 as title, the complete
+note as body, and draft and prerelease disabled. A create conflict, interrupted
+response, or malformed create response triggers one lookup. An exact page found
+there confirms the existing content; a differing page is a conflict. If that
+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.
+
+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.

docs/internal/overview.md

@@ -16,6 +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/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.
@@ -30,5 +32,7 @@ Implemented internal packages:
 
 The executable controller uses the runtime facade and the command-owned CLI
 adapter. The adapter uses the process runner and imports neither public facade.
-The publication operation coordinates the candidate and Git packages. Build
-and Gitea implementation packages will be added as those responsibilities land.
+The publication operation coordinates the candidate and Git packages. The
+internal Gitea client is documented in the
+[Gitea integration guide](../integrations/gitea.md); delivery orchestration will
+use it when that facade and CLI work lands.

docs/roadmap/implementation.md

@@ -1,6 +1,6 @@
 # ReleaseKit staged implementation plan
 
-Status: In progress. Stages 1–11 are complete; later stages remain pending.
+Status: In progress. Stages 1–12 are complete; later stages remain pending.
 
 Date: 2026-10-05
 
@@ -736,7 +736,7 @@ no publication or consumer pilot is needed to complete this stage.
 
 ## Stage 12: Find and create Gitea release pages
 
-Status: Pending. Depends on Stage 11.
+Status: Complete. Depends on Stage 11.
 
 1. Implement the small internal REST transport using the served API operations,
    explicit destination/token inputs, context cancellation, and structured

docs/roadmap/releasekit.md

@@ -2,7 +2,8 @@
 
 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; delivery and broader integrations remain
+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.
@@ -55,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. Delivery remains
-planned. The separate public `buildinfo` package provides lightweight runtime
-version access.
+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.
 
 Each facade owns its public named types and documented contracts. Public
 operations, inputs, outcomes, errors, and callbacks express deliberately