1038 changed files with 36183 additions and 245824 deletions
--- a/.agents/skills
+++ b/.agents/skills
@ -1 +0,0 @@
 ../skills
--- a/.claude/skills
+++ b/.claude/skills
@ -1 +0,0 @@
 ../skills
--- a/.env.template
+++ b/.env.template
@ -8,35 +8,9 @@
 # Application Settings
 # =============================================================================
 LOG_LEVEL=INFO
-PERFORMANCE_LOG_FORMAT=compact # compact|rich
+FASTAPI_HOST=0.0.0.0
-# API server processes used by the Docker entrypoint (default: 1).
+FASTAPI_PORT=8000
-# Each process owns a separate pool when connection pooling is enabled.
+# SESSION_PEERS_LIMIT=10
 # API_WORKERS=1
 # SESSION_OBSERVERS_LIMIT=10
 # GET_CONTEXT_MAX_TOKENS=100000
 # MAX_FILE_SIZE=5242880 # Bytes
 # MAX_MESSAGE_SIZE=25000 # Characters
 # Embedding settings
 # EMBED_MESSAGES=true
 # EMBEDDING_VECTOR_DIMENSIONS=1536
 # EMBEDDING_MAX_INPUT_TOKENS=8192
 # EMBEDDING_MAX_TOKENS_PER_REQUEST=300000
 # EMBEDDING_MODEL_CONFIG__TRANSPORT=openai
 # EMBEDDING_MODEL_CONFIG__MODEL=text-embedding-3-small
 # EMBEDDING_MODEL_CONFIG__MAX_BATCH_SIZE=10
 # EMBEDDING_MODEL_CONFIG__OVERRIDES__BASE_URL=
 # EMBEDDING_MODEL_CONFIG__OVERRIDES__API_KEY_ENV=
 # LANGFUSE_HOST=
 # LANGFUSE_PUBLIC_KEY=
 # LANGFUSE_SECRET_KEY=
 # COLLECT_METRICS_LOCAL=false
 # LOCAL_METRICS_FILE=metrics.jsonl
 # REASONING_TRACES_FILE=traces.jsonl  # Path to JSONL file for reasoning traces
 # NAMESPACE="honcho"
 # =============================================================================
 # Database Settings (REQUIRED)
@ -47,18 +21,14 @@ DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@localhost:5432/postgres
 # Optional database settings
 # DB_SCHEMA=public
 # DB_POOL_CLASS=default
 # DB_POOL_SIZE=10
 # DB_MAX_OVERFLOW=20
-# DB_POOL_TIMEOUT=5  # seconds a pooled checkout waits for a free connection (QueuePool only)
+# DB_POOL_TIMEOUT=30
 # DB_POOL_RECYCLE=300
 # DB_POOL_PRE_PING=true
 # DB_POOL_USE_LIFO=true
 # DB_SQL_DEBUG=false
 # DB_TRACING=false
 # Per-connection establish timeout (seconds) so a single connection attempt
 # fails fast instead of hanging when the server/pooler is unreachable.
 # DB_CONNECT_TIMEOUT_SECONDS=2
 # =============================================================================
 # Authentication Settings
@ -71,185 +41,70 @@ AUTH_USE_AUTH=false
 # AUTH_JWT_SECRET=your-secret-key-here
 # =============================================================================
-# LLM Provider (REQUIRED)
+# LLM API Keys (REQUIRED for full functionality)
 # =============================================================================
-# Honcho uses LLMs for memory extraction, summarization, dialectic chat, and
+# OpenAI API key for embeddings
-# dream consolidation. The server will fail to start without a provider configured.
+LLM_OPENAI_API_KEY=your-openai-api-key-here
-#
+
-# Quick start: set LLM_OPENAI_API_KEY below to use the built-in defaults.
+# Anthropic API key for dialectic and deriver functionality
-# Text-generation features default to transport = "openai" and
+LLM_ANTHROPIC_API_KEY=your-anthropic-api-key-here
-# model = "gpt-5.4-mini". Embeddings default to transport = "openai" and
+
-# model = "text-embedding-3-small". For OpenAI-compatible proxies
+# Google API key for summarization (if using Gemini)
-# (OpenRouter, Together, Fireworks, vLLM, Ollama, LiteLLM), override
+# LLM_GEMINI_API_KEY=your-google-api-key-here
-# MODEL_CONFIG__MODEL and MODEL_CONFIG__OVERRIDES__BASE_URL on each feature
+
-# section you want to route through that endpoint.
+# Groq API key for query generation (if using Groq)
-# Models must support tool calling (function calling).
+# LLM_GROQ_API_KEY=your-groq-api-key-here
-#
+
-# Supported transports: openai, anthropic, gemini
+# Base URL for OpenAI Compatible Requests if you want to use a different provider
-# Each transport picks up its API key from the corresponding LLM_*_API_KEY.
+# LLM_OPENAI_COMPATIBLE_BASE_URL=
-# Base URLs are set per-module via MODEL_CONFIG__OVERRIDES__BASE_URL.
+# LLM_OPENAI_COMPATIBLE_API_KEY=
 #
 LLM_OPENAI_API_KEY=your-api-key-here
 # LLM_ANTHROPIC_API_KEY=
 # LLM_GEMINI_API_KEY=
 # =============================================================================
 # LLM Configuration
 # =============================================================================
 # Global LLM settings
-# LLM_DEFAULT_MAX_TOKENS=2500
+# LLM_DEFAULT_MAX_TOKENS=1000
-# LLM_MAX_TOOL_OUTPUT_CHARS=10000  # Max chars for tool output (~2500 tokens)
+# LLM_DEFAULT_TEMPERATURE=0.0
-# LLM_MAX_MESSAGE_CONTENT_CHARS=2000  # Max chars per message in tool results
+
 # Dialectic LLM settings
 # LLM_DIALECTIC_PROVIDER=anthropic
 # LLM_DIALECTIC_MODEL=claude-3-7-sonnet-20250219
 # Query generation LLM settings
 # LLM_QUERY_GENERATION_PROVIDER=groq
 # LLM_QUERY_GENERATION_MODEL=llama-3.1-8b-instant
 # Summarization LLM settings
 # LLM_SUMMARY_PROVIDER=google
 # LLM_SUMMARY_MODEL=gemini-2.0-flash-lite
 # LLM_SUMMARY_MAX_TOKENS_SHORT=1000
 # LLM_SUMMARY_MAX_TOKENS_LONG=2000
 # Embedding settings
 # LLM_MAX_EMBEDDING_TOKENS=8192
 # LLM_MAX_EMBEDDING_TOKENS_PER_REQUEST=300000
 # =============================================================================
-# Deriver (Background Worker)
+# Agent Settings
 # =============================================================================
 # AGENT_SEMANTIC_SEARCH_TOP_K=10
 # AGENT_SEMANTIC_SEARCH_MAX_DISTANCE=0.85
 # AGENT_TOM_INFERENCE_METHOD=single_prompt
 # =============================================================================
 # Deriver (Background Worker) Settings
 # =============================================================================
 # DERIVER_ENABLED=true
 # Defaults:
 # DERIVER_MODEL_CONFIG__TRANSPORT=openai
 # DERIVER_MODEL_CONFIG__MODEL=gpt-5.4-mini
 # Optional overrides:
 # DERIVER_MODEL_CONFIG__MODEL=your-model-here
 # DERIVER_MODEL_CONFIG__OVERRIDES__BASE_URL=https://openrouter.ai/api/v1
 # DERIVER_WORKERS=1
 # DERIVER_POLLING_SLEEP_INTERVAL_SECONDS=1.0
 # Adaptive polling: grows the idle/error sleep from the base toward the max by
 # the multiplier each cycle, snapping back to base when work is found.
 # DERIVER_POLLING_BACKOFF_ENABLED=true
 # DERIVER_POLLING_SLEEP_MAX_INTERVAL_SECONDS=30.0
 # DERIVER_POLLING_BACKOFF_MULTIPLIER=2.0
 # Jitter so instances that start together don't poll in lockstep. Startup: sleep
 # a random delay in [0, value] before the first poll (0.0 disables). Per-cycle:
 # multiply every poll sleep by a random factor in [1-ratio, 1+ratio] (0.0 disables).
 # DERIVER_POLLING_STARTUP_JITTER_SECONDS=30.0
 # DERIVER_POLLING_JITTER_RATIO=0.5
 # DERIVER_STALE_SESSION_TIMEOUT_MINUTES=5
-# DERIVER_QUEUE_ERROR_RETENTION_SECONDS=2592000  # 30 days
+# DERIVER_POLLING_SLEEP_INTERVAL_SECONDS=1.0
-# DERIVER_MODEL_CONFIG__TEMPERATURE=
+# DERIVER_TOM_METHOD=single_prompt
-# DERIVER_MODEL_CONFIG__THINKING_EFFORT=minimal
+# DERIVER_USER_REPRESENTATION_METHOD=long_term
 # DERIVER_MODEL_CONFIG__THINKING_BUDGET_TOKENS=1024  # Gemini/Anthropic only
 # DERIVER_MODEL_CONFIG__STRUCTURED_OUTPUT_MODE=json_object  # for providers without json_schema support
 # DERIVER_DEDUPLICATE=true
 # DERIVER_MODEL_CONFIG__MAX_OUTPUT_TOKENS=4096
 # DERIVER_LOG_OBSERVATIONS=false
 # DERIVER_MAX_INPUT_TOKENS=25000
 # DERIVER_MAX_CUSTOM_INSTRUCTIONS_TOKENS=2000
 # DERIVER_WORKING_REPRESENTATION_MAX_OBSERVATIONS=100
 # DERIVER_REPRESENTATION_BATCH_WORK_UNIT_TARGET_TOKENS=512  # Min tokens a work unit accumulates before the deriver claims it; 0 disables the gate
 # DERIVER_REPRESENTATION_BATCH_TARGET_INPUT_TOKENS=1024  # Max context-window tokens per deriver LLM call
 # DERIVER_REPRESENTATION_BATCH_MAX_AGE_SECONDS=1800
 # DERIVER_FLUSH_ENABLED=false  # Bypass batch token threshold, process work immediately
 # DERIVER_MODEL_CONFIG__FALLBACK__MODEL=
 # DERIVER_MODEL_CONFIG__FALLBACK__TRANSPORT=
 # DERIVER_MODEL_CONFIG__OVERRIDES__BASE_URL=
 # DERIVER_MODEL_CONFIG__OVERRIDES__API_KEY_ENV=
 # =============================================================================
-# Peer Card
+# History Settings
 # =============================================================================
-# PEER_CARD_ENABLED=true
+# HISTORY_MESSAGES_PER_SHORT_SUMMARY=20
-
+# HISTORY_MESSAGES_PER_LONG_SUMMARY=60
 # =============================================================================
 # Dialectic
 # =============================================================================
 # DIALECTIC_MAX_OUTPUT_TOKENS=8192
 # DIALECTIC_MAX_INPUT_TOKENS=100000
 # DIALECTIC_HISTORY_TOKEN_LIMIT=8192
 # DIALECTIC_SESSION_HISTORY_MAX_TOKENS=4096
 #
 # Per-level settings (reasoning_level parameter in API)
 # Each level has its own nested MODEL_CONFIG, tool iterations, and max output tokens.
 # MAX_OUTPUT_TOKENS is optional per level; if not set, uses global DIALECTIC_MAX_OUTPUT_TOKENS.
 # Defaults:
 # DIALECTIC_LEVELS__minimal__MODEL_CONFIG__TRANSPORT=openai
 # DIALECTIC_LEVELS__minimal__MODEL_CONFIG__MODEL=gpt-5.4-mini
 # DIALECTIC_LEVELS__minimal__MAX_TOOL_ITERATIONS=1
 # DIALECTIC_LEVELS__minimal__MAX_OUTPUT_TOKENS=250
 # DIALECTIC_LEVELS__minimal__TOOL_CHOICE=auto
 # DIALECTIC_LEVELS__low__MODEL_CONFIG__TRANSPORT=openai
 # DIALECTIC_LEVELS__low__MODEL_CONFIG__MODEL=gpt-5.4-mini
 # DIALECTIC_LEVELS__low__MAX_TOOL_ITERATIONS=5
 # DIALECTIC_LEVELS__low__TOOL_CHOICE=auto
 # DIALECTIC_LEVELS__medium__MODEL_CONFIG__TRANSPORT=openai
 # DIALECTIC_LEVELS__medium__MODEL_CONFIG__MODEL=gpt-5.4-mini
 # DIALECTIC_LEVELS__medium__MAX_TOOL_ITERATIONS=2
 # DIALECTIC_LEVELS__high__MODEL_CONFIG__TRANSPORT=openai
 # DIALECTIC_LEVELS__high__MODEL_CONFIG__MODEL=gpt-5.4-mini
 # DIALECTIC_LEVELS__high__MAX_TOOL_ITERATIONS=4
 # DIALECTIC_LEVELS__max__MODEL_CONFIG__TRANSPORT=openai
 # DIALECTIC_LEVELS__max__MODEL_CONFIG__MODEL=gpt-5.4-mini
 # DIALECTIC_LEVELS__max__MAX_TOOL_ITERATIONS=10
 # Optional overrides (model and OpenAI-compatible base URL are per-level):
 # DIALECTIC_LEVELS__minimal__MODEL_CONFIG__MODEL=your-model-here
 # DIALECTIC_LEVELS__minimal__MODEL_CONFIG__OVERRIDES__BASE_URL=https://openrouter.ai/api/v1
 # DIALECTIC_LEVELS__low__MODEL_CONFIG__MODEL=your-model-here
 # DIALECTIC_LEVELS__low__MODEL_CONFIG__OVERRIDES__BASE_URL=https://openrouter.ai/api/v1
 # DIALECTIC_LEVELS__medium__MODEL_CONFIG__MODEL=your-model-here
 # DIALECTIC_LEVELS__medium__MODEL_CONFIG__OVERRIDES__BASE_URL=https://openrouter.ai/api/v1
 # DIALECTIC_LEVELS__high__MODEL_CONFIG__MODEL=your-model-here
 # DIALECTIC_LEVELS__high__MODEL_CONFIG__OVERRIDES__BASE_URL=https://openrouter.ai/api/v1
 # DIALECTIC_LEVELS__max__MODEL_CONFIG__MODEL=your-model-here
 # DIALECTIC_LEVELS__max__MODEL_CONFIG__OVERRIDES__BASE_URL=https://openrouter.ai/api/v1
 # DIALECTIC_LEVELS__max__MODEL_CONFIG__THINKING_EFFORT=medium
 # DIALECTIC_LEVELS__max__MODEL_CONFIG__THINKING_BUDGET_TOKENS=1024
 # Optional backup per level (must set both or neither):
 # DIALECTIC_LEVELS__max__MODEL_CONFIG__FALLBACK__MODEL=gemini-2.5-pro
 # DIALECTIC_LEVELS__max__MODEL_CONFIG__FALLBACK__TRANSPORT=gemini
 # =============================================================================
 # Summary
 # =============================================================================
 # SUMMARY_ENABLED=true
 # Defaults:
 # SUMMARY_MODEL_CONFIG__TRANSPORT=openai
 # SUMMARY_MODEL_CONFIG__MODEL=gpt-5.4-mini
 # Optional overrides:
 # SUMMARY_MODEL_CONFIG__MODEL=your-model-here
 # SUMMARY_MODEL_CONFIG__OVERRIDES__BASE_URL=https://openrouter.ai/api/v1
 # SUMMARY_MODEL_CONFIG__THINKING_EFFORT=minimal
 # SUMMARY_MODEL_CONFIG__THINKING_BUDGET_TOKENS=1024  # Gemini/Anthropic only
 # SUMMARY_MESSAGES_PER_SHORT_SUMMARY=20
 # SUMMARY_MESSAGES_PER_LONG_SUMMARY=60
 # SUMMARY_MAX_TOKENS_SHORT=1000
 # SUMMARY_MAX_TOKENS_LONG=4000
 # SUMMARY_MODEL_CONFIG__FALLBACK__MODEL=
 # =============================================================================
 # Dream
 # =============================================================================
 # DREAM_ENABLED=true
 # Defaults:
 # DREAM_DEDUCTION_MODEL_CONFIG__TRANSPORT=openai
 # DREAM_DEDUCTION_MODEL_CONFIG__MODEL=gpt-5.4-mini
 # DREAM_INDUCTION_MODEL_CONFIG__TRANSPORT=openai
 # DREAM_INDUCTION_MODEL_CONFIG__MODEL=gpt-5.4-mini
 # Optional overrides:
 # DREAM_DEDUCTION_MODEL_CONFIG__MODEL=your-model-here
 # DREAM_DEDUCTION_MODEL_CONFIG__OVERRIDES__BASE_URL=https://openrouter.ai/api/v1
 # DREAM_INDUCTION_MODEL_CONFIG__MODEL=your-model-here
 # DREAM_INDUCTION_MODEL_CONFIG__OVERRIDES__BASE_URL=https://openrouter.ai/api/v1
 # DREAM_DOCUMENT_THRESHOLD=50
 # DREAM_IDLE_TIMEOUT_MINUTES=60
 # DREAM_MIN_HOURS_BETWEEN_DREAMS=8
 # DREAM_ENABLED_TYPES=["omni"]
 # DREAM_MAX_TOOL_ITERATIONS=20
 # DREAM_HISTORY_TOKEN_LIMIT=16384
 # Surprisal sampling (advanced):
 # DREAM_SURPRISAL__ENABLED=false
 # DREAM_SURPRISAL__TREE_TYPE=kdtree
 # DREAM_SURPRISAL__TREE_K=5
 # DREAM_SURPRISAL__SAMPLING_STRATEGY=recent
 # DREAM_SURPRISAL__SAMPLE_SIZE=200
 # DREAM_SURPRISAL__TOP_PERCENT_SURPRISAL=0.10
 # DREAM_SURPRISAL__MIN_HIGH_SURPRISAL_FOR_REPLACE=10
 # DREAM_SURPRISAL__INCLUDE_LEVELS=["explicit","deductive"]
 # =============================================================================
 # Webhook Settings
 # =============================================================================
 # WEBHOOK_SECRET=
 # WEBHOOK_MAX_WORKSPACE_LIMIT=10
 # =============================================================================
 # Monitoring and Observability (Optional)
@ -258,77 +113,6 @@ LLM_OPENAI_API_KEY=your-api-key-here
 # SENTRY_ENABLED=false
 # SENTRY_DSN=your-sentry-dsn-here
 # SENTRY_RELEASE=your-release-semver
-# SENTRY_ENVIRONMENT=development
+# SENTRY_ENVIRONMENT=string-that-labels-deployment (default "development")
 # SENTRY_TRACES_SAMPLE_RATE=0.1
 # SENTRY_PROFILES_SAMPLE_RATE=0.1
 # =============================================================================
 # Prometheus Metrics Settings (Pull-based metrics)
 # =============================================================================
 # METRICS_ENABLED=false
 # METRICS_NAMESPACE=honcho  # Inherits from NAMESPACE if not set
 # =============================================================================
 # CloudEvents Telemetry Settings (Analytics events)
 # =============================================================================
 # TELEMETRY_ENABLED=false
 # TELEMETRY_ENDPOINT=https://telemetry.honcho.dev/v1/events
 # TELEMETRY_HEADERS={"Authorization": "Bearer your-token"}  # JSON string for auth headers
 # TELEMETRY_BATCH_SIZE=100
 # TELEMETRY_FLUSH_INTERVAL_SECONDS=1.0
 # TELEMETRY_FLUSH_THRESHOLD=50
 # TELEMETRY_MAX_RETRIES=3
 # TELEMETRY_MAX_BUFFER_SIZE=10000
 # TELEMETRY_NAMESPACE=honcho  # Inherits from NAMESPACE if not set
 # Full-fidelity payload tracing (llm.call.traced / trace.content). Default-off
 # TELEMETRY_TRACE_PAYLOADS_ENABLED=false  # Trace events ship to TELEMETRY_ENDPOINT
 # TELEMETRY_TRACE_MAX_BYTES=262144  # Per-message cap; oversized content is clipped
 # TELEMETRY_TRACE_PURPOSES=[]  # JSON list of CallPurpose values to capture; empty = all
 # =============================================================================
 # Cache
 # =============================================================================
 # CACHE_ENABLED=false
 # CACHE_URL="redis://localhost:6379/0?suppress=true"
 # CACHE_CLUSTER=false  # true when CACHE_URL is a Redis Cluster (e.g. Memorystore for Redis Cluster)
 # CACHE_NAMESPACE="honcho"  # Inherits from NAMESPACE if not set
 # CACHE_DEFAULT_TTL_SECONDS=300
 # CACHE_DEFAULT_LOCK_TTL_SECONDS=5
 # CACHE_LOCK_WAIT_CHECK_INTERVAL_SECONDS=0.1
 # =============================================================================
 # CORS Settings
 # =============================================================================
 # JSON array of origins allowed by the FastAPI CORSMiddleware. Defaults match
 # the previously hardcoded list: localhost, 127.0.0.1:8000 and api.honcho.dev.
 # CORS_ORIGINS=["http://localhost","http://127.0.0.1:8000","https://api.honcho.dev"]
 # =============================================================================
 # Vector Store Settings
 # =============================================================================
 # Vector store type: "pgvector", "turbopuffer", or "lancedb"
 VECTOR_STORE_TYPE=pgvector
 # Migration flag: set to true when migration from pgvector is complete
 VECTOR_STORE_MIGRATED=false
 # Global namespace prefix for all vector namespaces
 # Namespaces follow the pattern: {NAMESPACE}.{type}.{hash}
 # where hash is a base64url-encoded SHA-256 of the workspace/peer names
 # - Documents: {NAMESPACE}.doc.{hash(workspace, observer, observed)}
 # - Messages: {NAMESPACE}.msg.{hash(workspace)}
 # VECTOR_STORE_NAMESPACE=honcho  # Inherits from NAMESPACE if not set
 # Embedding dimensions are configured via EMBEDDING_VECTOR_DIMENSIONS (see top
 # of this file). VECTOR_STORE_DIMENSIONS is deprecated and ignored.
 # Turbopuffer-specific settings (required if TYPE is "turbopuffer")
 # VECTOR_STORE_TURBOPUFFER_API_KEY=your-turbopuffer-api-key
 # VECTOR_STORE_TURBOPUFFER_REGION=gcp-us-east4
 # LanceDB-specific settings (local embedded mode)
 # VECTOR_STORE_LANCEDB_PATH=./lancedb_data
 # Reconciliation interval for background sync (default: 5 minutes)
 # VECTOR_STORE_RECONCILIATION_INTERVAL_SECONDS=300
--- a/.gitattributes
+++ b/.gitattributes
@ -1,5 +0,0 @@
 # Shell entrypoints are executed with sh/dash inside the container image. A
 # Windows checkout with core.autocrlf=true rewrites them to CRLF, and dash
 # then aborts with "set: Illegal option" because the carriage return becomes
 # part of the "-e" flag argument (docker/entrypoint.sh).
 *.sh text eol=lf
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@ -1,61 +0,0 @@
 # Code owners for Honcho.
 #
 # Beyond review routing, this file is the allowlist for manually triggering
 # the live-llm-tests and unified-tests workflows (via their PR labels and
 # workflow_dispatch). The gate jobs grep every @username in this file —
 # regardless of which path pattern it sits on — and read it from `main`,
 # never from the PR branch, so additions only take effect once merged.
 #
 # The workflow gates only understand individual @usernames (no @org/team
 # entries).
 #
 # Order matters: GitHub applies the LAST matching pattern, so narrower rules
 # go further down. Paths not listed here have no automatic reviewer.
 # Telemetry, tracing, metrics.
 /src/telemetry/              @akattelu @Rajat-Ahuja1997
 # Data model, connections, configuration, LLM transport.
 /src/db.py                   @akattelu @eisene
 /src/models.py               @akattelu @eisene
 /src/config.py               @akattelu @eisene
 /src/cache/                  @akattelu @eisene
 /src/crud/                   @akattelu @eisene
 /migrations/                 @akattelu @eisene
 /src/llm/                    @akattelu @eisene
 # Client-facing surfaces and API shape.
 /sdks/                       @ajspig @akattelu
 /mcp/                        @ajspig @akattelu
 /honcho-cli/                 @ajspig @akattelu
 /src/routers/                @ajspig @akattelu
 /src/schemas/                @ajspig @akattelu
 # The reasoning agents, their prompts, and shared agent tooling.
 /src/deriver/                @eisene @akattelu
 /src/dreamer/                @eisene @akattelu
 /src/dialectic/              @eisene @akattelu
 /src/utils/                  @eisene @akattelu
 # Deployment, and swappable storage and inference backends.
 # /src/llm/backends/ must stay below /src/llm/ above — last match wins.
 /docker/                     @eisene @Rajat-Ahuja1997
 /Dockerfile                  @eisene @Rajat-Ahuja1997
 /docker-compose.yml.example  @eisene @Rajat-Ahuja1997
 /src/vector_store/           @eisene @Rajat-Ahuja1997
 /src/llm/backends/           @eisene @Rajat-Ahuja1997
 # Documentation and contributor-facing policy.
 /docs/                       @ajspig @akattelu
 /README.md                   @ajspig @akattelu
 /CONTRIBUTING.md             @akattelu @ajspig
 /SECURITY.md                 @Rajat-Ahuja1997 @ajspig
 # Reviewers auto-requested on changes under .github/ (workflows, this file,
 # templates).
 /.github/ @akattelu @eisene @Rajat-Ahuja1997 @VVoruganti
 # CI-trigger allowlist only: this path matches no real file, so these people
 # are never auto-requested for review, but the workflow gates still pick
 # them up.
 /ci-trigger-allowlist @ajspig @courtlandleer @erosika @lowyelling @vintrocode
--- a/.github/ISSUE_TEMPLATE/1-bug-report.md
+++ b/.github/ISSUE_TEMPLATE/1-bug-report.md
@ -0,0 +1,76 @@
 ---
 name: "🐞 Bug Report"
 about: "Report an issue to help the project improve."
 title: "[Bug] "
 labels: "bug"
 assignees: ""
 ---
 # **🐞 Bug Report**
 ## **Describe the bug**
 <!-- A clear and concise description of what the bug is. -->
 *
 ---
 ### **Is this a regression?**
 <!-- Did this behaviour used to work in the previous version? -->
 <!-- Yes, the last version in which this bug was not present was: ... -->
 ---
 ### **To Reproduce**
 <!-- Steps to reproduce the error:
 (e.g.:)
 1. Use x argument / navigate to
 2. Fill this information
 3. Go to...
 4. See error -->
 <!-- Write the steps here (add or remove as many steps as needed)-->
 1.
 2.
 3.
 4.
 ---
 ### **Expected behaviour**
 <!-- A clear and concise description of what you expected to happen. -->
 *
 ---
 ### **Media prove**
 <!-- If applicable, add screenshots or videos to help explain your problem. -->
 ---
 ### **Your environment**
 <!-- use all the applicable bulleted list elements for this specific issue,
 and remove all the bulleted list elements that are not relevant for this issue. -->
 * OS: <!--[e.g. Ubuntu 5.4.0-26-generic x86_64 / Windows 1904 ...]-->
 * Browser name and version:
 * Honcho Server Version: <!-- e.g. v0.0.8 -->
 * Honcho Client Version: <!-- e.g. Python v0.0.8 -->
 ---
 ### **Additional context**
 <!-- Add any other context or additional information about the problem here.-->
 *
 <!--📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛
 To expedite issue processing, please search open and closed issues before submitting a new one.
 📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛-->
--- a/.github/ISSUE_TEMPLATE/1-bug-report.yml
+++ b/.github/ISSUE_TEMPLATE/1-bug-report.yml
@ -1,72 +0,0 @@
 name: Bug report
 description: Something is broken or incorrect in Honcho (API, deriver, SDK, managed offering, etc.).
 title: "[Bug] "
 labels: ["bug"]
 body:
  - type: markdown
    attributes:
      value: |
        Thanks for filing a bug. Please search [existing issues](https://github.com/plastic-labs/honcho/issues) first.
        **Security vulnerability?** Do not use this form — report privately via [SECURITY.md](https://github.com/plastic-labs/honcho/blob/main/SECURITY.md).
        **Memory / recall quality** (wrong or noisy conclusions, weak dialectic answers) with no crash? Prefer the **Memory / recall quality** template.
  - type: dropdown
    id: deploy_mode
    attributes:
      label: Deploy mode
      description: Where are you running Honcho?
      options:
        - Managed (api.honcho.dev / app.honcho.dev)
        - Self-hosted
        - Unsure
    validations:
      required: true
  - type: input
    id: version
    attributes:
      label: Honcho version
      description: Server image tag or release, and SDK version if you use one. Write "managed" if you are not self-hosting.
      placeholder: e.g. server v2.4.1, honcho-ai 2.1.0
    validations:
      required: true
  - type: textarea
    id: description
    attributes:
      label: Describe the bug
      description: Clear and concise description of what is wrong.
      placeholder: When I…, Honcho…
    validations:
      required: true
  - type: textarea
    id: repro
    attributes:
      label: Steps to reproduce
      description: Minimal steps or a short script/API sequence. Redact secrets, JWTs, and production user content.
      placeholder: |
        1. Create a session with …
        2. POST /v3/... with body …
        3. Observe …
    validations:
      required: true
  - type: textarea
    id: logs
    attributes:
      label: Logs and evidence
      description: Relevant API or deriver logs or stack traces. Redact secrets and user content.
      render: shell
    validations:
      required: false
  - type: textarea
    id: context
    attributes:
      label: Additional context
      description: Config knobs, deployment notes, screenshots, related issues/PRs.
    validations:
      required: false
--- a/.github/ISSUE_TEMPLATE/2-failing-test.md
+++ b/.github/ISSUE_TEMPLATE/2-failing-test.md
@ -0,0 +1,38 @@
 ---
 name: "💉 Failing Test"
 about: "Report failing tests or CI jobs."
 title: "[Test] "
 labels: "Type: Test"
 assignees: ""
 ---
 # **💉 Failing Test**
 ## **Which jobs/test(s) are failing**
 <!-- The CI jobs or tests that are failing -->
 *
 ---
 ## **Reason for failure/description**
 <!-- Try to describe why the test is failing or what we are missing to make it pass. -->
 ---
 ### **Media prove**
 <!-- If applicable, add screenshots or videos to help explain your problem. -->
 ---
 ### **Additional context**
 <!-- Add any other context or additional information about the problem here. -->
 *
 <!--📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛
 To expedite issue processing, please search open and closed issues before submitting a new one.
 📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛-->
--- a/.github/ISSUE_TEMPLATE/2-quality-report.yml
+++ b/.github/ISSUE_TEMPLATE/2-quality-report.yml
@ -1,87 +0,0 @@
 name: Memory / recall quality
 description: Conclusions, representations, or dialectic answers are wrong, noisy, missing, or low-quality — not a hard crash.
 title: "[Quality] "
 labels: ["quality"]
 body:
  - type: markdown
    attributes:
      value: |
        Use this when Honcho runs without erroring, but **memory formation or recall quality** is off (bad conclusions, missed facts, weak chat answers, polluted representations, etc.).
        For crashes, 5xxs, auth failures, or incorrect API mechanics, use the **Bug report** template instead.
        **Do not paste production user content, full peer representations, or secrets.** Redact or invent a minimal synthetic example.
  - type: dropdown
    id: deploy_mode
    attributes:
      label: Deploy mode
      options:
        - Managed (api.honcho.dev / app.honcho.dev)
        - Self-hosted
        - Unsure
    validations:
      required: true
  - type: input
    id: version
    attributes:
      label: Honcho version
      description: Server image tag or release, and SDK version if you use one. Write "managed" if you are not self-hosting.
      placeholder: e.g. server v2.4.1, honcho-ai 2.1.0
    validations:
      required: true
  - type: textarea
    id: description
    attributes:
      label: What is wrong with the quality?
      description: Describe the failure mode (noise, omission, contradiction, staleness, over/under-generalization, etc.).
      placeholder: After ingesting messages about X, Honcho concludes Y / chat answers Z…
    validations:
      required: true
  - type: textarea
    id: repro
    attributes:
      label: Minimal scenario
      description: >
        Smallest synthetic message sequence or setup that triggers the issue.
        Prefer invented names/facts over real user data. Include observer/observed
        peer setup if relevant (self vs cross-peer).
      placeholder: |
        1. Peers: alice (user), bot (agent); session S
        2. Messages ingested: …
        3. Query / conclusion listing shows: …
    validations:
      required: true
  - type: textarea
    id: config
    attributes:
      label: Relevant config
      description: >
        Custom instructions, provider/model, deriver/dream settings, or workspace/peer
        config that affects reasoning. Redact secrets.
      placeholder: |
        Provider/model: …
        Custom instructions: (summary or redacted)
        Other: …
    validations:
      required: false
  - type: textarea
    id: evidence
    attributes:
      label: Evidence
      description: Redacted conclusion text, chat excerpts, or counts that show the failure. No production PII.
    validations:
      required: false
  - type: textarea
    id: context
    attributes:
      label: Additional context
      description: Frequency, scale (message/conclusion counts), related issues, workarounds.
    validations:
      required: false
--- a/.github/ISSUE_TEMPLATE/3-docs-bug.md
+++ b/.github/ISSUE_TEMPLATE/3-docs-bug.md
@ -8,10 +8,6 @@ assignees: ""
 ---
 # **📚 Documentation Issue Report**
 **Security vulnerability?** Do not use this form — report privately via [SECURITY.md](https://github.com/plastic-labs/honcho/blob/main/SECURITY.md).
 GitHub issues are public. Redact secrets, JWTs, and production user content.
 ## **Describe the bug**
 <!-- A clear and concise description of what the bug is. -->
@ -37,8 +33,8 @@ GitHub issues are public. Redact secrets, JWTs, and production user content.
 ---
-### **Screenshots and videos**
+### **Media prove**
-<!-- If applicable, add screenshots or videos to help explain your problem. Redact secrets and production content. -->
+<!-- If applicable, add screenshots or videos to help explain your problem. -->
 ---
@ -50,7 +46,7 @@ GitHub issues are public. Redact secrets, JWTs, and production user content.
 ---
 ### **Additional context**
-<!-- Add any other context about the problem. Redact secrets and production user content. -->
+<!-- Add any other context or additional information about the problem here.-->
 *
--- a/.github/ISSUE_TEMPLATE/3-feature-request.yml
+++ b/.github/ISSUE_TEMPLATE/3-feature-request.yml
@ -1,58 +0,0 @@
 name: Feature request
 description: Propose a new capability or an improvement to an existing one.
 title: "[Feature] "
 labels: ["enhancement"]
 body:
  - type: markdown
    attributes:
      value: |
        Tell us what problem you are trying to solve. Concrete use cases beat abstract wishlists.
        Questions about how to use Honcho belong on [Discord](https://discord.gg/honcho), not here.
  - type: dropdown
    id: request_type
    attributes:
      label: Request type
      options:
        - New capability
        - Improve an existing capability
        - API / SDK surface
        - Managed offering
        - Docs / DX
        - Other
    validations:
      required: true
  - type: textarea
    id: problem
    attributes:
      label: Problem
      description: What is hard or impossible today? Who hits this?
      placeholder: I'm always frustrated when… / My integration needs…
    validations:
      required: true
  - type: textarea
    id: solution
    attributes:
      label: Proposed solution
      description: What you would like Honcho to support. Sketches and API shapes welcome.
    validations:
      required: true
  - type: textarea
    id: alternatives
    attributes:
      label: Alternatives considered
      description: Workarounds, other APIs, or designs you already tried or ruled out.
    validations:
      required: false
  - type: textarea
    id: context
    attributes:
      label: Additional context
      description: Links, prior art, screenshots, related issues/PRs.
    validations:
      required: false
--- a/.github/ISSUE_TEMPLATE/4-feature-request.md
+++ b/.github/ISSUE_TEMPLATE/4-feature-request.md
@ -0,0 +1,42 @@
 ---
 name: "🚀🆕 Feature Request"
 about: "Suggest an idea or possible new feature for this project."
 title: ""
 labels: 'feature'
 assignees: ''
 ---
 # **🚀 Feature Request**
 ## **Is your feature request related to a problem? Please describe.**
 <!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] -->
 *
 ---
 ## **Describe the solution you'd like**
 <!-- A clear and concise description of what you want to happen. -->
 *
 ---
 ## **Describe alternatives you've considered**
 <!-- A clear and concise description of any alternative solutions or features you've considered. -->
 *
 ---
 ### **Additional context**
 <!-- Add any other context or additional information about the problem here.-->
 *
 <!--📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛
 To expedite issue processing, please search open and closed issues before submitting a new one.
 📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛-->
--- a/.github/ISSUE_TEMPLATE/4-integration-request.yml
+++ b/.github/ISSUE_TEMPLATE/4-integration-request.yml
@ -1,70 +0,0 @@
 name: Integration request
 description: Add Honcho to an app store, agent framework, plugin marketplace, or other third-party surface — or improve an existing integration.
 title: "[Integration] "
 labels: ["integration"]
 body:
  - type: markdown
    attributes:
      value: |
        Use this when you want Honcho available in (or better supported by) an external product surface — app stores, agent frameworks, plugin marketplaces, IDE extensions, MCP clients, etc.
        For core API/SDK product features that are not about a third-party surface, use the **Feature request** template instead.
  - type: dropdown
    id: request_kind
    attributes:
      label: What kind of request is this?
      options:
        - New integration / listing (Honcho is not there yet)
        - Improve an existing integration
        - Official plugin / extension
        - Marketplace or app-store listing
        - Docs / guide for integrating with a specific tool
        - Other
    validations:
      required: true
  - type: input
    id: target
    attributes:
      label: Target product or platform
      description: Name of the app, framework, marketplace, or tool.
      placeholder: e.g. Claude Code, Cursor, CrewAI, OpenClaw, VS Code Marketplace…
    validations:
      required: true
  - type: input
    id: target_url
    attributes:
      label: Link (if any)
      description: Docs, marketplace page, repo, or product URL.
      placeholder: https://…
    validations:
      required: false
  - type: textarea
    id: why
    attributes:
      label: Why does this matter?
      description: Who would use it, and what does the integration unlock?
    validations:
      required: true
  - type: textarea
    id: shape
    attributes:
      label: What should the integration look like?
      description: >
        e.g. one-click install, MCP server listing, native memory backend,
        SDK recipe, plugin with slash commands, env-var setup, etc.
        Link to prior art or a sketch if you have one.
    validations:
      required: false
  - type: textarea
    id: context
    attributes:
      label: Additional context
      description: Related issues, community demand, constraints, offers to help build it.
    validations:
      required: false
--- a/.github/ISSUE_TEMPLATE/5-enhancement-request.md
+++ b/.github/ISSUE_TEMPLATE/5-enhancement-request.md
@ -0,0 +1,42 @@
 ---
 name: "🚀➕ Enhancement Request"
 about: "Suggest an enhancement for this project. Improve an existing feature"
 title: ""
 labels: "Type: Enhancement"
 assignees: ""
 ---
 # **🚀 Enhancement Request**
 ## **Is your enhancement request related to a problem? Please describe.**
 <!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] -->
 *
 ---
 ## **Describe the solution you'd like**
 <!-- A clear and concise description of what you want to happen. -->
 *
 ---
 ## **Describe alternatives you've considered**
 <!-- A clear and concise description of any alternative solutions or features you've considered. -->
 *
 ---
 ### **Additional context**
 <!-- Add any other context or additional information about the problem here.-->
 *
 <!--📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛
 To expedite issue processing, please search open and closed issues before submitting a new one.
 📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛-->
--- a/.github/ISSUE_TEMPLATE/6-security-report.md
+++ b/.github/ISSUE_TEMPLATE/6-security-report.md
@ -0,0 +1,93 @@
 ---
 name: "⚠️ Security Report"
 about: "Report an issue to help the project improve."
 title: ""
 labels: "security"
 assignees: ""
 ---
 <!--📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛
 READ CAREFULLY IF YOUR ISSUE REPORT CONTAINS SENSIBLE OR PRIVATE DATA:
 (data that might be leaked or subtracted from our servers due to this
 security issue).
 If this security report (or the guide on how to "identify the security bug") includes
 certain personal information or involves personal identifiable data, or you believe
 that the data that you might leak by exposing the way on how to attack the project
 could be considered as a data leak or could violate the privacy of any kind of
 data or sensible data, please do not post it here and directly email the developer:
 (hello@plasticlabs.ai). You should post the issue with the least amount of
 sensible or private data as possible to help us manage the security issue, and
 with the extra data sent from your email to the developer (if any), we will deeply
 analyze and try to fix it as fast as possible.
 If you are in doubt about the data that you might post here (screenshots or media
 also, count as data), please directly email us.
 The data that must NOT be posted here:
 * Legal and/or full names
 * Names or usernames combined with other identifiers like phone numbers or email addresses
 * Health or financial information (including insurance information, social security numbers, etc.)
 * Information about political or religious affiliations
 * Information about race, ethnicity, sexual orientation, gender, or other identifying information that could be used for discriminatory purposes
 📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛-->
 # **⚠️ Security Report**
 ## **Describe the security issue**
 <!-- A clear and concise description of what the bug is. -->
 *
 ---
 ### **To Reproduce**
 <!-- Steps to reproduce the error:
 (e.g.:)
 1. Use x argument / navigate to
 2. Fill this information
 3. Go to...
 4. See error -->
 <!-- Write the steps here (add or remove as many steps as needed)-->
 1.
 2.
 3.
 4.
 ---
 ### **Expected behaviour**
 <!-- A clear and concise description of what you expected to happen. -->
 *
 ---
 ### **Media prove**
 <!-- If applicable, add screenshots or videos to help explain your problem. -->
 ---
 ### **Your environment**
 <!-- use all the applicable bulleted list elements for this specific issue,
 and remove all the bulleted list elements that are not relevant for this issue. -->
 * OS: <!--[e.g. Ubuntu 5.4.0-26-generic x86_64 / Windows 1904 ...]-->
 * Browser name and version:
 * Honcho Server Version: <!--[e.g. v0.0.1]-->
 * Honcho Client Version: <!--[e.g. Python v0.0.1]-->
 ---
 ### **Additional context**
 <!-- Add any other context or additional information about the problem here.-->
 *
--- a/.github/ISSUE_TEMPLATE/7-question-support.md
+++ b/.github/ISSUE_TEMPLATE/7-question-support.md
@ -0,0 +1,25 @@
 ---
 name: "❓ Question or Support Request"
 about: "Questions and requests for support."
 title: ""
 labels: "question"
 assignees: ""
 ---
 # **❓ Question or Support Request**
 ## **Describe your question or ask for support.**
 <!-- A clear and concise description of what your doubt is. -->
 *
 <!--📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛
 Before posting any questions or asking for support, first read the project's README.md file and
 (if there is any) the WIKI pages or any other additional documentation that might be listed
 in the project's README.md file.
 To expedite issue processing, please search open and closed issues before submitting a new one.
 📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛-->
--- a/.github/ISSUE_TEMPLATE/config.yml
+++ b/.github/ISSUE_TEMPLATE/config.yml
@ -1,11 +0,0 @@
 blank_issues_enabled: false
 contact_links:
  - name: Report a security vulnerability
    url: https://github.com/plastic-labs/honcho/security/advisories/new
    about: Private vulnerability reporting only — do not file public security issues.
  - name: Question or support
    url: https://discord.gg/honcho
    about: Ask the community and maintainers on Discord.
  - name: Documentation
    url: https://honcho.dev/docs
    about: Guides, API reference, and self-hosting docs.
--- a/.github/PULL_REQUEST_TEMPLATE/release.md
+++ b/.github/PULL_REQUEST_TEMPLATE/release.md
@ -31,7 +31,7 @@ For more information on closing issues using keywords, please check https://docs
 ## **Changelog**
 <!-- 📛📛📛📛
-Log of changes introduced in this release in the style of https://keepachangelog.com/en/1.1.0/
+Log of changes introduced in this release in the style fo https://keepachangelog.com/en/1.1.0/
 📛📛📛📛 -->
 ### **Added**
@ -45,3 +45,4 @@ Log of changes introduced in this release in the style of https://keepachangelog
 ### **Fixed**
 ### **Security**
--- a/.github/actions/load-staging-secrets/action.yml
+++ b/.github/actions/load-staging-secrets/action.yml
@ -1,84 +0,0 @@
 name: Load staging secrets
 description: >-
  Resolve staging secret ids from the two newest v<major.minor.patch> git tags,
  then load the newest fetchable secret's keys into the job environment from
  AWS Secrets Manager. Falls back to the second-latest tag when the latest
  tag's secret isn't published yet, and fails the job loudly when neither can
  be fetched. Requires the repository to be checked out and AWS credentials to
  be configured beforehand.
 inputs:
  secret-prefix:
    description: >-
      Secret-name prefix combined with a resolved tag version to form the full
      secret id. Masked so it stays out of public CI logs.
    required: true
 runs:
  using: composite
  steps:
    - name: Resolve secret ids from latest git tags
      id: resolve-secret
      shell: bash
      env:
        SECRET_PREFIX: ${{ inputs.secret-prefix }}
      run: |
        set -euo pipefail
        : "${SECRET_PREFIX:?secret-prefix input is empty — is the STAGING_SECRET_PREFIX secret set for this environment?}"
        # Keep the secret-name prefix out of public CI logs.
        echo "::add-mask::${SECRET_PREFIX}"
        # Two newest v<major.minor.patch> tags, highest first (tags are public).
        versions="$(git ls-remote --tags origin 'v*' \
          | sed -n 's#.*refs/tags/v\([0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\)$#\1#p' \
          | sort -t. -k1,1nr -k2,2nr -k3,3nr -u)"
        latest="$(printf '%s\n' "$versions" | sed -n '1p')"
        second="$(printf '%s\n' "$versions" | sed -n '2p')"
        if [ -z "${latest:-}" ]; then
          echo "::error::No v<semver> git tags found to resolve a secret version"
          exit 1
        fi
        latest_id="${SECRET_PREFIX}${latest}"
        echo "::add-mask::${latest_id}"
        echo "latest-id=${latest_id}" >> "$GITHUB_OUTPUT"
        echo "Latest version: ${latest}"
        if [ -n "${second:-}" ]; then
          second_id="${SECRET_PREFIX}${second}"
          echo "::add-mask::${second_id}"
          echo "second-id=${second_id}" >> "$GITHUB_OUTPUT"
          echo "Fallback version: ${second}"
        fi
    # Fetch the latest tag's secret. continue-on-error so a not-yet-published
    # latest falls through to the second-latest instead of failing the job.
    - name: Fetch staging secret (latest)
      id: fetch-latest
      continue-on-error: true
      uses: aws-actions/aws-secretsmanager-get-secrets@v2
      with:
        secret-ids: |
          ,${{ steps.resolve-secret.outputs.latest-id }}
        parse-json-secrets: true
    # Runs only if the latest fetch failed; this one is NOT continue-on-error,
    # so if the fallback also fails the job fails loudly.
    - name: Fetch staging secret (fallback to second-latest)
      id: fetch-fallback
      if: steps.fetch-latest.outcome == 'failure' && steps.resolve-secret.outputs.second-id != ''
      uses: aws-actions/aws-secretsmanager-get-secrets@v2
      with:
        secret-ids: |
          ,${{ steps.resolve-secret.outputs.second-id }}
        parse-json-secrets: true
    # If the latest fetch failed and the fallback was skipped (no second tag),
    # no secret keys were loaded — fail here instead of letting the job run
    # without staging config (e.g. every live LLM test would silently skip via
    # require_provider_key and the run would go green).
    - name: Verify staging secrets were loaded
      if: steps.fetch-latest.outcome != 'success' && steps.fetch-fallback.outcome != 'success'
      shell: bash
      run: |
        echo "::error::No staging secret could be fetched (latest failed; fallback skipped or failed)"
        exit 1
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@ -1,13 +0,0 @@
 ## Description
 <!-- 2-3 sentences about what problem this PR solves and how -->
 ## Proofs
 <!-- Add screenshots, logs, files as a proof that this change works -->
 ## Checklist
 - [ ] This PR is correlated to an existing issue, and I understand it will be closed if that issue does not have the `maintainer-approved` label.
 <!-- Fixes #XXX -->
--- a/.github/scripts/issue-gate.js
+++ b/.github/scripts/issue-gate.js
@ -1,286 +0,0 @@
 'use strict';
 /**
 * Issue gate — shared logic for `.github/workflows/issue-gate.yml` (immediate
 * feedback on pull request events) and `.github/workflows/pr-sweeper.yml`
 * (deferred re-check, close, and stale-draft cleanup).
 *
 * Both workflows `require` this file through actions/github-script, so it must
 * stay dependency-free: neither job runs an install step.
 *
 * See CONTRIBUTING.md for the policy this enforces.
 */
 const REQUIRED_LABEL = 'maintainer-approved';
 const GATE_LABEL = 'needs-approved-issue';
 const EXEMPT_LABEL = 'gate-exempt';
 const MARKER = '<!-- issue-gate -->';
 const DISCORD = 'http://discord.gg/honcho';
 // Hours a labelled pull request has before the sweeper closes it. Measured from
 // the notice comment, so the clock starts when the author was actually told —
 // not when the pull request was opened.
 const GRACE_HOURS = 72;
 // Days without activity before a draft from outside the org is closed.
 const DRAFT_STALE_DAYS = 30;
 const hasLabel = (pr, name) => (pr.labels || []).some((l) => l.name === name);
 const isBot = (account) => Boolean(account) && account.type === 'Bot';
 /**
 * Why this pull request is exempt from the gate, or null if it is not.
 *
 * Single source of truth: every caller that acts on a pull request runs this.
 */
 const exemptReason = async ({ github, owner, repo, pr }) => {
  if (isBot(pr.user)) return 'author is a bot';
  if (hasLabel(pr, EXEMPT_LABEL)) return `carries the ${EXEMPT_LABEL} label`;
  const username = pr.user && pr.user.login;
  if (!username) return null;
  const permission = await repoPermission({ github, owner, repo, username });
  if (WRITE_PERMISSIONS.includes(permission)) {
    return `author has ${permission} permission`;
  }
  return null;
 };
 // Repo roles that skip the gate. `read` / `triage` do not.
 const WRITE_PERMISSIONS = ['admin', 'maintain', 'write'];
 /** Highest repo permission for `username`, or null if they are not a collaborator. */
 async function repoPermission({ github, owner, repo, username }) {
  try {
    const { data } = await github.rest.repos.getCollaboratorPermissionLevel({
      owner, repo, username,
    });
    return data.permission;
  } catch (err) {
    if (err && err.status === 404) return null;
    throw err;
  }
 }
 const CLOSING_ISSUES = `
  query($owner: String!, $repo: String!, $number: Int!) {
    repository(owner: $owner, name: $repo) {
      pullRequest(number: $number) {
        closingIssuesReferences(first: 20) {
          nodes {
            number
            state
            labels(first: 50) { nodes { name } }
          }
        }
      }
    }
  }
 `;
 /**
 * Decide whether a pull request clears the gate.
 *
 * Reads GitHub's own resolved issue links rather than parsing the body, so both
 * `Fixes #123` and the sidebar "Development" link count. A bare `#123` mention
 * deliberately does not — that is a reference, not a claim to close.
 *
 * @returns {Promise<{passed: boolean, skipped?: string, issue?: number, reason?: string}>}
 */
 async function checkGate({ github, owner, repo, pr }) {
  if (pr.state !== 'open') return { passed: true, skipped: 'pull request is not open' };
  if (pr.draft) return { passed: true, skipped: 'pull request is a draft' };
  const exempt = await exemptReason({ github, owner, repo, pr });
  if (exempt) return { passed: true, skipped: exempt };
  const data = await github.graphql(CLOSING_ISSUES, { owner, repo, number: pr.number });
  const issues = data.repository.pullRequest.closingIssuesReferences.nodes;
  if (issues.length === 0) {
    return { passed: false, reason: 'This pull request is not linked to an issue.' };
  }
  const approved = issues.find(
    (i) => i.state === 'OPEN' && i.labels.nodes.some((l) => l.name === REQUIRED_LABEL),
  );
  if (approved) return { passed: true, issue: approved.number };
  const detail = issues
    .map((i) => `#${i.number} (${i.state === 'CLOSED' ? 'closed' : 'not approved'})`)
    .join(', ');
  return {
    passed: false,
    reason:
      `The linked ${issues.length === 1 ? 'issue is' : 'issues are'} not open with the ` +
      `\`${REQUIRED_LABEL}\` label: ${detail}.`,
  };
 }
 function noticeBody({ owner, repo, reason }) {
  return [
    MARKER,
    'Thanks for the contribution. This pull request does not clear our issue gate yet.',
    '',
    `**${reason}**`,
    '',
    `Every pull request to Honcho needs to be linked to an open issue carrying the \`${REQUIRED_LABEL}\` label. We do this so the review queue only holds work we have already agreed should be built — it means nobody spends time on a change we cannot merge.`,
    '',
    'To get this moving:',
    '',
    `1. Find or open an issue describing the change. [Approved issues are here](https://github.com/${owner}/${repo}/issues?q=is%3Aissue+is%3Aopen+label%3A${REQUIRED_LABEL}).`,
    `2. Make the case for it in [Discord](${DISCORD}) — maintainers are most active there, and it is by far the fastest route to a decision.`,
    `3. Once the issue has the label, link it: put \`Fixes #<number>\` in this pull request's description, or use **Development** in the sidebar.`,
    '',
    `**This will close automatically in ${GRACE_HOURS} hours if it is still unlinked.** Nothing is lost if that happens — link the issue, reopen, and it goes into the review queue.`,
    '',
    `See [CONTRIBUTING.md](https://github.com/${owner}/${repo}/blob/main/CONTRIBUTING.md) for the full process. If you think this is wrong, say so here and a maintainer will take a look.`,
  ].join('\n');
 }
 /**
 * Every gate notice this bot posted on a pull request, oldest first.
 *
 * Authorship is part of the test, not decoration. MARKER is an invisible HTML
 * comment, so anyone who can comment on a public repository can paste it. If
 * user comments counted, a third party could post one on someone else's pull
 * request: `runGate` posts a notice only when none exists, so the author would
 * never be told, and `runSweep` would then measure the grace window from the
 * stranger's timestamp and close them unwarned.
 */
 async function findNotices({ github, owner, repo, number }) {
  const comments = await github.paginate(github.rest.issues.listComments, {
    owner, repo, issue_number: number, per_page: 100,
  });
  return comments.filter((c) => isBot(c.user) && (c.body || '').includes(MARKER));
 }
 /**
 * Drop the gate label and delete the notice.
 *
 * Deleting matters: `runGate` posts a notice only when none exists, and the
 * sweeper measures grace from the notice timestamp. A notice left behind after
 * the gate clears would make a later re-block look weeks old and be closed with
 * no warning.
 */
 async function clearGate({ github, owner, repo, pr }) {
  if (hasLabel(pr, GATE_LABEL)) {
    await github.rest.issues
      .removeLabel({ owner, repo, issue_number: pr.number, name: GATE_LABEL })
      .catch(() => {});
  }
  for (const notice of await findNotices({ github, owner, repo, number: pr.number })) {
    await github.rest.issues
      .deleteComment({ owner, repo, comment_id: notice.id })
      .catch(() => {});
  }
 }
 /**
 * Entry point for `.github/workflows/issue-gate.yml`.
 * Labels and explains. Never closes — that is the sweeper's job.
 */
 async function runGate({ github, core, context }) {
  const pr = context.payload.pull_request;
  const { owner, repo } = context.repo;
  const result = await checkGate({ github, owner, repo, pr });
  if (result.passed) {
    core.info(
      result.skipped ? `Skipping gate: ${result.skipped}` : `Gate passed via #${result.issue}`,
    );
    await clearGate({ github, owner, repo, pr });
    return;
  }
  core.warning(`Gate failed: ${result.reason}`);
  await github.rest.issues.addLabels({
    owner, repo, issue_number: pr.number, labels: [GATE_LABEL],
  });
  const notices = await findNotices({ github, owner, repo, number: pr.number });
  if (notices.length > 0) return;
  await github.rest.issues.createComment({
    owner, repo, issue_number: pr.number,
    body: noticeBody({ owner, repo, reason: result.reason }),
  });
 }
 /** Entry point for `.github/workflows/pr-sweeper.yml`. */
 async function runSweep({ github, core, context, dryRun }) {
  const { owner, repo } = context.repo;
  const act = async (what, fn) => {
    core.info(dryRun ? `[dry run] ${what}` : what);
    if (!dryRun) await fn();
  };
  const close = (pr, body) => async () => {
    await github.rest.issues.createComment({ owner, repo, issue_number: pr.number, body });
    await github.rest.pulls.update({ owner, repo, pull_number: pr.number, state: 'closed' });
  };
  const prs = await github.paginate(github.rest.pulls.list, {
    owner, repo, state: 'open', per_page: 100,
  });
  core.info(`${prs.length} open pull requests${dryRun ? ' (dry run)' : ''}`);
  // Re-check everything wearing the gate label. Never close blind: a pull request
  // linked through the sidebar fires no webhook, so the gate workflow cannot have
  // noticed it — this pass is the only thing that will.
  for (const pr of prs.filter((p) => hasLabel(p, GATE_LABEL))) {
    const result = await checkGate({ github, owner, repo, pr });
    if (result.passed) {
      const why = result.skipped || `via #${result.issue}`;
      await act(`#${pr.number}: gate now clear (${why})`, async () => {
        await clearGate({ github, owner, repo, pr });
        await github.rest.issues.createComment({
          owner, repo, issue_number: pr.number,
          body: 'The issue link is in place — this pull request has cleared the gate and is waiting on review.',
        });
      });
      continue;
    }
    const [notice] = await findNotices({ github, owner, repo, number: pr.number });
    if (!notice) {
      core.info(`#${pr.number}: labelled but never notified — leaving it for the gate workflow`);
      continue;
    }
    const hours = (Date.now() - Date.parse(notice.created_at)) / 3_600_000;
    if (hours < GRACE_HOURS) {
      core.info(`#${pr.number}: ${Math.round(GRACE_HOURS - hours)}h of grace left`);
      continue;
    }
    await act(`#${pr.number}: closing — notified ${Math.round(hours)}h ago, still failing`, close(pr,
      `Closing this: ${GRACE_HOURS} hours have passed and the gate is still not clear. This is not a judgement on the code. Link an approved issue and reopen — it goes straight into the review queue.`,
    ));
  }
  // Stale drafts. The gate skips drafts entirely, so they never carry the label;
  // this pass keys off inactivity and applies the shared exemptions itself.
  for (const pr of prs.filter((p) => p.draft)) {
    const exempt = await exemptReason({ github, owner, repo, pr });
    if (exempt) {
      core.info(`#${pr.number}: leaving stale draft alone — ${exempt}`);
      continue;
    }
    const days = (Date.now() - Date.parse(pr.updated_at)) / 86_400_000;
    if (days < DRAFT_STALE_DAYS) continue;
    await act(`#${pr.number}: closing stale draft — ${Math.round(days)}d without activity`, close(pr,
      `Closing this draft after ${DRAFT_STALE_DAYS} days without activity, to keep the pull request list readable. Reopen whenever you pick it back up — nothing here is lost.`,
    ));
  }
 }
 module.exports = {
  checkGate, runGate, runSweep, noticeBody, findNotices, exemptReason,
  REQUIRED_LABEL, GATE_LABEL, EXEMPT_LABEL, MARKER, GRACE_HOURS, DRAFT_STALE_DAYS,
 };
--- a/.github/scripts/issue-gate.test.js
+++ b/.github/scripts/issue-gate.test.js
@ -1,161 +0,0 @@
 'use strict';
 // Self-check for the gate decision logic. No framework, no install:
 //   node .github/scripts/issue-gate.test.js
 // Covers checkGate() only — the side-effecting halves (runGate/runSweep) are
 // exercised against the real API via `pr-sweeper.yml`'s dry_run dispatch.
 const assert = require('node:assert');
 const {
  checkGate, findNotices, runSweep, REQUIRED_LABEL, EXEMPT_LABEL, MARKER,
 } = require('./issue-gate.js');
 const pull = (over = {}) => ({
  number: 1, state: 'open', draft: false,
  user: { type: 'User', login: 'alice' }, labels: [],
  ...over,
 });
 const notCollaborator = () => {
  const err = new Error('Not Found');
  err.status = 404;
  throw err;
 };
 // `linked` is the list of issues GitHub resolves as closing references.
 const stub = (linked, permission) => ({
  graphql: async () => ({
    repository: { pullRequest: { closingIssuesReferences: {
      nodes: linked.map((i) => ({
        number: i.number, state: i.state || 'OPEN',
        labels: { nodes: (i.labels || []).map((name) => ({ name })) },
      })),
    } } },
  }),
  rest: {
    repos: {
      getCollaboratorPermissionLevel: async () => {
        if (!permission) return notCollaborator();
        return { data: { permission } };
      },
    },
  },
 });
 const run = (linked, over, permission) =>
  checkGate({ github: stub(linked, permission), owner: 'o', repo: 'r', pr: pull(over) });
 const cases = [
  ['no linked issue fails', () => run([]), (r) => r.passed === false],
  ['linked but unapproved fails', () => run([{ number: 7 }]), (r) => r.passed === false],
  ['linked and approved passes',
    () => run([{ number: 7, labels: [REQUIRED_LABEL] }]),
    (r) => r.passed === true && r.issue === 7],
  ['approved but closed fails',
    () => run([{ number: 7, state: 'CLOSED', labels: [REQUIRED_LABEL] }]),
    (r) => r.passed === false],
  ['picks the approved one out of several',
    () => run([{ number: 7 }, { number: 8, labels: [REQUIRED_LABEL] }]),
    (r) => r.passed === true && r.issue === 8],
  // Exemptions.
  ['write permission skips', () => run([], {}, 'write'), (r) => r.passed === true],
  ['maintain permission skips', () => run([], {}, 'maintain'), (r) => r.passed === true],
  ['bot skips', () => run([], { user: { type: 'Bot' } }), (r) => r.passed === true],
  ['draft skips', () => run([], { draft: true }), (r) => r.passed === true],
  [`${EXEMPT_LABEL} skips`, () => run([], { labels: [{ name: EXEMPT_LABEL }] }), (r) => r.passed === true],
  ['triage permission is still gated', () => run([], {}, 'triage'), (r) => r.passed === false],
  ['MEMBER association without write is still gated',
    () => run([], { author_association: 'MEMBER' }),
    (r) => r.passed === false],
  ['CONTRIBUTOR with write skips',
    () => run([], { author_association: 'CONTRIBUTOR' }, 'write'),
    (r) => r.passed === true],
 ];
 // --- findNotices: only the bot's own notices count -------------------------
 // A stranger pasting the invisible MARKER into a comment must not suppress the
 // notice or become the grace-window clock.
 const commentsStub = (comments) => ({
  paginate: async () => comments,
  rest: { issues: { listComments: null } },
 });
 const noticeCases = [
  ['a user comment carrying MARKER is not a notice',
    [{ id: 1, user: { type: 'User' }, body: `sneaky ${MARKER}`, created_at: 'x' }], 0],
  ['a bot comment carrying MARKER is a notice',
    [{ id: 2, user: { type: 'Bot' }, body: `${MARKER}\nnotice`, created_at: 'x' }], 1],
  ['a bot comment without MARKER is not a notice',
    [{ id: 3, user: { type: 'Bot' }, body: 'unrelated', created_at: 'x' }], 0],
  ['a user MARKER does not mask the real bot notice',
    [{ id: 4, user: { type: 'User' }, body: MARKER, created_at: 'x' },
     { id: 5, user: { type: 'Bot' }, body: MARKER, created_at: 'y' }], 1],
 ];
 // --- runSweep: the stale-draft pass must honour every exemption ------------
 const draft = (over) => ({
  number: 9, draft: true, state: 'open', labels: [],
  user: { type: 'User', login: 'alice' },
  updated_at: new Date(Date.now() - 400 * 86400_000).toISOString(),
  ...over,
 });
 async function sweepClosed(pr, permission) {
  const closed = [];
  const github = {
    paginate: async (route) => (route === 'pulls' ? [pr] : []),
    rest: {
      pulls: {
        list: 'pulls',
        update: async ({ pull_number }) => closed.push(pull_number),
      },
      issues: { listComments: 'comments', createComment: async () => {} },
      repos: {
        getCollaboratorPermissionLevel: async () => {
          if (!permission) return notCollaborator();
          return { data: { permission } };
        },
      },
    },
  };
  await runSweep({
    github, core: { info() {}, warning() {} },
    context: { repo: { owner: 'o', repo: 'r' } }, dryRun: false,
  });
  return closed;
 }
 const sweepCases = [
  ['stale draft from an outside author closes', draft({}), 1],
  ['stale draft from a bot is left alone', draft({ user: { type: 'Bot' } }), 0],
  ['stale draft from a writer is left alone', draft({}), 0, 'write'],
  [`stale draft with ${EXEMPT_LABEL} is left alone`, draft({ labels: [{ name: EXEMPT_LABEL }] }), 0],
  ['recent draft is left alone', draft({ updated_at: new Date().toISOString() }), 0],
 ];
 (async () => {
  let failed = 0;
  for (const [name, comments, want] of noticeCases) {
    const got = (await findNotices({ github: commentsStub(comments), owner: 'o', repo: 'r', number: 1 })).length;
    if (got === want) console.log(`  ok   ${name}`);
    else { failed++; console.log(`  FAIL ${name} -> ${got} notices, wanted ${want}`); }
  }
  for (const [name, pr, want, permission] of sweepCases) {
    const got = (await sweepClosed(pr, permission)).length;
    if (got === want) console.log(`  ok   ${name}`);
    else { failed++; console.log(`  FAIL ${name} -> closed ${got}, wanted ${want}`); }
  }
  for (const [name, thunk, ok] of cases) {
    const result = await thunk();
    if (ok(result)) {
      console.log(`  ok   ${name}`);
    } else {
      failed++;
      console.log(`  FAIL ${name} -> ${JSON.stringify(result)}`);
    }
  }
  assert.strictEqual(failed, 0, `${failed} case(s) failed`);
  console.log(`\n${cases.length + noticeCases.length + sweepCases.length} passed`);
 })();
--- a/.github/workflows/fly-deploy-prod.yml
+++ b/.github/workflows/fly-deploy-prod.yml
@ -0,0 +1,61 @@
 # See https://fly.io/docs/app-guides/continuous-deployment-with-github-actions/
 name: Fly Deploy (Production Environment)
 permissions:
  contents: read
 on:
  push:
    tags:
      - v*
  workflow_dispatch:
    inputs:
      version:
        description: "Version to deploy (without v prefix)"
        required: true
        type: string
        default: 'manual'
 jobs:
  deploy-honcho-prod-image:
    name: Deploy Honcho Image (Production Environment)
    runs-on: ubuntu-latest
    concurrency:
      group: deploy-prod-group
      cancel-in-progress: true
    steps:
      - uses: actions/checkout@v4
      - uses: superfly/flyctl-actions/setup-flyctl@1.5
      - run: |
          # Determine the image label based on trigger type
          if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then
            IMAGE_LABEL="deployment-${{ github.event.inputs.version }}"
          else
            IMAGE_LABEL="deployment-${{ github.ref_name }}"
          fi
          flyctl deploy -a honcho-prod-image --remote-only --build-only --push --no-cache --image-label "$IMAGE_LABEL"
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_PROD_API_TOKEN }}
  prompt-service:
    name: Push to Service (Production Environment)
    needs: deploy-honcho-prod-image
    runs-on: ubuntu-latest
    steps:
      - name: Send POST request
        env:
          GITHUB_REF_NAME: ${{ github.ref_name }}
        run: |
          # Determine version and image label based on trigger type
          if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then
            TAG="${{ github.event.inputs.version }}"
            IMAGE_LABEL="honcho-prod-image:deployment-${{ github.event.inputs.version }}"
          else
            TAG=${GITHUB_REF_NAME#v}
            IMAGE_LABEL="honcho-prod-image:deployment-${GITHUB_REF_NAME}"
          fi
          curl --fail -X POST \
            -H "Content-Type: application/json" \
            -H "Authorization: Bearer ${{ secrets.PROD_ENV_WEBHOOK_SECRET }}" \
            -d "{\"version\":\"$TAG\",\"image_label\":\"$IMAGE_LABEL\"}" \
            "${{ secrets.PROD_ENV_URL }}/webhooks/v1/add_honcho_version"
--- a/.github/workflows/fly-deploy.yml
+++ b/.github/workflows/fly-deploy.yml
@ -0,0 +1,61 @@
 # See https://fly.io/docs/app-guides/continuous-deployment-with-github-actions/
 name: Fly Deploy (Test Environment)
 permissions:
  contents: read
 on:
  push:
    tags:
      - v*
  workflow_dispatch:
    inputs:
      version:
        description: "Version to deploy (without v prefix)"
        required: true
        type: string
        default: 'manual'
 jobs:
  deploy-honcho-image:
    name: Deploy Honcho Image (Test Environment)
    runs-on: ubuntu-latest
    concurrency: 
      group: deploy-test-group
      cancel-in-progress: true
    steps:
      - uses: actions/checkout@v4
      - uses: superfly/flyctl-actions/setup-flyctl@1.5
      - run: |
          # Determine the image label based on trigger type
          if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then
            IMAGE_LABEL="deployment-${{ github.event.inputs.version }}"
          else
            IMAGE_LABEL="deployment-${{ github.ref_name }}"
          fi
          flyctl deploy -a honcho-image --remote-only --build-only --push --no-cache --image-label "$IMAGE_LABEL"
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}
  prompt-service:
    name: Push to Service (Test Environment)
    runs-on: ubuntu-latest
    needs: deploy-honcho-image
    steps:
      - name: Send POST request
        env:
          GITHUB_REF_NAME: ${{ github.ref_name }}
        run: |
          # Determine version and image label based on trigger type
          if [[ "${{ github.event_name }}" == "workflow_dispatch" ]]; then
            TAG="${{ github.event.inputs.version }}"
            IMAGE_LABEL="honcho-image:deployment-${{ github.event.inputs.version }}"
          else
            TAG=${GITHUB_REF_NAME#v}
            IMAGE_LABEL="honcho-image:deployment-${GITHUB_REF_NAME}"
          fi
          curl --fail -X POST \
            -H "Content-Type: application/json" \
            -H "Authorization: Bearer ${{ secrets.TEST_ENV_WEBHOOK_SECRET }}" \
            -d "{\"version\":\"$TAG\",\"image_label\":\"$IMAGE_LABEL\"}" \
            "${{ secrets.TEST_ENV_URL }}/webhooks/v1/add_honcho_version"
--- a/.github/workflows/issue-gate.yml
+++ b/.github/workflows/issue-gate.yml
@ -1,37 +0,0 @@
 name: Issue Gate
 # Labels pull requests that are not linked to an issue carrying the
 # `maintainer-approved` label, and comments explaining how to fix it.
 #
 # This workflow never closes anything. `pr-sweeper.yml` re-checks later and closes
 # only after the grace period — that gives contributors time to link an issue, and
 # gives maintainers time to wave through a one-line fix. It is also the only thing
 # that can notice a sidebar issue link, which fires no webhook of its own.
 #
 # `pull_request_target` is required so the job has write access on pull requests
 # from forks. It must therefore NEVER run code from the pull request. The checkout
 # below is safe because on `pull_request_target` actions/checkout defaults to the
 # BASE ref, which is repo-trusted code. Never point it at `pr.head.sha`.
 #
 # Not triggered on `synchronize`: re-running on every push would be noise.
 # Drafts are ignored until marked ready.
 on:
  pull_request_target:
    types: [opened, edited, reopened, ready_for_review]
 permissions:
  contents: read
  issues: write
  pull-requests: write
 jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/github-script@v7
        with:
          script: |
            const gate = require(`${process.env.GITHUB_WORKSPACE}/.github/scripts/issue-gate.js`);
            await gate.runGate({ github, core, context });
--- a/.github/workflows/live-llm-tests.yml
+++ b/.github/workflows/live-llm-tests.yml
@ -1,124 +0,0 @@
 name: Live LLM Tests
 on:
  # Runs on main pushes that can affect the LLM transport (narrower than
  # unified-tests' src/** — live provider calls aren't worth burning on
  # changes that can't reach the backends).
  push:
    branches: [main]
    paths:
      - 'src/llm/**'
      - 'src/config.py'
      - 'tests/live_llm/**'
      - 'pyproject.toml'
      - 'uv.lock'
      - '.python-version'
      - '.github/workflows/live-llm-tests.yml'
  # Manual trigger for PRs: add the `run-live-llm` label to run the suite
  # against the PR's merge commit. The label is purged as soon as the run
  # starts so it can be re-added to trigger another run.
  pull_request:
    types: [labeled]
  workflow_dispatch:
 # Cap spend: at most one active run per PR (per ref for push/dispatch).
 # Re-triggering a PR run cancels the in-flight one instead of stacking live
 # provider calls; pushes to main queue instead of cancelling so main CI
 # results aren't lost.
 concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
  cancel-in-progress: ${{ github.event_name != 'push' }}
 permissions:
  contents: read
 jobs:
  # Only code owners (.github/CODEOWNERS) may trigger the suite manually via
  # the label or workflow_dispatch; the gate also purges the trigger label so
  # it can be re-added to trigger another run.
  gate:
    name: Gate manual trigger
    permissions:
      contents: read
      pull-requests: write
    uses: ./.github/workflows/manual-trigger-gate.yml
    with:
      label: run-live-llm
      allow-workflow-dispatch: true
  live-llm-tests:
    name: Run Live LLM Tests
    needs: gate
    # always() lets this run on push events, where the gate's jobs are skipped.
    # Manual triggers (label / workflow_dispatch) additionally require the
    # gate's CODEOWNERS check to have passed.
    if: >-
      always() &&
      (github.event_name == 'push' ||
       ((github.event_name == 'workflow_dispatch' ||
         github.event.label.name == 'run-live-llm') &&
        needs.gate.outputs.authorized == 'true'))
    runs-on: ubuntu-latest
    timeout-minutes: 20
    environment: unified-tests
    permissions:
      id-token: write  # Required for OIDC authentication with AWS
      contents: read
    env:
      PYTHONUNBUFFERED: "1"
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          ref: ${{ github.sha }}
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ vars.AWS_OIDC_ROLE_ARN }}
          aws-region: us-east-1
          role-duration-seconds: 3600
      # Resolves secret ids from the newest release tags, fetches the newest
      # available staging secret into the job env, and fails if none loaded.
      - name: Load staging secrets
        uses: ./.github/actions/load-staging-secrets
        with:
          secret-prefix: ${{ secrets.STAGING_SECRET_PREFIX }}
      # Configure the test environment. Sentry/CloudEvents endpoints aren't
      # reachable from CI. LIVE_LLM_ANTHROPIC_45_PLUS_MODELS must be set for
      # the Anthropic tests to materialize — the claude_4_5_plus family has no
      # default models, so with only the API key they'd silently collect as
      # empty parameter sets.
      - name: Configure test environment
        run: |
          {
            # The staging dotenv carries AUTH_USE_AUTH=true without a usable
            # JWT secret; src/config.py validates the pair at import time, so
            # disable auth (this suite never runs the API server anyway).
            echo "AUTH_USE_AUTH=false"
            echo "SENTRY_ENABLED=false"
            echo "TELEMETRY_ENABLED=false"
            echo "LIVE_LLM_ANTHROPIC_45_PLUS_MODELS=claude-sonnet-4-5"
          } >> "$GITHUB_ENV"
      - name: Install uv
        uses: astral-sh/setup-uv@v2
        with:
          enable-cache: true
          cache-dependency-glob: "uv.lock"
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version-file: ".python-version"
      - name: Install the project
        run: uv sync --all-extras
      # -n 0 overrides the `-n auto` xdist default from pyproject: ~15 short
      # tests gain nothing from parallelism, serial execution avoids bursting
      # every provider at once, and flake diagnosis gets ordered output.
      - name: Run live LLM tests
        run: uv run --frozen pytest tests/live_llm/ --live-llm -n 0 -v
--- a/.github/workflows/manual-trigger-gate.yml
+++ b/.github/workflows/manual-trigger-gate.yml
@ -1,81 +0,0 @@
 name: Manual Trigger Gate
 # Shared gate for workflows that can be triggered manually on PRs by adding a
 # label (and optionally via workflow_dispatch): verifies the actor is a code
 # owner and purges the trigger label so it can be re-added for another run.
 #
 # Callers must grant `pull-requests: write` on the calling job so the
 # remove-label job can delete the label, and should gate downstream jobs on
 # the `authorized` output rather than this workflow's conclusion.
 on:
  workflow_call:
    inputs:
      label:
        description: PR label that triggers the calling workflow
        required: true
        type: string
      allow-workflow-dispatch:
        description: Whether workflow_dispatch events may pass the gate
        required: false
        default: false
        type: boolean
    outputs:
      authorized:
        description: >-
          'true' when the manual trigger's actor passed the CODEOWNERS check.
          Empty on events where the check did not run (e.g. push).
        value: ${{ jobs.check-actor.outputs.authorized }}
 jobs:
  # Only code owners (.github/CODEOWNERS) may trigger the calling workflow
  # manually.
  check-actor:
    name: Verify actor is a code owner
    if: >-
      (inputs.allow-workflow-dispatch && github.event_name == 'workflow_dispatch') ||
      (github.event_name == 'pull_request' && github.event.label.name == inputs.label)
    runs-on: ubuntu-latest
    permissions:
      contents: read
    outputs:
      authorized: ${{ steps.codeowners.outputs.authorized }}
    steps:
      - name: Check actor against CODEOWNERS on main
        id: codeowners
        env:
          GH_TOKEN: ${{ github.token }}
          ACTOR: ${{ github.actor }}
        run: |
          set -euo pipefail
          # Usernames are case-insensitive on GitHub; compare lowercased.
          owners="$(gh api -H "Accept: application/vnd.github.raw" \
            "repos/${{ github.repository }}/contents/.github/CODEOWNERS?ref=main" \
            | sed 's/#.*//' | grep -oE '@[A-Za-z0-9-]+' | tr -d '@' \
            | tr '[:upper:]' '[:lower:]' | sort -u)"
          actor_lc="$(printf '%s' "$ACTOR" | tr '[:upper:]' '[:lower:]')"
          if printf '%s\n' "$owners" | grep -qxF "$actor_lc"; then
            echo "@${ACTOR} is a code owner; proceeding"
            echo "authorized=true" >> "$GITHUB_OUTPUT"
          else
            echo "::error::@${ACTOR} is not listed in .github/CODEOWNERS on main — only code owners may trigger this workflow manually"
            exit 1
          fi
  # Purge the trigger label first thing. Best-effort: failing to remove the
  # label (e.g. read-only token on a fork PR) doesn't block the tests.
  remove-label:
    name: Remove trigger label
    if: github.event_name == 'pull_request' && github.event.label.name == inputs.label
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - name: Remove trigger label
        env:
          GH_TOKEN: ${{ github.token }}
        run: |
          if ! gh api --method DELETE \
            "repos/${{ github.repository }}/issues/${{ github.event.pull_request.number }}/labels/${{ inputs.label }}"; then
            echo "::warning::Could not remove the ${{ inputs.label }} label (it may have been removed already)"
          fi
--- a/.github/workflows/pr-sweeper.yml
+++ b/.github/workflows/pr-sweeper.yml
@ -1,41 +0,0 @@
 name: PR Sweeper
 # Deferred half of the issue gate. Every six hours:
 #
 #   1. Re-check every pull request carrying `needs-approved-issue`. Clear the ones
 #      that now link an approved issue; close the ones still failing 72h after they
 #      were told. The re-check is the point — linking an issue through the sidebar
 #      fires no webhook, so `issue-gate.yml` never sees it.
 #   2. Close drafts from outside the org after 30 days without activity.
 #
 # Runs on `schedule`, so it never touches pull request code and needs none of the
 # `pull_request_target` precautions. Dispatch manually with dry_run to see what it
 # would do before it does it.
 on:
  schedule:
    - cron: '17 */6 * * *'
  workflow_dispatch:
    inputs:
      dry_run:
        description: 'Log intended actions without closing anything'
        type: boolean
        default: true
 permissions:
  contents: read
  issues: write
  pull-requests: write
 jobs:
  sweep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/github-script@v7
        env:
          DRY_RUN: ${{ github.event_name == 'workflow_dispatch' && inputs.dry_run || 'false' }}
        with:
          script: |
            const gate = require(`${process.env.GITHUB_WORKSPACE}/.github/scripts/issue-gate.js`);
            await gate.runSweep({ github, core, context, dryRun: process.env.DRY_RUN === 'true' });
--- a/.github/workflows/push-gcp-registry-prod.yml
+++ b/.github/workflows/push-gcp-registry-prod.yml
@ -1,78 +0,0 @@
 name: Build and Push to GCP Artifact Registry (production)
 permissions:
  contents: read
 on:
  push:
    tags:
      - v*
 env:
  GCP_PROJECT_ID: ${{ secrets.PROD_GCP_PROJECT_ID }}
  GCP_AR_LOCATION: ${{ secrets.PROD_GCP_AR_LOCATION }}
  GCP_AR_REPO: ${{ secrets.PROD_GCP_AR_REPO }}
  IMAGE_NAME: ${{ secrets.PROD_IMAGE_NAME }}
  GCP_SA_KEY: ${{ secrets.PROD_GCP_SA_KEY }}
 jobs:
  build-and-push:
    runs-on: ubuntu-latest
    outputs:
      version: ${{ steps.version.outputs.version }}
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          persist-credentials: false
      - name: Resolve and verify version
        id: version
        run: |
          VERSION="${GITHUB_REF_NAME#v}"
          # A running instance serves this version at /openapi.json, so it must
          # match the version being deployed.
          PYPROJECT_VERSION="$(grep -m1 '^version = ' pyproject.toml | cut -d'"' -f2)"
          if [[ "$VERSION" != "$PYPROJECT_VERSION" ]]; then
            echo "::error::pyproject.toml version '$PYPROJECT_VERSION' does not match tag '$GITHUB_REF_NAME'. Bump pyproject.toml before tagging."
            exit 1
          fi
          echo "version=$VERSION" >> "$GITHUB_OUTPUT"
      - name: Authenticate to GCP
        uses: google-github-actions/auth@v2
        with:
          credentials_json: ${{ env.GCP_SA_KEY }}
      - name: Set up Cloud SDK
        uses: google-github-actions/setup-gcloud@v2
      - name: Configure Docker for Artifact Registry
        run: gcloud auth configure-docker ${{ env.GCP_AR_LOCATION }}-docker.pkg.dev --quiet
      - name: Build and push image
        env:
          VERSION: ${{ steps.version.outputs.version }}
        run: |
          BASE="${{ env.GCP_AR_LOCATION }}-docker.pkg.dev/${{ env.GCP_PROJECT_ID }}/${{ env.GCP_AR_REPO }}/${{ env.IMAGE_NAME }}"
          TAG="$BASE:deployment-v${VERSION}"
          docker build -t "$TAG" .
          docker push "$TAG"
  prompt-service:
    name: Push to Service (Production Environment)
    runs-on: ubuntu-latest
    needs: build-and-push
    steps:
      - name: Send POST request
        env:
          VERSION: ${{ needs.build-and-push.outputs.version }}
        run: |
          # Name and tag only; the registry path is supplied downstream.
          IMAGE_LABEL="${{ env.IMAGE_NAME }}:deployment-v${VERSION}"
          curl --fail --connect-timeout 10 --max-time 60 -X POST \
            -H "Content-Type: application/json" \
            -H "Authorization: Bearer ${{ secrets.PROD_ENV_WEBHOOK_SECRET }}" \
            -d "{\"version\":\"$VERSION\",\"image_label\":\"$IMAGE_LABEL\"}" \
            "${{ secrets.PROD_ENV_URL }}/webhooks/v1/add_honcho_version"
--- a/.github/workflows/push-gcp-registry-staging.yml
+++ b/.github/workflows/push-gcp-registry-staging.yml
@ -1,78 +0,0 @@
 name: Build and Push to GCP Artifact Registry (Staging)
 permissions:
  contents: read
 on:
  push:
    tags:
      - v*
 env:
  GCP_PROJECT_ID: ${{ secrets.STAGING_GCP_PROJECT_ID }}
  GCP_AR_LOCATION: ${{ secrets.STAGING_GCP_AR_LOCATION }}
  GCP_AR_REPO: ${{ secrets.STAGING_GCP_AR_REPO }}
  IMAGE_NAME: ${{ secrets.STAGING_IMAGE_NAME }}
  GCP_SA_KEY: ${{ secrets.STAGING_GCP_SA_KEY }}
 jobs:
  build-and-push:
    runs-on: ubuntu-latest
    outputs:
      version: ${{ steps.version.outputs.version }}
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          persist-credentials: false
      - name: Resolve and verify version
        id: version
        run: |
          VERSION="${GITHUB_REF_NAME#v}"
          # A running instance serves this version at /openapi.json, so it must
          # match the version being deployed.
          PYPROJECT_VERSION="$(grep -m1 '^version = ' pyproject.toml | cut -d'"' -f2)"
          if [[ "$VERSION" != "$PYPROJECT_VERSION" ]]; then
            echo "::error::pyproject.toml version '$PYPROJECT_VERSION' does not match tag '$GITHUB_REF_NAME'. Bump pyproject.toml before tagging."
            exit 1
          fi
          echo "version=$VERSION" >> "$GITHUB_OUTPUT"
      - name: Authenticate to GCP
        uses: google-github-actions/auth@v2
        with:
          credentials_json: ${{ env.GCP_SA_KEY }}
      - name: Set up Cloud SDK
        uses: google-github-actions/setup-gcloud@v2
      - name: Configure Docker for Artifact Registry
        run: gcloud auth configure-docker ${{ env.GCP_AR_LOCATION }}-docker.pkg.dev --quiet
      - name: Build and push image
        env:
          VERSION: ${{ steps.version.outputs.version }}
        run: |
          BASE="${{ env.GCP_AR_LOCATION }}-docker.pkg.dev/${{ env.GCP_PROJECT_ID }}/${{ env.GCP_AR_REPO }}/${{ env.IMAGE_NAME }}"
          TAG="$BASE:deployment-v${VERSION}"
          docker build -t "$TAG" .
          docker push "$TAG"
  prompt-service:
    name: Push to Service (Staging Environment)
    runs-on: ubuntu-latest
    needs: build-and-push
    steps:
      - name: Send POST request
        env:
          VERSION: ${{ needs.build-and-push.outputs.version }}
        run: |
          # Name and tag only; the registry path is supplied downstream.
          IMAGE_LABEL="${{ env.IMAGE_NAME }}:deployment-v${VERSION}"
          curl --fail --connect-timeout 10 --max-time 60 -X POST \
            -H "Content-Type: application/json" \
            -H "Authorization: Bearer ${{ secrets.TEST_ENV_WEBHOOK_SECRET }}" \
            -d "{\"version\":\"$VERSION\",\"image_label\":\"$IMAGE_LABEL\"}" \
            "${{ secrets.TEST_ENV_URL }}/webhooks/v1/add_honcho_version"
--- a/.github/workflows/start-fly-runner.yml
+++ b/.github/workflows/start-fly-runner.yml
@ -1,132 +0,0 @@
 name: Start Fly Runner
 on:
  workflow_call:
    outputs:
      runner-ready:
        description: "Whether the runner is ready"
        value: ${{ jobs.start-runner.outputs.runner-ready }}
      machine-id:
        description: "The Fly machine ID that was started"
        value: ${{ jobs.start-runner.outputs.machine-id }}
      runner-labels:
        description: "Labels to target the self-hosted runner"
        value: ${{ jobs.start-runner.outputs.runner-labels }}
      runner-name:
        description: "Resolved GitHub runner name"
        value: ${{ jobs.start-runner.outputs.runner-name }}
 env:
  FLY_RUNNER_APP: ivysaur
  FLY_RUNNER_REGION: iad
  FLY_RUNNER_IMAGE: registry.fly.io/ivysaur:latest
 jobs:
  start-runner:
    name: Start Fly Runner
    runs-on: ubuntu-latest
    permissions:
      actions: read
      contents: read
    outputs:
      runner-ready: ${{ steps.wait-for-runner.outputs.ready }}
      machine-id: ${{ steps.machine-management.outputs.machine-id }}
      runner-labels: ${{ steps.generate-labels.outputs.labels }}
      runner-name: ${{ steps.wait-for-runner.outputs.runner-name }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Generate unique runner labels
        id: generate-labels
        run: |
          UNIQUE_LABELS='"self-hosted","${{ github.run_id }}"'
          echo "Generated unique labels: $UNIQUE_LABELS"
          echo "labels=$UNIQUE_LABELS" >> "$GITHUB_OUTPUT"
      - name: Setup Fly CLI
        uses: superfly/flyctl-actions/setup-flyctl@master
      - name: Get Fly app info
        id: get-app-info
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN_TESTING }}
        run: |
          echo "Getting app info for ${FLY_RUNNER_APP}..."
          flyctl status -a "${FLY_RUNNER_APP}"
      - name: Set GH_TOKEN in Fly secrets
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN_TESTING }}
        run: |
          echo "Setting GH_TOKEN in Fly secrets..."
          flyctl secrets set GH_TOKEN="${{ secrets.GH_TOKEN_ACTIONS }}" -a "${FLY_RUNNER_APP}"
      - name: Create Fly machine
        id: machine-management
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN_TESTING }}
        run: |
          set -euo pipefail
          # Always create a fresh ephemeral machine
          FULL_OUTPUT=$(flyctl machines run "${FLY_RUNNER_IMAGE}" \
            -a "${FLY_RUNNER_APP}" \
            --region "${FLY_RUNNER_REGION}" \
            --env RUN_ID=${{ github.run_id }} \
            --env TEST_TYPE="honcho-unified-runner" \
            --vm-size shared-cpu-8x \
            --vm-memory 8192 )
          MACHINE_ID=$(echo "$FULL_OUTPUT" | grep "Machine ID:" | awk '{print $3}')
          echo "Created machine: $MACHINE_ID"
          echo "machine-id=$MACHINE_ID" >> "$GITHUB_OUTPUT"
      - name: Wait for runner to be online
        id: wait-for-runner
        env:
          GITHUB_TOKEN: ${{ secrets.GH_TOKEN_ACTIONS }}
          MAX_WAIT: 420
        run: |
          set -euo pipefail
          if [ -z "${GITHUB_TOKEN}" ]; then
            echo "GH_TOKEN secret is required to poll the Actions runner API."
            exit 1
          fi
          EXPECTED_RUNNER_NAME="honcho-unified-runner-${{ github.run_id }}"
          echo "Waiting for runner named ${EXPECTED_RUNNER_NAME} to come online..."
          WAITED=0
          RUNNER_NAME=""
          while [ $WAITED -lt $MAX_WAIT ]; do
            RESPONSE=$(curl -s \
              -H "Authorization: Bearer ${GITHUB_TOKEN}" \
              -H "Accept: application/vnd.github.v3+json" \
              "https://api.github.com/repos/${{ github.repository }}/actions/runners")
            if echo "$RESPONSE" | grep -q '"message"'; then
              echo "API Error: $(echo "$RESPONSE" | jq -r '.message')"
              exit 1
            fi
            # Find runner with exact name and is online and not busy
            RUNNER_LINE=$(echo "$RESPONSE" | jq -r --arg runner_name "$EXPECTED_RUNNER_NAME" '.runners[]? | select(.name == $runner_name) | select(.status == "online") | select(.busy == false) | "\(.name)|\(.id)"' | head -n 1)
            if [ -n "$RUNNER_LINE" ]; then
              RUNNER_NAME=$(echo "$RUNNER_LINE" | cut -d'|' -f1)
              echo "✅ Found runner: ${RUNNER_NAME}"
              echo "ready=true" >> "$GITHUB_OUTPUT"
              echo "runner-name=${RUNNER_NAME}" >> "$GITHUB_OUTPUT"
              exit 0
            fi
            echo "⏳ Waiting for runner... (${WAITED}s elapsed)"
            sleep 15
            WAITED=$((WAITED + 15))
          done
          echo "Runner failed to come online within ${MAX_WAIT} seconds"
          echo "ready=false" >> "$GITHUB_OUTPUT"
          exit 1
--- a/.github/workflows/staticanalysis.yml
+++ b/.github/workflows/staticanalysis.yml
@ -1,9 +1,5 @@
 name: Static Analysis
-on:
+on: [push]
  push:
    branches: [main]
  pull_request:
    branches: [main]
 permissions:
  contents: read
@ -16,7 +12,7 @@ jobs:
      - name: "Set up Python"
        uses: actions/setup-python@v5
        with:
-          python-version-file: ".python-version"
+          python-version-file: "pyproject.toml"
      - name: Install uv
        uses: astral-sh/setup-uv@v2
        with:
@ -26,11 +22,3 @@ jobs:
        run: uv sync --all-extras --dev
      - name: run basedpyright
        run: uv run basedpyright
  issue-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # The gate runs from `pull_request_target`, where a crash is invisible until
      # a contributor's PR is silently ungated. Check it here instead.
      - run: node .github/scripts/issue-gate.test.js
--- a/.github/workflows/unified-tests.yml
+++ b/.github/workflows/unified-tests.yml
@ -1,233 +0,0 @@
 name: Unified Tests (Fly Runner)
 on:
  push:
    branches: [main]
    paths:
      - 'src/**'
      - 'tests/**'
  # Manual trigger for PRs: add the `run-unified-tests` label to run the suite
  # against the PR's merge commit. The label is purged as soon as the run
  # starts so it can be re-added to trigger another run.
  pull_request:
    types: [labeled]
 # Cap spend: at most one active run per PR (per ref for push). Re-triggering
 # a PR run cancels the in-flight one instead of stacking Fly machines; pushes
 # to main queue instead of cancelling so main CI results aren't lost. The
 # cleanup-machine job runs `if: always()`, which still executes on cancelled
 # runs, so a cancelled run's Fly machine and runner are still torn down.
 concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
  cancel-in-progress: ${{ github.event_name != 'push' }}
 permissions:
  contents: read
  actions: read
 jobs:
  # Only code owners (.github/CODEOWNERS) may trigger the suite manually via
  # the label; the gate also purges the trigger label so it can be re-added
  # to trigger another run.
  gate:
    name: Gate manual trigger
    permissions:
      contents: read
      pull-requests: write
    uses: ./.github/workflows/manual-trigger-gate.yml
    with:
      label: run-unified-tests
  start-runner:
    name: Start Fly Runner
    needs: gate
    # always() lets this run on push events, where the gate's jobs are skipped.
    # Label adds other than run-unified-tests trigger the workflow but skip
    # every job here; the run-unified-tests label additionally requires the
    # gate's CODEOWNERS check to have passed.
    if: >-
      always() &&
      (github.event_name == 'push' ||
       (github.event.label.name == 'run-unified-tests' &&
        needs.gate.outputs.authorized == 'true'))
    uses: ./.github/workflows/start-fly-runner.yml
    secrets: inherit
  unified-tests:
    name: Run Unified Tests
    runs-on: ${{ fromJSON(format('[{0}]', needs.start-runner.outputs.runner-labels)) }}
    needs: start-runner
    # !cancelled() so this doesn't inherit gate's skip on push events.
    if: >-
      !cancelled() &&
      needs.start-runner.outputs.runner-ready == 'true'
    timeout-minutes: 90
    environment: unified-tests
    permissions:
      id-token: write  # Required for OIDC authentication with AWS
      contents: read
    env:
      PYTHONUNBUFFERED: "1"
      TEST_DISCORD_WEBHOOK_URL: ${{ secrets.TEST_DISCORD_WEBHOOK_URL }}
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          ref: ${{ github.sha }}
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ vars.AWS_OIDC_ROLE_ARN }}
          aws-region: us-east-1
          role-duration-seconds: 43200 # 12 hours
      # Resolves secret ids from the newest release tags, fetches the newest
      # available staging secret into the job env, and fails if none loaded.
      - name: Load staging secrets
        uses: ./.github/actions/load-staging-secrets
        with:
          secret-prefix: ${{ secrets.STAGING_SECRET_PREFIX }}
      # Layer test-specific overrides on top of the staging secret. The staging
      # dotenv tracks the deployed release and can drift from what main's config
      # expects; the TESTING_SECRET_ID secret holds only the keys (flat JSON,
      # exact env var names) the unified tests need to pin. The get-secrets
      # action refuses to inject an env var that already exists, so the
      # overrides are fetched under a prefix alias here and promoted over the
      # staging values in the next step.
      - name: Fetch testing secret overrides
        uses: aws-actions/aws-secretsmanager-get-secrets@v2
        with:
          secret-ids: |
            HONCHO_TEST_OVERRIDE,${{ secrets.TESTING_SECRET_ID }}
          parse-json-secrets: true
      # Re-export each HONCHO_TEST_OVERRIDE_* var under its real name; the
      # later $GITHUB_ENV write wins over the value loaded from the staging
      # secret. Values are already masked by the fetch step above.
      - name: Apply testing secret overrides
        run: |
          set -euo pipefail
          applied=0
          while IFS= read -r -d '' entry; do
            name="${entry%%=*}"
            value="${entry#*=}"
            case "$name" in
              HONCHO_TEST_OVERRIDE_*)
                target="${name#HONCHO_TEST_OVERRIDE_}"
                {
                  echo "${target}<<__HONCHO_OVERRIDE_EOF__"
                  printf '%s\n' "$value"
                  echo "__HONCHO_OVERRIDE_EOF__"
                } >> "$GITHUB_ENV"
                echo "Overriding ${target}"
                applied=$((applied + 1))
                ;;
            esac
          done < <(env -0)
          echo "Applied ${applied} override(s)"
      # Configure the test environment. Disables auth/Sentry/CloudEvents telemetry
      # (their endpoints aren't reachable from CI), and points REASONING_TRACES_FILE
      # at a shared path so the API + deriver record full LLM I/O for auditing — the
      # runner uploads it to S3. Written after the fetch steps so these win over the
      # values loaded from Secrets Manager (last $GITHUB_ENV write wins). Stale
      # config keys loaded from the staging secret (e.g. settings that have since
      # been renamed or removed on main) must always be ignored by the app config.
      - name: Configure test environment
        run: |
          {
            echo "AUTH_USE_AUTH=false"
            echo "SENTRY_ENABLED=false"
            echo "TELEMETRY_ENABLED=false"
            echo "REASONING_TRACES_FILE=unified-reasoning-traces.jsonl"
          } >> "$GITHUB_ENV"
      - name: Verify Docker is available
        run: docker info
      - name: Verify uv and Python
        run: |
          uv --version
          python3.13 --version
          which python3.13
      - name: Install the project
        run: uv sync --all-extras
      - name: Run unified tests
        run: uv run python -m tests.unified.run
  cleanup-machine:
    name: Cleanup Fly Machine and Runner
    runs-on: ubuntu-latest
    needs: [start-runner, unified-tests]
    if: always() && needs.start-runner.outputs.machine-id != ''
    env:
      FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN_TESTING }}
      GITHUB_TOKEN: ${{ secrets.GH_TOKEN_ACTIONS }}
      FLY_RUNNER_APP: ivysaur
    steps:
      - name: Setup Fly CLI
        uses: superfly/flyctl-actions/setup-flyctl@1.5
      - name: Cleanup fly machine
        run: |
          set -euo pipefail
          MACHINE_ID="${{ needs.start-runner.outputs.machine-id }}"
          if [ -z "$MACHINE_ID" ]; then
            echo "No machine ID provided, skipping Fly cleanup."
            exit 0
          fi
          echo "🧹 Cleaning up machine: $MACHINE_ID"
          flyctl machines stop "$MACHINE_ID" -a "$FLY_RUNNER_APP" || echo "Machine may already be stopped"
          flyctl machines destroy "$MACHINE_ID" -a "$FLY_RUNNER_APP" --force || echo "Failed to destroy machine"
      - name: Cleanup GitHub runner
        run: |
          set -euo pipefail
          RUNNER_NAME="${{ needs.start-runner.outputs.runner-name }}"
          FALLBACK_LABEL="${{ github.run_id }}"
          echo "🗑️ Cleaning up GitHub runner (name: ${RUNNER_NAME:-unknown}, label: ${FALLBACK_LABEL})"
          RUNNERS_RESPONSE=$(curl -s \
            -H "Authorization: Bearer $GITHUB_TOKEN" \
            -H "Accept: application/vnd.github+json" \
            "https://api.github.com/repos/${{ github.repository }}/actions/runners")
          if echo "$RUNNERS_RESPONSE" | grep -q '"message"'; then
            echo "⚠️ Failed to fetch runners: $(echo "$RUNNERS_RESPONSE" | jq -r '.message')"
            exit 0
          fi
          RUNNER_ID=""
          if [ -n "$RUNNER_NAME" ]; then
            RUNNER_ID=$(echo "$RUNNERS_RESPONSE" | jq -r --arg name "$RUNNER_NAME" '.runners[]? | select(.name == $name) | .id')
          fi
          if [ -z "$RUNNER_ID" ]; then
            RUNNER_ID=$(echo "$RUNNERS_RESPONSE" | jq -r --arg label "$FALLBACK_LABEL" '.runners[]? | select([.labels[].name] | index($label)) | .id' | head -n 1)
          fi
          if [ -z "$RUNNER_ID" ] || [ "$RUNNER_ID" = "null" ]; then
            echo "⚠️ Runner not found, nothing to delete."
            exit 0
          fi
          DELETE_RESPONSE=$(curl -s -w "%{http_code}" \
            -X DELETE \
            -H "Accept: application/vnd.github+json" \
            -H "Authorization: Bearer $GITHUB_TOKEN" \
            "https://api.github.com/repos/${{ github.repository }}/actions/runners/$RUNNER_ID")
          HTTP_CODE="${DELETE_RESPONSE: -3}"
          if [ "$HTTP_CODE" = "204" ]; then
            echo "✅ Successfully deleted runner."
          else
            echo "⚠️ Failed to delete runner. HTTP code: $HTTP_CODE"
            echo "Response: ${DELETE_RESPONSE%???}"
          fi
--- a/.github/workflows/unittest.yml
+++ b/.github/workflows/unittest.yml
@ -3,61 +3,11 @@ name: FastAPI Tests with PostgreSQL and uv
 on:
  push:
    branches: [main]
    paths:
      - '**.py'
      - '**.ts'
      - '**.js'
      - '**.tsx'
      - '**.jsx'
      - 'pyproject.toml'
      - 'uv.lock'
      - '.python-version'
      - 'sdks/typescript/package.json'
      - 'sdks/typescript/bun.lock'
      - '.github/workflows/unittest.yml'
  pull_request:
    branches: [main]
    paths:
      - '**.py'
      - '**.ts'
      - '**.js'
      - '**.tsx'
      - '**.jsx'
      - 'pyproject.toml'
      - 'uv.lock'
      - '.python-version'
      - 'sdks/typescript/package.json'
      - 'sdks/typescript/bun.lock'
      - '.github/workflows/unittest.yml'
 permissions:
  contents: read
  pull-requests: read
 jobs:
-  # Determine which tests to run based on changed files
+  test:
  changes:
    runs-on: ubuntu-latest
    outputs:
      python: ${{ steps.filter.outputs.python }}
    steps:
      - uses: actions/checkout@v4
      - uses: dorny/paths-filter@v3
        id: filter
        with:
          filters: |
            python:
              - '**.py'
              - 'pyproject.toml'
              - 'uv.lock'
              - '.python-version'
              - 'migrations/**'
              - 'sdks/typescript/**'
              - '.github/workflows/unittest.yml'
  test-python:
    needs: changes
    if: ${{ needs.changes.outputs.python == 'true' }}
    runs-on: ubuntu-latest
    services:
@ -88,14 +38,7 @@ jobs:
      - name: "Set up Python"
        uses: actions/setup-python@v5
        with:
-          python-version-file: ".python-version"
+          python-version-file: "pyproject.toml"
      - name: Install bun
        uses: oven-sh/setup-bun@v2
      - name: Install TypeScript SDK dependencies
        run: bun install
        working-directory: sdks/typescript
      - name: Install the project
        run: uv sync --all-extras --dev
@ -108,46 +51,11 @@ jobs:
          SENTRY_ENABLED: false
          LLM_OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          LLM_ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
-          LLM_OPENAI_COMPATIBLE_API_KEY: test-key
+          LLM_DIALECTIC_PROVIDER: openai
-          LLM_OPENAI_COMPATIBLE_BASE_URL: http://localhost:8000
+          LLM_DIALECTIC_MODEL: test
-          DERIVER_PROVIDER: openai
+          LLM_QUERY_GENERATION_PROVIDER: openai
-          DERIVER_MODEL: test
+          LLM_QUERY_GENERATION_MODEL: test
-          DIALECTIC_LEVELS__minimal__PROVIDER: openai
+          LLM_TOM_INFERENCE_PROVIDER: openai
-          DIALECTIC_LEVELS__minimal__MODEL: test
+          LLM_TOM_INFERENCE_MODEL: test
-          DIALECTIC_LEVELS__minimal__THINKING_BUDGET_TOKENS: 0
+          LLM_SUMMARY_PROVIDER: openai
-          DIALECTIC_LEVELS__minimal__MAX_TOOL_ITERATIONS: 2
+          LLM_SUMMARY_MODEL: test
          DIALECTIC_LEVELS__low__PROVIDER: openai
          DIALECTIC_LEVELS__low__MODEL: test
          DIALECTIC_LEVELS__low__THINKING_BUDGET_TOKENS: 0
          DIALECTIC_LEVELS__low__MAX_TOOL_ITERATIONS: 5
          DIALECTIC_LEVELS__medium__PROVIDER: openai
          DIALECTIC_LEVELS__medium__MODEL: test
          DIALECTIC_LEVELS__medium__THINKING_BUDGET_TOKENS: 0
          DIALECTIC_LEVELS__medium__MAX_TOOL_ITERATIONS: 4
          DIALECTIC_LEVELS__high__PROVIDER: openai
          DIALECTIC_LEVELS__high__MODEL: test
          DIALECTIC_LEVELS__high__THINKING_BUDGET_TOKENS: 0
          DIALECTIC_LEVELS__high__MAX_TOOL_ITERATIONS: 4
          DIALECTIC_LEVELS__max__PROVIDER: openai
          DIALECTIC_LEVELS__max__MODEL: test
          DIALECTIC_LEVELS__max__THINKING_BUDGET_TOKENS: 0
          DIALECTIC_LEVELS__max__MAX_TOOL_ITERATIONS: 10
          DIALECTIC_QUERY_GENERATION_PROVIDER: openai
          DIALECTIC_QUERY_GENERATION_MODEL: test
          SUMMARY_PROVIDER: openai
          SUMMARY_MODEL: test
  # Status check for branch protection rules
  # This job always runs and reports success only if all required jobs pass
  test-status:
    runs-on: ubuntu-latest
    needs: [changes, test-python]
    if: always()
    steps:
      - name: Check test results
        run: |
          if [[ "${{ needs.changes.outputs.python }}" == "true" && "${{ needs.test-python.result }}" != "success" && "${{ needs.test-python.result }}" != "skipped" ]]; then
            echo "Python tests failed or were cancelled"
            exit 1
          fi
          echo "All required tests passed!"
--- a/.gitignore
+++ b/.gitignore
@ -1,14 +1,11 @@
 .worktrees/
 api/**/*.db
 api/data
 api/docker-compose.yml
 *.db
 data
-redis-data
+docker-compose.yml
-/docker-compose.yml
+compose.yml
 /compose.yml
 # Byte-compiled / optimized / DLL files
@ -141,7 +138,6 @@ venv/
 ENV/
 env.bak/
 venv.bak/
 .env.backup*
 # Spyder project settings
 .spyderproject
@ -182,17 +178,4 @@ docs/node_modules
 timing_logs.csv
 config.json
 config.toml
 .aider*
 CRUSH.md
 .crush/
 metrics.jsonl
 AGENTS.md
 lancedb_data/
 grafana-data/
 # Claude Code addon stuff
 .omc
--- a/.markdownlint.json
+++ b/.markdownlint.json
@ -1,15 +0,0 @@
 {
  "default": true,
  "MD013": false,
  "MD024": false,
  "MD025": false,
  "MD029": false,
  "MD040": false,
  "MD041": false,
  "line-length": false,
  "no-duplicate-heading": false,
  "single-h1": false,
  "ol-prefix": false,
  "fenced-code-language": false,
  "first-line-h1": false
 }
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@ -1,132 +0,0 @@
 # .pre-commit-config.yaml
 repos:
  # Basic file checks (run on all files)
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
      - id: check-json
      - id: check-toml
      - id: check-added-large-files
        args: ['--maxkb=1000']
      - id: check-merge-conflict
      - id: debug-statements
        files: \.(py|js|ts)$
      - id: mixed-line-ending
        args: ['--fix=lf']
      # Additional checks from suggestions
      - id: check-docstring-first
        files: \.py$
      - id: check-executables-have-shebangs
      - id: check-case-conflict
  # Python code formatting and linting with ruff
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.8.4
    hooks:
      # Linter - only on Python directories
      - id: ruff
        args: [--fix]
        files: ^(src/|tests/|scripts/|migrations/|sdks/python/).*\.py$
      # Formatter - only on Python directories
      - id: ruff-format
        files: ^(src/|tests/|scripts/|migrations/|sdks/python/).*\.py$
  # Security checks - only on main src code (not tests/scripts)
  - repo: https://github.com/PyCQA/bandit
    rev: 1.7.10
    hooks:
      - id: bandit
        args: ['-r']
        files: ^(src/|sdks/python/src/).*\.py$
  # Local hooks using your uv environment
  - repo: local
    hooks:
      # TypeScript linting with biome
      - id: biome-check
        name: biome check and format
        entry: bash -c 'cd sdks/typescript && bun run lint:fix'
        language: system
        files: ^sdks/typescript/.*\.(js|ts|jsx|tsx|json|jsonc)$
        pass_filenames: false
      # Type checking with basedpyright - only on main Python code
      - id: basedpyright
        name: basedpyright
        entry: uv run basedpyright
        language: system
        files: ^(src/|tests/|sdks/python/|scripts/).*\.py$
        require_serial: true
        pass_filenames: true
      # Run main application tests
      - id: pytest-main
        name: pytest (main app)
        entry: uv run pytest -x tests/ --ignore=tests/alembic/
        language: system
        files: ^(src/|tests/).*\.py$
        stages: [pre-push]
        pass_filenames: false
      # Run Alembic tests only when migrations change
      - id: pytest-alembic
        name: pytest (alembic migrations)
        entry: uv run python scripts/run_alembic_tests.py
        language: system
        files: ^(migrations/versions/.*\.py|tests/alembic/.*\.py)$
        stages: [pre-push]
        pass_filenames: true
        require_serial: true
      # Ensure each alembic migration revision has a corresponding test file
      - id: ensure-alembic-coverage
        name: ensure alembic migration test coverage
        entry: uv run python scripts/ensure_alembic_tests.py
        language: system
        files: ^(migrations/versions/.*\.py|tests/alembic/revisions/.*\.py)$
        stages: [pre-push]
        pass_filenames: false
      # Run Python SDK tests (if they exist)
      - id: pytest-python-sdk
        name: pytest (Python SDK)
        entry: bash -c 'if [ -d "sdks/python/tests" ]; then cd sdks/python && uv run pytest; fi'
        language: system
        files: ^sdks/python/.*\.py$
        stages: [pre-push]
        pass_filenames: false
      # TypeScript build with bun (tests run via pytest)
      - id: typescript-check
        name: TypeScript build
        entry: bash -c 'if [ -f "sdks/typescript/package.json" ]; then cd sdks/typescript && bun run build; fi'
        language: system
        files: ^sdks/typescript/.*\.(js|ts|jsx|tsx|json)$
        stages: [pre-push]
        pass_filenames: false
      # TypeScript type checking with bun
      - id: typescript-typecheck
        name: TypeScript type check
        entry: bash -c 'if [ -f "sdks/typescript/package.json" ]; then cd sdks/typescript && bun run typecheck; fi'
        language: system
        files: ^sdks/typescript/.*\.(ts|tsx)$
        pass_filenames: false
  # Documentation linting
  - repo: https://github.com/igorshubovych/markdownlint-cli
    rev: v0.37.0
    hooks:
      - id: markdownlint
        args: ['--fix']
        files: \.(md|mdx)$
  # Commit message linting
  - repo: https://github.com/commitizen-tools/commitizen
    rev: v3.13.0
    hooks:
      - id: commitizen
        stages: [commit-msg]
--- a/.python-version
+++ b/.python-version
@ -1 +1 @@
-3.13
+3.11
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@ -1,693 +1,29 @@
-# Changelog
+# Change Log
 All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](http://keepachangelog.com/)
 and this project adheres to [Semantic Versioning](http://semver.org/).
-## [3.1.1] - 2026-09-02
+## [2.0.4]
 ### Changed
 - Server `requires-python` is `>=3.13`, matching the production image. Self-hosters on 3.10–3.12 need to upgrade; SDK and CLI floors are unchanged (#1090)
 ### Fixed
 - Concurrent `create_documents` writers to the same collection deadlocked on `times_derived` reinforcement UPDATEs issued in batch order; the error was swallowed per-document, the batch was lost, and the queue item was marked processed. Writers now lock target rows with `SELECT ... ORDER BY id FOR UPDATE` before applying, abort the batch on `SQLAlchemyError` instead of continuing through a dead session, and retry transient errors (deadlock, serialization failure, lock/statement timeout, lost connection) up to `MAX_RETRYABLE_ATTEMPTS` instead of burning the item (#1033)
 - Scope backfill no longer embeds, writes, and syncs every planned copy at once. A 14k-document session is ~580MB of vectors; several concurrent backfills OOM-killed the deriver at its 1000Mi limit and crash-looped because the work units never completed. Phases 2–4 now run per chunk of 500 specs, reload source embeddings per chunk, and drop them once synced. Membership is locked across chunk writes so a concurrent leave cannot commit between the check and the inserts (#1104)
 - Model-generated observations with NUL bytes (`\u0000`) no longer fail the exact-content dedup pre-fetch with a Postgres `DataError` that dropped the whole observer batch. Ingress already stripped NUL from user content; the deriver now strips it so stored text matches embedded text. All-NUL content is dropped rather than stored empty (#1095)
 - `search_messages` no longer forwards `top_k=0` to Turbopuffer (which requires 1..10000). Zero/negative limits short-circuit to empty results; tool limits are floored at 1. The documents path was already guarded (#970); this closes the message path (#1084)
 - OpenAI-compatible tool-call turns with `content=null` keep null through history replay instead of being coerced to `""`. Providers that bind reasoning state to the exact assistant message shape were breaking on the empty string. Tool-less null still becomes `""` (#1064)
 - The production image now ships `pyproject.toml` in the runtime stage, so the service reports its real version instead of `unknown` in OpenAPI and telemetry (#1074)
 ## [3.1.0] - 2026-08-25
 ### Added
 - Scopes: a named grouping of sessions that acts as a visibility boundary on recall, implemented as a facade over an observer peer (`scope.{name}` with `{"kind": "scope"}`). Developers manage them exclusively through `/v3/workspaces/{workspace_id}/scopes` (create-or-get, list, get, add/list/remove session membership) and an optional `scopes` field on session create — never through the observer/observed mechanics. Scope peers cannot author messages, cannot be a chat or representation `target`, are excluded from `peers.list` by default (`PeerGet.kind` = `"scope"` / `"all"` switches the view), and are rejected on the generic session-peer routes. Workspace-level key required; peer- and session-scoped keys get 401. Legacy peers occupying a reserved `scope.` name without the kind flag are refused with 409, never adopted (#884)
 - `scope` read option on chat, representation, session context, and workspace search. A single scope swaps the observer to the backing scope peer so conclusion recall, peer cards, and message tools stay inside that scope's membership. A list of scopes takes the union of member sessions (capped at `MAX_SESSION_ALLOWLIST_ENTRIES`) and executes via the session-allowlist path. Empty scopes fail closed. `scope` is mutually exclusive with `filters` and `session_id`. Workspace- or admin-level key required (403 otherwise). Scope peers are also rejected as `peer_target` / `peer_perspective` on session context and as the path peer or `target` on `GET /peers/{id}/context` (#897)
 - Scope backfill-by-copy and removal reconciliation. Adding a session that already has messages copies its explicit-level documents into the scope's collections (no LLM re-derivation; idempotent via `copied_from`). Removing a session soft-deletes those copies and fail-closed cascades to derived documents whose `source_ids` intersect anything removed, then enqueues a `card_refresh` dream with `rebuild=True` plus an omni dream. `GET /v3/workspaces/{workspace_id}/scopes/{scope_id}/status` reports per-session backfill state (`pending` / `completed` / `failed`, plus `docs_copied`) (#904)
 - Workspace-level chat at `POST /v3/workspaces/{workspace_id}/chat`: agentic dialectic over the whole workspace instead of a single (observer, observed) pair. Prefetches workspace stats and the top active peers' self cards, then searches pair-scoped memory with `[observer->observed]` attribution. Supports `session_id`, `scope`, `reasoning_level`, `response_format`, and SSE streaming (#931)
 - MCP workspace discovery: tools accept `workspace_id`, the worker honors an optional `X-Honcho-Workspace-ID` connection header, and `list_workspace` / `create_workspace` tools let clients pick or create a workspace instead of relying on the SDK default (#1020)
 - MCP `search` also queries conclusions in parallel with messages when `peer_id` is given, returning `{messages, conclusions}`. The conclusions leg degrades to `[]` on error so search never gets worse than before (#974)
 - Prometheus metrics for physical DB connections, visible even under `DB_POOL_CLASS=null`: `db_connections_open` (gauge) and `db_connections_established` (counter), hooked to SQLAlchemy connection-lifecycle events and registered on both the API and the deriver (#1055)
 - Bounded-label Prometheus series are zero-initialized at process start so an absent series means a broken scrape rather than "nothing happened" (#927)
 ### Changed
 - Workspace and pair chat system prompts now describe Honcho, peers, and the harness on their own terms, and render only the tools the request actually offers. The pair prompt no longer advertises a write tool that is not in the loadout (#1066)
 - Deriver idle polling backoff is longer and no longer reset by periodic reconciler work, so downstream connection pools can cull idle DB connections (#1015)
 - LLM provider SDKs are lazy-loaded so idle API and deriver processes no longer pay for every provider at import time (#1011)
 - Production image is a multi-stage build: LanceDB/PyArrow move behind an optional `lancedb` extra (`INSTALL_LANCEDB=true` to restore them), FastAPI's unused cloud CLI is dropped, and the venv is copied into the runtime image with final ownership so Docker does not double the layer. Default unpacked image is about 663 MB (was 1.7 GB) (#1014)
 - Redis Cluster cache keys hash-tag the namespace so one deployment's keys land on a single shard instead of opening a connection to every node. No behaviour change on a non-cluster backend; existing keys age out by TTL (#1058)
 - Deriver extraction prompt no longer leaks its own few-shot examples into extracted conclusions (#1028)
 ### Fixed
 - Observer-scoped `get_observation_context` no longer materializes every session the observer has ever joined into a `session_name IN (...)` list (twice in one statement). Past ~32k sessions that hit psycopg's bind-parameter ceiling and 500'd. The observer half is now a correlated `EXISTS` over `session_peers`, two bind parameters regardless of membership size (#1065)
 - Re-adding an already-active session peer no longer advances `joined_at`, so `peer_perspective` search keeps messages from the original join. Genuine leave-and-rejoin still starts a new window (#1059)
 - Transient embedding-provider errors (for example an OpenAI-compatible 200 with empty `data: []`) were relabeled as token-limit errors. Only genuine oversize input raises `EmbeddingTokenLimitError`; other provider errors propagate unchanged (#791)
 - The filter DSL now fails closed with a 422 instead of a 500 on bad shapes, coerces operands by column type (so `{"session_id": {"ne": "abc"}}` is a string inequality rather than "invalid numeric"), and treats `NOT` / `ne` as null-safe (`IS NOT TRUE` / `IS DISTINCT FROM`) so negation no longer drops rows whose field is unset. Closed-set columns like `level` reject unknown values. Session-allowlist entries must be well-formed ids (`*` is 422, not a silent widen) (#947)
 - `ne` on JSONB metadata keys is null-safe: a missing key is not equal to the compared value, so `{"metadata": {"foo": {"ne": "bar"}}}` includes rows where `foo` is unset (#1036)
 - Oversized texts in `simple_batch_embed` are truncated to the embedding token cap instead of failing the whole batch. Representation processing reports failed observer saves in `RepresentationCompletedEvent` and raises when every observer save fails (#1019)
 - Assistant `reasoning_content` (DeepSeek / some OpenRouter models) is preserved across tool-loop turns. Previously the tool loop dropped thinking content before building the next assistant history message, so continuation requests failed. `reasoning_details` still takes precedence when both are present (#1034)
 - `create_observations` now honors `DERIVER_DEDUPLICATE` instead of hardcoding `deduplicate=True`, matching the representation write path (#1018)
 - `provider_params.timeout` is forwarded to the OpenAI-compatible embedding client, not just the LLM client (#1024)
 - Conclusions semantic-search validation errors name the field and the constraint instead of returning a generic 422 (#960)
 - OpenAI-compatible embedding calls request `encoding_format=float` so providers that default to base64 do not break pgvector inserts (#938)
 - Gemini batch embedding works for `gemini-embedding-2*` models, which rejected the previous request shape (#745)
 - MCP OAuth with no advertised scopes no longer defaults to read-only (which 403'd chat and search POSTs). Protected-resource metadata advertises read and write (#1004)
 ## [3.0.12] - 2026-08-10
 ### Added
 - Session allowlist on the Dialectic and representation via a constrained `filters` body on `POST /peers/{peer_id}/chat` and `/representation`, supporting only the `session_id` key (a session id, a bare list, or `{"in": [...]}`). Unsupported keys and shapes are rejected with 422 rather than silently ignored, it composes with `session_id` (which must be included in the allowlist when both are given), and it is capped at 1,000 sessions per request. Enforcement is uniform and fail-closed at every recall chokepoint: scoped conclusion recall is restricted to `level == "explicit"` (dream-derived conclusions carry a single `session_name` but are synthesized across all sessions, so that stamp can't be scoped on), `get_reasoning_chain` is unavailable under an allowlist, and an empty allowlist short-circuits to empty results everywhere. Workspace keys pass the allowlist as-given; peer-scoped JWTs must be an active member of every allowlisted session (401 otherwise) (#882)
 - Bare-list membership sugar in the filter DSL: `{"session_id": ["s1", "s2"]}` is now shorthand for `{"session_id": {"in": [...]}}` on regular columns generically. JSONB metadata columns are excluded and keep containment semantics. Strictly additive, since a bare list on a regular column previously compiled to a type-mismatched equality that matched nothing (#881)
 - Optional structured outputs on the Dialectic: `response_format` (a JSON Schema with root type `object`) on peer chat makes `content` a JSON string conforming to that schema. Only a conservative subset of JSON Schema is supported, with DoS guards and non-recursive `$ref` support (#896)
 - Combined tool calling and structured output in the LLM transport layer, with per-backend request shaping: OpenAI routes tool-carrying structured requests through `create()` with an explicit `json_schema` response format (`parse()` 500s on non-strict function tools), Anthropic skips the `{` JSON prefill when tools are present so `tool_use` blocks stay reachable, and Gemini injects a schema instruction into the final turn instead of using native `response_schema` (rejected alongside function calling before Gemini 3). All backends skip structured-output parsing on tool-call turns, which carry no consumable content (#907)
 - `card_refresh` dream type: a lightweight dream that runs only the peer-card update, for event-driven refreshes such as membership changes and cold starts. Handled by a new `CardRefreshSpecialist` restricted to `get_recent_observations`, `search_memory`, and `update_peer_card` (no observation-mutating tools) with a tool-iteration cap of `min(6, DREAM.MAX_TOOL_ITERATIONS)`. `POST /v3/workspaces/{workspace_id}/schedule_dream` accepts `dream_type=card_refresh` plus a `rebuild` flag, which omits the existing card from the prompt so the specialist rebuilds it solely from observations present in the collection. Card refreshes never advance the omni dream guard pair (`last_dream_at` / `last_dream_document_count`) (#883)
 - Full-fidelity LLM trace stream, with Langfuse as one projection over it: each call is captured once (`CapturedLLMCall`) and fanned out to a CloudEvents trace stream (`llm.call.traced` / `trace.content`) and a Langfuse exporter, both reconstructing trace → run → step → generation from the same source of truth. Adds `TELEMETRY_TRACE_PAYLOADS_ENABLED` (default `false`), `TELEMETRY_TRACE_MAX_BYTES` (default 262144, per-message cap with oversized content clipped), `TELEMETRY_TRACE_PURPOSES` (JSON list of `CallPurpose` values; empty means all), and `LANGFUSE_EXPORTER_MODE` (`exporter` by default; `inline` is kept for one release for side-by-side validation). Embedding calls are traced, dreamer branches nest under one dream trace, tool calls become spans under their step, and high-volume events are sampled deterministically. `TRACE_ENDPOINT` is dropped (#845)
 - Redis Cluster support via `CACHE_CLUSTER` (for example GCP Memorystore for Redis Cluster), alongside a new `CACHE_LOCK_WAIT_CHECK_INTERVAL_SECONDS` (#905)
 - `EMBEDDING_MODEL_CONFIG__MAX_BATCH_SIZE` caps texts per embedding request for OpenAI-compatible providers with smaller limits than OpenAI's, such as DashScope `text-embedding-v4` (10) and Alibaba Bailian `qwen3.7-text-embedding` (20). When unset, native provider defaults are preserved (OpenAI 2048, Gemini 100) (#983)
 - Per-request provider timeouts via `provider_params.timeout` on any model config, validated at config load so a bad value fails at startup with the exact config path instead of surfacing per-request as a retried 500. Good values normalize to float seconds; Gemini's is converted to milliseconds (#832)
 - `RepresentationCompletedEvent` now reports deduplication counts: `exact_dup_in_batch_count`, `exact_dup_existing_count`, `semantic_dup_rejected_count`, and `semantic_dup_replaced_count` (#910)
 - OAuth discovery for MCP clients: the MCP worker serves `/.well-known/oauth-protected-resource` (RFC 9728) without auth so clients can discover the authorization server, and a 401 now carries `WWW-Authenticate: Bearer resource_metadata="..."` (exposed cross-origin) to start the flow (#923)
 - Prometheus metrics for the immediate-embed fast path: tasks shed because `EMBEDDING_MAX_PENDING_EMBED_TASKS` was reached, and the current in-flight task count (#892)
 - Docs: a detailed system architecture diagram, a Codex integration guide (#879), a structured-outputs page (#896), a section on filtering conclusions by reasoning level (#851), a health-check endpoint reference, and SDK updates (#867)
 ### Changed
 - **Breaking config change:** `DERIVER_REPRESENTATION_BATCH_MAX_TOKENS` is split into two settings that were previously conflated — `DERIVER_REPRESENTATION_BATCH_WORK_UNIT_TARGET_TOKENS` (default 512), the producer-side minimum a work unit accumulates before the deriver claims it, where `0` disables the gate; and `DERIVER_REPRESENTATION_BATCH_TARGET_INPUT_TOKENS` (default 1024), the consumer-side maximum context-window tokens per deriver LLM call. Deployments setting the old name must migrate (#889)
 - The immediate-embed fast path now applies backpressure: `EMBEDDING_MAX_PENDING_EMBED_TASKS` (default 50) caps in-flight embed tasks, and once saturated, message creation skips the fast path entirely and the reconciler embeds on its next cycle. `0` disables the fast path (#892)
 - Explicit-level documents are now kept session-pure, so memory can be built by copying explicit documents between collections. Enforcement refuses rather than rewrites: `create_documents` rejects explicit documents with a null `session_name`, exact dedup keys on (content, level, session-for-explicit), semantic dedup scopes candidate search to the same level and — for explicit documents — the same session, and the generic `create_observations` tool rejects `level='explicit'` outside message-ingestion (deriver) context. Derived levels keep cross-session consolidation (#883)
 - Sentry's `before_send` filter is centralized as `default_before_send` in `src/telemetry/sentry.py` instead of living only in the API's `main.py`, so the deriver gets the same non-actionable-exception filtering. All Sentry events also carry a `namespace` tag for correlation (#934, #870)
 - The minimal deriver's extraction examples no longer teach inferences its own output schema forbids. The `EXAMPLES` block demonstrated deriving a specific birthday from "I just had my 25th birthday last Saturday", deriving residence from a single visit ("I took my dog for a walk in NYC" → "alice lives in NYC"), and a "+ general knowledge" deductive output the deriver has no channel for. The replacements stay inside the schema's contract and teach the boundary: the dog/NYC message is kept and shown extracting correctly, and a separate example shows "lives in NYC" is valid when actually stated (#985)
 - Dreamer specialists are instructed not to output summaries (#894)
 - `session_name` is deprecated for scoping in favor of the session allowlist. It is not removed and not aliased: it also pins the query to one session, bypasses observer scoping, and drives session-history injection into the dialectic prompt, so it has no drop-in replacement (#882)
 - The MCP worker no longer requires the `X-Honcho-User-Name` or `X-Honcho-Assistant-Name` headers (#923)
 ### Fixed
 - Session scoping was applied to only one of the three working-representation query paths: `session_name` reached the recent-documents query, but the semantic and most-derived paths ignored it, so `limit_to_session` leaked cross-session conclusions into perspectives. The allowlist is now threaded uniformly through all three paths and pushed down to pgvector and external vector stores (#881)
 - Empty membership lists failed open in the vector-store filter builders, silently widening scope: LanceDB dropped empty `IN` clauses and Turbopuffer emitted a bare `In []` with undocumented semantics. Both now emit an explicit always-false predicate, and `_build_filter_conditions` checks `is not None` rather than truthiness so an empty list is no longer treated like `None` (#881, #882)
 - Session-scoped CRUD helpers ignored the session allowlist entirely, so a caller could read a session the allowlist forbids. The API routes guarded this with a 422, but the dialectic tools call these CRUD functions directly and bypassed it. `_semantic_search_messages` (covering `search_messages` and `search_messages_temporal`), `grep_messages`, `get_messages_by_date_range`, `get_recent_history`, and `get_observation_context` now return `[]` when `session_name` is set and outside the allowlist (#882)
 - The cache client logged the full Redis URL — including the password — at INFO and WARNING on every connection attempt and failure, exposing the live credential in container logs and downstream aggregation. Credentials are now redacted across userinfo, the `?password=` (redis-py) and `?secret=` (cashews) query params, scheme-less URLs whose password is invisible to `.port`/`.password` parsing, and malformed URLs, whose fallback previously echoed the raw input verbatim (#869)
 - A `top_k` of `0` reached the vector store, where Turbopuffer rejects it with a 400 (`top_k must be between 1 and 10000`). A non-positive `top_k` now returns `[]` before the embedding call, and the semantic budget floors at 1 so an explicitly requested search isn't silently allocated zero (#970)
 - Gemini clients had no HTTP timeout, so a stalled socket wedged the deriver worker's uvloop event loop, which the in-process reconciler shares. A 10-minute timeout is now set on both the Gemini LLM client and the Gemini embedding client (#903)
 - Dreamer conclusions were dated to ingestion time rather than their latest source observation, and their timestamps are now normalized (#890)
 - Langfuse I/O annotation was gated on `LANGFUSE_PUBLIC_KEY` instead of `langfuse_inline_enabled`, so in the default `exporter` mode it called `update_current_generation()` with no active span — logging "No active span in current context" roughly 14 times per dialectic run and building throwaway `model_dump` payloads on every LLM call. Separately, `AgentToolSummaryCreatedEvent` hardcoded `run_id="deriver"` / `iteration=0`, polluting `run_id` grouping in the CloudEvents stream with a phantom run; both fields are now optional and the resource id is keyed on `message_id:summary_type` (schema_version 2 → 3) (#845)
 - Assistant tool calls were dropped from the captured trace stream for OpenAI and Gemini: `build_captured_messages` read only `{role, content, tool_call_id}`, but those providers keep tool calls outside `content`, so replayed tool-call turns landed as empty content and Gemini lost its text and tool results entirely. Tool calls are now normalized per provider into a unified `tool_calls` field and folded into the content hash. Gemini's `thought_signature` is bytes, so `model_dump(mode="json")` raised `UnicodeDecodeError` inside `emit_trace`, silently dropping whole tool-calling iterations from the trace stream (billing and Langfuse were unaffected); it is now base64-encoded on the telemetry path while replay keeps the raw bytes (#845)
 - `EmbeddingClient.encoding` forced full client construction, raising "OpenAI API key is required" even though tiktoken needs no credentials. The document dedup tie-break only needs `.encoding` for token counting, so any test hitting that path failed in environments without embedding keys — notably CI for pull requests from forks. The encoding is now resolved from the configured model directly, falling back to `cl100k_base`, and the underlying client's encoding is reused only when it has already been constructed (#955)
 - The Docker build failed under Podman because the uv build inputs weren't copied (#878)
 - LanceDB was installed on macOS Intel, where it doesn't work. A PEP 508 marker excludes `darwin/x86_64` and the LanceDB vector-store import is wrapped so a misconfiguration surfaces as a clear config error (#496)
 - Prompt checks requiring the literal token "json" for `json_object` mode are now satisfied in lowercase (#887)
 - Reverted an unintended `RepresentationCompletedEvent` schema-version increment
 - Documented preinstalling pgvector as a privileged role for deployments where the `DB_CONNECTION_URI` role deliberately cannot create extensions (managed Postgres, Kubernetes operators, NixOS). `CREATE EXTENSION IF NOT EXISTS vector` does not help there, because Postgres checks the privilege before checking whether the extension exists. Docker Compose is unaffected, since the bundled stack connects as the `postgres` superuser (#984)
 ## [3.0.11] - 2026-06-24
 ### Added
 - `api_request_duration_seconds` Prometheus histogram tracking per-route request latency, labeled by method and endpoint (#837)
 - LLM `provider_params` passthroughs (`extra_body` / `extra_headers` / `extra_query`) are now forwarded to the underlying provider transport across all backends, with shape validation that rejects non-mapping values (#821)
 - `structured_output_mode` model-config option to use `json_object` mode for OpenAI-compatible providers that lack native Structured Outputs support (used by the deriver) (#820)
 - OpenRouter app-attribution headers (`HTTP-Referer` / `X-Openrouter-Title`) are now sent on OpenAI-compatible clients when the configured base URL is OpenRouter, so requests are attributed to "Honcho" in OpenRouter's dashboard (#805)
 - Langfuse traces are now tagged with user and session IDs for easier trace filtering (#814)
 - `DERIVER_REPRESENTATION_BATCH_MAX_AGE_SECONDS` (default 1800s) lets sub-threshold representation work units flush once their oldest unprocessed queue item ages out. Set it to `0` to keep the legacy behavior where sub-threshold tails wait indefinitely unless `DERIVER_FLUSH_ENABLED=true` (#826)
 - Conclusion responses now include a `level` field (`explicit`, `deductive`, `inductive`, `contradiction`); list/query endpoints support filtering by `level` via `filters`, with reserved filter keys protected from being overridden by user-supplied filters (#851)
 ### Changed
 - Peer-scoped JWTs now get read-only access to the sessions their peer is an active member of (session context, summaries, peers, their own per-session config, search, and message reads). Session-scoped JWTs remain confined to their session and cannot reach peer routes (#679)
 - Compacted Honcho's log output, with guarded ms/s metric formatting that falls back to a plain string for non-numeric values (#836)
 - Sentry now drops noisy infra/scrape transactions: the reconciler opens a transaction only once a batch has rows (idle cycles emit none), and a `traces_sampler` returns `0.0` for `/metrics`, `/health`, `/openapi.json`, `/docs`, `/redoc`, and the deriver metrics server. `SENTRY.TRACES_SAMPLE_RATE` still governs real traffic (#834)
 ### Fixed
 - Peer- and session-scoped JWTs were effectively workspace-scoped: authorization walked the route's declared scope and fell through to a workspace match, so a `{w, p: alice}` token could act on any peer in the workspace. JWTs are now authorized by their narrowest claim and never widen to workspace access (#679)
 - The keys API now rejects creating a peer- or session-scoped key without a workspace. Such keys were minted successfully but failed verification on every request (#679)
 - Agent-supplied observation IDs carrying the display-format `id:` prefix are now normalized (prefix and trailing whitespace stripped) before `source_ids` are stored and on `get_reasoning_chain` lookups, fixing corrupted provenance links and broken reasoning-chain traversal (#795)
 - Fixed a `create_tree` keyword-argument mismatch in the Dreamer's surprisal tree construction (#749)
 - Providers that omit output-token counts (observed with Gemini on tool-loop completions) returned `output_tokens=None`, which raised a Pydantic validation error that aborted the call and crashed the Dreamer's induction phase before inductive conclusions were persisted. `None` is now coerced to `0` so token accounting degrades gracefully (#809)
 - Document creation now performs exact (case-insensitive, whitespace-trimmed) content deduplication before the existing semantic dedup step: exact duplicates within a batch collapse to a single insert, and an exact match against a live document reinforces it (atomic `times_derived` increment) instead of creating a new row (#861)
 - The OpenAI backend passed `tool_choice` through raw while the Anthropic and Gemini backends translate Honcho's canonical vocabulary to their native form, so on a mixed-provider fallback chain (for example Gemini primary → OpenAI backup) a canonical `"any"` reached OpenAI unchanged and was rejected as an invalid param. The OpenAI backend now converts it, mirroring the others: `any`/`required` → `required`, `auto`/`none` pass through, and a tool-name string or `{"name": ...}` dict becomes a function selection (#850)
 - Langfuse `@observe` auto-capture serialized every argument of `honcho_llm_call_inner` into the generation span input, including `client_override` (a live `AsyncOpenAI`/`genai` client) and `selected_config` (which carries `api_key`). Auto-capture deep-copied the client into a half-constructed object whose teardown raised (`AsyncHttpxClientWrapper ... no attribute '_state'` on OpenAI, flooding stderr; `BaseApiClient ... no attribute '_http_options'` on Gemini), and it leaked `ModelConfig.api_key` into traces. Capture is now an explicit allowlist: `capture_input`/`capture_output` are disabled and curated, serializable input and output are stamped instead, with tuning knobs surfaced as `model_parameters` via a secret-bearing denylist and per-call token usage mirrored as `usage_details` (#849)
 ## [3.0.10] - 2026-06-15
 ### Added
 - Messages are now embedded via a background task rather than blocking API request
 - Read-only DB session mode (`get_read_db` / `tracked_db(..., read_only=True)`) so reads don't hold a transaction open across the work
 - `CORS_ORIGINS` env var to configure CORS allowed origins without editing source; defaults match the prior hardcoded list, so self-hosted deployments behind custom domains can whitelist their frontend (#697)
 - `scripts/generate_jwt.py` — utility for minting scoped or admin Honcho JWTs (`--admin`, `--workspace`/`--peer`/`--session`, `--expires` with human-friendly durations, `--print-only`) without calling the keys API (#757)
 - `STALE_WORK_UNIT_CLEANUP_INTERVAL_SECONDS` (default 60s) — minimum jittered spacing between deriver stale-work-unit cleanup runs, so cleanup no longer runs on every seconds-scale poll (`0.0` keeps the legacy every-poll behavior) (#773)
 ### Changed
 - Optimized the deriver and dreamer prompt cache prefixes to improve prompt-cache hit rates (#806)
 ### Fixed
 - `times_derived` is now properly reinforced when a duplicate conclusion is detected. It had been pinned at 1 for nearly every conclusion (the reject-new branch dropped the increment and the new-wins branch reset the count to 1), so `ORDER BY times_derived DESC` fell back to arbitrary heap order and froze stale conclusions to the front of injected context. Reinforcement is now an atomic increment and both most-derived queries gained a `created_at DESC` recency tiebreaker (#768)
 - Webhook creation now correctly rejects private/internal IP addresses (#793)
 ## [3.0.9] - 2026-06-02
 ### Changed
 - Connection acquisition is now a single attempt with no server-side retry, on a vanilla `AsyncSession`. A new `DB_CONNECT_TIMEOUT_SECONDS` (default 2s) bounds the attempt so a saturated or unreachable pooler fails fast instead of holding a client connection open to re-knock. A saturated DB now surfaces to the caller — the API returns an error and the deriver backs off and retries on a later poll — which lets the pooler drain rather than amplifying saturation.
 ### Added
 - Deriver poll jitter so instances that start together don't poll in lockstep: `DERIVER_POLLING_STARTUP_JITTER_SECONDS` (random delay before the first poll, default 30s) and `DERIVER_POLLING_JITTER_RATIO` (±fraction applied to every poll sleep, default 0.5). Both disable at `0.0`; the underlying backoff schedule is unchanged.
 ### Removed
 - Reverted the connection-checkout retry and `HonchoAsyncSession` custom session introduced in 3.0.8. Removed the `DB_CONNECTION_RETRY_ENABLED` / `DB_CONNECTION_RETRY_MAX_DELAY_SECONDS` / `DB_CONNECTION_RETRY_BACKOFF_INITIAL_SECONDS` / `DB_CONNECTION_RETRY_BACKOFF_MAX_SECONDS` settings, the `db_connection_acquisitions{outcome=...}` Prometheus counter, and the `db.pool.acquire` Sentry span. Alerting built on `db_connection_acquisitions` should migrate to `db_pool_connections` / `db_queries_in_flight`.
 ## [3.0.8] - 2026-06-01
 ### Added
 - Connection-checkout retry with bounded exponential backoff (tenacity) on `get_db`/`tracked_db`: transient transaction-pooler (Supavisor) rejections — SQLAlchemy `TimeoutError` and `OperationalError` — now retry with backoff instead of surfacing as 500s under client-connection saturation. Gated by
  `DB_CONNECTION_RETRY_ENABLED` with configurable delay/backoff knobs; ~10s default budget (#758)
 - `HonchoAsyncSession` — a lazy `AsyncSession` that checks out its pooled connection (with retry) on the first DB-touching call rather than at construction. Request handlers doing non-DB work (embedding, file, LLM) before their first query no longer pin a pooler connection across it. Only the checkout is retried;
  the statement still runs exactly once, so writes are never duplicated (#758)
 - Adaptive deriver queue polling: the poll interval backs off when the queue is idle or erroring (base → max, doubling each cycle) and snaps back to base the moment work is claimed, cutting steady-state query load against the DB. Gated by `DERIVER_POLLING_BACKOFF_ENABLED` with configurable max/multiplier (#758)
 - New Prometheus `db_pool_connections` gauge (checked_out / checked_in / size / overflow), labeled `api`|`deriver`, registered in both the API lifespan and the deriver metrics server (#758)
 - New Prometheus `db_connection_acquisitions{outcome=ok|retried|exhausted}` counter — the alertable early-warning signal that connection checkouts are retrying through pooler rejection, before requests start failing (#758)
 - New Prometheus `db_queries_in_flight` gauge — statements actually executing on the wire (via SQLAlchemy cursor-execute events). Paired with `checked_out`, the gap reveals connections held but parked (the "idle in transaction during an external call" antipattern). Gated on `METRICS.ENABLED` for zero overhead when
  off (#758)
 - Explicit `SqlalchemyIntegration` in both the API and deriver Sentry inits; connection acquisition wrapped in a `db.pool.acquire` span with live pool stats captured on retry exhaustion (#758)
 ### Changed
 - Default `POOL_TIMEOUT` lowered to 5s, with validation that it stays under the connection-retry budget when a pooled (non-null) `POOL_CLASS` is configured; `config.toml.example` and the v2/v3 configuration docs updated to match (#758)
 - `HonchoAsyncSession` wraps every DB-touching session method (execute / scalar / scalars / flush / merge / refresh / commit / get / get_one / stream / stream_scalars / delete) so the lazy-checkout-with-retry guarantee has no holes; the acquired flag resets on `close()`/`reset()` so a reused session re-acquires on
  next use (#758)
 ### Fixed
 - Roll the session back on a retryable checkout failure before retrying — a failed autobegin could otherwise leave it pending-rollback, making the next connection attempt raise instead of cleanly re-checking-out (#758)
 - Guard `DBPoolCollector.collect()` so a pool-read/import hiccup can't raise and abort the entire `/metrics` scrape (Prometheus drops all metrics if any collector raises) (#758)
 - Clamp the pool overflow gauge to ≥ 0 (it could report negative before the pool fills) (#758)
 - Removed a double-sleep in the deriver idle poll so the backoff cap is a true cap rather than 2× (#758)
 ## [3.0.7] - 2026-05-21
 ### Added
 - New `src/llm/` module as the single owner of provider runtime: clients, backends, history adapters, tool loop, request builder, credentials, and caching policy (#459)
 - `AttemptPlan` dataclass captures per-retry provider selection (client, model, reasoning_effort, thinking_budget_tokens, selected_config) and pins it across stream-final retries so streaming doesn't bounce back to primary after the tool loop has settled on fallback (#459)
 - Gemini JSON-schema sanitizer for `function_declarations` — strips keywords Gemini's validator rejects (`additionalProperties`, `allOf`, etc.) while preserving semantics for all other backends (#459)
 - Dreamer specialists derive `effective_max_tokens` from `model_config.max_output_tokens` with a per-specialist default fallback (#459)
 - New cloudevent `LLMCallCompletedEvent` (`llm.call.completed`) fires once per provider hit with full cost-attribution context: transport/provider_label, model, token counts with cache breakdown, finish_reason, outcome, `is_final_attempt`, retry/fallback state, duration, tool-call shape, streaming flag, and agent correlation (`run_id` + iteration). Includes a `CallPurpose` closed enum (`deriver.representation`, `dialectic.answer`, `dream.deduction|induction`, `summary.short|long`) (#637)
 - `RepresentationCompletedEvent` now carries `total_input_tokens` for full-trace cost attribution (#637)
 - Per-emitter `honcho_version` injection on all CloudEvents plus emitter health metrics (#637)
 - `TelemetrySettings.HIGH_VOLUME_SAMPLE_RATE` (default 1.0) — deterministic per-`run_id` sampler so an entire agent trace is kept or dropped together; aggregate envelopes bypass the sampler (#637)
 - Deriver custom instructions: per-workspace/peer guidance threaded into the deriver prompt with a `MAX_CUSTOM_INSTRUCTIONS_TOKENS` budget (default 2000); deriver `MAX_INPUT_TOKENS` raised 23000 → 25000 to make room (#609)
 - Configurable embedding dimensions: `EMBEDDING_MODEL_CONFIG__DIMENSIONS_MODE` (`auto`/`always`/`never`) controls whether the OpenAI `dimensions=` parameter is forwarded; `auto` (default) sends it when the operator explicitly set `EMBEDDING_VECTOR_DIMENSIONS` and the model is not on the known-rejecting allowlist (#678)
 - New `honcho-cli` package — Python CLI for inspecting and managing peers, sessions, and configuration against a Honcho deployment (#424)
 - `HONCHO_API_URL` env var support in the MCP Worker, enabling self-hosted Honcho deployments to point the Worker at their own instance instead of `https://api.honcho.dev` (#575)
 - API ID `max_length` increased from 100 to 512 across `WorkspaceCreate`, `PeerCreate`, and `SessionCreate` to align the API contract with the underlying DB schema (#684)
 - Regression tests covering fallback-config thinking-param reach, provider_params → extra_params boundary, OpenAI reasoning-model parameter routing, Gemini blocked finish_reason handling, and fail-fast `max_tool_iterations` validation (#459)
 ### Changed
 - All LLM orchestration moved out of `src/utils/clients.py` into `src/llm/` with modules split by responsibility (api, executor, tool_loop, runtime, registry, conversation, request_builder, credentials, caching, backends, history_adapters) (#459)
 - Default `ModelConfig` factories (deriver, summary, dreamer specialists, dialectic levels) normalized to `openai/gpt-5.4-mini` with no extra parameters set by default; operators add transport/thinking overrides explicitly (#459)
 - OpenAI reasoning-model routing widened via `_uses_max_completion_tokens` heuristic covering `gpt-5.x` and `o1/o3/o4` — these models receive `max_completion_tokens` instead of `max_tokens` (#459)
 - Override client factories switched from unbounded `@cache` to `@lru_cache(maxsize=128)` for predictable memory growth on long-running processes (#459)
 - `get_backend` now delegates to `client_for_model_config`, so the live-test path and production path share one missing-API-key validation (#459)
 - Blocked Gemini responses (`SAFETY`, `RECITATION`, `PROHIBITED_CONTENT`, `BLOCKLIST`) raise `LLMError` in the streaming path too (previously only the non-streaming path), ensuring retry/fallback logic fires uniformly (#459)
 - Transport-change env overrides now strip transport-specific thinking params (thinking_budget_tokens vs. reasoning_effort) during config merge, including at the dialectic-level merge, so switching from Anthropic → OpenAI doesn't leave orphaned Anthropic-only params that the OpenAI backend would reject (#459)
 - `max_tool_iterations` out-of-range inputs now raise `ValidationException` instead of being silently clamped (#459)
 - Public API schemas (`WorkspaceCreate`, `PeerCreate`, `SessionCreate`) and SDK validation (`api_types.py`, `validation.ts`) accept IDs up to 512 chars (was 100) (#684)
 - Peer card prompts reframed as stable identity markers (replaces the prior "biographical/profile facts" language). Induction specialist is now opted out of peer card writes (`can_update_peer_card = False`) so only deduction touches the card (#686)
 - Vector store queries no longer fetch embedding vectors — only document metadata is returned, reducing payload size and DB load (pgvector, lancedb, turbopuffer) (#682)
 - Langfuse trace metadata now includes `namespace`, `model`, and `provider` so traces can be filtered by deployment slice (#565)
 - Deriver: model-aware tokenizer (replaces the previously hardcoded encoding) and explicit guard on empty message content (#647)
 - Dialectic level defaults now merge correctly with per-level overrides in `src/config` (#656)
 - Default dialectic tool choice switched from forced/required to `auto` (#630)
 - Vector sync given a substantial retry budget to tolerate transient embedding provider outages (#604)
 - `AgentToolConclusionsDeletedEvent` payload now carries `levels` for parity with the rest of the conclusion event surface (#612)
 - Turbopuffer vector store: `InternalServerError` caught and surfaced as a warning rather than a hard failure; unused `upsert_with_retry` and `VectorUpsertResult` removed; explicit silent and explicit-error paths for vector DB server errors (#561)
 - Troubleshooting docs updated to reflect nested-env-var form for per-component thinking-budget overrides (#459)
 - README refresh (#681)
 - CLAUDE.md refreshed against the current `src/` layout (#680)
 ### Fixed
 - Fallback `ModelConfig` temperature and `thinking_budget_tokens` reach the backend on the final retry — previously the primary's values were pre-populated into caller kwargs early and clobbered fallback values via `effective_config_for_call(update=...)` (#459)
 - Stream-final retries pin to the `AttemptPlan` that succeeded rather than re-running provider selection through the outer `current_attempt` ContextVar (which could roll streaming back to primary after the tool loop had already switched to fallback) (#459)
 - OpenAI structured-output calls continue to use `chat.completions.parse()` with strict schema enforcement, while tool-calling paths use `chat.completions.create()` without `strict:True` for broader proxy compatibility (OpenRouter, vLLM, Ollama) (#459)
 - Gemini `cached_content` reuse keys now include `system_instruction` and `tool_config` so cache hits don't cross configurations that differ only in those fields (#459)
 - Removed strict parameter validation for thinking params on Anthropic and OpenAI transports — was rejecting valid per-transport configs (#686)
 - `reverse` query parameter is now honored on the v3 workspace list (`POST /v3/workspaces/list`), peer list (`POST /v3/workspaces/{workspace_id}/peers/list`), workspace-scoped session list (`POST /v3/workspaces/{workspace_id}/sessions/list`), and peer-scoped session list (`POST /v3/workspaces/{workspace_id}/peers/{peer_id}/sessions`). Honcho SDKs at 2.1.0+ were already sending `reverse=true` for these routes but the server silently ignored it. Ties on `created_at` now fall back to the internal nanoid `id` so ordering remains stable across pages (#685)
 - LLM client factories now receive `base_url` from `LLMSettings` for default providers — previously the override path honored `base_url` but the default path didn't, so operators pointing at OpenAI-compatible proxies via `LLM__OPENAI_BASE_URL` were ignored (#643, fixes #641)
 - Internal N+1 query in dialectic agent tool execution — collapsed per-iteration DB lookups into a single fetch (#652)
 - Dreamer threshold and time-guard semantics: `check_and_schedule_dream` count filter now includes only `documents.level == 'explicit'` (dreamer-created levels are output, not input, and were inflating the threshold and creating a feedback loop); `last_dream_at` write relocated from `enqueue_dream` into `process_dream` so duplicate enqueues or failed runs no longer reset the 8-hour time guard (#573)
 - Deriver: blank observations are filtered out before embedding (previously triggered noisy embedding calls and persisted empty rows); blank-observation filtering unified across tool paths (#615)
 - Surprisal module: filter for level observations changed from `{"level": levels}` to `{"level": {"in": levels}}` — `apply_filter()` requires operator syntax, so the prior call silently returned 0 results and made the entire Surprisal phase of the Dream cycle a no-op (#581, fixes #559)
 - Removed hardcoded `stop_sequences` override from Deriver `ModelConfig` (was clobbering operator-configured stop sequences) (#587)
 - Removed stale `stop_sequences` from tests (#607)
 - Embedding client: `embed()` now wraps single-string input in an array, restoring compatibility with OpenAI-compatible third-party providers that reject scalar input (#586)
 - Docker Compose: deriver service startup gated on the API service healthcheck (prevents races where the deriver starts before the API has run migrations) (#689)
 - Docker image: `HEALTHCHECK` directive removed from the shared base image — it probed an HTTP endpoint only the API serves, permanently marking deriver containers as unhealthy. Service-level health checks now belong in each service's own configuration (k8s readiness/liveness probes on the API Deployment only) (#530)
 - `tests/unified`: `--test-dir`/`--test-file` arguments now use an argparse mutually-exclusive group instead of manual validation (#650)
 - CrewAI example updated for the latest CrewAI protocol (#631)
 ### Removed
 - `src/utils/clients.py` deleted; its responsibilities are split across `src/llm/registry.py`, `src/llm/credentials.py`, and the backend-specific modules (#459)
 - `HEALTHCHECK` directive removed from the shared Docker image (#530)
 ## [3.0.6] - 2026-04-10
 ### Changed
 - Tightened transaction scopes across search, agent tools, queue manager, and webhook delivery to minimize DB connection hold time during external operations (#525)
 - Search operations refactored to two-phase pattern — external work (embeddings, LLM calls) completes before opening a transaction (#525)
 - Agent tool executor performs external operations before acquiring DB sessions (#525)
 - Queue manager transaction scope reduced to only the critical section (#525)
 - Webhook delivery no longer holds a DB session parameter (#525)
 ### Fixed
 - Session leakage in non-session-scoped dialectic chat calls (#526)
 ### Added
 - Health check endpoint (`/health`) for container orchestration and load balancer probes (#510)
 ## [3.0.5] - 2026-04-03
 ### Fixed
 - explicit rollback on all transactions to force connection closed
 ## [3.0.4] - 2026-04-02
 ### Added
 - JSONB metadata validation enforces 100 key limit and max depth of 5 (#419)
 ### Changed
 - Schemas refactored from single `schemas.py` into `schemas/api.py`, `schemas/configuration.py`, and `schemas/internal.py` with backwards-compatible re-exports (#419)
 ### Fixed
 - Missing `deleted_at` filter on `RepresentationManager._query_documents_recent()` and `._query_documents_most_derived()` allowed soft-deleted documents to leak into the deriver's working representation (#456)
 - `CleanupStaleItemsCompletedEvent` emitted spuriously when no queue item was actually deleted (#454)
 - Empty JSON file uploads caused unhandled errors; now returns normalized error responses (#434)
 - Memory leak: `_observation_locks` switched to `WeakValueDictionary` to prevent unbounded growth (#419)
 - SQL injection in `dependencies.py`: parameterized `set_config` calls to prevent injection via request context (#419)
 - NUL byte crashes: string inputs (message content, queries, peer cards) now stripped at schema level (#419)
 - Filter recursion depth capped at 5 to prevent stack overflow (#419)
 - Dedup-skipped observations now correctly reflected in created counts (#477)
 - External vector store support for message search — routes queries through configured external vector store with oversampling and
  deduplication to handle chunked embeddings (#479)
 - Dialectic agent no longer holds a DB connection during LLM calls — embeddings are pre-computed before tool execution, DB sessions isolated in `extract_preferences`, `query_documents` no longer accepts a DB session parameter (#477)
 ## [3.0.3] - 2026-02-25
 ### Added
 - Consolidated session context into a single DB session with 40/60 token budget allocation between summary and messages
 - Observation validation via `ObservationInput` Pydantic schema with partial-success support and batch embedding with per-observation fallback
 - Peer card hard cap of 40 facts with case-insensitive deduplication and whitespace normalization
 - Safe integer coercion (`_safe_int`) for all LLM tool inputs to handle non-integer values like `"Infinity"`
 - Embedding pre-computation and reuse across multiple search calls in dialectic and representation flows
 - Peer existence validation in dialectic chat endpoints — raises ResourceNotFoundException instead of silently failing
 - Logging filter to suppress noisy `GET /metrics` access logs
 - Oolong long-context aggregation benchmark (synth and real variants, 1K–4M token context windows)
 - MolecularBench fact quality evaluation (ambiguity, decontextuality, minimality scoring)
 - CoverageBench information recall evaluation (gold fact extraction, coverage matching, QA verification)
 - LoCoMo summary-as-context baseline evaluation
 - Webhook delivery tests, dependency lifecycle tests, queue cleanup tests, summarizer fallback tests
 - Parallel test execution via pytest-xdist with worker-specific databases
 - `test_reasoning_levels.py` script for LOCOM dataset testing across reasoning levels
 ### Changed
 - Workspace deletion is now async — returns 202 Accepted, validates no active sessions (409 Conflict), cascade-deletes in background
 - Redis caching layer now stores plain-dict instead of ORM objects, with v2-prefixed keys, storage, resilient `safe_cache_set`/`safe_cache_delete` helpers, and deferred post-commit cache invalidation
 - All `get_or_create_*` CRUD operations now use savepoints (`db.begin_nested()`) instead of commit/rollback for race condition prevention
 - Reconciler vector sync uses direct ORM mutation instead of batch parameterized UPDATE statements
 - Summarizer enforces hard word limit in prompt and creates fallback text for empty summaries with `summary_tokens = 0`
 - Blocked Gemini responses (SAFETY, RECITATION, PROHIBITED_CONTENT, BLOCKLIST) now raise `LLMError` to trigger retry/backup-provider logic
 - Gemini client explicitly sets `max_output_tokens` from `max_tokens` parameter
 - All deriver and metrics collector logging replaced with structured `logging.getLogger(__name__)` calls
 - Dreamer specialist prompts updated to enforce durable-facts-only peer cards with max 40 entries and deduplication
 - `GetOrCreateResult` changed from `NamedTuple` to `dataclass` with `async post_commit()` method
 - FastAPI upgraded from 0.111.0 to 0.131.0; added pyarrow dependency
 - Queue status filtering to only show user-facing tasks (representation, summary, dream); excludes internal infrastructure tasks
 ### Fixed
 - JWT timestamp bug — `JWTParams.t` was evaluated once at class definition time instead of per-instance
 - Session cache invalidation on deletion was missing
 - `get_peer_card()` now properly propagates `ResourceNotFoundException` instead of swallowing it
 - `set_peer_card()` ensures peer exists via `get_or_create_peers()` before updating
 - Backup provider failover with proper tool input type safety
 - Removed `setup_admin_jwt()` from server startup
 - Sentry coroutine detection switched from `asyncio.iscoroutinefunction` to `inspect.iscoroutinefunction`
 ### Removed
 - `explicit.py` and `obex.py` benchmarks replaced by coverage.py and molecular.py
 - Claude Code review automation workflow (`.github/workflows/claude.yml`)
 - Coverage reporting from default pytest configuration
 ## [3.0.2] - 2026-01-27
 ### Added
 - Documentation for reasoning_level and Claude Code plugin
 ### Changed
 - Gave dreaming sub-agents better prompting around peer card creation, tweaked overall prompts
 ### Fixed
 - Added message-search fallback for memory search tool, necessary in fresh sessions
 - Made FLUSH_ENABLED a config value
 - Removed N+1 query in search_messages
 ## [3.0.1] - 2026-01-27
 ### Fixed
 - Token counting in Explicit Agent Loop
 - Backwards compatibility of queue items
 ## [3.0.0] - 2026-01-19
 ### Added
 - Agentic Dreamer for intelligent memory consolidation using LLM agents
 - Agentic Dialectic for query answering using LLM agents with tool use
 - Reasoning levels configuration for dialectic (`minimal`, `low`, `medium`, `high`, `max`)
 - Prometheus token tracking for deriver and dialectic operations
 - n8n integration
 - Cloud Events for auditable telemetry
 - External Vector Store support for turbopuffer and lancedb with reconciliation flow
 ### Changed
 - API route renaming for consistency
 - Dreamer and dialectic now respect peer card configuration settings
 - Observations renamed to Conclusions across API and SDKs
 - Deriver to buffer representation tasks to normalize workloads
 - Local Representation tasks to create singular QueueItems
 - getContext endpoint to use `search_query` rather than force `last_user_message`
 ### Fixed
 - Dream scheduling bugs
 - Summary creation when start_message_id > end_message_id
 - Cashews upgrade to prevent NoScriptError
 - Memory leak in `accumulate_metric` call
 ### Removed
 - Peer card configuration from message configuration; peer cards no longer created/updated in deriver process
 ## [2.5.1] - 2025-12-15
 ### Fixed
 - Backwards compatibility for `message_ids` field in documents to handle legacy tuple format
 ## [2.5.0] - 2025-12-03
 ### Added
 - Message level configurations
 - CRUD operations for observations
 - Comprehensive test cases for harness
 - Peer level get_context
 - Set Peer Card Method
 - Manual dreaming trigger endpoint
 ### Changed
 - Configurations to support more flags for fine-grained control of the deriver, peer cards, summaries, etc.
 - Working Representations to support more fine-grained parameters
 ### Fixed
 - File uploads to match `MessageCreate` structure
 - Cache invalidation strategy
 ## [2.4.3] - 2025-11-20
 ### Added
 - Redis caching to improve DB IO
 - Backup LLM provider to avoid failures when a provider is down
 ### Changed
 - QueueItems to use standardized columns
 - Improved Deduplication logic for Representation Tasks
 - More finegrained metrics for representation, summary, and peer card tasks
 - DB constraint to follow standard naming conventions
 ## [2.4.2] - 2025-11-03
 ### Fixed
 - Langfuse tracing to have readable waterfalls
 - Alembic Migrations to match models.py
 - message_in_seq correctly included in webhook payload
 ### Changed
 - Alembic to always use a session pooler
 - Statement timeout during alembic operations to 5 min
 ## [2.4.1] - 2025-10-24
 ### Added
 - Alembic migration validation test suite
 ### Fixed
 - Alembic migrations to batch changes
 - Batch message creation sequence number
 ### Changed
 - Logging infrastructure to remove noisy messages
 - Sentry integration is centralized
 ## [2.4.0] - 2025-10-09
 ### Added
 - Unified `Representation` class
 - vllm client support
 - Periodic queue cleanup logic
 - WIP Dreaming Feature
 - LongMemEval to Test Bench
 - Prometheus Client for better Metrics
 - Performance metrics instrumentation
 - Error reporting to deriver
 - Workspace Delete Method
 - Multi-db option in test harness
 ### Changed
 - Working Representations are Queried on the fly rather than cached in metadata
 - EmbeddingStore to RepresentationFactory
 - Summary Response Model to use public_id of message for cutoff
 - Semantic across codebase to reference resources based on `observer` and `observed`
 - Prompts for Deriver & Dialectic to reference peer_id and add examples
 - `Get Context` route returns peer card and representation in addition to messages and summaries
 - Refactoring logger.info calls to logger.debug where applicable
 ### Fixed
 - Gemini client to use async methods
 ## [2.3.3] — 2025-10-01
 ### Changed
 - Deriver Rollup Queue processes interleaved messages for more context
 ### Fixed
 - Dialectic Streaming to follow SSE conventions
 - Sentry tracing in the deriver
 ## [2.3.2] — 2025-09-25
 ### Added
 - Get peer cards endpoint (`GET /v2/peers/{peer_id}/card`) for retrieving targeted peer context information
 ### Changed
 - Replaced Mirascope dependency with small client implementation for better control
 - Optimized deriver performance by using joins on messages table instead of storing token count in queue payload
 - Database scope optimization for various operations
 - Batch representation task processing for ~10x speed improvement in practice
 ### Fixed
 - Separated clean and claim work units in queue manager to prevent race conditions
 - Skip locked ActiveQueueSession rows on delete operations
 - Langfuse SDK integration updates for compatibility
 - Added configurable maximum message size to prevent token overflow in deriver
 - Various minor bugfixes
 ## [2.3.1] - 2025-09-18
 ### Fixed
 - Added max message count to deriver in order to not overflow token limits
 ## [2.3.0] — 2025-08-14
 ### Added
 - `getSummaries` endpoint to get all available summaries for a session directly
 - Peer Card feature to improve context for deriver and dialectic
 ### Changed
 - Session Peer limit to be based on observers instead, renamed config value to
  `SESSION_OBSERVERS_LIMIT`
 - `Messages` can take a custom timestamp for the `created_at` field, defaulting
  to the current time
 - `get_context` endpoint returns detailed `Summary` object rather than just
  summary content
 - Working representations use a FIFO queue structure to maintain facts rather
  than a full rewrite
 - Optimized deriver enqueue by prefetching message sequence numbers (eliminates N+1 queries)
 ### Fixed
 - Deriver uses `get_context` internally to prevent context window limit errors
 - Embedding store will truncate context when querying documents to prevent embedding
  token limit errors
 - Queue manager to schedule work based on available works rather than total
  number of workers
 - Queue manager to use atomic db transactions rather than long lived transaction
  for the worker lifecycle
 - Timestamp formats unified to ISO 8601 across the codebase
 - Internal get_context method's cutoff value is exclusive now
 ## [2.2.0] — 2025-08-07
 ### Added
 - Arbitrary filters now available on all search endpoints
 - Search combines full-text and semantic using reciprocal rank fusion
 - Webhook support (currently only supports queue_empty and test events, more to come)
 - Small test harness and custom test format for evaluating Honcho output quality
 - Added MCP server and documentation for it
 ### Changed
 - Search has 10 results by default, max 100 results
 - Queue structure generalized to handle more event types
 - Summarizer now exhaustive by default and tuned for performance
 ### Fixed
 - Resolve race condition for peers that leave a session while sending messages
 - Added explicit rollback to solve integrity error in queue
 - Re-introduced Sentry tracing to deriver
 - Better integrity logic in get_or_create API methods
 ## [2.1.2] — 2025-07-30
 ### Fixed
 - Summarizer module to ignore empty summaries and pass appropriate one to get_context
 - Structured Outputs calls with OpenAI provider to pass strict=True to Pydantic Schema
 ## [2.1.1] — 2025-07-23
 ### Added
 - Test harness for custom Honcho evaluations
 - Better support for session and peer aware dialectic queries
 - Langfuse settings
 - Added recent history to dialectic prompt, dynamic based on new context window size setting
 ### Fixed
 - Summary queue logic
 - Formatting of logs
 - Filtering by session
 - Peer targeting in queries
 ### Changed
 - Made query expansion in dialectic off by default
 - Overhauled logging
 - Refactor summarization for performance and code clarity
 - Refactor queue payloads for clarity
 ## [2.1.0] — 2025-07-17
 ### Added
 - File uploads
 - Brand new "ROTE" deriver system
 - Updated dialectic system
 - Local working representations
 - Better logging for deriver/dialectic
 - Endpoint for deriver queue status
 ### Fixed
 - Document insertion
 - Session-scoped and peer-targeted dialectic queries work now
 ### Removed
 - Peer-level messages
 ### Changed
 - Dialectic chat endpoint takes a single query
 - Rearranged configuration values (LLM, Deriver, Dialectic, History->Summary)
 ## [2.0.5] - 2025-07-11
 ### Fixed
 - Groq API client to use the Async library
 ## [2.0.4] - 2025-07-02
 ### Fixed
 - Migration/provision scripts did not have correct database connection arguments, causing timeouts
-## [2.0.3] - 2025-07-01
+## [2.0.3]
 ### Fixed
 - Bug that causes runtime error when Sentry flags are enabled
-## [2.0.2] - 2025-06-27
+## [2.0.2]
 ### Fixed
 - Database initialization was misconfigured and led to provision_db script failing: switch to consistent working configuration with transaction pooler
-## [2.0.1] - 2025-06-26
+## [2.0.1]
 ### Added
@ -708,7 +44,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 - Use new config arrangement everywhere
 - Remove hardcoded responses
-## [2.0.0] - 2025-06-24
+## [2.0.0]
 ### Added
@ -751,7 +87,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 - Collections and Documents no longer exposed in the API, solely internal
 - Obsolete tests for apps, users, collections, documents, and metamessages
-## [1.1.0] - 2025-05-15
+## [1.1.0]
 ### Added
@ -761,7 +97,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 ### Changed
 - `/list` endpoints to not require a request body
- `metamessage_type` to `label` with backwards compatibility
+- `metamessage_type` to `label` with backwards compatability
 - Database Provisioning to rely on alembic
 - Database Session Manager to explicitly rollback transactions before closing
  the connection
@ -771,7 +107,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 - Alembic Migrations to include initial database migrations
 - Sentry Middleware to not report Honcho Exceptions
-## [1.0.0] - 2025-04-10
+## [1.0.0]
 ### Added
@ -787,7 +123,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 - Database provisioning is a separate script instead of happening on startup
 - Consolidated `session/chat` and `session/chat/stream` endpoints
-## [0.0.16] - 2025-03-05
+## [0.0.16]
 ### Added
@ -808,7 +144,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 - Self-hosting documentation and README to mention `uv` instead of `poetry`
-## [0.0.15] - 2025-01-06
+## [0.0.15]
 ### Added
@ -935,7 +271,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 - Authentication Middleware now implemented using built-in FastAPI Security
  module
 - Get by name routes for users and collections now include "name" in slug
- Python SDK moved to separate [repository](https://github.com/plastic-labs/honcho-python)
+- Python SDK moved to separate [respository](https://github.com/plastic-labs/honcho-python)
 ### Fixed
@ -1006,7 +342,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 ### Changed
 - session_data is now metadata
- session_data is a JSON field used python `dict` for compatibility
+- session_data is a JSON field used python `dict` for compatability
 ## [0.0.2] — 2024-02-01
--- a/CLAUDE.md
+++ b/CLAUDE.md
@ -1,20 +1,16 @@
 # CLAUDE.md
 This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
 # Honcho Overview
 ## What is Honcho?
-Honcho is an infrastructure layer for building AI agents with memory and social cognition. Its primary purposes include:
+Honcho is an infrastructure layer for building AI agents with social cognition and theory of mind capabilities. Its primary purposes include:
 - Imbuing agents with a sense of identity
 - Personalizing user experiences through understanding user psychology
- Providing a Chat Endpoint (the Dialectic agent) that injects personal context just-in-time
+- Providing a Dialectic API that injects personal context just-in-time
 - Supporting development of LLM-powered applications that adapt to end users
 - Enabling multi-peer sessions where multiple participants (users or agents) can interact
-Honcho leverages the inherent reasoning capabilities of LLMs to build coherent models of user psychology over time, enabling more personalized and effective AI interactions.
+Honcho leverages the inherent theory-of-mind capabilities of LLMs to build coherent models of user psychology over time, enabling more personalized and effective AI interactions.
 ## Core Concepts
@ -32,27 +28,25 @@ Honcho uses a peer-based model where both users and agents are represented as "p
 - **Peer** (formerly User): Any participant in the system (human or AI)
 - **Session**: A conversation context that can involve multiple peers
 - **Message**: Data units that can represent communication between peers OR arbitrary data ingested by a peer to enhance its global representation
- **Collections & Documents**: Internal vector storage for peer representations. Collections are keyed by `(observer, observed)` peer pairs. Collections/Documents are not directly exposed via API, but the observations stored within them are exposed as **Conclusions** (see `/v3/.../conclusions` endpoints).
+- **Collections & Documents**: Internal vector storage for theory-of-mind representations (not exposed via API)
 ## Architecture Overview
 ### API Structure
-All API routes follow the pattern: `/v3/{resource}/{id}/{action}`. Most "list/search" endpoints are `POST` so they can accept rich filter bodies.
+All API routes follow the pattern: `/v1/{resource}/{id}/{action}`
 - **Workspaces**: Create, list, update, search
 - **Peers**: Create, list, update, chat (dialectic), messages, representation
 - **Sessions**: Create, list, update, delete, clone, manage peers, get context
- **Messages**: Create (batch up to 100), upload (file), list, get, update
+- **Messages**: Create (batch up to 100), list, get, update
- **Conclusions**: Create, list, query (semantic search), delete — the API-facing name for observations stored in `(observer, observed)` collections
+- **Keys**: Create scoped JWT tokens
 - **Keys**: Create scoped JWTs
 - **Webhooks**: Register endpoint, list, delete, test
 ### Key Features
-#### Chat Endpoint (Dialectic agent) (`/peers/{peer_id}/chat`)
+#### Dialectic API (`/peers/{peer_id}/chat`)
- Provides bespoke responses informed by the representation
+- Provides theory-of-mind informed responses
 - Integrates long-term facts from vector storage
 - Supports streaming responses
 - Configurable LLM providers
@ -61,11 +55,18 @@ All API routes follow the pattern: `/v3/{resource}/{id}/{action}`. Most "list/se
 1. Messages created via API (batch or single)
 2. Enqueued for background processing:
-   - `representation`: Update peer's context
+   - `representation`: Update peer's theory of mind
   - `summary`: Create session summaries
 3. Session-based queue processing ensures order
 4. Results stored internally in vector DB
 #### Theory of Mind System
 - Multiple implementation methods (conversational, single_prompt, long_term)
 - Facts extracted from messages and stored in collections
 - Representations combine short-term inference with long-term facts
 - Configurable via peer and session feature flags
 ### Configuration
 - Hierarchical config: config.toml + environment variables
@ -86,27 +87,6 @@ All API routes follow the pattern: `/v3/{resource}/{id}/{action}`. Most "list/se
 - Typechecking: `uv run basedpyright`
 - Format code: `uv run ruff format src/`
 ### SDK Testing
 #### TypeScript SDK
 **🚨 DO NOT RUN `bun test` DIRECTLY. IT WILL NOT WORK. 🚨**
 The TypeScript SDK tests require a running Honcho server with database and Redis. Running `bun test` alone will fail immediately because there's no server. The tests are orchestrated via pytest which handles all the infrastructure setup.
 **The ONLY way to run TypeScript SDK tests:**
 ```bash
 # From the monorepo root (not from sdks/typescript/)
 uv run pytest tests/ -k typescript
 ```
 **To type-check the TypeScript SDK (this is fine to run directly):**
 ```bash
 cd sdks/typescript && bun run tsc --noEmit
 ```
 ### Code Style
 - Follow isort conventions with absolute imports preferred
@ -115,171 +95,37 @@ cd sdks/typescript && bun run tsc --noEmit
 - Line length: 88 chars (Black compatible)
 - Explicit error handling with appropriate exception types
 - Docstrings: Use Google style docstrings
 - **Never hold a DB session during external calls** (LLM, embedding, HTTP). If a function needs both a DB session and an external call result, compute the external result first and pass it as a parameter. This avoids tying up DB connections during slow network I/O. Use `tracked_db` for short-lived, DB-only operations; pass a shared session when multiple DB-only calls can reuse one connection.
 - **Never write through a read-only session** (`tracked_db(..., read_only=True)`, `get_read_db`, `ReadSessionLocal`). These run in AUTOCOMMIT mode with no transaction: writes are NOT blocked by the database — they silently commit immediately, and `begin_nested()` savepoints break. There is no runtime guard; this is enforced by convention only. Use `read_only=True` strictly for SELECT-only windows; anything that mutates (including get-or-create paths) must use a regular write session.
 #### Multi-row locking and deadlocks
 Tables written concurrently by more than one worker — `documents` (deriver, dreamer, scope backfill/removal, reconciler) and `queue` (every deriver replica) — deadlock when two writers touch an overlapping row set in different orders. Rules:
 - **A multi-row `SELECT ... FOR UPDATE` MUST carry an explicit `ORDER BY <pk>`.** Without it Postgres locks in scan order, which differs per plan, so two writers with overlapping sets can cycle. `_apply_document_row_updates` in `src/crud/document.py` is the reference implementation.
 - **`WHERE id IN (...)` does NOT impose an order**, so sorting the Python list is a no-op — the list order is discarded and the planner picks `Bitmap Heap Scan` (ctid order), `Index Scan` (id order), or `Seq Scan` per invocation. Deterministic ordering requires either a preceding `SELECT ... ORDER BY id FOR UPDATE` or `WHERE id IN (SELECT id ... ORDER BY id FOR UPDATE)`.
 - **`Document.id` is a random nanoid** (`models.py`), so id order is uncorrelated with physical order — an unordered predicate `UPDATE`/`DELETE` is roughly a coin flip against an id-ordered locker per row pair, not a rare edge case. (`QueueItem.id` is an integer identity, so there id order is also chronological.)
 - **Prefer no lock at all.** A single `UPDATE ... WHERE <predicate>` acquires row locks as it writes and has no separate lock phase to get wrong. Reach for `FOR UPDATE` only when a value must be read, computed in Python, and written back — that read-modify-write is the only reason `_apply_document_row_updates` locks (it replaced a server-side `func.greatest()`), and `populate_existing=True` is required with it so the identity map doesn't serve a stale pre-lock value. Server-side expressions (`func.greatest`, the JSONB `-` operator) avoid the lock entirely; see `_clear_work_unit_retry_attempts` in `src/deriver/queue_manager.py`.
 - `FOR UPDATE SKIP LOCKED` (the reconciler's claim pattern) never waits, so it cannot be a deadlock partner — but holding those locks across an external call still stalls other writers. See the "never hold a DB session during external calls" rule above.
 #### Auth scoping
 - **`allow_member_read=True` (in `require_auth(...)`) is read-only — NEVER set it on a route that mutates state.** It lets a peer-scoped key reach a session route when its peer is an active member of the session, so on a mutating route it would hand any session member write access (message injection, config mutation, deletion). HTTP method is not a reliable read/write signal here (some read routes use POST for a richer body), so this is enforced by an explicit allowlist in `tests/routes/test_auth_route_policy.py` — adding the flag to a new route fails that test until you consciously add the route to `EXPECTED_MEMBER_READ_ROUTES`, and you must never add a mutating method there.
 - **When a member-read route is keyed by another sub-resource** (e.g. `peers/{peer_id}/config`), the handler must additionally confirm a peer-scoped caller only reads its OWN resource (`jwt_params.p == peer_id`, else raise `AuthenticationException`). Membership grants session access, not access to a co-member's data. See `get_peer_config` in `src/routers/sessions.py`.
 ### Runtime Architecture
 Honcho runs as two cooperating processes that share a Postgres database and Redis cache:
 - **API server** (`uv run fastapi dev src/main.py`) — handles HTTP, enqueues background work, returns immediately. Hosts the **Dialectic** agent inline (synchronous tool loop during chat requests).
 - **Deriver worker** (`uv run python -m src.deriver`) — long-running queue consumer (uvloop). Runs the **Deriver**, **Summarizer**, and **Dreamer** off the queue. Can run multiple instances (`DERIVER_WORKERS`). Also hosts an in-process **Reconciler scheduler** (`src/reconciler/`) that periodically embeds messages with `sync_state='pending'` in `MessageEmbedding` and cleans up stale queue items — embedding generation is decoupled from message creation by design.
 ### Agent Architecture
 Honcho uses several specialized LLM agents. They share tool definitions and the LLM client abstraction in `src/utils/agent_tools.py` + `src/llm/`.
 > **Terminology:** what users see as **conclusions** (the public API surface and the term we use in documentation) is called **observations** in code symbols — `create_observations`, `delete_observations`, `get_observation_context`, etc. Doc prose below uses "conclusions"; references to actual code symbols stay as "observations."
 #### 1. Deriver (`src/deriver/`)
 **Role**: Memory formation through content ingestion.
 The Deriver processes batches of incoming messages and extracts conclusions about peers. The current architecture is "minimal deriver" — a **single LLM call** per batch using structured output, not an agentic tool loop. This trades flexibility for cost and predictability.
 - **Trigger**: Messages enqueued by `src/deriver/enqueue.py` on message create; consumed by `src/deriver/queue_manager.py` → `consumer.process_item()` → `deriver.process_representation_tasks_batch()`.
 - **Output**: Explicit conclusions (direct facts) and deductive conclusions (inferences) saved to `(observer, observed)` collections.
 - **Entry point**: `src/deriver/__main__.py` → `queue_manager.main()`.
 - **Prompts**: `src/deriver/prompts.py` (`minimal_deriver_prompt`).
 - **Custom instructions**: per-workspace/peer guidance can be threaded into the prompt via reasoning configuration; `DERIVER__MAX_CUSTOM_INSTRUCTIONS_TOKENS` caps the addition (default 2000) and `DERIVER__MAX_INPUT_TOKENS` defaults to 25000 to make room.
 #### 2. Dialectic (`src/dialectic/`)
 **Role**: Analysis and recall for answering queries.
 The Dialectic answers questions about peers by strategically gathering context from memory. It is the only tool-using agent on the synchronous request path — it loops over `DIALECTIC_TOOLS` until it has enough context to answer. (The Dreamer specialists also use tools, but run off the queue.)
 - **Trigger**: API call to `POST /v3/.../peers/{peer_id}/chat`.
 - **Tools** (see `DIALECTIC_TOOLS` in `src/utils/agent_tools.py`): `search_memory`, `search_messages`, `get_observation_context`, `grep_messages`, `get_messages_by_date_range`, `search_messages_temporal`, `get_reasoning_chain`. At the `minimal` reasoning level, a reduced set (`DIALECTIC_TOOLS_MINIMAL`) is used: just `search_memory` + `search_messages`.
 - **Reasoning levels**: 5 tiers — `minimal`, `low`, `medium`, `high`, `max` — each with its own model config (see `DialecticLevelSettings` in `src/config.py`).
 - **Output**: Natural language response grounded in gathered context. Supports SSE streaming.
 - **Entry point**: `src/dialectic/chat.py` → `agentic_chat()` / `agentic_chat_stream()` → `DialecticAgent` (in `src/dialectic/core.py`).
 #### 3. Dreamer (`src/dreamer/`)
 **Role**: Consolidation and self-improvement of memory.
 The Dreamer is an orchestrated multi-specialist system that runs during scheduled "dreams" to consolidate conclusions and build reasoning trees.
 - **Trigger**: Scheduled via `DreamScheduler` (`src/dreamer/dream_scheduler.py`) or explicit dream task on the queue.
 - **Strategy**: Surprisal-based prioritization (`src/dreamer/surprisal.py`) selects which conclusions to expand. The orchestrator (`orchestrator.run_dream`) runs two specialist phases:
  1. **DeductionSpecialist** (`specialists.py`) — produces deductive conclusions from explicit conclusions. Tools: `get_recent_observations`, `search_memory`, `search_messages`, `create_observations_deductive`, `delete_observations`, `update_peer_card`.
  2. **InductionSpecialist** — produces inductive conclusions from explicit + deductive conclusions. Tools: same discovery set + `create_observations_inductive`, `update_peer_card`.
 - **Reasoning trees** (`src/dreamer/trees/`, migration `f1a2b3c4d5e6_add_reasoning_tree_columns`): each conclusion links to its premises and downstream conclusions, enabling `get_reasoning_chain` traversal at recall time.
 - **Output**: Deductive/inductive conclusions, consolidated redundancies, updated peer cards.
 - **Entry point**: `src/dreamer/orchestrator.py` → `process_dream()` (the package-level export from `src/dreamer/__init__.py`), which wraps `run_dream()`.
 #### 4. Summarizer (`src/utils/summarizer.py`)
 **Role**: Two-tier session summarization (direct LLM call — no agentic tools).
 - **Trigger**: Runs as part of the queue pipeline alongside representation tasks.
 - **Tiers**: short summary every `SUMMARY_MESSAGES_PER_SHORT_SUMMARY` messages (default 20); long summary every `SUMMARY_MESSAGES_PER_LONG_SUMMARY` (default 60). Token caps configurable via `SUMMARY_MAX_TOKENS_SHORT` / `SUMMARY_MAX_TOKENS_LONG`.
 #### Shared Agent Infrastructure
 - **Tool definitions** (`src/utils/agent_tools.py`): unified `TOOLS` dict; per-agent lists (`DIALECTIC_TOOLS`, `DIALECTIC_TOOLS_MINIMAL`, `DREAMER_TOOLS`, `DEDUCTION_SPECIALIST_TOOLS`, `INDUCTION_SPECIALIST_TOOLS`).
 - **LLM subsystem** (`src/llm/`): provider-agnostic `honcho_llm_call()`. Backends in `src/llm/backends/` (`anthropic.py`, `gemini.py`, `openai.py`). Includes prompt caching (`caching.py`), structured output (`structured_output.py`), tool loop (`tool_loop.py`), history adapters for cross-provider message formats, and a model registry. Per-retry provider selection is pinned via an `AttemptPlan` so stream-final retries don't bounce back to primary after the tool loop has settled on fallback.
 - **Per-agent model config**: each agent has its own `MODEL_CONFIG` in `src/config.py` with fallback chains (see `ConfiguredModelSettings`, `FallbackModelSettings`).
 - **Telemetry**: cloudevents in `src/telemetry/events/` cover API routes, dialectic, dream, deletion, reconciliation, representation, and per-call LLM accounting (`llm.py` — `LLMCallCompletedEvent` fires once per provider hit with full cost-attribution context). High-volume events are sampled deterministically per `run_id` via `TelemetrySettings.HIGH_VOLUME_SAMPLE_RATE`.
 - **Prometheus metrics** (`src/telemetry/prometheus/`): every metric carries a `namespace` label and every recorder is fail-soft (a metrics error never propagates into a request or a worker loop). Counter children with a *bounded* label domain are zero-initialized per process at startup — `initialize_bounded_metrics(instance_type=...)`, called from the `src/main.py` lifespan (`api`) and `src/deriver/__main__.py` (`deriver`) — so an absent series means a broken scrape rather than "nothing happened". Two consequences worth knowing before touching telemetry:
  - **Adding a `BaseEvent` subclass requires adding its `_event_type` to `ALL_EVENT_TYPES`** in `src/telemetry/events/__init__.py` (and to `HIGH_VOLUME_EVENT_TYPES` if `_volume_class == "high_volume"`). Enforced by the drift guards in `tests/telemetry/test_metric_zero_init.py`, which assert set-equality against the discovered subclasses.
  - **A service-wide, non-additive gauge must be refreshed by every replica on its own timer**, and aggregated with `max()`/`avg()`, never `sum()`. `message_embeddings_pending` is the example: it reports a DB-global count, so it is driven from `ReconcilerScheduler._scheduler_loop` (runs on all replicas) rather than from the work-unit-deduped reconciliation cycle — otherwise, combined with the zero-init, every replica that never won the work unit would export a confident permanent `0`.
 ### Project Structure
 ```
 src/
-├── main.py              # FastAPI app: middleware, routers, lifespan, exception handlers
+├── main.py          # FastAPI app setup with middleware and exception handlers
-├── models.py            # SQLAlchemy ORM models (Workspace/Peer/Session/Message/
+├── models.py        # SQLAlchemy ORM models with proper type annotations
-│                        #   MessageEmbedding/Collection/Document/QueueItem/...)
+├── schemas.py       # Pydantic validation schemas for API
-├── config.py            # Pydantic-settings configuration (very large; see README)
+├── crud.py          # Database operations
-├── db.py                # Engine + session/context management (request_context var)
+├── dependencies.py  # Dependency injection (DB sessions)
-├── dependencies.py      # FastAPI DI (tracked_db, etc.)
+├── exceptions.py    # Custom exception types
 ├── exceptions.py        # Custom exception types (HonchoException + subclasses)
 ├── security.py      # JWT authentication
-├── embedding_client.py  # Embedding provider client (configurable dimensions
+├── agent.py         # Dialectic API implementation
-│                        #   via EMBEDDING_MODEL_CONFIG__DIMENSIONS_MODE)
+├── routers/         # API endpoints
-├── schemas/             # Pydantic schemas
+│   ├── workspaces.py
-│   ├── api.py            # Public API request/response schemas
+│   ├── peers.py
-│   ├── configuration.py  # Per-resource configuration schemas
+│   ├── sessions.py
-│   └── internal.py       # Internal-only schemas (queue payloads, etc.)
+│   ├── messages.py
-├── crud/                # Per-resource DB operations
+│   └── keys.py
-│   ├── collection.py, deriver.py, document.py, message.py
+├── deriver/         # Background processing system
-│   ├── peer.py, peer_card.py, representation.py  (RepresentationManager)
+│   ├── consumer.py  # Message processing logic
-│   ├── session.py, webhook.py, workspace.py
+│   ├── queue.py     # Queue management
-├── routers/             # FastAPI route handlers (all under /v3)
+│   └── tom/         # Theory of Mind implementations
-│   ├── workspaces.py, peers.py (dialectic /chat lives here), sessions.py
+└── utils/           # Utilities
-│   ├── messages.py, conclusions.py, keys.py, webhooks.py
+    ├── history.py   # Session history management
-├── dialectic/           # Dialectic agent — runs inline per chat request
+    ├── cache.py     # Caching utilities
-│   ├── chat.py           # agentic_chat() / agentic_chat_stream()
+    └── model_client.py # LLM client abstraction
 │   ├── core.py           # DialecticAgent (the tool-loop driver)
 │   └── prompts.py
 ├── deriver/             # Background queue consumer (separate process)
 │   ├── __main__.py       # `python -m src.deriver` entry point
 │   ├── queue_manager.py  # QueueManager + main() loop
 │   ├── consumer.py       # process_item dispatcher (representation / deletion / reconciler)
 │   ├── deriver.py        # "minimal deriver" — single-LLM-call batch processor
 │   ├── enqueue.py        # API → queue producer
 │   └── prompts.py
 ├── dreamer/             # Memory consolidation (runs off the queue)
 │   ├── orchestrator.py   # run_dream() / process_dream()
 │   ├── specialists.py    # DeductionSpecialist + InductionSpecialist
 │   ├── dream_scheduler.py
 │   ├── surprisal.py      # Surprisal-based conclusion prioritization
 │   └── trees/            # Reasoning-tree primitives
 ├── reconciler/          # In-process scheduler hosted by the deriver worker
 │   ├── scheduler.py      # ReconcilerScheduler (started from queue_manager.py)
 │   ├── sync_vectors.py   # Embeds MessageEmbedding rows with sync_state='pending'
 │   └── queue_cleanup.py  # Removes stale queue items
 ├── llm/                 # Provider-agnostic LLM client subsystem
 │   ├── api.py, backend.py, executor.py, runtime.py, registry.py
 │   ├── caching.py, structured_output.py, tool_loop.py, conversation.py
 │   ├── history_adapters.py, request_builder.py, credentials.py, types.py
 │   └── backends/         # anthropic.py, gemini.py, openai.py
 ├── cache/               # Redis cache abstraction (cashews-backed)
 │   └── client.py
 ├── vector_store/        # Optional external vector stores (pgvector is default,
 │   │                    #   implemented via MessageEmbedding/Document in models+crud)
 │   ├── lancedb.py
 │   └── turbopuffer.py
 ├── telemetry/           # Observability
 │   ├── emitter.py        # CloudEvents emitter
 │   ├── logging.py        # Logging helpers + route-template extraction
 │   ├── metrics_collector.py, reasoning_traces.py, sentry.py
 │   ├── events/           # Event type definitions
 │   └── prometheus/       # Prometheus metric definitions
 ├── utils/               # Cross-cutting utilities
 │   ├── agent_tools.py    # Tool definitions + per-agent tool lists
 │   ├── summarizer.py     # Two-tier session summarizer
 │   ├── representation.py # Representation formatting (distinct from crud/representation.py)
 │   ├── search.py, filter.py, formatting.py
 │   ├── tokens.py         # tiktoken-based counting
 │   ├── work_unit.py, queue_payload.py
 │   ├── config_helpers.py, json_parser.py, files.py
 │   └── types.py
 └── webhooks/            # Webhook delivery
    ├── events.py
    └── webhook_delivery.py
 ```
- Tests in pytest with fixtures in tests/conftest.py; subdirs mirror src/ (`tests/deriver/`, `tests/dialectic/`, etc.) plus `tests/bench/` (perf benchmarks), `tests/integration/`, `tests/live_llm/` (gated by `--live-llm`), and `tests/unified/` (the unified runner).
+- Tests in pytest with fixtures in tests/conftest.py
- Use environment variables via python-dotenv (.env). Config precedence: env > .env > config.toml > defaults.
+- Use environment variables via python-dotenv (.env)
 ### Database Design
@ -292,18 +138,13 @@ src/
 ### Key Architectural Decisions
-1. **Peer Paradigm**: humans and AI agents are unified as "Peers"; many-to-many with Sessions. Internal vector storage (Collections/Documents) is keyed by `(observer, observed)` peer pairs — the same mechanism powers self-representation (`observer == observed`) and cross-peer modeling.
+1. **Multi-Peer Sessions**: Sessions can have multiple participants with different observation settings
-2. **Multi-Peer Sessions**: Sessions can have multiple participants with different observation settings.
+2. **Flexible Theory of Mind**: Pluggable ToM implementations (conversational, single_prompt, long_term)
-3. **API server / worker split**: API enqueues, deriver worker process consumes. Never block HTTP on LLM work. The Reconciler runs as an in-process scheduler inside the deriver, handling async embedding sync and queue cleanup.
+3. **Background Processing**: Async queue system for expensive operations
-4. **"Minimal" deriver**: memory formation is a single structured-output LLM call per batch, not an agentic tool loop. Predictable cost, lower latency. The Dialectic is the one true tool-using agent.
+4. **Provider Abstraction**: Model client supports multiple LLM providers
-5. **Provider-agnostic LLM layer** (`src/llm/`): all model calls go through `honcho_llm_call()`. Backends (`anthropic`, `gemini`, `openai`) sit behind a registry; per-agent `MODEL_CONFIG` with fallback chains is resolved at call time.
+5. **Scoped Authentication**: JWT tokens can be scoped to workspace, peer, or session level
-6. **Dialectic reasoning tiers**: 5 levels (`minimal` → `max`); each level has its own model config and tool set (`minimal` uses a reduced toolset).
+6. **Batch Operations**: Support for bulk message creation (up to 100 messages)
-7. **Hybrid search**: Postgres FTS (GIN index on `to_tsvector('english', content)`) + vector similarity (HNSW on `MessageEmbedding.embedding`). `MessageEmbedding` is a separate table from `Message` with its own `sync_state` so embedding is decoupled from message creation.
+7. **Session History**: Two-tier summarization (short every 20 messages, long every 60)
 8. **Pluggable external vector stores**: defaults to pgvector inline; can swap to turbopuffer or lancedb (`VECTOR_STORE_*` config; `src/vector_store/`).
 9. **Composite-FK multi-tenancy**: `workspace_name` participates in nearly every composite FK. Cross-workspace data leakage is structurally impossible at the schema level.
 10. **Scoped Authentication**: JWTs can be scoped to workspace, peer, or session level.
 11. **Batch Operations**: Bulk message creation up to 100 messages per request.
 12. **Session History**: Two-tier summarization — short every `SUMMARY_MESSAGES_PER_SHORT_SUMMARY` (default 20), long every `SUMMARY_MESSAGES_PER_LONG_SUMMARY` (default 60).
 ### Error Handling
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@ -1,414 +1,173 @@
 # Contributing to Honcho
-<!-- This file is mirrored at docs/v3/contributing/guidelines.mdx. Update both. -->
+Thank you for your interest in contributing to Honcho! This guide outlines the process for contributing to the project and our development conventions.
-Thanks for your interest in contributing. This guide covers how work gets accepted, how
+## Getting Started
 Honcho is put together, and what a mergeable pull request looks like.
-Honcho is a small team maintaining a project that gets more proposals than we can review.
+Before you start contributing, please:
 The rules below exist so that the work you do has somewhere to land — not to keep you out.
-## Contents
+1. **Set up your development environment** - Follow the [Local Development guide](./README.md#local-development) in the README to get Honcho running locally.
- [Before you write code](#before-you-write-code)
+2. **Join our community** - Feel free to join us in our [Discord](http://discord.gg/plasticlabs) to discuss your changes, get help, or ask questions.
 - [What gets prioritized](#what-gets-prioritized)
 - [If you're an agent](#if-youre-an-agent)
 - [How Honcho works](#how-honcho-works)
 - [Where to change what](#where-to-change-what)
 - [Local setup](#local-setup)
 - [Making the change](#making-the-change)
 - [Opening the pull request](#opening-the-pull-request)
 - [Reporting bugs and requesting features](#reporting-bugs-and-requesting-features)
 - [Security](#security)
 - [License](#license)
-## Before you write code
+3. **Review existing issues** - Check the [issues tab](https://github.com/plastic-labs/honcho/issues) to see what's already being worked on or to find something to contribute to.
-**Every pull request needs an issue, and that issue needs the `maintainer-approved` label.**
+## Contribution Workflow
-A pull request that is not linked to an approved issue gets labelled
+### 1. Fork and Clone
 `needs-approved-issue`, with a comment explaining why. You then have 72 hours to link one
 before it is closed automatically. Reopening costs nothing once the link is in place. This
 is automated. We do this because an unreviewable backlog helps nobody: a PR against an
 unapproved issue is work you did that we may not be able to merge, no matter how good it
 is.
 So, in order:
 1. **Find approved work.** Browse
   [issues labelled `maintainer-approved`](https://github.com/plastic-labs/honcho/issues?q=is%3Aissue+is%3Aopen+label%3Amaintainer-approved).
   That label is the queue of things we have agreed should be built. Anything in it is fair
   game — comment on the issue to claim it.
 2. **Or open an issue and get it approved.** Use the
   [issue templates](https://github.com/plastic-labs/honcho/issues/new/choose). Maintainers
   triage and apply the label.
 3. **If you feel strongly about an issue, come to [Discord](https://discord.gg/honcho).**
   This is the fastest path by a wide margin. Maintainers are more active there than in the
   issue tracker, and a five-minute conversation about what you want to build usually
   resolves whether it fits before either side spends real time on it.
 4. **Then open the PR** and link the issue — either `Fixes #123` in the description, or
   **Development → link an issue** in the sidebar. Both work.
 Small exceptions we will not be pedantic about: fixing a typo, a broken link, or an
 obviously wrong code sample. Open the PR, explain it in one line, and we will sort out the
 issue linkage.
 ## What gets prioritized
 Roughly, work on Honcho falls along these axes. Knowing which one your idea sits on tells
 you a lot about how likely it is to get approved.
 | Axis | What it covers |
 | --- | --- |
 | **Observability** | Understanding how Honcho behaves in production — telemetry, tracing, CloudEvents, metrics. |
 | **Memory quality** | Better conclusions from the same input — the deriver, dreamer, and dialectic; eval results. |
 | **Developer experience** | Fitting cleanly into more application architectures — SDKs, scopes, composable peers, the CLI. |
 | **Breadth of input** | Widening what Honcho can ingest and represent — multimodal and non-conversational data. |
 | **Ubiquity** | Reachable wherever a developer already works — integrations, self-hosting, alternate vector-store and inference backends, local-first defaults. |
 | **Reliability and cost** | Trustworthy in production — connection and concurrency hardening, queue throughput, cost per token. |
 In practice, **Ubiquity** and **Developer experience** are where outside contributions land
 most easily. A new integration, a self-hosting rough edge, a vector-store or inference
 backend, an SDK ergonomics fix — these are additive and rarely collide with work already in
 flight.
 Changes to the reasoning pipeline itself — deriver prompts, dialectic tool design, dreamer
 strategy — are the hardest to accept from outside. Not because they are unwelcome, but
 because they are measured against eval results we run internally, and they frequently
 conflict with in-flight work. Talk to us in Discord first, always.
 ## If you're an agent
 If you are a coding agent working on this repository, read this section before writing code.
 The most common failure we see is a well-formed, well-tested pull request against an issue
 that was never approved. That gets closed, and the work is wasted.
 - **Check the gate first.** Before writing code:
 1. Fork the repository on GitHub
 2. Clone your fork locally:
   ```bash
-  gh issue view <N> --repo plastic-labs/honcho --json number,title,state,labels
+   git clone https://github.com/YOUR_USERNAME/honcho.git
   cd honcho
   ```
 3. Add the upstream repository as a remote:
   ```bash
   git remote add upstream https://github.com/plastic-labs/honcho.git
   ```
-  Stop if there is no issue number, if the issue is closed, or if `maintainer-approved` is
+### 2. Create a Branch
  not in the labels. Report that to the person you are working with instead of proceeding.
- **Do not open a PR in order to establish the issue link afterwards.** The issue comes
+Create a new branch for your feature or bug fix:
  first.
 - **Do not report checks you did not run.** If you did not execute the test command, say so.
  A PR body claiming a green run that did not happen costs a maintainer more time than no
  claim at all.
 - **Use the checklist.** [`skills/pre-pr/SKILL.md`](./skills/pre-pr/SKILL.md) in this repo
  encodes the gate, the test-layer matrix, and the PR body format. If your harness supports
  skills, invoke it rather than reimplementing the checks.
 ## How Honcho works
 Enough architecture to find your way around. For the user-facing model — what a Peer is, what
 `get_context` returns — see [Core Concepts in the README](./README.md#core-concepts) and the
 [documentation](https://honcho.dev/docs/).
 ### Two processes
 Honcho runs as two cooperating processes over a shared Postgres database and Redis cache.
 | | API server | Deriver worker |
 | --- | --- | --- |
 | Start | `uv run fastapi dev src/main.py` | `uv run python -m src.deriver` |
 | Entry | `src/main.py` | `src/deriver/__main__.py` |
 | Does | Serves HTTP, enqueues background work, returns immediately | Consumes the queue: Deriver, Summarizer, Dreamer, Reconciler |
 | Hosts | The Dialectic agent, inline on the request path | Everything else |
 The split is the load-bearing design decision: **an HTTP request never blocks on LLM work**,
 with the single exception of the Dialectic chat endpoint, which is synchronous by nature.
 If you are adding something slow, it belongs in the worker.
 The deriver is a separate process. If messages go in and nothing ever comes out, the usual
 cause is that nobody started it.
 ### The path of a message
 Worth tracing once, because it crosses most of the codebase:
 1. `POST /v3/workspaces/{w}/sessions/{s}/messages` lands in `src/routers/messages.py`.
 2. The row is written, then `enqueue()` in `src/deriver/enqueue.py` creates `queue_item`
   rows — one set of work per observing peer.
 3. `src/deriver/queue_manager.py` polls the queue, claiming work units so that messages in a
   session are processed in order.
 4. `process_item()` in `src/deriver/consumer.py` dispatches on task type — representation,
   summary, deletion, reconciliation.
 5. For a representation task, `process_representation_tasks_batch()` in
   `src/deriver/deriver.py` makes **one structured-output LLM call for the whole batch** and
   writes the resulting conclusions into the collection keyed by the
   `(observer, observed)` peer pair.
 6. Later, `src/dialectic/` reads those conclusions back at recall time to answer a chat
   request.
 Embedding is deliberately *not* on this path. `MessageEmbedding` rows are written with
 `sync_state='pending'` and embedded asynchronously by the Reconciler
 (`src/reconciler/sync_vectors.py`), which runs on a scheduler inside the deriver process.
 ### The four agents
 They share tool definitions in `src/utils/agent_tools.py` and the provider-agnostic LLM
 client in `src/llm/`. Each has its own `MODEL_CONFIG` with a fallback chain in
 `src/config.py`.
 | Agent | Where | Shape |
 | --- | --- | --- |
 | **Deriver** | `src/deriver/` | A single structured-output call per message batch. Not a tool loop — this is a deliberate cost and latency tradeoff. |
 | **Dialectic** | `src/dialectic/` | The one tool-using agent on the request path. Loops over tools until it can answer. Five reasoning tiers from `minimal` to `max`, each with its own model and tool set. |
 | **Dreamer** | `src/dreamer/` | Off-queue consolidation. Two specialist phases (deduction, then induction) that build reasoning trees over existing conclusions. |
 | **Summarizer** | `src/utils/summarizer.py` | Direct LLM call, no tools. Two tiers — short and long summaries at different message counts. |
 Prompts live in `src/deriver/prompts.py`, `src/dialectic/prompts.py`, and
 `src/dreamer/specialists.py`.
 ### A note on naming
 What the public API and documentation call **conclusions** are called **observations**
 throughout the code — `create_observations`, `get_observation_context`, and so on. Likewise
 **collections** and **documents** are internal storage concepts that are not exposed
 directly through the API. Do not rename across that boundary in a drive-by change; the
 public and internal vocabularies are being reconciled deliberately.
 ## Where to change what
 | I want to change... | Start here |
 | --- | --- |
 | An HTTP endpoint | `src/routers/` — one module per resource |
 | A database query | `src/crud/` — mirrors the router layout |
 | The database schema | `src/models.py`, plus a migration in `migrations/versions/` |
 | A configuration value | `src/config.py`, and add it to `config.toml.example` and `.env.template` |
 | A tool an agent can call | `src/utils/agent_tools.py` — definitions plus the per-agent tool lists |
 | A prompt | `src/deriver/prompts.py`, `src/dialectic/prompts.py`, `src/dreamer/specialists.py` |
 | LLM provider behavior | `src/llm/backends/` — `anthropic.py`, `gemini.py`, `openai.py` |
 | Embeddings or vector storage | `src/embedding_client.py`, `src/vector_store/` |
 | Telemetry or metrics | `src/telemetry/` — see the notes in `CLAUDE.md` before adding an event type |
 | Authentication and scoping | `src/security.py`, `src/dependencies.py` |
 | The Python or TypeScript SDK | `sdks/python/`, `sdks/typescript/` |
 | The CLI | `honcho-cli/` |
 | The MCP server | `mcp/` |
 | Public documentation | `docs/v3/` — Mintlify; nav lives in `docs/docs.json` |
 Tests in `tests/` mirror `src/`. `CLAUDE.md` at the repo root has more detail on house
 conventions, and is worth skimming even if you are not using an agent.
 ## Local setup
 To run a personal instance, install the CLI (`uv tool install honcho-cli`) and then run `honcho start --setup` (Docker + an LLM provider key — not the Honcho API key from `honcho init`) — [CLI in the README](./README.md#cli).
 To **develop this repo**, clone it and:
 ```bash
 uv sync                          # create the venv and install dependencies
 uv run alembic upgrade head      # apply migrations
 ```
 Run both processes, in separate terminals:
 ```bash
 uv run fastapi dev src/main.py   # API server, reloads on change
 uv run python -m src.deriver     # background worker
 ```
 Everything Python goes through `uv run`. Redis is optional for local development; without it
 caching is simply disabled.
 ### Running without a model provider
 `src/mock_provider/` is a deterministic, OpenAI-compatible endpoint, so you can run the full
 stack with no provider account, no API key, and no spend. It answers `/v1/chat/completions`
 and `/v1/embeddings` with obviously-synthetic content derived from the request, and the same
 request always produces the same response. Run it from the standard image or the repo:
 ```bash
 uv run fastapi run --host 0.0.0.0 --port 8106 src/mock_provider/main.py
 ```
 Then point Honcho at it. All three variables are required:
 ```bash
 export LLM_OPENAI_API_KEY=any-non-empty-string   # only truthiness is checked
 export LLM_OPENAI_BASE_URL=http://localhost:8106/v1
 export EMBEDDING_MODEL_CONFIG__OVERRIDES__BASE_URL=http://localhost:8106/v1
 ```
 The key's *value* is never checked — the mock reads no Authorization header, and Honcho only
 tests it for truthiness before building the client (`src/llm/registry.py`). Set the base URL
 without it and the client is never constructed, so the base URL is silently ignored. Keep the
 value obviously fake, so a module that ever escapes the override 401s rather than spends.
 Embeddings resolve through a separate client that reads the base URL only from the per-module
 override, so without the third variable your embedding calls go to `api.openai.com` for real.
 Do not set any per-module credential override (`..._OVERRIDES__API_KEY` / `API_KEY_ENV`) —
 that makes the module ignore the global base URL.
 Two things to know:
 - **A repo `.env` beats your exported environment.** `src/config.py` calls
  `load_dotenv(override=True)` at import, so a stale `.env` silently wins over the variables
  above. Set `PYTHON_DOTENV_DISABLED=1` (and `HONCHO_CONFIG_TOML_DISABLED=1` for a local
  `config.toml`) when you need the environment to be the only input.
 - **Mock embeddings are hash-derived and carry no semantic similarity.** Two paraphrases are as
  far apart as two unrelated strings. Recall against this provider must use lexical/full-text
  search; anything asserting on vector ranking needs a real embedding provider.
 ## Making the change
 ### Branches and commits
 ```bash
 git checkout -b feature/your-feature-name
 # or
 git checkout -b fix/your-bug-fix-name
 ```
-Prefixes: `feature/`, `fix/`, `docs/`, `refactor/`, `test/`.
+**Branch naming conventions:**
-Commits follow [Conventional Commits](https://www.conventionalcommits.org/), enforced by a
+- `feature/description` - for new features
-`commit-msg` hook:
+- `fix/description` - for bug fixes
 - `docs/description` - for documentation updates
 - `refactor/description` - for code refactoring
 - `test/description` - for adding or updating tests
 ### 3. Make Your Changes
 - Write clean, readable code that follows our coding standards (see below)
 - Add tests for new functionality
 - Update documentation as needed
 - Make sure your changes don't break existing functionality
 ### 4. Commit Your Changes
 We follow conventional commit standards. Format your commit messages as:
 ```
 type(scope): description
 [optional body]
 [optional footer]
 ```
 **Types:**
 - `feat`: A new feature
 - `fix`: A bug fix
 - `docs`: Documentation only changes
 - `style`: Changes that do not affect the meaning of the code
 - `refactor`: A code change that neither fixes a bug nor adds a feature
 - `test`: Adding missing tests or correcting existing tests
 - `chore`: Changes to the build process or auxiliary tools
 **Examples:**
 ```bash
 git commit -m "feat(api): add new dialectic endpoint for user insights"
 git commit -m "fix(db): resolve connection pool timeout issue"
 git commit -m "docs(readme): update installation instructions"
 ```
-Types: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`.
+### 5. Submit a Pull Request
-### Pre-commit hooks
+1. Push your branch to your fork:
-Install them. CI runs the same checks, and it is much faster to find out locally.
+   ```bash
   git push origin your-branch-name
   ```
-```bash
+2. Create a pull request on GitHub from your branch to the `main` branch
 uv run pre-commit install \
    --hook-type pre-commit \
    --hook-type commit-msg \
    --hook-type pre-push
 ```
-At **commit** time: ruff lint and format, biome for TypeScript, basedpyright, bandit,
+3. Fill out the pull request template with:
-markdownlint, and file hygiene. At **push** time: pytest, the alembic migration tests, and
+   - A clear description of what changes you've made
-the SDK builds.
+   - The motivation for the changes
   - Any relevant issue numbers (use "Closes #123" to auto-close issues)
   - Screenshots or examples if applicable
-That split matters — **a clean commit is not a clean push.** The test suite only runs at
+## Coding Standards
 `pre-push`, so the first time you see test failures may be well after you thought you were
 done.
-Run them by hand at any time:
+### Python Code Style
-```bash
+- Follow [PEP 8](https://www.python.org/dev/peps/pep-0008/) style guidelines
-uv run pre-commit run --all-files
+- Use [Black](https://black.readthedocs.io/) for code formatting (we may add this to CI in the future)
-uv run pre-commit run ruff --all-files
+- Use type hints where possible
-```
+- Write docstrings for functions and classes using Google style docstrings
-Or the individual tools:
+### Code Organization
-```bash
+- Keep functions focused and single-purpose
-uv run ruff check src/
+- Use meaningful variable and function names
-uv run ruff format src/
+- Add comments for complex logic
-uv run basedpyright
+- Follow existing patterns in the codebase
 ```
-### Tests
+### Testing
-Write tests for new functionality, in the directory under `tests/` that mirrors the code you
+- Write unit tests for new functionality
-changed. Which layer you need depends on what you touched:
+- Ensure existing tests pass before submitting
-
+- Use descriptive test names that explain what is being tested
-| What you changed | What to run |
+- Mock external dependencies appropriately
 | --- | --- |
 | Anything in `src/` | Unit tests in the matching `tests/` tree — `uv run pytest tests/...` |
 | Deriver, dialectic, dreamer, or the LLM path | Unit tests, and consider `tests/live_llm/` (gated behind `--live-llm`) |
 | Queue behavior, config hierarchy, multi-turn flows, SDK contracts | `uv run python -m tests.unified.run` |
 | A `/v3` endpoint or deriver queue behavior | Actually run the stack and exercise it — not just pytest |
 | A migration | `uv run python scripts/run_alembic_tests.py`; every revision needs a test file |
 The TypeScript SDK tests need a running server with a database and Redis, which pytest
 orchestrates. Run them with `uv run pytest tests/ -k typescript` from the repo root —
 `bun test` on its own will fail. To type-check the SDK alone:
 `cd sdks/typescript && bun run tsc --noEmit`.
 ### Documentation
-Update docs in the same PR when you change a public surface: `/v3` endpoints, SDK exports,
+- Update relevant documentation for new features
-or anything in `config.toml` / settings. Docs live in `docs/v3/`, and new pages need an entry
+- Include examples in docstrings where helpful
-in `docs/docs.json` or they will not appear in the nav.
+- Keep README and other docs up to date with changes
-## Opening the pull request
+## Review Process
-### Leave "Allow edits by maintainers" checked
+1. **Automated checks** - Your PR will run through automated checks including tests and linting
 2. **Project maintainer review** - A project maintainer will review your code for:
   - Code quality and adherence to standards
   - Functionality and correctness
   - Test coverage
   - Documentation completeness
 3. **Discussion and iteration** - You may be asked to make changes or clarifications
 4. **Approval and merge** - Once approved, your PR will be merged into `main`
-This is the single most useful thing you can do to get your PR merged quickly.
+## Types of Contributions
-Most contributor PRs arrive nearly right, needing a rename, a missing test, or a lint fix.
+We welcome various types of contributions:
 If we can push that commit ourselves, it merges the same day. If we cannot, it becomes a
 review comment, and then we wait — sometimes for weeks — for a round trip on a two-line
 change.
-GitHub checks the box by default when you fork. Leave it checked.
+- **Bug fixes** - Help us squash bugs and improve stability
 - **New features** - Add functionality that benefits the community
 - **Documentation** - Improve or expand our documentation
 - **Tests** - Increase test coverage and reliability
 - **Performance improvements** - Help make Honcho faster and more efficient
 - **Examples and tutorials** - Help other developers use Honcho
-One caveat worth knowing: **the option does not exist on forks owned by an organization.**
+## Issue Reporting
 If you have the choice, fork from your personal account.
-### Fill out the template
+When reporting bugs or requesting features:
-`.github/pull_request_template.md` asks for a description, proofs, and the issue checkbox.
+1. Check if the issue already exists
 2. Use the appropriate issue template
 3. Provide clear reproduction steps for bugs
 4. Include relevant environment information
 5. Be specific about expected vs actual behavior
-"Proofs" means evidence the change works: the command you ran and its result, a log snippet,
+## Questions and Support
 a screenshot, the failing case before and after. This is the section that most determines
 how fast your PR gets reviewed. Do not add sections to the template.
-Link the issue so the gate can see it: `Fixes #123` in the description, or the
+- **General questions** - Join our [Discord](http://discord.gg/plasticlabs)
-**Development** section of the sidebar. The gate reads GitHub's own resolved issue links, so
+- **Bug reports** - Use GitHub issues
-either route works — but a bare `#123` mention is only a reference and does not count.
+- **Feature requests** - Use GitHub issues with the feature request template
-
+- **Security issues** - Please email us privately rather than opening a public issue
 ### Review
 1. Automated checks run — tests, linting, static analysis, and the issue gate.
 2. A maintainer reviews for correctness, test coverage, and fit with the surrounding code.
   `.github/CODEOWNERS` routes the request to whoever owns the area you touched.
 3. You may be asked for changes. Or we may just push them, if you left edits enabled.
 4. Once approved, we merge to `main`.
 If a PR goes quiet, nudge us in [Discord](https://discord.gg/honcho).
 Please respond within 7 days - we may close any PRs that have seen no activity within a 7 day
 window. If you need more time, let us know in the PR comments.
 ## Reporting bugs and requesting features
 Use the [issue templates](https://github.com/plastic-labs/honcho/issues/new/choose). There is
 one per kind of report, and picking the right one is most of what gets an issue triaged
 quickly:
 - **Bug report** — something is broken or behaves incorrectly
 - **Memory / recall quality** — the deriver or dialectic returns poor, wrong, or missing context
 - **Feature request** — a new capability or API surface
 - **Integration request** — plugins, framework integrations, app-store listings
 - **Documentation issue** — anything wrong or missing in the docs
 - **General questions** — not an issue at all; ask in [Discord](https://discord.gg/honcho)
 Before opening one, search existing issues, including closed ones.
 A good bug report has the Honcho version or commit, whether you are self-hosted or on
 `api.honcho.dev`, the steps to reproduce, and what you expected instead. If it involves the
 deriver, logs from the worker process are usually the thing we ask for first.
 **Redact before you post.** Issues are public, and Honcho stores conversational data — strip
 API keys, JWTs, and production user content out of any log or payload you attach.
 ## Security
 Do not open a public issue for a suspected vulnerability. Report it privately through
 [GitHub Private Vulnerability Reporting](https://github.com/plastic-labs/honcho/security/advisories/new),
 which is the preferred channel, or by email. See [SECURITY.md](./SECURITY.md) for what to
 include, and note that Honcho does not operate a bug bounty.
 ## License
-By contributing to Honcho, you agree that your contributions will be licensed under the same
+By contributing to Honcho, you agree that your contributions will be licensed under the same [AGPL-3.0 License](./LICENSE) that covers the project.
 [AGPL-3.0 License](./LICENSE) that covers the project.
 Thank you for helping make Honcho better! 🫡
--- a/62
+++ b/62
@ -1,77 +1,47 @@
 # syntax=docker/dockerfile:1
 # https://pythonspeed.com/articles/base-image-python-docker-images/
 # https://testdriven.io/blog/docker-best-practices/
-FROM python:3.13-slim-bookworm AS builder
+FROM python:3.11-slim-bullseye
-COPY --from=ghcr.io/astral-sh/uv:0.9.24 /uv /bin/uv
+COPY --from=ghcr.io/astral-sh/uv:0.4.9 /uv /bin/uv
 # Set Working directory
 WORKDIR /app
 RUN addgroup --system app && adduser --system --group app
 RUN chown -R app:app /app
 USER app
 # Enable bytecode compilation
 ENV UV_COMPILE_BYTECODE=1
 # Copy from the cache instead of linking since it's a mounted volume
 ENV UV_LINK_MODE=copy
-# Python optimizations
+# Install the project's dependencies using the lockfile and settings
-ENV PYTHONDONTWRITEBYTECODE=1
+RUN --mount=type=cache,target=/root/.cache/uv \
-ENV PYTHONUNBUFFERED=1
+    --mount=type=bind,source=uv.lock,target=uv.lock \
    --mount=type=bind,source=pyproject.toml,target=pyproject.toml \
    uv sync --frozen --no-install-project --no-dev
 # Copy only requirements to cache them in docker layer
 COPY uv.lock pyproject.toml /app/
-# Optionall include lancedb with:
+# Sync the project
 #   docker build --build-arg INSTALL_LANCEDB=true .
 ARG INSTALL_LANCEDB=false
 RUN --mount=type=cache,target=/root/.cache/uv \
-    if [ "$INSTALL_LANCEDB" = "true" ]; then \
+    uv sync --frozen --no-dev
        uv sync --frozen --no-install-project --no-group dev --extra lancedb; \
    elif [ "$INSTALL_LANCEDB" = "false" ]; then \
        uv sync --frozen --no-install-project --no-group dev; \
    else \
        echo "INSTALL_LANCEDB must be 'true' or 'false'" >&2; \
        exit 2; \
    fi
 FROM python:3.13-slim-bookworm AS runtime
 WORKDIR /app
 ENV PYTHONDONTWRITEBYTECODE=1
 ENV PYTHONUNBUFFERED=1
 # Create the runtime user before copying dependencies with their final owner.
 # A recursive chown in a later layer would copy the whole virtualenv and nearly
 # double the image size.
 RUN addgroup --system app \
    && adduser --system --group app \
    && chown app:app /app \
    # Pre-create the LanceDB dir so a named volume mounted here inherits app
    # ownership instead of defaulting to root.
    && mkdir /app/lancedb_data \
    && chown app:app /app/lancedb_data
 COPY --from=builder --chown=app:app /app/.venv /app/.venv
 # Place executables in the environment at the front of the path
 ENV PATH="/app/.venv/bin:$PATH"
 ENV HOME=/app
 COPY --chown=app:app src/ /app/src/
 COPY --chown=app:app migrations/ /app/migrations/
 COPY --chown=app:app scripts/ /app/scripts/
 COPY --chown=app:app docker/ /app/docker/
 COPY --chown=app:app alembic.ini /app/alembic.ini
 # src/_version.py reads the service version from here at runtime, so this
 # is a runtime input as well as a build input.
 COPY --chown=app:app pyproject.toml /app/pyproject.toml
 # Copy config files - this will copy config.toml if it exists, and config.toml.example
 COPY --chown=app:app config.toml* /app/
 # Switch to non-root user
 USER app
 EXPOSE 8000
 # https://stackoverflow.com/questions/29663459/python-app-does-not-print-anything-when-running-detached-in-docker
 CMD ["fastapi", "run", "--host", "0.0.0.0", "src/main.py"]
--- a/README.md
+++ b/README.md
@ -1,375 +1,101 @@
-<!-- markdownlint-disable MD033 -->
+# 🫡 Honcho
 <div align="center">
  <a href="https://app.honcho.dev" target="_blank">
    <img src="assets/honcho.svg" alt="Honcho" width="400">
  </a>
 </div>
 <!-- markdownlint-enable MD033 -->
---
+![Static Badge](https://img.shields.io/badge/Version-2.0.4-blue)
-
+[![Discord](https://img.shields.io/discord/1016845111637839922?style=flat&logo=discord&logoColor=23ffffff&label=Plastic%20Labs&labelColor=235865F2)](https://discord.gg/plasticlabs)
-![Static Badge](https://img.shields.io/badge/Server-3.1.1-blue)
+[![arXiv](https://img.shields.io/badge/arXiv-2310.06983-b31b1b.svg)](https://arxiv.org/abs/2310.06983)
 ![GitHub License](https://img.shields.io/github/license/plastic-labs/honcho)
 ![GitHub Repo stars](https://img.shields.io/github/stars/plastic-labs/honcho)
 [![X (formerly Twitter) URL](https://img.shields.io/twitter/url?url=https%3A%2F%2Ftwitter.com%2Fplastic_labs)](https://twitter.com/plastic_labs)
 [![PyPI version](https://img.shields.io/pypi/v/honcho-ai.svg)](https://pypi.org/project/honcho-ai/)
 [![NPM version](https://img.shields.io/npm/v/@honcho-ai/sdk.svg)](https://npmjs.org/package/@honcho-ai/sdk)
 [![CLI](https://img.shields.io/pypi/v/honcho-cli.svg?label=honcho-cli)](https://pypi.org/project/honcho-cli/)
 [![Discord](https://img.shields.io/discord/1016845111637839922?style=flat&logo=discord&logoColor=23ffffff&label=Plastic%20Labs&labelColor=235865F2)](https://discord.gg/honcho)
-**Honcho is memory infrastructure for building stateful agents that understand changing people, agents, groups, projects, and ideas over time.**
+Honcho is an infrastructure layer for building AI agents with social cognition and theory-of-mind capabilities. It enables developers to create AI agents and LLM-powered applications that are personalized to their end users by leveraging the inherent theory-of-mind capabilities of LLMs to build coherent models of user psychology over time.
-Store messages and events, let Honcho reason in the background, then query peer representations, session context, search results, or natural-language insights from any model or framework. Use it managed at [api.honcho.dev](https://api.honcho.dev), run a local stack with [`honcho start`](#cli), or self-host the FastAPI server yourself.
+Read about the project [here](https://blog.plasticlabs.ai/blog/A-Simple-Honcho-Primer).
-Using Honcho as your memory system will earn your agents higher retention, more trust, and help you build data moats to out-compete incumbents.
+Read the user documentation [here](https://docs.honcho.dev)
-> Honcho has defined the Pareto Frontier of Agent Memory. Watch the [video](https://x.com/honchodotdev/status/2002090546521911703?s=20), check out our [evals page](https://honcho.dev/evals/), and read the [blog post](https://blog.plasticlabs.ai/research/Benchmarking-Honcho) for more detail.
+## Table of Contents
-## Contents
+- [Project Structure](#project-structure)
-
+- [Usage](#usage)
- [Start Here](#start-here)
+- [Local Development](#local-development)
- [Why Honcho](#why-honcho)
+  - [Prerequisites and Dependencies](#prerequisites-and-dependencies)
- [The Honcho Loop](#the-honcho-loop)
+  - [Setup](#setup)
- [Quickstart](#quickstart)
+  - [Docker](#docker)
- [What Honcho Gives You](#what-honcho-gives-you)
+  - [Deploy on Fly](#deploy-on-fly)
 - [Integrations](#integrations)
 - [CLI](#cli)
 - [Core Concepts](#core-concepts)
 - [Benchmarks & Evals](#benchmarks--evals)
 - [Self-hosting](#self-hosting)
 - [Configuration](#configuration)
  - [Using config.toml](#using-configtoml)
  - [Using Environment Variables](#using-environment-variables)
  - [Configuration Priority](#configuration-priority)
  - [Example](#example)
 - [Architecture](#architecture)
- [SDKs](#sdks)
+  - [Storage](#storage)
- [Learn More](#learn-more)
+  - [Insights](#insights)
 - [Contributing](#contributing)
 - [License](#license)
-The Honcho project is split between several repositories, with this one hosting the core service logic — implemented as a FastAPI server. Client SDKs for Python and TypeScript live in the [`sdks/`](./sdks) directory. The [`honcho-cli`](./honcho-cli) package lives here too.
+## Project Structure
-## Start Here
+The Honcho project is split between several repositories with this one hosting
 the core service logic. This is implemented as a FastAPI server/API to store
 data about an application's state.
-| I want to...                           | Path                                                       | Get started                   |
+There are also client sdks in implemented in the `sdks/` directory with support
-| -------------------------------------- | ---------------------------------------------------------- | ----------------------------- |
+for Python and TypeScript. These SDKs wrap core SDKs that are generated using
-| Give my coding agent persistent memory | Claude Code, OpenCode, OpenClaw, Hermes, or any MCP client | [Integrations](#integrations) |
+[Stainless](https://www.stainlessapi.com/).
 | Add memory to my product               | Python or TypeScript SDK                                   | [Quickstart](#quickstart)     |
 | Run Honcho locally                     | Install CLI, then `honcho start --setup`                   | [CLI](#cli)                   |
 | Inspect a deployment                   | `honcho workspace inspect`, `honcho doctor`                | [CLI](#cli)                   |
 | Self-host from source                  | Docker Compose or local development                        | [Self-hosting](#self-hosting) |
-## Why Honcho
+- [Python](https://pypi.org/project/honcho-ai/)
 - [TypeScript](https://www.npmjs.com/package/@honcho-ai/sdk)
-| Capability              | What it means                                                                        |
+We recommend using the official client SDKs instead of the core ones for better
-| ----------------------- | ------------------------------------------------------------------------------------ |
+developer experience, however for any custom use cases you can still access the
-| Reasoning-first memory  | Extracts conclusions from conversations and events, not just matching chunks.        |
+core SDKs in their own repos:
 | Peer-centric model      | Tracks users, agents, groups, projects, and ideas as entities that change over time. |
 | Multi-peer perspective  | Models what one peer knows about another when configured.                            |
 | Managed or self-hosted  | Use `api.honcho.dev`, `honcho start` locally, or run the FastAPI server yourself.    |
 | Agent-tool integrations | MCP, Claude Code, OpenCode, OpenClaw, Hermes, Cursor-compatible clients.             |
-## The Honcho Loop
+[Honcho Core Python](https://github.com/plastic-labs/honcho-python-core)
 [Honcho Core TypeScript](https://github.com/plastic-labs/honcho-node-core)
-1. **Store** conversations, events, documents, or tool traces as messages on a session.
+Examples on how to use the SDK are located within each SDK folder and in the
-2. **Reason** — Honcho processes the queue in the background and updates peer representations.
+[SDK Reference](https://docs.honcho.dev/v2/documentation/tutorial/SDK)
 3. **Query** — ask Honcho for context, search results, peer representations, or a natural-language answer.
 4. **Inject** — drop the result into any LLM call or agent framework.
-Concretely: workspaces hold peers, peers participate in sessions, messages live on sessions, and Honcho builds a per-peer representation that you query through the [Chat Endpoint](https://honcho.dev/docs/v3/documentation/features/chat) or directly.
+There are also documented examples of how to use the core SDKs in the
 [API Reference](https://docs.honcho.dev/api-reference/introduction) section of
 the documentation.
-## Quickstart
+## Usage
-Get an API key at [app.honcho.dev](https://app.honcho.dev) — when you sign up you'll be prompted to join an organization, which gets its own dedicated Honcho instance and $100 free credits. Or install the CLI and run [`honcho start --setup`](#cli), then point the SDK at `http://localhost:8000`.
+When you first install the SDKs they will be ready to go, pointing at
 [https://demo.honcho.dev](https://demo.honcho.dev) which is a demo server of Honcho. This server has no
 authentication, no SLA, and should only be used for testing and getting familiar
 with Honcho.
-### Python
+For a production ready version of Honcho sign up for an account at
 [https://app.honcho.dev](https://app.honcho.dev) and get started. When you sign up you'll be prompted to
 join an organization which will have a dedicated instance of Honcho.
-```bash
+Provision API keys and change your base url to point to
-pip install honcho-ai
+[https://api.honcho.dev](https://api.honcho.dev)
 # or: uv add honcho-ai
 # or: poetry add honcho-ai
 ```
-```python
+Additionally, Honcho can be self-hosted for testing and evaluation purposes. See
-import os
+the [Local Development](#local-development) section below for details on how to set up a local
-from honcho import Honcho
+version of Honcho.
-# Managed service uses api.honcho.dev by default. For self-hosted, pass
+## Local Development
 # base_url="http://localhost:8000" or set HONCHO_URL.
 honcho = Honcho(
    workspace_id="my-app-testing",
    api_key=os.environ["HONCHO_API_KEY"],
 )
-# 1. Store: peers and messages on a session
+Below is a guide on setting up a local environment for running the Honcho
-alice = honcho.peer("alice")
+Server.
 tutor = honcho.peer("tutor")
 session = honcho.session("session-1")
 session.add_messages([
    alice.message("Hey there — can you help me with my math homework?"),
    tutor.message("Absolutely. Send me your first problem!"),
 ])
-# 2. Reason: happens asynchronously in the background.
+> This guide was made using a M3 Macbook Pro. For any compatibility issues
 > on different platforms, please raise an Issue.
-# 3. Query: ask Honcho what it knows, or pull prompt-ready context.
+### Prerequisites and Dependencies
 answer = alice.chat("What learning styles does the user respond to best?")
 context = session.context(summary=True, tokens=10_000)
 # 4. Inject: hand the context to your model of choice.
 from openai import OpenAI
 client = OpenAI()
 completion = client.chat.completions.create(
    model=os.environ.get("OPENAI_MODEL", "gpt-4o-mini"),
    messages=context.to_openai(assistant=tutor),
 )
 ```
 ### TypeScript
 ```bash
 npm install @honcho-ai/sdk
 # or: bun add @honcho-ai/sdk
 ```
 ```typescript
 import { Honcho } from "@honcho-ai/sdk";
 import OpenAI from "openai";
 const honcho = new Honcho({
  workspaceId: "my-app-testing",
  apiKey: process.env.HONCHO_API_KEY,
 });
 const alice = await honcho.peer("alice");
 const tutor = await honcho.peer("tutor");
 const session = await honcho.session("session-1");
 await session.addMessages([
  alice.message("Hey there — can you help me with my math homework?"),
  tutor.message("Absolutely. Send me your first problem!"),
 ]);
 const answer = await alice.chat(
  "What learning styles does the user respond to best?",
 );
 const context = await session.context({ summary: true, tokens: 10_000 });
 const openai = new OpenAI();
 const completion = await openai.chat.completions.create({
  model: process.env.OPENAI_MODEL ?? "gpt-4o-mini",
  messages: context.toOpenAI({ assistant: tutor }),
 });
 ```
 > **Note:** background reasoning is asynchronous. Newly-added messages may take a moment to be reflected in chat/representation responses; for low-latency reads, use the [`representation`](https://honcho.dev/docs/v3/documentation/features/representation) endpoint.
 ## What Honcho Gives You
 | Need                               | API                                                             |
 | ---------------------------------- | --------------------------------------------------------------- |
 | Save interaction history           | `session.add_messages(...)`                                     |
 | Ask what Honcho knows about a peer | `peer.chat(...)`                                                |
 | Get prompt-ready context           | `session.context(...).to_openai(...)` / `.to_anthropic(...)`    |
 | Hybrid search (BM25 + vector)      | `peer.search(...)`, `session.search(...)`, `honcho.search(...)` |
 | Low-latency static representations | `peer.representation(...)`, `session.representation(...)`       |
 | Import documents                   | `session.upload_file(...)`                                      |
 | Inspect background processing      | `honcho.queue_status(...)`                                      |
 See the full [SDK Reference](https://honcho.dev/docs/v3/documentation/reference/sdk) and [API Reference](https://honcho.dev/docs/v3/api-reference/introduction).
 ## Integrations
 Honcho ships a first-party memory plugin for every major coding agent. They all read the same
 `~/.honcho/config.json`, so one key configures all of them — and pointing two at the same `workspace`
 gives them one shared memory.
 | Agent            | Install                                                 | Source                                                             |
 | ---------------- | ------------------------------------------------------- | ------------------------------------------------------------------ |
 | Claude Code      | `/plugin marketplace add plastic-labs/claude-honcho`    | [claude-honcho](https://github.com/plastic-labs/claude-honcho)     |
 | Codex            | `npm install -g @honcho-ai/codex-honcho`                | [codex-honcho](https://github.com/plastic-labs/codex-honcho)       |
 | Cursor           | `curl -fsSL .../cursor-honcho/main/install.sh \| bash`  | [cursor-honcho](https://github.com/plastic-labs/cursor-honcho)     |
 | DeepSeek Harness | `dsh plugin --profile <name> add @honcho-ai/dsh-honcho` | [dsh-honcho](https://github.com/plastic-labs/dsh-honcho)           |
 | OpenCode         | `opencode plugin "@honcho-ai/opencode-honcho" --global` | [opencode-honcho](https://github.com/plastic-labs/opencode-honcho) |
 | OpenClaw         | `openclaw plugins install @honcho-ai/openclaw-honcho`   | [openclaw-honcho](https://github.com/plastic-labs/openclaw-honcho) |
 | Hermes           | `hermes memory setup`                                   | built in upstream                                                  |
 | Any MCP client   | `claude mcp add honcho --transport http ...`            | [MCP guide](https://honcho.dev/docs/v3/guides/integrations/mcp)    |
 Get a key at [app.honcho.dev](https://app.honcho.dev), then `honcho init` (or `uv tool install honcho-cli && honcho init`) writes it to `~/.honcho/config.json` once for every integration.
 ### Claude Code
 Two ways, depending on how deep you want to go:
 **Plugin (richer integration — recommended for Claude Code users):**
 ```text
 /plugin marketplace add plastic-labs/claude-honcho
 /plugin install honcho@honcho
 ```
 **Raw MCP (works in any MCP client — Cursor, Cline, Windsurf, etc.):**
 ```bash
 claude mcp add honcho \
  --transport http \
  --url "https://mcp.honcho.dev" \
  --header "Authorization: Bearer hch-your-key-here" \
  --header "X-Honcho-User-Name: YourName"
 ```
 Details: [Claude Code guide](https://honcho.dev/docs/v3/guides/integrations/claude-code) · [MCP guide](https://honcho.dev/docs/v3/guides/integrations/mcp) · [repo](https://github.com/plastic-labs/claude-honcho).
 ### Codex
 ```bash
 npm install -g @honcho-ai/codex-honcho
 codex-honcho install      # registers hooks + MCP + skill in ~/.codex
 ```
 Restart Codex to load the hooks. Details: [Codex guide](https://honcho.dev/docs/v3/guides/integrations/codex) · [repo](https://github.com/plastic-labs/codex-honcho).
 ### Cursor
 ```bash
 curl -fsSL https://raw.githubusercontent.com/plastic-labs/cursor-honcho/main/install.sh | bash
 ```
 Windows (PowerShell): `irm https://raw.githubusercontent.com/plastic-labs/cursor-honcho/main/install.ps1 | iex`. The installer wires global hooks and MCP config. Details: [cursor-honcho](https://github.com/plastic-labs/cursor-honcho).
 ### DeepSeek Harness
 ```bash
 dsh plugin --profile <name> add @honcho-ai/dsh-honcho
 ```
 A native Cordis plugin. It injects memory into the system prompt and captures new information from the session event feed. The model gets three tools — honcho_search, honcho_chat, and honcho_remember — and you can run /honcho to check status.
 Details: [DeepSeek Harness guide](https://honcho.dev/docs/v3/guides/integrations/deepseek-harness) · [repo](https://github.com/plastic-labs/dsh-honcho).
 ### OpenCode
 ```bash
 opencode plugin "@honcho-ai/opencode-honcho" --global
 ```
 Details: [OpenCode guide](https://honcho.dev/docs/v3/guides/integrations/opencode) · [repo](https://github.com/plastic-labs/opencode-honcho).
 ### OpenClaw
 ```bash
 openclaw plugins install @honcho-ai/openclaw-honcho
 openclaw honcho setup
 openclaw gateway --force
 ```
 `openclaw honcho setup` prompts for your API key, writes the config, and optionally migrates legacy `MEMORY.md` / `USER.md` / `IDENTITY.md` files into Honcho (non-destructive — originals are never deleted). Details: [OpenClaw guide](https://honcho.dev/docs/v3/guides/integrations/openclaw) · [repo](https://github.com/plastic-labs/openclaw-honcho).
 ### Hermes
 ```bash
 hermes memory setup   # select "honcho", point at api.honcho.dev or your local server
 ```
 Details: [Hermes guide](https://honcho.dev/docs/v3/guides/integrations/hermes).
 ### Add Honcho to your own codebase (agent skill)
 For wiring the Honcho SDK into an existing application, install the integration skill — it explores your codebase, asks about integration preferences, generates the SDK setup, and verifies it works:
 ```bash
 npx skills add plastic-labs/honcho
 ```
 Then invoke `/honcho-integration` in Claude Code (or `/honcho-dev:integrate` via the plugin marketplace). The same command also installs the memory skills — `honcho-memory` (concepts: the recall/record loop, session and peer strategy, plus how to connect and drive an MCP-connected Honcho) and `honcho-cli` (inspecting a deployment, or running a local stack with `honcho start`). Details: [agentic development guide](https://honcho.dev/docs/v3/documentation/introduction/vibecoding).
 ### Other MCP clients
 The same `claude mcp add` form (or its client-specific equivalent) works in any MCP-compatible client. See [MCP guide](https://honcho.dev/docs/v3/guides/integrations/mcp).
 ## CLI
 [`honcho-cli`](https://pypi.org/project/honcho-cli/) inspects a Honcho deployment from the terminal, or runs a personal local stack with Docker.
 ```bash
 uv tool install honcho-cli
 honcho init                 # Honcho API key or browser login + server URL
 honcho start --setup basic  # local stack: LLM provider key + Docker
 honcho doctor
 ```
 `honcho init` authenticates the CLI against a Honcho server. `honcho start --setup` is a separate step: it writes the LLM provider key the local deriver needs and starts API + deriver + Postgres + Redis.
 Full commands and local-stack details: [CLI reference](https://honcho.dev/docs/v3/documentation/reference/cli) · [`honcho-cli/README.md`](./honcho-cli/README.md). To develop the server from source, see [Self-hosting](#self-hosting).
 ## Core Concepts
 Honcho organises everything around **peers** — humans and AI agents alike are first-class entities. The peer model enables:
 - Multi-participant sessions with mixed human and AI agents
 - Configurable observation settings (which peers observe which others)
 - Flexible identity management for all participants
 - Support for complex multi-agent interactions
 Peers exchange messages within sessions; Honcho reasons over those messages to build a representation of each peer that you can query.
 - **Workspace** (formerly App): top-level container; isolates data between use cases.
 - **Peer** (formerly User): any participant — human user or AI agent.
 - **Session**: a conversation context; many-to-many with peers.
 - **Scope**: a named grouping of sessions that bounds recall (chat, representation, search) to those members.
 - **Message**: an atomic data unit (peer-to-peer communication or ingested document chunk).
 What you query out of Honcho:
 - **Conclusions** — what Honcho has extracted about a peer (deductive and inductive). Exposed via the [conclusions API](https://honcho.dev/docs/v3/api-reference/introduction).
 - **Representations** — static, low-latency snapshots of what Honcho knows about a peer (optionally session-scoped).
 - **Peer Cards** — compact identity summaries.
 - **Session context / summaries** — prompt-ready bundles for long-running conversations.
 <!-- markdownlint-disable MD033 -->
 <details>
 <summary>Internal storage (Collections &amp; Documents)</summary>
 Internally, Honcho stores peer-related observations in **collections** of vector-embedded **documents**. Collections are keyed by `(observer, observed)` peer pairs — the same mechanism powers self-representation (`observer == observed`) and cross-peer modelling (peer X's understanding of peer Y). These primitives are not exposed directly; the Conclusions API is the public surface.
 </details>
 <!-- markdownlint-enable MD033 -->
 <!-- TODO(vineeth/marketing): write the "Honcho vs RAG / vector DB / memory-only" comparison.
     Audit recommendation referenced; copy intentionally deferred to avoid inventing
     positioning claims unsupported by primary sources. -->
 ## Benchmarks &amp; Evals
 Honcho's evals span LongMemEval, LoCoMo, and other long-conversation benchmarks. See the [evals page](https://honcho.dev/evals/), the [research blog post](https://blog.plasticlabs.ai/research/Benchmarking-Honcho), and the [Pareto-frontier announcement video](https://x.com/honchodotdev/status/2002090546521911703?s=20) for methodology and reproducible results.
 ## Self-hosting
 Honcho is open source under AGPL-3.0. To **run** a personal instance, install the CLI (`uv tool install honcho-cli`) and then [`honcho start --setup`](#cli). The paths below are for building from source, contributing, or deploying without the CLI.
 ### Quick start (from source, Docker)
 ```bash
 git clone https://github.com/plastic-labs/honcho.git
 cd honcho
 cp docker-compose.yml.example docker-compose.yml
 cp .env.template .env       # fill in LLM_GEMINI_API_KEY / LLM_ANTHROPIC_API_KEY / LLM_OPENAI_API_KEY
 docker compose up
 ```
 Then point the SDKs at it:
 ```python
 honcho = Honcho(workspace_id="my-app-testing", base_url="http://localhost:8000")
 # or: export HONCHO_URL=http://localhost:8000
 ```
 <!-- markdownlint-disable MD033 -->
 <details>
 <summary>Local development without Docker</summary>
 Below is a guide on setting up a local environment for running the Honcho Server without Docker.
 #### Prerequisites and Dependencies
 Honcho is developed using [python](https://www.python.org/) and [uv](https://docs.astral.sh/uv/).
-The minimum python version is `3.10`
+The minimum python version is `3.9`
-The minimum uv version is `0.5.0`
+The minimum uv version is `0.4.9`
-#### Setup
+### Setup
 Once the dependencies are installed on the system run the following steps to get
 the local project setup.
@ -405,13 +131,7 @@ Honcho utilizes [Postgres](https://www.postgresql.org/) for its database with
 pgvector. An easy way to get started with a postgres database is to create a project
 with [Supabase](https://supabase.com/)
-Alternatively, a `docker-compose` template is available with a sample database configuration.
+A `docker-compose` template is also available with a database configuration.
 To use Docker:
 ```bash
 cp docker-compose.yml.example docker-compose.yml
 docker compose up -d database
 ```
 4. **Edit the environment variables**
@ -423,12 +143,9 @@ security.
 Below are the required configurations:
 ```env
-DB_CONNECTION_URI= # Connection uri for a postgres database (with postgresql+psycopg prefix)
+DB_CONNECTION_URI= # Connection uri for a postgres database
-
+OPENAI_API_KEY= # API Key for OpenAI used for embedding documents
-# LLM Provider API Keys
+ANTHROPIC_API_KEY= # API Key for Anthropic used for the deriver and dialectic API
 LLM_GEMINI_API_KEY= # API Key for Google Gemini (used for deriver, summary, and dialectic minimal/low by default)
 LLM_ANTHROPIC_API_KEY= # API Key for Anthropic (used for dialectic medium/high/max and dream by default)
 LLM_OPENAI_API_KEY= # API Key for OpenAI (used for embeddings when EMBED_MESSAGES=true)
 ```
 > Note that the `DB_CONNECTION_URI` must have the prefix `postgresql+psycopg` to
@ -457,98 +174,160 @@ the `AUTH_JWT_SECRET` environment variable. This is required for `AUTH_USE_AUTH`
 AUTH_JWT_SECRET=<generated_secret>
 ```
-Once auth is enabled, use `scripts/generate_jwt.py` to mint tokens for local
+5. **Launch the API**
-development and scripting:
+
 With the dependencies installed, a database setup and enabled with `pgvector`,
 and the environment variables setup you can now launch a local instance of
 Honcho. The following command will launch the storage API for Honcho:
 ```bash
-# Admin token (full access, no expiry)
+fastapi dev src/main.py
 uv run python scripts/generate_jwt.py --admin
 # Admin token expiring in 24 hours
 uv run python scripts/generate_jwt.py --admin --expires 24h
 # Workspace-scoped token
 uv run python scripts/generate_jwt.py --workspace my-workspace --expires 30d
 # Capture a token for use in curl/scripts
 TOKEN=$(uv run python scripts/generate_jwt.py --admin --print-only)
 curl -H "Authorization: Bearer $TOKEN" http://localhost:8000/v3/workspaces
 ```
-Duration units: `s` (seconds), `m` (minutes), `h` (hours), `d` (days), `w` (weeks), `y` (years).
+This is a development server that will reload whenever code is changed. When
 first launching the API with a connection to the database it will provision the
 necessary tables for Honcho to operate.
-5. **Run database migrations**
+### Docker
-With the database set up and environment variables configured, run the migrations
+As mentioned earlier a `docker-compose` template is included for running Honcho.
-to create the necessary tables:
+As an alternative to running Honcho locally it can also be run with the compose
 template.
 The docker-compose template is set to use an environment file called `.env`.
 You can also copy the `.env.template` and fill with the appropriate values.
 Copy the template and update the appropriate environment variables before
 launching the service:
 ```bash
-uv run alembic upgrade head
+cd honcho
 cp .env.template .env
 # update the file with openai key and other wanted environment variables
 cp docker-compose.yml.example docker-compose.yml
 docker compose up
 ```
-This will create all tables for Honcho including workspaces, peers, sessions,
+### Deploy on Fly
 messages, and the queue system.
-6. **Launch Honcho**
+The API can also be deployed on fly.io. Follow the [Fly.io
 Docs](https://fly.io/docs/getting-started/) to setup your environment and the
 `flyctl`.
-With everything set up, you can now launch a local instance of Honcho. In addition to the database, two
+A sample `fly.toml` is included for convenience.
 components need to be running:
-**Start the API server:**
+> Note: The fly.toml does not include launching a Postgres database. This must
 > be configured separately
 Once `flyctl` is set up use the following commands to launch the application:
 ```bash
-uv run fastapi dev src/main.py
+cd honcho
 flyctl launch --no-deploy # Follow the prompts and edit as you see fit
 cat .env | flyctl secrets import # Load in your secrets
 flyctl deploy # Deploy with appropriate environment variables
 ```
 This is a development server that will reload whenever code is changed.
 **Start a background worker (deriver):**
 In a separate terminal, run:
 ```bash
 uv run python -m src.deriver
 ```
 The deriver generates representations, summaries, peer cards, and manages dreaming tasks. You can increase the number of derivers to improve runtime efficiency.
 </details>
 <!-- markdownlint-enable MD033 -->
 Contributors: see [`CONTRIBUTING.md`](./CONTRIBUTING.md) for pre-commit setup. Deploying to Fly.io: see [Self-hosting docs → Deploying on Fly.io](https://honcho.dev/docs/v3/contributing/self-hosting#deploying-on-fly-io).
 ## Configuration
-Honcho uses a flexible configuration system that supports both TOML files and environment variables. Configuration values are loaded in priority order: **environment variables > `.env` file > `config.toml` > defaults**.
+Honcho uses a flexible configuration system that supports both TOML files and environment variables. Configuration values are loaded in the following priority order (highest to lowest):
-Copy the example file to get started:
+1. Environment variables
 2. `.env` file (for local development)
 3. `config.toml` file
 4. Default values
 ### Using config.toml
 Copy the example configuration file to get started:
 ```bash
 cp config.toml.example config.toml
 ```
-The file is organized by subsystem — `[app]`, `[db]`, `[auth]`, `[cache]`, `[llm]`, `[deriver]`, `[dialectic]`, `[summary]`, `[dream]`, `[peer_card]`, `[webhook]`, `[metrics]`, `[telemetry]`, `[vector_store]`, and `[sentry]`. Any value can be overridden by an environment variable named `{SECTION}_{KEY}`, using `__` for nesting (`DIALECTIC_LEVELS__low__MODEL_CONFIG__MODEL`), or just `{KEY}` for app-level settings.
+Then modify the values as needed. The TOML file is organized into sections:
-See the [configuration reference](https://honcho.dev/docs/v3/contributing/configuration) for every available option, and [`.env.template`](./.env.template) for an annotated list of environment variables.
+- `[app]` - Application-level settings (log level, host, port)
 - `[db]` - Database connection and pool settings
 - `[auth]` - Authentication configuration
 - `[llm]` - LLM provider and model settings
 - `[agent]` - Agent behavior settings
 - `[deriver]` - Background worker settings
 - `[history]` - Message history settings
 ### Using Environment Variables
 All configuration values can be overridden using environment variables. The environment variable names follow this pattern:
 - `{SECTION}_{KEY}` for nested settings
 - Just `{KEY}` for app-level settings
 Examples:
 - `DB_CONNECTION_URI` - Database connection string
 - `AUTH_JWT_SECRET` - JWT secret key
 - `LLM_DIALECTIC_MODEL` - Dialectic LLM model
 - `LOG_LEVEL` - Application log level
 ### Configuration Priority
 When a configuration value is set in multiple places, Honcho uses this priority:
 1. **Environment variables** - Always take precedence
 2. **.env file** - Loaded for local development
 3. **config.toml** - Base configuration
 4. **Default values** - Built-in defaults
 This allows you to:
 - Use `config.toml` for base configuration
 - Override specific values with environment variables in production
 - Use `.env` files for local development without modifying config.toml
 ### Example
 If you have this in `config.toml`:
 ```toml
 [db]
 CONNECTION_URI = "postgresql://localhost/honcho_dev"
 POOL_SIZE = 10
 ```
 You can override just the connection URI in production:
 ```bash
 export DB_CONNECTION_URI="postgresql://prod-server/honcho_prod"
 ```
 The application will use the production connection URI while keeping the pool size from config.toml.
 ## Architecture
-Honcho splits into two services: **Storage** (workspaces, peers, sessions, scopes, messages, internal collections) and **Insights** (reasoning, conclusions, representations, summaries, the chat endpoint). Storage is synchronous via the API; Insights is asynchronous via a background queue consumed by the deriver worker process.
+The functionality of Honcho can be split into two different services: Storage
 and Insights.
-**Key features:**
+### Peer Paradigm
- **Rich Reasoning System** — multiple implementation methods that extract conclusions from interactions and build comprehensive representations of peers
+Honcho uses a peer-based model where both users and agents are represented as "peers". This unified approach enables:
 - **Chat Endpoint** — reasoning-informed responses that integrate conclusions with current context
 - **Background Processing** — asynchronous processing pipeline for expensive operations like representation updates and session summarization
 - **Multi-Provider Support** — configurable LLM providers for different use cases
-<!-- markdownlint-disable MD033 MD001 -->
+- Multi-participant sessions with mixed human and AI agents
-<details>
+- Configurable observation settings (which peers observe which others)
-<summary>Storage primitives in detail</summary>
+- Flexible identity management for all participants
 - Support for complex multi-agent interactions
 #### Key Features
 - **Theory-of-Mind System**: Multiple implementation methods that extract facts from interactions and build comprehensive models of peer psychology
 - **Dialectic API**: Provides theory-of-mind informed responses that integrate long-term facts with current context
 - **Background Processing**: Asynchronous processing pipeline for expensive operations like representation updates and session summarization
 - **Multi-Provider Support**: Configurable LLM providers for different use cases
 ### Storage
 Honcho contains several different primitives used for storing application and
 peer data. This data is used for managing conversations, modeling peer
-identity, building RAG applications, and more.
+psychology, building RAG applications, and more.
 The philosophy behind Honcho is to provide a platform that is peer-centric and
 easily scalable from a single user to a million.
@ -559,36 +338,38 @@ Below is a mapping of the different primitives and their relationships.
 Workspaces
 ├── Peers ←──────────────────┐
 │   ├── Sessions             │
-│   └── (internal collections, keyed by observer/observed peer pair)
+│   ├── Collections          │
 │   │   └── Documents        │
 │   └── Messages (peer-level)│
 │                            │
-├── Scopes ←─────────────────┤ (many-to-many with sessions)
+└── Sessions ←───────────────┤ (many-to-many)
 │                            │
 └── Sessions ←───────────────┤ (many-to-many with peers)
    ├── Peers ───────────────┘
    └── Messages (session-level)
 ```
 **Relationship Details:**
- A **Workspace** contains multiple **Peers** and **Scopes**.
+- A **Workspace** contains multiple **Peers**
- **Peers** and **Sessions** have a many-to-many relationship (peers can participate in multiple sessions, sessions can have multiple peers).
+- **Peers** and **Sessions** have a many-to-many relationship (peers can participate in multiple sessions, sessions can have multiple peers)
- **Scopes** and **Sessions** have a many-to-many relationship (a session can belong to several scopes; a scope groups many sessions).
+- **Messages** can exist at two levels:
- **Messages** belong to a session and are labelled by their source peer.
+  - **Session-level**: Communication between peers within a session
- **Internal collections** of vector-embedded **documents** are keyed by `(observer, observed)` peer pairs. They are not directly exposed via the API; the observations stored in them are exposed as **Conclusions**.
+  - **Peer-level**: Data ingested by a peer to enhance its global representation
 - **Collections** belong to specific **Peers**
 - **Documents** are stored within **Collections**
 Users familiar with APIs such as the OpenAI Assistants API will be familiar with
 much of the mapping here.
 #### Workspaces
-This is the top level construct of Honcho. Developers can register different
+This is the top level construct of Honcho (formerly called Apps). Developers can register different
 `Workspaces` for different assistants, agents, AI enabled features, etc. It is a way to
 isolate data between use cases and provide multi-tenant capabilities.
 #### Peers
 Within a `Workspace` everything revolves around a `Peer`. The `Peer` object
-represents any participant in the system — whether human users or AI agents.
+represents any participant in the system - whether human users or AI agents.
 This unified model enables complex multi-participant interactions.
 #### Sessions
@ -596,123 +377,72 @@ This unified model enables complex multi-participant interactions.
 The `Session` object represents a set of interactions between `Peers` within a
 `Workspace`. Other applications may refer to this as a thread or conversation.
 Sessions can involve multiple peers with configurable observation settings.
 A session can optionally join one or more **Scopes** at creation, or later via
 the scopes API.
 #### Scopes
 A `Scope` is a named grouping of sessions inside a `Workspace`. It is a
 visibility boundary on recall: chat, representation, session context, and
 workspace search answered through a scope see only what happened in that
 scope's member sessions. The underlying peers keep their unified
 representations across everything they have participated in.
 Developers manage scopes through the scopes API (`honcho.scope(...)` /
 `honcho.scopes()`) and an optional `scopes` field on session create — not
 through observer/observed configuration. Adding a session that already has
 messages copies its existing explicit conclusions into the scope (no
 re-derivation); removing one reconciles those copies back out. Query
 backfill progress with the scope `status` endpoint.
 A single scope name answers from that scope's collection and card. A list of
 scopes restricts recall to the union of their member sessions. Empty scopes
 fail closed. `scope` is mutually exclusive with `session` / `filters` on the
 same read.
 #### Messages
-The `Message` represents an atomic data unit that exists at the session level:
+The `Message` represents an atomic data unit that can exist at two levels:
 communication between peers within a session context. All messages are labelled
 by their source peer and can be processed asynchronously to update their
 representations. This flexible design allows for both conversational interactions
 and broader data ingestion for personality modelling.
-</details>
+- **Session-level Messages**: Communication between peers within a session context
-<!-- markdownlint-enable MD033 MD001 -->
+- **Peer-level Messages**: Arbitrary data ingested by a peer to enhance its global representation (independent of any session)
-<!-- markdownlint-disable MD033 -->
+All messages are labeled by their source peer and can be processed
-<details>
+asynchronously to update theory-of-mind models. This flexible design allows for
-<summary>Reasoning pipeline</summary>
+both conversational interactions and broader data ingestion for personality
 modeling.
-The reasoning functionality of Honcho is built on top of the Storage service. As
+#### Collections
 At a high level a `Collection` is a named group of `Documents`. Developers
 familiar with RAG based applications will be familiar with these. `Collections`
 store vector embedded data that developers and agents can retrieve against using
 functions like cosine similarity.
 Collections are also used internally by Honcho while creating theory-of-mind
 representations of peers.
 #### Documents
 As stated before a `Document` is vector embedded data stored in a `Collection`.
 ### Insights
 The Insight functionality of Honcho is built on top of the Storage service. As
 `Messages` and `Sessions` are created for `Peers`, Honcho will asynchronously
 reason about peer psychology to derive facts about them and store them
-in reserved internal collections.
+in reserved `Collections`.
-A high level summary of the pipeline is as follows:
+The system uses a sophisticated message processing pipeline:
-1. Messages are created via the API.
+1. Messages are created via API
-2. Derivation tasks are enqueued for background processing, including:
+2. Enqueued for background processing including:
-   - `representation`: update representations of `Peers`.
+   - `representation`: Update peer's theory of mind
-   - `summary`: create summaries of `Sessions`.
+   - `summary`: Create session summaries
-3. Session-based queue processing ensures proper ordering.
+3. Session-based queue processing ensures proper ordering
-4. Results are stored internally and surfaced via the Conclusions API, Representations, Peer Cards, and the Chat Endpoint.
+4. Results are stored internally in the vector database
-</details>
+To read more about how this works read our [Research Paper](https://arxiv.org/abs/2310.06983)
 <!-- markdownlint-enable MD033 -->
-<!-- markdownlint-disable MD033 MD001 -->
+Developers can then leverage these insights in their application to better
-<details>
+serve peer needs. The primary interface for using these insights is through
-<summary>Retrieving data and insights</summary>
+the [Dialectic Endpoint](https://blog.plasticlabs.ai/blog/Introducing-Honcho's-Dialectic-API).
-Honcho exposes several different ways to retrieve data from the system to best
+This is a regular API endpoint (`/peers/{peer_id}/chat`) that takes natural language requests to get data
-serve the needs of any given application.
+about the `Peer`. This robust design lets us use this single endpoint for all
 cases where extra personalization or information about the `Peer` is necessary.
-#### Get Context
+A developer's application can treat Honcho as an oracle to the `Peer` and
 consult it when necessary. Some examples of how to leverage the Dialectic
 API include:
-In long-running conversations with an LLM, the context window can fill up
+- Asking Honcho for a theory-of-mind insight about the `Peer`
-quickly. To address this, Honcho provides a `context`
+- Asking Honcho to hydrate a prompt with data about the `Peer`s behavior
-endpoint that returns a combination of messages, conclusions, summaries from a
+- Asking Honcho for a 2nd opinion or approach about how to respond to the Peer
-session up to a provided token limit.
+- Getting personalized responses that incorporate long-term facts and context
 Use this to keep sessions going indefinitely. If you'd like to see this in action, try out [Honcho Chat](https://honcho.chat).
 #### Search
 There are several search endpoints that let developers query messages at the
 `Workspace`, `Session`, or `Peer` level using a hybrid search strategy.
 Requests can include advanced filters to further refine
 the results.
 #### Chat API
 The flagship interface for using these insights is the [Chat Endpoint](https://honcho.dev/docs/v3/documentation/features/chat) (`POST /peers/{peer_id}/chat`). It takes natural-language requests to get data about a peer and returns reasoning-grounded responses. Examples:
 - Asking Honcho for a generic or specific insight about the peer.
 - Asking Honcho to hydrate a prompt with data about the peer's behaviour.
 - Asking Honcho for a second opinion on how to respond.
 - Getting personalised responses that incorporate long-term facts and context.
 #### Representations
 For low-latency use cases, Honcho provides access to a `representation` endpoint that returns a static document with insights about a peer in the context of a particular session. Use this to quickly add context to a prompt without having to wait for an LLM response.
 </details>
 <!-- markdownlint-enable MD033 MD001 -->
 ## SDKs
 - **Python** — [`honcho-ai`](https://pypi.org/project/honcho-ai/) on PyPI · source in [`sdks/python/`](./sdks/python)
 - **TypeScript** — [`@honcho-ai/sdk`](https://www.npmjs.com/package/@honcho-ai/sdk) on npm · source in [`sdks/typescript/`](./sdks/typescript)
 - **CLI** — [`honcho-cli`](https://pypi.org/project/honcho-cli/) on PyPI · source in [`honcho-cli/`](./honcho-cli) · [CLI reference](https://honcho.dev/docs/v3/documentation/reference/cli)
 SDKs are versioned independently of the server. Current SDK versions track each other; the server badge above reflects the deployed server version.
 See the [SDK Reference](https://honcho.dev/docs/v3/documentation/reference/sdk) for full API surface, the [API Reference](https://honcho.dev/docs/v3/api-reference/introduction) for the raw HTTP API, and per-SDK example folders for runnable demos.
 ## Learn More
 - [Developer documentation](https://honcho.dev/docs/) — full API surface, guides, integrations.
 - [CLI reference](https://honcho.dev/docs/v3/documentation/reference/cli) — local stack, inspect/debug commands, scripting.
 - [Plastic Labs blog](https://blog.plasticlabs.ai/) — design philosophy and history of the project.
 ## Contributing
-We welcome contributions to Honcho. One thing to know before you start: **pull requests must be linked to an issue carrying the `maintainer-approved` label**, or they are closed automatically. [Browse the approved queue](https://github.com/plastic-labs/honcho/issues?q=is%3Aissue+is%3Aopen+label%3Amaintainer-approved), or make your case in [Discord](http://discord.gg/honcho) — that is where maintainers are most active.
+We welcome contributions to Honcho! Please read our [Contributing Guide](./CONTRIBUTING.md) for details on our development process, coding conventions, and how to submit pull requests.
 See [CONTRIBUTING.md](./CONTRIBUTING.md) for the full process, an architecture walkthrough, and a map of where to change what. For vulnerabilities, see [SECURITY.md](./SECURITY.md) — note that Honcho does not operate a bug bounty.
 ## License
-Honcho is licensed under the AGPL-3.0 License. Learn more at the [License file](./LICENSE).
+Honcho is licensed under the AGPL-3.0 License. Learn more at the [License file](./LICENSE)
--- a/SECURITY.md
+++ b/SECURITY.md
@ -1,73 +0,0 @@
 # Security Policy
 ## Supported Versions
 The `main` branch of this repo maps to the latest canary version of Honcho. To see which versions are supported please refer to the git tags in the repo or the [compatibility guide](https://honcho.dev/docs/changelog/compatibility-guide).
 ## Reporting a Vulnerability
 Do not open a public issue for a suspected vulnerability. Report it privately through one of:
 1. **[GitHub Private Vulnerability Reporting](https://github.com/plastic-labs/honcho/security/advisories/new)** — preferred; it keeps the report, our replies, and any fix coordinated in one place.
 2. Email [support@honcho.dev](mailto:support@honcho.dev) with `[SECURITY]` in the subject.
 Include as much of the following as you have:
 - **Version** — a git commit SHA, or the release tag you are running
 - **Deployment** — self-hosted or the managed service at `api.honcho.dev`
 - **Affected component** — API, deriver, dialectic, auth/JWT, an SDK, or the managed offering
 - **Reproduction** — the exact steps, requests, or script that trigger it
 - **Proof of concept** — the smallest thing that demonstrates the issue actually works
 - **Impact** — what an attacker gains, and what they need to already have to get it
 - **How you found it** — manual review, fuzzing, a scanner, or model-assisted analysis
 Reports with a working proof of concept get looked at first. A report that only describes a
 theoretical problem is much slower for us to act on, because we have to build the repro
 ourselves before we can confirm anything.
 Honcho stores conversational data and peer representations. **Do not attach production user
 content, API keys, or JWTs** to a report — if we need a sample, we will ask for a redacted
 one.
 ## Testing
 Test against an instance you operate. Do not run security testing against `api.honcho.dev`
 or against any Honcho deployment that is not yours — self-hosting is a first-class path and
 takes a few minutes to set up — install the CLI (`uv tool install honcho-cli`) then run `honcho start --setup` (Docker + an LLM provider key), or see [Self-hosting](./README.md#self-hosting).
 ## What to Expect
 We will acknowledge your report and tell you whether we consider it in scope. If it is, we
 will let you know when a fix ships.
 We do not commit to a response SLA, we do not coordinate CVE assignment on request, and we
 do not operate a disclosure timeline you can hold us to. This is a small team.
 ## Out of Scope
 The following are not treated as vulnerabilities. Reports consisting only of these will be
 closed without a detailed response:
 - Automated scanner output with no working proof of concept
 - Model-generated findings that have not been verified by a human against a running instance
 - Missing security headers or TLS configuration with no demonstrated exploit
 - Rate limiting, or resource exhaustion with no demonstrated impact beyond your own instance
 - Vulnerabilities in dependencies with no demonstrated exploit path through Honcho
 - Configuration weaknesses that require an already-compromised host, or that come from
  deliberately insecure settings (for example running with `AUTH_USE_AUTH=false`, which is
  the documented local-development default and is not intended for a public deployment)
 - Social engineering, phishing, and physical access
 For ordinary bugs, memory or recall quality problems, and feature requests, use the
 [issue templates](https://github.com/plastic-labs/honcho/issues/new/choose) instead.
 ## No Bug Bounty
 The Honcho project does not offer any rewards for reported bugs or
 vulnerabilities. We do not aid security researchers to get such rewards for
 Honcho problems from other sources.
 A bug bounty gives people too strong incentives to find and make up "problems"
 in bad faith that cause overload and abuse.
 We still appreciate and value valid vulnerability reports.
--- a/assets/honcho.svg
+++ b/assets/honcho.svg
@ -1,27 +0,0 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 491.02 144">
  <defs>
    <style>
      .cls-1 {
        fill: #b5daff;
      }
      .cls-2 {
        fill: #191919;
      }
    </style>
  </defs>
  <rect class="cls-1" x="0" y="0" width="491.02" height="144" rx="70.34" ry="70.34"/>
  <g>
    <path class="cls-2" d="M42.36,73.11h0s0,0,0,0Z"/>
    <g>
      <path class="cls-2" d="M111.94,38.5v24.08h-16.9v-24.08h-21.06c-11.88,0-22.94,6.36-28.94,16.61-2.66,1.61-4.45,2.74-4.49,2.76-5.17,2.82-7.76,5.51-9.03,7.64-.99.02-1.84.75-1.98,1.75-.16,1.11.62,2.14,1.73,2.3s2.14-.62,2.3-1.73c.08-.57-.09-1.13-.42-1.55,1.87-3.02,5.83-5.51,8.25-6.83.42-.23,23.87-14.43,25.63-14.08.29.06.72.22,1.06.91.93,1.93-7.61,7.63-9.35,8.67-1.67,1-3.13,2.06-4.41,3.2-2.69,2.4-4.49,5.09-5.36,8.05-.53,1.78-2.02,6.91-5.66,8.19-.26-.57-.78-1.02-1.44-1.16-1.1-.23-2.18.48-2.41,1.58-.22,1.04.4,2.06,1.4,2.37,2.51,16.26,16.43,28.31,33.09,28.32h0s21.07.01,21.07.01v-28.16h16.9v28.16h21.07V38.5h-21.07,0ZM55.16,59.86c-.08,1.04-.32,2.24-.91,3.02-.62.82-1.79,1.52-2.84,2.01.83-1.79,2.09-3.47,3.75-5.03h0ZM73.96,83.12h-8.26c-.88,0-1.6.71-1.6,1.6,0,.44.18.84.47,1.13.29.29.69.47,1.13.47h8.26v17.37c-15.77,0-28.94-11.42-31.31-26.81.24-.18.44-.4.59-.67,3.01-1.08,5.29-2.56,7.32-9.03,1.09-.38,3.81-1.46,5.13-3.21,1.32-1.75,1.34-4.5,1.29-5.64.83-.63,1.73-1.24,2.7-1.82,5.56-3.33,11.57-7.86,10.05-11.01-.5-1.04-1.31-1.7-2.33-1.9-1.93-.38-11.56,5.06-18.73,9.32,5.94-7.87,15.32-12.63,25.31-12.63v42.82h0Z"/>
      <ellipse class="cls-2" cx="63.3" cy="66.65" rx="3.45" ry="5.35"/>
      <path class="cls-2" d="M187.15,40.14c4.44,2.01,7.66,5.5,9.66,10.49,2.01,4.99,3.01,12.11,3.01,21.36s-1,16.38-3.01,21.36c-2.01,4.99-5.23,8.48-9.66,10.49-4.44,2.01-10.64,3.01-18.6,3.01s-14.07-1-18.5-3.01c-4.44-2.01-7.66-5.5-9.66-10.49-2.01-4.99-3.01-12.11-3.01-21.36s1-16.38,3.01-21.36c2.01-4.99,5.23-8.48,9.66-10.49,4.44-2.01,10.6-3.01,18.5-3.01s14.16,1,18.6,3.01h0ZM162.97,54.38c-1.26,1.07-2.15,2.95-2.67,5.63s-.78,6.69-.78,11.99.26,9.31.78,11.99c.52,2.69,1.41,4.56,2.67,5.63s3.12,1.6,5.58,1.6,4.32-.53,5.58-1.6,2.15-2.95,2.67-5.63c.52-2.69.78-6.69.78-11.99s-.26-9.31-.78-11.99c-.52-2.69-1.41-4.56-2.67-5.63s-3.13-1.6-5.58-1.6-4.32.53-5.58,1.6Z"/>
      <path class="cls-2" d="M265.77,98.22c0,2.4-.61,4.21-1.84,5.44s-3.04,1.84-5.44,1.84h-8.06c-2.01,0-3.54-.45-4.61-1.36s-2.25-2.49-3.54-4.76l-14.57-23.02c-1.62-2.91-3.11-6.73-4.47-11.46h-.68c.64,4.53.97,8.61.97,12.24v28.36h-19.42v-59.73c0-2.4.61-4.21,1.84-5.44s3.04-1.84,5.44-1.84h8.06c2.01,0,3.53.45,4.56,1.36,1.03.91,2.23,2.49,3.59,4.76l13.99,21.95c1.75,3.11,3.46,6.93,5.15,11.46h.68c-.58-4.92-.88-8.97-.88-12.14l-.1-27.39h19.33v59.73h0Z"/>
      <path class="cls-2" d="M312.49,37.91c3.04.39,6.34,1.07,9.91,2.04l-1.55,15.34c-1.49,0-2.62-.03-3.4-.1l-17.09-.1c-2.27,0-3.98.47-5.15,1.41-1.17.94-1.98,2.59-2.43,4.95-.45,2.37-.68,5.87-.68,10.54s.23,8.18.68,10.54c.45,2.37,1.26,4.01,2.43,4.95,1.17.94,2.88,1.41,5.15,1.41,5.31,0,9.53-.05,12.67-.15s6.23-.31,9.27-.63l1.55,15.34c-3.43,1.17-6.9,1.99-10.39,2.48s-7.87.73-13.11.73c-7.51,0-13.47-1.12-17.87-3.35-4.4-2.23-7.59-5.86-9.57-10.88-1.98-5.02-2.96-11.83-2.96-20.44s.99-15.43,2.96-20.44c1.97-5.02,5.16-8.64,9.57-10.88,4.4-2.23,10.36-3.35,17.87-3.35,5.05,0,9.09.19,12.14.58h0Z"/>
      <path class="cls-2" d="M387.85,38.49v67.01h-21.07v-28.17h-16.9v28.17h-21.07V38.49h21.07v24.08h16.9v-24.08s21.07,0,21.07,0Z"/>
      <path class="cls-2" d="M441.99,40.14c4.44,2.01,7.66,5.5,9.66,10.49,2.01,4.99,3.01,12.11,3.01,21.36s-1,16.38-3.01,21.36c-2.01,4.99-5.23,8.48-9.66,10.49-4.44,2.01-10.64,3.01-18.6,3.01s-14.07-1-18.5-3.01c-4.44-2.01-7.66-5.5-9.66-10.49-2.01-4.99-3.01-12.11-3.01-21.36s1-16.38,3.01-21.36,5.23-8.48,9.66-10.49c4.44-2.01,10.6-3.01,18.5-3.01s14.16,1,18.6,3.01h0ZM417.81,54.38c-1.26,1.07-2.15,2.95-2.67,5.63-.52,2.69-.78,6.69-.78,11.99s.26,9.31.78,11.99c.52,2.69,1.41,4.56,2.67,5.63s3.12,1.6,5.58,1.6,4.32-.53,5.58-1.6,2.15-2.95,2.67-5.63c.52-2.69.78-6.69.78-11.99s-.26-9.31-.78-11.99c-.52-2.69-1.41-4.56-2.67-5.63s-3.13-1.6-5.58-1.6-4.32.53-5.58,1.6Z"/>
    </g>
  </g>
 </svg>
--- a/config.toml.example
+++ b/config.toml.example
@ -6,18 +6,8 @@
 # Application-level settings
 [app]
 LOG_LEVEL = "INFO"
-PERFORMANCE_LOG_FORMAT = "compact" # "compact" for single-line logs, "rich" for local panels
+FASTAPI_HOST = "0.0.0.0"
-SESSION_OBSERVERS_LIMIT = 10
+FASTAPI_PORT = 8000
 GET_CONTEXT_MAX_TOKENS = 100000
 MAX_FILE_SIZE = 5242880  # 5MB
 MAX_MESSAGE_SIZE = 25000 # Characters
 EMBED_MESSAGES = true
 # LANGFUSE_HOST = "https://api.langfuse.com"
 # LANGFUSE_PUBLIC_KEY = "your-public-key-here"
 # COLLECT_METRICS_LOCAL = false
 # LOCAL_METRICS_FILE = "metrics.jsonl"
 # REASONING_TRACES_FILE = "traces.jsonl"  # Path to JSONL file for reasoning traces
 NAMESPACE = "honcho"
 # Database settings
 [db]
@ -27,14 +17,11 @@ POOL_CLASS = "default"
 POOL_PRE_PING = true
 POOL_SIZE = 10
 MAX_OVERFLOW = 20
-POOL_TIMEOUT = 5  # seconds a pooled checkout waits for a free connection (QueuePool only)
+POOL_TIMEOUT = 30  # seconds
 POOL_RECYCLE = 300  # seconds
 POOL_USE_LIFO = true
 SQL_DEBUG = false
 TRACING = false
 # Per-connection establish timeout (seconds) so a single connection attempt
 # fails fast instead of hanging when the server/pooler is unreachable.
 CONNECT_TIMEOUT_SECONDS = 2
 # Authentication settings
 [auth]
@ -45,247 +32,51 @@ JWT_SECRET = "your-secret-key-here"  # Must be set if USE_AUTH is true
 [sentry]
 ENABLED = false
 DSN = ""
 RELEASE = ""
 ENVIRONMENT = "development"
 TRACES_SAMPLE_RATE = 0.1
 PROFILES_SAMPLE_RATE = 0.1
 # LLM settings
 [llm]
-DEFAULT_MAX_TOKENS = 2500
+DEFAULT_MAX_TOKENS = 1000
-MAX_TOOL_OUTPUT_CHARS = 10000  # Max chars for tool output (~2500 tokens)
+DEFAULT_TEMPERATURE = 0.0
 MAX_MESSAGE_CONTENT_CHARS = 2000  # Max chars per message in tool results
-# API Keys for LLM providers (set the ones you need)
+# Dialectic specific
-# Supported transports: openai, anthropic, gemini
+DIALECTIC_PROVIDER = "anthropic"
-# Base URLs are set per-module via model_config.overrides.base_url
+DIALECTIC_MODEL = "claude-3-7-sonnet-20250219"
-# Built-in text-generation defaults use openai / gpt-5.4-mini.
+
-# Embeddings default to openai / text-embedding-3-small.
+# Query Generation specific
-OPENAI_API_KEY = "your-api-key-here"
+QUERY_GENERATION_PROVIDER = "groq"
 QUERY_GENERATION_MODEL = "llama-3.1-8b-instant"
 # Summarization specific
 SUMMARY_PROVIDER = "google"
 SUMMARY_MODEL = "gemini-2.0-flash-lite"
 SUMMARY_MAX_TOKENS_SHORT = 1000
 SUMMARY_MAX_TOKENS_LONG = 2000
 # API Keys for LLM providers 
 # ANTHROPIC_API_KEY = "your-api-key"
 # OPENAI_API_KEY = "your-api-key"
 # OPENAI_COMPATIBLE_API_KEY = "your-api-key"
 # GEMINI_API_KEY = "your-api-key"
 # GROQ_API_KEY = "your-api-key"
 # OPENAI_COMPATIBLE_BASE_URL = "your-api-key"
-# Embedding settings
+# Agent settings
-[embedding]
+[agent]
-VECTOR_DIMENSIONS = 1536
+SEMANTIC_SEARCH_TOP_K = 10
-MAX_INPUT_TOKENS = 8192
+SEMANTIC_SEARCH_MAX_DISTANCE = 0.85
-MAX_TOKENS_PER_REQUEST = 300000
+TOM_INFERENCE_METHOD = "single_prompt"
 [embedding.model_config]
 transport = "openai"
 model = "text-embedding-3-small"
 # Optional provider request input cap. Useful for OpenAI-compatible embedding
 # APIs with smaller limits, such as DashScope text-embedding-v4.
 # max_batch_size = 10
 # Optional client HTTP timeout in seconds (OpenAI + Gemini).
 # timeout = 90.0
 # Optional module-level endpoint overrides
 # [embedding.model_config.overrides]
 # base_url = "https://embedding-proxy.internal.example/v1"
 # api_key_env = "EMBEDDING_CUSTOM_API_KEY"
 # Deriver settings
 [deriver]
 ENABLED = true
 WORKERS = 1
 POLLING_SLEEP_INTERVAL_SECONDS = 1.0
 # Adaptive polling: when idle/erroring, the sleep interval grows from
 # POLLING_SLEEP_INTERVAL_SECONDS toward POLLING_SLEEP_MAX_INTERVAL_SECONDS by
 # POLLING_BACKOFF_MULTIPLIER each cycle, then snaps back to base when work is
 # found. Cuts steady-state query load against the shared DB/pooler.
 POLLING_BACKOFF_ENABLED = true
 POLLING_SLEEP_MAX_INTERVAL_SECONDS = 30.0
 POLLING_BACKOFF_MULTIPLIER = 2.0
 # Jitter so instances that start together don't poll in lockstep. Startup:
 # sleep a random delay in [0, POLLING_STARTUP_JITTER_SECONDS] before the first
 # poll (0.0 disables). Per-cycle: multiply every poll sleep by a random factor
 # in [1 - ratio, 1 + ratio] (0.5 -> [0.5x, 1.5x]; 0.0 disables).
 POLLING_STARTUP_JITTER_SECONDS = 30.0
 POLLING_JITTER_RATIO = 0.5
 STALE_SESSION_TIMEOUT_MINUTES = 5
-# Minimum (jittered) spacing between stale-work-unit cleanup runs per instance.
+POLLING_SLEEP_INTERVAL_SECONDS = 1.0
-# Staleness is a minutes-timescale condition, so cleanup doesn't need to run on
+TOM_METHOD = "single_prompt"
-# every seconds-scale poll (0.0 = run every poll, legacy behavior).
+USER_REPRESENTATION_METHOD = "long_term"
 STALE_WORK_UNIT_CLEANUP_INTERVAL_SECONDS = 60.0
 # QUEUE_ERROR_RETENTION_SECONDS = 2592000  # 30 days
 DEDUPLICATE = true
 LOG_OBSERVATIONS = false
 MAX_INPUT_TOKENS = 25000
 MAX_CUSTOM_INSTRUCTIONS_TOKENS = 2000
 WORKING_REPRESENTATION_MAX_OBSERVATIONS = 100
 REPRESENTATION_BATCH_WORK_UNIT_TARGET_TOKENS = 512  # Min tokens a work unit accumulates before the deriver claims it; 0 disables the gate
 REPRESENTATION_BATCH_TARGET_INPUT_TOKENS = 1024  # Max context-window tokens per deriver LLM call
 REPRESENTATION_BATCH_MAX_AGE_SECONDS = 1800
 FLUSH_ENABLED = false  # Bypass batch token threshold, process work immediately
-[deriver.model_config]
+# History settings
-transport = "openai"
+[history]
 model = "gpt-5.4-mini"
 # temperature = 0.0
 # thinking_effort = "minimal"
 # thinking_budget_tokens = 1024
 # max_output_tokens = 4096
 # Optional module-level endpoint overrides
 # transport = "openai"
 # model = "my-local-model"
 # [deriver.model_config.overrides]
 # base_url = "https://llm.internal.example/v1"
 # api_key_env = "DERIVER_CUSTOM_API_KEY"
 # Optional fallback model
 # [deriver.model_config.fallback]
 # transport = "anthropic"
 # model = "claude-haiku-4-5"
 # [deriver.model_config.fallback.overrides]
 # base_url = "https://llm-backup.internal.example/v1"
 # api_key_env = "DERIVER_CUSTOM_BACKUP_API_KEY"
 # [deriver.model_config.overrides.provider_params]
 # verbosity = "low"
 # timeout = 3600.0
 # Peer card settings
 [peer_card]
 ENABLED = true
 # Dialectic settings
 [dialectic]
 MAX_OUTPUT_TOKENS = 8192
 MAX_INPUT_TOKENS = 100000
 HISTORY_TOKEN_LIMIT = 8192
 SESSION_HISTORY_MAX_TOKENS = 4096
 # Per-level settings for reasoning levels
 # MAX_OUTPUT_TOKENS is optional per level; if not set, uses global MAX_OUTPUT_TOKENS
 [dialectic.levels.minimal]
 MAX_TOOL_ITERATIONS = 1
 MAX_OUTPUT_TOKENS = 250
 TOOL_CHOICE = "auto"
 [dialectic.levels.minimal.model_config]
 transport = "openai"
 model = "gpt-5.4-mini"
 [dialectic.levels.low]
 MAX_TOOL_ITERATIONS = 5
 TOOL_CHOICE = "auto"
 [dialectic.levels.low.model_config]
 transport = "openai"
 model = "gpt-5.4-mini"
 [dialectic.levels.medium]
 MAX_TOOL_ITERATIONS = 2
 [dialectic.levels.medium.model_config]
 transport = "openai"
 model = "gpt-5.4-mini"
 [dialectic.levels.high]
 MAX_TOOL_ITERATIONS = 4
 [dialectic.levels.high.model_config]
 transport = "openai"
 model = "gpt-5.4-mini"
 [dialectic.levels.max]
 MAX_TOOL_ITERATIONS = 10
 [dialectic.levels.max.model_config]
 transport = "openai"
 model = "gpt-5.4-mini"
 # [dialectic.levels.max.model_config.fallback]
 # transport = "gemini"
 # model = "gemini-2.5-pro"
 # Summary settings
 [summary]
 ENABLED = true
 MESSAGES_PER_SHORT_SUMMARY = 20
 MESSAGES_PER_LONG_SUMMARY = 60
 MAX_TOKENS_SHORT = 1000
 MAX_TOKENS_LONG = 4000
 [summary.model_config]
 transport = "openai"
 model = "gpt-5.4-mini"
 # thinking_effort = "minimal"
 # thinking_budget_tokens = 1024
 # [summary.model_config.fallback]
 # transport = "anthropic"
 # model = "claude-haiku-4-5"
 # Dream settings
 [dream]
 ENABLED = true
 DOCUMENT_THRESHOLD = 50
 IDLE_TIMEOUT_MINUTES = 60
 MIN_HOURS_BETWEEN_DREAMS = 8
 ENABLED_TYPES = ["omni"]
 MAX_TOOL_ITERATIONS = 20
 HISTORY_TOKEN_LIMIT = 16384
 [dream.deduction_model_config]
 transport = "openai"
 model = "gpt-5.4-mini"
 [dream.induction_model_config]
 transport = "openai"
 model = "gpt-5.4-mini"
 # Surprisal-based sampling subsystem
 [dream.surprisal]
 ENABLED = false
 TREE_TYPE = "kdtree"  # Options: kdtree, balltree, rptree, covertree, lsh, graph, prototype
 TREE_K = 5  # k for kNN-based trees
 SAMPLING_STRATEGY = "recent"  # Options: recent, random, all
 SAMPLE_SIZE = 200
 TOP_PERCENT_SURPRISAL = 0.10  # Top 10% of observations
 MIN_HIGH_SURPRISAL_FOR_REPLACE = 10
 INCLUDE_LEVELS = ["explicit", "deductive"]
 # Webhook settings
 [webhook]
 SECRET = ""
 MAX_WORKSPACE_LIMIT = 10
 # Prometheus metrics settings (pull-based metrics)
 [metrics]
 ENABLED = false
 # NAMESPACE = "honcho"  # Inherits from app.NAMESPACE if not set
 # CloudEvents telemetry settings (analytics events)
 [telemetry]
 ENABLED = false
 # ENDPOINT = "https://telemetry.honcho.dev/v1/events"
 # HEADERS = '{"Authorization": "Bearer your-token"}'  # JSON string for auth headers
 BATCH_SIZE = 100
 FLUSH_INTERVAL_SECONDS = 1.0
 FLUSH_THRESHOLD = 50
 MAX_RETRIES = 3
 MAX_BUFFER_SIZE = 10000
 # NAMESPACE = "honcho"  # Inherits from app.NAMESPACE if not set
 # Cache settings
 [cache]
 ENABLED = false
 URL = "redis://localhost:6379/0?suppress=true"
 # NAMESPACE = "honcho"  # Inherits from app.NAMESPACE if not set
 DEFAULT_TTL_SECONDS = 300
 DEFAULT_LOCK_TTL_SECONDS = 5
 # Vector store settings
 [vector_store]
 # Vector store type: "pgvector", "turbopuffer", or "lancedb"
 TYPE = "pgvector"
 # Migration flag: set to true when migration from pgvector is complete
 MIGRATED = false
 NAMESPACE = "honcho"
 # DIMENSIONS is deprecated; embedding.vector_dimensions is authoritative.
 # TURBOPUFFER_API_KEY = "your-turbopuffer-api-key"
 # TURBOPUFFER_REGION = "us-east-1"
 LANCEDB_PATH = "./lancedb_data"
 RECONCILIATION_INTERVAL_SECONDS = 300
--- a/docker-compose.yml.example
+++ b/docker-compose.yml.example
@ -1,180 +1,46 @@
 # Honcho Docker Compose
 #
 # Usage:
 #   cp docker-compose.yml.example docker-compose.yml
 #   cp .env.template .env  # edit with your provider config
 #   docker compose up -d --build
 #   INSTALL_LANCEDB=true docker compose up -d --build  # optional local vector store
 #
 # By default, ports are bound to 127.0.0.1 (localhost only).
 # For development, uncomment the source mounts and monitoring services below.
 services:
  api:
    image: honcho:latest
    build:
      context: .
      dockerfile: Dockerfile
      args:
        INSTALL_LANCEDB: ${INSTALL_LANCEDB:-false}
    entrypoint: ["sh", "docker/entrypoint.sh"]
    depends_on:
      database:
        condition: service_healthy
      redis:
        condition: service_healthy
    ports:
-      - "127.0.0.1:8000:8000"
+      - 8000:8000
    healthcheck:
      test:
        [
          "CMD",
          "/app/.venv/bin/python",
          "-c",
          "import urllib.request; urllib.request.urlopen('http://localhost:8000/health', timeout=2).read()",
        ]
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 10s
    volumes:
-      # Shared LanceDB data (used when VECTOR_STORE_TYPE=lancedb)
+      - .:/app
      - lancedb-data:/app/lancedb_data
      # -- Development: mount source for live reload --
      # - .:/app
      # - venv:/app/.venv
    environment:
      - DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@database:5432/postgres
      - CACHE_URL=redis://redis:6379/0?suppress=true
      - CACHE_ENABLED=true
    env_file:
-      - path: .env
+      - .env
        required: false
    restart: unless-stopped
  deriver:
    build:
      context: .
      dockerfile: Dockerfile
-      args:
+    entrypoint: ["uv", "run", "python", "-m", "src.deriver"]
        INSTALL_LANCEDB: ${INSTALL_LANCEDB:-false}
    entrypoint: ["/app/.venv/bin/python", "-m", "src.deriver"]
    depends_on:
      api:
        condition: service_healthy
      database:
        condition: service_healthy
      redis:
        condition: service_healthy
    volumes:
-      # Shared LanceDB data (used when VECTOR_STORE_TYPE=lancedb)
+      - .:/app
      - lancedb-data:/app/lancedb_data
      # -- Development: mount source for live reload --
      # - .:/app
      # - venv:/app/.venv
    environment:
      - DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@database:5432/postgres
      - CACHE_URL=redis://redis:6379/0?suppress=true
      - CACHE_ENABLED=true
    env_file:
-      - path: .env
+      - .env
        required: false
    restart: unless-stopped
  mcp:
    build:
      context: ./mcp
      dockerfile: Dockerfile
    depends_on:
      api:
        condition: service_healthy
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      - HONCHO_API_URL=http://api:8000
    env_file:
      - path: .env
        required: false
    healthcheck:
      test:
        [
          "CMD",
          "bun",
          "-e",
          "fetch('http://127.0.0.1:3000/health').then((r)=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))",
        ]
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 10s
    restart: unless-stopped
  database:
    image: pgvector/pgvector:pg15
-    restart: unless-stopped
+    restart: always
    ports:
-      - "127.0.0.1:5432:5432"
+      - 5432:5432
    command: ["postgres", "-c", "max_connections=200"]
    environment:
-      - POSTGRES_DB=postgres
+      - POSTGRES_DB=honcho
-      - POSTGRES_USER=postgres
+      - POSTGRES_USER=testuser
-      - POSTGRES_PASSWORD=postgres
+      - POSTGRES_PASSWORD=testpwd
      # Allow passwordless connections from the host (port is bound to 127.0.0.1).
      # Lets the local test suite and ad-hoc tools connect without supplying a
      # password. Do NOT use this in production.
      - POSTGRES_HOST_AUTH_METHOD=trust
      - PGDATA=/var/lib/postgresql/data/pgdata
    volumes:
-      - ./database/init.sql:/docker-entrypoint-initdb.d/init.sql
+      - ./init.sql:/docker-entrypoint-initdb.d/init.sql
-      - pgdata:/var/lib/postgresql/data/
+      - ./data:/var/lib/postgresql/data/
    healthcheck:
-      test: ["CMD-SHELL", "pg_isready -U postgres -d postgres"]
+      test: ["CMD-SHELL", "pg_isready -U testuser -d honcho"]
      interval: 5s
      timeout: 5s
      retries: 5
  redis:
    image: redis:8.2
    restart: unless-stopped
    ports:
      - "127.0.0.1:6379:6379"
    volumes:
      - redis-data:/data
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping"]
      interval: 5s
      timeout: 5s
      retries: 5
  # -- Development: monitoring stack (uncomment to enable) --
  # prometheus:
  #   image: prom/prometheus:v3.2.1
  #   ports:
  #     - "127.0.0.1:9090:9090"
  #   volumes:
  #     - ./docker/prometheus.yml:/etc/prometheus/prometheus.yml:ro
  #     - prometheus-data:/prometheus
  #   depends_on:
  #     api:
  #       condition: service_started
  # grafana:
  #   image: grafana/grafana:11.4.0
  #   ports:
  #     - "127.0.0.1:3000:3000"
  #   environment:
  #     - GF_SECURITY_ADMIN_USER=admin
  #     - GF_SECURITY_ADMIN_PASSWORD=admin
  #     - GF_AUTH_ANONYMOUS_ENABLED=true
  #     - GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer
  #   volumes:
  #     - ./docker/grafana-datasource.yml:/etc/grafana/provisioning/datasources/datasource.yml:ro
  #   depends_on:
  #     prometheus:
  #       condition: service_started
 volumes:
  pgdata:
  redis-data:
  lancedb-data:
  # -- Development: uncomment if using source mounts --
  # venv:
  # prometheus-data:
--- a/docker/entrypoint.sh
+++ b/docker/entrypoint.sh
@ -1,8 +0,0 @@
 #!/bin/sh
 set -e
 echo "Running database migrations..."
 /app/.venv/bin/python scripts/provision_db.py
 echo "Starting API server..."
 exec /app/.venv/bin/fastapi run --host 0.0.0.0 --workers "${API_WORKERS:-1}" src/main.py
--- a/docker/grafana-datasource.yml
+++ b/docker/grafana-datasource.yml
@ -1,9 +0,0 @@
 apiVersion: 1
 datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
    editable: false
--- a/docker/prometheus.yml
+++ b/docker/prometheus.yml
@ -1,10 +0,0 @@
 global:
  scrape_interval: 15s
 scrape_configs:
  - job_name: honcho-api
    static_configs:
      - targets: ["api:8000"]
  - job_name: honcho-deriver
    static_configs:
      - targets: ["deriver:9090"]
--- a/docs/README.md
+++ b/docs/README.md
@ -5,21 +5,18 @@ These docs are built using Next.js via mintlify.
 ## Setting Up Honcho's Docs Locally
 1. Clone the repository:
 ```
 git clone git@github.com:plastic-labs/honcho.git
 ```
 2. Navigate into the `docs` folder:
 ```
 cd honcho/docs/
 ```
 The docs folder contains the markdown files that make up the documentation. The majority of the files are in the pages directory. Some notable files in this folder include:
 3. Verify that you have Node.js and npm installed in your system. You can check by running:
 3. Verify that you have Node.js and npm installed in your system. You can check by running:
 ```
 node --version
 npm --version
@ -28,19 +25,16 @@ npm --version
 4. If not installed, download Node.js and npm from the respective official websites.
 5. Once you have Node.js and npm running, proceed to install `pnpm` - another package manager that helps to manage project dependencies:
 ```
 npm install -g pnpm
 ```
 6. Install the project dependencies using pnpm:
 ```
 pnpm i
 ```
 7. After the successful installation of the project dependencies, start the local server:
 ```
 pnpm dev
 ```
--- a/docs/_snippets/overview-shields.mdx
+++ b/docs/_snippets/overview-shields.mdx
--- a/docs/bun.lock
+++ b/docs/bun.lock
--- a/docs/changelog/compatibility-guide.mdx
+++ b/docs/changelog/compatibility-guide.mdx
@ -4,59 +4,34 @@ description: "Compatibility guide for Honcho's SDKs and API"
 icon: "shield-check"
 ---
-This guide helps you match the right SDK version to your Honcho API version. Newer SDK patch versions are always backward-compatible within the same major version — install the latest patch for your range.
+This guide helps you understand which versions of Honcho's API are compatible with which SDK versions.
-## Current Versions
+## Version Compatibility
 ### Honcho API v2.0.2 (Current)
 <CardGroup cols={2}>
  <Card title="TypeScript SDK" icon="js">
-    **Latest:** v2.4.0
+    **Compatible Version:** v1.1.0
    Install with:
    ```bash
-    npm install @honcho-ai/sdk
+    npm install @honcho-ai/sdk@1.1.0
    ```
  </Card>
  <Card title="Python SDK" icon="python">
    **Latest:** v2.4.0
  <Card title="Python SDK" icon="python">
    **Compatible Version:** v1.1.0
    Install with:
    ```bash
-    pip install honcho-ai
+    pip install honcho-ai==1.1.0
    ```
  </Card>
 </CardGroup>
 ## Version Compatibility Table
-| Honcho API Version | TypeScript SDK | Python SDK |
+| Honcho API Version | TypeScript SDK | Python SDK | Notes |
-|-------------------|---------------|------------|
+|-------------------|---------------|------------|-------|
-| v3.1.1 (Current) | v2.4.0 | v2.4.0 |
+| v2.0.2 (Current) | v1.1.0 | v1.1.0 | Full compatibility with new peer architecture |
 | v3.1.0 | v2.4.0 | v2.4.0 |
 | v3.0.12 | v2.3.0 | v2.3.0 |
 | v3.0.11 | v2.1.2 | v2.1.2 |
 | v3.0.10 | v2.1.2 | v2.1.2 |
 | v3.0.9 | v2.1.2 | v2.1.2 |
 | v3.0.8 | v2.1.2 | v2.1.2 |
 | v3.0.7 | v2.1.2 | v2.1.2 |
 | v3.0.6 | v2.1.1 | v2.1.1 |
 | v3.0.5 | v2.1.0 | v2.1.0 |
 | v3.0.4 | v2.1.0 | v2.1.0 |
 | v3.0.3 | v2.1.0 | v2.1.0 |
 | v3.0.2 | v2.0.0+ | v2.0.0+ |
 | v3.0.1 | v2.0.0+ | v2.0.0+ |
 | v3.0.0 | v2.0.0+ | v2.0.0+ |
 | v2.5.1 | v1.6.0 | v1.6.0 |
 | v2.5.0 | v1.6.0 | v1.6.0 |
 | v2.4.3 | v1.5.0 | v1.5.0 |
 | v2.4.2 | v1.5.0 | v1.5.0 |
 | v2.4.1 | v1.5.0 | v1.5.0 |
 | v2.4.0 | v1.5.0 | v1.5.0 |
 | v2.3.3 | v1.4.1 | v1.4.1 |
 | v2.3.2 | v1.4.0 | v1.4.0 |
 | v2.3.1 | v1.4.0 | v1.4.0 |
 | v2.3.0 | v1.4.0 | v1.4.0 |
 | v2.2.0 | v1.3.0 | v1.3.0 |
 | v2.1.1 | v1.2.1 | v1.2.2 |
 | v2.1.0 | v1.2.1 | v1.2.2 |
 | v2.0.5 | v1.1.0 | v1.1.0 |
 | v2.0.4 | v1.1.0 | v1.1.0 |
--- a/docs/changelog/introduction.mdx
+++ b/docs/changelog/introduction.mdx
--- a/docs/docs.json
+++ b/docs/docs.json
@ -2,24 +2,10 @@
  "$schema": "https://mintlify.com/docs.json",
  "theme": "mint",
  "name": "Honcho",
  "redirects": [
    {
      "source": "/",
      "destination": "/v3/documentation/introduction/overview"
    },
    {
      "source": "/v3/guides/integrations/claudecode",
      "destination": "/v3/guides/integrations/claude-code"
    },
    {
      "source": "/v3/documentation/features/advanced/representation-scopes",
      "destination": "/v3/documentation/features/advanced/directional-representations"
    }
  ],
  "colors": {
-    "primary": "#66AAFF",
+    "primary": "#FF5A7E",
-    "dark": "#151E27",
+    "light": "#FF5A7E",
-    "light": "#86BCF2"
+    "dark": "#FF5A7E"
  },
  "favicon": "/favicon.svg",
  "contextual": {
@ -28,257 +14,9 @@
  "navigation": {
    "versions": [
      {
-        "version": "v3.1.1",
+        "version": "v2.0.4",
        "api": {
-          "openapi": ["v3/openapi.json"]
+          "openapi": ["openapi.documented.yml"]
        },
        "tabs": [
          {
            "tab": "Documentation",
            "groups": [
              {
                "group": "Introduction",
                "pages": [
                  "v3/documentation/introduction/overview",
                  "v3/documentation/introduction/quickstart",
                  "v3/documentation/introduction/vibecoding"
                ]
              },
              {
                "group": "Core Concepts",
                "pages": [
                  "v3/documentation/core-concepts/architecture",
                  "v3/documentation/core-concepts/reasoning",
                  "v3/documentation/core-concepts/representation",
                  "v3/documentation/core-concepts/design-patterns"
                ]
              },
              {
                "group": "Features",
                "pages": [
                  "v3/documentation/features/storing-data",
                  "v3/documentation/features/get-context",
                  "v3/documentation/features/chat",
                  {
                    "group": "Advanced",
                    "pages": [
                      "v3/documentation/features/advanced/overview",
                      "v3/documentation/features/advanced/reasoning-configuration",
                      "v3/documentation/features/advanced/summarizer",
                      "v3/documentation/features/advanced/peer-card",
                      "v3/documentation/features/advanced/directional-representations",
                      "v3/documentation/features/advanced/scopes",
                      "v3/documentation/features/advanced/dreaming",
                      "v3/documentation/features/advanced/queue-status",
                      "v3/documentation/features/advanced/webhooks",
                      "v3/documentation/features/advanced/search",
                      "v3/documentation/features/advanced/using-filters",
                      "v3/documentation/features/advanced/structured-outputs",
                      "v3/documentation/features/advanced/streaming-response",
                      "v3/documentation/features/advanced/file-uploads",
                      "v3/documentation/features/advanced/deleting-data"
                    ]
                  }
                ]
              },
              {
                "group": "Reference",
                "pages": [
                  "v3/documentation/reference/platform",
                  "v3/documentation/reference/sdk",
                  "v3/documentation/reference/cli"
                ]
              }
            ]
          },
          {
            "tab": "Guides",
            "groups": [
              {
                "group": "Overview",
                "pages": ["v3/guides/overview"]
              },
              {
                "group": "Integrations",
                "pages": [
                  "v3/guides/integrations/claude-code",
                  "v3/guides/integrations/opencode",
                  "v3/guides/integrations/codex",
                  "v3/guides/integrations/deepseek-harness",
                  "v3/guides/integrations/vercel-ai-sdk",
                  "v3/guides/integrations/crewai",
                  "v3/guides/integrations/langgraph",
                  "v3/guides/integrations/mcp",
                  "v3/guides/integrations/n8n",
                  "v3/guides/integrations/openclaw",
                  "v3/guides/integrations/hermes",
                  "v3/guides/integrations/zo-computer",
                  "v3/guides/integrations/paperclip",
                  "v3/guides/integrations/sillytavern"
                ]
              },
              {
                "group": "Tutorials",
                "pages": [
                  "v3/guides/recipes/unified-memory-setup",
                  "v3/guides/discord",
                  "v3/guides/granola",
                  "v3/guides/telegram",
                  "v3/guides/integrations/reachy-mini",
                  "v3/guides/gmail"
                ]
              },
              {
                "group": "Community Integrations",
                "pages": [
                  "v3/guides/community/agent0",
                  "v3/guides/community/pi-honcho-memory"
                ]
              },
              {
                "group": "Migrations",
                "pages": ["v3/guides/migrations/mem0"]
              }
            ]
          },
          {
            "tab": "Open Source",
            "groups": [
              {
                "group": "Self-Hosting",
                "pages": [
                  "v3/contributing/self-hosting",
                  "v3/contributing/configuration",
                  "v3/contributing/changing-embeddings",
                  "v3/contributing/troubleshooting"
                ]
              },
              {
                "group": "Contributing",
                "pages": [
                  "v3/contributing/guidelines",
                  "v3/contributing/license"
                ]
              }
            ]
          },
          {
            "tab": "API Reference",
            "groups": [
              {
                "group": "API Documentation",
                "pages": ["v3/api-reference/introduction"]
              },
              {
                "group": "workspaces",
                "pages": [
                  "v3/api-reference/endpoint/workspaces/get-or-create-workspace",
                  "v3/api-reference/endpoint/workspaces/get-all-workspaces",
                  "v3/api-reference/endpoint/workspaces/update-workspace",
                  "v3/api-reference/endpoint/workspaces/delete-workspace",
                  "v3/api-reference/endpoint/workspaces/search-workspace",
                  "v3/api-reference/endpoint/workspaces/get-queue-status",
                  "v3/api-reference/endpoint/workspaces/schedule-dream"
                ]
              },
              {
                "group": "peers",
                "pages": [
                  "v3/api-reference/endpoint/peers/get-peers",
                  "v3/api-reference/endpoint/peers/get-or-create-peer",
                  "v3/api-reference/endpoint/peers/update-peer",
                  "v3/api-reference/endpoint/peers/get-sessions-for-peer",
                  "v3/api-reference/endpoint/peers/chat",
                  "v3/api-reference/endpoint/peers/get-representation",
                  "v3/api-reference/endpoint/peers/get-peer-card",
                  "v3/api-reference/endpoint/peers/set-peer-card",
                  "v3/api-reference/endpoint/peers/get-peer-context",
                  "v3/api-reference/endpoint/peers/search-peer"
                ]
              },
              {
                "group": "sessions",
                "pages": [
                  "v3/api-reference/endpoint/sessions/get-or-create-session",
                  "v3/api-reference/endpoint/sessions/get-sessions",
                  "v3/api-reference/endpoint/sessions/update-session",
                  "v3/api-reference/endpoint/sessions/delete-session",
                  "v3/api-reference/endpoint/sessions/clone-session",
                  "v3/api-reference/endpoint/sessions/get-session-peers",
                  "v3/api-reference/endpoint/sessions/set-session-peers",
                  "v3/api-reference/endpoint/sessions/add-peers-to-session",
                  "v3/api-reference/endpoint/sessions/remove-peers-from-session",
                  "v3/api-reference/endpoint/sessions/get-peer-config",
                  "v3/api-reference/endpoint/sessions/set-peer-config",
                  "v3/api-reference/endpoint/sessions/get-session-context",
                  "v3/api-reference/endpoint/sessions/get-session-summaries",
                  "v3/api-reference/endpoint/sessions/search-session"
                ]
              },
              {
                "group": "scopes",
                "pages": [
                  "v3/api-reference/endpoint/scopes/get-or-create-scope",
                  "v3/api-reference/endpoint/scopes/get-scopes",
                  "v3/api-reference/endpoint/scopes/get-scope",
                  "v3/api-reference/endpoint/scopes/add-sessions-to-scope",
                  "v3/api-reference/endpoint/scopes/get-scope-sessions",
                  "v3/api-reference/endpoint/scopes/remove-session-from-scope",
                  "v3/api-reference/endpoint/scopes/get-scope-status"
                ]
              },
              {
                "group": "messages",
                "pages": [
                  "v3/api-reference/endpoint/messages/create-messages-for-session",
                  "v3/api-reference/endpoint/messages/get-messages",
                  "v3/api-reference/endpoint/messages/get-message",
                  "v3/api-reference/endpoint/messages/update-message",
                  "v3/api-reference/endpoint/messages/create-messages-with-file"
                ]
              },
              {
                "group": "conclusions",
                "pages": [
                  "v3/api-reference/endpoint/conclusions/create-conclusions",
                  "v3/api-reference/endpoint/conclusions/list-conclusions",
                  "v3/api-reference/endpoint/conclusions/query-conclusions",
                  "v3/api-reference/endpoint/conclusions/delete-conclusion"
                ]
              },
              {
                "group": "webhooks",
                "pages": [
                  "v3/api-reference/endpoint/webhooks/list-webhook-endpoints",
                  "v3/api-reference/endpoint/webhooks/get-or-create-webhook-endpoint",
                  "v3/api-reference/endpoint/webhooks/delete-webhook-endpoint",
                  "v3/api-reference/endpoint/webhooks/test-emit"
                ]
              },
              {
                "group": "miscellaneous",
                "pages": ["v3/api-reference/endpoint/keys/create-key"]
              }
            ]
          },
          {
            "tab": "Changelog",
            "groups": [
              {
                "group": "Overview",
                "pages": [
                  "changelog/introduction",
                  "changelog/compatibility-guide"
                ]
              }
            ]
          }
        ]
      },
      {
        "version": "v2.5.1",
        "api": {
          "openapi": ["v2/openapi.json"]
        },
        "tabs": [
          {
@ -288,34 +26,23 @@
                "group": "Introduction",
                "pages": [
                  "v2/documentation/introduction/overview",
-                  "v2/documentation/introduction/quickstart",
+                  "v2/documentation/introduction/quickstart"
                  "v2/documentation/introduction/vibecoding"
                ]
              },
              {
                "group": "Core Concepts",
                "pages": [
                  "v2/documentation/core-concepts/glossary",
                  "v2/documentation/core-concepts/architecture",
-                  "v2/documentation/core-concepts/features/storing-data",
+                  "v2/documentation/core-concepts/features"
                  "v2/documentation/core-concepts/features/dialectic-endpoint",
                  "v2/documentation/core-concepts/features/get-context",
                  "v2/documentation/core-concepts/features/search",
                  "v2/documentation/core-concepts/features/working-rep",
                  "v2/documentation/core-concepts/features/streaming-response",
                  "v2/documentation/core-concepts/features/using-filters",
                  "v2/documentation/core-concepts/features/file-uploads",
                  "v2/documentation/core-concepts/features/queue-status",
                  "v2/documentation/core-concepts/features/local-vs-global",
                  "v2/documentation/core-concepts/configuration",
                  "v2/documentation/core-concepts/summarizer",
                  "v2/documentation/core-concepts/glossary"
                ]
              },
              {
-                "group": "Reference",
+                "group": "Tutorial",
                "pages": [
-                  "v2/documentation/reference/platform",
+                  "v2/documentation/tutorial/platform",
-                  "v2/documentation/reference/sdk"
+                  "v2/documentation/tutorial/guided-tutorial",
                  "v2/documentation/tutorial/sdk"
                ]
              }
            ]
@ -325,26 +52,39 @@
            "groups": [
              {
                "group": "Getting Started",
                "pages": ["v2/guides/overview"]
              },
              {
                "group": "Migrations",
                "pages": ["v2/migrations/from-mem0"]
              },
              {
                "group": "Integrations",
                "pages": [
-                  "v2/integrations/crewai",
+                  "v2/guides/overview",
-                  "v2/integrations/langgraph",
+                  "v2/guides/ai-assisted-setup",
-                  "v2/integrations/mcp"
+                  "v2/guides/mcp"
                ]
              },
              {
                "group": "Application Interfaces",
                "pages": ["v2/guides/discord", "v2/guides/telegram"]
              },
              {
                "group": "Design Patterns",
                "pages": [
-                  "v2/guides/discord",
+                  "v2/guides/dialectic-endpoint",
-                  "v2/guides/n8n",
+                  "v2/guides/get-context",
-                  "v2/guides/telegram"
+                  "v2/guides/search",
                  "v2/guides/working-rep",
                  "v2/guides/streaming-response",
                  "v2/guides/using-filters"
                ]
              }
            ]
          },
          {
            "tab": "Contributing",
            "groups": [
              {
                "group": "Contributing",
                "pages": [
                  "v2/contributing/guidelines",
                  "v2/contributing/self-hosting",
                  "v2/contributing/configuration",
                  "v2/contributing/license"
                ]
              }
            ]
@ -362,10 +102,8 @@
                  "v2/api-reference/endpoint/workspaces/get-or-create-workspace",
                  "v2/api-reference/endpoint/workspaces/get-all-workspaces",
                  "v2/api-reference/endpoint/workspaces/update-workspace",
                  "v2/api-reference/endpoint/workspaces/delete-workspace",
                  "v2/api-reference/endpoint/workspaces/search-workspace",
-                  "v2/api-reference/endpoint/workspaces/get-deriver-status",
+                  "v2/api-reference/endpoint/workspaces/get-deriver-status"
                  "v2/api-reference/endpoint/workspaces/trigger-dream"
                ]
              },
              {
@ -376,10 +114,9 @@
                  "v2/api-reference/endpoint/peers/update-peer",
                  "v2/api-reference/endpoint/peers/get-sessions-for-peer",
                  "v2/api-reference/endpoint/peers/chat",
                  "v2/api-reference/endpoint/peers/create-messages-for-peer",
                  "v2/api-reference/endpoint/peers/get-messages-for-peer",
                  "v2/api-reference/endpoint/peers/get-working-representation",
                  "v2/api-reference/endpoint/peers/get-peer-card",
                  "v2/api-reference/endpoint/peers/set-peer-card",
                  "v2/api-reference/endpoint/peers/get-peer-context",
                  "v2/api-reference/endpoint/peers/search-peer"
                ]
              },
@ -398,7 +135,6 @@
                  "v2/api-reference/endpoint/sessions/get-peer-config",
                  "v2/api-reference/endpoint/sessions/set-peer-config",
                  "v2/api-reference/endpoint/sessions/get-session-context",
                  "v2/api-reference/endpoint/sessions/get-session-summaries",
                  "v2/api-reference/endpoint/sessions/search-session"
                ]
              },
@ -408,47 +144,23 @@
                  "v2/api-reference/endpoint/messages/create-messages-for-session",
                  "v2/api-reference/endpoint/messages/get-messages",
                  "v2/api-reference/endpoint/messages/get-message",
-                  "v2/api-reference/endpoint/messages/update-message",
+                  "v2/api-reference/endpoint/messages/update-message"
                  "v2/api-reference/endpoint/messages/create-messages-with-file"
                ]
              },
              {
-                "group": "observations",
+                "group": "keys",
-                "pages": [
+                "pages": ["v2/api-reference/endpoint/keys/create-key"]
                  "v2/api-reference/endpoint/observations/create-observations",
                  "v2/api-reference/endpoint/observations/list-observations",
                  "v2/api-reference/endpoint/observations/query-observations",
                  "v2/api-reference/endpoint/observations/delete-observation"
                ]
              },
              {
                "group": "webhooks",
                "pages": [
                  "v2/api-reference/endpoint/webhooks/list-webhook-endpoints",
                  "v2/api-reference/endpoint/webhooks/get-or-create-webhook-endpoint",
                  "v2/api-reference/endpoint/webhooks/delete-webhook-endpoint",
                  "v2/api-reference/endpoint/webhooks/test-emit"
                ]
              },
              {
                "group": "miscellaneous",
                "pages": [
                  "v2/api-reference/endpoint/keys/create-key",
                  "v2/api-reference/endpoint/metrics"
                ]
              }
            ]
          },
          {
-            "tab": "Contributing",
+            "tab": "Changelog",
            "groups": [
              {
-                "group": "Contributing",
+                "group": "Overview",
                "pages": [
-                  "v2/contributing/guidelines",
+                  "changelog/introduction",
-                  "v2/contributing/self-hosting",
+                  "changelog/compatibility-guide"
                  "v2/contributing/configuration",
                  "v2/contributing/license"
                ]
              }
            ]
@ -587,10 +299,41 @@
                ]
              }
            ]
-          }
+          },
          {
            "tab": "Changelog",
            "groups": [
              {
                "group": "Overview",
                "pages": [
                  "changelog/introduction",
                  "changelog/compatibility-guide"
                ]
              }
            ]
          }
        ]
      }
    ],
    "global": {
      "anchors": [
        {
          "anchor": "Managed Platform",
          "href": "https://app.honcho.dev",
          "icon": "book-open-cover"
        },
        {
          "anchor": "Community",
          "href": "https://discord.gg/honcho",
          "icon": "discord"
        },
        {
          "anchor": "Blog",
          "href": "https://blog.plasticlabs.ai",
          "icon": "newspaper"
        }
      ]
    }
  },
  "logo": {
    "light": "/logo/honcho-dark.svg",
@ -604,16 +347,14 @@
  },
  "footer": {
    "socials": {
-      "twitter": "https://x.com/honchodotdev",
+      "twitter": "https://twitter.com/plastic_labs",
-      "github": "https://github.com/plastic-labs/honcho",
+      "github": "https://github.com/plastic-labs",
-      "discord": "https://discord.gg/honcho",
+      "linkedin": "https://www.linkedin.com/company/plasticlabs"
      "linkedin": "https://www.linkedin.com/company/plasticlabs",
      "youtube": "https://www.youtube.com/@plasticlabs"
    }
  },
  "integrations": {
-    "gtm": {
+    "posthog": {
-      "tagId": "GTM-NSPT9PJF"
+      "apiKey": "phc_1yrzzcgywqXGcerkkI4g7C0YfyPMcAKNOOvGcjTCiUk"
    }
  }
 }
--- a/docs/images/agent_hierarchy.png
+++ b/docs/images/agent_hierarchy.png
--- a/docs/images/app-screenshots/api-keys-small.png
+++ b/docs/images/app-screenshots/api-keys-small.png
--- a/docs/images/app-screenshots/api-keys.png
+++ b/docs/images/app-screenshots/api-keys.png
--- a/docs/images/app-screenshots/api-playground.png
+++ b/docs/images/app-screenshots/api-playground.png
--- a/docs/images/app-screenshots/chat-endpoint.png
+++ b/docs/images/app-screenshots/chat-endpoint.png
--- a/docs/images/app-screenshots/create-message.png
+++ b/docs/images/app-screenshots/create-message.png
--- a/docs/images/app-screenshots/create-workspace.png
+++ b/docs/images/app-screenshots/create-workspace.png
--- a/docs/images/app-screenshots/explore-honcho.png
+++ b/docs/images/app-screenshots/explore-honcho.png
--- a/docs/images/app-screenshots/get-context.png
+++ b/docs/images/app-screenshots/get-context.png
--- a/docs/images/app-screenshots/get-started
+++ b/docs/images/app-screenshots/get-started
--- a/docs/images/app-screenshots/get-started-copy.png
+++ b/docs/images/app-screenshots/get-started-copy.png
--- a/docs/images/app-screenshots/machine-status.png
+++ b/docs/images/app-screenshots/machine-status.png
--- a/docs/images/app-screenshots/members-dashboard.png
+++ b/docs/images/app-screenshots/members-dashboard.png
--- a/docs/images/app-screenshots/peer-dash.png
+++ b/docs/images/app-screenshots/peer-dash.png
--- a/docs/images/app-screenshots/peer-utilities.png
+++ b/docs/images/app-screenshots/peer-utilities.png
--- a/docs/images/app-screenshots/performance-analytics.png
+++ b/docs/images/app-screenshots/performance-analytics.png
--- a/docs/images/app-screenshots/session-dash.png
+++ b/docs/images/app-screenshots/session-dash.png
--- a/docs/images/app-screenshots/session-utilities.png
+++ b/docs/images/app-screenshots/session-utilities.png
--- a/docs/images/app-screenshots/status-page.png
+++ b/docs/images/app-screenshots/status-page.png
--- a/docs/images/app-screenshots/upgrade-honcho.png
+++ b/docs/images/app-screenshots/upgrade-honcho.png
--- a/docs/images/app-screenshots/webhooks-create.png
+++ b/docs/images/app-screenshots/webhooks-create.png
--- a/docs/images/app-screenshots/webhooks-page.png
+++ b/docs/images/app-screenshots/webhooks-page.png
--- a/docs/images/app-screenshots/workspace-dash.png
+++ b/docs/images/app-screenshots/workspace-dash.png
--- a/docs/images/architecture.png
+++ b/docs/images/architecture.png
--- a/docs/images/basic_honcho_flowchart.png
+++ b/docs/images/basic_honcho_flowchart.png
--- a/docs/images/honcho-system-diagram.png
+++ b/docs/images/honcho-system-diagram.png
--- a/docs/images/integrations/n8n/Bearer_auth_cred.png
+++ b/docs/images/integrations/n8n/Bearer_auth_cred.png
--- a/docs/images/integrations/n8n/Http_request_core.png
+++ b/docs/images/integrations/n8n/Http_request_core.png
--- a/docs/images/integrations/n8n/complete_workflow.png
+++ b/docs/images/integrations/n8n/complete_workflow.png
--- a/docs/images/local-vs-global-reps.png
+++ b/docs/images/local-vs-global-reps.png
--- a/docs/images/observe_config.png
+++ b/docs/images/observe_config.png
--- a/docs/images/overview/honcho-overview-dark.svg
+++ b/docs/images/overview/honcho-overview-dark.svg
--- a/docs/images/overview/honcho-overview-light.png
+++ b/docs/images/overview/honcho-overview-light.png
--- a/docs/images/overview/honcho-overview-light.svg
+++ b/docs/images/overview/honcho-overview-light.svg
--- a/docs/images/overview/honcho-overview-no-background.png
+++ b/docs/images/overview/honcho-overview-no-background.png
--- a/docs/images/overview/honcho-overview.svg
+++ b/docs/images/overview/honcho-overview.svg
--- a/docs/images/perspectives.jpeg
+++ b/docs/images/perspectives.jpeg
--- a/docs/images/reasoning.png
+++ b/docs/images/reasoning.png
--- a/docs/logo/honcho-dark.svg
+++ b/docs/logo/honcho-dark.svg
@ -7,7 +7,7 @@
      }
      .cls-2 {
-        fill: #1A1C1E;
+        fill: #111444;
      }
      .cls-2, .cls-3 {
--- a/docs/logo/honcho-light.svg
+++ b/docs/logo/honcho-light.svg
@ -7,7 +7,7 @@
      }
      .cls-2 {
-        fill: #B5D9FD;
+        fill: #fff;
        stroke-width: 0px;
      }
    </style>
--- a/docs/package.json
+++ b/docs/package.json
@ -5,15 +5,17 @@
  "main": ".pnp.js",
  "scripts": {
    "dev": "mint dev",
-    "openapi": "npx @mintlify/scraping openapi-file v3/openapi.json -o v3/api-reference/endpoint",
+    "openapi": "npx @mintlify/scraping openapi-file openapi.json -o api-reference/endpoint",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
-    "@mintlify/scraping": "^4.0.467"
+    "@mintlify/scraping": "^4.0.284",
    "honcho-ai": "^0.0.11",
    "mintlify": "^4.1.96"
  },
  "devDependencies": {
-    "mint": "^4.2.204"
+    "mint": "^4.1.96"
  }
 }
--- a/docs/pnpm-lock.yaml
+++ b/docs/pnpm-lock.yaml
--- a/docs/posthog-consent.js
+++ b/docs/posthog-consent.js
@ -1,69 +0,0 @@
 // Loads PostHog only when the CookieConsent cookie grants Statistics; the
 // cookie is host-scoped, so a landing-page answer covers the docs.
 ;(function () {
  var KEY = 'phc_1yrzzcgywqXGcerkkI4g7C0YfyPMcAKNOOvGcjTCiUk'
  var loaded = false
  function granted() {
    var m = document.cookie.match(/(?:^|;\s*)CookieConsent=([^;]*)/)
    if (!m) return false
    var v = decodeURIComponent(m[1])
    // "-1" is Cookiebot's consent-not-required marker.
    return v === '-1' || /statistics\s*:\s*true/.test(v)
  }
  function loadPosthog() {
    if (loaded) return
    loaded = true
    var s = document.createElement('script')
    s.src = 'https://us-assets.i.posthog.com/static/array.js'
    s.async = true
    s.onerror = function () {
      loaded = false
    }
    s.onload = function () {
      // Consent withdrawn while array.js was downloading: skip init, allow a retry on re-grant.
      if (!granted()) {
        loaded = false
        return
      }
      window.posthog.init(KEY, {
        api_host: 'https://us.i.posthog.com',
        ui_host: 'https://us.posthog.com',
        cross_subdomain_cookie: true,
        person_profiles: 'identified_only',
        capture_pageview: 'history_change',
      })
    }
    document.head.appendChild(s)
  }
  function sync() {
    if (granted()) {
      if (!loaded) {
        loadPosthog()
      } else if (
        window.posthog &&
        window.posthog.has_opted_out_capturing &&
        window.posthog.has_opted_out_capturing()
      ) {
        window.posthog.opt_in_capturing()
      }
      return
    }
    // Withdrawal mid-session: an already running instance must stop.
    if (loaded && window.posthog && window.posthog.opt_out_capturing) {
      window.posthog.opt_out_capturing()
    }
  }
  sync()
  var events = [
    'CookiebotOnConsentReady',
    'CookiebotOnAccept',
    'CookiebotOnDecline',
  ]
  for (var i = 0; i < events.length; i++) {
    window.addEventListener(events[i], sync)
  }
 })()
--- a/docs/snippets/cli-commands.mdx
+++ b/docs/snippets/cli-commands.mdx
@ -1,652 +0,0 @@
 {/*
  GENERATED by honcho-cli/scripts/generate_cli_docs.py — do not edit.
  Re-generate with: uv run --package honcho-cli python honcho-cli/scripts/generate_cli_docs.py
  Source of truth: honcho-cli/src/honcho_cli/commands/
 */}
 ## honcho conclusion
 List, search, create, and delete peer conclusions (Honcho's memory atoms).
 <AccordionGroup>
 <Accordion title="create">
 Create a conclusion.
 ```bash
 honcho conclusion create <content>
 ```
 <ParamField path="content" type="string" required />
 <ParamField path="--observer" type="string">
  Observer peer ID.
 </ParamField>
 <ParamField path="--observed" type="string">
  Observed peer ID.
 </ParamField>
 <ParamField path="--session" type="string">
  Session context. Short alias: `-s`.
 </ParamField>
 </Accordion>
 <Accordion title="delete">
 Delete a conclusion.
 ```bash
 honcho conclusion delete <conclusion_id>
 ```
 <ParamField path="conclusion_id" type="string" required />
 <ParamField path="--observer" type="string">
  Observer peer ID.
 </ParamField>
 <ParamField path="--observed" type="string">
  Observed peer ID.
 </ParamField>
 <ParamField path="--yes" type="boolean">
  Skip confirmation. Short alias: `-y`.
 </ParamField>
 </Accordion>
 <Accordion title="list">
 List conclusions.
 ```bash
 honcho conclusion list
 ```
 <ParamField path="--observer" type="string">
  Observer peer ID.
 </ParamField>
 <ParamField path="--observed" type="string">
  Observed peer ID.
 </ParamField>
 <ParamField path="--limit" type="number" default="10">
  Max results.
 </ParamField>
 </Accordion>
 <Accordion title="search">
 Semantic search over conclusions.
 ```bash
 honcho conclusion search <query>
 ```
 <ParamField path="query" type="string" required />
 <ParamField path="--observer" type="string">
  Observer peer ID.
 </ParamField>
 <ParamField path="--observed" type="string">
  Observed peer ID.
 </ParamField>
 <ParamField path="--top-k" type="number" default="10">
  Max results.
 </ParamField>
 </Accordion>
 </AccordionGroup>
 ## honcho config
 Inspect CLI configuration.
 ```bash
 honcho config
 ```
 ## honcho doctor
 Verify config and connectivity. Scope with -w / -p to check workspace, peer, and queue health.
 ```bash
 honcho doctor
 ```
 ## honcho help
 Show help message.
 ```bash
 honcho help
 ```
 ## honcho init
 Set API key and server URL in ~/.honcho/config.json.
 Press Enter to keep the current value or type a replacement.
 Workspace / peer / session scoping is per-command via -w / -p / -s
 or HONCHO_* env vars — never persisted.
 ```bash
 honcho init
 ```
 <ParamField path="--api-key" type="string">
  API key (admin JWT).
 </ParamField>
 <ParamField path="--base-url" type="string">
  Honcho API URL (e.g. https://api.honcho.dev, http://localhost:8000).
 </ParamField>
 ## honcho message
 List, create, and get messages within a session.
 <AccordionGroup>
 <Accordion title="create">
 Create a message in a session.
 ```bash
 honcho message create <content>
 ```
 <ParamField path="content" type="string" required />
 <ParamField path="--peer" type="string" required>
  Peer ID of the message sender. Short alias: `-p`.
 </ParamField>
 <ParamField path="--metadata" type="string">
  JSON metadata to associate with the message.
 </ParamField>
 <ParamField path="--session" type="string">
  Session ID. Short alias: `-s`.
 </ParamField>
 </Accordion>
 <Accordion title="get">
 Get a single message by ID.
 ```bash
 honcho message get <message_id>
 ```
 <ParamField path="message_id" type="string" required />
 <ParamField path="--session" type="string">
  Session ID. Short alias: `-s`.
 </ParamField>
 </Accordion>
 <Accordion title="list">
 List messages in a session. Scoped to a peer with -p.
 ```bash
 honcho message list [<session_id>]
 ```
 <ParamField path="session_id" type="string" />
 <ParamField path="--last" type="number" default="20">
  Number of recent messages.
 </ParamField>
 <ParamField path="--reverse" type="boolean">
  Show oldest first (default is newest first).
 </ParamField>
 <ParamField path="--brief" type="boolean">
  Show only IDs, peer, token count, and created_at (no content).
 </ParamField>
 <ParamField path="--peer" type="string">
  Filter by peer ID. Short alias: `-p`.
 </ParamField>
 </Accordion>
 </AccordionGroup>
 ## honcho peer
 List, create, chat with, search, and manage peers and their representations.
 <AccordionGroup>
 <Accordion title="card">
 Get raw peer card content.
 ```bash
 honcho peer card [<peer_id>]
 ```
 <ParamField path="peer_id" type="string" />
 <ParamField path="--target" type="string">
  Target peer for relationship card.
 </ParamField>
 </Accordion>
 <Accordion title="chat">
 Query the dialectic about a peer.
 ```bash
 honcho peer chat <query>
 ```
 <ParamField path="query" type="string" required />
 <ParamField path="--target" type="string">
  Target peer for perspective.
 </ParamField>
 <ParamField path="--reasoning" type="string">
  Reasoning level: minimal, low, medium, high, max. Short alias: `-r`.
 </ParamField>
 </Accordion>
 <Accordion title="create">
 Create or get a peer.
 ```bash
 honcho peer create <peer_id>
 ```
 <ParamField path="peer_id" type="string" required />
 <ParamField path="--observe-me" type="boolean">
  Whether Honcho will form a representation of this peer. Negate with `--no-observe-me`.
 </ParamField>
 <ParamField path="--metadata" type="string">
  JSON metadata to associate with the peer.
 </ParamField>
 </Accordion>
 <Accordion title="get-metadata">
 Get metadata for a peer.
 ```bash
 honcho peer get-metadata [<peer_id>]
 ```
 <ParamField path="peer_id" type="string" />
 </Accordion>
 <Accordion title="inspect">
 Inspect a peer: card, session count, recent conclusions.
 ```bash
 honcho peer inspect [<peer_id>]
 ```
 <ParamField path="peer_id" type="string" />
 </Accordion>
 <Accordion title="list">
 List all peers in the workspace.
 ```bash
 honcho peer list
 ```
 </Accordion>
 <Accordion title="representation">
 Get the formatted representation for a peer.
 ```bash
 honcho peer representation [<peer_id>]
 ```
 <ParamField path="peer_id" type="string" />
 <ParamField path="--target" type="string">
  Target peer to get representation about.
 </ParamField>
 <ParamField path="--search-query" type="string">
  Semantic search query to filter conclusions.
 </ParamField>
 <ParamField path="--max-conclusions" type="number">
  Maximum number of conclusions to include.
 </ParamField>
 </Accordion>
 <Accordion title="search">
 Search a peer's messages.
 ```bash
 honcho peer search <query>
 ```
 <ParamField path="query" type="string" required />
 <ParamField path="--limit" type="number" default="10">
  Max results.
 </ParamField>
 </Accordion>
 <Accordion title="set-metadata">
 Set metadata for a peer.
 ```bash
 honcho peer set-metadata <metadata>
 ```
 <ParamField path="metadata" type="string" required />
 <ParamField path="--peer" type="string">
  Peer ID (uses default if omitted). Short alias: `-p`.
 </ParamField>
 </Accordion>
 </AccordionGroup>
 ## honcho session
 List, inspect, view, create, delete, and manage conversation sessions and their peers.
 <AccordionGroup>
 <Accordion title="add-peers">
 Add peers to a session.
 ```bash
 honcho session add-peers <session_id> <peer_ids>
 ```
 <ParamField path="session_id" type="string" required />
 <ParamField path="peer_ids" type="string" required />
 </Accordion>
 <Accordion title="context">
 Get session context (what an agent would see).
 ```bash
 honcho session context [<session_id>]
 ```
 <ParamField path="session_id" type="string" />
 <ParamField path="--tokens" type="number">
  Token budget.
 </ParamField>
 <ParamField path="--summary" type="boolean" default="true">
  Include summary. Negate with `--no-summary`.
 </ParamField>
 </Accordion>
 <Accordion title="create">
 Create or get a session.
 ```bash
 honcho session create <session_id>
 ```
 <ParamField path="session_id" type="string" required />
 <ParamField path="--peers" type="string">
  Comma-separated peer IDs to add to the session.
 </ParamField>
 <ParamField path="--metadata" type="string">
  JSON metadata to associate with the session.
 </ParamField>
 </Accordion>
 <Accordion title="delete">
 Delete a session and all its data. Destructive — requires --yes or interactive confirm.
 ```bash
 honcho session delete [<session_id>]
 ```
 <ParamField path="session_id" type="string" />
 <ParamField path="--yes" type="boolean">
  Skip confirmation. Short alias: `-y`.
 </ParamField>
 </Accordion>
 <Accordion title="get-metadata">
 Get metadata for a session.
 ```bash
 honcho session get-metadata [<session_id>]
 ```
 <ParamField path="session_id" type="string" />
 </Accordion>
 <Accordion title="inspect">
 Inspect a session: peers, message count, summaries, config.
 ```bash
 honcho session inspect [<session_id>]
 ```
 <ParamField path="session_id" type="string" />
 </Accordion>
 <Accordion title="list">
 List sessions in the workspace.
 ```bash
 honcho session list
 ```
 <ParamField path="--peer" type="string">
  Filter by peer. Short alias: `-p`.
 </ParamField>
 </Accordion>
 <Accordion title="peers">
 List peers in a session.
 ```bash
 honcho session peers [<session_id>]
 ```
 <ParamField path="session_id" type="string" />
 </Accordion>
 <Accordion title="remove-peers">
 Remove peers from a session.
 ```bash
 honcho session remove-peers <session_id> <peer_ids>
 ```
 <ParamField path="session_id" type="string" required />
 <ParamField path="peer_ids" type="string" required />
 </Accordion>
 <Accordion title="representation">
 Get the representation of a peer within a session.
 ```bash
 honcho session representation <peer_id> [<session_id>]
 ```
 <ParamField path="peer_id" type="string" required />
 <ParamField path="session_id" type="string" />
 <ParamField path="--target" type="string">
  Target peer (what peer_id knows about target).
 </ParamField>
 <ParamField path="--search-query" type="string">
  Semantic search query to filter conclusions.
 </ParamField>
 <ParamField path="--max-conclusions" type="number">
  Maximum number of conclusions to include.
 </ParamField>
 </Accordion>
 <Accordion title="search">
 Search messages in a session.
 ```bash
 honcho session search <query> [<session_id>]
 ```
 <ParamField path="query" type="string" required />
 <ParamField path="session_id" type="string" />
 <ParamField path="--limit" type="number" default="10">
  Max results.
 </ParamField>
 </Accordion>
 <Accordion title="set-metadata">
 Set metadata for a session.
 ```bash
 honcho session set-metadata [<session_id>]
 ```
 <ParamField path="session_id" type="string" />
 <ParamField path="--data" type="string" required>
  JSON metadata to set (e.g. '\{"key": "value"\}'). Short alias: `-d`.
 </ParamField>
 </Accordion>
 <Accordion title="summaries">
 Get session summaries (short + long).
 ```bash
 honcho session summaries [<session_id>]
 ```
 <ParamField path="session_id" type="string" />
 </Accordion>
 <Accordion title="view">
 View a session transcript as a chat log.
 Modes (pick one):
 - default / --last N: tail of the conversation (most recent N)
 - --page N [--size M]: page through the full transcript
 - --all: every message
 Paging follows the requested order: --page 1 starts at the oldest message,
 or the newest with --reverse.
 Human mode prints a row-delimited table. JSON mode emits the message list
 (same shape as message list).
 ```bash
 honcho session view [<session_id>]
 ```
 <ParamField path="session_id" type="string" />
 <ParamField path="--last" type="number">
  Show only the N most recent messages (default when no --page/--all: 50).
 </ParamField>
 <ParamField path="--page" type="number">
  1-indexed page of the full transcript. Use for page 2+.
 </ParamField>
 <ParamField path="--size" type="number">
  Messages per page; requires --page (1-100, default: 50).
 </ParamField>
 <ParamField path="--all" type="boolean">
  Show the full transcript (every page).
 </ParamField>
 <ParamField path="--reverse" type="boolean">
  Newest first (default is chronological: oldest at top).
 </ParamField>
 <ParamField path="--ids" type="boolean">
  Include message IDs in the transcript.
 </ParamField>
 <ParamField path="--peer" type="string">
  Filter by peer ID. Short alias: `-p`.
 </ParamField>
 </Accordion>
 </AccordionGroup>
 ## honcho start
 Start a local Honcho stack (API, deriver, Postgres, Redis).
 Requires Docker. Uses cloud LLM providers. Does not change the CLI's
 configured server URL — pass HONCHO_BASE_URL to talk to this stack.
 ``--setup basic`` or ``--setup advanced`` runs an interactive config wizard.
 ```bash
 honcho start
 ```
 <ParamField path="--profile" type="string" default="local">
  Local stack profile name.
 </ParamField>
 <ParamField path="--api-port" type="string">
  Host port for the API.
 </ParamField>
 <ParamField path="--db-port" type="string">
  Host port for Postgres.
 </ParamField>
 <ParamField path="--redis-port" type="string">
  Host port for Redis.
 </ParamField>
 <ParamField path="--setup" type="string">
  Interactive config wizard: basic (provider/model) or advanced (embeddings, deriver, dialectic, dreams, flush).
 </ParamField>
 <ParamField path="--image" type="string">
  Honcho image to pull and pin by digest (default: ghcr.io/plastic-labs/honcho:latest).
 </ParamField>
 <ParamField path="--timeout" type="string" default="180">
  Seconds to wait for /health after compose up.
 </ParamField>
 ## honcho status
 Show local stack endpoints and container health.
 With no ``--profile``, lists every stack under ``~/.honcho/profiles/``.
 ```bash
 honcho status
 ```
 <ParamField path="--profile" type="string">
  Limit to this profile. Omit to show every local stack.
 </ParamField>
 ## honcho stop
 Stop the local stack started by `honcho start`. Keeps data unless --wipe.
 ```bash
 honcho stop
 ```
 <ParamField path="--profile" type="string" default="local">
  Local stack profile name.
 </ParamField>
 <ParamField path="--wipe" type="boolean">
  Also delete volumes (Postgres data).
 </ParamField>
 ## honcho workspace
 List, create, inspect, delete, and search workspaces.
 <AccordionGroup>
 <Accordion title="create">
 Create or get a workspace.
 ```bash
 honcho workspace create <workspace_id>
 ```
 <ParamField path="workspace_id" type="string" required />
 <ParamField path="--metadata" type="string">
  JSON metadata to associate with the workspace.
 </ParamField>
 </Accordion>
 <Accordion title="delete">
 Delete a workspace. Use --dry-run first to see what will be deleted.
 Requires --yes to skip confirmation, or will prompt interactively.
 If sessions exist, requires --cascade to delete them first.
 ```bash
 honcho workspace delete <workspace_id>
 ```
 <ParamField path="workspace_id" type="string" required />
 <ParamField path="--yes" type="boolean">
  Skip confirmation prompt (for scripted/agent use). Short alias: `-y`.
 </ParamField>
 <ParamField path="--cascade" type="boolean">
  Delete all sessions before deleting the workspace.
 </ParamField>
 <ParamField path="--dry-run" type="boolean">
  Show what would be deleted without deleting.
 </ParamField>
 </Accordion>
 <Accordion title="inspect">
 Inspect a workspace: peers, sessions, config.
 ```bash
 honcho workspace inspect [<workspace_id>]
 ```
 <ParamField path="workspace_id" type="string" />
 </Accordion>
 <Accordion title="list">
 List all accessible workspaces.
 ```bash
 honcho workspace list
 ```
 </Accordion>
 <Accordion title="queue-status">
 Get queue processing status.
 ```bash
 honcho workspace queue-status
 ```
 <ParamField path="--observer" type="string">
  Filter by observer peer.
 </ParamField>
 <ParamField path="--sender" type="string">
  Filter by sender peer.
 </ParamField>
 </Accordion>
 <Accordion title="search">
 Search messages across workspace.
 ```bash
 honcho workspace search <query>
 ```
 <ParamField path="query" type="string" required />
 <ParamField path="--limit" type="number" default="10">
  Max results.
 </ParamField>
 </Accordion>
 </AccordionGroup>
--- a/Show More
+++ b/Show More