From 0fc00039bd98f497401d6cc73e9990ecf9763780 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Wed, 4 Nov 2026 02:38:06 +0000 Subject: [PATCH] Update ReleaseKit adoption plan after remediation --- docs/roadmap/releasekit-v0.9.0.md | 93 +++++++++++++++++-------------- 1 file changed, 50 insertions(+), 43 deletions(-) diff --git a/docs/roadmap/releasekit-v0.9.0.md b/docs/roadmap/releasekit-v0.9.0.md index 96740f7..5303b61 100644 --- a/docs/roadmap/releasekit-v0.9.0.md +++ b/docs/roadmap/releasekit-v0.9.0.md @@ -1,8 +1,8 @@ # ReleaseKit v0.9.0 adoption -Status: proposed maintenance roadmap; no implementation has started. Upgrade -scope is defined below. The scheduling of existing local corrections remains -open under OD-1. This document does not authorize source or hosted publication. +Status: R1 and R2 remediation is complete in separate commits. ReleaseKit v0.9.0 +adoption and the completion assertion repair remain planned; the root tool still +selects v0.8.0. This document does not authorize source or hosted publication. ## Purpose and authority @@ -20,7 +20,9 @@ and owning package tests until implementation updates them. ## Current baseline and review evidence -CommandKit baseline: `98e7e9933353cf43f2be4a96cb0436a0bce068d2`. +Current CommandKit baseline: `4d92ee4ee6a8403b22a4172e0f04face802b9499`. +The original upgrade review used `98e7e9933353cf43f2be4a96cb0436a0bce068d2`; +its findings and validation history are retained below. - The root [module](../../go.mod) selects `go.maximumdirect.net/releasekit v0.8.0` as a Go tool. Its selected version @@ -32,8 +34,11 @@ CommandKit baseline: `98e7e9933353cf43f2be4a96cb0436a0bce068d2`. - All three profiles already select the agreed generic file checks, forbidden token path, and page-only Gitea destination. Source publication and hosted delivery are separate operations. The local token directory remains ignored. -- [R1 and R2](remediation.md) remain open: legacy selector/raw-command collisions - and loss of optional POSIX-shell handling in launcher tests. +- [R1 and R2](remediation.md) are complete. Commit `7eac3fe` rejects invalid + legacy selectors before invoking Go; commit `4d92ee4` restores explicit, + optional POSIX-shell invocation in launcher tests. The remediation record owns + their acceptance evidence, including passing focused tests, shell syntax + checks, and profile assertions running when no shell is available. - Both integrations still require older published CommandKit dependencies than their current source needs. The completed [implementation record](implementation.md) distinguishes workspace-backed tests from independent release readiness. @@ -57,6 +62,13 @@ A disposable CommandKit upgrade changed only the selected ReleaseKit version in workspace-backed integration suites passed, and the real helper reported v0.9.0 under foreign target settings. No production publication or delivery was run. +A later disposable review at `7eac3fe` confirmed that downloading and tidying +v0.9.0 changed only the ReleaseKit requirement and its checksum entries. The +offline root suite and both workspace-backed integration suites passed with +Go 1.26.8, and the helper reported v0.9.0 under Windows/ARM64 target settings. +That snapshot excluded the then-uncommitted R2 change; it does not replace +validation of the eventual adoption commit. + The initial upgrade run failed in [`TestCompletionCommandContext`](../../completion_context_test.go). The same alias-order failure reproduced four times in 30 focused repetitions on the @@ -99,14 +111,16 @@ Integration attribution describes its own selected published dependency graph; update it only if that actual selection changes. No license-text replacement is needed for the unchanged upstream texts. -### Local correctness work +### Completed remediation and remaining correctness work -R1 and R2 keep their scope and acceptance evidence in [remediation.md](remediation.md). -The dependency upgrade does not close either finding. Subject to OD-1, address -them in the same maintenance effort while retaining the simplified test boundary -and the legitimate raw helper commands. +R1 and R2 were delivered before the dependency upgrade, with their completion +markers and acceptance evidence in [remediation.md](remediation.md). Preserve +their selector rejection, legitimate raw helper forms, and optional-shell test +boundary during adoption; no further implementation of those findings remains. -Also correct the completion test's incidental ordering assumption. Compare the +The completion test's incidental ordering assumption remains unresolved and is +separate from the completed remediation findings. Correct it in its own +reviewable commit within the remaining maintenance work. Compare the expected alias source/target records without depending on their iteration order, while still detecting missing, unexpected, or duplicate records. Sorting test-owned copies is one straightforward approach. Preserve the other routing @@ -115,8 +129,14 @@ a new internal alias order merely to make this assertion pass. ## Work needed -- [ ] Record the chosen maintenance scope for OD-1. Keep the upgrade and each local - correction reviewable, whether delivered together or separately. +- [x] Complete R1 in its own commit (`7eac3fe`), recording verification in + [remediation.md](remediation.md). +- [x] Complete R2 in its own commit (`4d92ee4`), recording verification in + [remediation.md](remediation.md). R1/R2 scheduling is resolved by their delivery + before adoption. +- [ ] Repair the completion assertion's ordering assumption and verify the + correction with focused repetitions. Preserve production ordering behavior + and the remaining routing assertions. - [ ] Select the root tool at v0.9.0, tidy module metadata, and inspect the actual `go.mod`/`go.sum` diff. Investigate unexpected version changes rather than accepting unrelated upgrades. Use normal cache preparation; direct @@ -126,9 +146,6 @@ a new internal alias order merely to make this assertion pass. entry in `docs/oss/attribution.md`. Check affected source links and fragments at the v0.9.0 commit. Update the earlier feature roadmap's pending-request statement while retaining its historical evidence. -- [ ] For bundled correctness work, implement R1 and R2 and the completion - assertion repair, with focused verification of the defects. Close existing - remediation findings only when their stated behavior has been verified. - [ ] Validate the actual upgraded helper with inherited foreign target values, and run the owning offline suites with Go 1.26.8. During development, use focused repetitions to check the completion repair; do not treat rerunning @@ -156,32 +173,22 @@ v0.9.0 for the host, aligned current documentation and attribution, and recorded validation of the final source. The reviewed upgrade introduced no other module version change; verify rather than assume that result during implementation. -If local corrections are bundled, completion also includes R1/R2 acceptance -evidence and a stable, order-independent completion assertion. If delivered -separately, report those items as outstanding rather than implying that adoption -resolved them. Independent integration dependency alignment remains separate -release-preparation work; this roadmap selects no future versions or sums. +R1/R2 acceptance evidence is complete in the remediation record. Completion of +the remaining maintenance work also includes a stable, order-independent +completion assertion and validation that the adopted helper retains the +corrected launcher behavior. Independent integration dependency alignment +remains separate release-preparation work; this roadmap selects no future +versions or sums. -## Open Decisions +## Sequencing after remediation -### OD-1: Bundle the existing local corrections with the upgrade? +The former OD-1 question about bundling R1/R2 with adoption is resolved: both +findings were corrected and committed separately before the upgrade. They are +neither open decisions nor remaining adoption tasks. -**Recommendation:** Deliver v0.9.0 adoption, R1, R2, and the completion assertion -repair as one focused maintenance effort, using separate reviewable commits as -appropriate. The existing issues are small, directly affect maintainer tooling -or the default suite, and otherwise leave misleading validation after a passing -upgrade run. Fixing the assertion without changing runtime ordering restores -useful evidence while keeping the requested contracts intact. - -This is a scheduling recommendation, not a requirement that every dependency -upgrade include unrelated repository repairs. It does not fold the older -integration dependency-version mismatch into this scope. - -**Viable alternative:** Land the tool and current-documentation updates first, -then deliver the three local corrections as separately tracked units. This -keeps the dependency change especially easy to review or revert and makes the -new recovery behavior available sooner. It leaves the known routing and test -issues active, so a passing upgrade run cannot be reported as resolution of -those issues or as proof of a consistently passing baseline. Keep their -follow-up explicit and apply existing candidate-validation requirements before -any actual source publication. +For the remaining work, repair the completion assertion, then adopt v0.9.0 and +align current documentation and attribution, keeping the test repair and tool +adoption reviewable as separate commits. Validate the resulting source and +record the actual evidence before marking adoption complete. A passing rerun +alone does not resolve the known nondeterministic assertion. The older +integration dependency-version mismatch remains outside this maintenance scope.