> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xynthis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Codebase memory

> Point Xynthis at a repo so recall can answer questions about your code's content and structure.

Two commands teach Xynthis a codebase, and they answer different questions. `xynthis corpus add` indexes file *content*: chunks of code and prose that recall can retrieve by meaning. `xynthis code scan` extracts *structure*: a typed knowledge graph of functions, classes, imports, and call edges. Use both on a repo you work in daily.

## Indexing content: corpus add

```bash theme={null}
xynthis corpus add ~/project --name project --mask "**/*.rs"
```

This creates a named collection (defaulting to the folder's basename), walks the tree, chunks each file, and ingests the chunks into the Binary Memory Core. Code files are chunked along AST boundaries so a function stays one chunk; prose falls back to heading-aware splitting. Force one strategy with `--ast` or `--regex`.

Ingestion streams: files are read and chunked in windows of 64 paths at a time, ingested in batches of 128, so peak memory stays proportional to the window rather than the corpus. Chunks are deduplicated by BLAKE3 hash, which is what makes re-indexing cheap: unchanged content is skipped, not re-embedded.

The caps, and what falls outside them:

| Limit                    | Value                                                                                         |
| ------------------------ | --------------------------------------------------------------------------------------------- |
| Max size per file        | 2 MiB (larger files are skipped; they are logs, datasets, or binaries)                        |
| Max files per ingest run | 20,000                                                                                        |
| Always excluded          | `.git`, `target`, `node_modules`, `dist`, `build`, `venv`, `.venv`, `__pycache__`, `.xynthis` |

By default the folder is watched after indexing, so edits re-ingest automatically. Pass `--no-watch` to skip that, or toggle later with `xynthis corpus watch <name> on|off`.

Give each collection a one-line description of what it is; recall uses it to route queries to the right corpus:

```bash theme={null}
xynthis corpus context set project "Rust monorepo for the Acme billing service"
xynthis corpus context check     # lists collections still missing a description
```

## Managing collections

```bash theme={null}
xynthis corpus list              # ID, NAME, DOCS, CHUNKS, WATCH, CONTEXT
xynthis corpus status project    # size, last update, context-present flag
xynthis corpus update project    # re-index one collection (omit the name for all)
xynthis corpus remove project    # drops the index; never touches your source files
```

## Scanning structure: code scan

```bash theme={null}
xynthis code scan ~/project
```

```
scanned 'project' at /Users/you/project
  files=482 funcs=2114 classes=390 imports=1268
  triples added=8730, replaced=0, elapsed=2140ms
```

The scanner AST-parses every supported file (Rust, TypeScript, Python, Go, and Swift) and writes typed triples into the brain's knowledge graph: `code:contains_fn`, `code:contains_class`, `code:imports`, `code:imported_by`, `code:defined_in`, and `code:calls` (call sites resolved cross-file through a symbol table).

Re-scans are incremental: each file's extraction is cached keyed by a BLAKE3 content hash, so an unchanged file is replayed from cache instead of re-parsed. After a big refactor, pass `--replace` to wipe the previous scan's triples before ingesting, which also drops that repo's cache entries.

Defaults are 10,000 files and 50,000 triples per scan; raise them with `--max-files` and `--max-triples` (the summary warns when the triple cap was hit). `--label` overrides the repo name baked into entity ids, which otherwise defaults to the path basename.

## What recall can answer afterward

Recall is layered: it consults the knowledge graph and the corpus chunks in the same query, so both kinds of code knowledge surface together.

```bash theme={null}
xynthis recall "where is license validation implemented"
```

With the corpus indexed, questions about content work: "where is the retry backoff configured", "show me the chunk that handles webhook signatures". With the scan ingested, structural questions work: what functions a file contains, what a module imports, what calls a given function. Graph entities follow the pattern `code:<label>::<relative-path>`, and the `kg_query` MCP tool queries them directly if you are wiring your own client. In chat, you just ask; the agent routes to recall and the graph itself.