Focus the plan on the complete initial implementation

docs/roadmap/releasekit.md

@@ -141,14 +141,16 @@ source, using the same version and target selection.
 A common tag-triggered Woodpecker workflow can run ReleaseKit against the
 tagged source. Repository-local YAML should declare the pinned tool image and
 credentials; each repository's ReleaseKit configuration should declare its
-main package and target set. ReleaseKit can own version injection, cross-builds,
-checksum generation, and delivery. The source-only repositories can declare
-zero binary assets.
+delivery destination and any binary main package and target set. ReleaseKit can
+own version injection, cross-builds, checksum generation, and delivery. All
+projects should receive hosted Gitea
+release pages. Source-only repositories declare zero binary assets and deliver
+the committed release note without a binary build or checksum manifest.
 
-For projects that declare a hosted Gitea release, a shared delivery command
-could create or find the release for the tag, use the checked-in note, and add
-the declared assets and checksum manifest. A retry should inspect existing
-assets, verify matching content, add only missing items, and stop on a conflict.
+The shared delivery command should create or find the release for the tag,
+use the checked-in note, and add declared binary assets and their checksum
+manifest where applicable. A retry should inspect existing assets, verify
+matching content, add only missing items, and stop on a conflict.
 An existing checksum manifest must remain consistent with any later addition.
 The release and its attachments are separate remote operations, so partial
 delivery must be expected and reported clearly.
@@ -160,10 +162,11 @@ same bytes as a previously published file. Content comparison would be a
 reason to implement a shared Gitea delivery client rather than rely solely on
 the plugin's skip behavior.
 
-Requiring a hosted Gitea release for PromptKit, ConfigKit, or Notarius would
-add a deliverable and credentials to their current source-only policies. That
-decision can be made separately from standardizing delivery for projects that
-already publish hosted assets.
+Hosted pages are selected for source-only projects, including PromptKit,
+ConfigKit, Notarius, and ReleaseKit. Adoption adds a page deliverable and delivery
+credentials to their procedures while preserving successful tag publication as
+source completion. The initial implementation should support both page-only and
+binary delivery through the same facade and command.
 
 ## Failure states
 
@@ -187,13 +190,16 @@ or checks. Shared mechanics and their repeated tests belong in ReleaseKit.
 Application runtime code should obtain version information through `buildinfo`.
 Source-only libraries need no runtime import or automatic binary deliverable.
 Projects declaring binaries should use the common target selection and version
-injection; projects declaring hosted delivery should use content-aware retries.
+injection; hosted delivery should use content-aware retries for both page-only
+and binary releases.
 Existing published tags, notes, pages, and assets retain their historical contents.
 
 Consumer policy and procedure changes should describe the deliberately adopted
 standard and its compatibility impact. Adoption should demonstrate reduced local
-infrastructure and one coherent release model. The implementation plan owns
-pilot selection, migration order, and acceptance evidence.
+infrastructure and one coherent release model. The implementation plan owns the
+complete initial ReleaseKit implementation and its development evidence.
+Architecture review follows that implementation; broader testing and consumer
+migration steps will be chosen afterward.
 
 ## Reviewed implementations