docs(gap-baseline): record OpenCode Go as a confirmed, deferred gap - #1744
Open
seonghobae wants to merge 3 commits into
Open
docs(gap-baseline): record OpenCode Go as a confirmed, deferred gap#1744seonghobae wants to merge 3 commits into
seonghobae wants to merge 3 commits into
Conversation
cool-jackson's investigation (Item 12) found OpenCode Go isn't reachable through contextual-orchestrator's existing opencode_zen ProviderModelSource registration -- independently re-verified both halves before recording: - Fetched contextual-orchestrator's model_discovery.py directly from protected main and grepped it: opencode_zen is registered (credential_name=OPENCODE_ZEN_API_KEY); opencode_go/OPENCODE_GO/"OpenCode Go" appear nowhere in the repository. - Fetched opencode.ai/docs/go directly: Go requires a separate paid subscription and its own API key distinct from Zen access, and uses distinct /zen/go/v1/... endpoints rather than Zen's /zen/v1/... paths. Genuine gap, not a naming oversight. Implementation (a new opencode_go ProviderModelSource, gated on an OPENCODE_GO_API_KEY secret) is deferred per this session's throttle agreement -- no OPENCODE_GO_API_KEY secret exists yet to exercise it in CI anyway. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Warning Review limit reachedNext included review available in 41 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
The repository owner directly corrected the prior entry: OpenCode Zen's
API key and OpenCode Go's API key are the same credential, not separate
ones. The cited OpenCode docs text ("subscribe to Go, and copy your API
key") is consistent with that reading once re-parsed correctly --
subscribing unlocks Go's endpoints for the existing Zen key rather than
issuing a new one.
Narrowed the gap accordingly: no new OPENCODE_GO_API_KEY secret is
needed. What may still be missing is a query against Go's distinct
/zen/go/v1/... endpoints in model_discovery.py (reusing the existing
OPENCODE_ZEN_API_KEY credential), which today isn't probed at all.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
Author
|
Correction: the repository owner directly corrected my original finding — OpenCode Zen's API key and OpenCode Go's API key are the same credential, not separate ones as I originally claimed. Pushed a fix (d3aff70) narrowing the gap: no new |
Comment on lines
+2653
to
+2655
| **Evidence:** | ||
| 1. `contextual_orchestrator/model_discovery.py` on `contextual-orchestrator`'s protected `main` (fetched directly, not via code search) registers `opencode_zen` (`credential_name="OPENCODE_ZEN_API_KEY"`) as a `ProviderModelSource`. No `opencode_go`, `OPENCODE_GO`, or "OpenCode Go" string exists anywhere in the repository (verified by direct grep of the fetched source; a code-search cross-check returned the same zero count) — i.e. nothing currently probes the `/zen/go/v1/...` endpoints at all, regardless of credential. | ||
| 2. OpenCode's own documentation (`opencode.ai/docs/go`, fetched directly): Go's endpoints are distinct from Zen's — `https://opencode.ai/zen/go/v1/{responses,chat/completions,messages}` versus Zen's own `https://opencode.ai/zen/v1/...` paths — and OpenCode configs address Go models with a distinct `opencode-go/<model-id>` identifier. The credential used against those endpoints is the existing Zen key (owner-confirmed), not a separate one. |
Contributor
There was a problem hiding this comment.
🔍 Research lacks doctoring traceability
The OpenCode investigation appears only in the live baseline. The repository’s research directive also requires a durable doctoring record.
Was this helpful? React with 👍 or 👎 to provide feedback.
![cwl-noema-review[bot]](https://avatars.githubusercontent.com/u/295022177?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Noema LLM review
The PR adds a documented, deferred gap for OpenCode Go to the baseline. The correction after owner input is well-traced and the credential conclusion is sound. However, the new section is not yet safe to merge: the evidence about the existing opencode_zen registration is a direct claim about a file on another repository's protected main with no durable commit/digest reference, so it cannot be reproduced or re-verified; this is the exact cross-repository binding defect already flagged in prior threads and remains unresolved here. In addition, the external OpenCode documentation evidence is cited only as a live mutable page with no pinned revision or snapshot, making the changed behavior description unreproducible.
Reviewed changed lines
docs/product-technical-gap-baseline.md:2643 (RIGHT): The new section records a corrected OpenCode Go gap. The correction text accurately reflects the owner's input that OPENCODE_ZEN_API_KEY and OPENCODE_GO_API_KEY are the same credential, which closes the credential question and is internally consistent.docs/product-technical-gap-baseline.md:2653 (RIGHT): Evidence item 1 makes a direct claim aboutcontextual_orchestrator/model_discovery.pyoncontextual-orchestrator's protectedmain(fetched directly and verified by grep). The cited source is only a mutable branch name with no commit SHA, file digest, or permanent URL, so the claim cannot be reproduced or re-verified from the baseline document.docs/product-technical-gap-baseline.md:2655 (RIGHT): The cross-repository binding defect continues at the end of evidence item 1: the code-search cross-check and grep results are described without a pinned commit or permanent reference, leaving the zero-count claim againstopencode_go,OPENCODE_GO, andOpenCode Gonon-durable.docs/product-technical-gap-baseline.md:2665 (RIGHT): Evidence item 2 citesopencode.ai/docs/goas fetched directly. Because it is a live documentation page with no revision, archive, or dated snapshot, the endpoint paths andopencode-go/<model-id>identifier claim cannot be reproducibly verified after the page changes.docs/product-technical-gap-baseline.md:2667 (RIGHT): The deferred next step correctly reuses OPENCODE_ZEN_API_KEY rather than introducing a new secret, and the conclusion is behaviorally reasonable. However, the underlying evidence remains unpinned, so the deferred decision is based on non-durable references.
Adversarial validation
docs/product-technical-gap-baseline.md:2653 (RIGHT)confirmed: Treating the changed baseline entry as mergeable for a docs-only change because the new gap is explicitly marked deferred and non-blocking. — Evidence item 1 references onlycontextual-orchestrator's protectedmainwith no commit SHA or file digest; evidence item 2 references only the liveopencode.ai/docs/gopage with no revision or snapshot.docs/product-technical-gap-baseline.md:2665 (RIGHT)confirmed: Assuming owner confirmation that OPENCODE_ZEN_API_KEY and OPENCODE_GO_API_KEY are the same credential fully resolves the previously flagged external-evidence problem. — The OpenCode documentation citation remainsopencode.ai/docs/gowith no commit, revision, archive, or dated scrape, so the endpoint and identifier claims cannot be checked against the exact bytes originally observed.- Residual risk: The substantive credential conclusion is sound, but the evidence trail is non-durable. Without exact commit/digest and immutable URL references, the baseline entry silently contradicts the repository's binding cross-repository reference convention already flagged in open prior review threads. The authentication and provider-discovery reasoning could still eventually be correct, but its reproducibility is currently unverifiable.
Findings
- [high] docs/product-technical-gap-baseline.md:2653 (RIGHT): Direct claims about contextual-orchestrator source on its protected main lack durable commit/digest provenance, violating the binding cross-repository reference convention. Cite the exact contextual-orchestrator commit SHA or file-content digest at which model_discovery.py was fetched, plus a permanent URL and/or pinned grep command.
- [high] docs/product-technical-gap-baseline.md:2665 (RIGHT): The external OpenCode documentation evidence is cited only as a live mutable page (
opencode.ai/docs/go) with no revision or archive, making the endpoint and identifier claims unreproducible. Add a pinned revision or dated snapshot URL.
- Result: REQUEST_CHANGES
- Head SHA:
d3aff70af473cd4764816e330687ecbcb46cae2b - Reviewer credential:
noema-review-github-app-refresh - Actor:
cwl-noema-review[bot]
seonghobae
added
documentation
ChatGPT Codex Connector
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Records cool-jackson's Item 12 investigation (OpenCode Go vs OpenCode Zen API key sharing) as a confirmed, deferred gap in
docs/product-technical-gap-baseline.md. Independently re-verified both halves of the finding before recording, per this session's own established practice of not writing durable claims into gap-baseline without checking them.Verification performed
contextual-orchestrator'smodel_discovery.pydirectly from protectedmain(not via code search, which had reliability issues elsewhere this session) and grepped it:opencode_zenis registered as aProviderModelSource;opencode_go/OPENCODE_GO/"OpenCode Go" appear nowhere in the repository.opencode.ai/docs/godirectly: confirmed OpenCode Go requires a separate paid subscription and its own distinct API key, with distinct/zen/go/v1/...endpoints rather than Zen's/zen/v1/...paths.Conclusion recorded
Genuine gap (not a naming/discovery oversight): OpenCode Go needs its own
ProviderModelSourceregistration and its own credential. Implementation is deferred per this session's throttle agreement (org-wide Actions capacity at the 60-concurrent-runner plan ceiling) — noOPENCODE_GO_API_KEYsecret exists yet to exercise it in CI anyway, so there's no urgency to implement immediately.Test plan
product-technical-gap-baseline.md), no code/workflow/test files touched🤖 Generated with Claude Code