Publish the captured release tag

docs/consumers/check.md

@@ -32,3 +32,18 @@ A successful check is evidence about the local candidate only. It does not
 check whether a remote branch or tag is available and does not create a tag.
 The [`check` command](../cli.md) reads the product and optional validation
 commands from `releasekit.json`.
+
+## Publishing the source tag
+
+`releasekit.Publish` uses the same request and performs candidate validation,
+authoritative remote checks, annotated-tag creation, and an exact tag push. The
+selected remote must publish `main` at the captured commit and must not already
+contain the selected version tag. A successful result includes the endpoint and
+tag object ID. Publication states distinguish an unattempted push, a tag that
+was created locally but not pushed, a successful push, a guard conflict, and an
+unresolved push error.
+
+When a push reports an error, the local annotated tag is retained and the
+result is `unknown` until a later implementation adds authoritative
+reconciliation. Do not treat that state as success or proof that the remote
+lacks the tag.

docs/internal/overview.md

@@ -18,11 +18,14 @@ Implemented internal packages:
   its committed release note and local tag state, runs validation once, and
   rechecks mutable repository state.
 - `internal/git` resolves one effective push destination, applies it to a
-  command-scoped remote, and reads exact authoritative branch and tag refs.
+  command-scoped remote, reads exact authoritative branch and tag refs, and
+  creates and pushes exact annotated tag objects.
+- `internal/publish` coordinates local and remote guards around one validation
+  run and reports the publication state reached by that invocation.
 - `cmd/releasekit/internal/cli` parses implemented commands, loads strict JSON
   profiles, and adapts configured checks to the process runner.
 
 The executable controller uses the runtime facade and the command-owned CLI
 adapter. The adapter uses the process runner and imports neither public facade.
-Release orchestration, build, Git, and Gitea implementation packages are
-introduced as their responsibilities are implemented.
+The publication operation coordinates the candidate and Git packages. Build
+and Gitea implementation packages will be added as those responsibilities land.

docs/roadmap/implementation.md

@@ -591,7 +591,7 @@ and unchanged persistent config and refs.
 
 ## Stage 7: Create and push the exact annotated tag
 
-Status: Pending. Depends on Stage 6.
+Status: Complete. Depends on Stage 6.
 
 1. Implement public publication request/result values and explicit conversion
    into the engine. Validate once between the complete preflight guards.
@@ -609,6 +609,13 @@ cannot expand publication. Note content, tag identity, and one-validation
 behavior are checked through the public facade. Restrict stage trials to test
 remotes while failure handling is incomplete.
 
+Evidence: the public `releasekit.Publish` API captures the committed note,
+validates once between exact remote guards, creates an unsigned annotated tag,
+rechecks local and remote state, and pushes only the captured tag object. Bare
+remote tests verify the note bytes, peeled commit, tag object, unchanged branch
+and unrelated refs, disabled follow-tags and mirror expansion, validation count,
+remote conflicts, and retained local tags with `unknown` status after push error.
+
 ## Stage 8: Resolve rejected and ambiguous publication
 
 Status: Pending. Depends on Stage 7.