Skip to content

feat(cli): add provider-bound frozen candidate inspection #2005

Description

@decode2

Pre-flight Checklist

  • I have searched existing issues and this is not a duplicate
  • I understand that PRs will be rejected if the linked issue does not have status:approved

🔍 Affected Area

CLI (commands, flags)

💡 Problem Statement

Issue #1992 requires OpenCode reviewers to inspect frozen Git candidates on native Windows without depending on the POSIX env -i command recipe. Moving directly from shell commands to managed reviewer prompts and permissions in one oversized PR produced a 633-line change and coupled the security primitive to its first consumer.

The repository currently has no provider-owned, cross-platform CLI capability that can expose only the immutable candidate operations reviewers need while keeping repository context, Git trees, paths, configuration isolation, output limits, and timeouts under native authority.

📦 Proposed Solution

Add an additive gentle-ai review inspect-candidate capability that:

  • accepts only provider-issued repository context plus exact revision, lineage, target, lens, and order bindings;
  • resolves base/candidate trees and the ordered changed-path manifest internally;
  • selects candidate paths only by canonical manifest index, never by model-provided path;
  • exposes only name-status, numstat, stat, patch, and object operations;
  • executes Git with structured argv and an isolated environment, without shell interpolation or safe.directory bypass;
  • bounds subprocesses, the aggregate operational phase, and returned payload size;
  • rejects unknown flags, positional arguments, stale authority, invalid operation combinations, and out-of-range selectors;
  • remains additive and does not change existing reviewer prompts or permissions.

🔄 Alternatives Considered

  • Platform-specific PowerShell/CMD/POSIX recipes: rejected because OpenCode may use different shells on Windows and permission matching can evaluate command nodes independently.
  • Direct git -c recipes: rejected because flags alone do not fully isolate inherited Git configuration, object directories, attributes, or external diff behavior.
  • Provider-installed wrapper scripts: rejected because they add platform-specific lifecycle, quoting, PATH, and atomic-upgrade complexity.
  • One 633-line PR: rejected because the capability and its OpenCode activation form two independently reviewable units above the repository 400-line budget.

📎 Additional Context

Relationship to existing work

Stacked-to-main justification

This issue is PR A of a maintainer-approved two-PR stack:

  1. PR A (this issue): add and test the inactive native capability, targeting main, with no reviewer behavior change.
  2. PR B (fix(opencode): support immutable review inspection on Windows #1992): after PR A merges, migrate managed OpenCode prompts and permissions to the capability and close the Windows bug.

The split is safe because PR A is additive and independently reversible. PR B depends operationally on PR A and cannot land first. This keeps each review at or below 400 changed lines without weakening tests or requesting size:exception.

Acceptance criteria

  • The capability accepts no caller-controlled repository path, Git tree, literal candidate path, or arbitrary Git argv.
  • Authority and artifact subject bindings are revalidated before inspection.
  • Every operation uses immutable trees, isolated Git configuration/attributes, bounded output, and fail-closed timeout handling.
  • Exact-output tests cover hostile inherited Git configuration and all supported operations through the public CLI dispatcher.
  • Tests prove invalid binding/flag combinations, payload bounds, deadline propagation, independent-error preservation, and no mutation of HEAD/index/worktree.
  • Windows packages cross-compile successfully.
  • Existing managed reviewer prompts, permissions, and golden assets remain byte-unchanged in this PR.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestpriority:highHigh prioritystatus:approvedApproved for implementation — PRs can now be opened

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions