Clarify verification ownership in the implementation plan

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.