Run API-only recovery independently of consumer vendoring

This commit is contained in:
2026-11-03 00:05:32 +00:00
parent 16d1c072e3
commit cd08a2892a
6 changed files with 165 additions and 24 deletions

View File

@@ -454,13 +454,20 @@ failures without additional consumer release infrastructure.
command selecting that exact path. Partial records can explain missing
evidence. Earlier failures still report their saved path when available.
Successful publication reports the path without prescribing a recovery step.
4. Build the printed command from the running executable's absolute path and the
absolute record path, quoting each argument for the POSIX-shell runbooks.
This works for a directly built CLI and a Go-tool-launched cached executable
without assuming `releasekit` is on PATH or that the consumer registered a
tool directive. Quote apostrophes safely; print the command without executing
a shell. Explain in recovery guidance that operators can use their selected
supported CLI if the original executable is no longer available.
4. Prefer the consumer module's registered Go tool for the printed command.
API-only consumers use durable private module/checksum files under Git
metadata, with a separate bootstrap module root so consumer vendoring does
not govern tool resolution. Retain the selected requirements, checksums,
versioned replacements, and original locations of local replacements.
Consumers without a selected ReleaseKit dependency use the native executable
path. Select the absolute record path explicitly and quote every argument
for the POSIX-shell runbooks, including apostrophes. The command survives a
cold Go-tool executable's removal and launcher-owned metadata cleanup.
Explain how to use another selected supported CLI if an entry point becomes
unavailable.
**R14 follow-up completed:** API-only recovery uses an independent private module
root. R15 tracks cancellation and preparation-failure handling separately.
**Verification:** Extend existing publication CLI tests for the default, override,
recording warning with successful status, and original failed/unknown status.
@@ -468,6 +475,10 @@ Use a built CLI in an assembled test to execute the printed recovery command
and verify it selects the original record among retries/modules. Test shell
argument quoting with synthetic paths. Keep the existing module-selected Go-tool
launchers and source bootstrap working without adding consumer-owned recording.
Include an API-only consumer that vendors the library without declaring the CLI
tool; execute its handoff and verify source/vendor contents remain unchanged.
Exercise relative local replacements, versioned replacements, and ReleaseKit's
own source-module recovery entry point.
## Stage 8: Finish assembled coverage and canonical documentation
@@ -482,6 +493,8 @@ contracts and a short consumer recovery workflow.
coordinate cancellation/interruption without arbitrary sleeps. Remove or move
the local tag and change branch, HEAD, remote URLs, or transport settings
before later recovery. Cover root/nested tags and original-record selection.
Retain the assembled vendored API-only handoff coverage added for R14,
alongside cold registered-tool and temporary-launcher recovery.
2. Establish read-only behavior through resulting refs, worktree/branch state,
saved records, and controlled observations of candidate/hosted boundaries.
Reuse lower-level classification and codec tests. Tests use local remotes,

View File

@@ -604,6 +604,11 @@ correctness for these additional combinations.
## R14: Support recovery for vendored API-only consumers — P2
**Completed:** API-only recovery uses a private module root with preserved module
settings and relocated local replacements. Vendored API-only, relative/versioned
replacement, cold Go-tool, native handoff, and source-module entry-point tests
passed. Stage 7/8 instructions and consumer/internal guidance are updated.
**Relevant code:** `internal/gotool/recovery.go:95–107`; the command assembly in
`cmd/releasekit/main.go:126–145`. Affects Stage 7 and its Stage 8 coverage.