Report compatibility and recovery

Apply this assessment when a requested existing report fails lookup, validation or its next consumer, including an older result, an unpromoted candidate or a resumed remediation inventory. A version number selects a reader and its semantics; it is not evidence that the analysis must be repeated. Distinguish a presentation/consumer mismatch from missing source, provenance, coverage or verification. Record the exact diagnostic, usable evidence, missing proof and smallest feasible recovery in the owning run notes before asking the user.

• Validate supported historical representations under their original contract. Preserve exact source reports, reviewer outputs, role cards, receipts, judgments and attempt history. Never change a schema or presentation marker merely to pass admission, invent provenance, reinterpret historical verdict values as current values, or claim old checks cover changed source.
• Automatically repair deterministic derived presentation or bookkeeping when retained authentic evidence proves every required value. Remediation owns its inventory and rendered scope; Code Review owns its candidate, manifest derivations and finalization. Invoke the owning workflow at its first unmet checkpoint without a new permission question or a model rerun for cosmetics. Retain byte-exact pre-repair artifacts in the run's recovery evidence before regenerating derived files. For historical completed results, preserve the original report before writing a separate candidate; only normal successful validation and promotion may replace the canonical result. Never rewrite frozen dispatch, contexts, source receipts or raw reviewer output. Actual denied capabilities and bounded retry limits still apply.
• A schema-2 archive or another unsupported representation stays unverified while assessed through archive access. Inspect retained source/revision bindings, reviewer outputs, role cards, provenance and gate evidence to identify concrete missing proof; do not stop at its version or feed the archive directly into remediation. Existing valid evidence may support producer recovery only where the current validator can authenticate its original bindings. Never transplant evidence between runs or relabel an old response as a fresh review. If authentic retained evidence is sufficient, regenerate only derived artifacts through the producer and validate a current candidate; otherwise record the precise coverage that needs new work.
• On resume, keep usable source, reviewer, check and discussion evidence; rerun missing, stale or unverifiable work. When no retained evidence can be authenticated or reused and recovery would repeat the review, start a fresh review if +review or another existing authorization permits it; an explicit Resume choice retains its separate decision rule below. A retained plan that the current host cannot execute is historical evidence, not a requirement to repair the old protocol. Preserve its frozen records, then use the current producer to prepare the necessary reviewer work under the existing resume authorization. If immutable planning files require a separate continuation directory, retain the old run and carry only evidence the normal validators can still authenticate; new reviewer results get fresh real dispatch and completion evidence. Never rewrite old provenance or bypass source, permission or stopped-route limits. A new artifact directory alone does not require a full-review choice or discard usable work.
• Substantive work already authorized by +review or an explicit resume continues automatically at the first unmet checkpoint. When a genuine remaining decision requires the user, use Incomplete review decision below; do not substitute a copyable resume request or silently finish with limitations.

After automatic or authorized recovery, run both producer artifact validators, normal promotion and --complete-run, then the consumer's ordinary admission and preflight. Resume the waiting remediation at its first unmet checkpoint in the same turn; the nested delivery rule applies to recovered reviews as well as fresh ones. A repaired format does not close unresolved findings or missing review evidence. If recovery cannot establish completed-review proof, preserve the exact remaining diagnostic and use the requesting workflow's missing-review decision; safe independent work continues within existing authority.

For either decision branch, select the control through User Questions: permitted synchronous request_user_input first; otherwise discover and invoke the native ask_user form when exposed, permitted and suitable. Consider async or plain chat only after native eligibility is exhausted, following the shared rendering, lifetime and fallback requirements. This selection precedes both Continue/Skip and other recovery prompts; never choose chat merely because a workflow supplies question wording. Runtime permissions retain their dedicated mechanism.

Interrupted checks and missed ordering

