config/ — Application Configuration & Prompt Templates

config/ — Application Configuration & Prompt Templates

All application configuration defined as Pydantic BaseModel schemas with hardcoded defaults. No YAML/TOML/JSON config files — the system boots with sane defaults and secrets come from Vault at runtime. The global config singleton is the canonical access point for all settings.

Files

• __init__.py — Re-exports AppConfig and the config singleton. Also initializes tools.registry first (import order matters for circular dep avoidance)
• config.py — Pure schema definitions (~800 lines of Pydantic BaseModel classes). Every config section lives here: ApiConfig, EmbeddingsConfig, LTMemoryConfig, PeanutGalleryConfig, etc. No logic, no side effects — just data shapes with defaults and descriptions
• config_manager.py — Runtime orchestrator. Defines AppConfig (root config aggregating all sections), handles system prompt loading, provides config.get("api.max_tokens") dot-notation access, dynamic tool config via __getattr__, and creates the singleton via config = initialize_config() at module load
• system_prompt.txt — Mira's core system prompt (identity, behavioral directives, output format). Loaded once at startup by AppConfig._load_system_prompt(). Template variables: {first_name}, {user_context}, {relative time since account creation} — substituted by working_memory/core.py at runtime
• announcement.py — Announcement system module. Reads announcement.json once at startup into a module-level cache. load_announcement() called during lifespan, get_cached_announcement() used by cns/api/data.py to serve to frontend
• announcement.json — Live announcement config. Set id + message to show a banner, set both to null to hide. Requires app restart
• announcement.sample.json — Reference example for announcement format
• vault.hcl — Local dev HashiCorp Vault config (file storage, TCP on 127.0.0.1:8200, no TLS). Consumed by Vault binary, not Python

Subdirectories

• prompts/ — LLM prompt templates for all subsystems (extraction, feedback, synthesis, subcortical, etc.). See prompts/CLAUDE.md

Key Entry Points

Config Sections

Patterns to Follow

Accessing Config

Always use the singleton: from config import config. Then dot-access: config.api.max_tokens, config.lt_memory.extraction.fuzzy_dedup_threshold. For dynamic key access: config.get("api.max_tokens") or config.require("api.max_tokens") (raises on None).

Adding New Config

1. Define a Pydantic BaseModel in config.py with Field(default=..., description=...)
2. Add it as a field on AppConfig in config_manager.py
3. Every field must have a default — no required fields (the system must boot without external config)

Secrets vs Config

• Config values (thresholds, model names, timeouts): Hardcoded defaults in Pydantic schemas
• Secrets (API keys, DB URLs, passwords): Lazy Vault lookups via properties on AppConfig (e.g., config.api_key). These use deferred imports to avoid circular deps

Dynamic Tool Config

Accessing config.<tool_name>_tool triggers __getattr__ → registry lookup. If the tool registered a custom Pydantic config class, it's used; otherwise a default {ToolName}Config(enabled=True) is auto-generated.

System Prompt Template Variables

system_prompt.txt uses {first_name}, {user_context}, and {relative time since account creation} — substituted by the working memory composition layer (working_memory/core.py:_handle_compose_prompt), not by config itself. LoRA behavioral directives are injected as a separate system prompt section by LoraTrinket, not inline.

Prompt Loading Convention

Each service loads its own prompts from config/prompts/ via Path("config/prompts"). There is no centralized loader. See prompts/CLAUDE.md for the full catalog.