Skip to main content

Module init

Module init 

Source
Expand description

Initialize the recall-echo memory system.

Creates the directory structure and template files needed for four-layer memory (graph, curated, short-term, long-term), picks an extraction provider, installs Claude Code’s hooks, registers the MCP server with every agent CLI on the machine, and downloads the embedding model.

§What init asks

As little as it can get away with. Setup friction is what loses users, so every question here has to earn itself:

  • one agent CLI installed — no question at all, that is the provider;
  • several — one short menu, defaulted to the CLI the session is running under, because that is the subscription the user just proved they have;
  • none — the full provider menu, since now the choice really is open.

Nothing prompts unless stderr is a terminal ([atty_check]); a scripted or piped install takes the same defaults without blocking.

§What it does without asking

Hooks, MCP registration and the model download are consequences of what is installed, not preferences, so they happen. Each is idempotent, each reports itself, and none of them can fail the command:

  • hooks are matched by command name, so re-running never duplicates one;
  • MCP servers live in a map keyed by name in every client, so re-registering the same name is a no-op (see crate::agent_cli);
  • the model is a content-addressed cache, so a second warm is a no-op.

§The build-directory guard

A binary under target/debug or target/release is a test harness or a working copy, not something a user’s hooks and MCP configs should be pinned to for the life of the install. Everything that writes outside the entity root — hooks, MCP registration — is skipped there, which is also what keeps cargo test from repointing the developer’s live tooling at a test binary or downloading 127 MB per test.

Functions§

run
Initialize memory structure at the given entity root.
run_with_reader
Testable init with injectable reader.