.agents/skills

@@ -1 +0,0 @@
-../skills

.claude/skills

@@ -1 +0,0 @@
-../skills

.env.template

@@ -1,6 +1,6 @@
 # Honcho Environment Variables Template
 # Copy this file to .env and fill in the appropriate values
-#
+# 
 # Required variables are marked with (REQUIRED)
 # Optional variables have default values and can be left commented out
 
@@ -8,35 +8,9 @@
 # Application Settings
 # =============================================================================
 LOG_LEVEL=INFO
-PERFORMANCE_LOG_FORMAT=compact # compact|rich
-# API server processes used by the Docker entrypoint (default: 1).
-# Each process owns a separate pool when connection pooling is enabled.
-# 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"
+FASTAPI_HOST=0.0.0.0
+FASTAPI_PORT=8000
+# SESSION_PEERS_LIMIT=10
 
 # =============================================================================
 # 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
-# dream consolidation. The server will fail to start without a provider configured.
-#
-# Quick start: set LLM_OPENAI_API_KEY below to use the built-in defaults.
-# Text-generation features default to transport = "openai" and
-# model = "gpt-5.4-mini". Embeddings default to transport = "openai" and
-# model = "text-embedding-3-small". For OpenAI-compatible proxies
-# (OpenRouter, Together, Fireworks, vLLM, Ollama, LiteLLM), override
-# MODEL_CONFIG__MODEL and MODEL_CONFIG__OVERRIDES__BASE_URL on each feature
-# section you want to route through that endpoint.
-# Models must support tool calling (function calling).
-#
-# Supported transports: openai, anthropic, gemini
-# Each transport picks up its API key from the corresponding LLM_*_API_KEY.
-# Base URLs are set per-module via MODEL_CONFIG__OVERRIDES__BASE_URL.
-#
-LLM_OPENAI_API_KEY=your-api-key-here
-# LLM_ANTHROPIC_API_KEY=
-# LLM_GEMINI_API_KEY=
+# OpenAI API key for embeddings
+LLM_OPENAI_API_KEY=your-openai-api-key-here
+
+# Anthropic API key for dialectic and deriver functionality
+LLM_ANTHROPIC_API_KEY=your-anthropic-api-key-here
+
+# Google API key for summarization (if using Gemini)
+# LLM_GEMINI_API_KEY=your-google-api-key-here
+
+# Groq API key for query generation (if using Groq)
+# LLM_GROQ_API_KEY=your-groq-api-key-here
+
+# Base URL for OpenAI Compatible Requests if you want to use a different provider
+# LLM_OPENAI_COMPATIBLE_BASE_URL=
+# LLM_OPENAI_COMPATIBLE_API_KEY=
 
 # =============================================================================
 # LLM Configuration
 # =============================================================================
 # Global LLM settings
-# LLM_DEFAULT_MAX_TOKENS=2500
-# LLM_MAX_TOOL_OUTPUT_CHARS=10000  # Max chars for tool output (~2500 tokens)
-# LLM_MAX_MESSAGE_CONTENT_CHARS=2000  # Max chars per message in tool results
+# LLM_DEFAULT_MAX_TOKENS=1000
+# LLM_DEFAULT_TEMPERATURE=0.0
+
+# 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_MODEL_CONFIG__TEMPERATURE=
-# DERIVER_MODEL_CONFIG__THINKING_EFFORT=minimal
-# 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=
+# DERIVER_POLLING_SLEEP_INTERVAL_SECONDS=1.0
+# DERIVER_TOM_METHOD=single_prompt
+# DERIVER_USER_REPRESENTATION_METHOD=long_term
 
 # =============================================================================
-# Peer Card
+# History Settings
 # =============================================================================
-# PEER_CARD_ENABLED=true
-
-# =============================================================================
-# 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
+# HISTORY_MESSAGES_PER_SHORT_SUMMARY=20
+# HISTORY_MESSAGES_PER_LONG_SUMMARY=60
 
 # =============================================================================
 # 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

.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

.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

.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.
+
+📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛-->

.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

.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.
+
+📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛-->

.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

.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**
-<!-- If applicable, add screenshots or videos to help explain your problem. Redact secrets and production content. -->
+### **Media prove**
+<!-- 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.-->
 
 *
 

