local-first code-knowledge daemon

insrc parses your repos into a graph + vector store, answers questions with citation-grounded context, and drives an autonomous define → design → plan → build workflow — all through your local claude / codex CLI sessions. No API keys, no data leaves your box.

get started how it works source
insrc — analyze 
$ insrc analyze "how does the workflow tracker push issues to GitHub?"
◆ decompose → 3 explorations · module.profile · symbol.locate · doc.constraint
◆ grounding on the dependency-closure graph … 41 entities, 7 relations
◆ synthesizing (citation-grounded) …

The tracker chain lives in src/workflow/tracker-auto.ts. On approval,
autoPushEpicOnHld / autoPushStoryOnLld / autoPushTasksOnPlan create typed
issues (Epic▸Story▸Task) as native sub-issues, committing the artifacts
and linking the blobs back from each issue. [tracker-auto.ts:112]

$

what's inside

▚

Indexer

tree-sitter parsing for TS, Python, Go, Java & Scala into a typed entity/relation graph with deterministic IDs.

architecture
⬡

Daemon & IPC

a background process that owns every DB, exposed over a JSON-RPC Unix socket. CLI, MCP & IDE all talk to it.

architecture
▦

Storage

LMDB-backed graph layer + LanceDB vectors for ANN search + DuckDB for the data-driver query tools.

architecture
⚒

~110 built-in tools

file · git · shell · http · web · gh · k8s · pkg · ssh · test · graph · db · data · code · cloud capability wrappers.

tools
◈

Providers

Ollama for local LLM + embeddings, and CliProvider wrapping the claude + codex CLIs. No REST.

providers
◎

Analyze framework

10 exploration recipes + a context builder that returns a verified 7-layer, citation-grounded bundle.

analyze
⟿

Workflow framework

define → design.epic → design.story → plan → build, with approval gates, open-question resolution & a GitHub tracker.

workflow
▮

Interactive CLI

a full-screen ink (React) TUI with Daemon / Repos / Workflows / Setup panes.

cli

at a glance

Everything routes through one daemon. Clients never open a database directly — the daemon is the single owner of the graph, the vectors and the tool registry.

claude / codex CLI insrc TUI VSCode fork │ │ │ └──────────┬─────────┴─────────┬─────────┘ ▼ ▼ MCP servers JSON-RPC over insrc_analyze_step ~/.insrc/daemon.sock insrc_workflow_step │ └──────────┬─────────┘ ▼ ┌────────────────────────┐ │ DAEMON │ owns all DB access │ registry · queue · fs │ │ watcher · tool exec │ └───────────┬────────────┘ ┌────────────────┼────────────────┐ ▼ ▼ ▼ LMDB graph Lance vectors DuckDB entities/edges ANN / embeddings data-driver tools
read the architecture

60-second start

bash
# build the daemon
$ npm install && npm run build

# launch the interactive TUI — add a repo from the Repos pane (press 'a')
$ npx insrc

# ask a grounded question about the codebase
$ insrc analyze "where is the repo registry contract enforced?"
full getting-started guide

principles

non-negotiable
  • Local-first. Embeddings are computed locally by Ollama; the graph + vectors live on your disk under ~/.insrc/.
  • No direct cloud REST. Cloud LLM access happens only through the installed claude and codex CLI binaries — auth & quota stay with your CLI OAuth sessions.
  • Accuracy is primary; cost is the least priority. Given an accurate-but-expensive path and a cheap-but-lossy one, insrc chooses accuracy.
  • No raw file dumps. Context is always structured entity summaries + relations from the graph, never a blind file paste.