RCA
The central OpenCode review workflow historically used GitHub repository visibility as the proxy for whether anonymous/free external models could receive review context. That is overly coarse: a private repository can contain only intentionally public-equivalent source, while a public repository can still contain sensitive material accidentally. Conversely, the absence of configured GitHub Actions secrets does not prove that tracked source, fixtures, history, comments, generated review evidence, customer names, architecture, or business context are non-confidential.
PR #830 replaces the blanket private-repository exclusion with a trusted-base, fail-closed opt-in and provider-scoped credential isolation. Code-level success is necessary but not sufficient; the feature is not operationally closed until a real private-repository run proves the intended model and credential boundary.
Feasibility decision
A realistic implementation must satisfy all of the following:
- The candidate repository owner affirmatively classifies the complete tracked review surface as
public_equivalent and accepts external free-model data use.
- The canonical policy is merged into the protected default branch before any later PR attempts to use it. A PR cannot self-enable the policy.
- The repository has no contractual, legal, export-control, data-residency, customer-confidentiality, or internal-policy restriction that conflicts with the selected provider's processing terms.
- Secret scanning and prohibited-pattern checks are defense in depth only; they are never treated as proof of public equivalence.
- The actual OpenCode free-model subprocess receives no GitHub token, Actions OIDC request credential, Actions runtime/cache/results credential, NVIDIA/OpenAI/OpenRouter key, or unrelated provider credential.
- A negative-control private repository without the trusted-base policy remains fail-closed on the private-safe keyed/fallback path.
- Provider unavailability, retention-policy uncertainty, or model-format failure must fall through without weakening required review, check, approval, or branch-protection gates.
If no repository satisfies these conditions, do not invent eligibility. Keep the feature available but inactive and record the specific failed feasibility condition.
Execution plan
After #830 reaches protected main through normal required checks and independent approval:
Acceptance evidence
This issue may close only when one unchanged protected-base canary run and one negative-control run prove all of the following:
- policy inherited from the protected base;
- no self-enablement by the reviewed PR;
- anonymous free model selected only for the opted-in canary;
- no provider/GitHub/Actions credentials exposed to the anonymous subprocess;
- private repository without policy does not use the free pool;
- review output still passes the existing current-head schema/evidence gate;
- required checks, independent approval, and branch protection remain separate and intact;
- rollback is demonstrated or deterministically rehearsed.
Queued, cancelled, skipped, rate-limited, predecessor-head, status-only, synthetic-merge-only, or local-only evidence is not operational acceptance.
Depends on #830.
RCA
The central OpenCode review workflow historically used GitHub repository visibility as the proxy for whether anonymous/free external models could receive review context. That is overly coarse: a private repository can contain only intentionally public-equivalent source, while a public repository can still contain sensitive material accidentally. Conversely, the absence of configured GitHub Actions secrets does not prove that tracked source, fixtures, history, comments, generated review evidence, customer names, architecture, or business context are non-confidential.
PR #830 replaces the blanket private-repository exclusion with a trusted-base, fail-closed opt-in and provider-scoped credential isolation. Code-level success is necessary but not sufficient; the feature is not operationally closed until a real private-repository run proves the intended model and credential boundary.
Feasibility decision
A realistic implementation must satisfy all of the following:
public_equivalentand accepts external free-model data use.If no repository satisfies these conditions, do not invent eligibility. Keep the feature available but inactive and record the specific failed feasibility condition.
Execution plan
After #830 reaches protected
mainthrough normal required checks and independent approval:.github/opencode-private-free-models.jsondeclaration in a normal reviewed PR. Merge it separately to the protected default branch.opencode-free/*candidate, exact head/base, and provider-guard behavior without retaining prompts, source bodies, credentials, or hidden reasoning.Acceptance evidence
This issue may close only when one unchanged protected-base canary run and one negative-control run prove all of the following:
Queued, cancelled, skipped, rate-limited, predecessor-head, status-only, synthetic-merge-only, or local-only evidence is not operational acceptance.
Depends on #830.