coordinator: classify zero-provider source seal failures

[sumitake]

Summary

Installed coordinator 6.1.1 returned an opaque, zero-provider source_seal_failed after about 60 seconds. The response had no failure_trace or safe subtype, so the caller could not distinguish a concurrent source mutation from a source limit, repository-shape problem, capture deadline, or I/O failure.

Evidence

• Request: project-estimation-r3-plan-r2
• Exact repository head requested: e52ab85c7b010d683906b3d6362c836d7c847792
• Manifest: 3f56ec0e275b807774edd0484514f4cdfaa78646cae403606ea6fb80618211cf
• Terminal response:

status=protocol_error
error_code=source_seal_failed
provider_processes=0
metadata_process_count=0
failure_trace=null

The worktree was not quiescent in the surrounding interval: transient request material and learning-ledger files were being changed by concurrent session activity. That makes a mutation race plausible, but the response does not prove it. Stable dirty linked worktrees are supposed to be supported, so "dirty" alone is not an actionable diagnosis.

Requested behavior

• Preserve fail-closed zero-provider behavior.
• Add one bounded, path-free source-seal detail from a closed vocabulary, for example source_changed_during_capture, unsupported_repository_shape, source_limit, capture_deadline, or source_io_error.
• Test stable dirty linked worktree success and concurrent-mutation failure with the specific safe subtype, bounded completion, cleanup, and zero provider calls.
• Document that request framing should live outside repo_root and that callers should keep source quiescent during seal/capture.

The consumed request was not replayed or relabelled.

[sumitake]

Additional same-task evidence from the project-estimation Task 5 review:

• request: project-estimation-task5-plan-review-20260821
• request delivery: closed stdin file under /private/tmp, outside repo_root
• repository state: staged Task 5 plan; the session transcript records no repository mutation between invocation and response
• elapsed: approximately 90 seconds
• result: status=protocol_error, error_code=source_seal_failed
• diagnostics: zero provider processes, null failure_trace, no artifact, same 3f56ec0e275b manifest-digest prefix as the earlier occurrence

The request was consumed and was not replayed. This occurrence weakens the provisional hypothesis that an in-repository request file alone caused the failure: the caller used the external-request-file boundary and still received no actionable source-seal subtype.

Durable workspace evidence is being updated in ERR-20260821-054052-codex-a1f4 via agent-collab-workspace PR #2917.

[sumitake]

Additional project-estimation evidence after the original issue/ledger cutoff:

• project-estimation-task5-r1-plan-review-20260821 returned protocol_error/source_seal_failed with zero provider processes and no artifact.
• project-estimation-task5-r2-implementation-review-20260821 failed at exact clean head prefix 042fd8bb with zero provider processes, zero metadata processes, no artifact, and no evidence receipt.
• Before the latter request, local checks established the canonical root, clean head, no Git lock, no tracked symlink, and successful Git connectivity.

Both attempts are terminal, neutral/unavailable evidence and were not replayed or relabelled. This further weakens dirty-request-file as a sufficient explanation and reinforces the need for a safe source-seal subtype.

Durable workspace record: ERR-20260821-185243-codex-6d08 in agent-collab-workspace PR #2923.

[sumitake]

Additive recurrence (plugin 6.2.0, manifest 13a9f85f6e35, runtime 4.1.0, 2026-08-23): review.repository (frontier/maximum, target_agent grok, timeout_ms 600000) with repo_root set to a LINKED GIT WORKTREE (.claude/worktrees/<topic>, where .git is a file pointer) returned status: protocol_error, error_code: source_seal_failed, zero provider processes, all diagnostics null. The identical request with repo_root pointed at the primary checkout (real .git directory) got past the seal (proceeded to provider execution). New reproduction detail for this issue: linked worktrees appear to be a deterministic seal-failure input, and the diagnostic does not say so — an actionable subtype (e.g. repo_root_is_linked_worktree) would have saved a blind retry.

[sumitake]

v6.2.2 release disposition: this diagnostic enhancement remains open. Runtime 4.2.0 improves selection, adapter, containment, and failed-operation diagnostics, but does not add a closed source-seal subtype to the generic source_seal_failed path. Keep source quiescent during capture, place request framing outside repo_root, treat a zero-provider failure as consumed and non-authoritative, and do not blind-retry. Reproduce against 6.2.2 before implementing the follow-up.

[sumitake]

Additive 6.2.2 recurrence (2026-08-24): request claude-plan-second-opinion used documented EOF-delimited stdin, review.repository, frontier/maximum, untargeted selection, and a canonical linked Git worktree root. The coordinator returned status=protocol_error, error_code=source_seal_failed, manifest_digest=63f3fc257df1665912ad992d1abe0e470ff06d0013422d25a6d40fb3dc16a8b6, zero provider processes, zero metadata processes, null failure trace, and no artifact/receipt. The request was consumed and was not replayed. This reproduces the linked-worktree seal failure on the current 6.2.2 release and confirms the open diagnostic gap remains.

