@opencode/core 0.0.0-reserved → 2.0.0

package/dist/chunks/aisdk-native-h251t0cq.js

@@ -0,0 +1,480 @@
+import {
+  AbsolutePath2
+} from "./aisdk-native-922hggd3.js";
+import {
+  Info18,
+  ID4,
+  Name2
+} from "./aisdk-native-rd6pz67j.js";
+import {
+  Service35
+} from "./aisdk-native-y9tfvs3x.js";
+import {
+  __export
+} from "./aisdk-native-9rqn6x4v.js";
+
+// src/plugin/skill.ts
+var exports_skill2 = {};
+__export(exports_skill2, {
+  OpencodeContent: () => OpencodeContent2,
+  OpencodeDescription: () => OpencodeDescription2,
+  Plugin: () => Plugin29,
+  ReportContent: () => ReportContent2,
+  SkillPlugin: () => exports_skill2
+});
+import { define } from "@opencode/plugin/effect/plugin";
+import { Effect } from "effect";
+import os from "os";
+
+// src/plugin/skill/opencode.md
+var opencode_default = `# OpenCode
+
+Use this guide as the starting point for work involving OpenCode itself. It
+covers the core concepts needed to configure and customize OpenCode, extend it
+with plugins, and build integrations with the OpenCode SDK, clients, and API.
+
+Full documentation is available at <https://opencode.ai/v2/docs/>. This overview is
+only an index of core concepts. Before answering a question about a topic below,
+fetch the URL named in that section and use the full page as the source of
+truth. Follow links from that page when the question needs more detail. Fetch
+<https://opencode.ai/v2/docs/> first when you need to discover the relevant
+documentation page.
+
+A machine-readable documentation index is available at
+<https://opencode.ai/v2/llms.txt>.
+
+## Version policy
+
+Always answer for OpenCode V2 unless the user explicitly asks about V1,
+legacy OpenCode, or migrating from V1.
+
+Use only <https://opencode.ai/v2/docs/> documentation as the source of truth for V2.
+Do not use <https://opencode.ai/docs/>, which documents V1, and do not use
+general web search to resolve a V2 documentation question when the V2 docs or
+linked pages cover it. The schema served from
+<https://opencode.ai/config.json> may describe V1 even though V2 configuration
+files include that URL for editor integration. Never use it to infer V2 field
+names or shapes. If V2 documentation is missing or contradictory, state the
+uncertainty or ask for clarification instead of falling back to V1.
+
+V1 documentation and syntax may be consulted only when the user explicitly
+asks about V1 or when needed as migration input. Outputs and recommendations
+must still use V2 unless the user specifically requests a V1 result.
+
+## [CLI](https://opencode.ai/v2/docs/cli)
+
+For questions about the terminal interface, command-line invocation, \`run\`,
+\`mini\`, terminal providers, or other CLI behavior, fetch the
+[CLI guide](https://opencode.ai/v2/docs/cli) and the relevant page linked from
+that section.
+
+CLI and TUI preferences are separate from OpenCode's server and project
+configuration. They live in the global \`~/.config/opencode/cli.json\`, or
+\`$XDG_CONFIG_HOME/opencode/cli.json\` when \`XDG_CONFIG_HOME\` is set. There is no
+project-local CLI configuration. Most preferences can also be changed from the
+TUI by pressing \`Ctrl+P\` and selecting **Open settings**.
+
+Fetch the full [CLI configuration guide](https://opencode.ai/v2/docs/cli/config)
+before editing \`cli.json\`. It covers terminal-only settings such as themes,
+keybindings, terminal plugins, scrolling, attention alerts, diff presentation,
+and terminal integration. Do not put these settings in \`opencode.json(c)\`.
+
+### [Keybinds](https://opencode.ai/v2/docs/cli/keybinds)
+
+Configure keybindings under \`keybinds\` in \`cli.json\`. The leader key is the
+\`keybinds.leader\` entry; leader timing is configured separately under
+\`leader.timeout\`. Bindings can use a string, an array of strings, or an object
+when event behavior such as \`preventDefault\` is required. Disable a binding
+with \`"none"\` or \`false\`.
+
+Never guess a command ID, default binding, or accepted key syntax. Fetch the
+full [keybind reference](https://opencode.ai/v2/docs/cli/keybinds), which lists
+the current IDs and defaults, before answering or editing a binding.
+
+## [OpenCode configuration](https://opencode.ai/v2/docs/config)
+
+OpenCode's server and project configuration uses JSON or JSONC. Include the
+published schema so the user's editor can validate fields and provide
+autocomplete:
+
+\`\`\`jsonc
+{
+  "$schema": "https://opencode.ai/config.json",
+}
+\`\`\`
+
+Global configuration lives at \`~/.config/opencode/opencode.json(c)\` and applies
+to every project for that user. Project configuration can live in any directory
+as \`opencode.json(c)\` or \`.opencode/opencode.json(c)\`, including nested packages
+in a monorepo.
+
+During ordinary project discovery, OpenCode searches the current Location
+directory and every ancestor through the filesystem root, including directories
+above the detected project or repository root. It merges direct
+\`opencode.json(c)\` files from the farthest ancestor to the current directory,
+then does the same for \`.opencode/opencode.json(c)\` files. This means every
+discovered \`.opencode\` config overrides every discovered direct config. Global
+filesystem configuration has lower precedence than these discovered documents.
+
+Common configuration fields include \`model\`, \`default_agent\`, \`permissions\`,
+\`agents\`, \`commands\`, \`plugins\`, \`providers\`, \`mcp\`, \`skills\`, \`instructions\`,
+\`references\`, \`formatter\`, and \`lsp\`.
+
+This configuration is distinct from \`cli.json\`. Use the
+[CLI configuration guide](https://opencode.ai/v2/docs/cli/config) for terminal
+preferences, especially themes and keybindings.
+
+Do not guess field names or shapes. Fetch the V2 configuration guide and its
+linked topic guide as the source of truth, and preserve unrelated settings when
+editing an existing file. Keep the published \`$schema\` URL in configuration
+examples, but do not fetch it to determine the V2 configuration shape.
+
+See the [full configuration guide](https://opencode.ai/v2/docs/config) for
+every field, examples, config locations, and links to dedicated feature guides.
+
+## [MCP servers](https://opencode.ai/v2/docs/mcp-servers)
+
+Configure MCP servers under \`mcp.servers\`. Prefer the CLI because it preserves
+unrelated configuration. Use \`--global\` when the user asks to set up a service
+for themselves without limiting it to the current project; omit it when they
+explicitly want project-local configuration.
+
+\`\`\`sh
+opencode mcp add <name> --global --url <remote-url>
+opencode mcp list
+\`\`\`
+
+Remote servers use OAuth by default. If \`mcp list\` reports that a server needs
+authentication, tell the user to run \`/mcps\`, select the server, and sign in.
+Do not run \`opencode mcp auth\` through the shell tool: it starts an interactive
+flow whose authorization link can be hidden in background process output.
+Use the user-facing MCP interface instead.
+
+Report the server as configured but awaiting sign-in until its connection
+status confirms it is connected.
+
+OAuth credentials are stored outside the OpenCode configuration. Do not ask for or
+store an API key when the server supports OAuth. Use header-based credentials
+only when OAuth is unavailable or the user explicitly requires them, and use an
+environment substitution such as \`{env:MCP_API_KEY}\` instead of writing a
+secret into configuration.
+
+## [V1 to V2 migration](https://opencode.ai/v2/docs/migrate-v1)
+
+For any request to migrate OpenCode configuration, agents, commands, skills,
+plugins, integrations, or other behavior from V1 to V2, read the full
+[migration guide](https://opencode.ai/v2/docs/migrate-v1) before acting. In
+the repository, its source is \`services/www/src/docs/content/migrate-v1.mdx\`.
+
+V1 config files and \`.opencode/\` definitions are intended to remain compatible.
+The only intentional breaking changes are the server API and plugin API. Native
+V2 config uses more ergonomic shapes, but conversion is optional. When the user
+requests conversion, inspect the complete configuration, preserve behavior and
+unrelated settings, and apply only the relevant migrations from the guide. For
+plugin migrations, fetch and follow both the migration guide and the full
+[plugins guide](https://opencode.ai/v2/docs/build/plugins). If non-API V1
+functionality fails in V2, use the \`report\` skill to file it as a compatibility
+bug.
+
+## [Plugins](https://opencode.ai/v2/docs/build/plugins)
+
+For questions about creating, configuring, loading, publishing, or migrating
+plugins, fetch the full [plugins guide](https://opencode.ai/v2/docs/build/plugins)
+before answering. Refer to this guide when the user wants to build a plugin. It
+covers hooks, transforms, tools, plugin context capabilities, and package
+entrypoints. Plugins can also extend the TUI; for those, fetch the
+[CLI plugin guide](https://opencode.ai/v2/docs/build/plugins/cli).
+For custom methods and events shared with other plugins or clients, fetch the
+[RPC guide](https://opencode.ai/v2/docs/build/plugins/rpc).
+
+## [Service](https://opencode.ai/v2/docs/troubleshooting#check-the-background-service)
+
+OpenCode uses a client-server architecture. Interfaces such as the TUI connect
+to a background OpenCode service, which owns sessions, configuration, plugins,
+permissions, and tool execution.
+
+OpenCode normally discovers or starts the shared background service
+automatically. If the service is stuck or unhealthy, restart it:
+
+\`\`\`sh
+opencode service restart
+\`\`\`
+
+Check its status after restarting:
+
+\`\`\`sh
+opencode service status
+\`\`\`
+
+## [API](https://opencode.ai/v2/docs/api)
+
+OpenCode exposes an HTTP API from its server. The API is described by an
+OpenAPI document available from the running server at \`/openapi.json\`.
+
+Use OpenCode's built-in \`api\` command for local requests. It uses the same
+discovery and authentication flow as the TUI and may start the background
+service when no compatible healthy service is available. It accepts either an
+HTTP method and path or an OpenAPI operation ID.
+
+Call an endpoint with an HTTP method and path:
+
+\`\`\`sh
+opencode api get /api/health
+\`\`\`
+
+Pass a request body with \`--data\` or \`-d\`, and additional headers with
+\`--header\` or \`-H\`:
+
+\`\`\`sh
+opencode api post /api/example --data '{"key":"value"}'
+opencode api get /api/example --header 'X-Example:value'
+\`\`\`
+
+Request bodies default to \`Content-Type: application/json\`. When OpenCode is
+connected to an explicit server instead of its managed background service, use
+the same configured server and authentication context rather than constructing
+an unauthenticated request separately.
+
+See the [full API reference](https://opencode.ai/v2/docs/api) for available
+endpoints, parameters, request bodies, and response schemas. The
+raw [OpenAPI specification](https://opencode.ai/v2/openapi.json) is also
+available for code generation and other tooling.
+
+## [Client](https://opencode.ai/v2/docs/build/client)
+
+For questions about connecting an application to OpenCode over the network,
+fetch the full [client guide](https://opencode.ai/v2/docs/build/client) before
+answering.
+
+\`@opencode/client\` is the generated TypeScript client for the OpenCode HTTP
+API. Its methods and types come from the same contract as the API reference.
+The default entrypoint exposes Promise-based resource clients and async
+iterables for streaming endpoints. The \`@opencode/client/effect\` entrypoint
+exposes typed Effects, Streams, and decoded OpenCode schema values. Its
+\`Service\` API can discover, start, stop, and authenticate with the local
+background service from a Node application.
+
+## [SDK](https://opencode.ai/v2/docs/build/sdk)
+
+For questions about embedding OpenCode directly in an application, fetch the
+full [SDK guide](https://opencode.ai/v2/docs/build/sdk) before answering. The SDK
+hosts OpenCode in the application without opening an HTTP listener.
+
+Use the [Effect SDK guide](https://opencode.ai/v2/docs/build/sdk/effect) for
+Effect applications. For Cloudflare Durable Objects, use the
+[Cloudflare SDK guide](https://opencode.ai/v2/docs/build/sdk/cloudflare).
+
+## [Troubleshooting](https://opencode.ai/v2/docs/troubleshooting)
+
+OpenCode runs a client and a background server. Start by determining whether a
+problem belongs to the client, the shared server, or one project.
+
+- Check the service with \`opencode service status\` and verify the API with
+  \`opencode api get /api/health\`.
+- Compare with \`opencode --standalone\`, which runs the TUI with a private
+  server, to isolate shared-service issues.
+- Inspect \`~/.local/share/opencode/log/opencode.log\`. Filter \`role=cli\` for
+  client startup and \`role=server\` for sessions, providers, plugins,
+  permissions, and tools.
+- Run one reproduction with \`OPENCODE_LOG_LEVEL=DEBUG\` when normal logs are not
+  sufficient.
+- Do not delete or edit the database, service registration, or service config
+  while diagnosing a problem. Back up persistent data before inspecting it
+  with external tools.
+- Redact API keys, authorization headers, prompts, file contents, and other
+  sensitive data before sharing diagnostics.
+
+See the [full troubleshooting guide](https://opencode.ai/v2/docs/troubleshooting)
+for service lifecycle commands, API inspection, log locations, explicit server
+connections, issue-reporting details, and local development paths.
+`;
+
+// src/plugin/skill/report.md
+var report_default = `<!--
+  Built-in skill. Name and description are registered in code at
+  packages/core/src/plugin/skill.ts. The body below becomes the skill's
+  content.
+-->
+
+# Report an opencode Issue
+
+Use this skill when the user wants to report an opencode issue or bug. Your job
+is to turn the user's problem into a useful GitHub issue with standard
+diagnostics plus the context needed to reproduce and resolve it.
+
+## Workflow
+
+1. Collect the standard diagnostics below.
+2. Ask only for missing details that are necessary to reproduce or understand
+   impact.
+3. Draft the issue in the standard format below.
+4. Publish it with GitHub CLI after the user confirms the title and body.
+
+Do not publish an issue without user confirmation. If GitHub CLI is not
+installed or not authenticated, explain the blocker and provide the exact issue
+title/body for the user.
+
+## Standard Diagnostics
+
+Collect these values when possible:
+
+- opencode version: run \`opencode --version\`.
+- Operating system: run \`uname -a\` on Unix-like systems, or \`ver\` on Windows.
+- Terminal: inspect \`$TERM\`, \`$TERM_PROGRAM\`, \`$COLORTERM\`, and any obvious
+  terminal app context the user provides.
+- Shell: inspect \`$SHELL\` on Unix-like systems, or \`%COMSPEC%\`/\`$ComSpec\` on
+  Windows when relevant.
+- Install/channel context: include whether this appears to be local, dev, beta,
+  or release if the version output or environment reveals it.
+- Active plugins: inspect opencode config for configured plugins when possible.
+  Check likely config locations such as \`opencode.json\`, \`opencode.jsonc\`,
+  \`.opencode/opencode.json\`, and \`~/.config/opencode/opencode.json\`. Record
+  configured plugin entries, local plugin files under \`.opencode/plugin/\` or
+  \`.opencode/plugins/\`, and note if plugin status could not be determined.
+
+If a diagnostic command fails, include \`Unavailable\` with the reason instead of
+guessing.
+
+## User-Specific Context
+
+Capture the details that make the issue actionable:
+
+- What the user was trying to do.
+- What happened.
+- What the user expected to happen.
+- Reproduction steps, ideally minimal and numbered.
+- Relevant logs, stack traces, screenshots, terminal output, or config snippets.
+- Whether the issue is reproducible consistently, intermittently, or only once.
+- Recent changes that may be related, such as updating opencode, changing
+  config, installing a plugin, changing terminal, or switching workspace.
+- Workarounds tried and whether they helped.
+
+Avoid pasting secrets. Redact tokens, API keys, private URLs, usernames, and
+project-specific confidential data unless the user explicitly says it is safe.
+
+## Issue Format
+
+Use this exact structure unless the repository issue template requires
+otherwise:
+
+\`\`\`markdown
+## Summary
+
+<!-- One or two sentences describing the bug and impact. -->
+
+## Environment
+
+- opencode version: <!-- value or Unavailable: reason -->
+- OS: <!-- value or Unavailable: reason -->
+- Terminal: <!-- value or Unavailable: reason -->
+- Shell: <!-- value or Unavailable: reason -->
+- Install/channel: <!-- value or Unavailable: reason -->
+- Active plugins: <!-- list, none found, or Unavailable: reason -->
+
+## Reproduction
+
+1. <!-- step -->
+2. <!-- step -->
+3. <!-- step -->
+
+## Expected Behavior
+
+<!-- What should have happened. -->
+
+## Actual Behavior
+
+<!-- What happened instead. Include exact errors when available. -->
+
+## Additional Context
+
+<!-- Logs, config snippets, screenshots, frequency, workarounds, related notes. -->
+\`\`\`
+
+Keep the title short and searchable. Prefer the form:
+
+\`\`\`text
+<area>: <specific failure or symptom>
+\`\`\`
+
+Examples: \`tui: skills dialog crashes outside location provider\`,
+\`cli: local service config writes release filename\`.
+
+## Publishing With GitHub CLI
+
+Use GitHub CLI from the repository checkout when available:
+
+\`\`\`sh
+gh issue create --title "<title>" --body-file <file>
+\`\`\`
+
+Write the body to a temporary markdown file first so quoting, newlines, logs,
+and code fences are preserved. If the issue belongs in a specific repository,
+use \`--repo owner/name\`. If labels are obvious and the repo accepts them, add
+\`--label bug\`; otherwise omit labels rather than guessing.
+
+After publishing, report the created issue URL to the user and mention any
+diagnostics that were unavailable.
+`;
+
+// src/plugin/skill.ts
+var OpencodeContent2 = opencode_default;
+var ReportContent2 = report_default;
+var OpencodeDescription2 = "Use this skill for any question about OpenCode itself, including how OpenCode works, using or configuring it, migrating from V1 to V2, troubleshooting it, developing plugins or integrations, using the OpenCode SDK, clients, server, or API, and contributing to the OpenCode codebase. Also use it for OpenCode agents, commands, skills, tools, permissions, MCP servers, providers, models, themes, keybinds, formatters, the CLI, TUI, desktop app, and web app.";
+var REPORT_DESCRIPTION = "Use when the user wants to report an opencode issue or bug. Collect standard diagnostics, add user-specific reproduction context, and publish the issue with GitHub CLI.";
+var Plugin29 = define({
+  id: "opencode.skill",
+  effect: Effect.fn(function* (ctx) {
+    const reportContent = yield* reportContentWithDiagnostics(ctx.app);
+    yield* ctx.skill.transform((editor) => {
+      editor.add(Info18.make({
+        id: ID4.make("opencode"),
+        name: Name2.make("OpenCode"),
+        description: OpencodeDescription2,
+        location: AbsolutePath2.make("/builtin/opencode.md"),
+        content: OpencodeContent2
+      }));
+      editor.add(Info18.make({
+        id: ID4.make("report"),
+        name: Name2.make("Report"),
+        description: REPORT_DESCRIPTION,
+        slash: true,
+        location: AbsolutePath2.make("/builtin/report.md"),
+        content: reportContent
+      }));
+    });
+  })
+});
+var reportContentWithDiagnostics = Effect.fn("SkillPlugin.reportContentWithDiagnostics")(function* (app) {
+  const plugins = yield* configuredPlugins();
+  return [
+    ReportContent2,
+    "",
+    "## Runtime Diagnostics Snapshot",
+    "",
+    "These values were captured when the built-in report skill was registered. Verify them before publishing.",
+    "",
+    `- opencode version: ${app.version}`,
+    `- install/channel: ${app.channel}`,
+    `- OS: ${os.type()} ${os.release()} (${os.platform()} ${os.arch()})`,
+    `- Terminal: ${terminal()}`,
+    `- Shell: ${shell()}`,
+    `- Active plugins: ${plugins.length === 0 ? "None found in config" : plugins.join(", ")}`
+  ].join(`
+`);
+});
+var configuredPlugins = Effect.fn("SkillPlugin.configuredPlugins")(function* () {
+  const config = yield* Service35;
+  return (yield* config.entries()).filter((entry) => entry.type === "document").flatMap((entry) => entry.info.plugins ?? []).map((entry) => typeof entry === "string" ? entry : entry.package).toSorted();
+});
+function terminal() {
+  return [
+    process.env.TERM_PROGRAM ? `TERM_PROGRAM=${process.env.TERM_PROGRAM}` : undefined,
+    process.env.TERM ? `TERM=${process.env.TERM}` : undefined,
+    process.env.COLORTERM ? `COLORTERM=${process.env.COLORTERM}` : undefined
+  ].filter((item) => item !== undefined).join(", ") || "Unavailable: terminal environment variables are not set";
+}
+function shell() {
+  return process.env.SHELL ?? process.env.ComSpec ?? process.env.COMSPEC ?? "Unavailable: shell environment variable is not set";
+}
+
+export { OpencodeContent2, ReportContent2, OpencodeDescription2, Plugin29, exports_skill2 };