Dual-review should expose provider progress and distinguish invocation failure from a review verdict

[BaseInfinity]

Feedback type

Improvement / reliability bug.

Local context

A large consumer-repository completion gate used the bundled dual-review adapter with two subscription-backed reviewers. One provider failed to start twice without producing a receipt on the first attempt. A later successful run took about 7.6 minutes and emitted no progress until the final receipt.

No product source, private content, secrets, or proprietary findings are included here.

Evidence

• Provider startup/invocation failure was reported only as a generic failed review.
• Because no reviewer receipt existed, the failure could not be distinguished cleanly from a substantive NOT CERTIFIED verdict at the workflow level.
• During a successful long review, the command was silent until completion, making a healthy long run hard to distinguish from a stalled provider.
• The final structured receipt itself was useful and preserved independent findings correctly.

Suggested change

1. Emit bounded heartbeat/progress events such as provider started, provider completed, reconciliation started, and receipt written.
2. Classify failures as invocation/auth/quota/timeout/reviewer-verdict rather than collapsing them into review failure.
3. Preserve any completed provider result when the peer invocation fails.
4. Write a partial structured receipt for infrastructure failure, explicitly marked non-certifying.
5. Include a safe retry recommendation only for transient invocation failures; do not imply substantive findings should be retried away.

Acceptance idea

An integration fixture with one successful fake reviewer and one startup failure should produce a partial non-certifying receipt with an infrastructure-failure class, while a slow successful fixture should emit at least one progress event before its final certified receipt.