[sumitake]

Additive evidence from the 6.2.4 release guard review attempt (2026-08-25 UTC): installed plugin 6.2.3, runtime-manifest SHA-256 a50f9c82aca2af54d764e03a5f00f7c38cd139249146a2edade97d602bf44964. Exact request shape was one closed review.repository request at frontier/maximum, target_agent null, timeout_ms 120000, against a clean workspace worktree at source commit bf1e80f0d733fb2513ca5fcfb098e99434e2728e. The coordinator returned status=protocol_error, error_code=source_seal_failed, disposition=inspect, metadata_process_count=0 and provider_processes=0. No replay was made; the PR trace will record the review surface as unavailable.

[sumitake]

Additive recurrence from the PR #3074 exact-head review attempt on 2026-08-27 UTC:

• Installed plugin: 6.2.4
• Runtime-manifest SHA-256: 688ae21fa5fd60412def402fd30c1a56a6807435114bd92537f60c89c05138ca
• Wire-contract SHA-256: 774067d0a2a640b2eac27cace99f6cf812649169e03aab2ec8fcf77a2c3fe2a9
• Request: one review.repository governance review at frontier / maximum, target_agent=gemini, timeout_ms=600000
• Reviewed source head: 06b804e61f7cd5a8b5bb0de1a54e8918cdd88226
• Source root: a clean disposable standalone Git clone under /private/tmp (not a linked worktree)
• Result: status=protocol_error, error_code=source_seal_failed, provider_processes=0, metadata_process_count=0, no verdict, receipt, artifact, or failure trace

The failure was treated as terminal neutral/unavailable evidence and was not replayed or represented as peer review. This adds a non-linked-worktree clean-clone reproduction to the open diagnostic gap. No prompt, source content, credentials, raw provider output, or environment data are included.

[sumitake]

Additive 6.2.4 recurrence and root-cause framing from 2026-08-27 UTC:

Observed request:

• request_id: ranchoburro-shared-zone-governance-20260827
• logical action: governance.repository
• quality and effort: frontier / maximum
• target_agent: null
• timeout_ms: 600000
• exact requested source head: 030a9ee3f1529d7115643d5b3a750f9a93b2ce06
• source shape: linked Git worktree
• installed plugin: 6.2.4
• runtime-manifest SHA-256: 688ae21fa5fd60412def402fd30c1a56a6807435114bd92537f60c89c05138ca
• wire-contract SHA-256: 774067d0a2a640b2eac27cace99f6cf812649169e03aab2ec8fcf77a2c3fe2a9

Terminal response:

• status: protocol_error
• error_code: source_seal_failed
• disposition: inspect
• provider_processes: 0
• metadata_process_count: 0
• failure_trace and all adapter, catalog, model, selection, implementation, and provider diagnostics: null
• no artifact, verdict, or execution receipt

The invocation was treated as consumed neutral or unavailable evidence and was not replayed.

Cross-occurrence evidence: this is the same manifest and wire-contract pair as the clean standalone-clone recurrence already recorded above. Therefore linked-worktree shape is not a sufficient explanation for this release, even though older evidence made it look deterministic.

The corresponding current source shape also shows why source_seal_failed is a symptom bucket rather than a root cause:

• provider_runtime.py lines 1511-1516 collapse OSError, TypeError, and ValueError from source identity capture into source_seal_failed.
• provider_runtime.py lines 1646-1649 separately collapse non-timeout PrivateRepositoryError cases from edge execution into the same source_seal_failed code.
• provider_runtime.py lines 299-315 substitutes the all-null diagnostics map when either branch omits diagnostics.
• PrivateRepositoryError already carries a redacted status and message, but the generic edge-execution mapping discards that causal distinction.

This source inspection does not prove the triggering cause of this occurrence. It proves that the public contract currently cannot reveal it because multiple stages and error classes converge on one code with null diagnostics.

Requested acceptance refinement:

1. Preserve fail-closed, zero-provider, no-replay behavior.
2. Preserve a closed path-free subtype at the first failing stage, plus a closed stage such as root_seal, identity_capture, snapshot_capture, source_revalidation, or adapter_source_match.
3. Map the already-redacted PrivateRepositoryError status and reason into that closed vocabulary instead of discarding them.
4. Regression-test standalone clones and linked worktrees with injected identity, deadline, limit, I/O, mutation, and adapter-source failures; assert the distinct stage and subtype, bounded cleanup, and zero provider execution when failure precedes invocation.

The checkout has since advanced, so current repository cleanliness is intentionally not presented as invocation-time evidence. No prompt, source contents, credentials, raw provider output, or local absolute paths are included.

