Verification as parent of code-review

[BjRo]

Motivation

Adaptive-delivery currently has detailed composition and convergence rules for code review. Broaden its interface to verification so code review, project-appropriate QA, and reviewer-facing evidence can cooperate through replaceable capabilities.

The goal is an explicit verification conclusion that accounts for every material acceptance criterion and makes unsupported claims or evidence gaps visible. Code review already checks acceptance criteria; the broader boundary adds composition and coverage across methods.

Target picture

Component	Responsibility
Adaptive-delivery and its active owner	Select required assurance, frame the goal, implement and repair, own the shared budget, continuation, and completion
Verification plugin	Coordinate selected assessments, combine their results and evidence, and request targeted follow-up verification
Code-review capability — required for the selected verification operation	Independently assess the implementation against acceptance criteria and engineering standards, and verify repairs
QA capability — optional	Exercise the system using methods appropriate to the project and independently verify behavioral repairs
Evidence capability — optional	Prepare a reviewer-facing explanation and useful artifacts for the delivered change

These remain separate, independently installable plugins. Verification discovers compatible capabilities by advertised intent and checks their behavioral contracts; it does not depend on a specific provider's identity, internal files, or installation. A compatible code-review replacement must work without redesigning verification.

Optional means not selected for every goal. Once a capability is required by the goal, its missing or incomplete result cannot silently count as success. Preserve the current review-selection policy during the structural work; a required review provider inside selected verification does not make review mandatory for every adaptive-delivery request.

Agreed convergence strategy

• The active owner remains the implementation and repair owner. Review and QA assessments run in fresh contexts and return findings and evidence.
• Collect all selected assessment results before starting a repair attempt. The owner addresses the combined eligible blockers together; assessments may run concurrently where practical.
• Keep a shared default maximum of two owner repair attempts across verification. Preserve explicit finite overrides and the strictest invocation, time, token, and authority limits.
• Each repair is followed by fresh verification against the original findings, attempted repairs, current candidate, and direct repair-caused regressions.
• Fresh context preserves the required finding history. Follow-up verifies that the fix actually worked and keeps the original finding set closed apart from direct repair-caused regressions.
• Clear current-content evidence ends repair immediately. Further attempts require material progress and remaining budget. Unchanged, unavailable, inconclusive, oscillating, or exhausted evidence cannot clear the goal.
• No additional repair controller, adaptive-delivery owner, or lifecycle ledger is introduced.

Delivery sequence

1. #154 — introduce the separate verification capability and compatible result/follow-up boundary, backed by existing code review.
2. #155 — route adaptive-delivery through verification and preserve owner-led convergence with combined findings and a shared budget.
3. #156 — add an optional fresh-context QA capability, including project-appropriate execution and targeted repair verification.
4. #68 — add optional reviewer-facing evidence packaging through the verification boundary.

The first two tickets establish the structure using existing behavior. QA and evidence follow that foundation; neither is necessary to deliver the structural slices, and they do not require a dependency on each other's implementation.

Acceptance criteria

• Adaptive-delivery consumes a verification contract, and the existing code-review capability remains independently useful and replaceable.
• The structural delivery preserves acceptance-criteria review, successful required checks, fresh assessment, closed findings, target-bound evidence, and existing convergence stop conditions.
• Selected verification produces an overall conclusion accounting for every material acceptance criterion, with honest limitations and missing evidence.
• QA can report observable behavior and feed repairs into the same owner and shared convergence budget.
• Evidence can help human reviewers consume the change package through useful project-appropriate previews, examples, and links under existing publication authority.
• Focused composition evidence covers a compatible replacement provider, review-only verification, missing required versus absent optional capabilities, combined findings, and repair outcomes on current content.

Sequencing boundaries and deferred detail

Existing findings, test results, and repair evidence remain necessary for verification. The later evidence feature is their curated presentation for human reviewers; it is not a prerequisite for the first structural delivery.

QA's initial project execution paths and the evidence capability's artifact formats, storage/retention, PR presentation, and required-artifact policy are elaborated in their own tickets. No always-required rich evidence package has been agreed.

Repository basis

• docs/design.md: plugins as optionality boundaries; explicit orchestration and intent-matched capabilities.
• docs/specs/layer-composition.md: compatible handoffs, one policy owner, and caller-owned continuation.
• docs/specs/adaptive-delivery.md: current assurance selection and budgeted closed-set repair.
• docs/specs/code-review.md: existing acceptance assessment, independent readers, and fix-verification evidence.