oh-my-opencode 5.0.0-beta.4 → 5.0.0-beta.40

package/dist/skills/data-scientist/references/execution-templates.md

@@ -1,197 +0,0 @@
-# Execution Templates
-
-## Template 1: DuckDB for Simple/Complex SQL Queries
-
-**Use when:**
-- Simple aggregation on single file
-- Complex multi-table joins
-- Heavy GROUP BY operations
-- Window functions with complex SQL logic
-- Ad-hoc exploration queries
-
-```python
-uv run --with numpy --with duckdb python -c "
-import duckdb
-
-# Simple query - direct file access
-result = duckdb.sql('''
-    SELECT
-        category,
-        COUNT(*) as count,
-        AVG(amount) as avg_amount,
-        SUM(amount) as total
-    FROM 'data.csv'
-    WHERE date >= '2024-01-01'
-    GROUP BY category
-    ORDER BY total DESC
-    LIMIT 10
-''').pl()
-
-print('**Results**')
-print(result)
-print(f'\\nProcessed {len(result)} categories')
-"
-```
-
-## Template 2: Polars for Filtering & Sorting
-
-**Use when:**
-- Primary operation is filtering large dataset
-- Sorting required
-- Chain transformations
-- Memory-efficient processing needed
-
-```python
-uv run --with numpy --with polars python -c "
-import polars as pl
-
-# Lazy evaluation for optimal performance
-result = (
-    pl.scan_csv('data.csv')  # Lazy scan
-    .filter(
-        (pl.col('amount') > 1000) &
-        (pl.col('status') == 'active') &
-        (pl.col('date') >= '2024-01-01')
-    )
-    .sort('amount', descending=True)
-    .head(100)
-    .collect()  # Execute optimized plan
-)
-
-print('**Filtered and Sorted Results**')
-print(result)
-print(f'\\nFound {len(result)} matching rows')
-"
-```
-
-## Template 3: Hybrid Approach (Best of Both)
-
-**Use when:**
-- Need joins AND heavy filtering
-- Complex SQL followed by transformations
-- Optimize different operation stages
-
-```python
-uv run --with numpy --with duckdb --with polars --with pyarrow python -c "
-import duckdb
-import polars as pl
-
-print('Phase 1: DuckDB for complex join (3x faster)')
-# DuckDB excels at joins
-joined = duckdb.sql('''
-    SELECT
-        o.order_id,
-        o.amount,
-        c.customer_id,
-        c.region,
-        p.category
-    FROM 'orders.csv' o
-    JOIN 'customers.csv' c ON o.customer_id = c.customer_id
-    JOIN 'products.csv' p ON o.product_id = p.product_id
-    WHERE o.date >= '2024-01-01'
-''').pl()  # Convert to Polars
-
-print(f'Joined {len(joined):,} rows')
-
-print('\\nPhase 2: Polars for ultra-fast filtering (128x faster)')
-# Polars excels at filtering
-filtered = (
-    joined
-    .filter(
-        (pl.col('amount') > 100) &
-        (pl.col('region').is_in(['North', 'South', 'East']))
-    )
-    .with_columns([
-        (pl.col('amount') * 1.1).alias('amount_with_tax')
-    ])
-)
-
-print(f'Filtered to {len(filtered):,} rows')
-
-print('\\nPhase 3: DuckDB for final aggregation (4x faster)')
-# Back to DuckDB for aggregation
-duckdb.register('filtered_data', filtered)
-final = duckdb.sql('''
-    SELECT
-        region,
-        category,
-        COUNT(DISTINCT customer_id) as customers,
-        SUM(amount_with_tax) as total_revenue,
-        AVG(amount_with_tax) as avg_transaction
-    FROM filtered_data
-    GROUP BY region, category
-    HAVING total_revenue > 10000
-    ORDER BY total_revenue DESC
-''').pl()
-
-print('\\n**Final Results**')
-print(final)
-"
-```
-
-## Template 4: Polars Streaming for Large Files
-
-**Use when:**
-- Dataset larger than available RAM
-- Need to process data in batches
-- Memory constraints
-
-```python
-uv run --with numpy --with polars python -c "
-import polars as pl
-
-# Streaming mode - processes data in chunks
-result = (
-    pl.scan_csv('huge_file.csv')
-    .filter(pl.col('status') == 'active')
-    .with_columns([
-        (pl.col('amount') * 1.1).alias('adjusted_amount')
-    ])
-    .groupby('category')
-    .agg([
-        pl.sum('adjusted_amount').alias('total'),
-        pl.count().alias('count')
-    ])
-    .collect(streaming=True)  # Streaming mode for large data
-)
-
-print('**Streaming Results**')
-print(result)
-print(f'\\nProcessed {result[\"count\"].sum():,} total rows')
-"
-```
-
-## Template 5: Visualization with Matplotlib
-
-**Use when:**
-- User requests charts, graphs, or plots
-- Exploratory data analysis (EDA)
-- Time-series or distribution analysis
-
-```python
-uv run --with numpy --with duckdb --with polars --with pyarrow --with matplotlib python -c "
-import duckdb
-import matplotlib.pyplot as plt
-
-# Query data
-result = duckdb.sql('''
-    SELECT
-        date,
-        SUM(amount) as total
-    FROM 'data.csv'
-    GROUP BY date
-    ORDER BY date
-''').pl()
-
-# Create visualization
-plt.figure(figsize=(10, 6))
-plt.plot(result['date'], result['total'])
-plt.xlabel('Date')
-plt.ylabel('Total Amount')
-plt.title('Daily Total Trends')
-plt.xticks(rotation=45)
-plt.tight_layout()
-plt.savefig('output.png')
-print('Chart saved to output.png')
-"
-```

