v0.1.15

Tempest v0.1.15

This release ships Atlas 1.3.0 in full and fixes three bugs that surfaced immediately after — a tokenizer that was misfiring on its own new CLI flags, a cold-start bottleneck that sent concurrent connections through a single warming worker, and an MCP surface that wasn't exposing the new asset tools by default.

What's in this release

Atlas 1.3.0

The big feature: you can now attach external documents (markdown files, notes, PDFs, any text asset) to the Atlas graph and have them participate in retrieval alongside code. An agent asking "how does X work" can get back both the implementation and the design doc that explains it — from one atlas_explore call.

Asset nodes and describes edges

Assets are first-class nodes with kind='asset'. They reuse the existing FTS trigger, edge table, and embedding sync without a separate index, so search automatically covers them. Attach an asset to any code symbol or file with a describes edge; the edge is the association — retrieval follows it the same way it follows any other graph edge. The Atlas facade exposes the full lifecycle (addAsset, link, unlink, remove, list, getAsset, semanticSearch).

Chunking and PDF extraction

Long documents are sliced into 1 500-character chunks with 100-character overlap and stored in the new asset_chunks table (migration v10). syncEmbeddings drains chunks alongside nodes, and vector search rolls chunk hits back up to their parent asset before ranking, so you get the document — not a fragment — in results. PDF text extraction is handled by pdf-parse as an optional dependency: missing install leaves extractedText null, so PDFs still index (and search via FTS), just without vector recall.

CLI write path

Asset management is exposed as CLI flags on server-entry.ts: --asset-add, --asset-remove, --asset-link, --asset-unlink, --asset-list (with optional --asset-linked-to). All write operations are CLI-only by design — the MCP surface stays read-only.

Three new read-only MCP tools

atlas_assets, atlas_asset_content, and atlas_semantic_search are the read surface agents can call. They cover what atlas_explore doesn't: listing what assets exist, pulling an asset's extracted text directly, and running a pure vector search across code and assets combined.

---

Fix: grep-poisoning tokenizer splitting on the wrong boundary

shouldSkipGrep decides whether a query looks like a symbol search (and should skip the ripgrep channel to avoid noise). It was splitting the query on [^A-Za-z0-9_]+ — which tears server-entry into server and entry and strips -- from --asset-add, discarding the hyphen signal that makes those tokens look like identifiers. The result: queries that are obviously about CLI flags or hyphenated module names weren't being classified as symbol-search intent, so the ripgrep channel ran on them and injected unrelated hits.

Fixed by splitting on whitespace first, then trimming leading/trailing punctuation from each token. --asset-add stays as one token of length 9; server-entry stays as one token with a hyphen. The identity classifier (identShape) then sees the tokens as they were intended.

Fix: cold-start bottleneck on concurrent connections

The query pool was seeding with spawnOne() on construction — one eager worker ready for the first request. Under a single-connection workload that's fine; under two or more concurrent connections arriving before the pool warmed fully, all of them queued behind that one worker's 30–45 s load window.

warmToTarget() now runs on construction and after every worker transitions to READY. It grows toward maxSize up to MAX_CONCURRENT_SPAWN pending cold-starts at a time, so the pool converges on full capacity in the background regardless of queue depth. The next burst of connections finds workers already warm.

Fix: asset tools not exposed by default

DEFAULT_MCP_TOOLS contained only explore. The three new asset tools (assets, asset_content, semantic_search) were available but hidden — an agent using the default MCP surface had no way to list assets, read their content, or run a semantic-only search without opting in via ATLAS_MCP_TOOLS. They're now in the default set. The rationale for why explore alone is insufficient (its narrow "symbol graph" scope) applies in reverse here: these three cover different axes, so the "presence steers mis-picks" concern that keeps search/callers/callees hidden doesn't apply.

Platform Support

Platform	Status
Windows 11 (x64)	Supported. Pre-built binary available. MSI and NSIS installers.
macOS	Supported. Separate arm64 and x86_64 builds.
Linux	Supported. x86_64 and arm64 AppImage + deb.

Windows requires WebView2 (bundled automatically when necessary).

Database Branches (from v0.1.5) additionally require Docker; without it the feature stays dormant and everything else works normally.

Atlas semantic search (from v0.1.10) downloads a ~25 MB embedding model on first opt-in.

What's next

Atlas follow-ups still on the list: fusing asset hits into atlas_explore results so you don't have to call semantic_search separately, and a first-run onboarding flow for attaching your docs directory. Beyond that: Threads polish, Hephaestus hardening across all three OSes, Automations out of beta, and keyboard-native everything.