Fix/workflow executor provider api #49
Merged
Conversation
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
Add detailed documentation analyzing three key aspects of OpenCode: 1. MCP server connection support - covers entry points, configuration, connection lifecycle, protocol handling, tool registration, and error handling 2. Session multiple connections and message ordering - explains how multiple clients can connect to the same session and how message ordering is guaranteed through callback queues and locks 3. Multi-server statefulness - analyzes why OpenCode servers are stateful and require session affinity, documenting in-memory state that prevents horizontal scaling without distributed coordination
Add four additional documentation files analyzing OpenCode architecture: 1. event-historical-replay.md - Explains that OpenCode does NOT replay historical events on client connect; uses pull-based model for history and push-based for real-time updates 2. lsp-utilization.md - Comprehensive analysis of how OpenCode uses LSP including 19 built-in language servers, diagnostics injection, and symbol search capabilities 3. golang-project-prompts.md - Documents what prompts are sent for Go projects; importantly, there are NO Go-specific instructions - the model infers conventions from project structure and its training 4. lsp-selection-mechanism.md - Details how OpenCode selects which LSP server to use based on file extensions, root detection, and configuration hierarchy
Document the complete system prompt sent to LLMs including: - All prompt template files (anthropic.txt, beast.txt, gemini.txt, etc.) - Step-by-step construction process in resolveSystemPrompt() - Full anthropic.txt content (106 lines) with all sections - Environment context template with variable substitution - Custom instructions loading from AGENTS.md/CLAUDE.md - Final 2-message structure for caching optimization - Complete example of final prompt for Claude on Go project - Model-specific variations (GPT, Gemini, etc.)
Add design document for enabling clients to register tool definitions with the server and have the server delegate execution back to the client. Key aspects covered: - Protocol design with new message types for tool requests/responses - Client tool registry for server-side management - SDK client tools manager for registering and handling tools - Both SSE and WebSocket communication options - Security considerations (auth, sandboxing, rate limiting) - Error handling and timeout management - Usage examples for common scenarios - Phased implementation plan
Comprehensive design documentation for deploying OpenCode as a multi-tenant web service including: - System architecture and component design - Authentication, authorization, and multi-tenancy - Database schema and storage strategies - Horizontal scaling and Kubernetes deployment - Security controls and compliance requirements - API design with versioning and streaming support
Alternative storage design for MySQL deployments with: - Snowflake-style BIGINT ID generation (8 bytes vs 16) - No foreign keys, stored procedures, or triggers - Application-level referential integrity - Efficient cursor-based pagination - Sharding strategy by organization - Connection pooling and read/write splitting
…lity analysis - Document all server-side APIs for session, message, and task management - Document all client-side APIs including Bus events, Storage, and Provider - Analyze event system for real-time subagent monitoring - Provide implementation guide for new clients - Assess feasibility of building clients in various languages (TypeScript, Python, Go, Rust) - Include architecture patterns and feature parity matrix - Document existing SDK (@opencode-ai/sdk) and web client (packages/desktop) - Add packages overview showing all available client implementations
Comprehensive analysis of OpenCode's todo and task tool systems including: - TodoWrite and TodoRead tool definitions and data models - Task tool for subagent spawning - Internal storage design and event bus architecture - Usage guidelines and prompts from todowrite.txt, todoread.txt, task.txt - System integration points and UI rendering - Data flow diagrams and common patterns - File references with line numbers This documentation provides a complete reference for understanding how OpenCode implements task management and agent delegation.
Create a detailed 14-section whitepaper synthesizing all architectural analysis into a cohesive document covering: 1. System Overview - Architecture style, technology stack, components 2. Core Architecture - Instance model, HTTP API, message flow 3. Session Management - Lifecycle, sequential processing, multi-client 4. MCP Server Integration - Configuration, lifecycle, tool registration 5. LSP Integration - 19 language servers, selection algorithm, usage 6. System Prompt Construction - Assembly pipeline, model-specific prompts 7. Event System - Bus architecture, event flow, client subscription 8. Storage Layer - File-based JSON storage, lock implementation 9. Concurrency Control - Multi-layer locking, race prevention 10. Multi-Server Considerations - Statefulness analysis, deployment options 11. Security Model - Permission system, MCP/LSP security 12. Performance Characteristics - Bottlenecks, optimizations, scalability 13. Design Decisions - Language-agnostic prompts, file storage, locking 14. Future Considerations - Enhancement opportunities, evolution phases Includes comprehensive diagrams, decision rationales, trade-off analysis, and complete reference appendices for files, events, and configuration.
Add detailed feature plan for implementing custom system and initial prompt templates per session. This will enable users to create specialized agents (e.g., data analyst, security auditor) by providing custom prompt templates when starting a session. Key features: - Session-level custom prompt templates (persistent) - Support for file-based and inline prompts - Template resolution from project/global directories - Auto-detection of file vs inline prompts - Backward compatible with existing sessions - Comprehensive implementation plan with ~145 LOC The plan includes: - Current architecture analysis - Technical design and schema changes - Implementation roadmap (3 phases) - API changes and CLI integration - Security considerations - Testing strategy - Example templates for data analyst and security auditor Ready for review and implementation.
…2.0)
Expand the custom system prompt feature plan to include comprehensive
template variable interpolation in Phase 1 core implementation.
Major additions:
- 17 built-in variables (PROJECT_NAME, GIT_BRANCH, PRIMARY_LANGUAGE, etc.)
- Custom variables via session, config, or environment (OPENCODE_VAR_*)
- Variable syntax: ${VAR}, ${VAR:default}, ${VAR|filter}
- Filters: uppercase, lowercase, capitalize
- Auto-detection of primary programming language
- Git branch detection
- Variable resolution priority order
Implementation details:
- interpolateVariables() function with full variable map
- detectPrimaryLanguage() helper (extension-based detection)
- getGitBranch() helper for git integration
- extractEnvVariables() for OPENCODE_VAR_* support
- applyFilter() for variable transformations
- Updated Session schema to include variables field
- Task 1.5 added to Phase 1 implementation plan
Examples updated:
- Data analyst template with PROJECT_NAME, DATE variables
- Security auditor template with GIT_BRANCH, PLATFORM variables
- New team analyst example showing custom variables
- API examples showing variables field usage
Document changes:
- Updated executive summary with variable features
- Moved variable interpolation from Phase 4 to Phase 1
- Updated file modification summary (~250 LOC total)
- Version bump to 2.0 with changelog
Ready for implementation.
…lation
Implement core functionality for session-level custom prompt templates with
template variable interpolation support.
- Added `customPrompt` field to Session.Info schema with type, value, loadedAt, and variables
- Updated Session.create schema to accept customPrompt parameter (string or object)
- Implemented parseCustomPromptInput() helper for auto-detecting file vs inline prompts
- Updated createNext() function to persist custom prompt metadata
- Added fromSession() function to load and interpolate session-level prompts
- Implemented resolveTemplatePath() for file resolution (project, global, absolute paths)
- Added interpolateVariables() function for template variable substitution
- Implemented 17 built-in variables:
* PROJECT_NAME, PROJECT_PATH, WORKING_DIR
* GIT_BRANCH, GIT_REPO, PRIMARY_LANGUAGE
* PLATFORM, DATE, TIME, DATETIME
* USER, HOSTNAME, SESSION_ID, SESSION_TITLE
* AGENT_NAME, MODEL_ID, OPENCODE_VERSION
- Added detectPrimaryLanguage() helper (extension-based detection)
- Added getGitBranch() helper for git integration
- Added extractEnvVariables() for OPENCODE_VAR_* support
- Added applyFilter() for variable transformations (uppercase, lowercase, capitalize)
- Variable syntax support: ${VAR}, ${VAR:default}, ${VAR|filter}
- File size limit: 100 KB for prompt templates
- Modified resolveSystemPrompt() to accept sessionID parameter
- Added call to SystemPrompt.fromSession() in priority order:
1. Per-request system parameter
2. Agent-specific prompt
3. Session-level custom prompt (NEW)
4. Model-specific default
5. Environment context
6. Custom instructions
- Updated all call sites to pass sessionID
- Session.create API now validates customPrompt field
- Added promptVariables field to Config.Info schema for global custom variables
- Security: path traversal prevention in resolveTemplatePath()
- File-based templates: load from .opencode/prompts/ or ~/.opencode/prompts/
- Inline templates: pass prompt text directly
- Auto-detection: automatically distinguish file paths from inline text
- Custom variables: session-specific, config-based, or environment (OPENCODE_VAR_*)
- Variable resolution priority: session > config > environment > built-in > default
- Backward compatible: sessions without custom prompts work as before
Files modified:
- src/session/index.ts (~50 LOC)
- src/session/system.ts (~180 LOC)
- src/session/prompt.ts (~10 LOC)
- src/config/config.ts (~5 LOC)
Total: ~245 LOC
Add CLI flags and template discovery commands for custom prompt templates. - Added --prompt <template> flag to run command (auto-detect file/inline) - Added --prompt-file <path> flag for explicit file mode - Added --prompt-inline <text> flag for explicit inline mode - Updated session creation in run.ts to pass customPrompt parameter - Implemented getCustomPrompt() helper to parse CLI args - Updated both attach and bootstrap session creation paths - Created new `prompts` command with actions: list, show - `opencode prompts list`: Lists all available templates * Shows project templates (.opencode/prompts/) * Shows global templates (~/.opencode/prompts/) * Displays template name and size in KB * Groups by location (project vs global) - `opencode prompts show --name <template>`: Displays template details * Shows location, path, and size * Preview mode: first 10 lines (default) * Full mode: complete content (--verbose flag) * Helpful error message if template not found - Registered PromptsCommand in main CLI - Auto-detection of file vs inline prompts in run command - Convenient template browsing and inspection - Clear usage examples in command output - Support for .txt and .md template files ```bash opencode run --prompt data-analyst.txt "analyze this data" opencode run --prompt-file ~/templates/security.txt "audit code" opencode run --prompt-inline "You are a Python expert" "refactor this" opencode prompts list opencode prompts show --name data-analyst.txt opencode prompts show --name security.txt --verbose ``` Files modified/added: - src/cli/cmd/run.ts (~20 LOC modified) - src/cli/cmd/prompts.ts (~200 LOC new) - src/index.ts (~2 LOC modified) Total: ~222 LOC
…mpts This commit implements Phase 3 of the custom system prompts feature, focusing on user experience improvements: ## Template Management (Task 3.1) - Added create/edit/delete actions to prompts command - Implemented createTemplate() with base template support - Supports --base flag to copy from existing templates (anthropic, beast, gemini, codex, qwen, polaris) - Auto-creates template directory if it doesn't exist - Opens template in $EDITOR after creation - Supports both project and global templates via --global flag - Implemented editTemplate() to modify existing templates - Finds templates in project or global directories - Opens in configured $EDITOR - Implemented deleteTemplate() with confirmation prompt - Interactive yes/no confirmation before deletion - Supports --global flag for explicit global template deletion ## Session Inspection (Task 3.2) - Added custom prompt display in TUI session list - Shows 📄 emoji and file path for file-based prompts - Shows 📝 emoji for inline prompts - Displayed as subtitle in session list dialog - Added custom prompt display in CLI run command - Shows "Custom prompt: file: <path>" or "Custom prompt: inline prompt" - Displayed after session creation in both attach and bootstrap modes - Uses info styling to make it visible but not intrusive Changes: - src/cli/cmd/prompts.ts: Added create/edit/delete functions (~200 LOC) - src/cli/cmd/run.ts: Added custom prompt info display in both execution paths - src/cli/cmd/tui/component/dialog-session-list.tsx: Added subtitle with custom prompt indicator All three phases of the custom system prompts feature are now complete.
Add detailed protocol specification document covering: - Architecture overview (separate processes, HTTP communication) - Transport layer details (HTTP/1.1, SSE) - Data formats (JSON schemas) - Communication patterns (request-response, SSE, bidirectional queue) - Complete API endpoint reference - Event system documentation (27+ event types) - Error handling specifications - Security considerations - Practical examples This documentation provides a complete reference for understanding and implementing the TUI client-server communication protocol.
Add comprehensive documentation for AI response streaming: - New Streaming Pattern section explaining SSE-based streaming - Updated Send Message endpoint with streaming behavior warning - Enhanced message.part.updated event documentation with delta field - Updated practical examples showing real streaming events - Clarified that HTTP response waits while SSE delivers incremental updates Key clarifications: - Streaming works via Server-Sent Events, not HTTP response streaming - Text deltas delivered in real-time via message.part.updated events - Delta field contains incremental text chunks for efficient rendering - 16ms batching window for event optimization - HTTP POST blocks until AI completes, then returns final message Implementation references added for processor and delta handling.
Analyze the repository's testing infrastructure and strategies including: - Testing framework overview (Bun, Go native, pytest) - Test categories by package (51 total test files) - Mock infrastructure patterns - CI/CD pipeline configuration - Critical gap analysis: no real model testing or agent evals Key finding: The codebase has solid unit/integration tests but lacks AI-specific testing against real models and performance evaluation.
Analyze how existing test infrastructure can validate the client tools feature from client-side-tools.md: - Bun test framework for ClientToolRegistry unit tests - Instance.provide() pattern for isolated test context - Python subprocess integration tests for API routes - Mock HTTP transport patterns for SDK testing - Event bus testing for tool request events - Retry/timeout patterns for execution timeouts Key finding: Current infrastructure fully supports the feature testing except for end-to-end tests requiring real AI model interaction.
Add comprehensive protocol documentation for client-side tools: - New API endpoints: register, unregister, result, pending SSE - WebSocket alternative protocol for low-latency communication - Data types: ClientToolDefinition, ExecutionRequest, Result, Error - New event types: client-tool.registered/executing/completed/failed - Communication pattern diagram showing full execution flow - Complete example of tool registration and execution - Security considerations and permission integration - Timeout and error handling specifications Bumps protocol version to 1.1.0
Add infrastructure for SDK clients to register and execute custom tools that run on the client rather than the server. New files: - src/tool/client-registry.ts: Core registry for client tools with registration, execution, timeout handling, and event emission - src/server/client-tools.ts: HTTP API routes for tool registration, result submission, and SSE streaming of tool requests API endpoints: - POST /client-tools/register - Register tools for a client - DELETE /client-tools/unregister - Remove tools - POST /client-tools/result - Submit execution result - GET /client-tools/pending/:clientID - SSE stream for tool requests - GET /client-tools/tools/:clientID - Get client's tools - GET /client-tools/tools - Get all client tools Events added: - client-tool.request - Tool execution requested - client-tool.registered/unregistered - Tool lifecycle - client-tool.executing/completed/failed - Execution status Tests: - 30 unit tests for ClientToolRegistry (all passing) - Integration test scaffolding for API endpoints (skipped in CI)
Add 33 tests covering the custom system prompt template functionality: - parseCustomPromptInput auto-detection (file vs inline) - interpolateVariables with built-in and custom variables - Variable filters (uppercase, lowercase, capitalize) - Default values for missing variables - fromSession loading and interpolation - File size limits and error handling - OPENCODE_VAR_* environment variable extraction - Edge cases and complex templates
Evaluate the feasibility of running the opencode AI assistant over go-memsh's memory file system with client-server architecture: - Analyze both go-memsh and opencode architectures - Propose three integration options (Protocol Bridge, Embedded Go, Dual-Mode Provider) - Recommend Protocol Bridge approach with ~2-4 weeks implementation effort - Include tool mapping analysis, implementation plan, and code examples - Document required go-memsh enhancements and risk assessment
Add new commands designed for efficient LLM tool integration: - stat: Returns file metadata as JSON (size, mtime, mode, is_dir, perm) - readfile: Returns raw file content with offset/limit support - writefile: Writes stdin to file with append and --parents options - findex/find2: Enhanced find with -maxdepth, -mindepth, -mtime, -size, -empty - grepex/grep2: Enhanced grep with -r, -l, -L, -A/-B/-C context, --include/--exclude - exists: Quick file/directory existence check with -f/-d flags Also fixes build error in stdio() function by properly handling interp.HandlerCtx which returns a struct value, not a pointer. All new commands have comprehensive tests covering edge cases.
Implement @opencode-ai/memsh-cli, a TypeScript client for connecting to the go-memsh service. This package provides the same tool features as packages/opencode for working over the memory file system. Key features: - MemshClient: WebSocket JSON-RPC client for go-memsh communication - Session: High-level session management for shell operations - Tools mirroring packages/opencode functionality: - bash: Execute shell commands - read: Read file contents - write: Write file contents - edit: Edit files with string replacement - glob: Find files by pattern - grep: Search file contents - ls: List directory contents - CLI entry point for interactive and single-command usage - Unit tests for client and tool infrastructure
Implement a Go client SDK in go-memsh/client that provides the same functionality as the TypeScript memsh-cli package. Key components: - Client: WebSocket JSON-RPC client with REST API support - Session management (create, list, remove) - Auto-reconnect support - Request/response handling - Session: High-level session wrapper - File operations (read, write, exists, mkdir, rm, ls) - Working directory management - Command execution helpers - Tools mirroring packages/memsh-cli functionality: - BashTool: Execute shell commands - ReadTool: Read file contents with line numbers - WriteTool: Write/create files - EditTool: Edit files with string replacement - GlobTool: Find files by pattern - GrepTool: Search file contents - LsTool: List directory contents All 15 unit tests pass.
Comprehensive analysis of rewriting the OpenCode server in Go: - Feasibility assessment: HIGH - technically feasible - 8-12 week implementation timeline across 7 phases - Protocol remains unchanged (REST + SSE), TUI client compatible - Leverages existing Go code (go-memsh, SDK) patterns
Comprehensive planning documentation for Go OpenCode server rewrite: - README.md: Overview, project structure, timeline - 01-foundation.md: Core types, storage, event bus - 04-tool-system.md: Tool framework and implementations - 05-permission-security.md: Permission system, mvdan/sh bash parsing - test-plan.md: Testing strategy matching TypeScript test infrastructure - technical-specs.md: API contracts, data formats, integration requirements Key decisions: - Use mvdan/sh (already in go-memsh) for bash command parsing - Go standard testing + testify for test framework - Match existing REST + SSE protocol for TUI compatibility
Comprehensive evaluation of Google's ADK-Go as a potential replacement for the Vercel AI SDK. Includes: - Feature comparison matrix - How-to documentation for Go implementations - Code examples for streaming, providers, tools, MCP, and sessions - Gap analysis and recommendations
Updated the evaluation to include CloudWeGo Eino as the recommended framework for the OpenCode Go implementation. Key findings: - Eino provides near feature parity with Vercel AI SDK - Multi-provider support: Claude, OpenAI, Gemini, Ollama, etc. - Built-in AWS Bedrock support for Claude - Cache control and extended thinking for Claude - MCP integration via official MCP SDK - ReAct agent and graph orchestration built-in - Production-tested at ByteDance scale ADK-Go relegated to reference patterns only due to Gemini-only limitation.
Add four missing plan documents for the Go OpenCode server rewrite by analyzing the TypeScript source code: - 02-http-server.md: HTTP server, routing, middleware, SSE streaming - 03-llm-providers.md: LLM provider abstraction (Anthropic, OpenAI, Google) - 06-session-processing.md: Agentic loop and message processing - 07-advanced-features.md: LSP, MCP, multi-agent system These documents complete the full implementation plan referenced in plan/go-opencode/README.md.
Implement a comprehensive DSL for defining and executing agentic workflows: Schema & Types: - WorkflowDefinition: Define workflows with inputs, agents, steps, and orchestrator config - Step types: agent, pause, parallel, conditional, loop, transform - Runtime state tracking with WorkflowInstance and StepState Parser: - Parse workflows from Markdown (with YAML frontmatter), YAML, or JSON - Support for inline agent definitions with custom prompts and tools - Validation of step references, agent references, and dependency cycles Executor/Orchestrator: - Execute workflows with configurable modes: auto, guided, manual - Human review pauses with approval/rejection flow - Parallel step execution with concurrency control - Conditional branching and loop support - Variable interpolation between steps - Event-driven progress tracking Workflow Tool: - Start, resume, cancel, and check status of workflows - Real-time updates via event subscriptions - Structured output with step states and variables Example workflows: - Code review: multi-agent analysis, review, and fix workflow - Feature implementation: research, plan, implement, test workflow - Parallel analysis: concurrent security, performance, and style checks
Enhance the workflow DSL with LLM-powered decision making:
Schema changes:
- Add `conditionType` field to ConditionalStep ("expression" | "llm")
- Add `conditionType` field to LoopStep for while/until conditions
- Add new `LLMEvalStep` for complex LLM-based evaluations
- Supports boolean, choice, text, and JSON output formats
- Configurable model and temperature
Executor changes:
- Implement `executeLLMEvalStep` for the new step type
- Implement `evaluateLLMCondition` helper for LLM-based yes/no decisions
- Update conditional step to support LLM evaluation
- Update loop step to support LLM-based while/until conditions
- Add detailed logging for LLM evaluations
Example workflow:
- Add iterative-refinement.md demonstrating:
- LLM evaluation for quality assessment
- Loop with LLM-based exit condition
- Conditional branching based on LLM decisions
Add comprehensive code review findings from analyzing eino source: - Graph implementation patterns (compose/graph.go) - Chain API as syntactic sugar for linear workflows - Workflow field-level data mapping via AddInput() - ReAct agent graph orchestration with tool call branching - Multi-Agent Host pattern for specialist delegation - Eino-ext components: MCP integration, sequential thinking Include architectural mapping table showing how OpenCode DSL concepts translate to Eino implementations, plus proposed Go implementation patterns for DSL-to-Eino conversion.
This implements the go-opencode server providing a single binary deployment option compatible with the original TypeScript server behavior. Features implemented: - Phase 1: Core types (Session, Message, Parts), storage layer with file locking, event bus system, XDG-compliant configuration loading - Phase 2: HTTP server with Chi router, REST API endpoints, SSE streaming - Phase 3: Provider abstraction using ByteDance Eino framework with Anthropic and OpenAI provider support (including Bedrock/Azure) - Phase 4: Tool framework with core tools (Read, Write, Edit, Bash, Glob, Grep, List) The server uses the Eino LLM framework for unified provider abstraction and tool integration, enabling seamless switching between LLM providers.
Adds comprehensive unit tests for: - Storage layer (Put, Get, Delete, List, Scan, Exists, concurrent access) - Event bus (Subscribe, SubscribeAll, Publish, PublishSync, unsubscribe) - Types (JSON serialization for Session, Message, Parts) - HTTP handlers (session CRUD, config, file operations) - SSE streaming (SSE writer, heartbeats, event filtering, headers) Fixes a bug in storage/lock.go where Lock() would fail when the parent directory didn't exist. Now creates the directory before acquiring lock.
Add comprehensive unit tests for LLM provider and tool system: Provider tests (provider_test.go, registry_test.go): - ParseModelString parsing and validation - Model priority sorting - ConvertToEinoTools conversion - JSON schema parameter parsing - Message and tool call conversion - Provider registry CRUD operations - Concurrent access safety - InitializeProviders configuration handling Tool tests (registry_test.go, tools_test.go): - Tool registry operations - Eino tool wrapper integration - ReadTool file operations with offset/limit - WriteTool file creation and overwrite - EditTool string replacement and replace_all - ListTool directory listing - BashTool command execution with timeout - GlobTool pattern matching - GrepTool regex search - Tool context metadata handling All 104 tests passing.
Mark completed acceptance criteria in plan documents: - Phase 1 (Foundation): All criteria complete - Phase 2 (HTTP Server): Core criteria complete - Phase 3 (LLM Providers): Eino integration complete - Phase 4 (Tool System): All tools and tests complete Update README timeline with status indicators showing 104 tests passing across all implemented phases.
Implement the complete permission system for controlling tool execution: - Add permission package with types, permission actions (allow/deny/ask) - Implement bash command parser using mvdan/sh for shell command analysis - Add permission checker with ask flow and event publishing - Implement wildcard pattern matching for bash command permissions - Add doom loop detection to prevent infinite tool call loops - Integrate permission checking into bash tool with external dir validation Key features: - Parse complex bash commands (pipelines, chains, subshells) - Detect dangerous commands (rm, mv, cp, chmod, etc.) and validate paths - Check for external directory access outside working directory - Support pattern-based permission configuration (e.g., "git *", "npm install *") - Publish permission request events via event bus for TUI integration Test coverage: 42 new tests covering all permission components
Phase 6 implements the core agentic loop and message processing system: New Files: - internal/session/agent.go: Agent configuration types (default, code, plan agents) - internal/session/processor.go: Main processor for handling message processing - internal/session/loop.go: Agentic loop execution with retry and step limits - internal/session/stream.go: LLM stream processing with SSE events - internal/session/tools.go: Tool execution with permission checks and doom loop detection - internal/session/system.go: System prompt builder with environment context - internal/session/compact.go: Message compaction for context overflow - internal/session/processor_test.go: Unit tests for processor components Key Features: - Agentic loop with max steps (50) and max retries (3) - Streaming updates via callback and event bus - Tool execution with metadata updates - Doom loop detection (3+ identical calls triggers permission check) - Session abort functionality - Context overflow detection and compaction - System prompt with provider-specific headers - Custom rules from AGENTS.md/CLAUDE.md - Token and cost tracking All tests passing (165+ tests across Phases 1-6).
Phase 7 Advanced Features implementation: - Agent System (internal/agent/) - Multi-agent configuration with built-in agents (build, plan, general, explore) - Registry for agent management with custom config loading - Permission handling per agent with tool and bash filtering - LSP Client (internal/lsp/) - Language Server Protocol client with JSON-RPC over stdio - Support for TypeScript, Go, Python, Rust language servers - Operations: hover, workspace/document symbols, definition, references - MCP Client (internal/mcp/) - Model Context Protocol client for tool integration - HTTP and stdio transports for remote/local servers - Tool listing and execution with proper namespacing - Task Tool (internal/tool/task.go) - Sub-agent spawning for autonomous task handling - Support for general, explore, and plan agent types - Executor interface for flexible task processing All 247 tests passing across Phase 1-7 components.
Compare go-opencode with TypeScript opencode implementation: - Configuration file format and field differences - CLI command and flag gaps - Environment variable support - Detailed implementation plan for compatibility
Replace custom wildcard matching implementations with the doublestar/v4 package for proper glob pattern support including ** patterns. Changes: - go-opencode: Update agent.go matchWildcard to use doublestar for complex patterns while preserving simple string matching for basic * patterns - go-memsh: Update llm_commands.go find command to use doublestar.Match instead of regex conversion for glob patterns - go-memsh: Update collectFiles to use doublestar for include/exclude pattern matching - go-memsh: Update client/tools.go GlobTool to use doublestar for proper ** pattern support when filtering files
- Add Cobra CLI framework with subcommands (serve, run, models, auth, agent, debug)
- Support ~/.opencode/ config location for TypeScript compatibility
- Support ~/.config/opencode/ for XDG compliance
- Add OPENCODE_CONFIG and OPENCODE_CONFIG_DIR environment variables
- Add config interpolation for {env:VAR} and {file:path} placeholders
- Use tidwall/jsonc for proper JSONC (JSON with comments) parsing
- Add ProviderOptions for nested TypeScript-style provider configuration
- Expand config types: Schema, Username, Theme, Share, Tools, MCP, etc.
- Add comprehensive tests for all configuration features
- Deduplicate config loading to prevent duplicate instructions
Document custom implementations that could be replaced with established GitHub packages, categorized by priority (high/medium/low) with detailed rationale for each recommendation.
Replace custom JSON-RPC implementation with the official MCP Go SDK (github.com/modelcontextprotocol/go-sdk v1.1.0): - Remove transport.go with manual JSON-RPC protocol handling - Rewrite client.go to use SDK's Client, ClientSession, and transports - Simplify types.go with SDK type adapters (FromSDKTool, FromSDKResource) - Use SDK's CommandTransport for stdio and SSEClientTransport for HTTP - Reduce code by ~500 lines while maintaining API compatibility Benefits: - Standardized protocol implementation - Better connection management and error handling - Built-in support for MCP spec versions - Reduced maintenance burden
Replace custom Levenshtein distance and exponential backoff implementations with battle-tested open source packages: - Use agnivade/levenshtein for string distance calculation in edit tool - Use cenkalti/backoff/v4 for retry logic with jitter and context awareness - Keep custom SSE implementation (documented decision: better suited to our event bus) Changes: - internal/tool/edit.go: Use agnivade/levenshtein package - internal/session/loop.go: Use cenkalti/backoff/v4 with jitter, max interval, context support - internal/server/sse.go: Add documentation explaining why custom SSE is kept - internal/session/processor_test.go: Add tests for new backoff function Benefits: - Levenshtein: Better edge case handling, optimized for large strings - Backoff: Jitter prevents thundering herd, context-aware cancellation See docs/github-packages-opportunities.md for full analysis.
- Add yaml@2.8.0 to dependencies for workflow parser - Add 'workflow' prefix to Identifier for WorkflowInstance schema 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
- Handle undefined arg value in cli.ts - Add index signature to ExecuteCommandParams - Add index signatures and export metadata interfaces - Use z.number() instead of z.coerce.number() in ReadTool 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
… modules - workflow/executor.ts: Add proper orchestrator defaults with typed values - workflow/executor.ts: Fix status comparison with type assertion - workflow/index.ts: Fix duplicate id by spreading config first - workflow/index.ts: Remove unused reload() function - workflow/tool.ts: Change pausedStep type from null to undefined - session/system.ts: Use fs.existsSync instead of Bun.file().existsSync() - dialog-session-list.tsx: Remove customPrompt UI (SDK type not updated) - client-tools.ts: Add type assertions for resolver() calls - test/client-tools-api.test.ts: Fix stdout type assertion 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Replace standard Go log package with zerolog for structured JSON logging: - Add internal/logging package wrapping zerolog with convenient helpers - Update cmd/opencode-server and cmd/opencode/commands to use new logging - Support --print-logs and --log-level CLI flags for log control - Pretty-print console output for development mode - Update github-packages-opportunities.md to mark logging as completed
- Add --log-file flag to write logs to /tmp/opencode-YYYYMMDD-HHMMSS.log - Support multi-writer output (console + file simultaneously) - Add configuration logging: - Log each config file loaded with path - Log configuration summary (model, providers, agents, MCP servers) - Add LLM interaction logging: - Log request details (provider, model, message count, step) - Log user message content (truncated) - Log response with tokens, duration, finish reason - Log assistant response and tool calls - Add GetLogFilePath() and Close() helpers to logging package
- Add ThreeDotsLabs/watermill as pub/sub infrastructure for event bus - Use watermill's gochannel.GoChannel for in-memory pub/sub - Maintain full API compatibility with original implementation - Expose PubSub() method for advanced use cases (middleware, routing) - Add proper Close() method for graceful shutdown - Update opportunity doc to mark watermill integration as done
- Add ARK provider implementation using eino-ext/components/model/ark - Add Ginkgo/Gomega testing framework with comprehensive test utilities - Create citest/ directory with service, server, and e2e test suites - Add test utilities for server lifecycle, HTTP client, and SSE streaming - Add plan documents for integration testing strategy - Update registry to initialize ARK provider from config 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
- Change writeSuccess() to return `true` instead of `{"success": true}`
- Add Title field to CreateSessionRequest for session creation
- Update Service.Create() to accept optional title parameter
- Fix listSessions to list all sessions when no directory specified
- Return empty array [] instead of null for empty session lists
- Add OpenAI provider support with gpt-4o-mini as default model
- Make CI test fixture switchable between OpenAI and ARK providers
- Fix SSE headers to flush immediately for proper streaming
- Fix stream processing for delta vs accumulated content modes
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The Provider.getModel() API now returns just the model info directly, with Provider.getLanguage(model) as a separate function to get the language model. Updated executor.ts to use the new API pattern. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.