package/dist/skills/data-scientist/references/integration-patterns.md

@@ -1,153 +0,0 @@
-# Integration Patterns: DuckDB ↔ Polars
-
-## Zero-Copy Conversions (FASTEST)
-
-### DuckDB → Polars (Recommended)
-
-```python
-import duckdb
-import polars as pl
-
-# Direct conversion with .pl() - zero-copy via Arrow
-df_polars = duckdb.sql("""
-    SELECT * FROM 'data.parquet'
-    WHERE amount > 100
-""").pl()  # Returns Polars DataFrame directly
-
-# Lazy version for large datasets
-lazy_df = duckdb.sql("SELECT * FROM 'data.parquet'").pl(lazy=True)
-result = lazy_df.filter(pl.col('status') == 'active').collect()
-```
-
-### Polars → DuckDB (Direct Reference)
-
-```python
-import duckdb
-import polars as pl
-
-# DuckDB can query Polars DataFrames directly by name
-df = pl.read_parquet('data.parquet')
-
-result = duckdb.sql("""
-    SELECT category, SUM(amount) as total
-    FROM df
-    GROUP BY category
-    ORDER BY total DESC
-""").pl()  # Query df directly, return as Polars
-```
-
-### Via Arrow (When Needed)
-
-```python
-# Polars → Arrow → DuckDB
-df_polars = pl.read_csv('data.csv')
-duckdb.register('my_table', df_polars.to_arrow())
-
-# DuckDB → Arrow → Polars
-arrow_table = duckdb.sql("SELECT * FROM data").arrow()
-df_polars = pl.from_arrow(arrow_table)
-```
-
-## WRONG vs RIGHT Patterns
-
-### ❌ NEVER - Using Pandas
-
-```python
-# FORBIDDEN - decisively slower than Polars/DuckDB on every operation!
-import pandas as pd
-df = pd.read_csv('data.csv')
-result = df.groupby('category')['amount'].sum()
-```
-
-### ✅ CORRECT - DuckDB for simple aggregation query
-
-```python
-import duckdb
-# Direct file query - no memory loading!
-result = duckdb.sql("""
-    SELECT category, SUM(amount) as total
-    FROM 'data.csv'
-    GROUP BY category
-""").pl()  # Fast, memory-efficient
-```
-
-### ❌ NEVER - Loading file before DuckDB query
-
-```python
-# WRONG - Unnecessary memory usage
-import polars as pl
-import duckdb
-df = pl.read_csv('data.csv')  # Loads entire file
-result = duckdb.sql("SELECT * FROM df WHERE amount > 100").pl()
-```
-
-### ✅ CORRECT - Let DuckDB query directly
-
-```python
-import duckdb
-# DuckDB queries file directly - much faster!
-result = duckdb.sql("""
-    SELECT * FROM 'data.csv'
-    WHERE amount > 100
-""").pl()
-```
-
-### ❌ NEVER - Eager evaluation in Polars
-
-```python
-# WRONG - Loads everything immediately
-import polars as pl
-df = pl.read_csv('large_data.csv')  # Eager load
-filtered = df.filter(pl.col('value') > 100)
-```
-
-### ✅ CORRECT - Lazy evaluation
-
-```python
-import polars as pl
-# Lazy - builds query plan, optimizes, executes once
-df = pl.scan_csv('large_data.csv')  # Lazy
-result = (
-    df
-    .filter(pl.col('value') > 100)
-    .groupby('category')
-    .agg(pl.sum('value'))
-    .collect()  # Execute optimized plan
-)
-```
-
-### ❌ NEVER - Unnecessary Conversions
-
-```python
-# WASTEFUL (DuckDB → Pandas → Polars)
-import duckdb, pandas as pd, polars as pl
-df_pd = duckdb.sql("SELECT * FROM 'data.csv'").df()  # requires pandas - the skill never ships it
-df_pl = pl.from_pandas(df_pd)
-```
-
-### ✅ CORRECT - Direct conversion
-
-```python
-# DIRECT (DuckDB → Polars via Arrow)
-import duckdb
-df_pl = duckdb.sql("SELECT * FROM 'data.csv'").pl()
-```
-
-### ❌ NEVER - Wrong tool for heavy filtering
-
-```python
-# SLOW (DuckDB not optimal for filtering)
-import duckdb
-result = duckdb.sql("""
-    SELECT * FROM 'huge.csv'
-    WHERE complex_filter = true
-""").pl()
-```
-
-### ✅ CORRECT - Use Polars for filtering
-
-```python
-# FAST (Polars 128x faster for filtering)
-import polars as pl
-result = pl.scan_csv('huge.csv').filter(pl.col('complex_filter')).collect()
-```