[sumitake]

Additive 6.3.0 recurrence from planning PR #3093 replacement-head review on 2026-08-27 UTC. Request runtime-failure-plan-review-20260827-r8-grok used governance.repository, frontier/maximum, target_agent grok, timeout_ms 600000, and exact signed source head fa93dceb63a3721c932a0cc02629dc250a7a3d5d in a clean linked Codex worktree; request framing was outside repo_root. Installed manifest SHA-256: 688ae21fa5fd60412def402fd30c1a56a6807435114bd92537f60c89c05138ca; wire SHA-256: 774067d0a2a640b2eac27cace99f6cf812649169e03aab2ec8fcf77a2c3fe2a9. Terminal result: protocol_error / source_seal_failed, provider_processes=0, metadata_process_count=0, no artifact, verdict, receipt, failure trace, or adapter identity. Immediate post-result checks positively showed the same exact local and remote head, empty porcelain status, clean tracked and staged diffs, and git diff --check success. This remains neutral unavailable evidence; no provider call occurred and the request was not relabeled as review. The next separately named attempt will use the repository sealed_review_root helper rather than reusing the linked worktree source shape.

[sumitake]

Additive 6.3.0 recurrence from planning PR #3093 exact-head review on 2026-08-27 UTC. Request runtime-failure-plan-review-20260827-r10-grok used governance.repository, frontier/maximum, target grok, timeout_ms 600000, and signed source head 0a3603004fd2981cd1fc1e0a6d6d0bae5f47355f. The source was a clean standalone clone produced and verified by scripts/sealed_review_root.py, with a real .git directory and the request file outside repo_root. Installed manifest SHA-256: 688ae21fa5fd60412def402fd30c1a56a6807435114bd92537f60c89c05138ca; wire SHA-256: 774067d0a2a640b2eac27cace99f6cf812649169e03aab2ec8fcf77a2c3fe2a9. Terminal result: protocol_error / source_seal_failed, provider_processes=0, metadata_process_count=0, no artifact, verdict, receipt, failure trace, or adapter identity. The isolated clone was deterministically removed through the same helper. This is neutral unavailable evidence; no provider call occurred and the request was not replayed.

[sumitake]

Additive exact-head evidence from the runtime-failure-fidelity implementation at 24c58b8ddd744d8e243b4e5377aa4116db583978.

• Installed plugin/runtime: 6.3.0; installed manifest SHA-256 688ae21fa5fd60412def402fd30c1a56a6807435114bd92537f60c89c05138ca; installed wire-contract SHA-256 774067d0a2a640b2eac27cace99f6cf812649169e03aab2ec8fcf77a2c3fe2a9.
• A corrected repository request against a clean standalone clone, using the installed public coordinator's supported top-level repo_root request shape, failed before provider invocation with protocol_error / source_seal_failed. Zero provider processes and zero provider metadata were observed; no artifact was produced. Response SHA-256 7e70b7947e030bb049b415b33b7d40055d5ff866fd1060529fad64e25f52009b.
• The same corrected request shape against the clean canonical worktree failed identically before provider invocation. Response SHA-256 7cae1bc1c9021d5dd68ad49d8750d4f27204f11ce892deaa87c2a67c2affe78f.
• The candidate exact-head direct runtime (wire schema 8) subsequently sealed that source and completed separate Gemini cross-check and governance invocations successfully. Cross-check artifact SHA-256 648cf4690252cfbb9f1c9de3e4d2caae81261a1dfb523240c5fc931257514e8f; governance artifact SHA-256 b88fe4d1f1e620db1a398b05285649516da6e67be9ff6859683f646fca1322c1.

This reinforces that the installed coordinator's zero-provider source-seal failure needs the typed diagnostic disposition tracked here; it was not a repository-dirty condition or a provider failure. The failed requests were not retried after the two clean-source reproductions.

[sumitake]

Resolved by merged workspace runtime source in PR #3097 (merge a23bc86dee3b8bdbea2c4932cc3877b5e77b56c0), invocation hardening in PR #3099 (merge fa27403adc5b7fd0c9493c4b7136f09b07783e92), and plugin distribution PR #180 (merge a8afaa8). The fix is carried by immutable v7.0.0 release 378330262; archive SHA-256 eb1b2aa3eb8fa916bc6ae4e422127c15cc8da81c1a31c202f9bbeffc2c3aa9ac. Post-restart JOHN-MBP verification matched all 170 published members and manifest SHA-256 2bf858764510fddfa86f491f677ad1a80d05b854a33d77a9a3230d0cb399fddf. The single all-action readiness request returned ok for 12 logical actions and proved zero model calls; no provider canary or replay was run.

The released runtime now preserves typed zero-provider source-capture/seal causes instead of collapsing them into a generic failure. This closes the stated diagnostic defect.