diff --git a/docs/roadmap/implementation.md b/docs/roadmap/implementation.md index 86db1ce..cb39d9d 100644 --- a/docs/roadmap/implementation.md +++ b/docs/roadmap/implementation.md @@ -52,13 +52,21 @@ this implementation. [testing policy](../policy/testing.md). Use local Git repositories, Go packages, controlled command doubles, and HTTP fixtures. Default tests remain offline and independent of real credentials or sibling checkouts. +- Verification lists describe required evidence, including existing tests. + Give each behavior a test owner: parser/checker tests cover syntax and rules; + candidate-tree and Git tests cover file access and resolution; conversion + tests cover each API/profile selection; shared orchestration tests cover + ordering, failure stopping, cancellation, and callback execution. Use + representative integration cases to verify these boundaries work together. + Add coverage where the change introduces a risk or leaves an evidence gap. - Prepare newly selected development dependencies before offline validation. Apply the [OSS policy](../policy/oss.md) when adding dependencies or adapting third-party material, including any required attribution and license texts. - Verify the focused outcome, stage its relevant changes, review the diff, and create a nonempty commit with a short plain English message. Preserve unrelated - work and continue to the next stage. These stages require local work and - automated checks; consumer changes in Stage 14 are committed in that repository. + work, report the stage's outcome and verification, and stop until the next + stage is requested. These stages require local work and automated checks; + consumer changes in Stage 14 are committed in that repository. ## Design carried through the stages @@ -389,9 +397,12 @@ Undefined references and HTML prose remain governed by parser interpretation. **Verification:** Valid/missing files and anchors, same-document/empty fragments, percent-escaped paths and fragments, query strings, directories and non-Markdown -files, absolute in-checkout paths, symlink-parent traversal and cycles, outside -links with both settings, submodule observations, neighboring files present/absent, -missing local Git objects, cancellation, and unchanged candidate/worktree bytes. +files, outside links with both settings, and submodule observations. Check how +resolver results and inspection errors become Markdown findings, preserving +causes and cancellation. Use representative committed-tree integration cases +and verify unchanged candidate/worktree bytes. Existing candidate-tree and Git +tests own detailed absolute-path, symlink-parent, cycle, neighboring-file, +missing-object, and traversal-cancellation cases. ## Stage 11: Expose Markdown selection and complete validation integration @@ -401,8 +412,9 @@ missing local Git objects, cancellation, and unchanged candidate/worktree bytes. Enable on a non-nil group/empty object and map the boundary boolean explicitly. 2. Wire the checker and nonfailure observations into the shared executor/output writer. Reuse existing facade/CLI diagnostic formatting and exit classification. -3. Update GoDoc, configuration, check/publish guides, CLI reference, internal - inventory, and maintained validation examples for all operational selections. +3. Document the newly operational Markdown selection in its canonical owners. + Review earlier stages' GoDoc, configuration, check/publish guides, CLI reference, + internal inventory, and examples for consistency across combined selections. 4. Use self-contained fixtures representing Audita defaults/artifacts, ConfigKit's race/vet/compilation, and PromptKit's shared settings plus example assertions. Document how consumers remove duplicate generic commands when adopting settings. @@ -444,14 +456,17 @@ fixture and instrument Go/transport operations. Prove wrong tag/commit stops before module resolution/build, a dirty module cannot select a different tool, the verified checkout selects the tool, module metadata and source remain unchanged, and the executable/temporary files are cleaned up. Tool metadata -preparation is separate from offline candidate checks. +preparation is separate from offline candidate checks. Include a representative +case that verifies invocation of the selected executable with the event arguments +and propagation of its exit status. Existing delivery tests own hosted behavior. ## Stage 13: Verify upgrades, retries, and bootstrap variants **Outcome:** Tool selection follows the triggering release across supported uses. -1. Add local module-proxy fixtures for two tool versions and tagged consumer - module configurations. Execute the maintained workflow body against both. +1. Extend Stage 12's bootstrap fixtures with a local module proxy for two tool + versions and tagged consumer module configurations. Execute the maintained + workflow body against both. Keep live infrastructure outside the default test suite. 2. Verify a retry of an older tag still selects that tag's module configuration when the default branch has upgraded. Include missing tool-only checksums and @@ -464,10 +479,11 @@ preparation is separate from offline candidate checks. retries, and the distinct tool/app artifact preparation steps. **Verification:** Two dependency versions, older-source retries, self bootstrap, -separately installed tool, source-only page delivery, binary delivery using a -local HTTP fixture, and preserved tag/commit/destination/state behavior. An -application without a declared ReleaseKit dependency uses the installed-tool -integration. +and separately installed tool, using the shared bootstrap fixtures. Existing +delivery and publication tests retain ownership of source-only pages, binary +delivery, destination handling, and publication states. Add integration coverage +for any new interaction introduced by bootstrap changes. An application without +a declared ReleaseKit dependency uses the installed-tool integration. ## Stage 14: Migrate Audita's local CI integration @@ -477,12 +493,15 @@ integration. Adapt `.woodpecker/release.yml` to the maintained module-based template, preserving its Go image, Gitea secret name, and release profile. 2. Retain its existing released ReleaseKit module selection for this migration; - that version already supplies `ci-deliver`. Align `scripts/release.sh` with - the selected bootstrap metadata approach and preserve native executable exit - behavior. Keep generated tool output outside the candidate source where needed. + that version already supplies `ci-deliver`. Make any necessary adjustments to + `scripts/release.sh` for the selected bootstrap metadata approach, preserving + arguments and native executable exit behavior. Keep generated tool output + outside the candidate source where needed. 3. Verify the consumer's actual wrapper/workflow using local tagged fixtures and - prepared module caches. Confirm matching selection and unchanged profiles, - source validation, binary targets, hosted page behavior, and source files. + prepared module caches. Confirm matching tool selection, preserved arguments + and exit status, and unchanged source files. Review the diff for preservation + of the release profile and binary targets. Existing consumer and ReleaseKit + tests retain ownership of source validation and hosted delivery behavior. 4. Commit the focused migration in Audita with a plain English message. Record its commit and local verification in this plan's implementation status.