.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

.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.
+
+📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛-->

.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

.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.
+
+📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛-->

.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.-->
+
+*

.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.
+
+📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛📛-->

.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.

.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**
+

.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

.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 -->

.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,
-};

.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`);
-})();

.github/workflows/docker-build.yml

@@ -54,5 +54,5 @@ jobs:
         uses: actions/attest-build-provenance@v1.1.2
         with:
           subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
-          subject-digest: ${{ steps.push.outputs.digest }}
+          subject-digest: ${{ steps.push.outputs.digest }} 
           push-to-registry: true

.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"

.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"

.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 });

.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

.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

.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' });

.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"

.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"

.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

.github/workflows/staticanalysis.yml

@@ -1,9 +1,5 @@
 name: Static Analysis
-on:
-  push:
-    branches: [main]
-  pull_request:
-    branches: [main]
+on: [push]
 
 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

.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

.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
-  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' }}
+  test:
     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"
-
-      - name: Install bun
-        uses: oven-sh/setup-bun@v2
-
-      - name: Install TypeScript SDK dependencies
-        run: bun install
-        working-directory: sdks/typescript
+          python-version-file: "pyproject.toml"
 
       - 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_OPENAI_COMPATIBLE_BASE_URL: http://localhost:8000
-          DERIVER_PROVIDER: openai
-          DERIVER_MODEL: test
-          DIALECTIC_LEVELS__minimal__PROVIDER: openai
-          DIALECTIC_LEVELS__minimal__MODEL: test
-          DIALECTIC_LEVELS__minimal__THINKING_BUDGET_TOKENS: 0
-          DIALECTIC_LEVELS__minimal__MAX_TOOL_ITERATIONS: 2
-          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!"
+          LLM_DIALECTIC_PROVIDER: openai
+          LLM_DIALECTIC_MODEL: test
+          LLM_QUERY_GENERATION_PROVIDER: openai
+          LLM_QUERY_GENERATION_MODEL: test
+          LLM_TOM_INFERENCE_PROVIDER: openai
+          LLM_TOM_INFERENCE_MODEL: test
+          LLM_SUMMARY_PROVIDER: openai
+          LLM_SUMMARY_MODEL: test

.gitignore

@@ -1,14 +1,11 @@
-.worktrees/
 api/**/*.db
 api/data
 api/docker-compose.yml
 
 *.db
 data
-redis-data
-/docker-compose.yml
-/compose.yml
-
+docker-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

.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
-}

.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]

.python-version

@@ -1 +1 @@
-3.13
+3.11

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
-
-### 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
+## [2.0.4]
 
 ### 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
 

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
-- **Conclusions**: Create, list, query (semantic search), delete — the API-facing name for observations stored in `(observer, observed)` collections
-- **Keys**: Create scoped JWTs
-- **Webhooks**: Register endpoint, list, delete, test
+- **Messages**: Create (batch up to 100), list, get, update
+- **Keys**: Create scoped JWT tokens
 
 ### 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
-├── models.py            # SQLAlchemy ORM models (Workspace/Peer/Session/Message/
-│                        #   MessageEmbedding/Collection/Document/QueueItem/...)
-├── config.py            # Pydantic-settings configuration (very large; see README)
-├── db.py                # Engine + session/context management (request_context var)
-├── dependencies.py      # FastAPI DI (tracked_db, etc.)
-├── exceptions.py        # Custom exception types (HonchoException + subclasses)
-├── security.py          # JWT authentication
-├── embedding_client.py  # Embedding provider client (configurable dimensions
-│                        #   via EMBEDDING_MODEL_CONFIG__DIMENSIONS_MODE)
-├── schemas/             # Pydantic schemas
-│   ├── api.py            # Public API request/response schemas
-│   ├── configuration.py  # Per-resource configuration schemas
-│   └── internal.py       # Internal-only schemas (queue payloads, etc.)
-├── crud/                # Per-resource DB operations
-│   ├── collection.py, deriver.py, document.py, message.py
-│   ├── peer.py, peer_card.py, representation.py  (RepresentationManager)
-│   ├── session.py, webhook.py, workspace.py
-├── routers/             # FastAPI route handlers (all under /v3)
-│   ├── workspaces.py, peers.py (dialectic /chat lives here), sessions.py
-│   ├── messages.py, conclusions.py, keys.py, webhooks.py
-├── dialectic/           # Dialectic agent — runs inline per chat request
-│   ├── chat.py           # agentic_chat() / agentic_chat_stream()
-│   ├── 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
+├── main.py          # FastAPI app setup with middleware and exception handlers
+├── models.py        # SQLAlchemy ORM models with proper type annotations
+├── schemas.py       # Pydantic validation schemas for API
+├── crud.py          # Database operations
+├── dependencies.py  # Dependency injection (DB sessions)
+├── exceptions.py    # Custom exception types
+├── security.py      # JWT authentication
+├── agent.py         # Dialectic API implementation
+├── routers/         # API endpoints
+│   ├── workspaces.py
+│   ├── peers.py
+│   ├── sessions.py
+│   ├── messages.py
+│   └── keys.py
+├── deriver/         # Background processing system
+│   ├── consumer.py  # Message processing logic
+│   ├── queue.py     # Queue management
+│   └── tom/         # Theory of Mind implementations
+└── utils/           # Utilities
+    ├── history.py   # Session history management
+    ├── cache.py     # Caching utilities
+    └── model_client.py # LLM client abstraction
 ```
 
