Grok review.repository returns protocol violation and timeout on v7

[sumitake]

Summary

Two operator-authorized, exact-head review.repository requests targeting logical agent grok failed under the published agent-collab 7.0.0 / provider runtime 5.0.0 contract while the equivalent Gemini requests succeeded.

Request shape

• logical action: review.repository
• quality profile: frontier
• effort class: maximum
• target agent: grok
• timeout: 120000 ms
• sources: clean public repository snapshots at exact nonzero heads
• invocation: one EOF-delimited JSON request per coordinator process; no TTY
• caller: Codex/OpenAI-family primary
• plugin: 7.0.0
• provider runtime: 5.0.0
• wire schema: 8

Observed outcomes

1. Public plugin repository review:

   • status: protocol_error
   • error code: execution_contract_violation
   • adapter code: failed_terminal
   • failure phase: protocol
   • failed operation counts included one repository read and one unclassified operation
   • cleanup confirmed: true

2. Public workspace repository review:

   • status/error code: timeout
   • adapter code: provider_timeout
   • failure phase: inference
   • cleanup confirmed: true

Neither request was replayed and neither outcome was treated as review evidence. Fresh Gemini requests against the same exact heads succeeded, which narrows this to the Grok route or its interaction with these repository reviews rather than the coordinator request schema in general.

Expected

Each request should either return a valid descriptor-owned review_findings artifact or a more specific actionable diagnostic that distinguishes a provider/tool failure from an output-contract rejection.

No private paths, prompts, provider output, credentials, or secret-bearing diagnostics are included here.

[sumitake]

Additional sanitized evidence from a separate exact-head documentation review:

• action: review.repository
• logical reviewer: Gemini / Google family
• observed result: one bounded client wait ended without a usable review receipt after 120 seconds; the coordinator reported terminal cleanup confirmed, so the result was treated as unavailable evidence and was not replayed
• follow-up: a separately authorized fresh request with a longer bounded timeout completed successfully at the same repository head
• caller state: unchanged throughout; no repository mutation was delegated

This suggests the timeout symptom is not Grok-specific. It may reflect the current client wait bound versus valid provider latency rather than a deterministic provider failure.

[sumitake]

Systemic cross-adapter comparator for the Grok-specific symptom tracked here: an exact-head Gemini review.repository request through installed plugin 7.0.0 also ended in provider_timeout after one provider process had started, with zero managed tool outcomes, cleanup confirmed, no typed auth/quota/upstream terminal, and no replay. Full immutable evidence and generation distinction are recorded in #187 comment 5487708990.

This supports treating the timeout class as managed-route liveness/progress supervision rather than Grok provider unavailability. A larger fixed wall-clock constant is not the durable remedy: a carrier with trustworthy content-free progress should use descriptor-signed admitted-progress inactivity, while strict finite time remains for phases without progress and for post-provider verification/cleanup. This is a cross-link only; it does not duplicate the evidence body or claim that the unreleased 5.0.3 candidate failed.