package/dist/skills/data-scientist/references/performance-benchmarks.md

@@ -1,37 +0,0 @@
-# Performance Benchmarks
-
-Routing heuristics distilled from public 2024-2025 results in the [db-benchmark suite](https://github.com/h2oai/db-benchmark) (rendered at [h2oai.github.io/db-benchmark](https://h2oai.github.io/db-benchmark/)) and from the vendors' own documentation ([duckdb.org](https://duckdb.org/), [pola.rs](https://pola.rs/)).
-
-**Read these as routing guidance, not guarantees.** Multipliers vary with dataset size, cardinality, data types, and hardware. When the choice materially matters, measure on the actual data.
-
-## Operation Performance Comparison
-
-| Operation Type      | Winner      | Indicative advantage | When to Use                                    |
-|---------------------|-------------|----------------------|------------------------------------------------|
-| **Filtering**       | **Polars**  | often the fastest by a wide margin (SIMD, predicate pushdown) | Single-table filters |
-| **Sorting**         | **Polars**  | typically the fastest | ORDER BY operations, ranking                   |
-| **Joins**           | **DuckDB**  | typically faster; richer join types | Multi-table joins, especially complex joins    |
-| **Aggregations**    | **DuckDB**  | typically faster on large datasets | GROUP BY, complex aggregations                 |
-| **Window Funcs**    | **Polars**  | typically faster | RANK, LAG/LEAD, running totals                 |
-| **Transformations** | **Polars**  | typically faster | Pivot, melt, string operations                 |
-| **Direct Query**    | **DuckDB**  | avoids loading to memory entirely | Ad-hoc exploration without loading to memory   |
-| **Streaming**       | **Polars**  | handles datasets larger than RAM | Datasets larger than RAM                       |
-
-Both tools are decisively faster than pandas on 1M+ row workloads, which is why pandas is banned outright in this skill.
-
-## Operation Detection Keywords
-
-Automatically detect operation types from user requests:
-
-- **Filter**: "where", "filter", "condition", "select rows", "find"
-- **Sort**: "sort", "order", "top", "bottom", "rank"
-- **Join**: "join", "merge", "combine tables"
-- **Aggregate**: "group", "sum", "avg", "count", "mean", "total", "aggregate"
-- **Transform**: "pivot", "melt", "reshape", "string operations", "clean", "transform"
-- **Window**: "running", "cumulative", "lag", "lead", "rank", "partition"
-
-## Benchmarking Notes
-
-- Public suites exercise typical analytical workloads (1M-100M rows).
-- Performance advantages are approximate and vary by dataset characteristics.
-- Real-world performance depends on data types, cardinality, and hardware.

package/dist/tools/call-omo-agent/background-agent-executor.d.ts

@@ -1,5 +0,0 @@
-import type { BackgroundManager } from "../../features/background-agent";
-import type { PluginInput } from "@opencode-ai/plugin";
-import type { CallOmoAgentArgs } from "./types";
-import type { ToolContextWithMetadata } from "./tool-context-with-metadata";
-export declare function executeBackgroundAgent(args: CallOmoAgentArgs, toolContext: ToolContextWithMetadata, manager: BackgroundManager, client: PluginInput["client"]): Promise<string>;

package/dist/tools/call-omo-agent/message-storage-directory.d.ts

@@ -1 +0,0 @@
-export { getMessageDir } from "../../shared";

package/dist/tools/delegate-task/model-string-parser.d.ts

@@ -1 +0,0 @@
-export { parseModelString, parseVariantFromModelID } from "@oh-my-opencode/model-core";

package/packages/lsp-tools-mcp/dist/lsp/cleanup-errors.d.ts

@@ -1 +0,0 @@
-export * from "@oh-my-opencode/lsp-core/lsp/cleanup-errors";

package/packages/lsp-tools-mcp/dist/lsp/constants.d.ts

@@ -1 +0,0 @@
-export * from "@oh-my-opencode/lsp-core/lsp/constants";

package/packages/lsp-tools-mcp/dist/lsp/language-mappings.d.ts

@@ -1 +0,0 @@
-export * from "@oh-my-opencode/lsp-core/lsp/language-mappings";

package/packages/lsp-tools-mcp/dist/lsp/process-signal-cleanup.d.ts

@@ -1 +0,0 @@
-export * from "@oh-my-opencode/lsp-core/lsp/process-signal-cleanup";

package/packages/lsp-tools-mcp/dist/missing-dependency-result.d.ts

@@ -1 +0,0 @@
-export * from "@oh-my-opencode/lsp-core/missing-dependency-result";

package/packages/omo-codex/plugin/components/codegraph/AGENTS.md

@@ -1,58 +0,0 @@
-# packages/omo-codex/plugin/components/codegraph/ (CodeGraph MCP Wrapper + Bootstrap Hooks)
-
-**Generated:** 2026-07-17 (7d664b96b)
-
-## OVERVIEW
-
-`@sisyphuslabs/codex-codegraph` (private, Node >=20, bin `omo-codegraph`). Wraps the external CodeGraph CLI (`@colbymchenry/codegraph`, pinned `1.5.0` through the shared `CODEGRAPH_PINNED_VERSION` and the component optionalDependency) behind a stdio MCP server plus Codex lifecycle hooks. Two committed dists ship in the published payload; rebuild `dist/` in the same change as `src/` edits.
-
-Codex wiring (all repo-relative to `packages/omo-codex/plugin/`):
-- **MCP:** `.mcp.json` server `codegraph` → `node components/codegraph/dist/serve.js` (`required: false`).
-- **SessionStart hook:** `hooks/session-start-checking-codegraph-bootstrap.json` → `dist/cli.js hook session-start` (timeout 5).
-- **PostToolUse hook:** `hooks/post-tool-use-checking-codegraph-init-guidance.json`, matcher `^(codegraph[._].*|mcp__codegraph__.*)$` → `dist/cli.js hook post-tool-use`.
-- Both hooks registered in `.codex-plugin/plugin.json`; Windows variants dispatch via `components/bootstrap/scripts/node-dispatch.ps1`.
-
-Serve pipeline (`src/serve.ts`): OMO SOT config gate (`[codex].codegraph.enabled=false` → unavailable stub) → resolve binary (`OMO_CODEGRAPH_BIN` env → bundled → provisioned `~/.omo/codegraph/bin` → PATH) → Node support gate (major 20-24; >=25 crashes CodeGraph mid-indexing; `CODEGRAPH_ALLOW_UNSAFE_NODE=1` overrides) → auto-provision into `~/.omo/codegraph` unless `codegraph.auto_provision=false` → bridge JSON-RPC to `codegraph serve --mcp`. Project cwd resolved from `OMO_CODEGRAPH_PROJECT_CWD` → `OMO_CODEGRAPH_SESSION_START_CWD` → `PWD` → wrapper cwd. When the binary is missing/disabled, `mcp-unavailable.ts` still answers `initialize`/`tools/*` with the skip reason so Codex startup never fails.
-
-Hook pipeline (`src/hook.ts` + `src/session-start-*.ts`): `hook session-start` checks only the exact filesystem marker `<projectRoot>/.codegraph/codegraph.db`; it never invokes the upstream CLI for status. An exact database skips as initialized, an ancestor database records `skipped-nested-root`, and only a definitive no-database result may acquire the per-project atomic lock and spawn `hook session-start-worker`. Live locks record `skipped-locked`; stale locks recover into an exponential cooldown instead of spawning immediately. Worker failures and skips persist a cooldown stamp (15 minutes by default, doubling to a 24-hour cap; configurable with Codex-only `codegraph.session_start_cooldown_ms`, minimum 60000), while success clears it. The worker prepares the workspace, invokes only `codegraph init` with a 60-second tree timeout, and records success only after the exact project database appears. Hook suppressions and worker outcomes append to `~/.omo/codegraph/session-start.jsonl`. `hook post-tool-use` emits init guidance when a codegraph tool result indicates an uninitialized project. `cli.js` with no hook subcommand falls through to serve.
-
-## includeCode CONTRACT (commit 4cf383c5b)
-
-`src/mcp-bridge.ts` rewrites the upstream `codegraph_node` contract in-flight: `tools/list` responses get a clarified description + `includeCode` schema description, and `tools/call` results replace "Structural outline only" text. Contract: `includeCode=true` returns leaf-symbol source only; container symbols (classes, interfaces, structs, enums, modules, namespaces) return structural outlines with member lists BY DESIGN: for container source, request a specific member symbol or file mode with `symbolsOnly=false` plus `offset`/`limit`. Pinned by `test/serve-mcp-bridge.test.ts`.
-
-## KEY FILES
-
-| File | Purpose |
-|------|---------|
-| `src/serve.ts` | MCP entry: config/resolution/Node gates, provisioning, bridge or unavailable stub |
-| `src/cli.ts` | Hook CLI router: `hook session-start` / `hook post-tool-use` / `hook session-start-worker` / serve fallback |
-| `src/hook.ts` | SessionStart exact-root decision pipeline + detached worker spawn |
-| `src/post-tool-use-hook.ts` | PostToolUse init guidance emission |
-| `src/session-start-project.ts` | Exact database and ancestor-coverage filesystem probes |
-| `src/session-start-lock.ts` | Atomic per-project worker lock + stale recovery |
-| `src/session-start-cooldown.ts` | Persistent exponential failure cooldown state |
-| `src/session-start-worker.ts` | Background bootstrap orchestration and lock lifecycle |
-| `src/session-start-command.ts` | Provision/resolve + bounded `codegraph init` invocation |
-| `src/session-start-outcome.ts` | `session-start.jsonl` outcome writer |
-| `src/mcp-bridge.ts` | Stdio JSON-RPC forwarder; per-request framed/line response-mode tracking; codegraph_node contract rewrites; awaits stdio writes and SIGKILLs the child on response-forwarding failure |
-| `src/mcp-unavailable.ts` | Reason-bearing stub MCP server for disabled/missing binary |
-| `src/serve-invocation.ts` | win32 invocation shim: `.cmd`/`.bat` via `cmd.exe /d /s /c`, `.js`/`.mjs`/`.cjs` via `process.execPath` (mirrored by `resolveCodegraphCommandInvocation` in session-start-worker) |
-| `src/hook-types.ts` | Shared hook/worker option + outcome types |
-
-## WHERE TO LOOK
-
-| Task | Location |
-|------|----------|
-| Resolution order, provisioning, Node gate, env, gitignore/workspace prep | `packages/utils/src/codegraph/` (`resolve.ts`, `provision.ts`, `node-support.ts`, `env.ts`, `workspace.ts`, `guidance.ts`), bundled at build time |
-| `[codex].codegraph` config keys (`enabled`, `auto_provision`, `trustedCodegraphInstallDir`) | `packages/omo-codex/plugin/shared/src/config-loader.ts` |
-| JSON-RPC framing primitives | `packages/mcp-stdio-core/src/` |
-| Build / test / typecheck | `bun run build` (bun build → `dist/serve.js` + `dist/cli.js`, target node ESM), `bun test ./test`, `tsc --noEmit` |
-
-## NOTES
-
-- This component tests with `bun test` (unlike the vitest-based `lsp` sibling); given/when/then style.
-- `src/` imports reach sibling packages via relative paths (`../../../../../utils/src/...`); they are inlined by `bun build`, so runtime `dist/` has zero deps beyond Node.
-- `serve.ts` and SessionStart command provisioning derive their version from the shared `CODEGRAPH_PINNED_VERSION`; the component optionalDependency must match that pin.
-- `trustedCodegraphInstallDir` overrides the `~/.omo/codegraph` install dir and is forwarded to children as `CODEGRAPH_INSTALL_DIR`.
-- `resolution.source === "env"` is never auto-provisioned over: a user-set `OMO_CODEGRAPH_BIN` pointing at a missing file skips the MCP instead of silently substituting a download.
-- `runBridgedCodegraphProcess` awaits every stdio write and races `childExit` against response forwarding; a forwarding error (e.g. parent stdout `EPIPE`) rejects the serve promise, destroys the child pipes, and `SIGKILL`s the codegraph child if still alive so a held-open child is never orphaned. Pinned by `test/serve-mcp-bridge-lifecycle.test.ts` and the held-open case in `test/serve-mcp-bridge.test.ts`.