fix(opencode): enrich reviewer output with provider-owned capture subject

[dnlrsls]

Pre-flight Checklist

• I have searched existing issues and this is not a duplicate.
• I understand PRs require status:approved.

Bug Description

A negotiated bounded review exposes provider-owned artifact_subject, exact candidate diff, and changed-path manifest through START/status. The selected OpenCode reviewer correctly returns the strict native model-owned shape {findings,evidence}. The managed review-result-artifacts.ts hook forwards that JSON unchanged to review capture-result, but native admission requires the capture-only envelope to also contain provider-derived top-level subject_hash and inspection. Capture therefore fails with reviewer artifact admission incomplete: reviewer result omitted the provider-owned artifact subject, preserves the raw result, and leaves authority in reviewing with no admitted lens result.

This is a product/integration regression or incomplete acceptance from merged PR #1550, which introduced provider-owned artifact admission and claimed managed OpenCode support. It is distinct from #1610 (authority revision propagation), #1411 (capture incident preservation/recovery), and #1454 (immutable diff/manifest delivery). The reviewer must not emit or construct provider-owned metadata; the adapter owns enrichment.

Steps to Reproduce

1. Install/sync a Gentle AI beta containing provider-owned reviewer artifact admission and use OpenCode.
2. Start or resume a negotiated review whose native next transition is collect/reviewer_results_required; verify it provides artifact_subject, candidate_diff, and changed_path_manifest.
3. Launch the selected bound reviewer through the managed hook.
4. Let the reviewer return valid strict JSON with only findings and evidence, as required by its agent contract.
5. Observe the after-hook extract that JSON and forward it unchanged to review capture-result.
6. Observe capture fail with the admission-incomplete error and preserve the raw reviewer result while authority remains unchanged.

Expected Behavior

The managed adapter should build a capture-only envelope by combining reviewer-owned findings/evidence with provider-owned subject_hash from artifact_subject.subject_hash and inspection: {status: "completed", paths: [...]} derived from the exact ordered changed-path manifest. Models must continue returning only findings/evidence. The same deterministic enrichment path should support replaying a preserved raw result through full native verification without rerunning the lens or opening another review budget.

Actual Behavior

The installed plugin and the current beta managed asset both forward reviewer output unchanged. Preflight/transition context contains the provider-owned subject and manifest, but the after-hook does not retain or merge them into capture stdin. Native capture sees an empty subject hash and rejects admission.

Environment

• Gentle AI Version: beta module v1.49.1-0.20260722122850-8881b60b01c7, revision 8881b60b01c7 (post-v2.1.11 development build)
• Operating System: Windows
• AI Agent / Client: OpenCode
• Affected Area: Installation Pipeline (managed OpenCode plugin)

Logs / Error Output

gentle-ai review capture-result failed (1): Error: reviewer artifact admission incomplete: reviewer result omitted the provider-owned artifact subject

Additional Context

Verified source-backed causal chain:

• internal/cli/review_start_contract.go and internal/cli/review_next_transition.go expose the provider-owned subject/diff/manifest.
• internal/cli/review_facade.go decodes capture input with top-level subject_hash, inspection, findings, and evidence.
• internal/reviewtransaction/artifact_admission.go rejects a missing subject hash.
• internal/assets/opencode/plugins/review-result-artifacts.ts extracts reviewer JSON and forwards it unchanged; the installed managed plugin has the same ownership gap.

Acceptance criteria:

• Reviewer output contract remains strict {findings,evidence} only.
• Adapter retains provider preflight/transition context for the exact bound slot.
• Adapter constructs capture stdin with provider-derived subject_hash and ordered completed inspection.paths.
• Models never construct hashes, manifests, inspection metadata, or canonical artifacts.
• Preserved raw results can pass through the same enrichment and native verification path without another reviewer invocation.
• A behavioral managed-hook test mocks preflight/transition context, supplies findings/evidence-only output, asserts exact capture stdin, and covers preserved-result recovery and idempotent replay.

[decode2]

Verified incident evidence

I reproduced this exact failure with OpenCode on Linux using Gentle AI beta 1.49.1-0.20260722122850-8881b60b01c7. Provider preflight returned a complete artifact_subject, immutable candidate diff, and changed-path manifest. The managed before-hook injected that provider context, but the after-hook passed only the reviewer-owned {findings,evidence} object to native capture. Native admission then failed with:

reviewer artifact admission incomplete: reviewer result omitted the provider-owned artifact subject

The exactly-once behavior is important here: the reliability lens was consumed once, authority remained reviewing, next_transition remained collect, and candidate/index bytes remained immutable. Preservation reproduced rather than repaired the failure. The preserved raw payload was exactly 960 bytes and contained only findings and evidence; it contained no artifact subject, lineage, target, lens, or order metadata. This confirms the missing binding is an adapter-boundary problem, not malformed reviewer analysis.

