Record ReleaseKit adoption review findings

2026-10-08 17:01:58 +00:00
parent f887fac809
commit ac90b9835b
1 changed files with 70 additions and 0 deletions
--- a/docs/roadmap/remediation.md
+++ b/docs/roadmap/remediation.md
@@ -0,0 +1,70 @@
+# ReleaseKit adoption review findings
+
+Reviewed commits `1917dcf` through `f887fac` against the
+[adoption roadmap](releasekit.md) and [implementation plan](implementation.md).
+The selected module, profile, validation sequence, and tag-only publication
+match the intended architecture. Address the following documentation findings.
+
+## 1. Preserve the captured endpoint during manual recovery (P2)
+
+Affected: [release procedure](../release.md#5-recover-from-a-failed-or-uncertain-tag-push),
+lines 180–199.
+
+The manual recovery command queries a literal URL without checking whether Git
+rewrites it. ReleaseKit v0.2.0's own recovery procedure verifies that the captured
+endpoint still resolves to itself before querying it. Without that check, the
+documented query can inspect a different repository and falsely establish that
+the published tag is absent. The runbook then permits deletion of the retained
+local tag and a retry based on that incorrect conclusion.
+
+Review reproduced this with two temporary bare repositories: the actual endpoint
+contained the published annotated tag; an `insteadOf` rewrite sent the runbook's
+query to a repository with the same `main` commit but no tag. The query succeeded
+and reported only `main`.
+
+Use the endpoint captured in the publication report and follow ReleaseKit's
+existing URL-resolution check before querying its refs, for example:
+
+```sh
+authoritative='COPY_CAPTURED_ENDPOINT'
+release_version='vMAJOR.MINOR.PATCH'
+test "$(git ls-remote --get-url -- "$authoritative")" = "$authoritative" &&
+  git ls-remote --refs -- "$authoritative" refs/heads/main "refs/tags/$release_version"
+```
+
+A failed equality check or query leaves the result unresolved. Retain the
+existing bounded recovery and confirmed-absence requirements. Verify this
+correction with a temporary URL-rewrite fixture; it adds no recurring release
+gate or ConfigKit-owned recovery implementation.
+
+## 2. Remove the unsupported prohibition on `go tool` (P3)
+
+Affected: [release procedure](../release.md#1-select-go-and-prepare-the-tool),
+lines 84–86.
+
+The runbook prohibits both `go run` and `go tool` on an exit-status rationale.
+That rationale applies to `go run`, but the review's Go 1.26.8 invocation
+`GOTOOLCHAIN=local GOPROXY=off go tool releasekit publish invalid` returned
+ReleaseKit's status 2 and its publication diagnostics unchanged. The blanket
+`go tool` prohibition unnecessarily extends the selected native-executable
+workflow into an unsupported restriction.
+
+Keep the documented temporary executable build and publication commands.
+Remove `go tool` from the prohibition and explain the exit-status limitation
+specifically for `go run`. No additional execution mode or test matrix is needed.
+
+## 3. Reconcile completed implementation status (P3)
+
+Affected: the adoption roadmap's opening status and final migration-verification
+bullet, and the implementation plan's opening status.
+
+All seven stage headings are marked complete, but the plan still says
+"Status: Planned" and the roadmap says isolated fixture verification remains
+unfinished. The final two commits identify that verification as completed;
+this review also reproduced validation failure without a tag, successful
+annotated-tag publication with each selected gate once, and wrong-endpoint
+rejection before any Go validation or tag creation.
+
+Mark the documents complete and describe the verification as completed.
+Keep retirement during release preparation under the existing release policy.
+Do not add a permanent migration-verification gate.