-- 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).
-- Use environment variables via python-dotenv (.env). Config precedence: env > .env > config.toml > defaults.
+- Tests in pytest with fixtures in tests/conftest.py
+- 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.
-2. **Multi-Peer Sessions**: Sessions can have multiple participants with different observation settings.
-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.
-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.
-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.
-6. **Dialectic reasoning tiers**: 5 levels (`minimal` → `max`); each level has its own model config and tool set (`minimal` uses a reduced toolset).
-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.
-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).
+1. **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. **Background Processing**: Async queue system for expensive operations
+4. **Provider Abstraction**: Model client supports multiple LLM providers
+5. **Scoped Authentication**: JWT tokens can be scoped to workspace, peer, or session level
+6. **Batch Operations**: Support for bulk message creation (up to 100 messages)
+7. **Session History**: Two-tier summarization (short every 20 messages, long every 60)
 
 ### Error Handling
 

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
-Honcho is put together, and what a mergeable pull request looks like.
+## Getting Started
 
-Honcho is a small team maintaining a project that gets more proposals than we can review.
-The rules below exist so that the work you do has somewhere to land — not to keep you out.
+Before you start contributing, please:
 
-## 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)
-- [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)
+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.
 
-## 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
-`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.
+### 1. Fork and Clone
 
-So, in order:
+1. Fork the repository on GitHub
+2. Clone your fork locally:
+   ```bash
+   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
+   ```
 
-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. Create a Branch
 
-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:
-
-  ```bash
-  gh issue view <N> --repo plastic-labs/honcho --json number,title,state,labels
-  ```
-
-  Stop if there is no issue number, if the issue is closed, or if `maintainer-approved` is
-  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
-  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
+Create a new branch for your feature or bug fix:
 
 ```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
-`commit-msg` hook:
+- `feature/description` - for new features
+- `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
-uv run pre-commit install \
-    --hook-type pre-commit \
-    --hook-type commit-msg \
-    --hook-type pre-push
-```
+2. Create a pull request on GitHub from your branch to the `main` branch
 
-At **commit** time: ruff lint and format, biome for TypeScript, basedpyright, bandit,
-markdownlint, and file hygiene. At **push** time: pytest, the alembic migration tests, and
-the SDK builds.
+3. Fill out the pull request template with:
+   - A clear description of what changes you've made
+   - 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
-`pre-push`, so the first time you see test failures may be well after you thought you were
-done.
+## Coding Standards
 
-Run them by hand at any time:
+### Python Code Style
 