A gate exceeding 15 minutes is not a blocker while observed test completions, advancing percentages or other concrete evidence shows progress toward its acceptance condition. The shared runner allows 7200 seconds (two hours) per gate by default; preserve explicit project/user limits. Keep the active run and report concrete progress at the host update cadence. Do not restart or terminate a progressing gate at 15 minutes. Silence alone proves neither progress nor a hang; inspect retained output and process evidence before diagnosing a stall. Logged test errors remain evidence to reconcile with the final summary, not a reason to discard the remaining run. The runner enforces elapsed time, not a progress detector; the parent owns progress assessment and earlier intervention for a proven stall.

For an interrupted gate or an irrecoverable ordering mistake in an identified retained review, this section takes precedence over the three-option decision below and every summary of it. Continue authorized recoverable work automatically. If a concrete user decision remains, ask Continue the review of <target>, or skip <blocked step>? through the same native question route with exactly Continue and Skip; identify the actual target, step, retained run, usable evidence and consequences. Never offer a fresh review as the remedy for elapsed time or a missed ordering checkpoint.

• Continue: keep the retained review and valid evidence; finish the running check or rerun an interrupted check within the two-hour budget and actual permissions. Do not duplicate a still-running gate. Continue independent authorized work. Reading a diff first cannot reconstruct a blind blueprint: record that ordering failure honestly, perform any still-useful analysis as non-blind, and keep the missing checkpoint unresolved rather than repeating the full review and claiming blindness.
• Skip: omit further execution of the named blocked step and continue the remaining review using retained findings. This explicit waiver never establishes completed-review proof: preserve failed/timeout receipts, mark missing coverage and the ordering failure in notes and the handoff, and retain an incomplete outcome wherever required validation cannot pass. Do not turn an applicable failed gate into not-applicable or admit incomplete findings as a completed review for joined remediation.

Neither choice overrides a denial, required capability, recurrence stop, source binding or artifact validation. A genuine permission decision still uses its owning approval boundary. Reuse an existing choice for the unchanged blocker; do not ask again merely because work remains.

Incomplete review decision

Apply Interrupted checks and missed ordering first when its trigger matches; the choices below cover other genuine recovery decisions, such as missing source or unavailable retained reviewer evidence.

First apply User Questions: confirm a decision is missing, inspect exposed controls and discover deferred ask_user before considering async. Follow the shared eligibility and fallback rules; a visible async tool alone does not establish usable native rendering. An accepted async question owns the pending decision: yield without a final or status message. Unstarted authorized review work continues without this question.

After permitted automatic recovery and independent work, explain the concrete blocker, retained run and which evidence remains usable. Ask through the host's native user-question tool: How should we continue the review of <target>? Replace the target with the actual linked PR or local scope. Present exactly these three options, with recommendations in descriptions rather than changing the labels:

• New review: start a fresh run, recollect current source and perform the full review. Preserve the old run. This choice does not clear denied capabilities, recurrence history or stopped-route limits.
• Resume last one: resume the identified latest retained run at its first unmet checkpoint, reusing only still-valid evidence. Reacquire missing checks or authentic reviewer coverage through permitted recovery; never relabel rejected output as valid. Explain any required capability or source refresh first. If no retained source or evidence identifies the requested run, explain that fact and request a new choice; never silently turn Resume into New. An unusable execution plan alone follows the recovery rule above, without another question.
• Stop: stop this review and any waiting joined remediation, preserve artifacts and existing changes, and perform no further checks or fixes. Do not undo preparation or reinterpret Stop as continuing with available findings.

An explicit existing New/Resume choice for the unchanged target and blocker remains binding; do not ask again merely because work remains. A genuinely new blocker or changed decision may require this prompt. Neither choice grants missing runtime permissions or authorizes retrying an operation still stopped by policy. State what must change before the selected route can proceed. A denial remains a denial; do not use a fresh run to route around it.

For a nested review, the remediation parent owns the single prompt and retains its waiting run. A completed review returns its exact canonical result for admission, finding selection and remediation; it never becomes the remediation final answer. If the native question tool is unavailable, ask the applicable question and options once in chat. Await the answer without sleeping or emitting a final incomplete-review report while the question is pending. Explicit user instructions to continue with available findings remain valid, but that is not an offered recovery option and never establishes completed-review proof.