Secondary compatibility finding

Managed preservation emitted an opaque reference with the form rinc1_5a2... (redacted), but the same installed beta rejected the documented recovery surface before any capture attempt:

flag provided but not defined: -recovery-token

Acceptance should therefore include capability/version coherence: if preserve-result emits a recovery reference, that installed build must expose and accept the corresponding recovery capability, or clearly report that recovery is unavailable without emitting an unusable reference.

Verified fix behavior and safety constraints

A local proof of the adapter behavior passed all focused tests, 5/5. The adapter attaches the provider-issued subject before capture, rejects any mismatched model-supplied subject, and preserves the same provider-bound capture payload for recovery. OpenCode required a restart for verification because plugins load once per process. This is behavioral proof only; I am not linking or proposing a PR here.

The fix must preserve these safety properties:

• No manual JSON augmentation during incident recovery.
• No model-authored hash or provider-owned metadata.
• No reviewer relaunch and no new review budget for the same consumed lens.
• No weakening of native artifact admission or validation.
• Recovery must replay the same provider-bound capture payload through native verification.

[decode2]

Correction to my earlier local-fix note: installed beta 1.49.1-0.20260722122850-8881b60b01c7 authoritatively decodes capture input as top-level subject_hash, inspection: {status: "completed", paths: [...]}, findings, and evidence. It does not accept the preflight artifact_subject object. Submitting that object produced exactly: decode reviewer result: json: unknown field "artifact_subject". The adapter fix now derives subject_hash and ordered inspection paths from provider preflight instead.

[dnlrsls]

Verified on Windows 11, PowerShell 7, and OpenCode with active Gentle AI main development build 1.49.1-0.20260722163017-4907129ec9dc. For an existing medium-tier lineage in reviewing, negotiated review status --contract gentle-ai.review-integration/v1 --next-transition returned complete provider-owned context: artifact_subject with subject_hash, exact authority revision/target/repository context/lens/order, base64 immutable candidate diff, and an ordered changed-path manifest.

The OpenCode orchestration contract still requires a literal GENTLE_AI_REVIEW_BINDING prefix before launching the selected reviewer, but neither START nor negotiated STATUS renders it. Hand construction is forbidden because models and orchestrators must not author provider-owned hashes or canonical capture metadata. Orchestration therefore stops before reviewer invocation: no lens is consumed, no reviewer result, finalize journal, or receipt exists, authority remains reviewing, and candidate/Git bytes remain unchanged. This complements #1689s post-review capture-enrichment failure by proving a pre-launch executability gap at the same adapter ownership boundary.

Suggested acceptance addition: the managed OpenCode adapter must deterministically retain, render, and consume the provider-owned binding from negotiated transition context before reviewer launch, including exact revision/target/repository context/lens/order, without parent/model JSON construction. An end-to-end test should prove STATUS/START -> bound reviewer -> enriched capture.

[dnlrsls]

Could a maintainer please review this issue and, if the scope is accepted, apply status:approved? Engram #652 is implemented locally but remains blocked here. Preserved lineage review-39abc6a048bb1d3d still reports the exact frozen candidate snapshot, authority reviewing, action finalize, and next transition collect/reviewer_results_required. #652 cannot safely finalize by manually constructing provider-owned metadata or rerunning the consumed lens, because either would violate the review lifecycle guarantees.

[dnlrsls]

A second Windows/OpenCode reproduction confirms the pre-launch adapter executability gap already described in the 2026-07-22 comment. Native START/current authority supplied immutable artifact subjects, the exact candidate diff, ordered manifest, repository context, target, and revision, but the managed path did not render a plugin-compatible literal GENTLE_AI_REVIEW_BINDING {json} for the task prompt.

The managed plugin activates only when the task prompt begins with that exact regex-compatible binding and expected field schema. Without a provider-rendered literal, a manually reconstructed prompt bypassed the hook; the attempted external-temp fallback then hit OpenCode expected external_directory guard. Four reviewer tasks produced no admissible capture, and one falsely reported completed against unrelated paths. Native admission behaved correctly: zero results were captured, authority remained reviewing, and candidate bytes/path modes remained immutable. This is Gentle AI managed adapter/orchestration ownership, not an OpenCode permission bug. The external-directory denial was correct, and external temp files are not the supported transport.

Recovery remains same-lineage collection after a fresh OpenCode session, with no new START or review budget required. Suggested acceptance: native next-transition/managed adapter must deterministically emit or internally retain the exact opaque task binding, inject frozen context inline, fail before reviewer launch when injection is absent, and cover START/STATUS -> bound task -> capture in an end-to-end hook test. Unlike #1743, this case has zero captured results and supported same-slot recovery, so it does not require a new recovery issue.