-```bash
-uv run pre-commit run --all-files
-uv run pre-commit run ruff --all-files
-```
+- Follow [PEP 8](https://www.python.org/dev/peps/pep-0008/) style guidelines
+- Use [Black](https://black.readthedocs.io/) for code formatting (we may add this to CI in the future)
+- Use type hints where possible
+- Write docstrings for functions and classes using Google style docstrings
 
-Or the individual tools:
+### Code Organization
 
-```bash
-uv run ruff check src/
-uv run ruff format src/
-uv run basedpyright
-```
+- Keep functions focused and single-purpose
+- Use meaningful variable and function names
+- Add comments for complex logic
+- Follow existing patterns in the codebase
 
-### Tests
+### Testing
 
-Write tests for new functionality, in the directory under `tests/` that mirrors the code you
-changed. Which layer you need depends on what you touched:
-
-| What you changed | What to run |
-| --- | --- |
-| 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`.
+- Write unit tests for new functionality
+- Ensure existing tests pass before submitting
+- Use descriptive test names that explain what is being tested
+- Mock external dependencies appropriately
 
 ### Documentation
 
-Update docs in the same PR when you change a public surface: `/v3` endpoints, SDK exports,
-or anything in `config.toml` / settings. Docs live in `docs/v3/`, and new pages need an entry
-in `docs/docs.json` or they will not appear in the nav.
+- Update relevant documentation for new features
+- Include examples in docstrings where helpful
+- 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.
-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.
+We welcome various types of contributions:
 
-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.**
-If you have the choice, fork from your personal account.
+## Issue Reporting
 
-### 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,
-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.
+## Questions and Support
 
-Link the issue so the gate can see it: `Fixes #123` in the description, or the
-**Development** section of the sidebar. The gate reads GitHub's own resolved issue links, so
-either route works — but a bare `#123` mention is only a reference and does not count.
-
-### 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.
+- **General questions** - Join our [Discord](http://discord.gg/plasticlabs)
+- **Bug reports** - Use GitHub issues
+- **Feature requests** - Use GitHub issues with the feature request template
+- **Security issues** - Please email us privately rather than opening a public issue
 
 ## License
 
-By contributing to Honcho, you agree that your contributions will be licensed under the same
-[AGPL-3.0 License](./LICENSE) that covers the project.
+By contributing to Honcho, you agree that your contributions will be licensed under the same [AGPL-3.0 License](./LICENSE) that covers the project.
 
 Thank you for helping make Honcho better! 🫡

Dockerfile

@@ -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
-ENV PYTHONDONTWRITEBYTECODE=1
-ENV PYTHONUNBUFFERED=1
+# Install the project's dependencies using the lockfile and settings
+RUN --mount=type=cache,target=/root/.cache/uv \
+    --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:
-#   docker build --build-arg INSTALL_LANCEDB=true .
-ARG INSTALL_LANCEDB=false
+# Sync the project
 RUN --mount=type=cache,target=/root/.cache/uv \
-    if [ "$INSTALL_LANCEDB" = "true" ]; then \
-        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
+    uv sync --frozen --no-dev
 
 # 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"]
+

README.md

@@ -1,375 +1,101 @@
-<!-- markdownlint-disable MD033 -->
-<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 -->
+# 🫡 Honcho
 
----
-
-![Static Badge](https://img.shields.io/badge/Server-3.1.1-blue)
+![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)
+[![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
-
-- [Start Here](#start-here)
-- [Why Honcho](#why-honcho)
-- [The Honcho Loop](#the-honcho-loop)
-- [Quickstart](#quickstart)
-- [What Honcho Gives You](#what-honcho-gives-you)
-- [Integrations](#integrations)
-- [CLI](#cli)
-- [Core Concepts](#core-concepts)
-- [Benchmarks & Evals](#benchmarks--evals)
-- [Self-hosting](#self-hosting)
+- [Project Structure](#project-structure)
+- [Usage](#usage)
+- [Local Development](#local-development)
+  - [Prerequisites and Dependencies](#prerequisites-and-dependencies)
+  - [Setup](#setup)
+  - [Docker](#docker)
+  - [Deploy on Fly](#deploy-on-fly)
 - [Configuration](#configuration)
+  - [Using config.toml](#using-configtoml)
+  - [Using Environment Variables](#using-environment-variables)
+  - [Configuration Priority](#configuration-priority)
+  - [Example](#example)
 - [Architecture](#architecture)
-- [SDKs](#sdks)
-- [Learn More](#learn-more)
+  - [Storage](#storage)
+  - [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                   |
-| -------------------------------------- | ---------------------------------------------------------- | ----------------------------- |
-| Give my coding agent persistent memory | Claude Code, OpenCode, OpenClaw, Hermes, or any MCP client | [Integrations](#integrations) |
-| 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) |
+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
+[Stainless](https://www.stainlessapi.com/).
 
-## Why Honcho
+- [Python](https://pypi.org/project/honcho-ai/)
+- [TypeScript](https://www.npmjs.com/package/@honcho-ai/sdk)
 
-| Capability              | What it means                                                                        |
-| ----------------------- | ------------------------------------------------------------------------------------ |
-| Reasoning-first memory  | Extracts conclusions from conversations and events, not just matching chunks.        |
-| 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.             |
+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
+core SDKs in their own repos:
 
-## 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.
-2. **Reason** — Honcho processes the queue in the background and updates peer representations.
-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.
+Examples on how to use the SDK are located within each SDK folder and in the
+[SDK Reference](https://docs.honcho.dev/v2/documentation/tutorial/SDK)
 
-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
-pip install honcho-ai
-# or: uv add honcho-ai
-# or: poetry add honcho-ai
-```
+Provision API keys and change your base url to point to
+[https://api.honcho.dev](https://api.honcho.dev)
 
-```python
-import os
-from honcho import Honcho
+Additionally, Honcho can be self-hosted for testing and evaluation purposes. See
+the [Local Development](#local-development) section below for details on how to set up a local
+version of Honcho.
 
-# Managed service uses api.honcho.dev by default. For self-hosted, pass
-# base_url="http://localhost:8000" or set HONCHO_URL.
-honcho = Honcho(
-    workspace_id="my-app-testing",
-    api_key=os.environ["HONCHO_API_KEY"],
-)
+## Local Development
 
-# 1. Store: peers and messages on a session
-alice = honcho.peer("alice")
-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!"),
-])
+Below is a guide on setting up a local environment for running the Honcho
+Server.
 
-# 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.
-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
+### 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 uv version is `0.5.0`
+The minimum python version is `3.9`
+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.
-To use Docker:
-
-```bash
-cp docker-compose.yml.example docker-compose.yml
-docker compose up -d database
-```
+A `docker-compose` template is also available with a database configuration.
 
 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)
-
-# LLM Provider API Keys
-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)
+DB_CONNECTION_URI= # Connection uri for a postgres database
+OPENAI_API_KEY= # API Key for OpenAI used for embedding documents
+ANTHROPIC_API_KEY= # API Key for Anthropic used for the deriver and dialectic API
 ```
 
 > 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
-development and scripting:
+5. **Launch the API**
+
+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)
-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
+fastapi dev src/main.py
 ```
 
-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
-to create the necessary tables:
+As mentioned earlier a `docker-compose` template is included for running Honcho.
+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,
-messages, and the queue system.
+### Deploy on Fly
 
-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
-components need to be running:
+A sample `fly.toml` is included for convenience.
 
-**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
-- **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
+Honcho uses a peer-based model where both users and agents are represented as "peers". This unified approach enables:
 
-<!-- markdownlint-disable MD033 MD001 -->
-<details>
-<summary>Storage primitives in detail</summary>
+- 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
+
+#### 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 with peers)
+└── Sessions ←───────────────┤ (many-to-many)
     ├── Peers ───────────────┘
     └── Messages (session-level)
 ```
 
 **Relationship Details:**
 
-- A **Workspace** contains multiple **Peers** and **Scopes**.
-- **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** belong to a session and are labelled by their source peer.
-- **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**.
+- 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)
+- **Messages** can exist at two levels:
+  - **Session-level**: Communication between peers within a session
+  - **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:
-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.
+The `Message` represents an atomic data unit that can exist at two levels:
 
-</details>
-<!-- markdownlint-enable MD033 MD001 -->
+- **Session-level Messages**: Communication between peers within a session context
+- **Peer-level Messages**: Arbitrary data ingested by a peer to enhance its global representation (independent of any session)
 
-<!-- markdownlint-disable MD033 -->
-<details>
-<summary>Reasoning pipeline</summary>
+All messages are labeled by their source peer and can be processed
+asynchronously to update theory-of-mind models. This flexible design allows for
+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.
-2. Derivation tasks are enqueued for background processing, including:
-   - `representation`: update representations of `Peers`.
-   - `summary`: create summaries of `Sessions`.
-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.
+1. Messages are created via API
+2. Enqueued for background processing including:
+   - `representation`: Update peer's theory of mind
+   - `summary`: Create session summaries
+3. Session-based queue processing ensures proper ordering
+4. Results are stored internally in the vector database
 
-</details>
-<!-- markdownlint-enable MD033 -->
+To read more about how this works read our [Research Paper](https://arxiv.org/abs/2310.06983)
 
-<!-- markdownlint-disable MD033 MD001 -->
-<details>
-<summary>Retrieving data and insights</summary>
+Developers can then leverage these insights in their application to better
+serve peer needs. The primary interface for using these insights is through
+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
-serve the needs of any given application.
+This is a regular API endpoint (`/peers/{peer_id}/chat`) that takes natural language requests to get data
+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
-quickly. To address this, Honcho provides a `context`
-endpoint that returns a combination of messages, conclusions, summaries from a
-session up to a provided token limit.
-
-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.
+- Asking Honcho for a theory-of-mind insight about the `Peer`
+- Asking Honcho to hydrate a prompt with data about the `Peer`s behavior
+- Asking Honcho for a 2nd opinion or approach about how to respond to the Peer
+- Getting personalized responses that incorporate long-term facts and context
 
 ## 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.
-
-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.
+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.
 
 ## 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)

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.

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>

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
-SESSION_OBSERVERS_LIMIT = 10
-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"
+FASTAPI_HOST = "0.0.0.0"
+FASTAPI_PORT = 8000
 
 # 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
-MAX_TOOL_OUTPUT_CHARS = 10000  # Max chars for tool output (~2500 tokens)
-MAX_MESSAGE_CONTENT_CHARS = 2000  # Max chars per message in tool results
+DEFAULT_MAX_TOKENS = 1000
+DEFAULT_TEMPERATURE = 0.0
 
-# API Keys for LLM providers (set the ones you need)
-# Supported transports: openai, anthropic, gemini
-# Base URLs are set per-module via model_config.overrides.base_url
-# Built-in text-generation defaults use openai / gpt-5.4-mini.
-# Embeddings default to openai / text-embedding-3-small.
-OPENAI_API_KEY = "your-api-key-here"
+# Dialectic specific
+DIALECTIC_PROVIDER = "anthropic"
+DIALECTIC_MODEL = "claude-3-7-sonnet-20250219"
+
+# Query Generation specific
+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
-[embedding]
-VECTOR_DIMENSIONS = 1536
-MAX_INPUT_TOKENS = 8192
-MAX_TOKENS_PER_REQUEST = 300000
-
-[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"
+# Agent settings
+[agent]
+SEMANTIC_SEARCH_TOP_K = 10
+SEMANTIC_SEARCH_MAX_DISTANCE = 0.85
+TOM_INFERENCE_METHOD = "single_prompt"
 
 # 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.
-# Staleness is a minutes-timescale condition, so cleanup doesn't need to run on
-# every seconds-scale poll (0.0 = run every poll, legacy behavior).
-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
+POLLING_SLEEP_INTERVAL_SECONDS = 1.0
+TOM_METHOD = "single_prompt"
+USER_REPRESENTATION_METHOD = "long_term"
 
-[deriver.model_config]
-transport = "openai"
-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
+# History settings
+[history]
 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

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"
-    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
+      - 8000:8000
     volumes:
-      # Shared LanceDB data (used when VECTOR_STORE_TYPE=lancedb)
-      - 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
+      - .:/app
     env_file:
-      - path: .env
-        required: false
-    restart: unless-stopped
-
+      - .env
   deriver:
     build:
       context: .
       dockerfile: Dockerfile
-      args:
-        INSTALL_LANCEDB: ${INSTALL_LANCEDB:-false}
-    entrypoint: ["/app/.venv/bin/python", "-m", "src.deriver"]
+    entrypoint: ["uv", "run", "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)
-      - 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
+      - .:/app
     env_file:
-      - path: .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
-
+      - .env
   database:
     image: pgvector/pgvector:pg15
-    restart: unless-stopped
+    restart: always
     ports:
-      - "127.0.0.1:5432:5432"
-    command: ["postgres", "-c", "max_connections=200"]
+      - 5432:5432
     environment:
-      - POSTGRES_DB=postgres
-      - POSTGRES_USER=postgres
-      - POSTGRES_PASSWORD=postgres
-      # 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_DB=honcho
+      - POSTGRES_USER=testuser
+      - POSTGRES_PASSWORD=testpwd
       - POSTGRES_HOST_AUTH_METHOD=trust
       - PGDATA=/var/lib/postgresql/data/pgdata
     volumes:
-      - ./database/init.sql:/docker-entrypoint-initdb.d/init.sql
-      - pgdata:/var/lib/postgresql/data/
+      - ./init.sql:/docker-entrypoint-initdb.d/init.sql
+      - ./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:

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

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

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"]

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,21 +25,18 @@ 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
 ```
 
-Now, you should be able to view the docs on your local environment by visiting `http://localhost:3000`. You can explore the different markdown files and make changes as you see fit.
+Now, you should be able to view the docs on your local environment by visiting `http://localhost:3000`. You can explore the different markdown files and make changes as you see fit.

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
-
+    **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 |
-|-------------------|---------------|------------|
-| v3.1.1 (Current) | v2.4.0 | v2.4.0 |
-| 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 |
+| Honcho API Version | TypeScript SDK | Python SDK | Notes |
+|-------------------|---------------|------------|-------|
+| v2.0.2 (Current) | v1.1.0 | v1.1.0 | Full compatibility with new peer architecture |

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",
-    "dark": "#151E27",
-    "light": "#86BCF2"
+    "primary": "#FF5A7E",
+    "light": "#FF5A7E",
+    "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"]
-        },
-        "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"]
+          "openapi": ["openapi.documented.yml"]
         },
         "tabs": [
           {
@@ -288,34 +26,23 @@
                 "group": "Introduction",
                 "pages": [
                   "v2/documentation/introduction/overview",
-                  "v2/documentation/introduction/quickstart",
-                  "v2/documentation/introduction/vibecoding"
+                  "v2/documentation/introduction/quickstart"
                 ]
               },
               {
                 "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/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"
+                  "v2/documentation/core-concepts/features"
                 ]
               },
               {
-                "group": "Reference",
+                "group": "Tutorial",
                 "pages": [
-                  "v2/documentation/reference/platform",
-                  "v2/documentation/reference/sdk"
+                  "v2/documentation/tutorial/platform",
+                  "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/integrations/langgraph",
-                  "v2/integrations/mcp"
+                  "v2/guides/overview",
+                  "v2/guides/ai-assisted-setup",
+                  "v2/guides/mcp"
                 ]
               },
               {
                 "group": "Application Interfaces",
+                "pages": ["v2/guides/discord", "v2/guides/telegram"]
+              },
+              {
+                "group": "Design Patterns",
                 "pages": [
-                  "v2/guides/discord",
-                  "v2/guides/n8n",
-                  "v2/guides/telegram"
+                  "v2/guides/dialectic-endpoint",
+                  "v2/guides/get-context",
+                  "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/trigger-dream"
+                  "v2/api-reference/endpoint/workspaces/get-deriver-status"
                 ]
               },
               {
@@ -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/create-messages-with-file"
+                  "v2/api-reference/endpoint/messages/update-message"
                 ]
               },
               {
-                "group": "observations",
-                "pages": [
-                  "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"
-                ]
+                "group": "keys",
+                "pages": ["v2/api-reference/endpoint/keys/create-key"]
               }
             ]
           },
           {
-            "tab": "Contributing",
+            "tab": "Changelog",
             "groups": [
               {
-                "group": "Contributing",
+                "group": "Overview",
                 "pages": [
-                  "v2/contributing/guidelines",
-                  "v2/contributing/self-hosting",
-                  "v2/contributing/configuration",
-                  "v2/contributing/license"
+                  "changelog/introduction",
+                  "changelog/compatibility-guide"
                 ]
               }
             ]
@@ -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",
-      "github": "https://github.com/plastic-labs/honcho",
-      "discord": "https://discord.gg/honcho",
-      "linkedin": "https://www.linkedin.com/company/plasticlabs",
-      "youtube": "https://www.youtube.com/@plasticlabs"
+      "twitter": "https://twitter.com/plastic_labs",
+      "github": "https://github.com/plastic-labs",
+      "linkedin": "https://www.linkedin.com/company/plasticlabs"
     }
   },
   "integrations": {
-    "gtm": {
-      "tagId": "GTM-NSPT9PJF"
+    "posthog": {
+      "apiKey": "phc_1yrzzcgywqXGcerkkI4g7C0YfyPMcAKNOOvGcjTCiUk"
     }
   }
 }

docs/logo/honcho-dark.svg

@@ -7,7 +7,7 @@
       }
 
       .cls-2 {
-        fill: #1A1C1E;
+        fill: #111444;
       }
 
       .cls-2, .cls-3 {
@@ -34,4 +34,4 @@
     <path class="cls-2" d="M839.24,3.18v156.95h-49.36v-65.97h-39.58v65.97h-49.36V3.18h49.36v56.41h39.58V3.18h49.36Z"/>
     <path class="cls-2" d="M966.05,7.05c10.39,4.7,17.93,12.89,22.63,24.57,4.7,11.68,7.05,28.36,7.05,50.04s-2.35,38.37-7.05,50.04c-4.7,11.68-12.25,19.87-22.63,24.57-10.39,4.7-24.91,7.05-43.56,7.05s-32.95-2.35-43.33-7.05c-10.39-4.7-17.93-12.89-22.63-24.57-4.7-11.68-7.05-28.36-7.05-50.04s2.35-38.36,7.05-50.04c4.7-11.68,12.24-19.86,22.63-24.57,10.39-4.7,24.83-7.05,43.33-7.05s33.17,2.35,43.56,7.05ZM909.41,40.38c-2.96,2.5-5.04,6.9-6.26,13.19-1.22,6.29-1.82,15.66-1.82,28.09s.6,21.8,1.82,28.09c1.21,6.29,3.3,10.69,6.26,13.19s7.31,3.75,13.08,3.75,10.12-1.25,13.08-3.75,5.04-6.9,6.26-13.19c1.21-6.29,1.82-15.66,1.82-28.09s-.61-21.8-1.82-28.09c-1.22-6.29-3.3-10.69-6.26-13.19s-7.32-3.75-13.08-3.75-10.12,1.25-13.08,3.75Z"/>
   </g>
-</svg>
+</svg>

docs/logo/honcho-light.svg

@@ -7,7 +7,7 @@
       }
 
       .cls-2 {
-        fill: #B5D9FD;
+        fill: #fff;
         stroke-width: 0px;
       }
     </style>
@@ -27,4 +27,4 @@
     <path class="cls-2" d="M839.24,3.18v156.95h-49.36v-65.97h-39.58v65.97h-49.36V3.18h49.36v56.41h39.58V3.18h49.36Z"/>
     <path class="cls-2" d="M966.05,7.05c10.39,4.7,17.93,12.89,22.63,24.57,4.7,11.68,7.05,28.36,7.05,50.04s-2.35,38.37-7.05,50.04c-4.7,11.68-12.25,19.87-22.63,24.57-10.39,4.7-24.91,7.05-43.56,7.05s-32.95-2.35-43.33-7.05c-10.39-4.7-17.93-12.89-22.63-24.57-4.7-11.68-7.05-28.36-7.05-50.04s2.35-38.36,7.05-50.04c4.7-11.68,12.24-19.86,22.63-24.57,10.39-4.7,24.83-7.05,43.33-7.05s33.17,2.35,43.56,7.05ZM909.41,40.38c-2.96,2.5-5.04,6.9-6.26,13.19-1.22,6.29-1.82,15.66-1.82,28.09s.6,21.8,1.82,28.09c1.21,6.29,3.3,10.69,6.26,13.19s7.31,3.75,13.08,3.75,10.12-1.25,13.08-3.75,5.04-6.9,6.26-13.19c1.21-6.29,1.82-15.66,1.82-28.09s-.61-21.8-1.82-28.09c-1.22-6.29-3.3-10.69-6.26-13.19s-7.32-3.75-13.08-3.75-10.12,1.25-13.08,3.75Z"/>
   </g>
-</svg>
+</svg>

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"
   }
 }

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)
-  }
-})()