Skip to content

Operational validation: governed free-model canary for private repositories #833

Description

@seonghobae

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:

  1. The candidate repository owner affirmatively classifies the complete tracked review surface as public_equivalent and accepts external free-model data use.
  2. 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.
  3. 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.
  4. Secret scanning and prohibited-pattern checks are defense in depth only; they are never treated as proof of public equivalence.
  5. 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.
  6. A negative-control private repository without the trusted-base policy remains fail-closed on the private-safe keyed/fallback path.
  7. 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:

  • Inventory private ContextualWisdomLab repositories under their existing writer leases; do not write any repository owned by another enabled loop.
  • Select one deliberately low-risk canary whose complete tracked source and review evidence can be authoritatively classified as public-equivalent. Prefer a purpose-built fixture/canary repository over a production repository.
  • In that repository, add only the canonical .github/opencode-private-free-models.json declaration in a normal reviewed PR. Merge it separately to the protected default branch.
  • Open or use a later bounded PR so the policy is inherited from the immutable base rather than introduced by the same head.
  • Trigger a normal OpenCode review and retain bounded evidence of the selected opencode-free/* candidate, exact head/base, and provider-guard behavior without retaining prompts, source bodies, credentials, or hidden reasoning.
  • Verify the child environment excludes all credential classes listed above.
  • Run the same review path against a private negative-control repository without the policy and verify that anonymous free candidates are not enabled.
  • Verify keyed/private-safe fallback remains available when configured and that total provider exhaustion remains fail-closed.
  • Record operator rollback: remove/disable the policy through a separately reviewed protected-base change, then verify a later PR no longer receives anonymous free candidates.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions