fix(plugin): derive id from package name

[regulusleow]

Summary

Export plugin id in src/plugin.ts to satisfy the V1 PluginModule shape required by OpenCode's file/path plugin loading path.

Note: The type-safety refactor commits that were originally part of this PR have been cherry-picked and merged separately via #93.

Problem

When loading opencode-mem from a local filesystem path (rather than npm install), the V1 plugin module shape requires an explicit id. Without it, loading fails with:

Path plugin ... must export id

Changes

• Export plugin id in src/plugin.ts, derived from package.json.name with a safe fallback
• Keep V1 PluginModule default export shape: { id, server }
• Add contract test assertions to verify id exists, is non-empty, and matches package.json.name

Validation

bun test tests/plugin-loader-contract.test.ts

Original work by @regulusleow.

[Copilot]

Pull request overview

This PR refactors the OpenAI Chat Completions provider to use tighter internal typings and adds a plugin id export (derived from package.json.name) to satisfy the OpenCode 1.3.x plugin-loader contract, along with expanded tests and config guidance.

Changes:

• Tightened typing in OpenAIChatCompletionProvider (request/response message shapes, config typing, and response parsing).
• Exported plugin id (and included it in the default PluginModule export) and added a contract test asserting id matches the package name.
• Added provider-focused tests for the OpenAI chat path and clarified config template comments for OpenAI-compatible endpoints.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
tests/plugin-loader-contract.test.ts	Adds an assertion that the built plugin default export includes a non-empty id matching package.json.name.
tests/openai-chat-completion-provider.test.ts	New test suite covering OpenAI chat provider behavior (headers, apiUrl, request body, tool-call loop behavior).
src/services/ai/providers/openai-chat-completion.ts	Refactors provider code to tighten types and introduce type guards + typed request/response objects.
src/plugin.ts	Exports id derived from package.json.name and includes it in the default PluginModule export.
src/config.ts	Updates config template comments to clarify OpenAI-compatible usage and examples.

Comments suppressed due to low confidence (1)

src/services/ai/providers/openai-chat-completion.ts:26

• ToolCallResponse.choices[].message.content is typed as string | undefined, but OpenAI Chat Completions can return content: null when the assistant emits tool_calls. With the current type, isToolCallResponse() narrows data to ToolCallResponse even when content is actually null, making the typing unsound and undermining the goal of “tightened typing”. Consider widening this to string | null (and optionally reflecting that in APIMessage.content too).

interface ToolCallResponse {
  choices: Array<{
    message: {
      content?: string;
      tool_calls?: Array<{
        id: string;
        type: "function";
        function: {
          name: string;
          arguments: string;
        };
      }>;
    };
    finish_reason?: string;

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[regulusleow]

@NaNomicon The Copilot-flagged items have been addressed and tested locally (18/18 passing):

• isToolCallResponse → hasNonEmptyChoices: renamed and strengthened with minimal field validation
• content || "" → split ?? "" (session) / ?? null (API messages): preserves OpenAI's null for tool-calling responses

As for the plugin.ts id change — happy to drop it if it's not needed for mainline usage. Let me know either way.