Plan the release audit implementation

docs/roadmap/audit.md

@@ -1,7 +1,8 @@
 # ReleaseKit pre-release audit
 
 Date: 2026-10-06. Reviewed source: `536a57916f6565ae8194c4563577dfcebd6cfb69`.
-Status: review findings and proposed changes, revised for the clarified product goals.
+Status: historical review evidence and selected target direction for the
+[implementation plan](implementation.md).
 Audience: maintainers deciding the shared release standard before `v0.1.0`.
 
 ## Assessment
@@ -115,8 +116,8 @@ configuration. Preserve caches and legitimate dependency preparation settings.
 Share internal Go-environment handling where the semantics match. Preserve
 the settings appropriate to native tests and static release builds separately.
 Apply the same baseline to ReleaseKit's own profile. Retain a regression showing
-that a failing test remains effective under an ambient filter. F4 and Open Question 1 address how
-intentional product-specific checks should compose with this baseline.
+that a failing test remains effective under an ambient filter. F4 and Design
+Choice 1 describe how product-specific checks compose with this baseline.
 
 ### F2 — High: automatic push recovery can query a different endpoint and report false absence
 
@@ -174,7 +175,7 @@ settings that affect expected compatibility or validation. Keep the application
 profile focused on its package, binary name, and targets. Exact toolchain
 pinning and detailed build metadata remain optional operational choices.
 When a retry requires the original bytes, preserve and reuse those artifacts.
-Open Question 2 compares local toolchain use with a centrally maintained build
+Design Choice 2 compares local toolchain use with a centrally maintained build
 environment for consumers that benefit from shared setup.
 
 ### F4 — Design priority: adding a custom check replaces the entire standard suite
@@ -195,8 +196,8 @@ to preserve one suite run.
 product-specific checks. Move redundant suite invocations out of consumer scripts.
 Retain checks for actual product behavior, such as PromptKit's examples. Add
 alternative test-invocation settings when a concrete consumer requirement
-justifies them. This proposal changes the current customization contract; Open
-Question 1 records the replacement-callback alternative.
+justifies them. This choice changes the current customization contract; Design
+Choice 1 records the replacement-callback alternative.
 
 ### F5 — Design priority: the CLI owns reusable tagged-build delivery orchestration
 
@@ -219,7 +220,7 @@ source before expensive compilation, then retain the necessary checks before
 remote effects. Let the CLI adapt JSON, credentials, and output to that operation.
 Use the same build declaration for candidate validation and delivery. Support
 caller-provided builds for concrete needs such as retrying with retained
-artifacts, as discussed in Open Question 3. Keep separate building useful for
+artifacts, as discussed in Design Choice 3. Keep separate building useful for
 local development. The ordinary consumer workflow should complete delivery in
 one invocation; advanced artifact handoffs can use private coordination data
 when needed.
@@ -241,11 +242,12 @@ publication and CI delivery.
 **Recommendation.** Provide one maintained integration entry point and one
 default delivery sequence for source-only and binary profiles. Consumers select
 the ReleaseKit version, supply product settings, and provision credentials.
-Centralize installation and update instructions. Choose source installation or a
-maintained image according to the setup and maintenance effort each saves.
+Centralize installation and update instructions. Use versioned source
+installation for the shared CI command. Evaluate a maintained image by the
+additional setup and maintenance effort it saves.
 Keep dependency preparation separate from offline validation/builds. A split
 build/delivery flow remains useful for an actual credential boundary or artifact
-handoff. See Open Question 4 for packaging alternatives.
+handoff. See Design Choice 4 for packaging alternatives.
 
 `TestWoodpeckerDeliveryCommandSequences` in
 [the CLI workflow tests](../../cmd/releasekit/woodpecker_test.go) executes
@@ -276,9 +278,8 @@ reporting and automation.
 **Recommendation.** Prefer mutually exclusive current-outcome categories:
 confirmed matching, uploaded, known pending, conflicting, and uncertain. Move an
 asset out of pending when its outcome becomes uncertain or conflicting, and
-clarify the facade GoDoc. Alternatively, explicitly define pending as a superset
-of all unfinished assets and implement that rule consistently; see Open
-Question 5. Update behavioral tests to protect the selected meaning.
+clarify the facade GoDoc. Design Choice 5 records the alternative superset
+interpretation.
 
 ### F8 — Maintainability: artifact rules have several implementation owners
 
@@ -301,7 +302,7 @@ from receipt and delivery adapters. Share Go invocation/environment construction
 where the semantics match. Keep the explicit facade conversions required
 by the ADR. Focus refactoring on the small internal helpers that own these rules.
 
-## Recommended standard and release sequencing
+## Target state
 
 Retain the existing source transaction: committed stable-version note, clean
 `main`, candidate already on authoritative `main`, one validation, selected-target
