Metadata-Version: 2.3
Name: solidoc-solidjs-mcp
Version: 0.2.1
Summary: High-performance, local FastEmbed vector MCP server for SolidJS documentation
Author: Nitin
Author-email: Nitin <pypi@600613017.xyz>
License: MIT
Requires-Dist: mcp>=1.2.0,<2.0.0
Requires-Dist: fastembed>=0.4.0
Requires-Dist: numpy>=1.26.0
Requires-Dist: typer>=0.12.0
Requires-Dist: rich>=13.7.0
Requires-Dist: pydantic>=2.7.0
Requires-Python: >=3.10
Description-Content-Type: text/markdown

# SolidOC (solidoc-solidjs-mcp)

High-performance, local FastEmbed ONNX vector + SQLite FTS5 Model Context
Protocol (MCP) server for SolidJS documentation and @solid-primitives.

- **Hybrid search**: 384-dim BAAI/bge-small-en-v1.5 embeddings + SQLite FTS5
  BM25, fixed candidate pools, deterministic rankings.
- **Clean chunks**: heading-aware splitting, version-badge stripping,
  tiny-section merging, cross-doc dedupe; every chunk fully inside the
  model's 512-token window (zero silent truncation).
- **Native stdio**: local execution, zero network ports.
- **Additive-only installer**: never rewrites your existing MCPs or settings.

## Install (Windows and WSL — same package, simultaneously)

One wheel (`py3-none-any`) serves both OSes. Install it as an *application*
so the `solidoc` command lands on PATH: `pipx install` or `uv tool install`.
Plain `pip install` / `uv pip install` only drops the library into a Python
environment (no command on PATH) — if you went that way by habit and get
`solidoc: command not found`, reinstall with one of the two below.

What `solidoc install` does — all three, every time:

1. Registers the server in the global OpenCode config (one additive entry;
   sibling MCPs, comments, and formatting are preserved).
2. Copies the prebuilt docs database (~18.6 MB) into the per-OS user path
   (see table below). An existing database is left byte-identical.
3. Downloads the embedding model (~70 MB, once per OS) into the per-OS
   model cache (see table below).

Total first-install download is ~90 MB. Offline? The config entry still
applies; the data steps print a skip line and happen on the first search
instead — so the first answer is the slow one, never the install.

Windows (PowerShell):

```powershell
pipx install solidoc-solidjs-mcp
# or: uv tool install solidoc-solidjs-mcp
solidoc install
solidoc search "createSignal" --limit 1   # verify: expect "Type signature" at 0.5948
```

WSL / Linux (bash). The `export` line is one-time setup — persist it so
every new shell finds the command:

```bash
uv tool install solidoc-solidjs-mcp
# or: pipx install solidoc-solidjs-mcp
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
export PATH="$HOME/.local/bin:$PATH"   # this shell only; new shells use .bashrc
solidoc install
solidoc search "createSignal" --limit 1   # verify: expect "Type signature" at 0.5948
```

> **Close OpenCode first.** It holds locks on the server executable and the
> database; installing, uninstalling, or reinstalling while it runs will
> fail or half-finish.

Each OS keeps its **own** database, model cache, and config (see paths
below). Never point the DB across the Windows/WSL boundary (`/mnt/...`):
SQLite locking is unreliable there and both sides will corrupt or stall.

No step above builds anything from source: the wheel already contains the
database and the code, so install is copy + download + one config entry.

### Per-OS paths

| What                  | Windows                                            | WSL / Linux                          |
|-----------------------|----------------------------------------------------|--------------------------------------|
| Server executable     | pipx venv `Scripts\solidoc.EXE` (on PATH)          | pipx venv `bin/solidoc` (on PATH)    |
| Vector database       | `%USERPROFILE%\.solidoc\solidoc.db`                | `~/.solidoc/solidoc.db`              |
| Embedding model cache | `%TEMP%\fastembed_cache`                           | `$TMPDIR/fastembed_cache` or `~/.cache/fastembed` |
| Global MCP config     | `%USERPROFILE%\.config\opencode\opencode.jsonc`    | `~/.config/opencode/opencode.jsonc`  |
| Repo-local MCP config | `<repo>\opencode.jsonc`                            | `<repo>/opencode.jsonc`              |

