Resolve ReleaseKit workflow and validator selection

docs/roadmap/commandkit.md

@@ -304,7 +304,8 @@ integration acceptance. No additional upstream request was identified.
 
 ### Output-Failure Behavior
 
-This is decision 2 in the [master discussion order](library-adoption.md#open-decisions).
+This is the remaining open decision in the
+[master roadmap](library-adoption.md#open-decisions).
 Specify how failed transcript, report, debug-artifact, and standard reporter writes
 influence the process outcome. The existing visibility rules and prohibition on
 a successful completion summary after required-output failure remain selected.

docs/roadmap/library-adoption.md

@@ -4,7 +4,8 @@
 
 **Status:** Agreed direction with proposed sequencing. Initial outlines only;
 no implementation or dependency changes have been made for this plan. Resolve
-the two remaining [open decisions](#open-decisions) in the listed order.
+the remaining [output-failure decision](#open-decisions) before implementation
+planning. ReleaseKit workflow and validator selection are resolved below.
 
 ## Objective and Document Ownership
 
@@ -101,6 +102,7 @@ satisfied as recorded below:
 | `go.maximumdirect.net/commandkit` | v0.6.0 | `1613ff95cab60581de5d86f6e9e2a3cc091a44a0` |
 | `go.maximumdirect.net/ckconfig` | v0.6.0 | `5ed947bd26bf2c6d70d1d748b693eca89f18d605` |
 | `go.maximumdirect.net/ckprompt` | v0.6.0 | `1ca660e35fb58fc0dc318e411afb6e3631a40ef1` |
+| `go.maximumdirect.net/releasekit` | v0.9.0 | `2180aa868ec2caa95fc8279fd59d5f0ebac41bd4` |
 
 The integration tags are `integrations/ckconfig/v0.6.0` and
 `integrations/ckprompt/v0.6.0` in CommandKit's repository. Use the
@@ -117,11 +119,11 @@ records the API contract and review evidence. The selected release set removes
 the upstream availability blocker; Audita implementation and acceptance remain
 pending under the sequence below.
 
-ReleaseKit v0.9.0 at `go.maximumdirect.net/releasekit` is also a required target.
+The reviewed target dependency graph includes ReleaseKit v0.9.0, but Audita's
-The library graph already brings in that version, but Audita's direct tool still
+direct tool still uses old-path v0.4.1. The release, workflow, and validator review
-uses old-path v0.4.1. Direct adoption includes reviewing the v0.9.0 release and
+is complete, with no identified upstream blocker. The agreed
-validator APIs; the earlier integration checks do not establish its suitability
+[ReleaseKit adoption work](#releasekit-adoption-work) below remains to be
-for Audita's complete release workflow.
+implemented and accepted in Audita.
 
 ## Proposed Order of Operations
 
@@ -181,30 +183,82 @@ implementation stage is ready.
 
 ## ReleaseKit Adoption Work
 
-The concrete workflow and validator selection remain
+### Workflow and Validator Selection — Resolved
-[open decision 1](#1-releasekit-workflow-and-validator-selection).
 
-1. Review v0.9.0's supported release workflow, validators, and version integration.
+Adopt ReleaseKit v0.9.0's standard publication and asynchronous delivery workflow.
-   Inventory Audita's launcher, scripts, CI responsibilities, and local release
+This implements the ownership decision in [ADR 0001](../adr/0001-releasekit.md).
-   checks against those facilities. Select the best target workflow without
+Audita already delegates publication, builds, and delivery to ReleaseKit; the
-   preserving old invocation or validation behavior for compatibility.
+upgrade modernizes that integration and removes duplicated generic tests. No
-2. Move the direct tool and version integration to the new module identity.
+additional Audita-owned release validator or upstream feature request is needed
-   Replace local orchestration and validation with supported ReleaseKit facilities
+for the reviewed requirements. Audita's domain tests remain in the ordinary
-   wherever possible. Keep repository-specific configuration and necessary domain
+offline suite executed by ReleaseKit.
-   integration; remove redundant wrappers and checks.
+
-3. Select ReleaseKit-owned validators freely according to the desired workflow;
+The selected workflow is:
-   there is no numerical limit or presumption against adopting upstream checks.
+
-   For every retained local release validator, record its domain-specific purpose
+1. Prepare the release note and final committed candidate, then push that
-   and why upstream facilities do not satisfy it. Remove checks without that
+   candidate to the authoritative `main` branch.
-   justification, and propose reusable missing capabilities upstream.
+2. Use one ReleaseKit `publish` invocation to validate the candidate, check the
-4. Reconcile the release policy and runbook with the selected workflow as it lands,
+   required builds and version identity, and publish the annotated tag. Keep
-   including provisions that would otherwise restrict the chosen upstream
+   `check` available for diagnosis; do not require it before `publish` repeats
-   validators. Update CI, version reporting, and attribution as needed. The
+   validation.
-   current runbook is a baseline to replace, not a compatibility constraint.
+3. Use the maintained Woodpecker tag-delivery workflow to invoke `ci-deliver`
-5. Verify the selected validators, version identity, and release orchestration
+   from the tagged source. Deliver the hosted release page, Linux amd64 and arm64
-   through non-publishing checks. Cover any justified domain validation and verify
+   binaries, and checksums asynchronously. Successful tag publication completes
-   that removed local checks are no longer duplicated around upstream validation.
+   the source release; report artifact delivery separately.
-   Adoption work does not authorize publishing a release.
+4. Use ReleaseKit's standard recovery commands and procedures for publication
+   and delivery failures, without a separate Audita recovery layer.
+
+Use the reviewed upstream [publication guide](https://forge.maximumdirect.net/base-layer/releasekit/src/tag/v0.9.0/docs/consumers/publish.md),
+[delivery guide](https://forge.maximumdirect.net/base-layer/releasekit/src/tag/v0.9.0/docs/consumers/delivery.md),
+and [configuration reference](https://forge.maximumdirect.net/base-layer/releasekit/src/tag/v0.9.0/docs/config.md)
+for standard behavior. Select these checks through the native release profile:
+
+| Capability | Selection | Reason |
+| --- | --- | --- |
+| Standard offline Go test suite and candidate/publication guards | Retain ReleaseKit's built-in checks | Validate Audita's behavior and the exact source being published. |
+| Race detection | `validation.go.race: true` | Audita's concurrent processing and cancellation warrant race detection in the single standard suite. |
+| Full Go vet | `validation.go.full_vet: true` | Add static checks; ReleaseKit disables test-time vet to avoid duplication. |
+| Go formatting | `validation.go_format: true` | Enforce consistent formatting through the shared implementation. |
+| Local Markdown links and heading references | `validation.markdown: {}` | Protect documentation navigation using upstream defaults. |
+| Committed workspace files | `validation.module_distribution.workspace_files: true` | Keep development workspace files out of releases. |
+| Filesystem module replacements | `validation.module_distribution.local_replacements: true` | Prevent releases depending on local dependency checkouts. |
+| Application builds and version identity | Retain `build.targets` for `linux/amd64` and `linux/arm64`, with ReleaseKit's native version check | Verify the required production binaries and their embedded version. |
+| Additional compile-only targets | Omit `validation.go.compile_targets` initially | Limited additional value alongside the required application builds. |
+| File-size limits | Omit `validation.file_size` initially | No application-specific size ceiling has been selected. |
+| Forbidden-file paths | Omit `validation.forbidden_files` initially | Delivery uses the existing CI secret; no release-token file is configured. |
+
+Do not duplicate these checks in profile `checks`, custom release hooks, or
+surrounding scripts. Any future local release validator requires a documented
+domain-specific justification; reusable gaps should be addressed upstream.
+
+### Required Implementation and Acceptance
+
+1. Migrate the direct tool declaration and runtime `buildinfo` import together
+   to `go.maximumdirect.net/releasekit` v0.9.0 so build-time version injection
+   and runtime reporting use the same implementation. Remove superseded direct
+   dependencies and tool registrations.
+2. Update the launcher and Woodpecker workflow from the v0.9.0
+   [adoption recipes](https://forge.maximumdirect.net/base-layer/releasekit/src/tag/v0.9.0/docs/consumers/adoption.md)
+   and [tag-delivery template](https://forge.maximumdirect.net/base-layer/releasekit/src/tag/v0.9.0/examples/woodpecker/tag-delivery.yml).
+   Include Go host-platform selection and invocation by the full tool-package
+   path; a dependency upgrade alone does not update copied recipes. Keep only
+   necessary repository wiring around the maintained upstream workflow.
+3. Apply the selected checks in `releasekit.json`, add the required
+   `delivery.forge: "gitea"`, and retain Audita's product, production targets,
+   delivery destination, and CI secret mapping. Align local validation and CI
+   with the selected Go 1.27-or-newer toolchain. Include the C compiler and cgo
+   prerequisites required by race detection in the maintainer setup.
+4. Remove generic launcher and bootstrap tests already covered by ReleaseKit.
+   Retain focused checks for Audita's product settings, targets, destination,
+   and version integration. Reconcile the release policy and runbook with the
+   selected workflow and validator rationale as implementation lands; update
+   attribution and link to standard upstream recovery documentation.
+5. Verify the selected validators, both production builds, version identity,
+   and assembled launcher/CI wiring without publishing a release. Confirm that
+   removed local checks are no longer duplicated around upstream validation.
+   Hosted-delivery integration remains implementation acceptance work; the
+   disposable local check below does not establish it. Adoption work does not
+   authorize publishing a release.
 
 ## Shared Evidence, Validation, and Completion
 
@@ -222,6 +276,11 @@ contracts. Disposable checks using Go 1.27.3 established:
   covering debug capture, reporting-mode ordering, aliases, and quiet transcript
   destination validation. The assembled graph retains the selected ConfigKit and
   PromptKit versions and brings in ReleaseKit v0.9.0.
+- A disposable Audita copy with the ReleaseKit tool and runtime version import
+  migrated to v0.9.0, and toolchain references aligned, passes the selected native
+  validators, Linux amd64 and arm64 builds, and the native version-output check.
+  This exercised local `check` only; no release was published and hosted delivery
+  was not exercised.
 
 These are review results, not implementation acceptance. They involved no live
 provider calls and do not prove migrated Audita behavior or cross-platform
@@ -250,35 +309,12 @@ and retain shared license texts. Do not copy upstream policy inventories.
 
 ## Open Decisions
 
-Work through these decisions in order. Recommendations below remain proposals;
+CommandKit release selection and ReleaseKit workflow/validator selection are
-the existing adoption principles remain in force. CommandKit release selection
+resolved above. One decision remains before implementation planning.
-is resolved in the dependency set above.
 
-### 1. ReleaseKit Workflow and Validator Selection
+### Output-Failure Behavior
-
-Inventory the current launcher, scripts, CI responsibilities, version integration,
-and local release checks against ReleaseKit v0.9.0. Select the concrete workflow,
-upstream validators, machinery to remove, and any remaining domain-specific
-checks. ReleaseKit adoption and its target version are already agreed.
-
-**Recommendation:** use the upstream-supported release workflow to own as much
-orchestration and validation as it supports. Select all ReleaseKit-owned validators
-appropriate to Audita's release requirements, and retain local validation only
-with a documented domain-specific justification. This directly reduces Audita's
-maintenance burden and follows the suite's standard path. The inventory must
-establish which facilities cover the current responsibilities and whether an
-upstream request is needed.
-
-**Alternative:** let CI explicitly sequence ReleaseKit commands through a thin
-repository-owned orchestration layer where the upstream workflow cannot express
-Audita's required scheduling or platform coordination. Validation still belongs
-upstream except for justified domain checks. This can fit concrete CI needs but
-retains local sequencing to maintain; prefer an upstream enhancement for a
-reusable gap rather than permanently duplicating release machinery.
-
-### 2. Output-Failure Behavior
 
 Resolve the [output-failure decision](commandkit.md#output-failure-behavior) in
-the CommandKit roadmap after the ReleaseKit selection above. That document owns the
+the CommandKit roadmap. That document owns the recommendation, alternative, and
-recommendation, alternative, and behavior contract. This decision completes the
+behavior contract. This decision completes the
 remaining write-failure detail before implementing the output/reporting boundary.