feat: OpenCode Observability Plugin#73
Conversation
Signed-off-by: Binfeng Xu <binfengx@nvidia.com>
…to feature/bx-opencode
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR introduces a complete OpenCode observability plugin integration for NeMo Flow. The plugin captures OpenCode hook events and exports passive observability traces (ATOF/ATIF) through NeMo Flow's runtime, with configuration validation, session-scoped mark emission, tool span lifecycle tracking, and cleanup on shutdown. ChangesOpenCode Plugin Integration
🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Comment |
github-actions
Bot
added
size:XL
Signed-off-by: Binfeng Xu <binfengx@nvidia.com>
…to feature/bx-opencode
|
/retest |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@integrations/opencode-plugin/server.js`:
- Around line 214-216: The subscriber registered via
lib.registerSubscriber(using atofSubscriberName) writes with
fsSync.appendFileSync(options.atofPath, ...) with no error handling; wrap the
appendFileSync call inside a try/catch inside the subscriber callback, and on
error log or swallow the error (use existing logger or console.error) so
ENOSPC/EACCES or other sync I/O failures do not throw out of the event delivery
path; keep the callback signature and behavior otherwise unchanged so NeMo
Flow/framework behavior is preserved.
- Around line 33-60: The write function currently lets filesystem errors bubble
up and reject plugin hooks; wrap the entire body of write (the path-handling,
ensureParentDir, fs.appendFile and the console logging branches) in a try/catch
so any thrown error is swallowed (or downgraded to a non-fatal fallback) and
write always resolves; on fs failures fall back to console logging the same
formatted message (include PLUGIN_ID, message and toJsonSafe(extra)), and ensure
warnOnce/info/warn/error callers (and the seen set logic) continue to return a
resolved Promise rather than letting errors propagate from write (keep the
existing Promise.resolve() return for the seen shortcut). Use the existing
symbols write, PLUGIN_ID, logPath, ensureParentDir, fs.appendFile, toJsonSafe
and seen to locate where to add the try/catch and fallback.
- Around line 197-198: recentFlushes is an unbounded Map used as a 2s dedupe
cache and needs pruning; change its entries so each key maps to insertion
timestamp (or schedule a per-key setTimeout) and remove entries older than 2
seconds. Locate the recentFlushes usage in server.js (the const recentFlushes =
new Map() declaration and any code that checks/sets keys) and: when adding a
key, store Date.now() (or schedule a setTimeout to delete that key after
2000ms); when checking a key, consider it expired if its timestamp is >2000ms
old and delete it before proceeding; optionally add a short periodic cleanup
(setInterval) to remove stale keys if you choose timestamp-based approach.
Ensure the semantics of the dedupe window remain 2 seconds and that no other
code relies on Map values being non-timestamps.
- Around line 1-2: Replace the line-style SPDX header comments at the top of
integrations/opencode-plugin/server.js with a C-style comment block;
specifically, change the two leading single-line comments containing
"SPDX-FileCopyrightText: Copyright (c) 2026, NVIDIA CORPORATION & AFFILIATES.
All rights reserved." and "SPDX-License-Identifier: Apache-2.0" into a single /*
... */ block so the file has a C-style SPDX header as required by the repo's
licensing guidelines.
- Around line 251-259: In withStack, always restore the prior thread scope stack
instead of only when previous is truthy: capture priorStack via
lib.currentScopeStack(), set lib.setThreadScopeStack(session.stack) before
running callback, and in the finally block call
lib.setThreadScopeStack(previousStack) (even if previousStack is undefined) so
the thread scope is always reset; reference the withStack function and the
lib.currentScopeStack / lib.setThreadScopeStack calls to locate where to change
the restore logic.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: ff9f6b37-40d8-4c6f-8698-7fab042a2722
📒 Files selected for processing (1)
integrations/opencode-plugin/server.js
📜 Review details
🧰 Additional context used
📓 Path-based instructions (12)
**/*.{js,ts,tsx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Use camelCase naming convention for Node.js code
Files:
integrations/opencode-plugin/server.js
**/*.{rs,go,js,ts,tsx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in all Rust, Go, JavaScript, and TypeScript source files using C-style comment syntax
Files:
integrations/opencode-plugin/server.js
**/*.{rs,py,go,js,ts,tsx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Use
SONAR_IGNORE_START/SONAR_IGNORE_ENDmarkers only for documented false positives that cannot be resolved in code; keep ignored blocks small, add explanatory comments, and require reviewer sign-off
Files:
integrations/opencode-plugin/server.js
**/*.{md,markdown,py,sh,bash,js,ts,java,cpp,go,rust}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repo references, and build commands current in documentation
Files:
integrations/opencode-plugin/server.js
**/*.{md,markdown,py,sh,bash,js,ts,example}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Example commands must match current package names and paths
Files:
integrations/opencode-plugin/server.js
**/{integrations,integration,*-integration}/**
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
**/{integrations,integration,*-integration}/**: Keep NeMo Flow optional in framework integrations
Preserve the framework's original behavior when NeMo Flow is absent
Wrap tool and LLM paths at the correct framework boundary
Integration pattern must followdocs/integrate-frameworks/adding-scopes.md
Files:
integrations/opencode-plugin/server.js
{crates/adaptive/**,python/nemo_flow/{adaptive,plugin}.py,go/nemo_flow/{adaptive,**}/*.go,**/*.{ts,js,wasm}}
📄 CodeRabbit inference engine (.agents/skills/maintain-optimizer/SKILL.md)
Keep adaptive config schema, plugin lifecycle, and bindings in sync across crates/adaptive, core, bindings, Python (python/nemo_flow/adaptive.py and python/nemo_flow/plugin.py), Go (go/nemo_flow/adaptive and go/nemo_flow), and Node/WebAssembly helpers
Files:
integrations/opencode-plugin/server.js
**/*.{js,ts,tsx,jsx,py,rs,go,java,c,cpp,h,cc,cxx,cs,rb,php,swift,kt}
📄 CodeRabbit inference engine (.agents/skills/prepare-pr/SKILL.md)
Changed files must be formatted with the language-native formatter
Files:
integrations/opencode-plugin/server.js
**/*.{rs,py,js,ts,go,sh,toml,yaml,yml,json,md,rst}
📄 CodeRabbit inference engine (AGENTS.md)
Keep SPDX headers on source, docs, scripts, and configuration files. The project is Apache-2.0.
Files:
integrations/opencode-plugin/server.js
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
If Node.js language surface changed, always run Node.js test target even when Rust core did not change
Files:
integrations/opencode-plugin/server.js
**/*.{py,js,ts,tsx,go,rs,md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Format changed files with the language-native formatter before the final lint/test pass
Files:
integrations/opencode-plugin/server.js
**/*.{rs,py,js,ts,tsx,go}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
During iteration, prefer
uv run pre-commit run --files <changed files...>for targeted validation
Files:
integrations/opencode-plugin/server.js
Co-authored-by: Will Killian <2007799+willkill07@users.noreply.github.com> Signed-off-by: Binfeng Xu <billxbf@gmail.com>
Co-authored-by: Will Killian <2007799+willkill07@users.noreply.github.com> Signed-off-by: Binfeng Xu <billxbf@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (1)
integrations/opencode-plugin/package.json (1)
32-32: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winConsider linking to integration-specific documentation.
The homepage currently points to the general NeMo-Flow README. Per previous review feedback, consider linking directly to the OpenCode integration documentation if available (e.g., a specific section or doc page for this plugin).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@integrations/opencode-plugin/package.json` at line 32, The package.json "homepage" field for the OpenCode plugin points to the general NeMo-Flow README; update the "homepage" value in the integrations/opencode-plugin package.json to a URL that points directly to the OpenCode integration documentation (e.g., a specific section, doc page, or repo path for the OpenCode plugin) or, if no dedicated doc exists, add a short internal doc and link to it; modify the "homepage" string to that integration-specific URL so the package links to the correct documentation.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/integrate-frameworks/opencode.md`:
- Around line 22-43: The Mermaid diagram block (the ```{mermaid} ... flowchart
LR ... ``` section) is missing an introductory sentence; add a complete lead-in
sentence immediately before the ```{mermaid} block that briefly explains what
the diagram illustrates (e.g., "The following diagram shows the flow between
Developer, Stock OpenCode, the NeMo Flow plugin and runtime and the ATOF/ATIF
exports.") so the diagram is properly introduced and follows the documentation
guideline for complete-sentence introductions.
- Around line 50-51: Update the sentence that reads "Build the NeMo Flow Node.js
binding before loading the plugin from a source checkout. `crates/node` is under
the NeMo Flow repository root:" by formatting the directory path crates/node as
inline code (monospace) so it appears as `crates/node`; locate the sentence
starting with "Build the NeMo Flow Node.js binding..." in
docs/integrate-frameworks/opencode.md and replace the plain text path with the
inline-code version.
In `@integrations/opencode-plugin/package.json`:
- Line 47: The package.json currently references a local file dependency
"nemo-flow-node": "file:../../crates/node" which will break npm publish; fix it
by either replacing that file: spec with a published semver (e.g.,
"nemo-flow-node": "x.y.z") or add a prepublishOnly script that rewrites the
dependency to a published version before packing, or publish nemo-flow-node
separately and reference it by version, or mark this package as "private": true
and document that it is workspace-only; update package.json accordingly and
ensure any publish scripts or README reflect the chosen approach.
- Around line 7-16: Remove the redundant "default" export conditions from the
package.json exports map since "type":"module" makes "import" sufficient; update
the exports entries for "." and "./server" to only use the "import":
"./server.js" condition so that both export paths point to server.js with a
single import condition, ensuring no other keys are changed.
- Line 44: The engines entry in package.json includes a nonstandard "opencode"
constraint which npm ignores; remove the "opencode" key from the engines object
and either add an appropriate entry under peerDependencies or devDependencies
(e.g., "opencode": ">=1.14.40") if you need package-level version enforcement,
or move it to a documentation-only field (e.g., a custom "metadata" or README)
if it's merely informational; update the package.json JSON structure accordingly
and ensure package installs still validate "node" and "npm" under the existing
engines field.
- Around line 46-48: The package.json currently lists "nemo-flow-node" as a hard
dependency; change it to an optional dependency (move "nemo-flow-node" from
"dependencies" into "optionalDependencies") so the runtime try/catch dynamic
import behavior (the code that dynamically imports "nemo-flow-node" and returns
{} on failure) can gracefully fall back, or alternatively move it to
"peerDependencies" if the host framework must supply it; update only the
dependency section and leave the dynamic import logic unchanged.
---
Duplicate comments:
In `@integrations/opencode-plugin/package.json`:
- Line 32: The package.json "homepage" field for the OpenCode plugin points to
the general NeMo-Flow README; update the "homepage" value in the
integrations/opencode-plugin package.json to a URL that points directly to the
OpenCode integration documentation (e.g., a specific section, doc page, or repo
path for the OpenCode plugin) or, if no dedicated doc exists, add a short
internal doc and link to it; modify the "homepage" string to that
integration-specific URL so the package links to the correct documentation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 3a4c7fc0-c8cb-432c-9ef4-a7c4abadf751
📒 Files selected for processing (2)
docs/integrate-frameworks/opencode.mdintegrations/opencode-plugin/package.json
📜 Review details
🧰 Additional context used
📓 Path-based instructions (21)
**/{integrations,integration,*-integration}/**
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
**/{integrations,integration,*-integration}/**: Keep NeMo Flow optional in framework integrations
Preserve the framework's original behavior when NeMo Flow is absent
Wrap tool and LLM paths at the correct framework boundary
Integration pattern must followdocs/integrate-frameworks/adding-scopes.md
Files:
integrations/opencode-plugin/package.json
**/*.{md,rst,html,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-brand-terminology.md)
**/*.{md,rst,html,txt}: Always spellNVIDIAin all caps. Do not useNvidia,nvidia,nVidia,nVIDIA, orNV.
Usean NVIDIAbefore a noun because the name starts with an 'en' sound.
Do not add a registered trademark symbol afterNVIDIAwhen referring to the company.
Use trademark symbols with product names only when the document type or legal guidance requires them.
Verify official capitalization, spacing, and hyphenation for product names.
Precede NVIDIA product names withNVIDIAon first mention when it is natural and accurate.
Do not rewrite product names for grammar or title-case rules.
Preserve third-party product names according to the owner's spelling.
Include the company name and full model qualifier on first use when it helps identify the model.
Preserve the official capitalization and punctuation of model names.
Use shorter family names only after the full name is established.
Spell out a term on first use and put the acronym in parentheses unless the acronym is widely understood by the intended audience.
Use the acronym on later mentions after it has been defined.
For long documents, reintroduce the full term if readers might lose context.
Form plurals of acronyms withs, not an apostrophe, such asGPUs.
In headings, common acronyms can remain abbreviated. Spell out the term in the first or second sentence of the body.
Common terms such asCPU,GPU,PC,API, andUIusually do not need to be spelled out for developer audiences.
Files:
docs/integrate-frameworks/opencode.md
**/*.{md,rst,html}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-brand-terminology.md)
Link the first mention of a product name when the destination helps the reader.
Files:
docs/integrate-frameworks/opencode.md
**/*.{md,rst,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,rst,txt}: SpellNVIDIAin all caps. Do not useNvidia,nvidia, orNV.
Format commands, code elements, expressions, package names, file names, and paths as inline code.
Use descriptive link text. Avoid raw URLs and weak anchors such as 'here' or 'read more.'
Use title case consistently for technical documentation headings.
Introduce code blocks, lists, tables, and images with complete sentences.
Write procedures as imperative steps. Keep steps parallel and split long procedures into smaller tasks.
Prefer active voice, present tense, short sentences, contractions, and plain English.
Usecanfor possibility and reservemayfor permission.
Useafterfor temporal relationships instead ofonce.
Preferrefer tooverseewhen the wording points readers to another resource.
Avoid culture-specific idioms, unnecessary Latinisms, jokes, and marketing exaggeration in technical documentation.
Spell out months in body text, avoid ordinal dates, and use clear time zones.
Spell out whole numbers from zero through nine unless they are technical values, parameters, versions, or UI values.
Use numerals for 10 or greater and include commas in thousands.
Do not add trademark symbols to learning-oriented documentation unless the source, platform, or legal guidance explicitly requires them.
Do not add trademark symbols to NeMo Flow learning documentation by default.
Do not rewrite API names, package names, command flags, or code literals for style reasons.
Files:
docs/integrate-frameworks/opencode.md
**/*.{md,markdown,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-technical-docs.md)
**/*.{md,markdown,rst}: Use title case consistently in technical documentation headings
Avoid quotation marks, ampersands, and exclamation marks in headings
Keep product, event, research, and whitepaper names in their official title case
Use title case for table headers
Do not force social-media sentence case into technical docs
Use monospace formatting for code elements, commands, parameters, package names, and expressions
Use monospace formatting for directories, file names, and paths
Use angle brackets inside monospace for variables inside paths, such as/home/<username>/.login
Use quotation marks for error messages and strings in documentation
Use bold formatting for UI buttons, menus, fields, and labels in documentation
Use angle brackets between UI labels for menu paths, such as File > Save As
Use italics for new terms on first use in documentation
Use italics for publication titles in documentation
Use plain text formatting for keyboard shortcuts in documentation
Prefer[NVIDIA/NeMo](link)format for GitHub repository references over generic phrases like 'the GitHub repo'
Introduce every code block with a complete sentence
Do not make a code block complete the grammar of the previous sentence
Do not continue a sentence after a code block
Use syntax highlighting when the format supports it for code blocks
Avoid the word 'snippet' unless the surrounding docs already use it as a term of art
Keep inline method, function, and class references consistent with nearby docs, omitting empty parentheses for prose readability when no call is shown
Use descriptive anchor text that matches the destination title when possible for links
Avoid raw URLs in running text in documentation
Avoid generic link anchors such as 'here,' 'this page,' and 'read more' in documentation
Include the acronym in link text if a linked term includes an acronym
Do not link long sentences or multiple sentences in documentation
Avoid links that pull readers away from a procedure unles...
Files:
docs/integrate-frameworks/opencode.md
**/*.{html,md}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in HTML and Markdown files using HTML comment syntax
Files:
docs/integrate-frameworks/opencode.md
docs/**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Run
./scripts/build-docs.shfor documentation site changes
docs/**/*.md: Relevant getting-started or reference docs must be updated when examples change
Release-policy docs must point to GitHub Releases as the only release-history source of truth
docs/**/*.md: Use title case for headings in technical documentation
Introduce code blocks, tables, and lists with complete lead-in sentences in documentation
Files:
docs/integrate-frameworks/opencode.md
**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Run Markdown link checking via
lycheeforREADME.md,CONTRIBUTING.md, anddocs/through pre-commit hooks
Files:
docs/integrate-frameworks/opencode.md
**/*.{md,markdown,py,sh,bash,js,ts,java,cpp,go,rust}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repo references, and build commands current in documentation
Files:
docs/integrate-frameworks/opencode.md
{RELEASING.md,CHANGELOG.md,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep release-process and release-notes guidance in repo-maintainer docs such as RELEASING.md, not as user-facing docs pages or CHANGELOG.md
Files:
docs/integrate-frameworks/opencode.md
**/*.{md,markdown,py,sh,bash}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep stable user-facing wrappers at scripts/ root in docs and examples; only point at namespaced helper paths when documenting internal maintenance work
Files:
docs/integrate-frameworks/opencode.md
**/*.{md,markdown,py,sh,bash,js,ts,example}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Example commands must match current package names and paths
Files:
docs/integrate-frameworks/opencode.md
docs/integrate-frameworks/**/*.md
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
Documentation must be updated if activation or usage of the integration changed
Files:
docs/integrate-frameworks/opencode.md
{scripts/*.sh,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
Use root
./scripts/*.shcommands in docs and contributor guidance as documented, with implementations underscripts/third-party/
Files:
docs/integrate-frameworks/opencode.md
{docs/**,examples/**,crates/adaptive/**,python/nemo_flow/**,go/nemo_flow/**,**/{example,component}.{ts,tsx,js,rs,py,go}}
📄 CodeRabbit inference engine (.agents/skills/maintain-optimizer/SKILL.md)
Any new adaptive component kind must have documentation, examples, and binding coverage across all supported languages
Files:
docs/integrate-frameworks/opencode.md
{README*,CHANGELOG*,docs/**/*.{md,rst,txt},examples/**/*,*.md}
📄 CodeRabbit inference engine (.agents/skills/rename-surfaces/SKILL.md)
Update documentation, examples, and getting-started guides with new package/module/crate names after rename operations
Files:
docs/integrate-frameworks/opencode.md
**/*.{md,txt,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
**/*.{md,txt,rst}: Ensure commands, package names, file paths, and APIs in documentation are correct and not stale; flag incorrect or outdated information as blocking issues
Ensure examples and procedures in documentation will execute successfully with current APIs and commands
Use consistent user-facing terminology throughout documentation that matches current repo terminology
Capitalize NVIDIA correctly in all documentation and public-facing text
Format code, commands, paths, and filenames as inline code (monospace) in documentation
Use descriptive anchor text for links instead of bare URLs or weak labels like 'here' in documentation
Prefer active voice, present tense, short sentences, and plain English in documentation
Structure documentation procedures as imperative steps that are easy to scan and not too long for a single sequence
Prefer 'after' instead of 'once' for temporal references in documentation
Use 'can' instead of 'may' when describing possibility (rather than permission) in documentation
Avoid ambiguous numeric dates and ordinal dates in documentation body text
Files:
docs/integrate-frameworks/opencode.md
{README.md,docs/**/*.md,examples/**/*.{js,ts,py,go,rs}}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Keep documentation and examples synchronized with current install, import, and build commands
Files:
docs/integrate-frameworks/opencode.md
**/*.{py,js,ts,tsx,go,rs,md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Format changed files with the language-native formatter before the final lint/test pass
Files:
docs/integrate-frameworks/opencode.md
{README.md,CONTRIBUTING.md,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
For docs-only changes, run targeted checks only if commands, package names, or examples changed. Use
just docsfor docs-site builds andjust docs-linkcheckwhen links changed
Files:
docs/integrate-frameworks/opencode.md
{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}
⚙️ CodeRabbit configuration file
{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}: Review documentation for technical accuracy against the current API, command correctness, and consistency across language bindings.
Flag stale examples, missing SPDX headers where required, and instructions that no longer match CI or pre-commit behavior.
Files:
docs/integrate-frameworks/opencode.md
🔇 Additional comments (4)
docs/integrate-frameworks/opencode.md (3)
68-70: Inconsistent package identifier.Line 69 mentions the published package as
@nvidia/nemoflow-opencode-plugin, but the configuration example at line 80 usesnemo-flow-opencode. These identifiers should match the actual published package name.
92-94: Runtime failure scenario documented.The documentation describes pass-through behavior when
nemo-flow-nodeis missing or fails to initialize. This was previously questioned as unnecessary ifnemo-flow-nodeis a declared dependency of the plugin package.
248-263: Demo video script in user-facing documentation.This section provides a storyboard for recording a walkthrough video. It may be more appropriate for internal contributor documentation or marketing materials rather than user-facing integration guides.
integrations/opencode-plugin/package.json (1)
50-50: ⚡ Quick winVerify
@opencode-ai/pluginversion 1.14.40 exists.The package specifies
@opencode-ai/plugin@>=1.14.40as a peer dependency and^1.14.40as a dev dependency. Confirm that version 1.14.40 exists in the npm registry and that this is the correct minimum version for the plugin API surface used inserver.js.What is the latest version of `@opencode-ai/plugin` on npm and does version 1.14.40 exist?Also applies to: 53-53
There was a problem hiding this comment.
Actionable comments posted: 8
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/integrate-frameworks/opencode.md`:
- Around line 8-10: Add an inline link on the first occurrence of the product
name "OpenCode" in the sentence that begins "NeMo Flow integrates with
OpenCode..." so the first mention points to OpenCode's official project page
(replace plain text "OpenCode" with a hyperlink to the project's URL), leaving
subsequent mentions unchanged; update the sentence where "OpenCode" appears to
use the linked form.
- Around line 15-16: Update the sentence that reads "The generic NeMo Flow
`observability` plugin config controls ATOF, ATIF, OpenTelemetry, and
OpenInference export." to spell out the project-specific acronyms on first use:
replace the first mentions of ATOF and ATIF with their full forms followed by
the acronym in parentheses (e.g., "Full Term for ATOF (ATOF)" and "Full Term for
ATIF (ATIF)"), keep the acronyms for subsequent references, and leave
OpenTelemetry and OpenInference unchanged; locate and edit the phrase containing
`observability`, `ATOF`, and `ATIF`.
In `@integrations/opencode/README.md`:
- Around line 77-78: Update the README line to use the full configuration key
path for openinference to match the preceding item: replace the standalone
`openinference` with `plugins.components[].config.openinference` so readers can
copy the exact field; ensure the exact token
`plugins.components[].config.openinference` is used in the same style as
`plugins.components[].config.opentelemetry` for consistency.
- Around line 8-10: Update the first occurrence of the token "OpenCode" in the
README to be a Markdown link to the official OpenCode project (wrap the first
"OpenCode" instance with the project's canonical URL, e.g.,
[OpenCode](https://opencode.dev) or the official repo URL), leaving subsequent
mentions unchanged; ensure the link text remains "OpenCode" and the surrounding
sentence formatting is preserved in the README heading/paragraph where
"OpenCode" is first used.
In `@integrations/opencode/server.js`:
- Around line 50-53: Console logging prints the raw extra object (variable
extra) and can leak sensitive fields; use the already-sanitized payload (e.g.,
record.extra or the result of toJsonSafe(extra)) when writing to console instead
of extra so the PLUGIN_ID log branches (text / level) print the redacted data
rather than the original object.
- Around line 425-460: Guard all NeMo Flow runtime/exporter calls so failures
degrade to warn-only: wrap the lib.pushScope call (where session.scope is set
inside withStack in the session initialization) and the lib.event call inside
emitMark in try/catch blocks, and do the same for lib.toolCall and
lib.toolCallEnd usages referenced elsewhere (around the 593-638 region); on
exception call logger.warnOnce(...) with a clear message and return early so the
hook becomes a no-op but does not reject the integration. Ensure you only catch
errors from NeMo calls (leave other logic unchanged) and preserve existing
return values/flow when a NeMo call fails.
- Around line 99-105: The plugin currently enables by default but never
registers an observability exporter because normalizePluginHostConfig(baseDir,
rawOptions.plugins) falls back to components: [] and the old shortcuts
atofPath/atifPath are rejected; modify the return value construction to ensure
an observability component is registered when none exist: when
normalizePluginHostConfig(...) yields no observability components add a default
component (e.g., an observability exporter configured with
resolveOutputPath(baseDir, rawOptions.atofPath ?? rawOptions.atifPath ??
"./.nemoflow/default.atof")) or map the removed shortcuts (rawOptions.atofPath /
rawOptions.atifPath) into a components entry so that the initialized plugins
list includes a writer; update the code near the existing rejectRemovedOption
calls and the object returned from normalizePluginHostConfig to perform this
seeding/mapping.
In `@integrations/opencode/test/server.test.mjs`:
- Around line 326-336: The test currently dereferences the result of
runtime.events.find(...) into message.metadata without confirming the event
exists; update the checks to first assert the found event is present (e.g.,
assert.ok(message, 'expected opencode.chat.message event')) before accessing
nested fields, then proceed to assert message.metadata.sessionID, agent, model,
etc.; apply the same pattern for the other occurrence referenced (the find(...)
used at lines 440-446) so both places validate the event object exists before
dereferencing its metadata.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 10f91bd2-bf59-428b-8142-ba6e5153cd07
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (6)
docs/integrate-frameworks/opencode.mdintegrations/opencode/README.mdintegrations/opencode/package.jsonintegrations/opencode/server.jsintegrations/opencode/test/server.test.mjspackage.json
📜 Review details
🧰 Additional context used
📓 Path-based instructions (32)
{Cargo.toml,setup.py,setup.cfg,pyproject.toml,go.mod,go.sum,package.json,package-lock.json,yarn.lock,pom.xml,*.gradle}
📄 CodeRabbit inference engine (.agents/skills/rename-surfaces/SKILL.md)
Update repository manifest files (Cargo.toml, setup.py, go.mod, package.json, etc.) with new package/crate names during rename operations
Files:
package.json
{Cargo.toml,pyproject.toml,go/nemo_flow/go.mod,package.json,package-lock.json,crates/node/package.json}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Maintain consistent package names, import paths, and module names across Rust, Python, Go, Node, and WebAssembly workspaces in NeMo Flow
Files:
package.json
**/{integrations,integration,*-integration}/**
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
**/{integrations,integration,*-integration}/**: Keep NeMo Flow optional in framework integrations
Preserve the framework's original behavior when NeMo Flow is absent
Wrap tool and LLM paths at the correct framework boundary
Integration pattern must followdocs/integrate-frameworks/adding-scopes.md
Files:
integrations/opencode/package.jsonintegrations/opencode/README.mdintegrations/opencode/server.jsintegrations/opencode/test/server.test.mjs
**/*.{md,rst,html,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-brand-terminology.md)
**/*.{md,rst,html,txt}: Always spellNVIDIAin all caps. Do not useNvidia,nvidia,nVidia,nVIDIA, orNV.
Usean NVIDIAbefore a noun because the name starts with an 'en' sound.
Do not add a registered trademark symbol afterNVIDIAwhen referring to the company.
Use trademark symbols with product names only when the document type or legal guidance requires them.
Verify official capitalization, spacing, and hyphenation for product names.
Precede NVIDIA product names withNVIDIAon first mention when it is natural and accurate.
Do not rewrite product names for grammar or title-case rules.
Preserve third-party product names according to the owner's spelling.
Include the company name and full model qualifier on first use when it helps identify the model.
Preserve the official capitalization and punctuation of model names.
Use shorter family names only after the full name is established.
Spell out a term on first use and put the acronym in parentheses unless the acronym is widely understood by the intended audience.
Use the acronym on later mentions after it has been defined.
For long documents, reintroduce the full term if readers might lose context.
Form plurals of acronyms withs, not an apostrophe, such asGPUs.
In headings, common acronyms can remain abbreviated. Spell out the term in the first or second sentence of the body.
Common terms such asCPU,GPU,PC,API, andUIusually do not need to be spelled out for developer audiences.
Files:
integrations/opencode/README.mddocs/integrate-frameworks/opencode.md
**/*.{md,rst,html}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-brand-terminology.md)
Link the first mention of a product name when the destination helps the reader.
Files:
integrations/opencode/README.mddocs/integrate-frameworks/opencode.md
**/*.{md,rst,txt}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-guide.md)
**/*.{md,rst,txt}: SpellNVIDIAin all caps. Do not useNvidia,nvidia, orNV.
Format commands, code elements, expressions, package names, file names, and paths as inline code.
Use descriptive link text. Avoid raw URLs and weak anchors such as 'here' or 'read more.'
Use title case consistently for technical documentation headings.
Introduce code blocks, lists, tables, and images with complete sentences.
Write procedures as imperative steps. Keep steps parallel and split long procedures into smaller tasks.
Prefer active voice, present tense, short sentences, contractions, and plain English.
Usecanfor possibility and reservemayfor permission.
Useafterfor temporal relationships instead ofonce.
Preferrefer tooverseewhen the wording points readers to another resource.
Avoid culture-specific idioms, unnecessary Latinisms, jokes, and marketing exaggeration in technical documentation.
Spell out months in body text, avoid ordinal dates, and use clear time zones.
Spell out whole numbers from zero through nine unless they are technical values, parameters, versions, or UI values.
Use numerals for 10 or greater and include commas in thousands.
Do not add trademark symbols to learning-oriented documentation unless the source, platform, or legal guidance explicitly requires them.
Do not add trademark symbols to NeMo Flow learning documentation by default.
Do not rewrite API names, package names, command flags, or code literals for style reasons.
Files:
integrations/opencode/README.mddocs/integrate-frameworks/opencode.md
**/*.{md,markdown,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/assets/nvidia-style-technical-docs.md)
**/*.{md,markdown,rst}: Use title case consistently in technical documentation headings
Avoid quotation marks, ampersands, and exclamation marks in headings
Keep product, event, research, and whitepaper names in their official title case
Use title case for table headers
Do not force social-media sentence case into technical docs
Use monospace formatting for code elements, commands, parameters, package names, and expressions
Use monospace formatting for directories, file names, and paths
Use angle brackets inside monospace for variables inside paths, such as/home/<username>/.login
Use quotation marks for error messages and strings in documentation
Use bold formatting for UI buttons, menus, fields, and labels in documentation
Use angle brackets between UI labels for menu paths, such as File > Save As
Use italics for new terms on first use in documentation
Use italics for publication titles in documentation
Use plain text formatting for keyboard shortcuts in documentation
Prefer[NVIDIA/NeMo](link)format for GitHub repository references over generic phrases like 'the GitHub repo'
Introduce every code block with a complete sentence
Do not make a code block complete the grammar of the previous sentence
Do not continue a sentence after a code block
Use syntax highlighting when the format supports it for code blocks
Avoid the word 'snippet' unless the surrounding docs already use it as a term of art
Keep inline method, function, and class references consistent with nearby docs, omitting empty parentheses for prose readability when no call is shown
Use descriptive anchor text that matches the destination title when possible for links
Avoid raw URLs in running text in documentation
Avoid generic link anchors such as 'here,' 'this page,' and 'read more' in documentation
Include the acronym in link text if a linked term includes an acronym
Do not link long sentences or multiple sentences in documentation
Avoid links that pull readers away from a procedure unles...
Files:
integrations/opencode/README.mddocs/integrate-frameworks/opencode.md
**/*.{html,md}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in HTML and Markdown files using HTML comment syntax
Files:
integrations/opencode/README.mddocs/integrate-frameworks/opencode.md
**/README.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Update relevant crate or package README when that surface changed
Relevant package or crate README.md files must be updated when examples or binding guidance changes
Files:
integrations/opencode/README.md
**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Run Markdown link checking via
lycheeforREADME.md,CONTRIBUTING.md, anddocs/through pre-commit hooks
Files:
integrations/opencode/README.mddocs/integrate-frameworks/opencode.md
**/*.{md,markdown,py,sh,bash,js,ts,java,cpp,go,rust}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep package names, repo references, and build commands current in documentation
Files:
integrations/opencode/README.mddocs/integrate-frameworks/opencode.mdintegrations/opencode/server.js
**/*.{md,markdown,py,sh,bash}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep stable user-facing wrappers at scripts/ root in docs and examples; only point at namespaced helper paths when documenting internal maintenance work
Files:
integrations/opencode/README.mddocs/integrate-frameworks/opencode.md
**/*.{md,markdown,py,sh,bash,js,ts,example}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Example commands must match current package names and paths
Files:
integrations/opencode/README.mddocs/integrate-frameworks/opencode.mdintegrations/opencode/server.js
**/*.{md,txt,rst}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
**/*.{md,txt,rst}: Ensure commands, package names, file paths, and APIs in documentation are correct and not stale; flag incorrect or outdated information as blocking issues
Ensure examples and procedures in documentation will execute successfully with current APIs and commands
Use consistent user-facing terminology throughout documentation that matches current repo terminology
Capitalize NVIDIA correctly in all documentation and public-facing text
Format code, commands, paths, and filenames as inline code (monospace) in documentation
Use descriptive anchor text for links instead of bare URLs or weak labels like 'here' in documentation
Prefer active voice, present tense, short sentences, and plain English in documentation
Structure documentation procedures as imperative steps that are easy to scan and not too long for a single sequence
Prefer 'after' instead of 'once' for temporal references in documentation
Use 'can' instead of 'may' when describing possibility (rather than permission) in documentation
Avoid ambiguous numeric dates and ordinal dates in documentation body text
Files:
integrations/opencode/README.mddocs/integrate-frameworks/opencode.md
{README.md,docs/index.md,**/README.md}
📄 CodeRabbit inference engine (.agents/skills/review-doc-style/SKILL.md)
Update entry-point documentation (README.md, docs/index.md, package READMEs, binding-level source READMEs) whenever public behavior changes
Files:
integrations/opencode/README.md
**/*.{py,js,ts,tsx,go,rs,md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
Format changed files with the language-native formatter before the final lint/test pass
Files:
integrations/opencode/README.mddocs/integrate-frameworks/opencode.mdintegrations/opencode/server.js
docs/**/*.md
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Run
./scripts/build-docs.shfor documentation site changes
docs/**/*.md: Relevant getting-started or reference docs must be updated when examples change
Release-policy docs must point to GitHub Releases as the only release-history source of truth
docs/**/*.md: Use title case for headings in technical documentation
Introduce code blocks, tables, and lists with complete lead-in sentences in documentation
Files:
docs/integrate-frameworks/opencode.md
{RELEASING.md,CHANGELOG.md,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/contribute-docs/SKILL.md)
Keep release-process and release-notes guidance in repo-maintainer docs such as RELEASING.md, not as user-facing docs pages or CHANGELOG.md
Files:
docs/integrate-frameworks/opencode.md
docs/integrate-frameworks/**/*.md
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
Documentation must be updated if activation or usage of the integration changed
Files:
docs/integrate-frameworks/opencode.md
{scripts/*.sh,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/contribute-integration/SKILL.md)
Use root
./scripts/*.shcommands in docs and contributor guidance as documented, with implementations underscripts/third-party/
Files:
docs/integrate-frameworks/opencode.md
{docs/**,examples/**,crates/adaptive/**,python/nemo_flow/**,go/nemo_flow/**,**/{example,component}.{ts,tsx,js,rs,py,go}}
📄 CodeRabbit inference engine (.agents/skills/maintain-optimizer/SKILL.md)
Any new adaptive component kind must have documentation, examples, and binding coverage across all supported languages
Files:
docs/integrate-frameworks/opencode.md
{README*,CHANGELOG*,docs/**/*.{md,rst,txt},examples/**/*,*.md}
📄 CodeRabbit inference engine (.agents/skills/rename-surfaces/SKILL.md)
Update documentation, examples, and getting-started guides with new package/module/crate names after rename operations
Files:
docs/integrate-frameworks/opencode.md
{README.md,docs/**/*.md,examples/**/*.{js,ts,py,go,rs}}
📄 CodeRabbit inference engine (.agents/skills/maintain-packaging/SKILL.md)
Keep documentation and examples synchronized with current install, import, and build commands
Files:
docs/integrate-frameworks/opencode.md
{README.md,CONTRIBUTING.md,docs/**/*.md}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
For docs-only changes, run targeted checks only if commands, package names, or examples changed. Use
just docsfor docs-site builds andjust docs-linkcheckwhen links changed
Files:
docs/integrate-frameworks/opencode.md
{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}
⚙️ CodeRabbit configuration file
{docs/**,README.md,CONTRIBUTING.md,RELEASING.md,SECURITY.md}: Review documentation for technical accuracy against the current API, command correctness, and consistency across language bindings.
Flag stale examples, missing SPDX headers where required, and instructions that no longer match CI or pre-commit behavior.
Files:
docs/integrate-frameworks/opencode.md
**/*.{js,ts,tsx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Use camelCase naming convention for Node.js code
Files:
integrations/opencode/server.js
**/*.{rs,go,js,ts,tsx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Include SPDX license headers in all Rust, Go, JavaScript, and TypeScript source files using C-style comment syntax
Files:
integrations/opencode/server.js
**/*.{rs,py,go,js,ts,tsx}
📄 CodeRabbit inference engine (CONTRIBUTING.md)
Use
SONAR_IGNORE_START/SONAR_IGNORE_ENDmarkers only for documented false positives that cannot be resolved in code; keep ignored blocks small, add explanatory comments, and require reviewer sign-off
Files:
integrations/opencode/server.js
{crates/adaptive/**,python/nemo_flow/{adaptive,plugin}.py,go/nemo_flow/{adaptive,**}/*.go,**/*.{ts,js,wasm}}
📄 CodeRabbit inference engine (.agents/skills/maintain-optimizer/SKILL.md)
Keep adaptive config schema, plugin lifecycle, and bindings in sync across crates/adaptive, core, bindings, Python (python/nemo_flow/adaptive.py and python/nemo_flow/plugin.py), Go (go/nemo_flow/adaptive and go/nemo_flow), and Node/WebAssembly helpers
Files:
integrations/opencode/server.js
**/*.{js,ts,tsx,jsx,py,rs,go,java,c,cpp,h,cc,cxx,cs,rb,php,swift,kt}
📄 CodeRabbit inference engine (.agents/skills/prepare-pr/SKILL.md)
Changed files must be formatted with the language-native formatter
Files:
integrations/opencode/server.js
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
If Node.js language surface changed, always run Node.js test target even when Rust core did not change
Files:
integrations/opencode/server.js
**/*.{rs,py,js,ts,tsx,go}
📄 CodeRabbit inference engine (.agents/skills/validate-change/SKILL.md)
During iteration, prefer
uv run pre-commit run --files <changed files...>for targeted validation
Files:
integrations/opencode/server.js
🔇 Additional comments (4)
integrations/opencode/package.json (2)
43-45: Keepnemo-flow-nodeoptional in this integration manifest.Line 43 declares
nemo-flow-nodeas a hard dependency, which conflicts with the integration optionality requirement for framework integrations.#!/bin/bash set -euo pipefail echo "Checking dependency placement in integrations/opencode/package.json..." sed -n '40,52p' integrations/opencode/package.json echo echo "Checking fallback/import patterns in integrations/opencode/server.js..." rg -nP -C3 'nemo-flow-node|loadRuntime|try\s*\{|catch\s*\(' integrations/opencode/server.jsAs per coding guidelines,
**/{integrations,integration,*-integration}/**: Keep NeMo Flow optional in framework integrations.
1-42: LGTM!Also applies to: 46-52
package.json (1)
10-11: LGTM!integrations/opencode/test/server.test.mjs (1)
1-325: LGTM!Also applies to: 337-439, 447-449
Signed-off-by: Binfeng Xu <billxbf@gmail.com>
2 participants
Overview
Details
integrations/opencode-pluginas an npm package for OpenCode server plugin usage.crates/nodeopencodeopencode.jsonwith the plugin file URLopencodeand inspect.nemoflowoutputexample
opencode.jsonWhere should the reviewer start?
Start with
integrations/opencode-plugin/server.js, then reviewintegrations/opencode-plugin/test/server.test.mjs.Summary by CodeRabbit
New Features
Documentation
Chores