## Usage (commands run standalone — no uv/pip prefix needed)

```bash
solidoc serve                    # boot the MCP stdio server (what OpenCode launches)
solidoc search "createSignal"    # test hybrid search in the terminal
solidoc search "query" --category primitives --limit 3
solidoc install                  # global config, from anywhere (the simple default)
solidoc install <path>           # repo-local install into that directory
solidoc install --global         # explicit global (same as bare)
solidoc uninstall                # global entry + wipe DB + model cache (asks first)
solidoc uninstall <path>         # same, for that directory
solidoc uninstall --global --yes # same, global scope, no prompt
solidoc build --docs ./assets    # rebuild the vector DB from markdown (rare)
```

`install` is additive-only: sibling MCPs, comments, and formatting in your
config are preserved (verified by `test_installer.py`). If your main config
file is unparseable, it is backed up, left untouched, and the entry goes
into a sibling `opencode.json` that OpenCode merges automatically.

`uninstall` is a full wipe of solidoc artifacts only: our config entry, the
SQLite database, and our model-cache subtree. Everything else is left
byte-identical. Removing the package itself is a second, separate step —
and order matters: `solidoc uninstall` **first** (it needs the CLI
present), `pip uninstall solidoc-solidjs-mcp` second. Reversed order strands
the database with no tool to remove it.

## Rebuilding the database

Only needed when the documentation sources change. From the source tree
(`assets/` lives in this repo, so clones can rebuild anywhere):

```bash
uv run solidoc build --docs ./assets --db solidoc/solidoc.db   # ~40 min, single process
```

Expect per-batch log lines (`batch 12/57 ... rate=1.5/s`); a flat 0% for the
first minutes is normal (model load), but any batch stalled >5 min is not —
stop it with Ctrl+C (workers exit with the terminal) and report it.

## WSL validation (no Windows crossover)

The wheel bundles one OS-portable database (relative paths, float32 blobs,
cross-platform SQLite). Install copies it into `~/.solidoc/` and downloads
the model (~70 MB) automatically; after installing the tool (see Install
above, including the one-time PATH line):

```bash
solidoc install
solidoc search "createSignal" --limit 1   # instant after provisioning
```

No build, no manual copy. What stays forbidden is *running* two servers
against one shared file across `/mnt` (locking) — each OS keeps its own
copy. If the bundled DB ever misbehaves, fall back to a native WSL rebuild
from the cloned `assets/` instead.

## Troubleshooting

- **First search is slow**: install provisions the DB + model (~70 MB), so
  this only happens when install ran offline — the first search then fetches
  what is missing, and everything is local after that.
- **`solidoc: command not found` after install**: you used `pip install` /
  `uv pip install` (library into an environment, no command on PATH).
  Reinstall with `pipx install solidoc-solidjs-mcp` or
  `uv tool install solidoc-solidjs-mcp`. On WSL/Linux, also check the
  one-time `~/.bashrc` PATH line from Install above (new shells need it).
- **Install/uninstall errors about locked files**: quit OpenCode first.
- **Unparseable config**: the installer backs it up, leaves it alone, and
  prints the exact block to paste manually.

## Release checklist (maintainers)

1. Bump `version` in pyproject.toml (+ uv.lock) and commit + push code.
2. Only when the docs changed: rebuild the DB (`solidoc build --docs
   ./assets --db solidoc/solidoc.db`, ~40 min, filepaths stored relative, no
   machine paths leak), commit the DB + `assets/` (yes, the binary lives in
   git — it is the release artifact) and push. Code-only releases reuse the
   committed DB blob untouched.
3. Run both suites with the venv python directly (`uv run` can hit
   locked-EXE sync in dev): `test_determinism.py`, `test_installer.py`.
4. `uv build`, then audit: wheel must contain `solidoc/solidoc.db` (sha256
   matches the committed blob), must not contain `__pycache__` (`tests/`
   shipping inside is accepted house practice).
5. Clean-venv trial with an isolated HOME: install the wheel, bare `install`
   from a repo dir must land global and provision data, `solidoc serve
   --help` exits 0, first `search` answers.
6. Publish, then validate with a real pipx/uv-tool install on each OS.