@@ -316,31 +317,24 @@ ReleaseKit owns the standard suite, routine build settings, delivery sequence,
 and recovery reporting. Product developers choose versions and write
 compatibility notes. Evaluate each proposed setting by the work it saves them.
 
-Recommended order:
-
-1. Fix F1–F2 and retain focused behavioral regressions before tagging `v0.1.0`.
-2. Settle the validation and delivery API choices in Open Questions 1 and 3.
-   Adopt clear result categories under Question 5. Implement the selected
-   changes with their canonical documentation and consolidate F8 in those owners.
-3. Address F3 through internal compatibility defaults, using Open Question 2 to
-   keep build configuration proportionate to actual consumer needs.
-4. Exercise one source-only consumer with an extra product check and one binary
-   consumer through the common integration. Measure removed scripts, duplicated
-   tests, setup steps, and recurring release decisions. Keep ReleaseKit's default
-   suite independent of sibling checkouts.
-5. Choose the simplest shared installation and update path under Open Question 4.
-   Verify the maintained integration during deployment preparation. Follow the
-   existing maintainer procedure for the release note and source publication;
-   report hosted delivery separately.
+The [implementation plan](implementation.md) owns the stages, API changes,
+regression coverage, and completion criteria needed to reach this target.
+Representative adoption should demonstrate fewer scripts, duplicated tests,
+setup steps, and recurring release decisions.
 
 Feature expansion should follow demonstrated consumer needs and measurable
 reductions in application maintenance or developer effort.
 
-## Open Questions
+## Design Choices
+
+The implementation plan selects the recommended directions below for the
+upcoming sprint. Alternatives record the tradeoffs for future consumer needs.
+These choices describe the target behavior; current contracts change as their
+implementation lands.
 
 ### 1. Should product checks supplement or replace standard validation?
 
-**Recommended:** Run the shared offline Go suite once, followed by optional
+**Selected direction:** Run the shared offline Go suite once, followed by optional
 product-specific checks. ReleaseKit owns the command and its routine environment
 settings. Migrate repeated suite invocations out of application scripts. Add
 alternative invocation settings when an actual consumer requirement establishes
@@ -356,8 +350,8 @@ specific consumer need.
 
 ### 2. How should ReleaseKit choose build settings?
 
-**Recommended:** Use the available compatible Go toolchain, ordinary baseline CPU
-settings, and shared build flags. Handle incidental environment settings internally
+**Selected direction:** Use the available compatible Go toolchain, ordinary
+baseline CPU settings, and shared build flags. Handle incidental settings internally
 so developers can rely on the selected target's expected compatibility. Keep
 application configuration small. Toolchain-dependent byte differences are
 acceptable; digest checks preserve existing published content, and retained
@@ -373,7 +367,7 @@ Explicit hardware variants can be added for a demonstrated product need.
 
 ### 3. Should the library own build-and-deliver, or accept only completed builds?
 
-**Recommended:** Provide one facade operation for tagged-source verification,
+**Selected direction:** Provide one facade operation for tagged-source verification,
 selected-target builds, temporary storage, checksums, uploads, and cleanup.
 Use it from the CLI so both interfaces share the procedure. Retain separate
 building for local development and support prebuilt delivery where a concrete
@@ -389,11 +383,13 @@ operational separation they need.
 
 ### 4. How should the shared executable and CI integration be distributed?
 
-**Recommended:** Choose the simplest maintained entry point for installation,
-updates, and delivery. Begin with versioned source installation if it keeps
-consumer integration small. Centralize reusable setup and provide one clear
-upgrade procedure. Applications should select a ReleaseKit version and supply
-product settings and credentials; shared integration should own routine setup.
+**Selected direction:** Choose the simplest maintained entry point for installation,
+updates, and delivery. Use versioned source installation and a shared CI delivery
+command. The command prepares the tagged checkout, reads its product profile,
+prepares dependencies for selected binaries, and invokes ordinary facade delivery.
+Centralize reusable setup and provide one clear upgrade procedure. Applications
+select a ReleaseKit version and supply product settings and credentials; shared
+integration owns routine setup.
 Assess packaging by the consumer code and recurring developer work it removes.
 
 **Viable alternative:** Publish a maintained CI image containing ReleaseKit and
@@ -405,7 +401,7 @@ applications a small configuration and a routine invocation.
 
 ### 5. How should delivery results support simple recovery?
 
-**Recommended:** Use exclusive outcome categories: matching, uploaded, known
+**Selected direction:** Use exclusive outcome categories: matching, uploaded, known
 pending, conflicting, and uncertain. Present ordinary callers with completion or
 a clear failure and recovery instruction. Keep asset details available for
 diagnostics. Derive recovery guidance centrally so each application can present