.agents/skills

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

.claude/skills

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

.claude/skills/honcho-integration/SKILL.md

@@ -0,0 +1,540 @@
+---
+name: honcho-integration
+description: Integrate Honcho memory and social cognition into existing Python or TypeScript codebases. Use when adding Honcho SDK, setting up peers, configuring sessions, implementing the dialectic chat endpoint for AI agents, or wiring Honcho into bot frameworks (nanobot, openclaw, picoclaw, etc).
+allowed-tools: Read, Glob, Grep, Bash(uv:*), Bash(bun:*), Bash(npm:*), Edit, Write, WebFetch, AskUserQuestion
+---
+
+# Honcho Integration Guide
+
+## What is Honcho
+
+Honcho is an open source memory library for building stateful agents. It works with any model, framework, or architecture. You send Honcho the messages from your conversations, and custom reasoning models process them in the background — extracting premises, drawing conclusions, and building rich representations of each participant over time. Your agent can then query those representations on-demand ("What does this user care about?", "How technical is this person?") and get grounded, reasoned answers.
+
+The key mental model: **Peers** are any participant — human or AI. Both are represented the same way. Observation settings (`observe_me`, `observe_others`) control which peers Honcho reasons about. Typically you want Honcho to model your users (`observe_me=True`) but not your AI assistant (`observe_me=False`). **Sessions** scope conversations between peers. **Messages** are the raw data you feed in — Honcho reasons about them asynchronously and stores the results as the peer's **representation**. No messages means no reasoning means no memory.
+
+Your agent accesses this memory through `peer.chat(query)` (ask a natural language question, get a reasoned answer), `session.context()` (get formatted conversation history + representations), or both.
+
+## Integration Workflow
+
+Follow these phases in order:
+
+### Phase 1: Codebase Exploration
+
+Before asking the user anything, explore the codebase to understand:
+
+1. **Language & Framework**: Is this Python or TypeScript? What frameworks are used (FastAPI, Express, Next.js, etc.)?
+2. **Existing AI/LLM code**: Search for existing LLM integrations (OpenAI, Anthropic, LangChain, etc.)
+3. **Entity structure**: Identify users, agents, bots, or other entities that interact
+4. **Session/conversation handling**: How does the app currently manage conversations?
+5. **Message flow**: Where are messages sent/received? What's the request/response cycle?
+
+Use Glob and Grep to find:
+
+- `**/*.py` or `**/*.ts` files with "openai", "anthropic", "llm", "chat", "message"
+- User/session models or types
+- API routes handling chat or conversation endpoints
+
+> **Bot framework detected?** If the codebase is built around an agent loop, tool registry, session manager, and message bus (e.g., nanobot, openclaw, picoclaw), read `{baseDir}/references/bot-frameworks.md` for framework-specific integration guidance and check `{baseDir}/references/bot-frameworks/<framework>/` for concrete reference implementations.
+
+### Phase 2: Interview (REQUIRED)
+
+After exploring the codebase, use the **AskUserQuestion** tool to clarify integration requirements. Ask these questions (adapt based on what you learned in Phase 1):
+
+#### Question Set 1 - Entities & Peers
+
+Ask about which entities should be Honcho peers:
+
+- header: "Peers"
+- question: "Which entities should Honcho track and build representations for?"
+- options based on what you found (e.g., "End users only", "Users + AI assistant", "Users + multiple AI agents", "All participants including third-party services")
+- Include a follow-up if they have multiple AI agents: should any AI peers be observed?
+
+#### Question Set 2 - Integration Pattern
+
+Ask how they want to use Honcho context:
+
+- header: "Pattern"
+- question: "How should your AI access Honcho's user context?"
+- options:
+  - "Tool call (Recommended)" - "Agent queries Honcho on-demand via function calling"
+  - "Pre-fetch" - "Fetch user context before each LLM call with predefined queries"
+  - "context()" - "Include conversation history and representations in prompt"
+  - "Multiple patterns" - "Combine approaches for different use cases"
+
+#### Question Set 3 - Session Structure
+
+Ask about conversation structure:
+
+- header: "Sessions"
+- question: "How should conversations map to Honcho sessions?"
+- options based on their app (e.g., "One session per chat thread", "One session per user", "Multiple users per session (group chat)", "Custom session logic")
+
+#### Question Set 4 - Specific Queries (if using pre-fetch pattern)
+
+If they chose pre-fetch, ask what context matters:
+
+- header: "Context"
+- question: "What user context should be fetched for the AI?"
+- multiSelect: true
+- options: "Communication style", "Expertise level", "Goals/priorities", "Preferences", "Recent activity summary", "Custom queries"
+
+### Phase 3: Implementation
+
+Based on interview responses, implement the integration:
+
+1. Install the SDK
+2. Create Honcho client initialization
+3. Set up peer creation for identified entities
+4. Implement the chosen integration pattern(s)
+5. Add message storage after exchanges
+6. Update any existing conversation handlers
+
+### Phase 4: Verification
+
+- Ensure all message exchanges are stored to Honcho
+- Verify AI peers have `observe_me=False` (unless user specifically wants AI observation)
+- Check that the workspace ID is consistent across the codebase
+- Confirm environment variable for API key is documented
+
+---
+
+## Before You Start
+
+1. **Check the latest SDK versions** at <https://docs.honcho.dev/changelog/introduction>
+   - Python SDK: `honcho-ai`
+   - TypeScript SDK: `@honcho-ai/sdk`
+
+2. **Get an API key** ask the user to get a Honcho API key from <https://app.honcho.dev> and add it to the environment.
+
+## Installation
+
+### Python (use uv)
+
+```bash
+uv add honcho-ai
+```
+
+### TypeScript (use bun)
+
+```bash
+bun add @honcho-ai/sdk
+```
+
+## Sync vs Async
+
+**TypeScript** — The SDK is async by default. All methods return promises. No separate sync API.
+
+**Python** — The SDK provides both sync and async interfaces:
+
+- **Sync** (default): `from honcho import Honcho` — use in sync frameworks (Flask, Django, CLI scripts)
+- **Async**: `from honcho import Honcho` with `.aio` namespace — use in async frameworks (FastAPI, Starlette, async workers)
+
+```python
+# Sync usage (Flask, Django, scripts)
+from honcho import Honcho
+honcho = Honcho(workspace_id="my-app", api_key=os.environ["HONCHO_API_KEY"])
+peer = honcho.peer("user-123")
+response = peer.chat("What does this user prefer?")
+
+# Async usage (FastAPI, Starlette)
+from honcho import Honcho
+honcho = Honcho(workspace_id="my-app", api_key=os.environ["HONCHO_API_KEY"])
+peer = honcho.aio.peer("user-123")
+response = await peer.chat("What does this user prefer?")
+```
+
+Match the client to the framework — check whether the codebase uses `async def` handlers or sync `def` handlers and choose accordingly. The rest of this skill shows sync Python examples; swap to `.aio` equivalents for async codebases.
+
+## Core Integration Patterns
+
+### 1. Initialize with a Single Workspace
+
+Use ONE workspace for your entire application. The workspace name should reflect your app/product.
+
+**Python:**
+
+```python
+from honcho import Honcho
+import os
+
+# Sync client (Flask, Django, scripts)
+honcho = Honcho(
+    workspace_id="your-app-name",
+    api_key=os.environ["HONCHO_API_KEY"],
+    environment="production"
+)
+
+# Async client (FastAPI, Starlette) — use honcho.aio for all operations
+# honcho.aio.peer(), honcho.aio.session(), etc.
+```
+
+**TypeScript:**
+
+```typescript
+import { Honcho } from '@honcho-ai/sdk';
+
+// All methods are async by default
+const honcho = new Honcho({
+    workspaceId: "your-app-name",
+    apiKey: process.env.HONCHO_API_KEY,
+    environment: "production"
+});
+```
+
+### 2. Create Peers for ALL Entities
+
+Create peers for **every entity** in your business logic - users AND AI assistants.
+
+**Python:**
+
+```python
+from honcho import PeerConfig
+
+# Human users
+user = honcho.peer("user-123")
+
+# AI assistants - set observe_me=False so Honcho doesn't model the AI
+assistant = honcho.peer("assistant", configuration=PeerConfig(observe_me=False))
+support_bot = honcho.peer("support-bot", configuration=PeerConfig(observe_me=False))
+```
+
+**TypeScript:**
+
+```typescript
+// Human users
+const user = await honcho.peer("user-123");
+
+// AI assistants - set observeMe=false so Honcho doesn't model the AI
+const assistant = await honcho.peer("assistant", { configuration: { observeMe: false } });
+const supportBot = await honcho.peer("support-bot", { configuration: { observeMe: false } });
+```
+
+### 3. Multi-Peer Sessions
+
+Sessions can have multiple participants. Configure observation settings per-peer.
+
+**Python:**
+
+```python
+from honcho.api_types import SessionPeerConfig
+
+session = honcho.session("conversation-123")
+
+# User is observed (Honcho builds a model of them)
+user_config = SessionPeerConfig(observe_me=True, observe_others=True)
+
+# AI is NOT observed (no model built of the AI)
+ai_config = SessionPeerConfig(observe_me=False, observe_others=True)
+
+session.add_peers([
+    (user, user_config),
+    (assistant, ai_config)
+])
+```
+
+**TypeScript:**
+
+```typescript
+const session = await honcho.session("conversation-123");
+
+await session.addPeers([
+    [user, { observeMe: true, observeOthers: true }],
+    [assistant, { observeMe: false, observeOthers: true }]
+]);
+```
+
+### 4. Add Messages to Sessions
+
+**Python:**
+
+```python
+session.add_messages([
+    user.message("I'm having trouble with my account"),
+    assistant.message("I'd be happy to help. What seems to be the issue?"),
+    user.message("I can't reset my password")
+])
+```
+
+**TypeScript:**
+
+```typescript
+await session.addMessages([
+    user.message("I'm having trouble with my account"),
+    assistant.message("I'd be happy to help. What seems to be the issue?"),
+    user.message("I can't reset my password")
+]);
+```
+
+## Using Honcho for AI Agents
+
+### Pattern A: Dialectic Chat as a Tool Call (Recommended for Agents)
+
+Make Honcho's chat endpoint available as a **tool** for your AI agent. This lets the agent query user context on-demand.
+
+**Python (OpenAI function calling):**
+
+```python
+import openai
+from honcho import Honcho
+
+honcho = Honcho(workspace_id="my-app", api_key=os.environ["HONCHO_API_KEY"])
+
+# Define the tool for your agent
+honcho_tool = {
+    "type": "function",
+    "function": {
+        "name": "query_user_context",
+        "description": "Query Honcho to retrieve relevant context about the user based on their history and preferences. Use this when you need to understand the user's background, preferences, past interactions, or goals.",
+        "parameters": {
+            "type": "object",
+            "properties": {
+                "query": {
+                    "type": "string",
+                    "description": "A natural language question about the user, e.g. 'What are this user's main goals?' or 'What communication style does this user prefer?'"
+                }
+            },
+            "required": ["query"]
+        }
+    }
+}
+
+def handle_honcho_tool_call(user_id: str, query: str) -> str:
+    """Execute the Honcho chat tool call."""
+    peer = honcho.peer(user_id)
+    return peer.chat(query)
+
+# Use in your agent loop
+def run_agent(user_id: str, user_message: str):
+    messages = [{"role": "user", "content": user_message}]
+
+    response = openai.chat.completions.create(
+        model="gpt-4",
+        messages=messages,
+        tools=[honcho_tool]
+    )
+
+    # Handle tool calls
+    if response.choices[0].message.tool_calls:
+        for tool_call in response.choices[0].message.tool_calls:
+            if tool_call.function.name == "query_user_context":
+                import json
+                args = json.loads(tool_call.function.arguments)
+                result = handle_honcho_tool_call(user_id, args["query"])
+                # Continue conversation with tool result...
+```
+
+**TypeScript (OpenAI function calling):**
+
+```typescript
+import OpenAI from 'openai';
+import { Honcho } from '@honcho-ai/sdk';
+
+const honcho = new Honcho({
+    workspaceId: "my-app",
+    apiKey: process.env.HONCHO_API_KEY
+});
+
+const honchoTool: OpenAI.ChatCompletionTool = {
+    type: "function",
+    function: {
+        name: "query_user_context",
+        description: "Query Honcho to retrieve relevant context about the user based on their history and preferences.",
+        parameters: {
+            type: "object",
+            properties: {
+                query: {
+                    type: "string",
+                    description: "A natural language question about the user"
+                }
+            },
+            required: ["query"]
+        }
+    }
+};
+
+async function handleHonchoToolCall(userId: string, query: string): Promise<string> {
+    const peer = await honcho.peer(userId);
+    return await peer.chat(query);
+}
+```
+
+### Pattern B: Pre-fetch Context with Targeted Queries
+
+For simpler integrations, fetch user context before the LLM call using pre-defined queries.
+
+**Python:**
+
+```python
+def get_user_context_for_prompt(user_id: str) -> dict:
+    """Fetch key user attributes via targeted Honcho queries."""
+    peer = honcho.peer(user_id)
+
+    return {
+        "communication_style": peer.chat("What communication style does this user prefer? Be concise."),
+        "expertise_level": peer.chat("What is this user's technical expertise level? Be concise."),
+        "current_goals": peer.chat("What are this user's current goals or priorities? Be concise."),
+        "preferences": peer.chat("What key preferences should I know about this user? Be concise.")
+    }
+
+def build_system_prompt(user_context: dict) -> str:
+    return f"""You are a helpful assistant. Here's what you know about this user:
+
+Communication style: {user_context['communication_style']}
+Expertise level: {user_context['expertise_level']}
+Current goals: {user_context['current_goals']}
+Key preferences: {user_context['preferences']}
+
+Tailor your responses accordingly."""
+```
+
+**TypeScript:**
+
+```typescript
+async function getUserContextForPrompt(userId: string): Promise<Record<string, string>> {
+    const peer = await honcho.peer(userId);
+
+    const [style, expertise, goals, preferences] = await Promise.all([
+        peer.chat("What communication style does this user prefer? Be concise."),
+        peer.chat("What is this user's technical expertise level? Be concise."),
+        peer.chat("What are this user's current goals or priorities? Be concise."),
+        peer.chat("What key preferences should I know about this user? Be concise.")
+    ]);
+
+    return {
+        communicationStyle: style,
+        expertiseLevel: expertise,
+        currentGoals: goals,
+        preferences: preferences
+    };
+}
+```
+
+### Pattern C: Get Context for LLM Integration
+
+Use `context()` for conversation history with built-in LLM formatting.
+
+**Python:**
+
+```python
+import openai
+
+session = honcho.session("conversation-123")
+user = honcho.peer("user-123")
+assistant = honcho.peer("assistant", configuration=PeerConfig(observe_me=False))
+
+# Get context formatted for your LLM
+context = session.context(
+    tokens=2000,
+    peer_target=user.id,  # Include representation of this user
+    summary=True           # Include conversation summaries
+)
+
+# Convert to OpenAI format
+messages = context.to_openai(assistant=assistant)
+
+# Or Anthropic format
+# messages = context.to_anthropic(assistant=assistant)
+
+# Add the new user message
+messages.append({"role": "user", "content": "What should I focus on today?"})
+
+response = openai.chat.completions.create(
+    model="gpt-4",
+    messages=messages
+)
+
+# Store the exchange
+session.add_messages([
+    user.message("What should I focus on today?"),
+    assistant.message(response.choices[0].message.content)
+])
+```
+
+**TypeScript:**
+
+```typescript
+import OpenAI from 'openai';
+
+const session = await honcho.session("conversation-123");
+const user = await honcho.peer("user-123");
+const assistant = await honcho.peer("assistant", { configuration: { observeMe: false } });
+
+// Get context formatted for your LLM
+const context = await session.context({
+    tokens: 2000,
+    peerTarget: user.id,  // Include representation of this user
+    summary: true          // Include conversation summaries
+});
+
+// Convert to OpenAI format
+const messages = context.toOpenAI(assistant);
+
+// Or Anthropic format
+// const messages = context.toAnthropic(assistant);
+
+// Add the new user message
+messages.push({ role: "user", content: "What should I focus on today?" });
+
+const openai = new OpenAI();
+const response = await openai.chat.completions.create({
+    model: "gpt-4",
+    messages
+});
+
+// Store the exchange
+await session.addMessages([
+    user.message("What should I focus on today?"),
+    assistant.message(response.choices[0].message.content!)
+]);
+```
+
+## Streaming Responses
+
+**Python:**
+
+```python
+stream = peer.chat_stream("What do we know about this user?")
+
+for chunk in stream:
+    print(chunk, end="", flush=True)
+```
+
+**TypeScript:**
+
+```typescript
+const stream = await peer.chatStream("What do we know about this user?");
+
+for await (const chunk of stream) {
+    process.stdout.write(chunk);
+}
+```
+
+## Integration Checklist
+
+When integrating Honcho into an existing codebase:
+
+- [ ] Install SDK with `uv add honcho-ai` (Python) or `bun add @honcho-ai/sdk` (TypeScript)
+- [ ] Set up `HONCHO_API_KEY` environment variable
+- [ ] Initialize Honcho client with a single workspace ID
+- [ ] Create peers for all entities (users AND AI assistants)
+- [ ] Set `observe_me=False` for AI peers
+- [ ] Configure sessions with appropriate peer observation settings
+- [ ] Choose integration pattern:
+  - [ ] Tool call pattern for agentic systems
+  - [ ] Pre-fetch pattern for simpler integrations
+  - [ ] context() for conversation history
+- [ ] Store messages after each exchange to build user models
+
+## Common Mistakes to Avoid
+
+1. **Multiple workspaces**: Use ONE workspace per application
+2. **Forgetting AI peers**: Create peers for AI assistants, not just users
+3. **Observing AI peers**: Set `observe_me=False` for AI peers unless you specifically want Honcho to model your AI's behavior
+4. **Not storing messages**: Always call `add_messages()` to feed Honcho's reasoning engine
+5. **Blocking on processing**: Messages are processed asynchronously — don't poll or wait for reasoning to complete before continuing
+
+## Resources
+
+- Documentation: <https://docs.honcho.dev>
+- Latest SDK versions: <https://docs.honcho.dev/changelog/introduction>
+- API Reference: <https://docs.honcho.dev/v3/api-reference/introduction>

.claude/skills/honcho-integration/references/bot-frameworks.md

@@ -127,7 +127,7 @@ Key patterns (shared):
 
 - IDs sanitized to `^[a-zA-Z0-9_-]+` (Honcho requirement)
 - User peer: `observe_me=True, observe_others=True`
-- Assistant/bot peer: `observe_others=True`; set `observe_me=False` only for deterministic bots (scripted output — nothing to model). AI-assistant bots can keep `observe_me=True`.
+- Assistant peer: `observe_me=False, observe_others=True`
 
 If references exist for this framework, use them directly from `{baseDir}/references/bot-frameworks/<framework>/`.
 

.claude/skills/honcho-integration/references/bot-frameworks/nanobot/session.py

@@ -13,7 +13,7 @@ from nanobot.honcho.client import get_honcho_client
 
 if TYPE_CHECKING:
     from honcho import Honcho
-    from honcho.api_types import SessionPeerConfig
+    from honcho.session import SessionPeerConfig
 
 
 @dataclass
@@ -101,7 +101,7 @@ class HonchoSessionManager:
         """
         Get or create a Honcho peer.
 
-        As of v2.1.0, peer() always makes a get-or-create API call.
+        Peers are lazy -- no API call until first use.
         Observation settings are controlled per-session via SessionPeerConfig.
 
         Args:
@@ -137,11 +137,8 @@ class HonchoSessionManager:
 
         session = self.honcho.session(session_id)
 
-        # Configure peer observation settings.
-        # observe_me=False on the assistant skips modeling it — optional for an
-        # AI assistant (fine to leave observation on); it's really only needed
-        # for deterministic bots, where there's nothing meaningful to model.
-        from honcho.api_types import SessionPeerConfig
+        # Configure peer observation settings
+        from honcho.session import SessionPeerConfig
         user_config = SessionPeerConfig(observe_me=True, observe_others=True)
         ai_config = SessionPeerConfig(observe_me=False, observe_others=True)
 

.claude/skills/migrate-honcho-py/DETAILED-CHANGES.md

@@ -0,0 +1,478 @@
+# Detailed API Changes
+
+## 1. Async Client Architecture (Major Change)
+
+The separate `AsyncHoncho`, `AsyncPeer`, and `AsyncSession` classes have been removed. Use the `.aio` accessor instead.
+
+### Before (v1.6.0)
+
+```python
+from honcho import Honcho, AsyncHoncho, AsyncPeer, AsyncSession
+
+# Sync client
+client = Honcho()
+
+# Async client - separate class
+async_client = AsyncHoncho()
+peer = await async_client.peer("user-123")
+response = await peer.chat("query")
+```
+
+### After (v2.0.0)
+
+```python
+from honcho import Honcho
+
+# Single client with .aio accessor for async operations
+client = Honcho()
+
+# Sync operations
+peer = client.peer("user-123")
+response = peer.chat("query")
+
+# Async operations via .aio accessor
+peer = await client.aio.peer("user-123")
+response = await peer.aio.chat("query")
+
+# Async iteration
+async for p in client.aio.peers():
+    print(p.id)
+```
+
+**Migration steps:**
+
+1. Remove all `AsyncHoncho`, `AsyncPeer`, `AsyncSession` imports
+2. Replace `AsyncHoncho()` with `Honcho()` and use `.aio` accessor
+3. Replace `AsyncPeer` type hints with `Peer`
+4. Replace `AsyncSession` type hints with `Session`
+5. Access async methods via `.aio` property on instances
+
+---
+
+## 2. Observations → Conclusions (Terminology Change)
+
+### Before (v1.6.0)
+
+```python
+from honcho import Observation, ObservationScope, AsyncObservationScope
+
+# Access observations
+scope = peer.observations
+scope = peer.observations_of("other-peer")
+
+# List observations
+obs_list = scope.list()
+
+# Query observations
+results = scope.query("preferences")
+
+# Create observations
+scope.create([{"content": "User likes dark mode", "session_id": "sess-1"}])
+
+# Get representation from observations
+rep = scope.get_representation()
+```
+
+### After (v2.0.0)
+
+```python
+from honcho import Conclusion, ConclusionScope, ConclusionScopeAio
+
+# Access conclusions
+scope = peer.conclusions
+scope = peer.conclusions_of("other-peer")
+
+# List conclusions (now returns SyncPage, not list)
+conclusions_page = scope.list()
+for conclusion in conclusions_page:
+    print(conclusion.content)
+
+# Query conclusions
+results = scope.query("preferences")
+
+# Create conclusions
+scope.create([{"content": "User likes dark mode", "session_id": "sess-1"}])
+
+# Get representation from conclusions
+rep = scope.representation()  # Returns str, not Representation object
+```
+
+---
+
+## 3. Representation Type Change (Major Change)
+
+The `Representation` class has been removed. Representations are now simple strings.
+
+### Before (v1.6.0)
+
+```python
+from honcho import Representation, ExplicitObservation, DeductiveObservation
+
+# Get working representation
+rep: Representation = peer.working_rep()
+
+# Access explicit and deductive observations
+for obs in rep.explicit:
+    print(obs.content, obs.created_at)
+
+for obs in rep.deductive:
+    print(obs.conclusion, obs.premises)
+
+# Check if empty
+if rep.is_empty():
+    print("No observations")
+
+# Merge representations
+rep.merge_representation(other_rep)
+
+# Diff representations
+diff = rep.diff_representation(other_rep)
+
+# String formatting
+print(str(rep))
+print(rep.str_no_timestamps())
+print(rep.format_as_markdown())
+```
+
+### After (v2.0.0)
+
+```python
+# Get representation - now returns str directly
+rep: str = peer.representation()
+
+# It's just a string now
+print(rep)
+
+# Check if empty
+if not rep:
+    print("No conclusions")
+```
+
+**Removed methods:**
+
+- `.explicit` property
+- `.deductive` property
+- `.is_empty()`
+- `.merge_representation()`
+- `.diff_representation()`
+- `.str_no_timestamps()`
+- `.format_as_markdown()`
+
+---
+
+## 4. Configuration Parameter Rename
+
+All `config` parameters have been renamed to `configuration`, and configuration types are now strongly typed.
+
+### Before (v1.6.0)
+
+```python
+# Creating resources with config
+peer = client.peer("user-1", config={"observe_me": True})
+session = client.session("sess-1", config={"some_setting": True})
+
+# Getting/setting config
+config = peer.get_config()
+peer.set_config({"observe_me": False})
+
+config = session.get_config()
+session.set_config({"some_setting": False})
+
+config = client.get_config()
+client.set_config({"workspace_setting": True})
+
+# Message config parameter
+msg = peer.message("Hello", config={"reasoning": {"enabled": True}})
+```
+
+### After (v2.0.0)
+
+```python
+from honcho.api_types import PeerConfig, SessionConfiguration, WorkspaceConfiguration
+
+# Creating resources with configuration (typed)
+peer = client.peer("user-1", configuration=PeerConfig(observe_me=True))
+session = client.session("sess-1", configuration=SessionConfiguration())
+
+# Getting/setting configuration (returns typed objects)
+config: PeerConfig = peer.get_configuration()
+peer.set_configuration(PeerConfig(observe_me=False))
+
+config: SessionConfiguration = session.get_configuration()
+session.set_configuration(SessionConfiguration())
+
+config: WorkspaceConfiguration = client.get_configuration()
+client.set_configuration(WorkspaceConfiguration())
+
+# Message configuration parameter
+msg = peer.message("Hello", configuration={"reasoning": {"enabled": True}})
+```
+
+---
+
+## 5. Streaming Chat API Change
+
+### Before (v1.6.0)
+
+```python
+# Streaming via parameter
+response = peer.chat("query", stream=True)
+for chunk in response:
+    print(chunk, end="")
+
+final = response.get_final_response()
+```
+
+### After (v2.0.0)
+
+```python
+# Streaming via separate method
+stream = peer.chat_stream("query")
+for chunk in stream:
+    print(chunk, end="")
+
+final = stream.get_final_response()
+
+# Non-streaming (no stream parameter needed)
+response = peer.chat("query")
+```
+
+---
+
+## 6. Deriver Status → Queue Status
+
+### Before (v1.6.0)
+
+```python
+from honcho_core.types import DeriverStatus
+
+# Get status
+status: DeriverStatus = client.get_deriver_status()
+status = session.get_deriver_status()
+
+# Poll until complete
+status = client.poll_deriver_status(timeout=300.0)
+status = session.poll_deriver_status(timeout=300.0)
+
+# Access fields
+print(status.pending_work_units)
+print(status.in_progress_work_units)
+```
+
+### After (v2.0.0)
+
+```python
+from honcho.api_types import QueueStatusResponse
+
+# Get status
+status: QueueStatusResponse = client.queue_status()
+status = session.queue_status()
+
+# Access fields (same as before)
+print(status.pending_work_units)
+print(status.in_progress_work_units)
+
+# poll_deriver_status has been removed - implement polling manually if needed:
+import time
+
+def poll_until_complete(client, timeout=300.0):
+    start = time.time()
+    while time.time() - start < timeout:
+        status = client.queue_status()
+        if status.pending_work_units == 0 and status.in_progress_work_units == 0:
+            return status
+        time.sleep(1)
+    raise TimeoutError("Queue processing did not complete in time")
+```
+
+---
+
+## 7. PeerContext Changes
+
+### Before (v1.6.0)
+
+```python
+from honcho import PeerContext
+
+context: PeerContext = peer.get_context()
+
+# Access representation (was Representation object)
+rep: Representation = context.representation
+if rep:
+    print(rep.explicit)
+    print(rep.deductive)
+```
+
+### After (v2.0.0)
+
+```python
+from honcho.api_types import PeerContextResponse
+
+context: PeerContextResponse = peer.context()
+
+# Access representation (now str)
+rep: str | None = context.representation
+if rep:
+    print(rep)
+```
+
+---
+
+## 8. Card Method Return Type Change
+
+### Before (v1.6.0)
+
+```python
+# card() returned str (joined with newlines)
+card: str = peer.card()
+print(card)  # "line1\nline2\nline3"
+```
+
+### After (v2.0.0)
+
+```python
+# card() returns list[str] | None
+card: list[str] | None = peer.card()
+if card:
+    print("\n".join(card))  # Join manually if needed
+```
+
+---
+
+## 9. Message Update Location Change
+
+### Before (v1.6.0)
+
+```python
+# Update message via client
+updated = client.update_message(
+    message=msg,
+    metadata={"key": "value"},
+    session="session-id"  # Required if message is string ID
+)
+```
+
+### After (v2.0.0)
+
+```python
+# Update message via session
+updated = session.update_message(
+    message=msg,
+    metadata={"key": "value"}
+)
+```
+
+---
+
+## 10. Removed: `core` Property
+
+### Before (v1.6.0)
+
+```python
+# Access underlying Stainless-generated client
+core_client = client.core
+workspace = client.core.workspaces.get_or_create(id="custom-workspace")
+```
+
+### After (v2.0.0)
+
+```python
+# The `core` property has been removed
+# The SDK no longer uses a Stainless-generated client internally
+# Use the SDK's public API directly
+```
+
+---
+
+## 11. Environment Changes
+
+### Before (v1.6.0)
+
+```python
+# Three environments available
+client = Honcho(environment="local")
+client = Honcho(environment="production")
+client = Honcho(environment="demo")
+```
+
+### After (v2.0.0)
+
+```python
+# Only two environments
+client = Honcho(environment="local")
+client = Honcho(environment="production")
+# "demo" environment has been removed
+```
+
+---
+
+## 12. Reasoning Level Parameter (New Feature)
+
+The chat method now supports a `reasoning_level` parameter:
+
+```python
+# New in v2.0.0
+response = peer.chat(
+    "complex query",
+    reasoning_level="high"  # "minimal", "low", "medium", "high", "max"
+)
+
+stream = peer.chat_stream(
+    "complex query",
+    reasoning_level="max"
+)
+```
+
+---
+
+## 13. Import Changes Summary
+
+### Removed Imports
+
+```python
+# These no longer exist in v2.0.0
+from honcho import AsyncHoncho          # Use Honcho with .aio accessor
+from honcho import AsyncPeer            # Use Peer with .aio accessor
+from honcho import AsyncSession         # Use Session with .aio accessor
+from honcho import Observation          # Renamed to Conclusion
+from honcho import ObservationScope     # Renamed to ConclusionScope
+from honcho import AsyncObservationScope # Renamed to ConclusionScopeAio
+from honcho import Representation       # Removed (now str)
+from honcho import ExplicitObservation  # Removed
+from honcho import DeductiveObservation # Removed
+from honcho import PeerContext          # Use PeerContextResponse from api_types
+```
+
+### New Imports
+
+```python
+from honcho import Conclusion, ConclusionScope
+from honcho import ConclusionScopeAio
+from honcho import HonchoAio, PeerAio, SessionAio  # For type hints
+from honcho import MessageCreateParams, Message
+
+# Typed configuration classes
+from honcho.api_types import (
+    PeerConfig,
+    SessionConfiguration,
+    WorkspaceConfiguration,
+    SessionPeerConfig,
+    QueueStatusResponse,
+    PeerContextResponse,
+)
+```
+
+### Message Type Import Changes
+
+```python
+# Before
+from honcho_core.types.workspaces.sessions import MessageCreateParam
+from honcho_core.types.workspaces.sessions.message import Message
+from honcho.session import SessionPeerConfig
+
+# After
+from honcho import Message, MessageCreateParams  # Note: plural "Params"
+from honcho.api_types import SessionPeerConfig
+```
+
+**Note:** `MessageCreateParam` (singular) is now `MessageCreateParams` (plural).

.claude/skills/migrate-honcho-py/MIGRATION-CHECKLIST.md

@@ -0,0 +1,122 @@
+# Migration Checklist
+
+Use this checklist to track migration progress. Copy into your working notes and check off items as completed.
+
+## Dependencies
+
+- [ ] Update `honcho` package to v2.0.0
+- [ ] Remove any `honcho-core` imports
+
+## Async Architecture Changes
+
+- [ ] Remove `AsyncHoncho` imports → use `Honcho` with `.aio` accessor
+- [ ] Remove `AsyncPeer` imports → use `Peer` with `.aio` accessor
+- [ ] Remove `AsyncSession` imports → use `Session` with `.aio` accessor
+- [ ] Update all async client usage to use `.aio` accessor pattern
+- [ ] Update type hints: `AsyncPeer` → `Peer`, `AsyncSession` → `Session`
+
+## Terminology: Observations → Conclusions
+
+- [ ] Replace `Observation` import with `Conclusion`
+- [ ] Replace `ObservationScope` import with `ConclusionScope`
+- [ ] Replace `AsyncObservationScope` import with `ConclusionScopeAio`
+- [ ] Replace `.observations` property with `.conclusions`
+- [ ] Replace `.observations_of()` method with `.conclusions_of()`
+- [ ] Replace `.get_representation()` with `.representation()`
+
+## Representation Changes
+
+- [ ] Remove `Representation` import (now returns `str`)
+- [ ] Remove `ExplicitObservation` import
+- [ ] Remove `DeductiveObservation` import
+- [ ] Replace `working_rep()` with `representation()`
+- [ ] Update type hints from `Representation` to `str`
+- [ ] Remove `.explicit` property access
+- [ ] Remove `.deductive` property access
+- [ ] Replace `.is_empty()` checks with `not rep`
+- [ ] Remove `.merge_representation()` calls
+- [ ] Remove `.diff_representation()` calls
+- [ ] Remove `.str_no_timestamps()` calls
+- [ ] Remove `.format_as_markdown()` calls
+
+## Configuration Changes
+
+- [ ] Replace all `config=` parameters with `configuration=`
+- [ ] Replace `.get_config()` with `.get_configuration()`
+- [ ] Replace `.set_config()` with `.set_configuration()`
+- [ ] Rename `.get_peer_config()` → `.get_peer_configuration()`
+- [ ] Rename `.set_peer_config()` → `.set_peer_configuration()`
+- [ ] Import typed config classes from `honcho.api_types` if needed:
+  - [ ] `PeerConfig`
+  - [ ] `SessionConfiguration`
+  - [ ] `WorkspaceConfiguration`
+
+## Method Renames
+
+### Peer Methods
+
+- [ ] `peer.working_rep()` → `peer.representation()`
+- [ ] `peer.get_context()` → `peer.context()`
+- [ ] `peer.get_sessions()` → `peer.sessions()`
+- [ ] `peer.chat(stream=True)` → `peer.chat_stream()`
+
+### Session Methods
+
+- [ ] `session.get_context()` → `session.context()`
+- [ ] `session.get_summaries()` → `session.summaries()`
+- [ ] `session.get_messages()` → `session.messages()`
+- [ ] `session.get_peers()` → `session.peers()`
+- [ ] `session.get_peer_config()` → `session.get_peer_configuration()`
+- [ ] `session.set_peer_config()` → `session.set_peer_configuration()`
+- [ ] `session.working_rep()` → `session.representation()`
+- [ ] `session.get_deriver_status()` → `session.queue_status()`
+- [ ] Remove `session.poll_deriver_status()` calls
+
+### Client Methods
+
+- [ ] `client.get_peers()` → `client.peers()`
+- [ ] `client.get_sessions()` → `client.sessions()`
+- [ ] `client.get_workspaces()` → `client.workspaces()`
+- [ ] `client.get_deriver_status()` → `client.queue_status()`
+- [ ] Remove `client.poll_deriver_status()` calls
+- [ ] Move `client.update_message()` → `session.update_message()`
+
+## Parameter Renames
+
+- [ ] `include_most_derived=` → `include_most_frequent=`
+- [ ] `max_observations=` → `max_conclusions=`
+- [ ] `last_user_message=` → `search_query=`
+
+## Return Type Changes
+
+- [ ] Handle `card()` returning `list[str] | None` instead of `str`
+- [ ] Handle `.list()` on conclusions returning `SyncPage` instead of `list`
+
+## Removed Features
+
+- [ ] Remove any usage of `client.core` property
+- [ ] Remove usage of `"demo"` environment (only `"local"` and `"production"` remain)
+- [ ] Implement custom polling if you were using `poll_deriver_status()`
+
+## Type Import Updates
+
+- [ ] Replace `PeerContext` import with `PeerContextResponse` from `honcho.api_types`
+- [ ] Replace `DeriverStatus` import with `QueueStatusResponse` from `honcho.api_types`
+- [ ] Replace `MessageCreateParam` with `MessageCreateParams` (plural)
+- [ ] Move `SessionPeerConfig` import from `honcho.session` to `honcho.api_types`
+
+## Exception Handling (Optional)
+
+- [ ] Update exception handling to use new exception types if needed:
+  - `HonchoError`, `APIError`, `BadRequestError`, `AuthenticationError`
+  - `PermissionDeniedError`, `NotFoundError`, `ConflictError`
+  - `UnprocessableEntityError`, `RateLimitError`, `ServerError`
+  - `TimeoutError`, `ConnectionError`
+
+## Final Verification
+
+- [ ] Run type checker (mypy/pyright) with no errors
+- [ ] Run tests
+- [ ] Verify async operations work with `.aio` accessor
+- [ ] Verify streaming functionality works with `chat_stream()`
+- [ ] Verify configuration changes take effect

.claude/skills/migrate-honcho-py/SKILL.md

@@ -0,0 +1,278 @@
+---
+name: migrate-honcho
+description: Migrates Honcho Python SDK code from v1.6.0 to v2.0.0. Use when upgrading honcho package, fixing breaking changes after upgrade, or when errors mention AsyncHoncho, observations, Representation class, .core property, or get_config methods.
+---
+
+# Honcho Python SDK Migration (v1.6.0 → v2.0.0)
+
+## Overview
+
+This skill migrates code from `honcho` Python SDK v1.6.0 to v2.0.0 (required for Honcho 3.0.0+).
+
+**Key breaking changes:**
+
+- `AsyncHoncho`/`AsyncPeer`/`AsyncSession` removed → use `.aio` accessor
+- "Observation" → "Conclusion" terminology
+- `Representation` class removed (returns `str` now)
+- `get_config`/`set_config` → `get_configuration`/`set_configuration`
+- Streaming via `chat_stream()` instead of `chat(stream=True)`
+- `poll_deriver_status()` removed
+- `.core` property removed
+
+## Quick Migration
+
+### 1. Update async architecture
+
+```python
+# Before
+from honcho import AsyncHoncho, AsyncPeer, AsyncSession
+
+async_client = AsyncHoncho()
+peer = await async_client.peer("user-123")
+response = await peer.chat("query")
+
+# After
+from honcho import Honcho
+
+client = Honcho()
+peer = await client.aio.peer("user-123")
+response = await peer.aio.chat("query")
+
+# Async iteration
+async for p in client.aio.peers():
+    print(p.id)
+```
+
+### 2. Replace observations with conclusions
+
+```python
+# Before
+from honcho import Observation, ObservationScope, AsyncObservationScope
+
+scope = peer.observations
+scope = peer.observations_of("other-peer")
+rep = scope.get_representation()
+
+# After
+from honcho import Conclusion, ConclusionScope, ConclusionScopeAio
+
+scope = peer.conclusions
+scope = peer.conclusions_of("other-peer")
+rep = scope.representation()  # Returns str
+```
+
+### 3. Update representation handling
+
+```python
+# Before
+from honcho import Representation, ExplicitObservation, DeductiveObservation
+
+rep: Representation = peer.working_rep()
+print(rep.explicit)
+print(rep.deductive)
+if rep.is_empty():
+    print("No observations")
+
+# After
+rep: str = peer.representation()
+print(rep)  # Just a string now
+if not rep:
+    print("No conclusions")
+```
+
+### 4. Rename configuration methods
+
+```python
+# Before
+config = peer.get_config()
+peer.set_config({"observe_me": False})
+session.get_config()
+client.get_config()
+
+# After
+from honcho.api_types import PeerConfig, SessionConfiguration, WorkspaceConfiguration
+
+config = peer.get_configuration()
+peer.set_configuration(PeerConfig(observe_me=False))
+session.get_configuration()
+client.get_configuration()
+```
+
+### 5. Update method names
+
+```python
+# Before
+peer.working_rep()
+peer.get_context()
+peer.get_sessions()
+session.get_context()
+session.get_summaries()
+session.get_messages()
+session.get_peers()
+session.get_peer_config()
+client.get_peers()
+client.get_sessions()
+client.get_workspaces()
+
+# After
+peer.representation()
+peer.context()
+peer.sessions()
+session.context()
+session.summaries()
+session.messages()
+session.peers()
+session.get_peer_configuration()
+client.peers()
+client.sessions()
+client.workspaces()
+```
+
+### 6. Update streaming
+
+```python
+# Before
+response = peer.chat("query", stream=True)
+for chunk in response:
+    print(chunk, end="")
+
+# After
+stream = peer.chat_stream("query")
+for chunk in stream:
+    print(chunk, end="")
+```
+
+### 7. Update queue status (formerly deriver)
+
+```python
+# Before
+from honcho_core.types import DeriverStatus
+
+status = client.get_deriver_status()
+status = client.poll_deriver_status(timeout=300.0)  # Removed!
+
+# After
+from honcho.api_types import QueueStatusResponse
+
+status = client.queue_status()
+# poll_deriver_status removed - implement polling manually if needed
+```
+
+### 8. Update representation parameters
+
+```python
+# Before
+rep = peer.working_rep(
+    include_most_derived=True,
+    max_observations=50
+)
+
+# After
+rep = peer.representation(
+    include_most_frequent=True,
+    max_conclusions=50
+)
+```
+
+### 9. Move update_message to session
+
+```python
+# Before
+updated = client.update_message(message=msg, metadata={"key": "value"}, session="sess-id")
+
+# After
+updated = session.update_message(message=msg, metadata={"key": "value"})
+```
+
+### 10. Update card() return type
+
+```python
+# Before
+card: str = peer.card()  # Returns str
+
+# After
+card: list[str] | None = peer.card()  # Returns list[str] | None
+if card:
+    print("\n".join(card))
+```
+
+## Quick Reference Table
+
+| v1.6.0 | v2.0.0 |
+|--------|--------|
+| `AsyncHoncho()` | `Honcho()` + `.aio` accessor |
+| `AsyncPeer` | `Peer` + `.aio` accessor |
+| `AsyncSession` | `Session` + `.aio` accessor |
+| `Observation` | `Conclusion` |
+| `ObservationScope` | `ConclusionScope` |
+| `AsyncObservationScope` | `ConclusionScopeAio` |
+| `Representation` | `str` |
+| `.observations` | `.conclusions` |
+| `.observations_of()` | `.conclusions_of()` |
+| `.get_config()` | `.get_configuration()` |
+| `.set_config()` | `.set_configuration()` |
+| `.working_rep()` | `.representation()` |
+| `.get_context()` | `.context()` |
+| `.get_sessions()` | `.sessions()` |
+| `.get_peers()` | `.peers()` |
+| `.get_messages()` | `.messages()` |
+| `.get_summaries()` | `.summaries()` |
+| `.get_deriver_status()` | `.queue_status()` |
+| `.poll_deriver_status()` | *(removed)* |
+| `.get_peer_config()` | `.get_peer_configuration()` |
+| `.set_peer_config()` | `.set_peer_configuration()` |
+| `client.update_message()` | `session.update_message()` |
+| `chat(stream=True)` | `chat_stream()` |
+| `include_most_derived=` | `include_most_frequent=` |
+| `max_observations=` | `max_conclusions=` |
+| `last_user_message=` | `search_query=` |
+| `config=` | `configuration=` |
+| `PeerContext` | `PeerContextResponse` |
+| `DeriverStatus` | `QueueStatusResponse` |
+| `client.core` | *(removed)* |
+
+## Detailed Reference
+
+For comprehensive details on each change, see:
+
+- [DETAILED-CHANGES.md](DETAILED-CHANGES.md) - Full API change documentation
+- [MIGRATION-CHECKLIST.md](MIGRATION-CHECKLIST.md) - Step-by-step checklist
+
+## New Exception Types
+
+```python
+from honcho import (
+    HonchoError,
+    APIError,
+    BadRequestError,
+    AuthenticationError,
+    PermissionDeniedError,
+    NotFoundError,
+    ConflictError,
+    UnprocessableEntityError,
+    RateLimitError,
+    ServerError,
+    TimeoutError,
+    ConnectionError,
+)
+```
+
+## New Import Locations
+
+```python
+# Configuration types
+from honcho.api_types import (
+    PeerConfig,
+    SessionConfiguration,
+    WorkspaceConfiguration,
+    SessionPeerConfig,
+    QueueStatusResponse,
+    PeerContextResponse,
+)
+
+# Async type hints
+from honcho import HonchoAio, PeerAio, SessionAio
+
+# Message types (note: Params is plural now)
+from honcho import Message, MessageCreateParams
+```

.claude/skills/migrate-honcho-ts/DETAILED-CHANGES.md

@@ -0,0 +1,434 @@
+# Detailed API Changes
+
+## Client Changes
+
+### `.core` Property Removed
+
+The `.core` property (which exposed the raw `@honcho-ai/core` client) has been removed. Use `.http` for advanced HTTP access.
+
+```typescript
+// Before
+const workspace = await client.core.workspaces.getOrCreate({ id: 'my-workspace' })
+
+// After - SDK handles workspace creation automatically
+// For advanced usage:
+const response = await client.http.post('/v3/workspaces', { body: { id: 'my-workspace' } })
+```
+
+### Listing Methods Return Type Changes
+
+- `workspaces()` now returns `Page<string>` instead of `string[]`
+- `session.peers()` now returns `Peer[]` instead of `Page<Peer>`
+
+```typescript
+const workspacePage = await honcho.workspaces()
+for (const id of workspacePage.items) {
+  console.log(id)
+}
+```
+
+### `updateMessage()` Moved to Session
+
+```typescript
+// Before
+await honcho.updateMessage(message, { key: 'value' }, session)
+
+// After
+await session.updateMessage(message, { key: 'value' })
+```
+
+### `config` Option Renamed to `configuration`
+
+```typescript
+// Before
+const peer = await honcho.peer('user-id', { config: { observe_me: true } })
+const session = await honcho.session('session-id', { config: { ... } })
+
+// After
+const peer = await honcho.peer('user-id', { configuration: { observeMe: true } })
+const session = await honcho.session('session-id', { configuration: { reasoning: { enabled: true } } })
+```
+
+---
+
+## Peer Changes
+
+### Streaming API
+
+The `stream` option on `chat()` has been removed. Use `chatStream()` instead.
+
+```typescript
+// Before
+const stream = await peer.chat('Hello', { stream: true })
+for await (const chunk of stream) {
+  process.stdout.write(chunk)
+}
+
+// After
+const stream = await peer.chatStream('Hello')
+for await (const chunk of stream) {
+  process.stdout.write(chunk)
+}
+```
+
+Non-streaming `chat()` now only returns `string | null`:
+
+```typescript
+const response = await peer.chat('Hello')  // Returns string | null
+```
+
+### New `reasoningLevel` Option
+
+```typescript
+const response = await peer.chat('Complex question', {
+  reasoningLevel: 'high'  // 'minimal' | 'low' | 'medium' | 'high' | 'max'
+})
+```
+
+### `workingRep()` Renamed to `representation()`
+
+```typescript
+// Before
+const rep = await peer.workingRep(session, target, options)
+console.log(rep.toString())
+console.log(rep.explicit)
+console.log(rep.deductive)
+
+// After
+const rep = await peer.representation({
+  session,
+  target,
+  searchQuery: options?.searchQuery,
+  maxConclusions: options?.maxObservations,
+  includeMostFrequent: options?.includeMostDerived,
+})
+console.log(rep)  // Returns string directly
+```
+
+### `getContext()` Renamed to `context()`
+
+Options are now passed as a single object:
+
+```typescript
+// Before
+const ctx = await peer.getContext(target, options)
+
+// After
+const ctx = await peer.context({ target, ...options })
+```
+
+### `card()` Return Type Changed
+
+```typescript
+// Before
+const card = await peer.card(target)  // Returns string
+
+// After
+const card = await peer.card(target)  // Returns string[] | null
+```
+
+### `message()` Options Changed
+
+```typescript
+// Before
+const msg = peer.message('Hello', {
+  metadata: { key: 'value' },
+  configuration: { deriver: { enabled: true } },
+  created_at: '2024-01-01T00:00:00Z'
+})
+// Returns ValidatedMessageCreate with peer_id, created_at
+
+// After
+const msg = peer.message('Hello', {
+  metadata: { key: 'value' },
+  configuration: { reasoning: { enabled: true } },
+  createdAt: '2024-01-01T00:00:00Z'
+})
+// Returns MessageInput with peerId, createdAt
+```
+
+### `PeerContext.representation` Type Changed
+
+```typescript
+// Before
+const ctx = await peer.getContext()
+if (ctx.representation) {
+  console.log(ctx.representation.explicit)  // Representation object
+  console.log(ctx.representation.deductive)
+}
+
+// After
+const ctx = await peer.context()
+if (ctx.representation) {
+  console.log(ctx.representation)  // Now a string
+}
+```
+
+---
+
+## Session Changes
+
+### `getPeers()` Return Type Changed
+
+```typescript
+// Before
+const peers = await session.getPeers()  // Returns Page<Peer>
+
+// After
+const peers = await session.peers()  // Returns Peer[]
+```
+
+### `getContext()` Renamed to `context()`
+
+```typescript
+// Before
+const ctx = await session.getContext({
+  summary: true,
+  peerTarget: user,
+  peerPerspective: assistant,
+  lastUserMessage: "What are my preferences?",
+  representationOptions: {
+    maxObservations: 50,
+    includeMostDerived: true
+  }
+})
+
+// After
+const ctx = await session.context({
+  summary: true,
+  peerTarget: user,
+  peerPerspective: assistant,
+  searchQuery: "What are my preferences?",
+  representationOptions: {
+    maxConclusions: 50,
+    includeMostFrequent: true
+  }
+})
+```
+
+### `SessionPeerConfig` Uses camelCase and Methods Renamed
+
+```typescript
+// Before
+await session.setPeerConfig(peer, {
+  observe_me: true,
+  observe_others: false
+})
+const config = await session.peerConfig(peer)
+
+// After
+await session.setPeerConfiguration(peer, {
+  observeMe: true,
+  observeOthers: false
+})
+const config = await session.getPeerConfiguration(peer)
+```
+
+---
+
+## Message Changes
+
+### Message Properties Use camelCase
+
+```typescript
+// Before (from @honcho-ai/core)
+message.peer_id
+message.session_id
+message.workspace_id
+message.created_at
+message.token_count
+
+// After
+message.peerId
+message.sessionId
+message.workspaceId
+message.createdAt
+message.tokenCount
+```
+
+### MessageInput Type
+
+```typescript
+// Before
+interface ValidatedMessageCreate {
+  peer_id: string
+  content: string
+  metadata?: Record<string, unknown>
+  configuration?: Record<string, unknown>
+  created_at?: string
+}
+
+// After
+interface MessageInput {
+  peerId: string
+  content: string
+  metadata?: Record<string, unknown>
+  configuration?: MessageConfiguration
+  createdAt?: string
+}
+```
+
+---
+
+## Streaming Changes
+
+### `DialecticStreamDelta` Removed
+
+```typescript
+// Before
+import { DialecticStreamDelta, DialecticStreamChunk } from '@honcho-ai/sdk'
+
+// After
+import { DialecticStreamChunk, DialecticStreamResponse } from '@honcho-ai/sdk'
+```
+
+---
+
+## Configuration Changes
+
+### Workspace Configuration
+
+Configurations are now strongly typed objects instead of `Record<string, unknown>`.
+
+```typescript
+// Before
+await honcho.setConfig({
+  deriver: { enabled: true },
+  some_custom_key: 'value'
+})
+
+// After
+await honcho.setConfiguration({
+  reasoning: {
+    enabled: true,
+    customInstructions: 'Be concise'
+  },
+  peerCard: {
+    use: true,
+    create: true
+  },
+  summary: {
+    enabled: true,
+    messagesPerShortSummary: 20,
+    messagesPerLongSummary: 60
+  },
+  dream: {
+    enabled: true
+  }
+})
+```
+
+### Peer Configuration
+
+```typescript
+// Before
+await peer.setConfig({ observe_me: false })
+
+// After
+await peer.setConfiguration({ observeMe: false })
+```
+
+### Message Configuration
+
+```typescript
+// Before
+peer.message('Hello', {
+  configuration: {
+    deriver: { enabled: true }
+  }
+})
+
+// After
+peer.message('Hello', {
+  configuration: {
+    reasoning: {
+      enabled: true,
+      customInstructions: 'Focus on emotions'
+    }
+  }
+})
+```
+
+---
+
+## Type Changes
+
+### Removed Exports
+
+- `Observation` (use `Conclusion`)
+- `ObservationScope` (use `ConclusionScope`)
+- `ObservationData`, `ObservationCreateParam`, `ObservationQueryParams`
+- `Representation`, `RepresentationData`, `RepresentationOptions` (class removed)
+- `ExplicitObservation`, `DeductiveObservation`
+- `DialecticStreamDelta`
+- `DeriverStatusOptions` (use `QueueStatusOptions`)
+- `MessageCreate` (use `MessageInput`)
+- `WorkingRepParams`
+
+### New Exports
+
+```typescript
+import {
+  // Domain classes
+  Conclusion,
+  ConclusionScope,
+  ConclusionCreateParams,
+
+  // Error types
+  HonchoError,
+  AuthenticationError,
+  BadRequestError,
+  NotFoundError,
+  PermissionDeniedError,
+  RateLimitError,
+  ConflictError,
+  UnprocessableEntityError,
+  ServerError,
+  ConnectionError,
+  TimeoutError,
+
+  // Message types
+  Message,
+  MessageInput,
+
+  // Configuration types
+  WorkspaceConfig,
+  SessionConfig,
+  PeerConfig,
+  SessionPeerConfig,
+  MessageConfiguration,
+  ReasoningConfig,
+  PeerCardConfig,
+  SummaryConfig,
+  DreamConfig,
+
+  // API response types
+  QueueStatus,
+  QueueStatusOptions,
+  RepresentationOptions,
+  ConclusionQueryParams,
+  ConclusionResponse,
+} from '@honcho-ai/sdk'
+```
+
+### SummaryData Type Changed
+
+```typescript
+// Before
+interface SummaryData {
+  content: string
+  message_id: string
+  summary_type: string
+  created_at: string
+  token_count: number
+}
+
+// After
+interface SummaryData {
+  content: string
+  messageId: string
+  summaryType: string
+  createdAt: string
+  tokenCount: number
+}
+```

.claude/skills/migrate-honcho-ts/MIGRATION-CHECKLIST.md

@@ -0,0 +1,109 @@
+# Migration Checklist
+
+Use this checklist to track migration progress. Copy into your working notes and check off items as completed.
+
+## Dependencies
+
+- [ ] Remove `@honcho-ai/core` from dependencies
+- [ ] Update `@honcho-ai/sdk` to v2.0.0
+
+## Client-Level Changes
+
+- [ ] Replace all `.core` usages with `.http` or remove
+- [ ] Rename `getConfig()` → `getConfiguration()`
+- [ ] Rename `setConfig()` → `setConfiguration()`
+- [ ] Rename `getPeers()` → `peers()`
+- [ ] Rename `getSessions()` → `sessions()`
+- [ ] Rename `getWorkspaces()` → `workspaces()` (returns `Page<string>` now)
+- [ ] Rename `getDeriverStatus()` → `queueStatus()`
+- [ ] Remove `pollDeriverStatus()` calls entirely (no replacement—do not rely on queue being empty)
+- [ ] Move `updateMessage()` calls from client to session
+
+## Peer-Level Changes
+
+- [ ] Replace `peer.chat(q, { stream: true })` with `peer.chatStream(q)`
+- [ ] Rename `getSessions()` → `sessions()`
+- [ ] Rename `getConfig()` → `getConfiguration()`
+- [ ] Rename `setConfig()` → `setConfiguration()`
+- [ ] Rename `peerConfig()` → `getPeerConfiguration()`
+- [ ] Rename `setPeerConfig()` → `setPeerConfiguration()`
+- [ ] Rename `workingRep()` → `representation()` (returns string now)
+- [ ] Rename `getContext()` → `context()`
+- [ ] Replace `observations` → `conclusions`
+- [ ] Replace `observationsOf()` → `conclusionsOf()`
+- [ ] Handle `card()` returning `string[] | null` instead of `string`
+
+## Session-Level Changes
+
+- [ ] Rename `getPeers()` → `peers()` (returns `Peer[]` now, not `Page<Peer>`)
+- [ ] Rename `getMessages()` → `messages()`
+- [ ] Rename `getConfig()` → `getConfiguration()`
+- [ ] Rename `setConfig()` → `setConfiguration()`
+- [ ] Rename `getContext()` → `context()`
+- [ ] Rename `getSummaries()` → `summaries()`
+- [ ] Rename `getDeriverStatus()` → `queueStatus()`
+- [ ] Remove `pollDeriverStatus()` calls entirely (no replacement—do not rely on queue being empty)
+- [ ] Rename `workingRep()` → `representation()` (returns string now)
+
+## Terminology Changes
+
+- [ ] Rename `maxObservations` → `maxConclusions`
+- [ ] Rename `includeMostDerived` → `includeMostFrequent`
+- [ ] Rename `lastUserMessage` → `searchQuery`
+- [ ] Rename `Observation` type → `Conclusion`
+- [ ] Rename `ObservationScope` type → `ConclusionScope`
+
+## snake_case → camelCase
+
+- [ ] Update all `{ config: ... }` to `{ configuration: ... }`
+- [ ] Update `observe_me` → `observeMe`
+- [ ] Update `observe_others` → `observeOthers`
+- [ ] Update `created_at` → `createdAt`
+- [ ] Update message property access:
+  - [ ] `peer_id` → `peerId`
+  - [ ] `session_id` → `sessionId`
+  - [ ] `workspace_id` → `workspaceId`
+  - [ ] `created_at` → `createdAt`
+  - [ ] `token_count` → `tokenCount`
+- [ ] Update summary property access:
+  - [ ] `message_id` → `messageId`
+  - [ ] `summary_type` → `summaryType`
+
+## Configuration Objects
+
+- [ ] Update workspace configuration to typed structure
+- [ ] Update session configuration to typed structure
+- [ ] Update peer configuration to typed structure
+- [ ] Replace `deriver` config with `reasoning` config
+
+## Error Handling
+
+- [ ] Update error handling to use new error types if needed
+
+## Type Imports
+
+- [ ] Remove imports of deleted types:
+  - `Observation`, `ObservationScope`, `ObservationData`
+  - `Representation`, `RepresentationData`
+  - `ExplicitObservation`, `DeductiveObservation`
+  - `DialecticStreamDelta`
+  - `DeriverStatusOptions`
+  - `MessageCreate`, `ValidatedMessageCreate`
+  - `WorkingRepParams`
+- [ ] Add imports of new types as needed:
+  - `Conclusion`, `ConclusionScope`
+  - `MessageInput`
+  - `QueueStatusOptions`
+  - Error types
+
+## Representation Handling
+
+- [ ] Remove usage of `Representation` class methods (`.explicit`, `.deductive`, `.isEmpty()`, `.diff()`)
+- [ ] Handle representation as plain string
+
+## Final Verification
+
+- [ ] Run TypeScript compiler with no errors
+- [ ] Run tests
+- [ ] Verify streaming functionality works
+- [ ] Verify configuration changes take effect

.claude/skills/migrate-honcho-ts/SKILL.md

@@ -0,0 +1,228 @@
+---
+name: migrate-honcho-ts
+description: Migrates Honcho TypeScript SDK code from v1.6.0 to v2.0.0. Use when upgrading @honcho-ai/sdk, fixing breaking changes after upgrade, or when errors mention removed APIs like .core, getConfig, observations, or snake_case properties.
+---
+
+# Honcho TypeScript SDK Migration (v1.6.0 → v2.0.0)
+
+## Overview
+
+This skill migrates code from `@honcho-ai/sdk` v1.6.0 to v2.0.0 (required for Honcho 3.0.0+).
+
+**Key breaking changes:**
+
+- `@honcho-ai/core` dependency removed
+- "Observation" → "Conclusion" terminology
+- "Deriver" → "Queue" terminology
+- `getConfig`/`setConfig` → `getConfiguration`/`setConfiguration`
+- `snake_case` → `camelCase` throughout
+- Streaming via `chatStream()` instead of `chat({ stream: true })`
+- `Representation` class removed (returns string now)
+
+## Quick Migration
+
+### 1. Update dependencies
+
+Remove `@honcho-ai/core` from package.json. The SDK now has its own HTTP client.
+
+### 2. Replace `.core` with `.http`
+
+```typescript
+// Before
+const workspace = await client.core.workspaces.getOrCreate({ id: 'my-workspace' })
+
+// After
+const response = await client.http.post('/v3/workspaces', { body: { id: 'my-workspace' } })
+```
+
+### 3. Rename configuration methods
+
+```typescript
+// Before
+await honcho.getConfig()
+await honcho.setConfig({ key: 'value' })
+await peer.getConfig()
+await session.getConfig()
+
+// After
+await honcho.getConfiguration()
+await honcho.setConfiguration({ reasoning: { enabled: true } })
+await peer.getConfiguration()
+await session.getConfiguration()
+```
+
+### 4. Rename listing methods
+
+```typescript
+// Before
+const peers = await honcho.getPeers()
+const sessions = await honcho.getSessions()
+const workspaces = await honcho.getWorkspaces()  // string[]
+
+// After
+const peers = await honcho.peers()
+const sessions = await honcho.sessions()
+const workspaces = await honcho.workspaces()  // Page<string>
+```
+
+### 5. Update streaming
+
+```typescript
+// Before
+const stream = await peer.chat('Hello', { stream: true })
+
+// After
+const stream = await peer.chatStream('Hello')
+```
+
+### 6. Update observations → conclusions
+
+```typescript
+// Before
+peer.observations
+peer.observationsOf('bob')
+maxObservations: 50
+includeMostDerived: true
+
+// After
+peer.conclusions
+peer.conclusionsOf('bob')
+maxConclusions: 50
+includeMostFrequent: true
+```
+
+### 7. Update queue status methods
+
+```typescript
+// Before
+await honcho.getDeriverStatus({ observer: peer })
+await honcho.pollDeriverStatus({ timeoutMs: 60000 })  // REMOVE - see note below
+
+// After
+await honcho.queueStatus({ observer: peer })
+// pollDeriverStatus() has no replacement - see note below
+```
+
+**Important:** `pollDeriverStatus()` and its polling pattern have been removed entirely. Do not rely on the queue ever being empty. The queue is a continuous processing system—new messages may arrive at any time, and waiting for "completion" is not a valid pattern. If your code previously polled for queue completion, redesign it to work without that assumption.
+
+### 8. Convert snake_case to camelCase
+
+```typescript
+// Before
+message.peer_id
+message.session_id
+message.created_at
+message.token_count
+{ observe_me: true, observe_others: false }
+{ created_at: '2024-01-01' }
+
+// After
+message.peerId
+message.sessionId
+message.createdAt
+message.tokenCount
+{ observeMe: true, observeOthers: false }
+{ createdAt: '2024-01-01' }
+```
+
+### 9. Update representation calls
+
+```typescript
+// Before
+const rep = await peer.workingRep(session, target, options)
+console.log(rep.explicit)  // ExplicitObservation[]
+console.log(rep.deductive) // DeductiveObservation[]
+
+// After
+const rep = await peer.representation({ session, target, ...options })
+console.log(rep)  // string
+```
+
+### 10. Move updateMessage to session
+
+```typescript
+// Before
+await honcho.updateMessage(message, metadata, session)
+
+// After
+await session.updateMessage(message, metadata)
+```
+
+## Quick Reference Table
+
+| v1.6.0 | v2.0.0 |
+|--------|--------|
+| `client.core` | `client.http` |
+| `getConfig()` | `getConfiguration()` |
+| `setConfig()` | `setConfiguration()` |
+| `getPeers()` | `peers()` |
+| `getSessions()` | `sessions()` |
+| `getWorkspaces()` | `workspaces()` |
+| `getDeriverStatus()` | `queueStatus()` |
+| `pollDeriverStatus()` | *Removed - do not poll* |
+| `peer.chat(q, { stream: true })` | `peer.chatStream(q)` |
+| `peer.workingRep()` | `peer.representation()` |
+| `peer.getContext()` | `peer.context()` |
+| `peer.observations` | `peer.conclusions` |
+| `peer.observationsOf()` | `peer.conclusionsOf()` |
+| `session.getPeers()` | `session.peers()` |
+| `session.getMessages()` | `session.messages()` |
+| `session.getSummaries()` | `session.summaries()` |
+| `session.getContext()` | `session.context()` |
+| `session.workingRep()` | `session.representation()` |
+| `session.peerConfig()` | `session.getPeerConfiguration()` |
+| `session.setPeerConfig()` | `session.setPeerConfiguration()` |
+| `{ timeoutMs: 60000 }` | `{ timeout: 60 }` |
+| `{ maxObservations: 50 }` | `{ maxConclusions: 50 }` |
+| `{ includeMostDerived }` | `{ includeMostFrequent }` |
+| `{ lastUserMessage }` | `{ searchQuery }` |
+| `{ config: ... }` | `{ configuration: ... }` |
+| `message.peer_id` | `message.peerId` |
+| `message.created_at` | `message.createdAt` |
+| `Observation` | `Conclusion` |
+| `ObservationScope` | `ConclusionScope` |
+
+## Detailed Reference
+
+For comprehensive details on each change, see:
+
+- [DETAILED-CHANGES.md](DETAILED-CHANGES.md) - Full API change documentation
+- [MIGRATION-CHECKLIST.md](MIGRATION-CHECKLIST.md) - Step-by-step checklist
+
+## New Error Types
+
+```typescript
+import {
+  HonchoError,
+  AuthenticationError,
+  BadRequestError,
+  NotFoundError,
+  PermissionDeniedError,
+  RateLimitError,
+  ConflictError,
+  UnprocessableEntityError,
+  ServerError,
+  ConnectionError,
+  TimeoutError
+} from '@honcho-ai/sdk'
+```
+
+## New Configuration Types
+
+Configurations are now strongly typed:
+
+```typescript
+await honcho.setConfiguration({
+  reasoning: {
+    enabled: true,
+    customInstructions: 'Be concise'
+  },
+  peerCard: { use: true, create: true },
+  summary: {
+    enabled: true,
+    messagesPerShortSummary: 20,
+    messagesPerLongSummary: 60
+  },
+  dream: { enabled: true }
+})
+```

.env.template

@@ -8,10 +8,6 @@
 # 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
@@ -19,18 +15,11 @@ PERFORMANCE_LOG_FORMAT=compact # compact|rich
 
 # 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=
+# MAX_EMBEDDING_TOKENS=8192
+# MAX_EMBEDDING_TOKENS_PER_REQUEST=300000
 
 # LANGFUSE_HOST=
 # LANGFUSE_PUBLIC_KEY=
-# LANGFUSE_SECRET_KEY=
 
 # COLLECT_METRICS_LOCAL=false
 # LOCAL_METRICS_FILE=metrics.jsonl
@@ -43,22 +32,19 @@ PERFORMANCE_LOG_FORMAT=compact # compact|rich
 # =============================================================================
 # Connection URI for PostgreSQL database with pgvector support
 # Must use postgresql+psycopg prefix for SQLAlchemy compatibility
-DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@localhost:5432/postgres
+DB_CONNECTION_URI=postgresql+psycopg://testuser:testpwd@localhost:5432/honcho
 
 # 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,179 +57,160 @@ 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=
+
+# Separate vLLM endpoint (for local models)
+# LLM_VLLM_API_KEY=
+# LLM_VLLM_BASE_URL=
 
 # =============================================================================
 # LLM Configuration
 # =============================================================================
 # Global LLM settings
 # LLM_DEFAULT_MAX_TOKENS=2500
+# LLM_EMBEDDING_PROVIDER=openai
 # 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
 
 # =============================================================================
-# Deriver (Background Worker)
+# 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_PROVIDER=google
+# DERIVER_MODEL=gemini-2.5-flash-lite
+# DERIVER_TEMPERATURE=
 # DERIVER_DEDUPLICATE=true
-# DERIVER_MODEL_CONFIG__MAX_OUTPUT_TOKENS=4096
+# DERIVER_MAX_OUTPUT_TOKENS=4096
+# DERIVER_THINKING_BUDGET_TOKENS=1024
 # DERIVER_LOG_OBSERVATIONS=false
-# DERIVER_MAX_INPUT_TOKENS=25000
-# DERIVER_MAX_CUSTOM_INSTRUCTIONS_TOKENS=2000
+# DERIVER_MAX_INPUT_TOKENS=23000
 # 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_REPRESENTATION_BATCH_MAX_TOKENS=1024
 # 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_BACKUP_PROVIDER=
+# DERIVER_BACKUP_MODEL=
 
 # =============================================================================
-# Peer Card
+# Peer Card Configuration
 # =============================================================================
 # PEER_CARD_ENABLED=true
 
 # =============================================================================
-# Dialectic
+# Dialectic Settings
 # =============================================================================
+# Global dialectic settings
 # 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
+# Each level can have its own provider, model, thinking budget, tool iterations, and max output tokens
+# MAX_OUTPUT_TOKENS is optional per level; if not set, uses global DIALECTIC_MAX_OUTPUT_TOKENS
+
+# Minimal level
+# DIALECTIC_LEVELS__minimal__PROVIDER=google
+# DIALECTIC_LEVELS__minimal__MODEL=gemini-2.5-flash-lite
+# DIALECTIC_LEVELS__minimal__THINKING_BUDGET_TOKENS=0
 # 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__minimal__MAX_OUTPUT_TOKENS=250  # Reduced output for cost savings
+
+# Low level
+# DIALECTIC_LEVELS__low__PROVIDER=google
+# DIALECTIC_LEVELS__low__MODEL=gemini-2.5-flash-lite
+# DIALECTIC_LEVELS__low__THINKING_BUDGET_TOKENS=0
 # 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__low__MAX_OUTPUT_TOKENS=8192  # Optional: override global default
+
+# Medium level
+# DIALECTIC_LEVELS__medium__PROVIDER=anthropic
+# DIALECTIC_LEVELS__medium__MODEL=claude-haiku-4-5
+# DIALECTIC_LEVELS__medium__THINKING_BUDGET_TOKENS=1024
 # 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__medium__MAX_OUTPUT_TOKENS=8192  # Optional: override global default
+# DIALECTIC_LEVELS__medium__TOOL_CHOICE=
+
+# High level
+# DIALECTIC_LEVELS__high__PROVIDER=anthropic
+# DIALECTIC_LEVELS__high__MODEL=claude-haiku-4-5
+# DIALECTIC_LEVELS__high__THINKING_BUDGET_TOKENS=1024
 # 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__high__MAX_OUTPUT_TOKENS=8192  # Optional: override global default
+
+# Max level
+# DIALECTIC_LEVELS__max__PROVIDER=anthropic
+# DIALECTIC_LEVELS__max__MODEL=claude-haiku-4-5
+# DIALECTIC_LEVELS__max__THINKING_BUDGET_TOKENS=2048
 # 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
+# DIALECTIC_LEVELS__max__MAX_OUTPUT_TOKENS=8192  # Optional: override global default
 # 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
+# DIALECTIC_LEVELS__max__BACKUP_PROVIDER=google
+# DIALECTIC_LEVELS__max__BACKUP_MODEL=gemini-2.5-pro
 
 # =============================================================================
-# Summary
+# Summary Settings
 # =============================================================================
 # 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_PROVIDER=google
+# SUMMARY_MODEL=gemini-2.5-flash
 # SUMMARY_MAX_TOKENS_SHORT=1000
 # SUMMARY_MAX_TOKENS_LONG=4000
-# SUMMARY_MODEL_CONFIG__FALLBACK__MODEL=
+# SUMMARY_THINKING_BUDGET_TOKENS=512
+# SUMMARY_BACKUP_PROVIDER=
+# SUMMARY_BACKUP_MODEL=
 
 # =============================================================================
-# Dream
+# Dream Settings
 # =============================================================================
 # 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_PROVIDER=anthropic
+# DREAM_MODEL=claude-sonnet-4-20250514
+# DREAM_MAX_OUTPUT_TOKENS=16384
+# DREAM_THINKING_BUDGET_TOKENS=8192
 # DREAM_MAX_TOOL_ITERATIONS=20
 # DREAM_HISTORY_TOKEN_LIMIT=16384
+# DREAM_BACKUP_PROVIDER=
+# DREAM_BACKUP_MODEL=
 
-# Surprisal sampling (advanced):
+# Specialist models (use same provider as main model)
+# DREAM_DEDUCTION_MODEL=claude-haiku-4-5
+# DREAM_INDUCTION_MODEL=claude-haiku-4-5
+
+# Dream Surprisal Settings (Tree-based observation sampling for targeted reasoning)
 # 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"]
+# DREAM_SURPRISAL__TREE_TYPE=kdtree  # Options: kdtree, balltree, rptree, covertree, lsh, graph, prototype
+# DREAM_SURPRISAL__TREE_K=5  # Number of neighbors for kNN-based trees
+# DREAM_SURPRISAL__SAMPLING_STRATEGY=recent  # Options: recent, random, all
+# DREAM_SURPRISAL__SAMPLE_SIZE=200  # Number of observations to sample for tree building
+# DREAM_SURPRISAL__TOP_PERCENT_SURPRISAL=0.10  # Top percentage of observations (0.10 = top 10%)
+# DREAM_SURPRISAL__MIN_HIGH_SURPRISAL_FOR_REPLACE=10  # Hybrid mode: min observations to replace standard questions
+# DREAM_SURPRISAL__INCLUDE_LEVELS=["explicit","deductive"]  # Observation levels to include
 
 # =============================================================================
 # Webhook Settings
@@ -281,28 +248,14 @@ LLM_OPENAI_API_KEY=your-api-key-here
 # 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
@@ -320,8 +273,8 @@ VECTOR_STORE_MIGRATED=false
 # - 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.
+# Embedding dimensions (default: 1536 for OpenAI text-embedding-3-small)
+# VECTOR_STORE_DIMENSIONS=1536
 
 # Turbopuffer-specific settings (required if TYPE is "turbopuffer")
 # VECTOR_STORE_TURBOPUFFER_API_KEY=your-turbopuffer-api-key

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

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

@@ -6,50 +6,14 @@ on:
     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
 
@@ -57,10 +21,7 @@ jobs:
     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'
+    if: needs.start-runner.outputs.runner-ready == 'true'
     timeout-minutes: 90
     environment: unified-tests
     permissions:
@@ -79,80 +40,25 @@ jobs:
       - name: Configure AWS credentials
         uses: aws-actions/configure-aws-credentials@v4
         with:
-          role-to-assume: ${{ vars.AWS_OIDC_ROLE_ARN }}
+          role-to-assume: arn:aws:iam::444554165670:role/GitHubActionsS3Role
           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
+      - name: Fetch secrets from AWS Secrets Manager
         uses: aws-actions/aws-secretsmanager-get-secrets@v2
         with:
           secret-ids: |
-            HONCHO_TEST_OVERRIDE,${{ secrets.TESTING_SECRET_ID }}
+            ,testing/unified/tests
           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
+          python3.12 --version
+          which python3.12
 
       - name: Install the project
         run: uv sync --all-extras
@@ -204,7 +110,7 @@ jobs:
             exit 0
           fi
 
-          RUNNER_ID=""
+          RUNNER_ID="" 
           if [ -n "$RUNNER_NAME" ]; then
             RUNNER_ID=$(echo "$RUNNERS_RESPONSE" | jq -r --arg name "$RUNNER_NAME" '.runners[]? | select(.name == $name) | .id')
           fi

.github/workflows/unittest.yml

@@ -11,7 +11,6 @@ on:
       - '**.jsx'
       - 'pyproject.toml'
       - 'uv.lock'
-      - '.python-version'
       - 'sdks/typescript/package.json'
       - 'sdks/typescript/bun.lock'
       - '.github/workflows/unittest.yml'
@@ -25,7 +24,6 @@ on:
       - '**.jsx'
       - 'pyproject.toml'
       - 'uv.lock'
-      - '.python-version'
       - 'sdks/typescript/package.json'
       - 'sdks/typescript/bun.lock'
       - '.github/workflows/unittest.yml'
@@ -50,7 +48,6 @@ jobs:
               - '**.py'
               - 'pyproject.toml'
               - 'uv.lock'
-              - '.python-version'
               - 'migrations/**'
               - 'sdks/typescript/**'
               - '.github/workflows/unittest.yml'
@@ -88,7 +85,7 @@ jobs:
       - name: "Set up Python"
         uses: actions/setup-python@v5
         with:
-          python-version-file: ".python-version"
+          python-version-file: "pyproject.toml"
 
       - name: Install bun
         uses: oven-sh/setup-bun@v2

.gitignore

@@ -1,4 +1,3 @@
-.worktrees/
 api/**/*.db
 api/data
 api/docker-compose.yml
@@ -6,8 +5,8 @@ api/docker-compose.yml
 *.db
 data
 redis-data
-/docker-compose.yml
-/compose.yml
+docker-compose.yml
+compose.yml
 
 
 
@@ -182,7 +181,6 @@ docs/node_modules
 
 timing_logs.csv
 
-config.json
 config.toml
 .aider*
 
@@ -193,6 +191,3 @@ metrics.jsonl
 AGENTS.md
 lancedb_data/
 grafana-data/
-
-# Claude Code addon stuff
-.omc

.pre-commit-config.yaml

@@ -60,7 +60,7 @@ repos:
         language: system
         files: ^(src/|tests/|sdks/python/|scripts/).*\.py$
         require_serial: true
-        pass_filenames: true
+        pass_filenames: false
 
       # Run main application tests
       - id: pytest-main

.python-version

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

CHANGELOG.md

@@ -5,313 +5,6 @@ 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
@@ -761,7 +454,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
@@ -935,7 +628,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 +699,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

@@ -10,7 +10,7 @@ Honcho is an infrastructure layer for building AI agents with memory and social
 
 - 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
 
@@ -32,25 +32,23 @@ 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 peer 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
+- **Messages**: Create (batch up to 100), list, get, update
 - **Keys**: Create scoped JWTs
-- **Webhooks**: Register endpoint, list, delete, test
 
 ### Key Features
 
-#### Chat Endpoint (Dialectic agent) (`/peers/{peer_id}/chat`)
+#### Dialectic API (`/peers/{peer_id}/chat`)
 
 - Provides bespoke responses informed by the representation
 - Integrates long-term facts from vector storage
@@ -116,170 +114,128 @@ cd sdks/typescript && bun run tsc --noEmit
 - 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/`.
+Honcho uses three specialized LLM agents that work together to form memories and answer queries:
 
-> **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 Agent (`src/deriver/agent/`)
 
-#### 1. Deriver (`src/deriver/`)
+**Role**: Memory formation through content ingestion
 
-**Role**: Memory formation through content ingestion.
+The Deriver processes incoming messages and extracts observations about peers.
 
-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 created via API are enqueued for background processing
+- **Tools**: `create_observations`, `update_peer_card`, `get_recent_history`, `search_memory`, `get_observation_context`, `search_messages`
+- **Output**: Explicit observations (direct facts) and deductive observations (inferences)
+- **Entry point**: `src/deriver/agent/worker.py` → `Agent.run_loop()`
 
-- **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 Agent (`src/dialectic/agent/`)
 
-#### 2. Dialectic (`src/dialectic/`)
+**Role**: Analysis and recall for answering queries
 
-**Role**: Analysis and recall for answering queries.
+The Dialectic answers questions about peers by strategically gathering context from memory.
 
-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 `/peers/{peer_id}/chat` with `agentic=true`
+- **Tools**: `search_memory`, `get_recent_history`, `get_observation_context`, `search_messages`, `get_recent_observations`, `get_most_derived_observations`, `get_session_summary`, `get_peer_card`, `create_observations` (deductive only)
+- **Output**: Natural language response grounded in gathered context
+- **Entry point**: `src/dialectic/chat.py` → `agentic_chat()` → `DialecticAgent.answer()`
 
-- **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 Agent (`src/dreamer/agent.py`)
 
-#### 3. Dreamer (`src/dreamer/`)
+**Role**: Consolidation and self-improvement of memory
 
-**Role**: Consolidation and self-improvement of memory.
+The Dreamer explores and consolidates observations to improve memory quality.
 
-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`.
+- **Trigger**: Scheduled or explicit dream task via queue
+- **Tools**: `get_recent_observations`, `get_most_derived_observations`, `search_memory`, `create_observations`, `delete_observations`, `update_peer_card`
+- **Strategy**: Random walk exploration - start from recent/high-value observations, search for related content, consolidate redundancies
+- **Output**: Consolidated observations, deleted redundancies
+- **Entry point**: `src/dreamer/agent.py` → `DreamerAgent.consolidate()`
 
 #### 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`.
+All agents share common infrastructure in `src/utils/agent_tools.py`:
+
+- **Tool definitions**: Unified tool schemas used by all agents
+- **Tool executor**: `create_tool_executor()` factory creates context-aware executors
+- **LLM client**: `honcho_llm_call()` handles tool calling loops with configurable iterations
 
 ### 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)
+├── 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
+├── config.py            # Configuration management
+├── db.py                # Database connection and session management
+├── dependencies.py      # Dependency injection (DB sessions)
+├── exceptions.py        # Custom exception types
 ├── 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
+├── embedding_client.py  # Embedding service client
+├── crud/                # Database operations
+│   ├── __init__.py
+│   ├── collection.py     # Collection CRUD operations
+│   ├── deriver.py        # Deriver-related CRUD operations
+│   ├── document.py       # Document CRUD operations
+│   ├── message.py        # Message CRUD operations
+│   ├── peer.py           # Peer CRUD operations
+│   ├── peer_card.py      # Peer Card CRUD operations
+│   ├── representation.py # RepresentationManager and representation operations
+│   ├── session.py        # Session CRUD operations
+│   ├── webhook.py        # Webhook CRUD operations
+│   └── workspace.py      # Workspace CRUD operations
+├── dialectic/            # Dialectic API implementation
+│   ├── __init__.py
+│   ├── chat.py           # Chat functionality (standard + agentic)
+│   ├── prompts.py        # Prompt templates
+│   └── agent/            # Agentic dialectic implementation
+│       ├── __init__.py
+│       ├── core.py       # DialecticAgent class
+│       └── prompts.py    # Agent system prompts
+├── routers/              # API endpoints
+│   ├── workspaces.py
+│   ├── peers.py
+│   ├── sessions.py
+│   ├── messages.py
+│   ├── keys.py
+│   └── webhooks.py      # Webhook endpoints
+├── deriver/             # Background processing system
+│   ├── __init__.py
+│   ├── __main__.py      # Deriver entry point
+│   ├── consumer.py      # Message consumer
+│   ├── enqueue.py       # Queue operations
+│   ├── queue_manager.py # Queue management
+│   └── agent/           # Agentic deriver implementation
+│       ├── __init__.py
+│       ├── core.py      # Agent class
+│       ├── worker.py    # Task processing
+│       └── prompts.py   # Agent system prompts
+├── dreamer/             # Memory consolidation system
+│   ├── __init__.py
+│   ├── agent.py         # DreamerAgent class + process_agent_dream
+│   └── dreamer.py       # Legacy dreamer (scheduled)
+├── utils/               # Utilities
+│   ├── __init__.py
+│   ├── agent_tools.py   # Shared agent tools and executor
+│   ├── clients.py       # LLM client abstraction
+│   ├── files.py         # File handling utilities
+│   ├── filter.py        # Query filtering utilities
+│   ├── formatting.py    # Message formatting utilities
+│   ├── logging.py       # Logging and metrics (Rich console output)
+│   ├── search.py        # Search functionality
+│   ├── shared_models.py # Shared data models
+│   ├── summarizer.py    # Session summarization
+│   └── types.py         # Type definitions
+└── webhooks/            # Webhook system
+    ├── events.py        # Webhook event definitions
+    ├── webhook_delivery.py # Webhook delivery logic
+    └── README.md        # Webhook documentation
 ```
 
-- 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 +248,12 @@ 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
+3. **Background Processing**: Async queue system for expensive operations
+4. **Provider Abstraction**: Model client supports multiple LLM providers
+5. **Scoped Authentication**: JWTs 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,176 @@
 # 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:
 
-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.
+   ```bash
+   git clone https://github.com/YOUR_USERNAME/honcho.git
+   cd honcho
+   ```
 
-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. Add the upstream repository as a remote:
 
-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.
+   ```bash
+   git remote add upstream https://github.com/plastic-labs/honcho.git
+   ```
 
-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.
+### 2. Create a Branch
 
-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,11 +1,10 @@
-# 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.13-slim-bookworm
 
 COPY --from=ghcr.io/astral-sh/uv:0.9.24 /uv /bin/uv
 
+# Set Working directory
 WORKDIR /app
 
 # Enable bytecode compilation
@@ -18,54 +17,29 @@ ENV UV_LINK_MODE=copy
 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-group 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-group dev
 
 # Place executables in the environment at the front of the path
 ENV PATH="/app/.venv/bin:$PATH"
-ENV HOME=/app
+
+# Create non-root user and set ownership
+RUN addgroup --system app && adduser --system --group app && chown -R app:app /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/
 
@@ -74,4 +48,7 @@ USER app
 
 EXPOSE 8000
 
+HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
+    CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/openapi.json')" || exit 1
+
 CMD ["fastapi", "run", "--host", "0.0.0.0", "src/main.py"]

README.md

@@ -8,368 +8,164 @@
 
 ---
 
-![Static Badge](https://img.shields.io/badge/Server-3.1.1-blue)
+![Static Badge](https://img.shields.io/badge/Version-3.0.3-blue)
 [![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)
+[![Discord](https://img.shields.io/discord/1016845111637839922?style=flat&logo=discord&logoColor=23ffffff&label=Plastic%20Labs&labelColor=235865F2)](https://discord.gg/plasticlabs)
 
-**Honcho is memory infrastructure for building stateful agents that understand changing people, agents, groups, projects, and ideas over time.**
+Honcho is an open source memory library with a managed service for building stateful
+agents. Use it with any model, framework, or architecture. It enables agents to build
+and maintain state about any entity--users, agents, groups, ideas, and more. And because
+it's a continual learning system, it understands entities that change over time. Using
+Honcho as your memory system will earn your agents higher retention, more trust, and
+help you build data moats to out-compete incumbents.
 
-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.
+> 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://evals.honcho.dev/), and read the [blog post](https://blog.plasticlabs.ai/research/Benchmarking-Honcho) for more detail.
 
-Using Honcho as your memory system will earn your agents higher retention, more trust, and help you build data moats to out-compete incumbents.
+## TL;DR - Getting Started
 
-> 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.
+With Honcho you can easily setup your application's workflow, save your
+interaction history, and leverage the reasoning it does to inform the behavior of
+your agents
 
-## Contents
+> Typescript examples are available in our [docs](https://docs.honcho.dev).
 
-- [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)
+1. Install the SDK
+
+```bash
+# Python
+pip install honcho-ai
+uv add honcho-ai
+poetry add honcho-ai
+```
+
+2. Setup your `Workspace`, `Peers`, `Session`, and send `Messages`
+
+```python
+from honcho import Honcho
+
+# 1. Initialize your Honcho client
+honcho = Honcho(workspace_id="my-app-testing")
+
+# 2. Initialize peers
+alice = honcho.peer("alice")
+tutor = honcho.peer("tutor")
+
+# 3. Create a session and add messages
+
+session = honcho.session("session-1")
+# Adding messages from a peer will automatically add them to the session
+session.add_messages(
+    [
+        alice.message("Hey there — can you help me with my math homework?"),
+        tutor.message("Absolutely. Send me your first problem!"),
+    ]
+)
+```
+
+3. Leverage reasoning from Honcho to inform your agent's behavior
+
+```python
+
+### 1. Use the chat endpoint to ask questions about your users in natural language
+response = alice.chat("What learning styles does the user respond to best?")
+
+### 2. Use session context to continue a conversation with an LLM
+context = session.context(summary=True, tokens=10_000)
+
+# Convert to a format to send to OpenAI and get the next message
+openai_messages = context.to_openai(assistant=tutor)
+
+from openai import OpenAI
+client = OpenAI()
+response = client.chat.completions.create(
+  model="gpt-4",
+  messages=openai_messages
+)
+
+### 3. Search for similar messages
+results = alice.search("Math Homework")
+
+### 4. Get a session-scoped representation of a peer
+alice_representation = session.representation(alice)
+
+```
+
+This is a simple example of how you can use Honcho to build a chatbot and
+leverage insights to personalize the agent's behavior.
+
+Sign up at [app.honcho.dev](https://app.honcho.dev) to get started with a managed version of Honcho.
+
+Learn more ways to use Honcho on our [developer docs](https://docs.honcho.dev).
+
+Read about the design philosophy and history of the project on our [blog](https://blog.plasticlabs.ai/).
+
+## 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)
+  - [Reasoning](#reasoning)
+  - [Retrieving Data & Insights](#retrieving-data--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.
+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.
 
-## Start Here
+There are also client SDKs implemented in the `sdks/` directory with support
+for Python and TypeScript.
 
-| 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) |
+- [Python](https://pypi.org/project/honcho-ai/)
+- [TypeScript](https://www.npmjs.com/package/@honcho-ai/sdk)
 
-## Why Honcho
+Examples on how to use the SDK are located within each SDK folder and in the
+[SDK Reference](https://docs.honcho.dev/v3/documentation/tutorial/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.             |
+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.
 
-## The Honcho Loop
+## Usage
 
-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.
+Sign up for an account at
+[https://app.honcho.dev](https://app.honcho.dev) and get started with $100 free credits. When you sign up you'll be prompted to
+join an organization which will have a dedicated instance of Honcho.
 
-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.
+Provision API keys and change your base url to point to
+[https://api.honcho.dev](https://api.honcho.dev)
 
-## Quickstart
+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.
 
-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`.
+## Local Development
 
-### Python
+Below is a guide on setting up a local environment for running the Honcho
+Server.
 
-```bash
-pip install honcho-ai
-# or: uv add honcho-ai
-# or: poetry add honcho-ai
-```
+> This guide was made using a M3 Macbook Pro. For any compatibility issues
+> on different platforms, please raise an Issue.
 
-```python
-import os
-from honcho import 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"],
-)
-
-# 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!"),
-])
-
-# 2. Reason: happens asynchronously in the background.
-
-# 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.
@@ -425,10 +221,11 @@ 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)
+# LLM Provider API Keys (at least one required depending on your configuration)
+LLM_ANTHROPIC_API_KEY= # API Key for Anthropic (used for dialectic by default)
+LLM_OPENAI_API_KEY= # API Key for OpenAI (optional, for embeddings if EMBED_MESSAGES=true)
+LLM_GEMINI_API_KEY= # API Key for Google Gemini (used for summary/deriver by default)
+LLM_GROQ_API_KEY= # API Key for Groq (used for query generation by default)
 ```
 
 > Note that the `DB_CONNECTION_URI` must have the prefix `postgresql+psycopg` to
@@ -457,26 +254,6 @@ 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:
-
-```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
-```
-
-Duration units: `s` (seconds), `m` (minutes), `h` (hours), `d` (days), `w` (weeks), `y` (years).
-
 5. **Run database migrations**
 
 With the database set up and environment variables configured, run the migrations
@@ -510,41 +287,208 @@ In a separate terminal, run:
 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.
+The deriver generates representation, summaries, peer cards, and manages dreaming tasks. You can increase the number of deriver's to improve runtime efficiency.
 
-</details>
-<!-- markdownlint-enable MD033 -->
+### Pre-commit Hooks
 
-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).
+Honcho uses pre-commit hooks to ensure code quality and consistency across the project. These hooks automatically run checks on your code before each commit, including linting, formatting, type checking, and security scans.
+
+#### Installation
+
+To set up pre-commit hooks in your development environment:
+
+1. **Install pre-commit using uv**
+
+```bash
+uv add --dev pre-commit
+```
+
+2. **Install the pre-commit hooks**
+
+```bash
+uv run pre-commit install \
+    --hook-type pre-commit \
+    --hook-type commit-msg \
+    --hook-type pre-push
+```
+
+This will install hooks for `pre-commit`, `commit-msg`, and `pre-push` stages.
+
+#### What the hooks do
+
+The pre-commit configuration includes:
+
+- **Code Quality**: Python linting and formatting (ruff), TypeScript linting (biome)
+- **Type Checking**: Static type analysis with basedpyright
+- **Security**: Vulnerability scanning with bandit
+- **Documentation**: Markdown linting and license header checks
+- **Testing**: Automated test runs for Python and TypeScript code
+- **File Hygiene**: Trailing whitespace, line endings, file size checks
+- **Commit Standards**: Conventional commit message validation
+
+#### Manual execution
+
+You can run the hooks manually on all files without making a commit:
+
+```bash
+uv run pre-commit run --all-files
+```
+
+Or run specific hooks:
+
+```bash
+uv run pre-commit run ruff --all-files
+uv run pre-commit run basedpyright --all-files
+```
+
+### Docker
+
+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
+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
+```
+
+### Deploy on Fly
+
+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`.
+
+A sample `fly.toml` is included for convenience.
+
+> 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
+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
+```
 
 ## 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, session limits, embedding settings, namespace)
+- `[db]` - Database connection and pool settings
+- `[auth]` - Authentication configuration
+- `[cache]` - Redis cache configuration
+- `[llm]` - LLM provider API keys and general settings
+- `[deriver]` - Background worker settings and representation configuration
+- `[peer_card]` - Peer card generation settings
+- `[dialectic]` - Dialectic API configuration with per-level reasoning settings
+- `[summary]` - Session summarization settings
+- `[dream]` - Dream processing configuration (including specialist models and surprisal settings)
+- `[webhook]` - Webhook configuration
+- `[metrics]` - Prometheus pull-based metrics
+- `[telemetry]` - CloudEvents telemetry for analytics
+- `[vector_store]` - Vector store configuration (pgvector, turbopuffer, or lancedb)
+- `[sentry]` - Error tracking and monitoring 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
+- `DIALECTIC_LEVELS__low__MODEL` - Model for low reasoning level
+- `DERIVER_PROVIDER` - Provider for background deriver
+- `SUMMARY_PROVIDER` - Summary generation provider
+- `LOG_LEVEL` - Application log level
+- `METRICS_ENABLED` - Enable Prometheus metrics
+- `TELEMETRY_ENABLED` - Enable CloudEvents telemetry
+
+### 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 an entity-centric model where both users and agents are represented as "[peers](https://blog.plasticlabs.ai/blog/Beyond-the-User-Assistant-Paradigm;-Introducing-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
+
+- **Rich Reasoning System**: Multiple implementation methods that extract conclusions from interactions and build comprehensive representations of peers
+- **Chat API**: Provides 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
+
+### Storage
 
 Honcho contains several different primitives used for storing application and
 peer data. This data is used for managing conversations, modeling peer
@@ -559,22 +503,23 @@ Below is a mapping of the different primitives and their relationships.
 Workspaces
 ├── Peers ←──────────────────┐
 │   ├── Sessions             │
-│   └── (internal collections, keyed by observer/observed peer pair)
+│   └── Collections          │
+│       └── Documents        │
 │                            │
-├── 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
+- **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.
@@ -588,7 +533,7 @@ 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,64 +541,48 @@ 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
 
-<!-- markdownlint-disable MD033 -->
-<details>
-<summary>Reasoning pipeline</summary>
+All messages are labeled 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
+modeling.
+
+#### 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 representations of peers.
+
+#### Documents
+
+As stated before a `Document` is vector embedded data stored in a `Collection`.
+
+### Reasoning
 
 The reasoning 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:
 
-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 the API
+2. Derivation Tasks are enqueued for background processing including:
+   - `representation`: To update representations of `Peers`
+   - `summary`: To create summaries of `Sessions`
+3. Session-based queue processing ensures proper ordering
+4. Results are stored internally
 
-</details>
-<!-- markdownlint-enable MD033 -->
-
-<!-- markdownlint-disable MD033 MD001 -->
-<details>
-<summary>Retrieving data and insights</summary>
+### Retrieving Data & Insights
 
 Honcho exposes several different ways to retrieve data from the system to best
 serve the needs of any given application.
@@ -677,42 +606,36 @@ 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:
+The flagship interface for using these insights is through
+the [`Chat` Endpoint](https://blog.plasticlabs.ai/archive/ARCHIVED;-Introducing-Honcho's-Dialectic-API).
 
-- 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.
+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.
+
+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:
+
+- Asking Honcho for a generic or specific 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
 
 #### 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.
+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.
 
-</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.
+Use this to quickly add context to a prompt without having to wait for an LLM
+response.
 
 ## 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.

config.toml.example

@@ -6,12 +6,13 @@
 # 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
+MAX_EMBEDDING_TOKENS = 8192
+MAX_EMBEDDING_TOKENS_PER_REQUEST = 300000
 # LANGFUSE_HOST = "https://api.langfuse.com"
 # LANGFUSE_PUBLIC_KEY = "your-public-key-here"
 # COLLECT_METRICS_LOCAL = false
@@ -27,14 +28,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]
@@ -53,98 +51,43 @@ PROFILES_SAMPLE_RATE = 0.1
 # LLM settings
 [llm]
 DEFAULT_MAX_TOKENS = 2500
+EMBEDDING_PROVIDER = "openai"
 MAX_TOOL_OUTPUT_CHARS = 10000  # Max chars for tool output (~2500 tokens)
 MAX_MESSAGE_CONTENT_CHARS = 2000  # Max chars per message in tool results
 
-# 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"
+# 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-base-url"
 
-# 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"
+# Separate vLLM endpoint (for local models)
+# VLLM_API_KEY = "your-api-key"
+# VLLM_BASE_URL = "your-base-url"
 
 # 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
+PROVIDER = "google"
+MODEL = "gemini-2.5-flash-lite"
+# TEMPERATURE = 0.0
+# BACKUP_PROVIDER = "anthropic"
+# BACKUP_MODEL = "claude-haiku-4-5"
 DEDUPLICATE = true
+MAX_OUTPUT_TOKENS = 4096
+THINKING_BUDGET_TOKENS = 1024
 LOG_OBSERVATIONS = false
-MAX_INPUT_TOKENS = 25000
-MAX_CUSTOM_INSTRUCTIONS_TOKENS = 2000
+MAX_INPUT_TOKENS = 23000
 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
+REPRESENTATION_BATCH_MAX_TOKENS = 1024
 FLUSH_ENABLED = false  # Bypass batch token threshold, process work immediately
 
-[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
@@ -159,64 +102,55 @@ 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]
+PROVIDER = "google"
+MODEL = "gemini-2.5-flash-lite"
+THINKING_BUDGET_TOKENS = 0
 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]
+PROVIDER = "google"
+MODEL = "gemini-2.5-flash-lite"
+THINKING_BUDGET_TOKENS = 0
 MAX_TOOL_ITERATIONS = 5
-TOOL_CHOICE = "auto"
-
-[dialectic.levels.low.model_config]
-transport = "openai"
-model = "gpt-5.4-mini"
+# MAX_OUTPUT_TOKENS = 8192  # Optional: override global default
 
 [dialectic.levels.medium]
+PROVIDER = "anthropic"
+MODEL = "claude-haiku-4-5"
+THINKING_BUDGET_TOKENS = 1024
 MAX_TOOL_ITERATIONS = 2
-
-[dialectic.levels.medium.model_config]
-transport = "openai"
-model = "gpt-5.4-mini"
+# MAX_OUTPUT_TOKENS = 8192  # Optional: override global default
 
 [dialectic.levels.high]
+PROVIDER = "anthropic"
+MODEL = "claude-haiku-4-5"
+THINKING_BUDGET_TOKENS = 1024
 MAX_TOOL_ITERATIONS = 4
-
-[dialectic.levels.high.model_config]
-transport = "openai"
-model = "gpt-5.4-mini"
+# MAX_OUTPUT_TOKENS = 8192  # Optional: override global default
 
 [dialectic.levels.max]
+PROVIDER = "anthropic"
+MODEL = "claude-haiku-4-5"
+THINKING_BUDGET_TOKENS = 2048
 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"
+# MAX_OUTPUT_TOKENS = 8192  # Optional: override global default
+# Backup provider example (optional, must set both or neither):
+# BACKUP_PROVIDER = "google"
+# BACKUP_MODEL = "gemini-2.5-pro"
 
 # Summary settings
 [summary]
 ENABLED = true
 MESSAGES_PER_SHORT_SUMMARY = 20
 MESSAGES_PER_LONG_SUMMARY = 60
+PROVIDER = "google"
+MODEL = "gemini-2.5-flash"
 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"
+THINKING_BUDGET_TOKENS = 512
+# BACKUP_PROVIDER = "google"
+# BACKUP_MODEL = "gemini-2.5-flash"
 
 # Dream settings
 [dream]
@@ -225,16 +159,18 @@ DOCUMENT_THRESHOLD = 50
 IDLE_TIMEOUT_MINUTES = 60
 MIN_HOURS_BETWEEN_DREAMS = 8
 ENABLED_TYPES = ["omni"]
+PROVIDER = "anthropic"
+MODEL = "claude-sonnet-4-20250514"
+MAX_OUTPUT_TOKENS = 16384
+THINKING_BUDGET_TOKENS = 8192
 MAX_TOOL_ITERATIONS = 20
 HISTORY_TOKEN_LIMIT = 16384
+# BACKUP_PROVIDER = "google"
+# BACKUP_MODEL = "gemini-2.5-flash"
 
-[dream.deduction_model_config]
-transport = "openai"
-model = "gpt-5.4-mini"
-
-[dream.induction_model_config]
-transport = "openai"
-model = "gpt-5.4-mini"
+# Specialist models (use same provider as main model)
+DEDUCTION_MODEL = "claude-haiku-4-5"
+INDUCTION_MODEL = "claude-haiku-4-5"
 
 # Surprisal-based sampling subsystem
 [dream.surprisal]
@@ -284,7 +220,7 @@ 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.
+DIMENSIONS = 1536
 # TURBOPUFFER_API_KEY = "your-turbopuffer-api-key"
 # TURBOPUFFER_REGION = "us-east-1"
 LANCEDB_PATH = "./lancedb_data"

docker-compose.yml.example

@@ -1,180 +1,75 @@
-# 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
+      - venv:/app/.venv
     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
+      - venv:/app/.venv
     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
+    command: ["postgres", "-c", "max_connections=800"]
     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/
     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
+    restart: always
     ports:
-      - "127.0.0.1:6379:6379"
+      - 6379:6379
     volumes:
-      - redis-data:/data
+      - ./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
-
+  grafana:
+    image: grafana/grafana:11.4.0
+    ports:
+      - 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:
+      - ./grafana-data:/var/lib/grafana
 volumes:
   pgdata:
-  redis-data:
-  lancedb-data:
-  # -- Development: uncomment if using source mounts --
-  # venv:
-  # prometheus-data:
+  venv:

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/bun.lock

@@ -6,6 +6,7 @@
       "name": "honcho-docs",
       "dependencies": {
         "@mintlify/scraping": "^4.0.467",
+        "honcho-ai": "^0.0.11",
       },
       "devDependencies": {
         "mint": "^4.2.204",
@@ -297,6 +298,8 @@
 
     "@types/node": ["@types/node@18.19.120", "", { "dependencies": { "undici-types": "~5.26.4" } }, "sha512-WtCGHFXnVI8WHLxDAt5TbnCM4eSE+nI0QN2NJtwzcgMhht2eNz6V9evJrk+lwC8bCY8OWV5Ym8Jz7ZEyGnKnMA=="],
 
+    "@types/node-fetch": ["@types/node-fetch@2.6.12", "", { "dependencies": { "@types/node": "*", "form-data": "^4.0.0" } }, "sha512-8nneRWKCg3rMtF69nLQJnOYUcbafYeFSjqkw3jCRLsqkWFlHaoQrr5mXmofFGOx3DKn7UfmBMyov8ySvLRVldA=="],
+
     "@types/react": ["@types/react@19.1.8", "", { "dependencies": { "csstype": "^3.0.2" } }, "sha512-AwAfQ2Wa5bCx9WP8nZL2uMZWod7J7/JSplxbTmBQ5ms6QpqNYm672H0Vu9ZVKVngQ+ii4R/byguVEUZQyeg44g=="],
 
     "@types/unist": ["@types/unist@3.0.3", "", {}, "sha512-ko/gIFJRv177XgZsZcBwnqJN5x/Gien8qNOn0D5bQU/zAzVf9Zt3BlcUiLqhV9y4ARk0GbT3tnUiPNgnTXzc/Q=="],
@@ -323,6 +326,8 @@
 
     "agent-base": ["agent-base@7.1.4", "", {}, "sha512-MnA+YT8fwfJPgBx3m60MNqakm30XOkyIoH1y6huTQvC0PwZG7ki8NacLBcrPbNoo8vEZy7Jpuk7+jMO+CUovTQ=="],
 
+    "agentkeepalive": ["agentkeepalive@4.6.0", "", { "dependencies": { "humanize-ms": "^1.2.1" } }, "sha512-kja8j7PjmncONqaTsB8fQ+wE2mSU2DJ9D4XKoJ5PFWIdRMa6SLSN1ff4mOr4jCbfRSsxR4keIiySJU0N9T5hIQ=="],
+
     "aggregate-error": ["aggregate-error@4.0.1", "", { "dependencies": { "clean-stack": "^4.0.0", "indent-string": "^5.0.0" } }, "sha512-0poP0T7el6Vq3rstR8Mn4V/IQrpBLO6POkUSrN7RhyY+GF/InCFShQzsQ39T25gkHhLgSLByyAz+Kjb+c2L98w=="],
 
     "ajv": ["ajv@8.17.1", "", { "dependencies": { "fast-deep-equal": "^3.1.3", "fast-uri": "^3.0.1", "json-schema-traverse": "^1.0.0", "require-from-string": "^2.0.2" } }, "sha512-B/gBuNg5SiMTrPkC+A2+cW0RszwxYmn6VYxB/inlBStS5nx6xHIt/ehKRhIMhqusl7a8LjQoZnjCs5vhwxOQ1g=="],
@@ -677,10 +682,12 @@
 
     "form-data": ["form-data@4.0.4", "", { "dependencies": { "asynckit": "^0.4.0", "combined-stream": "^1.0.8", "es-set-tostringtag": "^2.1.0", "hasown": "^2.0.2", "mime-types": "^2.1.12" } }, "sha512-KrGhL9Q4zjj0kiUt5OO4Mr/A/jlI2jDYs5eHBpYHPcBEVSiipAvn2Ko2HnPe20rmcuuvMHNdZFp+4IlGTMF0Ow=="],
 
-    "form-data-encoder": ["form-data-encoder@2.1.4", "", {}, "sha512-yDYSgNMraqvnxiEXO4hi88+YZxaHC6QKzb5N84iRCTDeRO7ZALpir/lVmf/uXUhnwUr2O4HU8s/n6x+yNjQkHw=="],
+    "form-data-encoder": ["form-data-encoder@1.7.2", "", {}, "sha512-qfqtYan3rxrnCk1VYaA4H+Ms9xdpPqvLZa6xmMgFvhO32x7/3J/ExcTd6qpxM0vH2GdMI+poehyBZvqfMTto8A=="],
 
     "format": ["format@0.2.2", "", {}, "sha512-wzsgA6WOq+09wrU1tsJ09udeR/YZRaeArL9e1wPbFg3GG2yDnC2ldKpxs4xunpFF9DgqCqOIra3bc1HWrJ37Ww=="],
 
+    "formdata-node": ["formdata-node@4.4.1", "", { "dependencies": { "node-domexception": "1.0.0", "web-streams-polyfill": "4.0.0-beta.3" } }, "sha512-0iirZp3uVDjVGt9p49aTaqjk84TrglENEDuqfdlZQ1roC9CWlPk6Avf8EEnZNcAqPonwkG35x4n3ww/1THYAeQ=="],
+
     "forwarded": ["forwarded@0.2.0", "", {}, "sha512-buRG0fpBtRHSTCOASe6hD258tEubFoRLb4ZNA6NxMVHNw2gOcwHo9wyablzMzOA5z9xA9L1KNjk/Nt6MT9aYow=="],
 
     "fresh": ["fresh@0.5.2", "", {}, "sha512-zJ2mQYM18rEFOudeV4GShTGIQ7RbzA7ozbU9I/XBpm7kqgMywgmylMwXHxZJmkVoYkna9d2pVXVXPdYTP9ej8Q=="],
@@ -781,6 +788,8 @@
 
     "hex-rgb": ["hex-rgb@5.0.0", "", {}, "sha512-NQO+lgVUCtHxZ792FodgW0zflK+ozS9X9dwGp9XvvmPlH7pyxd588cn24TD3rmPm/N0AIRXF10Otah8yKqGw4w=="],
 
+    "honcho-ai": ["honcho-ai@0.0.11", "", { "dependencies": { "@types/node": "^18.11.18", "@types/node-fetch": "^2.6.4", "abort-controller": "^3.0.0", "agentkeepalive": "^4.2.1", "form-data-encoder": "1.7.2", "formdata-node": "^4.3.2", "node-fetch": "^2.6.7" } }, "sha512-SUl/PnMldTCz8G4S8faP00M2iFd9qWDkI5U8w0FQ7OC6SgKzTf1nJ/j3gyzctzR2IZ6LrOz/2d5OwO4f/PCMww=="],
+
     "html-void-elements": ["html-void-elements@3.0.0", "", {}, "sha512-bEqo66MRXsUGxWHV5IP0PUiAWwoEjba4VCzg0LjFJBpchPaTfyfCKTG6bc5F8ucKec3q5y6qOdGyYTSBEvhCrg=="],
 
     "http-cache-semantics": ["http-cache-semantics@4.2.0", "", {}, "sha512-dTxcvPXqPvXBQpq5dUr6mEMJX4oIEFv6bwom3FDwKRDsuIjjJGANqhBuoAn9c1RQJIdAKav33ED65E2ys+87QQ=="],
@@ -793,6 +802,8 @@
 
     "https-proxy-agent": ["https-proxy-agent@7.0.6", "", { "dependencies": { "agent-base": "^7.1.2", "debug": "4" } }, "sha512-vK9P5/iUfdl95AI+JVyUuIcVtd4ofvtrOr3HNtM2yxC9bnMbEdp3x01OhQNnjb8IJYi38VlTE3mBXwcfvywuSw=="],
 
+    "humanize-ms": ["humanize-ms@1.2.1", "", { "dependencies": { "ms": "^2.0.0" } }, "sha512-Fl70vYtsAFb/C06PTS9dZBo7ihau+Tu/DNCk/OyHhea07S+aeMWpFFkUaXRa8fI+ScZbEI8dfSxwY7gxZ9SAVQ=="],
+
     "ico-endec": ["ico-endec@0.1.6", "", {}, "sha512-ZdLU38ZoED3g1j3iEyzcQj+wAkY2xfWNkymszfJPoxucIUhK7NayQ+/C4Kv0nDFMIsbtbEHldv3V8PU494/ueQ=="],
 
     "iconv-lite": ["iconv-lite@0.7.0", "", { "dependencies": { "safer-buffer": ">= 2.1.2 < 3.0.0" } }, "sha512-cf6L2Ds3h57VVmkZe+Pn+5APsT7FpqJtEhhieDCvrE2MK5Qk9MyffgQyuxQTm6BChfeZNtcOLHp9IcWRVcIcBQ=="],
@@ -1125,7 +1136,9 @@
 
     "nlcst-to-string": ["nlcst-to-string@4.0.0", "", { "dependencies": { "@types/nlcst": "^2.0.0" } }, "sha512-YKLBCcUYKAg0FNlOBT6aI91qFmSiFKiluk655WzPF+DDMA02qIyy8uiRqI8QXtcFpEvll12LpL5MXqEmAZ+dcA=="],
 
-    "node-fetch": ["node-fetch@2.6.7", "", { "dependencies": { "whatwg-url": "^5.0.0" }, "peerDependencies": { "encoding": "^0.1.0" }, "optionalPeers": ["encoding"] }, "sha512-ZjMPFEfVx5j+y2yF35Kzx5sF7kDzxuDj6ziH4FFbOp87zKDZNx8yExJIb05OGF4Nlt9IHFIMBkRl41VdvcNdbQ=="],
+    "node-domexception": ["node-domexception@1.0.0", "", {}, "sha512-/jKZoMpw0F8GRwl4/eLROPA3cfcXtLApP0QzLmUT/HuPCZWyB7IY9ZrMeKw2O/nFIqPQB3PVM9aYm0F312AXDQ=="],
+
+    "node-fetch": ["node-fetch@2.7.0", "", { "dependencies": { "whatwg-url": "^5.0.0" }, "peerDependencies": { "encoding": "^0.1.0" }, "optionalPeers": ["encoding"] }, "sha512-c4FRfUm/dbcWZ7U+1Wq0AwCyFL+3nt2bEw05wfxSz+DWpWsitgmSgYmy2dQdWyKC1694ELPqMs/YzUSNozLt8A=="],
 
     "normalize-path": ["normalize-path@3.0.0", "", {}, "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA=="],
 
@@ -1577,6 +1590,8 @@
 
     "web-namespaces": ["web-namespaces@2.0.1", "", {}, "sha512-bKr1DkiNa2krS7qxNtdrtHAmzuYGFQLiQ13TsorsdT6ULTkPLKuu5+GsFpDlg6JFjUTwX2DyhMPG2be8uPrqsQ=="],
 
+    "web-streams-polyfill": ["web-streams-polyfill@4.0.0-beta.3", "", {}, "sha512-QW95TCTaHmsYfHDybGMwO5IJIM93I/6vTRk+daHTWFPhwh+C8Cg7j7XyKrwrj8Ib6vYXe0ocYNrmzY4xAAN6ug=="],
+
     "webidl-conversions": ["webidl-conversions@3.0.1", "", {}, "sha512-2JAn3z8AR6rjK8Sm8orRC0h/bcl/DqL7tRPdGZ4I1CjdF+EaMLmYxBHyXuKL849eucPFhvBoxMsflfOb8kxaeQ=="],
 
     "whatwg-url": ["whatwg-url@5.0.0", "", { "dependencies": { "tr46": "~0.0.3", "webidl-conversions": "^3.0.0" } }, "sha512-saE57nupxk6v3HY35+jzBwYa0rKSy0XR8JSxZPwgLr7ys0IBzhGviA1/TUGJLmSVqs8pb9AnvICXEuOHLprYTw=="],
@@ -1631,6 +1646,8 @@
 
     "@asyncapi/parser/ajv-formats": ["ajv-formats@2.1.1", "", { "dependencies": { "ajv": "^8.0.0" } }, "sha512-Wx0Kx52hxE7C18hkMEggYlEifqWZtYaRgouJor+WMdPnQyEK13vgEWyVNup7SoeeoLMsr4kf5h6dOW11I15MUA=="],
 
+    "@asyncapi/parser/node-fetch": ["node-fetch@2.6.7", "", { "dependencies": { "whatwg-url": "^5.0.0" }, "peerDependencies": { "encoding": "^0.1.0" }, "optionalPeers": ["encoding"] }, "sha512-ZjMPFEfVx5j+y2yF35Kzx5sF7kDzxuDj6ziH4FFbOp87zKDZNx8yExJIb05OGF4Nlt9IHFIMBkRl41VdvcNdbQ=="],
+
     "@inquirer/checkbox/@inquirer/core": ["@inquirer/core@10.3.2", "", { "dependencies": { "@inquirer/ansi": "^1.0.2", "@inquirer/figures": "^1.0.15", "@inquirer/type": "^3.0.10", "cli-width": "^4.1.0", "mute-stream": "^2.0.0", "signal-exit": "^4.1.0", "wrap-ansi": "^6.2.0", "yoctocolors-cjs": "^2.1.3" }, "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-43RTuEbfP8MbKzedNqBrlhhNKVwoK//vUFNW3Q3vZ88BLcrs4kYpGg+B2mm5p2K/HfygoCxuKwJJiv8PbGmE0A=="],
 
     "@inquirer/checkbox/@inquirer/type": ["@inquirer/type@3.0.10", "", { "peerDependencies": { "@types/node": ">=18" }, "optionalPeers": ["@types/node"] }, "sha512-BvziSRxfz5Ov8ch0z/n3oijRSEcEsHnhggm4xFZe93DHcUCTlutlq9Ox4SVENAfcRD22UQq7T/atg9Wr3k09eA=="],
@@ -1697,8 +1714,6 @@
 
     "@stoplight/better-ajv-errors/leven": ["leven@3.1.0", "", {}, "sha512-qsda+H8jTaUaN/x5vzW2rzc+8Rw4TAQ/4KjB46IwK5VH+IlVeeeje/EoZRpiXvIqjFgK84QffqPztGI3VBLG1A=="],
 
-    "@stoplight/json-ref-readers/node-fetch": ["node-fetch@2.7.0", "", { "dependencies": { "whatwg-url": "^5.0.0" }, "peerDependencies": { "encoding": "^0.1.0" }, "optionalPeers": ["encoding"] }, "sha512-c4FRfUm/dbcWZ7U+1Wq0AwCyFL+3nt2bEw05wfxSz+DWpWsitgmSgYmy2dQdWyKC1694ELPqMs/YzUSNozLt8A=="],
-
     "@stoplight/json-ref-readers/tslib": ["tslib@1.14.1", "", {}, "sha512-Xni35NKzjgMrwevysHTCArtLDpPvye8zV/0E4EyYn43P7/7qvQwPh9BGkHewbMulVntbigmcT7rdX3BNo9wRJg=="],
 
     "@stoplight/spectral-core/@stoplight/types": ["@stoplight/types@13.6.0", "", { "dependencies": { "@types/json-schema": "^7.0.4", "utility-types": "^3.10.0" } }, "sha512-dzyuzvUjv3m1wmhPfq82lCVYGcXG0xUYgqnWfCq3PCVR4BKFhjdkHrnJ+jIDoMKvXb05AZP/ObQF6+NpDo29IQ=="],
@@ -1709,8 +1724,6 @@
 
     "@stoplight/spectral-parsers/@stoplight/types": ["@stoplight/types@14.1.1", "", { "dependencies": { "@types/json-schema": "^7.0.4", "utility-types": "^3.10.0" } }, "sha512-/kjtr+0t0tjKr+heVfviO9FrU/uGLc+QNX3fHJc19xsCNYqU7lVhaXxDmEID9BZTjG+/r9pK9xP/xU02XGg65g=="],
 
-    "@stoplight/spectral-runtime/node-fetch": ["node-fetch@2.7.0", "", { "dependencies": { "whatwg-url": "^5.0.0" }, "peerDependencies": { "encoding": "^0.1.0" }, "optionalPeers": ["encoding"] }, "sha512-c4FRfUm/dbcWZ7U+1Wq0AwCyFL+3nt2bEw05wfxSz+DWpWsitgmSgYmy2dQdWyKC1694ELPqMs/YzUSNozLt8A=="],
-
     "@stoplight/yaml/@stoplight/types": ["@stoplight/types@14.1.1", "", { "dependencies": { "@types/json-schema": "^7.0.4", "utility-types": "^3.10.0" } }, "sha512-/kjtr+0t0tjKr+heVfviO9FrU/uGLc+QNX3fHJc19xsCNYqU7lVhaXxDmEID9BZTjG+/r9pK9xP/xU02XGg65g=="],
 
     "body-parser/debug": ["debug@2.6.9", "", { "dependencies": { "ms": "2.0.0" } }, "sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA=="],
@@ -1759,6 +1772,8 @@
 
     "glob/minipass": ["minipass@7.1.2", "", {}, "sha512-qOOzS1cBTWYF4BH8fVePDBOO9iptMnGUEZwNc/cMWnTV2nVLZ7VoNWEPHkYczZA0pdoA7dl6e7FL659nX9S2aw=="],
 
+    "got/form-data-encoder": ["form-data-encoder@2.1.4", "", {}, "sha512-yDYSgNMraqvnxiEXO4hi88+YZxaHC6QKzb5N84iRCTDeRO7ZALpir/lVmf/uXUhnwUr2O4HU8s/n6x+yNjQkHw=="],
+
     "gray-matter/js-yaml": ["js-yaml@3.14.1", "", { "dependencies": { "argparse": "^1.0.7", "esprima": "^4.0.0" }, "bin": { "js-yaml": "bin/js-yaml.js" } }, "sha512-okMH7OXXJ7YrN9Ok3/SXrnu4iX9yOk+25nqX4imS2npuvTYDmo/QEZoqwZkYaIDk3jVvBOTOIEgEhaLOynBS9g=="],
 
     "ink/string-width": ["string-width@7.2.0", "", { "dependencies": { "emoji-regex": "^10.3.0", "get-east-asian-width": "^1.0.0", "strip-ansi": "^7.1.0" } }, "sha512-tsaTIkKW9b4N+AEj+SVA+WhJzV7/zMhcSu78mLKWSk7cXMOSHsBKFWUs0fWwq8QyK3MgJBQRX6Gbi4kYbdvGkQ=="],
@@ -1925,6 +1940,10 @@
 
     "inquirer/ansi-escapes/type-fest": ["type-fest@0.21.3", "", {}, "sha512-t0rzBq87m3fVcduHDUFhKmyyX+9eo6WQjZvf51Ea/M0Q7+T374Jp1aUiyUl0GKxp8M/OETVHSDvmkyPgvX+X2w=="],
 
+    "is-online/got/form-data-encoder": ["form-data-encoder@2.1.4", "", {}, "sha512-yDYSgNMraqvnxiEXO4hi88+YZxaHC6QKzb5N84iRCTDeRO7ZALpir/lVmf/uXUhnwUr2O4HU8s/n6x+yNjQkHw=="],
+
+    "public-ip/got/form-data-encoder": ["form-data-encoder@2.1.4", "", {}, "sha512-yDYSgNMraqvnxiEXO4hi88+YZxaHC6QKzb5N84iRCTDeRO7ZALpir/lVmf/uXUhnwUr2O4HU8s/n6x+yNjQkHw=="],
+
     "send/debug/ms": ["ms@2.0.0", "", {}, "sha512-Tpp60P6IUJDTuOq/5Z8cdskzJujfwqfOTkrwIwj7IRISpnkJnT6SyJ4PCPnGMoFjC9ddhal5KVIYtAt97ix05A=="],
 
     "widest-line/string-width/emoji-regex": ["emoji-regex@10.4.0", "", {}, "sha512-EC+0oUMY1Rqm4O6LLrgjtYDvcVYTy7chDnM4Q7030tP4Kwj3u/pR6gP9ygnp2CJMK5Gq+9Q2oqmrFJAz01DXjw=="],

docs/changelog/compatibility-guide.mdx

@@ -10,14 +10,14 @@ This guide helps you match the right SDK version to your Honcho API version. New
 
 <CardGroup cols={2}>
   <Card title="TypeScript SDK" icon="js">
-    **Latest:** v2.4.0
+    **Latest:** v2.0.1
 
     ```bash
     npm install @honcho-ai/sdk
     ```
   </Card>
   <Card title="Python SDK" icon="python">
-    **Latest:** v2.4.0
+    **Latest:** v2.0.1
 
     ```bash
     pip install honcho-ai
@@ -30,18 +30,7 @@ This guide helps you match the right SDK version to your Honcho API version. New
 
 | 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.3 (Current) | v2.0.1 | v2.0.1 |
 | 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+ |

docs/changelog/introduction.mdx

@@ -27,296 +27,7 @@ Welcome to the Honcho changelog! This section documents all notable changes to t
 ### Honcho API and SDK Changelogs
 <Tabs>
     <Tab title="Honcho API">
-        <Update label="v3.1.1 (Current)">
-        ### 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)
-        </Update>
-
-        <Update label="v3.1.0">
-        ### 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)
-        </Update>
-
-        <Update label="v3.0.12">
-        ### 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)
-        </Update>
-
-        <Update label="v3.0.11">
-        ### 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)
-        </Update>
-
-        <Update label="v3.0.10">
-        ### 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)
-        </Update>
-
-        <Update label="v3.0.9">
-        ### 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`.
-        </Update>
-
-        <Update label="v3.0.8">
-        ### 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)
-        </Update>
-
-        <Update label="v3.0.7">
-        ### Added
-
-        - New `src/llm/` package as the single owner of provider runtime: clients, backends, history adapters, tool loop, request builder, credentials, and caching policy (#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, retry/fallback state, duration, tool-call shape, streaming flag, and agent correlation (`run_id` + iteration) (#637)
-        - `RepresentationCompletedEvent` now carries `total_input_tokens` for full-trace cost attribution; per-emitter `honcho_version` injection; deterministic per-`run_id` high-volume sampler via `TelemetrySettings.HIGH_VOLUME_SAMPLE_RATE` (#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 (#609)
-        - Configurable embedding dimensions: `EMBEDDING_MODEL_CONFIG__DIMENSIONS_MODE` (`auto`/`always`/`never`) controls whether OpenAI `dimensions=` is forwarded (#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 for self-hosted deployments (#575)
-        - API ID `max_length` increased from 100 to 512 across `WorkspaceCreate`, `PeerCreate`, and `SessionCreate` to align with the DB schema (#684)
-        - `AttemptPlan` dataclass pins per-retry provider selection 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 while preserving semantics for other backends (#459)
-
-        ### Changed
-
-        - All LLM orchestration moved out of `src/utils/clients.py` into `src/llm/` with modules split by responsibility (#459)
-        - Default `ModelConfig` factories (deriver, summary, dreamer specialists, dialectic levels) normalized with no extra parameters set by default; operators add transport/thinking overrides explicitly (#459)
-        - OpenAI reasoning-model routing widened to cover `gpt-5.x` and `o1/o3/o4` — these models receive `max_completion_tokens` instead of `max_tokens` (#459)
-        - Peer card prompts reframed as stable identity markers; induction specialist now opts out of peer card writes 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 (#656)
-        - Default dialectic tool choice switched to `auto` (#630)
-        - Vector sync given a substantial retry budget to tolerate transient embedding provider outages (#604)
-        - `AgentToolConclusionsDeletedEvent` payload now carries `levels` (#612)
-        - Turbopuffer: `InternalServerError` caught and surfaced as a warning rather than a hard failure; vector store sync errors downgraded to warnings (#561)
-
-        ### Fixed
-
-        - `reverse` query parameter is now honored on the v3 workspace list, peer list, workspace-scoped session list, and peer-scoped session list. 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` for stable ordering across pages (#685)
-        - LLM client factories now receive `base_url` from `LLMSettings` for default providers — operators pointing at OpenAI-compatible proxies via `LLM__OPENAI_BASE_URL` were previously ignored on the default path (#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: count filter now includes only `documents.level == 'explicit'` (was inflating threshold via dreamer-created levels and creating a feedback loop); `last_dream_at` write relocated from enqueue to process 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) (#615)
-        - Surprisal module: filter format corrected from `{"level": levels}` to `{"level": {"in": levels}}` — 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)
-        - 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; service-level health checks now belong in each service's own configuration (#530)
-        - Removed strict parameter validation for thinking params on Anthropic and OpenAI transports — was rejecting valid per-transport configs (#686)
-        - Stream-final retries pin to the `AttemptPlan` that succeeded rather than re-running provider selection through the outer `current_attempt` ContextVar (#459)
-        - Gemini `cached_content` reuse keys now include `system_instruction` and `tool_config` so cache hits don't cross configurations (#459)
-        - 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 from the shared Docker image (#530)
-        </Update>
-
-        <Update label="v3.0.6">
-        ### 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)
-        </Update>
-
-        <Update label="v3.0.5">
-        ### Fixed
-
-        - explicit rollback on all transactions to force connection closed
-        </Update>
-
-        <Update label="v3.0.4">
-        ### 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)
-        </Update>
-        <Update label="v3.0.3">
+        <Update label="v3.0.3 (Current)">
         ### Added
 
         - Consolidated session context into a single DB session with 40/60 token budget allocation between summary and messages
@@ -766,7 +477,7 @@ Welcome to the Honcho changelog! This section documents all notable changes to t
         ### 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
@@ -800,72 +511,7 @@ Welcome to the Honcho changelog! This section documents all notable changes to t
 
     <Tab title="Python SDK">
         [Python SDK](https://pypi.org/project/honcho-ai/)
-        <Update label="v2.4.0">
-            ### Added
-
-            - Scopes: `Honcho.scope()` / `HonchoAio.scope()` get-or-create a named visibility boundary, `Honcho.scopes()` lists them, and a `Scope` object adds/removes sessions, lists membership, and reads backfill `status()`. `Honcho.session(..., scopes=[...])` joins a new session to scopes at creation. Requires a Honcho server with the matching API support (Honcho v3.1.0+).
-            - `scope` option on `Peer.chat()` / `chat_stream()`, representation, session context, and workspace search. A single scope answers from that scope's collection and card; a list of scopes restricts recall to the union of their member sessions (explicit-only). Mutually exclusive with `session` / `sessions` / `filters`.
-            - Workspace-level chat: `Honcho.chat()` / `HonchoAio.chat()` and `chat_stream()` ask a question across every peer in the workspace, with the same `session`, `scope`, `reasoning_level`, and `response_format` options as `Peer.chat()`. Requires a Honcho server with the matching API support (Honcho v3.1.0+).
-
-            ### Changed
-
-            - `ConclusionScope` is renamed to `ConclusionsView`. The old name remains as a deprecated alias for one more minor version. "Scope" now means a named set of sessions (`Scope`); these objects are views over one observer/observed pair.
-        </Update>
-        <Update label="v2.3.0">
-        ### Added
-
-        - `response_format` on `Peer.chat()` / `PeerAio.chat()` and `Peer.chat_stream()` / `PeerAio.chat_stream()`, for constraining a dialectic answer to a schema. Pass a Pydantic model class to get a validated instance back (parsed via `model_validate_json`), or a raw JSON Schema dict to get the JSON string as-is. Overloads type the return precisely, so a model class narrows to that model and a dict narrows to `str`. On the streaming variants, chunks stay raw text that accumulates to a JSON string — parse it after the stream completes. Requires a Honcho server with the matching API support (Honcho v3.0.12+).
-        - `response_format` field on `DialecticParams`.
-        </Update>
-        <Update label="v2.2.0">
-        ### Added
-
-        - `ConclusionLevel` type (`explicit`, `deductive`, `inductive`, `contradiction`) and a `level` field on `Conclusion`, exposing the reasoning level the server already tracked but previously stripped from responses.
-        - `filters` parameter on `ConclusionScope.list()` and `ConclusionScope.query()` (sync and async), passed through to the same dynamic server-side filter logic as `peers()`/`sessions()`/`messages()`. Filter explicit-only conclusions with `filters={"level": "explicit"}`, or by any other supported field/operator. Requires a Honcho server with the matching API support (Honcho v3.0.11+).
-
-        ### Fixed
-
-        - Scope-managed filter keys (`observer`, `observed`, `session`) are now rejected with a clear `ValueError` if passed in `filters`, instead of silently overriding the scope and returning conclusions from a different peer pair. Use `peer.conclusions` / `conclusions_of(target)` and the `session=` parameter instead. `session_id` remains a valid filter on `query()`.
-        </Update>
-        <Update label="v2.1.2">
-        ### Added
-
-        - `page`, `size`, and `reverse` pagination parameters on `Honcho.workspaces()` and `HonchoAio.workspaces()`, closing the gap from 2.1.0 which added these to other list methods but not to `workspaces()`. Honoring `reverse` on the workspace/peer/session list routes also requires a Honcho server with the matching API fix; older servers silently ignore the parameter.
-        - `peers` parameter on `Honcho.session()` and `HonchoAio.session()` — attach peers to a session at creation time instead of needing a follow-up `session.add_peers()` call. Accepts the same shapes as `Session.add_peers` (peer ID string, `Peer` object, list of either, or tuples with `SessionPeerConfig`).
-
-        ### Changed
-
-        - `WorkspaceCreateParams`, `PeerCreateParams`, and `SessionCreateParams` now accept IDs up to 512 characters (was 100), matching the server-side schema change in Honcho v3.0.7.
-        </Update>
-        <Update label="v2.1.1">
-        ### Fixed
-
-        - Broadened HTTP retry logic to cover `httpx.NetworkError` and `httpx.RemoteProtocolError` in addition to `httpx.TimeoutException` and `httpx.ConnectError`, improving resilience against transient network failures
-        </Update>
-        <Update label="v2.1.0">
-        ### Added
-
-        - `created_at` property on `Peer` and `Session` objects
-        - `is_active` property on `Session` objects
-        - `get_message(message_id)` method on `Session` (sync and async) to fetch a single message by ID
-        - `page`, `size`, and `reverse` pagination parameters on all list methods
-
-        ### Changed
-
-        - **Breaking**: `peer()` and `session()` now always make a get-or-create API call — no more lazy initialization
-        - Response configuration models now tolerate unknown fields from newer servers for forward compatibility
-
-        ### Fixed
-
-        - Sync and async `Session.get_metadata()`, `get_configuration()`, and `refresh()` now refresh cached `created_at` and `is_active` values along with metadata and configuration
-        - `honcho.__version__` now derives from package metadata, with a source-checkout fallback, so it stays aligned with released package versions
-        </Update>
-        <Update label="v2.0.2">
-        ### Changed
-
-        - All input models now reject unknown fields via strict Pydantic validation (`extra="forbid"`). Previously, misspelled or extraneous fields were silently ignored. Now a `ValidationError` is raised with the unrecognized field name.
-        </Update>
-        <Update label="v2.0.1">
+        <Update label="v2.0.1 (Current)">
             ### Added
 
         - `set_peer_card` method
@@ -979,98 +625,7 @@ Welcome to the Honcho changelog! This section documents all notable changes to t
 
     <Tab title="TypeScript SDK">
         [TypeScript SDK](https://www.npmjs.com/package/@honcho-ai/sdk)
-        <Update label="v2.4.0">
-            ### Added
-
-            - Scopes: `honcho.scope()` get-or-creates a named visibility boundary, `honcho.scopes()` lists them, and a `Scope` object adds/removes sessions, lists membership, and reads backfill `status()`. `honcho.session({ scopes: [...] })` joins a new session to scopes at creation. Requires a Honcho server with the matching API support (Honcho v3.1.0+).
-            - `scope` option on `peer.chat()` / `chatStream()`, representation, session context, and workspace search. A single scope answers from that scope's collection and card; a list of scopes restricts recall to the union of their member sessions (explicit-only). Mutually exclusive with `session` / `sessions` / `filters`.
-            - Workspace-level chat: `honcho.chat()` / `honcho.chatStream()` ask a question across every peer in the workspace, with the same `session`, `scope`, `reasoningLevel`, and `responseFormat` options as `peer.chat()`. Requires a Honcho server with the matching API support (Honcho v3.1.0+).
-
-            ### Changed
-
-            - `ConclusionScope` is renamed to `ConclusionsView`. The old name remains as a deprecated alias for one more minor version. "Scope" now means a named set of sessions (`Scope`); these objects are views over one observer/observed pair.
-        </Update>
-        <Update label="v2.3.0">
-        ### Added
-
-        - `responseFormat` option on `peer.chat()` and `peer.chatStream()`, for constraining a dialectic answer to a schema. Pass a Zod schema to get a parsed, validated result back, or a raw JSON Schema object to get the JSON string as-is. Overloads type the return precisely, so a Zod schema narrows to its inferred type and a plain object narrows to `string`. On `chatStream()`, chunks stay raw text that accumulates to a JSON string — parse it after the stream completes. Requires a Honcho server with the matching API support (Honcho v3.0.12+).
-        </Update>
-        <Update label="v2.2.0">
-        ### Added
-
-        - `ConclusionLevel` type (`explicit`, `deductive`, `inductive`, `contradiction`) and a `level` field on `Conclusion`, exposing the reasoning level the server already tracked but previously stripped from responses.
-        - `filters` option on `conclusions.list()` and `conclusions.query()`, passed through to the same dynamic server-side filter logic as the other list endpoints. Filter explicit-only conclusions with `{ filters: { level: 'explicit' } }`, or by any other supported field/operator. Requires a Honcho server with the matching API support (Honcho v3.0.11+).
-
-        ### Fixed
-
-        - Scope-managed filter keys (`observer`, `observed`, `session`) are now rejected with a clear error if passed in `filters`, instead of silently overriding the scope and returning conclusions from a different peer pair. Use `peer.conclusions` / `peer.conclusionsOf(target)` and the dedicated `session` option instead. `session_id` remains a valid filter on `query()`.
-        </Update>
-        <Update label="v2.1.2">
-        ### Added
-
-        - `peers` option on `Honcho.session()` — attach peers to a session at creation time instead of needing a follow-up `session.addPeers()` call. Accepts the same `PeerAddition` shape as `session.addPeers()` (peer ID strings, `Peer` objects, arrays of either, or a record with per-peer `observe_me`/`observe_others` config).
-
-        ### Changed
-
-        - ID validation in `validation.ts` now accepts workspace, peer, and session IDs up to 512 characters (was 100), matching the server-side schema change in Honcho v3.0.7.
-
-        ### Fixed
-
-        - `Honcho.workspaces()` now actually forwards the `reverse` option to the server. The 2.1.0 changelog listed `workspaces()` among the list methods that gained `reverse`, but `client.ts` was missing the field on the params type and request builder, so the option was silently dropped. Honoring `reverse` on the workspace/peer/session list routes also requires a Honcho server with the matching API fix; older servers silently ignore the parameter.
-        </Update>
-        <Update label="v2.1.1">
-        ### Fixed
-
-        - Broadened fetch error retry logic to catch all `TypeError` network failures (connection resets, DNS errors, etc.) instead of only those with `'fetch'` in the message, improving resilience across runtimes (Node, Bun, browsers)
-        </Update>
-        <Update label="v2.1.0">
-        ### Added
-
-        - `createdAt` property on `Peer` and `Session` wrapper objects
-        - `isActive` property on `Session` wrapper objects
-        - `getMessage(messageId)` method on `Session` to fetch a single message by ID
-        - `Peer.representation()`, `Session.representation()`, and `Session.context()` now accept `Message` objects for `searchQuery`
-        - `page`, `size`, and `reverse` pagination controls on all list methods
-
-        ### Changed
-
-        - **Breaking**: `searchQuery` removed from top-level `context()` options — use `representationOptions.searchQuery` instead:
-          ```typescript
-          // Before (v2.0.x)
-          await session.context({ searchQuery: "..." });
-          // After (v2.1.0)
-          await session.context({ representationOptions: { searchQuery: "..." } });
-          ```
-        - List methods (`peers()`, `sessions()`, `messages()`, `workspaces()`) support both the new options object and the legacy raw-filter form
-        - Representation search options now accept strings and content-like objects, including `Message` instances, while rejecting whitespace-only or invalid runtime inputs
-        - **Breaking**: `peer()` and `session()` now always make a get-or-create API call — no more lazy initialization. If you relied on constructing SDK objects without triggering a network request, note that every `peer()` and `session()` call now hits the API:
-          ```typescript
-          // Before (v2.0.x) — no API call
-          const session = honcho.session("my-session");
-          // After (v2.1.0) — makes a get-or-create API call
-          const session = await honcho.session("my-session");
-          ```
-        - Response configuration models now tolerate unknown fields from newer servers for forward compatibility
-        - Moved `@types/node` from `dependencies` to `devDependencies`
-
-        ### Fixed
-
-        - `uploadFile()` now rejects unsupported top-level binary/object inputs and only validates inputs the serializer can actually upload
-        - `uploadFile()` now serializes message configuration using API field names, matching `addMessages()`
-        - Session fetch methods now refresh cached `createdAt` and `isActive` values alongside metadata and configuration
-        </Update>
-        <Update label="v2.0.2">
-        ### Changed
-
-        - Client constructor now rejects unknown options via `.strict()` Zod validation. Previously, misspelled options (e.g., `baseUrl` instead of `baseURL`) were silently ignored, causing the SDK to fall back to defaults. Now a `ZodError` is thrown with the unrecognized key name.
-        - All input schemas now use `.strict()` validation to reject unknown fields.
-        - `FileUploadSchema.configuration` now uses `MessageConfigurationSchema` instead of open record type.
-
-        ### Fixed
-
-        - README example used `baseUrl` instead of `baseURL`.
-        </Update>
-        <Update label="v2.0.1">
+        <Update label="v2.0.1 (Current)">
         ### Added
 
         - `setPeerCard` method
@@ -1183,54 +738,6 @@ Welcome to the Honcho changelog! This section documents all notable changes to t
             - Simplified Honcho client import path
         </Update>
     </Tab>
-    <Tab title="Honcho CLI">
-        [Honcho CLI](https://pypi.org/project/honcho-cli/)
-        <Update label="v0.1.4">
-        ### Added
-
-        - A TTY notice when a newer `honcho-cli` is on PyPI (`uv tool upgrade honcho-cli`). Skipped in JSON mode; disable with `HONCHO_NO_UPDATE_CHECK`
-
-        ### Fixed
-
-        - `--setup` for openai-compatible writes `EMBEDDING_MODEL_CONFIG__OVERRIDES__BASE_URL` into the profile `.env` alongside `LLM_OPENAI_BASE_URL` (#1068)
-        - `--setup` API key prompts echo `*` per character so a paste is visibly received instead of a blank getpass field
-        </Update>
-        <Update label="v0.1.3">
-        ### Added
-
-        - `honcho start`, `honcho stop`, and `honcho status` — run a personal Honcho stack in Docker (API, deriver, Postgres, Redis). Profiles live under `~/.honcho/profiles/`. First start pins `ghcr.io/plastic-labs/honcho:latest` by digest and copies the image `config.toml`. Optional `--setup basic` / `--setup advanced` wizard writes LLM overrides to `.env` (#1029)
-        - `honcho session view` — session transcript table (`--last N`, `--page N --size M`, `--all`, `--reverse`, `--ids`, peer filter via `-p`). Content is shown verbatim, timestamps are normalized to UTC, and the command is read-only: unlike the other session commands it never get-or-creates the session (#1006)
-
-        ### Fixed
-
-        - `honcho message list --last N` no longer stops at the first page of 50 — it walks pages to fill the requested window (#1006)
-        </Update>
-        <Update label="v0.1.2">
-        ### Added
-
-        - Device-code OAuth login for managed Honcho servers. `honcho init` now offers browser-based login (RFC 8628 device authorization grant) when the host advertises the device grant in its OAuth authorization-server metadata; tokens are persisted to `~/.honcho/config.json` and auto-refreshed (#891)
-        - `HONCHO_CONFIG_DIR` environment variable for pointing the CLI at an alternate config directory (#891)
-
-        ### Changed
-
-        - An OAuth grant now records the host it was minted against and is ignored — neither used nor refreshed — when `base_url` points elsewhere, so a staging grant is never sent to production. A live OAuth token takes precedence over a stored `apiKey`, and a dead grant degrades to the saved key with a warning instead of aborting. Device login no longer deletes the shared `apiKey`, which sibling tools read from the same config file (#891)
-        </Update>
-        <Update label="v0.1.1">
-        ### Fixed
-
-        - Declare `click` as an explicit dependency. The CLI imported `click` directly but relied on it being pulled in transitively, so installs without it on the path could fail at runtime (#787)
-        </Update>
-        <Update label="v0.1.0">
-        ### Added
-
-        - Initial release of `honcho-cli` — a terminal for inspecting and managing a Honcho deployment (#424)
-        - `workspace`, `peer`, `session`, `message`, `conclusion`, and `config` command groups for managing resources against any Honcho server
-        - `init` onboarding flow that prompts for and persists connection settings, with flag/env-var pre-seeding for non-interactive use
-        - Per-command flags, environment variables, and a config file for pointing the CLI at different servers (local, self-hosted, or hosted)
-        - Rich terminal output and an agent-usage mode for scripting against the CLI
-        - Documentation and an agent skill for the CLI (#589)
-        </Update>
-    </Tab>
 </Tabs>
 
 ## Getting Help
@@ -1238,4 +745,4 @@ Welcome to the Honcho changelog! This section documents all notable changes to t
 If you encounter issues using the Honcho API or its SDKs:
 
 1. Open an issue on [GitHub](https://github.com/plastic-labs/honcho/issues)
-2. Join our [Discord community](http://discord.gg/honcho) for support
+2. Join our [Discord community](http://discord.gg/plasticlabs) for support

docs/docs.json

@@ -10,10 +10,6 @@
     {
       "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": {
@@ -23,14 +19,21 @@
   },
   "favicon": "/favicon.svg",
   "contextual": {
-    "options": ["copy", "view", "chatgpt", "claude"]
+    "options": [
+      "copy",
+      "view",
+      "chatgpt",
+      "claude"
+    ]
   },
   "navigation": {
     "versions": [
       {
-        "version": "v3.1.1",
+        "version": "v3.0.3",
         "api": {
-          "openapi": ["v3/openapi.json"]
+          "openapi": [
+            "v3/openapi.json"
+          ]
         },
         "tabs": [
           {
@@ -49,34 +52,26 @@
                 "pages": [
                   "v3/documentation/core-concepts/architecture",
                   "v3/documentation/core-concepts/reasoning",
-                  "v3/documentation/core-concepts/representation",
-                  "v3/documentation/core-concepts/design-patterns"
+                  "v3/documentation/core-concepts/representation"
                 ]
               },
               {
                 "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/reasoning-configuration",
+                      "v3/documentation/features/advanced/representation-scopes",
+                      "v3/documentation/features/advanced/summarizer",
                       "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"
+                      "v3/documentation/features/advanced/streaming-response"
                     ]
                   }
                 ]
@@ -85,8 +80,7 @@
                 "group": "Reference",
                 "pages": [
                   "v3/documentation/reference/platform",
-                  "v3/documentation/reference/sdk",
-                  "v3/documentation/reference/cli"
+                  "v3/documentation/reference/sdk"
                 ]
               }
             ]
@@ -96,48 +90,35 @@
             "groups": [
               {
                 "group": "Overview",
-                "pages": ["v3/guides/overview"]
+                "pages": [
+                  "v3/guides/overview",
+                  "v3/guides/file-uploads",
+                  "v3/guides/storing-data"
+                ]
               },
               {
                 "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"
+                  "v3/guides/integrations/claude-code"
                 ]
               },
               {
                 "group": "Migrations",
-                "pages": ["v3/guides/migrations/mem0"]
+                "pages": [
+                  "v3/guides/migrations/mem0"
+                ]
+              },
+              {
+                "group": "Chatbots",
+                "pages": [
+                  "v3/guides/discord",
+                  "v3/guides/telegram"
+                ]
               }
             ]
           },
@@ -148,9 +129,7 @@
                 "group": "Self-Hosting",
                 "pages": [
                   "v3/contributing/self-hosting",
-                  "v3/contributing/configuration",
-                  "v3/contributing/changing-embeddings",
-                  "v3/contributing/troubleshooting"
+                  "v3/contributing/configuration"
                 ]
               },
               {
@@ -167,7 +146,9 @@
             "groups": [
               {
                 "group": "API Documentation",
-                "pages": ["v3/api-reference/introduction"]
+                "pages": [
+                  "v3/api-reference/introduction"
+                ]
               },
               {
                 "group": "workspaces",
@@ -215,18 +196,6 @@
                   "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": [
@@ -257,7 +226,9 @@
               },
               {
                 "group": "miscellaneous",
-                "pages": ["v3/api-reference/endpoint/keys/create-key"]
+                "pages": [
+                  "v3/api-reference/endpoint/keys/create-key"
+                ]
               }
             ]
           },
@@ -278,7 +249,9 @@
       {
         "version": "v2.5.1",
         "api": {
-          "openapi": ["v2/openapi.json"]
+          "openapi": [
+            "v2/openapi.json"
+          ]
         },
         "tabs": [
           {
@@ -325,25 +298,29 @@
             "groups": [
               {
                 "group": "Getting Started",
-                "pages": ["v2/guides/overview"]
+                "pages": [
+                  "v2/guides/overview"
+                ]
               },
               {
                 "group": "Migrations",
-                "pages": ["v2/migrations/from-mem0"]
+                "pages": [
+                  "v2/migrations/from-mem0"
+                ]
               },
               {
                 "group": "Integrations",
                 "pages": [
                   "v2/integrations/crewai",
                   "v2/integrations/langgraph",
-                  "v2/integrations/mcp"
+                  "v2/integrations/mcp",
+                  "v2/integrations/n8n"
                 ]
               },
               {
                 "group": "Application Interfaces",
                 "pages": [
                   "v2/guides/discord",
-                  "v2/guides/n8n",
                   "v2/guides/telegram"
                 ]
               }
@@ -354,7 +331,9 @@
             "groups": [
               {
                 "group": "API Documentation",
-                "pages": ["v2/api-reference/introduction"]
+                "pages": [
+                  "v2/api-reference/introduction"
+                ]
               },
               {
                 "group": "workspaces",
@@ -458,7 +437,9 @@
       {
         "version": "v1.1.0",
         "api": {
-          "openapi": ["openapi.json"]
+          "openapi": [
+            "openapi.json"
+          ]
         },
         "tabs": [
           {
@@ -488,15 +469,23 @@
             "groups": [
               {
                 "group": "Getting Started",
-                "pages": ["v1/guides/overview", "v1/guides/streaming-response"]
+                "pages": [
+                  "v1/guides/overview",
+                  "v1/guides/streaming-response"
+                ]
               },
               {
                 "group": "Application Interfaces",
-                "pages": ["v1/guides/discord", "v1/guides/honcho-mcp"]
+                "pages": [
+                  "v1/guides/discord",
+                  "v1/guides/honcho-mcp"
+                ]
               },
               {
                 "group": "Personal Memory",
-                "pages": ["v1/guides/dialectic-endpoint"]
+                "pages": [
+                  "v1/guides/dialectic-endpoint"
+                ]
               }
             ]
           },
@@ -505,7 +494,9 @@
             "groups": [
               {
                 "group": "API Documentation",
-                "pages": ["v1/api-reference/introduction"]
+                "pages": [
+                  "v1/api-reference/introduction"
+                ]
               },
               {
                 "group": "apps",
@@ -553,7 +544,9 @@
               },
               {
                 "group": "keys",
-                "pages": ["v1/api-reference/endpoint/keys/create-key"]
+                "pages": [
+                  "v1/api-reference/endpoint/keys/create-key"
+                ]
               },
               {
                 "group": "metamessages",
@@ -612,8 +605,8 @@
     }
   },
   "integrations": {
-    "gtm": {
-      "tagId": "GTM-NSPT9PJF"
+    "posthog": {
+      "apiKey": "phc_1yrzzcgywqXGcerkkI4g7C0YfyPMcAKNOOvGcjTCiUk"
     }
   }
 }

docs/package.json

@@ -11,7 +11,8 @@
   "author": "",
   "license": "ISC",
   "dependencies": {
-    "@mintlify/scraping": "^4.0.467"
+    "@mintlify/scraping": "^4.0.467",
+    "honcho-ai": "^0.0.11"
   },
   "devDependencies": {
     "mint": "^4.2.204"

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

docs/snippets/cli-commands.mdx

@@ -1,652 +0,0 @@
-{/*
-  GENERATED by honcho-cli/scripts/generate_cli_docs.py — do not edit.
-  Re-generate with: uv run --package honcho-cli python honcho-cli/scripts/generate_cli_docs.py
-  Source of truth: honcho-cli/src/honcho_cli/commands/
-*/}
-
-## honcho conclusion
-
-List, search, create, and delete peer conclusions (Honcho's memory atoms).
-
-<AccordionGroup>
-<Accordion title="create">
-Create a conclusion.
-
-```bash
-honcho conclusion create <content>
-```
-
-<ParamField path="content" type="string" required />
-<ParamField path="--observer" type="string">
-  Observer peer ID.
-</ParamField>
-<ParamField path="--observed" type="string">
-  Observed peer ID.
-</ParamField>
-<ParamField path="--session" type="string">
-  Session context. Short alias: `-s`.
-</ParamField>
-</Accordion>
-<Accordion title="delete">
-Delete a conclusion.
-
-```bash
-honcho conclusion delete <conclusion_id>
-```
-
-<ParamField path="conclusion_id" type="string" required />
-<ParamField path="--observer" type="string">
-  Observer peer ID.
-</ParamField>
-<ParamField path="--observed" type="string">
-  Observed peer ID.
-</ParamField>
-<ParamField path="--yes" type="boolean">
-  Skip confirmation. Short alias: `-y`.
-</ParamField>
-</Accordion>
-<Accordion title="list">
-List conclusions.
-
-```bash
-honcho conclusion list
-```
-
-<ParamField path="--observer" type="string">
-  Observer peer ID.
-</ParamField>
-<ParamField path="--observed" type="string">
-  Observed peer ID.
-</ParamField>
-<ParamField path="--limit" type="number" default="10">
-  Max results.
-</ParamField>
-</Accordion>
-<Accordion title="search">
-Semantic search over conclusions.
-
-```bash
-honcho conclusion search <query>
-```
-
-<ParamField path="query" type="string" required />
-<ParamField path="--observer" type="string">
-  Observer peer ID.
-</ParamField>
-<ParamField path="--observed" type="string">
-  Observed peer ID.
-</ParamField>
-<ParamField path="--top-k" type="number" default="10">
-  Max results.
-</ParamField>
-</Accordion>
-</AccordionGroup>
-
-## honcho config
-
-Inspect CLI configuration.
-
-```bash
-honcho config
-```
-
-
-## honcho doctor
-
-Verify config and connectivity. Scope with -w / -p to check workspace, peer, and queue health.
-
-```bash
-honcho doctor
-```
-
-
-## honcho help
-
-Show help message.
-
-```bash
-honcho help
-```
-
-
-## honcho init
-
-Set API key and server URL in ~/.honcho/config.json.
-
-Press Enter to keep the current value or type a replacement.
-Workspace / peer / session scoping is per-command via -w / -p / -s
-or HONCHO_* env vars — never persisted.
-
-```bash
-honcho init
-```
-
-<ParamField path="--api-key" type="string">
-  API key (admin JWT).
-</ParamField>
-<ParamField path="--base-url" type="string">
-  Honcho API URL (e.g. https://api.honcho.dev, http://localhost:8000).
-</ParamField>
-
-## honcho message
-
-List, create, and get messages within a session.
-
-<AccordionGroup>
-<Accordion title="create">
-Create a message in a session.
-
-```bash
-honcho message create <content>
-```
-
-<ParamField path="content" type="string" required />
-<ParamField path="--peer" type="string" required>
-  Peer ID of the message sender. Short alias: `-p`.
-</ParamField>
-<ParamField path="--metadata" type="string">
-  JSON metadata to associate with the message.
-</ParamField>
-<ParamField path="--session" type="string">
-  Session ID. Short alias: `-s`.
-</ParamField>
-</Accordion>
-<Accordion title="get">
-Get a single message by ID.
-
-```bash
-honcho message get <message_id>
-```
-
-<ParamField path="message_id" type="string" required />
-<ParamField path="--session" type="string">
-  Session ID. Short alias: `-s`.
-</ParamField>
-</Accordion>
-<Accordion title="list">
-List messages in a session. Scoped to a peer with -p.
-
-```bash
-honcho message list [<session_id>]
-```
-
-<ParamField path="session_id" type="string" />
-<ParamField path="--last" type="number" default="20">
-  Number of recent messages.
-</ParamField>
-<ParamField path="--reverse" type="boolean">
-  Show oldest first (default is newest first).
-</ParamField>
-<ParamField path="--brief" type="boolean">
-  Show only IDs, peer, token count, and created_at (no content).
-</ParamField>
-<ParamField path="--peer" type="string">
-  Filter by peer ID. Short alias: `-p`.
-</ParamField>
-</Accordion>
-</AccordionGroup>
-
-## honcho peer
-
-List, create, chat with, search, and manage peers and their representations.
-
-<AccordionGroup>
-<Accordion title="card">
-Get raw peer card content.
-
-```bash
-honcho peer card [<peer_id>]
-```
-
-<ParamField path="peer_id" type="string" />
-<ParamField path="--target" type="string">
-  Target peer for relationship card.
-</ParamField>
-</Accordion>
-<Accordion title="chat">
-Query the dialectic about a peer.
-
-```bash
-honcho peer chat <query>
-```
-
-<ParamField path="query" type="string" required />
-<ParamField path="--target" type="string">
-  Target peer for perspective.
-</ParamField>
-<ParamField path="--reasoning" type="string">
-  Reasoning level: minimal, low, medium, high, max. Short alias: `-r`.
-</ParamField>
-</Accordion>
-<Accordion title="create">
-Create or get a peer.
-
-```bash
-honcho peer create <peer_id>
-```
-
-<ParamField path="peer_id" type="string" required />
-<ParamField path="--observe-me" type="boolean">
-  Whether Honcho will form a representation of this peer. Negate with `--no-observe-me`.
-</ParamField>
-<ParamField path="--metadata" type="string">
-  JSON metadata to associate with the peer.
-</ParamField>
-</Accordion>
-<Accordion title="get-metadata">
-Get metadata for a peer.
-
-```bash
-honcho peer get-metadata [<peer_id>]
-```
-
-<ParamField path="peer_id" type="string" />
-</Accordion>
-<Accordion title="inspect">
-Inspect a peer: card, session count, recent conclusions.
-
-```bash
-honcho peer inspect [<peer_id>]
-```
-
-<ParamField path="peer_id" type="string" />
-</Accordion>
-<Accordion title="list">
-List all peers in the workspace.
-
-```bash
-honcho peer list
-```
-
-</Accordion>
-<Accordion title="representation">
-Get the formatted representation for a peer.
-
-```bash
-honcho peer representation [<peer_id>]
-```
-
-<ParamField path="peer_id" type="string" />
-<ParamField path="--target" type="string">
-  Target peer to get representation about.
-</ParamField>
-<ParamField path="--search-query" type="string">
-  Semantic search query to filter conclusions.
-</ParamField>
-<ParamField path="--max-conclusions" type="number">
-  Maximum number of conclusions to include.
-</ParamField>
-</Accordion>
-<Accordion title="search">
-Search a peer's messages.
-
-```bash
-honcho peer search <query>
-```
-
-<ParamField path="query" type="string" required />
-<ParamField path="--limit" type="number" default="10">
-  Max results.
-</ParamField>
-</Accordion>
-<Accordion title="set-metadata">
-Set metadata for a peer.
-
-```bash
-honcho peer set-metadata <metadata>
-```
-
-<ParamField path="metadata" type="string" required />
-<ParamField path="--peer" type="string">
-  Peer ID (uses default if omitted). Short alias: `-p`.
-</ParamField>
-</Accordion>
-</AccordionGroup>
-
-## honcho session
-
-List, inspect, view, create, delete, and manage conversation sessions and their peers.
-
-<AccordionGroup>
-<Accordion title="add-peers">
-Add peers to a session.
-
-```bash
-honcho session add-peers <session_id> <peer_ids>
-```
-
-<ParamField path="session_id" type="string" required />
-<ParamField path="peer_ids" type="string" required />
-</Accordion>
-<Accordion title="context">
-Get session context (what an agent would see).
-
-```bash
-honcho session context [<session_id>]
-```
-
-<ParamField path="session_id" type="string" />
-<ParamField path="--tokens" type="number">
-  Token budget.
-</ParamField>
-<ParamField path="--summary" type="boolean" default="true">
-  Include summary. Negate with `--no-summary`.
-</ParamField>
-</Accordion>
-<Accordion title="create">
-Create or get a session.
-
-```bash
-honcho session create <session_id>
-```
-
-<ParamField path="session_id" type="string" required />
-<ParamField path="--peers" type="string">
-  Comma-separated peer IDs to add to the session.
-</ParamField>
-<ParamField path="--metadata" type="string">
-  JSON metadata to associate with the session.
-</ParamField>
-</Accordion>
-<Accordion title="delete">
-Delete a session and all its data. Destructive — requires --yes or interactive confirm.
-
-```bash
-honcho session delete [<session_id>]
-```
-
-<ParamField path="session_id" type="string" />
-<ParamField path="--yes" type="boolean">
-  Skip confirmation. Short alias: `-y`.
-</ParamField>
-</Accordion>
-<Accordion title="get-metadata">
-Get metadata for a session.
-
-```bash
-honcho session get-metadata [<session_id>]
-```
-
-<ParamField path="session_id" type="string" />
-</Accordion>
-<Accordion title="inspect">
-Inspect a session: peers, message count, summaries, config.
-
-```bash
-honcho session inspect [<session_id>]
-```
-
-<ParamField path="session_id" type="string" />
-</Accordion>
-<Accordion title="list">
-List sessions in the workspace.
-
-```bash
-honcho session list
-```
-
-<ParamField path="--peer" type="string">
-  Filter by peer. Short alias: `-p`.
-</ParamField>
-</Accordion>
-<Accordion title="peers">
-List peers in a session.
-
-```bash
-honcho session peers [<session_id>]
-```
-
-<ParamField path="session_id" type="string" />
-</Accordion>
-<Accordion title="remove-peers">
-Remove peers from a session.
-
-```bash
-honcho session remove-peers <session_id> <peer_ids>
-```
-
-<ParamField path="session_id" type="string" required />
-<ParamField path="peer_ids" type="string" required />
-</Accordion>
-<Accordion title="representation">
-Get the representation of a peer within a session.
-
-```bash
-honcho session representation <peer_id> [<session_id>]
-```
-
-<ParamField path="peer_id" type="string" required />
-<ParamField path="session_id" type="string" />
-<ParamField path="--target" type="string">
-  Target peer (what peer_id knows about target).
-</ParamField>
-<ParamField path="--search-query" type="string">
-  Semantic search query to filter conclusions.
-</ParamField>
-<ParamField path="--max-conclusions" type="number">
-  Maximum number of conclusions to include.
-</ParamField>
-</Accordion>
-<Accordion title="search">
-Search messages in a session.
-
-```bash
-honcho session search <query> [<session_id>]
-```
-
-<ParamField path="query" type="string" required />
-<ParamField path="session_id" type="string" />
-<ParamField path="--limit" type="number" default="10">
-  Max results.
-</ParamField>
-</Accordion>
-<Accordion title="set-metadata">
-Set metadata for a session.
-
-```bash
-honcho session set-metadata [<session_id>]
-```
-
-<ParamField path="session_id" type="string" />
-<ParamField path="--data" type="string" required>
-  JSON metadata to set (e.g. '\{"key": "value"\}'). Short alias: `-d`.
-</ParamField>
-</Accordion>
-<Accordion title="summaries">
-Get session summaries (short + long).
-
-```bash
-honcho session summaries [<session_id>]
-```
-
-<ParamField path="session_id" type="string" />
-</Accordion>
-<Accordion title="view">
-View a session transcript as a chat log.
-
-Modes (pick one):
-
-- default / --last N: tail of the conversation (most recent N)
-- --page N [--size M]: page through the full transcript
-- --all: every message
-
-Paging follows the requested order: --page 1 starts at the oldest message,
-or the newest with --reverse.
-
-Human mode prints a row-delimited table. JSON mode emits the message list
-(same shape as message list).
-
-```bash
-honcho session view [<session_id>]
-```
-
-<ParamField path="session_id" type="string" />
-<ParamField path="--last" type="number">
-  Show only the N most recent messages (default when no --page/--all: 50).
-</ParamField>
-<ParamField path="--page" type="number">
-  1-indexed page of the full transcript. Use for page 2+.
-</ParamField>
-<ParamField path="--size" type="number">
-  Messages per page; requires --page (1-100, default: 50).
-</ParamField>
-<ParamField path="--all" type="boolean">
-  Show the full transcript (every page).
-</ParamField>
-<ParamField path="--reverse" type="boolean">
-  Newest first (default is chronological: oldest at top).
-</ParamField>
-<ParamField path="--ids" type="boolean">
-  Include message IDs in the transcript.
-</ParamField>
-<ParamField path="--peer" type="string">
-  Filter by peer ID. Short alias: `-p`.
-</ParamField>
-</Accordion>
-</AccordionGroup>
-
-## honcho start
-
-Start a local Honcho stack (API, deriver, Postgres, Redis).
-
-Requires Docker. Uses cloud LLM providers. Does not change the CLI's
-configured server URL — pass HONCHO_BASE_URL to talk to this stack.
-``--setup basic`` or ``--setup advanced`` runs an interactive config wizard.
-
-```bash
-honcho start
-```
-
-<ParamField path="--profile" type="string" default="local">
-  Local stack profile name.
-</ParamField>
-<ParamField path="--api-port" type="string">
-  Host port for the API.
-</ParamField>
-<ParamField path="--db-port" type="string">
-  Host port for Postgres.
-</ParamField>
-<ParamField path="--redis-port" type="string">
-  Host port for Redis.
-</ParamField>
-<ParamField path="--setup" type="string">
-  Interactive config wizard: basic (provider/model) or advanced (embeddings, deriver, dialectic, dreams, flush).
-</ParamField>
-<ParamField path="--image" type="string">
-  Honcho image to pull and pin by digest (default: ghcr.io/plastic-labs/honcho:latest).
-</ParamField>
-<ParamField path="--timeout" type="string" default="180">
-  Seconds to wait for /health after compose up.
-</ParamField>
-
-## honcho status
-
-Show local stack endpoints and container health.
-
-With no ``--profile``, lists every stack under ``~/.honcho/profiles/``.
-
-```bash
-honcho status
-```
-
-<ParamField path="--profile" type="string">
-  Limit to this profile. Omit to show every local stack.
-</ParamField>
-
-## honcho stop
-
-Stop the local stack started by `honcho start`. Keeps data unless --wipe.
-
-```bash
-honcho stop
-```
-
-<ParamField path="--profile" type="string" default="local">
-  Local stack profile name.
-</ParamField>
-<ParamField path="--wipe" type="boolean">
-  Also delete volumes (Postgres data).
-</ParamField>
-
-## honcho workspace
-
-List, create, inspect, delete, and search workspaces.
-
-<AccordionGroup>
-<Accordion title="create">
-Create or get a workspace.
-
-```bash
-honcho workspace create <workspace_id>
-```
-
-<ParamField path="workspace_id" type="string" required />
-<ParamField path="--metadata" type="string">
-  JSON metadata to associate with the workspace.
-</ParamField>
-</Accordion>
-<Accordion title="delete">
-Delete a workspace. Use --dry-run first to see what will be deleted.
-
-Requires --yes to skip confirmation, or will prompt interactively.
-If sessions exist, requires --cascade to delete them first.
-
-```bash
-honcho workspace delete <workspace_id>
-```
-
-<ParamField path="workspace_id" type="string" required />
-<ParamField path="--yes" type="boolean">
-  Skip confirmation prompt (for scripted/agent use). Short alias: `-y`.
-</ParamField>
-<ParamField path="--cascade" type="boolean">
-  Delete all sessions before deleting the workspace.
-</ParamField>
-<ParamField path="--dry-run" type="boolean">
-  Show what would be deleted without deleting.
-</ParamField>
-</Accordion>
-<Accordion title="inspect">
-Inspect a workspace: peers, sessions, config.
-
-```bash
-honcho workspace inspect [<workspace_id>]
-```
-
-<ParamField path="workspace_id" type="string" />
-</Accordion>
-<Accordion title="list">
-List all accessible workspaces.
-
-```bash
-honcho workspace list
-```
-
-</Accordion>
-<Accordion title="queue-status">
-Get queue processing status.
-
-```bash
-honcho workspace queue-status
-```
-
-<ParamField path="--observer" type="string">
-  Filter by observer peer.
-</ParamField>
-<ParamField path="--sender" type="string">
-  Filter by sender peer.
-</ParamField>
-</Accordion>
-<Accordion title="search">
-Search messages across workspace.
-
-```bash
-honcho workspace search <query>
-```
-
-<ParamField path="query" type="string" required />
-<ParamField path="--limit" type="number" default="10">
-  Max results.
-</ParamField>
-</Accordion>
-</AccordionGroup>

docs/v1/contributing/guidelines.mdx

@@ -11,7 +11,7 @@ indicate a feature or bug fix you are working on.
 
 Once you have finished your contribution make a PR , and it will be reviewed by
 a project manager. Feel free to join us in our
-[discord](http://discord.gg/honcho) to discuss your changes or get help.
+[discord](http://discord.gg/plasticlabs) to discuss your changes or get help.
 
 Your changes will undergo a period of testing and discussion before finally
 being entered into the `main` branch and being staged for release. For more

docs/v1/guides/honcho-mcp.mdx

@@ -59,4 +59,4 @@ Finally, Claude needs instructions on how to use Honcho. The Desktop app doesn't
 
 <Note>Be sure to update the \<app_name\> and \<user_name\> variables in the instructions.txt file.</Note>
 
-Claude should then query for insights before responding and write your messages to storage! If you come up with more creative ways to get Claude to manage its own memory with Honcho, feel free to [let us know](https://discord.gg/honcho) or make a PR on this [repo](https://github.com/plastic-labs/honcho-mcp/tree/main)!
+Claude should then query for insights before responding and write your messages to storage! If you come up with more creative ways to get Claude to manage its own memory with Honcho, feel free to [let us know](https://discord.gg/plasticlabs) or make a PR on this [repo](https://github.com/plastic-labs/honcho-mcp/tree/main)!

docs/v2/contributing/configuration.mdx

@@ -96,14 +96,14 @@ If you have this in `config.toml`:
 
 ```toml
 [db]
-CONNECTION_URI = "postgresql+psycopg://localhost/honcho_dev"
+CONNECTION_URI = "postgresql://localhost/honcho_dev"
 POOL_SIZE = 10
 ```
 
 You can override just the connection URI in production:
 
 ```bash
-export DB_CONNECTION_URI="postgresql+psycopg://prod-server/honcho_prod"
+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.
@@ -149,7 +149,7 @@ LOCAL_METRICS_FILE=metrics.jsonl
 DB_CONNECTION_URI=postgresql+psycopg://username:password@host:port/database
 
 # Example for local development
-DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@localhost:5432/postgres
+DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@localhost:5432/honcho
 
 # Example for production
 DB_CONNECTION_URI=postgresql+psycopg://honcho_user:secure_password@db.example.com:5432/honcho_prod
@@ -161,7 +161,7 @@ DB_CONNECTION_URI=postgresql+psycopg://honcho_user:secure_password@db.example.co
 DB_SCHEMA=public
 DB_POOL_SIZE=10
 DB_MAX_OVERFLOW=20
-DB_POOL_TIMEOUT=5
+DB_POOL_TIMEOUT=30
 DB_POOL_RECYCLE=300
 DB_POOL_PRE_PING=true
 DB_SQL_DEBUG=false

docs/v2/contributing/guidelines.mdx

@@ -5,31 +5,13 @@ icon: 'handshake'
 
 Thank you for your interest in contributing to Honcho! This guide outlines the process for contributing to the project and our development conventions.
 
-## Before you write code
-
-**Every pull request needs an issue, and that issue needs the `maintainer-approved` label.**
-
-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.
-
-So, in order:
-
-1. **Find approved work.** Browse [issues labelled `maintainer-approved`](https://github.com/plastic-labs/honcho/issues?q=is%3Aissue+is%3Aopen+label%3Amaintainer-approved). That label is the queue of things we have agreed should be built. Anything in it is fair game — comment on the issue to claim it.
-
-2. **Or open an issue and get it approved.** Use the [issue templates](https://github.com/plastic-labs/honcho/issues/new/choose). Maintainers triage and apply the label.
-
-3. **If you feel strongly about an issue, come to [Discord](https://discord.gg/honcho).** This is the fastest path by a wide margin. Maintainers are more active there than in the issue tracker, and a five-minute conversation about what you want to build usually resolves whether it fits before either side spends real time on it.
-
-4. **Then open the PR** and link the issue — either `Fixes #123` in the description, or **Development → link an issue** in the sidebar. Both work.
-
-Small exceptions we will not be pedantic about: fixing a typo, a broken link, or an obviously wrong code sample. Open the PR, explain it in one line, and we will sort out the issue linkage.
-
 ## Getting Started
 
 Before you start contributing, please:
 
 1. **Set up your development environment** - Follow the [Local Development guide](https://github.com/plastic-labs/honcho/blob/main/CONTRIBUTING.md#local-development) in the Honcho repository to get Honcho running locally.
 
-2. **Join our community** - Feel free to join us in our [Discord](https://discord.gg/honcho) to discuss your changes, get help, or ask questions.
+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.
 
 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.
 
@@ -112,7 +94,7 @@ git commit -m "docs(readme): update installation instructions"
 3. Fill out the pull request template with:
    - A clear description of what changes you've made
    - The motivation for the changes
-   - A link to the approved issue — `Fixes #123` in the description, or **Development → link an issue** in the sidebar. This is required; see [Before you write code](#before-you-write-code).
+   - Any relevant issue numbers (use "Closes #123" to auto-close issues)
    - Screenshots or examples if applicable
 
 ## Coding Standards
@@ -146,7 +128,7 @@ git commit -m "docs(readme): update installation instructions"
 
 ## Review Process
 
-1. **Automated checks** - Your PR will run through automated checks including tests, linting, and the issue gate
+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
@@ -171,21 +153,17 @@ We welcome various types of contributions:
 When reporting bugs or requesting features:
 
 1. Check if the issue already exists
-2. Use the appropriate [issue template](https://github.com/plastic-labs/honcho/issues/new/choose) (bug, memory/recall quality, feature, integration, or documentation)
+2. Use the appropriate issue template
 3. Provide clear reproduction steps for bugs
-4. Include relevant environment information (managed vs self-hosted, server version, SDK)
+4. Include relevant environment information
 5. Be specific about expected vs actual behavior
-6. Redact secrets, JWTs, and production user content
 
 ## Questions and Support
 
-- **General questions** - Join our [Discord](https://discord.gg/honcho)
-- **Bug reports** - GitHub issues → Bug report template
-- **Memory / recall quality** - GitHub issues → Memory / recall quality template
-- **Feature requests** - GitHub issues → Feature request template
-- **Integrations / plugins / app-store listings** - GitHub issues → Integration request template
-- **Documentation issues** - GitHub issues → Documentation issue template
-- **Security issues** - Report **privately** only — see [`SECURITY.md`](https://github.com/plastic-labs/honcho/blob/main/SECURITY.md) (GitHub Private Vulnerability Reporting or email). Do not open a public issue.
+- **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
 

docs/v2/contributing/self-hosting.mdx

@@ -59,8 +59,7 @@ OPENAI_API_KEY=your-openai-api-key
 ANTHROPIC_API_KEY=your-anthropic-api-key
 
 # Database will be created automatically by Docker
-DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@database:5432/postgres
-
+DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@database:5432/honcho
 
 # Disable auth for local development
 AUTH_USE_AUTH=false
@@ -135,21 +134,24 @@ Download from [postgresql.org](https://www.postgresql.org/download/windows/)
 
 ```bash
 docker run --name honcho-db \
+  -e POSTGRES_DB=honcho \
   -e POSTGRES_USER=postgres \
   -e POSTGRES_PASSWORD=postgres \
   -p 5432:5432 \
   -d pgvector/pgvector:pg15
 ```
 
-### 3. Enable Extensions
+### 3. Create Database and Enable Extensions
 
-Connect to PostgreSQL and enable pgvector:
+Connect to PostgreSQL and set up the database:
 
 ```bash
 # Connect to PostgreSQL
 psql -U postgres
 
-# Enable extensions on the default database
+# Create database and enable extensions
+CREATE DATABASE honcho;
+\c honcho
 CREATE EXTENSION IF NOT EXISTS vector;
 CREATE EXTENSION IF NOT EXISTS pg_trgm;
 \q
@@ -167,7 +169,7 @@ Edit `.env` with your configuration:
 
 ```bash
 # Database connection
-DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@localhost:5432/postgres
+DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@localhost:5432/honcho
 
 # Optional API keys (required for LLM features)
 OPENAI_API_KEY=your-openai-api-key
@@ -277,7 +279,7 @@ const client = new Honcho({
 - **Explore the API**: Check out the [API Reference](/v2/api-reference/introduction)
 - **Try the SDKs**: See our [guides](/v2/guides) for examples
 - **Configure Honcho**: Visit the [Configuration Guide](./configuration) for detailed settings
-- **Join the community**: [Discord](https://discord.gg/honcho)
+- **Join the community**: [Discord](https://discord.gg/plasticlabs)
 
 ## Troubleshooting
 
@@ -308,7 +310,7 @@ const client = new Honcho({
 ### Getting Help
 
 - **GitHub Issues**: [Report bugs](https://github.com/plastic-labs/honcho/issues)
-- **Discord**: [Join our community](https://discord.gg/honcho)
+- **Discord**: [Join our community](https://discord.gg/plasticlabs)
 - **Documentation**: Check the [Configuration Guide](./configuration) for detailed settings
 
 ## Production Considerations

docs/v2/documentation/core-concepts/configuration.mdx

@@ -353,20 +353,6 @@ import { Honcho } from "@honcho-ai/sdk";
 ```
 </CodeGroup>
 
-### Observation and Peer Join Order
-
-Reasoning tasks are scheduled at the time a message is created, based on which peers are in the session **at that moment**. Honcho does not retroactively schedule reasoning for peers that join later.
-
-This means:
-
-- If Peer C joins a session **after** messages from Peer A and Peer B have already been sent, Peer C will **not** receive reasoning tasks for those earlier messages—even if Peer C has `observe_others` enabled.
-- Peer C will only begin observing new messages sent after they join the session.
-- Similarly, if a peer leaves a session, they stop being included as an observer for any messages sent after their departure.
-
-<Warning>
-There is no retroactive reasoning. If your application needs an observer peer to reason about prior conversation history, add the peer to the session **before** messages are sent. Alternatively use the .chat() endpoint to include the conversation history in the agent's context, regardless of if they were reasoned against or not
-</Warning>
-
 ## Full Configuration Schema Reference
 
 ### Workspace & Session Configuration

docs/v2/documentation/introduction/overview.mdx

@@ -115,5 +115,5 @@ fundamental concepts </Card> </CardGroup>
 ## Community & Support
 
 - **GitHub**: [plastic-labs/honcho](https://github.com/plastic-labs/honcho)
-- **Discord**: [Join our community](http://discord.gg/honcho)
+- **Discord**: [Join our community](http://discord.gg/plasticlabs)
 - **Issues**: Report bugs and request features on GitHub

docs/v2/documentation/introduction/vibecoding.mdx

@@ -25,10 +25,10 @@ I want to start building with Honcho - a memory and personalization platform for
 ## Honcho Resources
 
 **Documentation:**
-- Main docs: https://honcho.dev/docs
-- API Reference: https://honcho.dev/docs/v2/api-reference/introduction
-- Quickstart: https://honcho.dev/docs/v2/documentation/introduction/quickstart
-- Architecture: https://honcho.dev/docs/v2/documentation/reference/architecture
+- Main docs: https://docs.honcho.dev
+- API Reference: https://docs.honcho.dev/v2/api-reference/introduction
+- Quickstart: https://docs.honcho.dev/v2/documentation/introduction/quickstart
+- Architecture: https://docs.honcho.dev/v2/documentation/reference/architecture
 
 **Code & Examples:**
 - Core repo: https://github.com/plastic-labs/honcho

docs/v2/documentation/reference/guided-tutorial.mdx

@@ -422,4 +422,4 @@ Congratulations! You've built a complete personal AI assistant with Honcho that
 - [SDK Reference](/v2/documentation/reference/sdk)
 - [API Reference](/v2/api-reference/introduction)
 - [More Examples](/v2/guides/overview)
-- [Discord Community](http://discord.gg/honcho)
+- [Discord Community](http://discord.gg/plasticlabs)

docs/v2/documentation/reference/platform.mdx

@@ -206,7 +206,7 @@ Dive into our [API Reference](/v2/api-reference) to explore all available endpoi
   <Card title="Sign up to Honcho Platform" icon="rocket" href="https://app.honcho.dev">
     Get started with managed Honcho instances
   </Card>
-  <Card title="Join our Discord" icon="discord" href="http://discord.gg/honcho">
+  <Card title="Join our Discord" icon="discord" href="http://discord.gg/plasticlabs">
     Connect with 1000+ developers building with Honcho
   </Card>
   <Card title="Contribute to Honcho" icon="code" href="/v2/contributing/guidelines">

docs/v2/integrations/crewai.mdx

@@ -97,7 +97,7 @@ results = storage.search("query", filters={
 })
 ```
 
-For the full filter syntax including logical operators (AND, OR, NOT), comparison operators, and metadata filtering, see the [Using Filters](https://honcho.dev/docs/v2/documentation/core-concepts/features/using-filters) documentation.
+For the full filter syntax including logical operators (AND, OR, NOT), comparison operators, and metadata filtering, see the [Using Filters](https://docs.honcho.dev/v2/documentation/core-concepts/features/using-filters) documentation.
 
 <Note>
 For comprehensive details about CrewAI's memory system, see the [official CrewAI Memory documentation](https://docs.crewai.com/en/concepts/memory).

docs/v2/integrations/mcp.mdx

@@ -70,4 +70,4 @@ You may customize your assistant name and/or workspace ID. Both are optional.
 
 4. Finally, Claude needs instructions on how to use Honcho. The Desktop app doesn't allow you to add system prompts directly, but you can create a project and paste these [instructions](https://raw.githubusercontent.com/plastic-labs/honcho/refs/heads/main/mcp/instructions.md) into the "Project Instructions" field.
 
-Claude should then query for insights before responding and write your messages to storage! If you come up with more creative ways to get Claude to manage its own memory with Honcho, feel free to [let us know](https://discord.gg/honcho) or make a PR on this [repo](https://github.com/plastic-labs/honcho/tree/main/mcp)!
+Claude should then query for insights before responding and write your messages to storage! If you come up with more creative ways to get Claude to manage its own memory with Honcho, feel free to [let us know](https://discord.gg/plasticlabs) or make a PR on this [repo](https://github.com/plastic-labs/honcho/tree/main/mcp)!

docs/v3/api-reference/endpoint/health-check.mdx

@@ -1,3 +0,0 @@
----
-openapi: get /health
----

docs/v3/api-reference/endpoint/keys/create-key.mdx

@@ -1,15 +1,3 @@
 ---
 openapi: post /v3/keys
 ---
-
-<Note>
-Requires an admin key. On Honcho Cloud (`api.honcho.dev`) the returned key is a
-real cloud key on the calling key's instance, attributed to its owner and
-revocable from the [API Keys page](https://app.honcho.dev/api-keys). On a
-self-hosted instance it returns an error when `AUTH_USE_AUTH` is disabled.
-
-Provide at least one of `workspace_id`, `peer_id`, or `session_id` — a request
-carrying none of them is rejected. A key scoped to a peer or a session must also
-carry its `workspace_id`. On Honcho Cloud, pass either `admin=true` or a
-`workspace_id`.
-</Note>

docs/v3/api-reference/endpoint/scopes/add-sessions-to-scope.mdx

@@ -1,3 +0,0 @@
----
-openapi: post /v3/workspaces/{workspace_id}/scopes/{scope_id}/sessions
----

docs/v3/api-reference/endpoint/scopes/get-or-create-scope.mdx

@@ -1,3 +0,0 @@
----
-openapi: post /v3/workspaces/{workspace_id}/scopes
----

docs/v3/api-reference/endpoint/scopes/get-scope-sessions.mdx

@@ -1,3 +0,0 @@
----
-openapi: post /v3/workspaces/{workspace_id}/scopes/{scope_id}/sessions/list
----

docs/v3/api-reference/endpoint/scopes/get-scope-status.mdx

@@ -1,3 +0,0 @@
----
-openapi: get /v3/workspaces/{workspace_id}/scopes/{scope_id}/status
----

docs/v3/api-reference/endpoint/scopes/get-scope.mdx

@@ -1,3 +0,0 @@
----
-openapi: get /v3/workspaces/{workspace_id}/scopes/{scope_id}
----

docs/v3/api-reference/endpoint/scopes/get-scopes.mdx

@@ -1,3 +0,0 @@
----
-openapi: post /v3/workspaces/{workspace_id}/scopes/list
----

docs/v3/api-reference/endpoint/scopes/remove-session-from-scope.mdx

@@ -1,3 +0,0 @@
----
-openapi: delete /v3/workspaces/{workspace_id}/scopes/{scope_id}/sessions/{session_id}
----

docs/v3/contributing/changing-embeddings.mdx

@@ -1,62 +0,0 @@
----
-title: "Changing Embeddings"
-description: "How to switch embedding dimension or model on a Honcho deployment"
-icon: "rotate"
----
-
-## Short answer: you can't, in place.
-
-The embedding dimension is **machine-enforced** as immutable for the life of a deployment. The embedding model is **operator-owned** as immutable by contract. The supported way to change either is:
-
-1. Stand up a new deployment at the desired configuration.
-2. Replay or re-embed your data into it out-of-band.
-3. Cut traffic over to the new deployment.
-
-The rest of this page explains why, and what the safety boundaries actually are.
-
-## Why dimension is enforced and model is not
-
-On boot, both the API (`src/main.py` lifespan) and the deriver (`src/deriver/__main__.py`) run the validator in `src/startup/embedding_validator.py`. It does a schema-qualified `pg_attribute` lookup against `documents.embedding` and `message_embeddings.embedding`, decodes the declared `atttypmod`, and compares it to `EMBEDDING_VECTOR_DIMENSIONS`. A mismatch crashes the process with an actionable error before any HTTP route is served or any queue task is processed.
-
-There is no equivalent check for the model. The pgvector column does not record what model produced the vectors inside it, and this design intentionally avoids adding new persistent metadata fields. The runtime has no way to detect that you swapped `text-embedding-3-small` for a different model that emits the same dimension.
-
-That last point is a real footgun:
-
-<Warning>
-Changing `EMBEDDING_MODEL_CONFIG__MODEL` to a different model at the **same dimension** (for example `text-embedding-3-small@1536` → `text-embedding-3-large` truncated to 1536) will silently succeed. New writes will use the new model; existing rows still hold vectors from the old model; recall quality will degrade with no startup or runtime warning.
-
-Treat model identity as a contract you own. If you need to change it, follow the destroy + rebuild path below.
-</Warning>
-
-## Recipe: changing dim or model
-
-Concretely, for either a dim change or a model change:
-
-1. **Provision the new deployment** with the target environment.
-
-   ```bash
-   # On the new deployment:
-   export EMBEDDING_VECTOR_DIMENSIONS=768
-   export EMBEDDING_MODEL_CONFIG__TRANSPORT=openai
-   export EMBEDDING_MODEL_CONFIG__MODEL=nomic-embed-text
-   export EMBEDDING_MODEL_CONFIG__OVERRIDES__BASE_URL=http://your-ollama:11434/v1
-   alembic upgrade head
-   uv run python scripts/configure_embeddings.py --dry-run
-   uv run python scripts/configure_embeddings.py --yes
-   ```
-
-2. **Replay your source data** (messages, documents, ingested content) into the new deployment via your normal application path. Honcho's existing message-creation API will re-derive embeddings using the new configuration. There is no in-place re-embedding tool — that would be a separate spec covering atomicity, cost-per-token, and dialectic-during-migration semantics.
-
-3. **Cut over** at your application layer (DNS, load balancer, feature flag — whatever you use). The old deployment can stay running until you are confident in the new one; this design does not require an atomic switch.
-
-The startup validator on the new deployment will refuse to start if step 1's `configure_embeddings.py` did not run, so a misconfiguration cannot quietly write wrong-dim vectors into the new schema.
-
-## Edge case: truncation at the default dimension
-
-If you are using `text-embedding-3-large` but truncating to 1536 (the default), be aware that `EMBEDDING_MODEL_CONFIG__DIMENSIONS_MODE=auto` will **not** forward `dimensions=` to the API — `auto` interprets the default as "operator did not opt into a non-default dim." The provider will return native 3072, the response-dim validator will reject it, and the request will fail.
-
-For this case, either set `EMBEDDING_VECTOR_DIMENSIONS=1536` explicitly (so `auto` knows the operator opted in), or set `EMBEDDING_MODEL_CONFIG__DIMENSIONS_MODE=always`.
-
-## Backend swap (turbopuffer ↔ lancedb ↔ pgvector) is a different operation
-
-Switching the *storage backend* at constant dim/model — for example moving from pgvector to Turbopuffer — is supported via `src/reconciler/sync_vectors.py` and `VECTOR_STORE_MIGRATED`. That flow is unchanged by the embedding-pipeline work and is documented separately. It is **not** the destroy + rebuild path described above.

docs/v3/contributing/guidelines.mdx

@@ -3,360 +3,170 @@ title: 'Contributing Guidelines'
 icon: 'handshake'
 ---
 
-{/* This file mirrors CONTRIBUTING.md in the repo root. 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:
 
-## Before you write code
+1. **Set up your development environment** - Follow the [Local Development guide](https://github.com/plastic-labs/honcho/blob/main/CONTRIBUTING.md#local-development) in the Honcho repository to get Honcho running locally.
 
-**Every pull request needs an issue, and that issue needs the `maintainer-approved` label.**
+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.
 
-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.
+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.
 
-So, in order:
+## Contribution Workflow
 
-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.
+### 1. Fork and Clone
 
-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.
+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
+   ```
 
-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.
+### 2. Create a Branch
 
-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`](https://github.com/plastic-labs/honcho/blob/main/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](https://github.com/plastic-labs/honcho#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) — [CLI reference](/v3/documentation/reference/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.
-
-## 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:**
+- `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
 
-Commits follow [Conventional Commits](https://www.conventionalcommits.org/), enforced by a
-`commit-msg` hook:
+### 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:
+   ```bash
+   git push origin your-branch-name
+   ```
 
-Install them. CI runs the same checks, and it is much faster to find out locally.
+2. Create a pull request on GitHub from your branch to the `main` branch
 
-```bash
-uv run pre-commit install \
-    --hook-type pre-commit \
-    --hook-type commit-msg \
-    --hook-type pre-push
-```
+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
 
-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.
+## Coding Standards
 
-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.
+### Python Code Style
 
-Run them by hand at any time:
+- 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
 
-```bash
-uv run pre-commit run --all-files
-uv run pre-commit run ruff --all-files
-```
+### Code Organization
 
-Or the individual tools:
+- Keep functions focused and single-purpose
+- Use meaningful variable and function names
+- Add comments for complex logic
+- Follow existing patterns in the codebase
 
-```bash
-uv run ruff check src/
-uv run ruff format src/
-uv run basedpyright
-```
+### Testing
 
-### Tests
-
-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).
-
-## 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](https://github.com/plastic-labs/honcho/blob/main/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! 🫡

docs/v3/contributing/self-hosting.mdx

@@ -7,8 +7,6 @@ icon: 'computer'
 
 This guide helps you set up a local environment to run Honcho for development, testing, or self-hosting.
 
-**Just want a running instance?** `uv tool install honcho-cli` only installs the `honcho` command. Then run [`honcho start --setup`](/v3/documentation/reference/cli#local-stack) (Docker + an LLM provider key) — that pulls a published image and starts API, deriver, Postgres, and Redis. The rest of this page is for building from source, contributing, or deploying without the CLI.
-
 ## Overview
 
 By the end of this guide, you'll have:
@@ -22,9 +20,9 @@ By the end of this guide, you'll have:
 Before you begin, ensure you have the following installed:
 
 ### Required Software
-- **uv** - Python package manager: `curl -LsSf https://astral.sh/uv/install.sh | sh` or `brew install uv`
+- **uv** - Python package manager: `pip install uv` (manages Python installations automatically)
 - **Git** - [Download from git-scm.com](https://git-scm.com/downloads)
-- **Docker** - required for the CLI local stack and the compose-from-source path; not needed for a fully manual setup. [Download from docker.com](https://www.docker.com/products/docker-desktop/)
+- **Docker** (optional) - [Download from docker.com](https://www.docker.com/products/docker-desktop/)
 
 ### Database Options
 You'll need a PostgreSQL database with the pgvector extension. Choose one:
@@ -34,51 +32,9 @@ You'll need a PostgreSQL database with the pgvector extension. Choose one:
 - **Railway** - Simple cloud PostgreSQL hosting
 - **Your own PostgreSQL server**
 
-## LLM Setup
+## Docker Setup (Recommended)
 
-Honcho uses LLMs for memory extraction, summarization, dialectic chat, and dreaming. The server will **fail to start** without a provider configured.
-
-If you keep the built-in defaults, you only need one API key: all text-generation features default to `openai / gpt-5.4-mini`, and embeddings default to `openai / text-embedding-3-small`. Any OpenAI-compatible endpoint works too — OpenRouter, Together, Fireworks, Ollama, vLLM, or LiteLLM. Models must support tool calling (function calling).
-
-After copying `.env.template` to `.env`, the default setup is:
-
-```bash
-# Required for the built-in defaults
-LLM_OPENAI_API_KEY=sk-...
-```
-
-If you want a different model or an OpenAI-compatible proxy, uncomment and edit the relevant `*_MODEL_CONFIG__TRANSPORT`, `*_MODEL_CONFIG__MODEL`, and `*_MODEL_CONFIG__OVERRIDES__BASE_URL` lines in the Deriver, Dialectic, Summary, and Dream sections. For example:
-
-```bash
-LLM_OPENAI_API_KEY=sk-or-v1-...
-
-DERIVER_MODEL_CONFIG__TRANSPORT=openai
-DERIVER_MODEL_CONFIG__MODEL=google/gemini-2.5-flash
-DERIVER_MODEL_CONFIG__OVERRIDES__BASE_URL=https://openrouter.ai/api/v1
-```
-
-<Info>
-For recommended model tiers per feature, using multiple providers, or direct vendor API keys, see the [Configuration Guide](./configuration#llm-configuration).
-</Info>
-
-## Personal local stack (CLI)
-
-Recommended if you want Honcho running locally without cloning this repo or building an image. Install the CLI, then run the setup wizard:
-
-```bash
-uv tool install honcho-cli
-honcho start --setup basic   # prompts for LLM provider + key, then starts Docker
-```
-
-`honcho start` pulls `ghcr.io/plastic-labs/honcho:latest`, pins that digest, and starts API + deriver + Postgres + Redis. Stack files live under `~/.honcho/profiles/local/`. It does **not** rewrite `environmentUrl` in `~/.honcho/config.json` (that file is shared with plugins). Talk to the stack with `HONCHO_BASE_URL=http://127.0.0.1:8000`, or run `honcho init --base-url http://127.0.0.1:8000` to persist local as the CLI default.
-
-See the [CLI reference](/v3/documentation/reference/cli#local-stack) for `--setup`, profiles, `--image`, ports, `honcho status` / `stop`, and pointing the CLI at local.
-
-## From source (Docker Compose)
-
-Docker Compose in this repo handles the database, Redis, and Honcho server. The compose file **builds the image from source** so you can develop against local code. A pre-built image is published at `ghcr.io/plastic-labs/honcho:latest` (what `honcho start` uses); it is not on Docker Hub. Building from source requires Docker with BuildKit enabled — see [Troubleshooting](./troubleshooting#docker-build-fails-with-permission-errors) if the build fails.
-
-The compose file is production-oriented by default (ports bound to `127.0.0.1`, restart policies, caching enabled). For development, uncomment the source mounts and monitoring services inside the file.
+The easiest way to get started is using Docker Compose, which handles both the database and Honcho server.
 
 ### 1. Clone the Repository
 
@@ -95,39 +51,45 @@ Copy the example environment file and configure it:
 cp .env.template .env
 ```
 
-Edit `.env` and configure your LLM provider — see [LLM Setup](#llm-setup) above. The database connection is set in the compose file. Auth is disabled by default (`AUTH_USE_AUTH=false`).
+Edit `.env` and set your API keys (if using LLM features):
+
+```bash
+# Optional API keys (required for LLM features)
+OPENAI_API_KEY=your-openai-api-key
+ANTHROPIC_API_KEY=your-anthropic-api-key
+
+# Database will be created automatically by Docker
+DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@database:5432/honcho
+
+# Disable auth for local development
+AUTH_USE_AUTH=false
+```
 
 ### 3. Start the Services
 
 ```bash
+# Copy the example docker-compose file
 cp docker-compose.yml.example docker-compose.yml
-docker compose up -d --build
+
+# Start PostgreSQL and Honcho
+docker compose up -d
 ```
 
-The first build takes a few minutes (compiling from source). Subsequent starts are fast.
+### 4. Verify It's Working
 
-The default image does not include LanceDB. To use `VECTOR_STORE_TYPE=lancedb`, build with `INSTALL_LANCEDB=true docker compose up -d --build`.
-
-This starts four services: **api** (port 8000), **deriver** (background worker), **database** (PostgreSQL with pgvector, port 5432), and **redis** (port 6379). All ports are bound to `127.0.0.1`. Redis caching is enabled by default.
-
-For development, uncomment the source mount and monitoring sections inside `docker-compose.yml` to enable live reload, Prometheus, and Grafana.
-
-### 4. Verify
-
-Migrations run automatically on startup.
+Check that both services are running:
 
 ```bash
-# Check all containers are running
 docker compose ps
-
-# Health check (confirms the process is up)
-curl http://localhost:8000/health
-
-# Check the deriver is processing (look for "polling" or "processing" in logs)
-docker compose logs deriver --tail 20
 ```
 
-For a full end-to-end test, see [Verify Your Setup](#verify-your-setup) below.
+Test the Honcho API:
+
+```bash
+curl http://localhost:8000/health
+```
+
+You should see a response indicating the service is healthy.
 
 ## Manual Setup
 
@@ -172,31 +134,29 @@ Download from [postgresql.org](https://www.postgresql.org/download/windows/)
 
 ```bash
 docker run --name honcho-db \
+  -e POSTGRES_DB=honcho \
   -e POSTGRES_USER=postgres \
   -e POSTGRES_PASSWORD=postgres \
   -p 5432:5432 \
   -d pgvector/pgvector:pg15
 ```
 
-### 3. Enable Extensions
+### 3. Create Database and Enable Extensions
 
-Connect to PostgreSQL and enable pgvector:
+Connect to PostgreSQL and set up the database:
 
 ```bash
 # Connect to PostgreSQL
 psql -U postgres
 
-# Enable the pgvector extension on the default database
+# Create database and enable extensions
+CREATE DATABASE honcho;
+\c honcho
 CREATE EXTENSION IF NOT EXISTS vector;
+CREATE EXTENSION IF NOT EXISTS pg_trgm;
 \q
 ```
 
-<Note>
-**Least-privilege database roles.** Honcho runs `CREATE EXTENSION IF NOT EXISTS vector` before migrations and again at startup, so if the role in `DB_CONNECTION_URI` can't create extensions, both fail with a privilege error — `IF NOT EXISTS` doesn't help, because Postgres checks the privilege first.
-
-Run the statement above once as a superuser (or `rds_superuser`) and the application role needs no extension privileges. See [Troubleshooting](/v3/contributing/troubleshooting) if you hit this.
-</Note>
-
 ### 4. Configure Environment
 
 Create a `.env` file with your settings:
@@ -205,10 +165,17 @@ Create a `.env` file with your settings:
 cp .env.template .env
 ```
 
-Edit `.env` — configure your LLM provider (see [LLM Setup](#llm-setup) above) and set the database connection:
+Edit `.env` with your configuration:
 
 ```bash
-DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@localhost:5432/postgres
+# Database connection
+DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@localhost:5432/honcho
+
+# Optional API keys (required for LLM features)
+OPENAI_API_KEY=your-openai-api-key
+ANTHROPIC_API_KEY=your-anthropic-api-key
+
+# Development settings
 AUTH_USE_AUTH=false
 LOG_LEVEL=DEBUG
 ```
@@ -224,21 +191,11 @@ uv run alembic upgrade head
 
 ```bash
 # Start the development server
-uv run fastapi dev src/main.py
+fastapi dev src/main.py
 ```
 
 The server will be available at `http://localhost:8000`.
 
-### 7. Start the Background Worker (Deriver)
-
-In a **separate terminal**, start the deriver background worker:
-
-```bash
-uv run python -m src.deriver
-```
-
-The deriver is essential for Honcho's core functionality. It processes incoming messages to extract observations, build peer representations, generate session summaries, and run dream consolidation. Without it, messages will be stored but no memory or reasoning will occur.
-
 ## Cloud Database Setup
 
 If you prefer to use a managed PostgreSQL service:
@@ -249,6 +206,7 @@ If you prefer to use a managed PostgreSQL service:
 2. **Enable pgvector extension** in the SQL editor:
    ```sql
    CREATE EXTENSION IF NOT EXISTS vector;
+   CREATE EXTENSION IF NOT EXISTS pg_trgm;
    ```
 3. **Get your connection string** from Settings > Database
 4. **Update your `.env` file** with the connection string
@@ -269,38 +227,23 @@ Once your Honcho server is running, verify everything is working:
 
 ```bash
 curl http://localhost:8000/health
-# {"status":"ok"}
 ```
 
-Note: `/health` only confirms the process is running. It does not check database or LLM connectivity.
-
-### 2. Smoke Test (database + API)
-
-This confirms the database connection, migrations, and API are all working:
-
-```bash
-# Create a workspace
-curl -s -X POST http://localhost:8000/v3/workspaces \
-  -H "Content-Type: application/json" \
-  -d '{"name": "test"}' | python3 -m json.tool
-```
-
-If you get back a workspace object with an `id`, your database is connected and migrations ran correctly.
-
-### 3. API Documentation
+### 2. API Documentation
 
 Visit `http://localhost:8000/docs` to see the interactive API documentation.
 
-### 4. Test with SDK
+### 3. Test with SDK
+
+Create a simple test script:
 
 ```python
 from honcho import Honcho
 
-client = Honcho(
-    base_url="http://localhost:8000",
-    workspace_id="test"
-)
+# Connect to your local instance
+client = Honcho(base_url="http://localhost:8000")
 
+# Create a test peer
 peer = client.peer("test-user")
 print(f"Created peer: {peer.id}")
 ```
@@ -316,7 +259,8 @@ Now that Honcho is running locally, you can connect your applications:
 from honcho import Honcho
 
 client = Honcho(
-    base_url="http://localhost:8000",
+    base_url="http://localhost:8000",  # Your local instance
+    api_key="your-api-key"  # If auth is enabled
 )
 ```
 
@@ -325,125 +269,56 @@ client = Honcho(
 import { Honcho } from '@honcho-ai/sdk';
 
 const client = new Honcho({
-  baseUrl: 'http://localhost:8000',
+  baseUrl: 'http://localhost:8000',  // Your local instance
+  apiKey: 'your-api-key'  // If auth is enabled
 });
 ```
 
 ### Next Steps
 
-- **Configure Honcho**: Visit the [Configuration Guide](./configuration) for model tiers, provider options, and tuning
-- **Use the CLI**: install with `uv tool install honcho-cli`, then [`honcho start --setup`](/v3/documentation/reference/cli#local-stack) for a local stack; inspect with `honcho workspace inspect` / `honcho doctor`
 - **Explore the API**: Check out the [API Reference](../api-reference/introduction)
 - **Try the SDKs**: See our [guides](../guides) for examples
-- **Join the community**: [Discord](https://discord.gg/honcho)
+- **Configure Honcho**: Visit the [Configuration Guide](./configuration) for detailed settings
+- **Join the community**: [Discord](https://discord.gg/plasticlabs)
 
 ## Troubleshooting
 
-Running into issues? See the [Troubleshooting Guide](./troubleshooting) for detailed solutions to common problems including:
+### Common Issues
 
-- Startup failures (missing API keys, database issues)
-- Runtime errors ("An unexpected error occurred" on every request)
-- Deriver not processing messages
-- Database connection and migration issues
-- Docker and Redis problems
-- CLI local stack (`honcho start`) — missing LLM key, health timeout, still talking to api.honcho.dev
+**Database Connection Errors**
+- Ensure PostgreSQL is running
+- Verify the connection string format: `postgresql+psycopg://...`
+- Check that pgvector extension is installed
 
-**Quick checks:**
-- Verify the server is running: `curl http://localhost:8000/health`
-- Check logs: `docker compose logs api` (from-source Docker), `docker compose -p honcho-local logs` (`honcho start`), or terminal output (manual setup)
-- Ensure migrations ran: `uv run alembic upgrade head` (from-source only; `honcho start` runs them in the image entrypoint)
+**API Key Issues**
+- Verify your OpenAI and Anthropic API keys are valid
+- Check that the keys have sufficient credits/quota
+
+**Port Already in Use**
+- Pass a different port to FastAPI or stop other services using port 8000
+
+**Docker Issues**
+- Ensure Docker is running
+- Check container logs: `docker compose logs`
+- Restart containers: `docker compose down && docker compose up -d`
+
+**Migration Errors**
+- Ensure the database exists and pgvector is enabled
+- Check database permissions
+- Run migrations manually: `uv run alembic upgrade head`
+
+### Getting Help
+
+- **GitHub Issues**: [Report bugs](https://github.com/plastic-labs/honcho/issues)
+- **Discord**: [Join our community](https://discord.gg/plasticlabs)
+- **Documentation**: Check the [Configuration Guide](./configuration) for detailed settings
 
 ## Production Considerations
 
-The default compose file is already production-oriented — ports bound to `127.0.0.1`, restart policies, caching enabled.
+When self-hosting for production, consider:
 
-### Security
-- Set `AUTH_USE_AUTH=true` and generate a JWT secret with `python scripts/generate_jwt_secret.py`
-- Use HTTPS via a reverse proxy in front of Honcho. Example with Caddy (automatic TLS):
-  ```
-  honcho.example.com {
-      reverse_proxy localhost:8000
-  }
-  ```
-  Or with nginx:
-  ```nginx
-  server {
-      listen 443 ssl;
-      server_name honcho.example.com;
-      ssl_certificate /etc/letsencrypt/live/honcho.example.com/fullchain.pem;
-      ssl_certificate_key /etc/letsencrypt/live/honcho.example.com/privkey.pem;
-      location / {
-          proxy_pass http://127.0.0.1:8000;
-          proxy_set_header Host $host;
-          proxy_set_header X-Real-IP $remote_addr;
-          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-          proxy_set_header X-Forwarded-Proto $scheme;
-      }
-  }
-  ```
-- Secure your database with strong credentials and restrict network access
-- The production compose binds PostgreSQL and Redis to `127.0.0.1` only — they are not accessible from the network
-
-### Scaling the Deriver
-- Increase `DERIVER_WORKERS` (default: 1) for higher message throughput
-- You can also run multiple deriver processes across machines — they coordinate via the database queue
-- Monitor deriver logs for processing backlog
-
-### Scaling the API
-
-Set `API_WORKERS` to run multiple API server processes in the Docker container. It defaults to `1`, preserving the existing single-process behavior.
-
-When connection pooling is enabled (`DB_POOL_CLASS` is not `null`), each API process creates its own SQLAlchemy connection pool. Keep the combined capacity below the PostgreSQL connection limit:
-
-```text
-API_WORKERS * (DB_POOL_SIZE + DB_MAX_OVERFLOW) < PostgreSQL max_connections
-```
-
-With the default pooled settings (`10 + 20`), each API worker can open up to 30 connections. For example, `API_WORKERS=3` allows up to 90 API connections. Leave additional headroom for the deriver, migrations, administration, and monitoring.
-
-When `DB_POOL_CLASS=null`, SQLAlchemy uses `NullPool`; `DB_POOL_SIZE` and `DB_MAX_OVERFLOW` do not apply, and connections are opened and closed per use.
-
-### Caching
-- The production compose enables Redis caching by default (`CACHE_ENABLED=true`)
-- For the development compose, enable manually: `CACHE_ENABLED=true`
-- Configure `CACHE_URL` to point to your Redis instance (or use a managed Redis service)
-
-### Database Migrations
-- Always run `uv run alembic upgrade head` after updating Honcho before starting the server
-- Check current migration status with `uv run alembic current`
-
-### LLM Providers
-- Ensure your API keys are configured (see [LLM Setup](#llm-setup))
-- For alternative providers or per-feature model overrides, see the [Configuration Guide](./configuration#llm-configuration)
-
-### Monitoring
-- Enable Prometheus metrics with `METRICS_ENABLED=true`. The API exposes `/metrics` on port 8000, the deriver on port 9090 (internal to its container — not published to the host by default).
-- Enable Sentry error tracking with `SENTRY_ENABLED=true`
-- The development compose includes Prometheus (host port 9090) and Grafana (host port 3000) for scraping and dashboards. Uncomment those services to enable them.
-
-### Backups
-- Set up regular PostgreSQL backups:
-  ```bash
-  # One-off backup
-  docker compose exec database pg_dump -U postgres postgres > backup-$(date +%Y%m%d).sql
-
-  # Restore
-  cat backup.sql | docker compose exec -T database psql -U postgres postgres
-  ```
-
-## Deploying on Fly.io
-
-The API can be deployed on [Fly.io](https://fly.io). Follow the [Fly.io getting-started docs](https://fly.io/docs/getting-started/) to set up your account and install `flyctl`. A sample `fly.toml` is included in the repo for convenience.
-
-<Note>
-The included `fly.toml` does not provision a PostgreSQL database. Stand one up separately (Fly Postgres, Supabase, Neon, or another managed provider) and set `DB_CONNECTION_URI` to point at it.
-</Note>
-
-Once `flyctl` is set up, from the repo root:
-
-```bash
-flyctl launch --no-deploy           # follow the prompts and edit as you see fit
-cat .env | flyctl secrets import    # load secrets from .env
-flyctl deploy                       # deploy
-```
-- Back up your `.env` or `config.toml` configuration files
+- **Security**: Enable authentication, use HTTPS, secure your database
+- **Scaling**: Use connection pooling, consider load balancing
+- **Monitoring**: Set up logging, error tracking, health checks
+- **Backups**: Regular database backups, disaster recovery plan
+- **Updates**: Keep Honcho and dependencies updated

docs/v3/contributing/troubleshooting.mdx

@@ -1,351 +0,0 @@
----
-title: 'Troubleshooting'
-sidebarTitle: 'Troubleshooting'
-description: 'Common issues and solutions when self-hosting Honcho'
-icon: 'wrench'
----
-
-This page covers common issues you may encounter when self-hosting Honcho, what causes them, and how to fix them.
-
-## Startup Failures
-
-### Server won't start: "Missing client for ..."
-
-```
-ValueError: Missing client for Deriver: google
-```
-
-**Cause:** The server validates at startup that all configured LLM providers have API keys. If a provider is referenced in your configuration but the corresponding API key isn't set, the server refuses to start.
-
-**Fix:** Set the API keys for your configured providers. With default configuration, you need:
-
-```bash
-LLM_GEMINI_API_KEY=...    # Used by deriver, summary, dialectic minimal/low
-LLM_ANTHROPIC_API_KEY=... # Used by dialectic medium/high/max, dream
-LLM_OPENAI_API_KEY=...    # Used by embeddings (when EMBED_MESSAGES=true)
-```
-
-See the [LLM Setup](/v3/contributing/self-hosting#llm-setup) section for provider configuration. You can change which providers are used in your `.env` or `config.toml` (see [Configuration Guide](./configuration#llm-configuration)).
-
-### Server won't start: "JWT_SECRET must be set"
-
-```
-ValueError: JWT_SECRET must be set if USE_AUTH is true
-```
-
-**Cause:** You enabled authentication (`AUTH_USE_AUTH=true`) but didn't provide a JWT secret.
-
-**Fix:** Generate a secret and set it:
-
-```bash
-python scripts/generate_jwt_secret.py
-# Then set the output as:
-AUTH_JWT_SECRET=<generated_secret>
-```
-
-Or disable authentication for local development: `AUTH_USE_AUTH=false`
-
-## Runtime Errors
-
-### API returns "An unexpected error occurred" on every request
-
-**Cause:** This is almost always a database issue. The health endpoint (`/health`) will return `{"status": "ok"}` even when the database is unreachable because it doesn't check the database connection. The actual error appears in the server logs.
-
-**Common causes and fixes:**
-
-1. **Database is unreachable** — Check that PostgreSQL is running and the `DB_CONNECTION_URI` is correct
-2. **Migrations haven't been run** — The server starts successfully without tables, but every API call will fail. Run:
-   ```bash
-   uv run alembic upgrade head
-   ```
-   In Docker:
-   ```bash
-   docker compose exec api uv run alembic upgrade head
-   ```
-3. **pgvector extension not installed** — The `vector` extension must be enabled in your database:
-   ```sql
-   CREATE EXTENSION IF NOT EXISTS vector;
-   ```
-
-**How to diagnose:** Check the server logs for the actual error. Look for:
-- `sqlalchemy.exc.OperationalError` — database connection issue
-- `sqlalchemy.exc.ProgrammingError` with "relation does not exist" — migrations not run
-- `psycopg.OperationalError` — connection refused or authentication failed
-
-### Health check passes but API calls fail
-
-The `/health` endpoint is a lightweight check that confirms the server process is running. It does **not** verify:
-- Database connectivity
-- That migrations have been run
-- That LLM providers are reachable
-
-To verify full functionality, try creating a workspace:
-
-```bash
-curl -X POST http://localhost:8000/v3/workspaces \
-  -H "Content-Type: application/json" \
-  -d '{"name": "test"}'
-```
-
-If this succeeds, your database connection and migrations are working.
-
-### Deriver not processing messages
-
-Messages are stored but no observations, summaries, or representations are being generated.
-
-**Common causes:**
-
-1. **Deriver isn't running** — In manual setup, the deriver is a separate process:
-   ```bash
-   uv run python -m src.deriver
-   ```
-   In Docker, it starts automatically via `docker compose up`.
-
-2. **Deriver can't reach the database** — Check deriver logs for connection errors. The deriver uses the same `DB_CONNECTION_URI` as the API server.
-
-3. **Missing LLM API key for deriver provider** — By default the deriver uses Google Gemini (`LLM_GEMINI_API_KEY`). Check deriver logs for API errors.
-
-4. **Processing backlog** — With `DERIVER_WORKERS=1` (default), high message volume can cause a backlog. Increase workers:
-   ```bash
-   DERIVER_WORKERS=4
-   ```
-
-## Alternative Provider Issues
-
-### OpenRouter / custom provider not working
-
-If calls to an OpenAI-compatible proxy fail:
-
-1. **Verify the endpoint and key are set.** Use `transport = "openai"` with a base URL override:
-   ```bash
-   LLM_OPENAI_API_KEY=sk-or-v1-...
-   DERIVER_MODEL_CONFIG__OVERRIDES__BASE_URL=https://openrouter.ai/api/v1
-   ```
-
-2. **Check model names match the provider's format.** OpenRouter uses `vendor/model` format (e.g., `anthropic/claude-haiku-4-5`), not the raw model ID.
-
-3. **Ensure your model supports tool calling.** The deriver, dialectic, and dream agents require tool use. Check the provider's model page for tool calling support.
-
-4. **Check server logs for the actual error.** API errors from the upstream provider will appear in Honcho's logs with the HTTP status code and message body.
-
-### vLLM / Ollama not responding
-
-1. **Verify the model server is running** and accessible from the Honcho process (or container):
-   ```bash
-   curl http://localhost:8000/v1/models   # vLLM
-   curl http://localhost:11434/v1/models  # Ollama
-   ```
-
-2. **In Docker**, `localhost` inside a container doesn't reach the host. Use `host.docker.internal` (macOS/Windows) or the host's network IP:
-   ```bash
-   DERIVER_MODEL_CONFIG__OVERRIDES__BASE_URL=http://host.docker.internal:8000/v1
-   ```
-
-3. **Structured output failures** — vLLM's structured output support is limited to certain response formats. If you see JSON parsing errors, check the deriver/dream logs for the raw response. See [Deriver produces no observations](#deriver-produces-no-observations) below.
-
-### Deriver produces no observations
-
-If messages are processed (the queue drains, no errors in logs) but peers never accumulate observations — and you're using an OpenAI-compatible provider — the likely cause is that the provider doesn't support OpenAI Structured Outputs (`json_schema`). The OpenAI backend requests `json_schema` by default; providers like **Z.AI GLM** and some **Ollama/vLLM** deployments either reject it or silently ignore it and return prose, which the deriver can't parse into observations.
-
-**Fix:** set `STRUCTURED_OUTPUT_MODE=json_object` on the deriver's model config to request loose JSON mode, which injects the schema into the prompt instead:
-
-```bash
-DERIVER_MODEL_CONFIG__STRUCTURED_OUTPUT_MODE=json_object
-```
-
-This is a per-model-config setting on the OpenAI transport; set it on whichever features use the affected provider (e.g. `DREAM_DEDUCTION_MODEL_CONFIG__STRUCTURED_OUTPUT_MODE`).
-
-### Thinking budget errors with non-Anthropic providers
-
-If you see errors like `thinking budget not supported`, `invalid parameter`, or silent failures where agents produce no output, one of your per-component `*_MODEL_CONFIG__THINKING_BUDGET_TOKENS` overrides is likely set to a value > 0 with a provider that doesn't support Anthropic-style extended thinking. The built-in defaults do not set thinking budgets, so this only applies if you added those overrides yourself.
-
-**Fix:** Set `*_MODEL_CONFIG__THINKING_BUDGET_TOKENS=0` for every component when using models that don't support thinking:
-
-```bash
-DERIVER_MODEL_CONFIG__THINKING_BUDGET_TOKENS=0
-SUMMARY_MODEL_CONFIG__THINKING_BUDGET_TOKENS=0
-DREAM_DEDUCTION_MODEL_CONFIG__THINKING_BUDGET_TOKENS=0
-DREAM_INDUCTION_MODEL_CONFIG__THINKING_BUDGET_TOKENS=0
-DIALECTIC_LEVELS__minimal__MODEL_CONFIG__THINKING_BUDGET_TOKENS=0
-DIALECTIC_LEVELS__low__MODEL_CONFIG__THINKING_BUDGET_TOKENS=0
-DIALECTIC_LEVELS__medium__MODEL_CONFIG__THINKING_BUDGET_TOKENS=0
-DIALECTIC_LEVELS__high__MODEL_CONFIG__THINKING_BUDGET_TOKENS=0
-DIALECTIC_LEVELS__max__MODEL_CONFIG__THINKING_BUDGET_TOKENS=0
-```
-
-For OpenAI reasoning models, use `*_MODEL_CONFIG__THINKING_EFFORT` instead of `*_MODEL_CONFIG__THINKING_BUDGET_TOKENS`.
-
-## Database Issues
-
-### Connection string format
-
-The connection URI **must** use the `postgresql+psycopg` prefix:
-
-```bash
-# Correct
-DB_CONNECTION_URI=postgresql+psycopg://postgres:postgres@localhost:5432/postgres
-
-# Wrong - will fail
-DB_CONNECTION_URI=postgresql://postgres:postgres@localhost:5432/postgres
-DB_CONNECTION_URI=postgres://postgres:postgres@localhost:5432/postgres
-```
-
-### Checking migration status
-
-```bash
-# See current migration version
-uv run alembic current
-
-# See migration history
-uv run alembic history
-
-# Upgrade to latest
-uv run alembic upgrade head
-```
-
-### "permission denied to create extension \"vector\""
-
-**Cause:** The role in `DB_CONNECTION_URI` is not a superuser and lacks privileges to create extensions. Honcho issues `CREATE EXTENSION IF NOT EXISTS vector` both before running migrations and again at server startup, so this fails in both places. `IF NOT EXISTS` does not help — Postgres checks the privilege before checking whether the extension exists.
-
-**Fix:** Preinstall pgvector once with a privileged role (superuser, or `rds_superuser` on RDS) in the Honcho database:
-
-```sql
-CREATE EXTENSION IF NOT EXISTS vector;
-```
-
-The `IF NOT EXISTS` calls then short-circuit and the application role needs no extension privileges. This is the supported path for deployments where the platform, not the application, owns extension management.
-
-You won't hit this with `docker compose` — the bundled stack connects as `postgres`, a superuser, and its database service also creates the extension from `database/init.sql` on first boot. It comes up on managed Postgres, Kubernetes operators, and other setups where you bring your own database and its role is deliberately not a superuser.
-
-## Cache & Redis
-
-### Redis is optional
-
-Redis is used for caching when `CACHE_ENABLED=true` (default: `false`). If Redis is unreachable, Honcho **gracefully falls back to in-memory caching** and logs a warning. This means:
-
-- The server and deriver will still start and function normally
-- Performance may be reduced under high load without Redis
-- You do not need Redis for local development or testing
-
-### Redis connection issues
-
-If you see Redis connection warnings in logs but `CACHE_ENABLED=false`, they can be safely ignored. If you want caching:
-
-```bash
-# Start Redis via Docker
-docker run -d -p 6379:6379 redis:latest
-
-# Configure Honcho
-CACHE_ENABLED=true
-CACHE_URL=redis://localhost:6379/0
-```
-
-## Docker Issues
-
-### Docker build fails with permission errors
-
-The Honcho Dockerfile uses BuildKit mount syntax and creates a non-root `app` user. Common build failures:
-
-**1. BuildKit not enabled**
-
-The Dockerfile uses `RUN --mount=type=cache` which requires Docker BuildKit. If you see syntax errors during build:
-
-```bash
-# Ensure BuildKit is enabled
-DOCKER_BUILDKIT=1 docker compose build
-```
-
-Or add to your Docker daemon config (`/etc/docker/daemon.json`):
-```json
-{ "features": { "buildkit": true } }
-```
-
-**2. Permission denied during build or at runtime (Linux)**
-
-On Linux, AppArmor or SELinux can block Docker build operations and volume mounts. Symptoms include permission denied errors during `COPY`, `RUN`, or when the container tries to access mounted volumes.
-
-```bash
-# Check if AppArmor is blocking Docker
-sudo aa-status | grep docker
-
-# Temporarily test without AppArmor (for diagnosis only)
-docker compose down
-sudo aa-remove-unknown
-docker compose up -d
-```
-
-For SELinux, add `:z` to volume mounts in `docker-compose.yml`:
-```yaml
-volumes:
-  - .:/app:z
-```
-
-**3. Volume mount UID mismatch**
-
-The Dockerfile creates a non-root `app` user, but `docker-compose.yml.example` mounts `.:/app` which overlays the container filesystem with host-owned files. The `app` user inside the container may not have permission to read them.
-
-If you see permission errors at runtime (not build time), you can either:
-- Run without the source mount (remove `- .:/app` from volumes — the image already contains the code)
-- Or fix ownership: `sudo chown -R 100:101 .` (matches the `app` user inside the container)
-
-### Containers start but API fails
-
-1. Check container status: `docker compose ps`
-2. Check API logs: `docker compose logs api`
-3. Check database logs: `docker compose logs database`
-4. Ensure migrations ran: `docker compose exec api uv run alembic upgrade head`
-
-### Port conflicts
-
-If port 8000 is already in use:
-
-```bash
-# Check what's using the port
-lsof -i :8000
-
-# Or change the port mapping in docker-compose.yml
-ports:
-  - "8001:8000"  # Map to a different host port
-```
-
-### Rebuilding after code changes
-
-```bash
-docker compose build --no-cache
-docker compose up -d
-```
-
-## CLI local stack (`honcho start`)
-
-The CLI local stack lives under `~/.honcho/profiles/` (default profile `local`) and uses the published image `ghcr.io/plastic-labs/honcho:latest`. Logs: `docker compose -p honcho-local logs`. Full flags: [CLI reference](/v3/documentation/reference/cli#local-stack).
-
-### `MISSING_LLM_KEY`
-
-**Cause:** No provider key in the environment or the profile `.env`.
-
-**Fix:** Export `LLM_OPENAI_API_KEY`, `LLM_ANTHROPIC_API_KEY`, or `LLM_GEMINI_API_KEY`, or run `honcho start --setup basic` in a TTY (not with `--json`).
-
-### Timed out waiting for `/health`
-
-**Cause:** The API container started but did not become ready within `--timeout` (default 180s).
-
-**Fix:** Check `docker compose -p honcho-local logs api` and `... logs deriver`. Increase `--timeout`. Confirm Docker is running. A first-time GHCR pull happens *before* this wait (during image pin) — if that step hung, look at Docker pull logs instead.
-
-### CLI still talks to `api.honcho.dev`
-
-**Cause:** `honcho start` does not rewrite `environmentUrl` in `~/.honcho/config.json`.
-
-**Fix:** Prefix commands with `HONCHO_BASE_URL=http://127.0.0.1:8000`, or run `honcho init --base-url http://127.0.0.1:8000` to persist local as the default. `honcho status` prints the one-shot hint.
-
-### Port already in use
-
-The CLI remaps 8000/5432/6379 automatically unless you pinned them with `--api-port` / `--db-port` / `--redis-port`. Pass those flags if you need a specific host port.
-
-## Getting Help
-
-If your issue isn't covered here:
-
-- **Check the logs** — most issues are diagnosed from server or deriver logs (`docker compose logs` for from-source compose; `docker compose -p honcho-local logs` for `honcho start`)
-- **GitHub Issues** — [Report bugs](https://github.com/plastic-labs/honcho/issues)
-- **Discord** — [Join our community](https://discord.gg/plasticlabs)
-- **Configuration** — See the [Configuration Guide](./configuration) for all available settings

docs/v3/documentation/core-concepts/architecture.mdx

@@ -34,7 +34,7 @@ Honcho has a hierarchical data model centered around the entities below.
 
 Workspaces are the top-level containers in Honcho. They provide complete isolation between different applications or environments, essentially serving as a namespace to keep different workloads separate. You might use separate workspaces for development, staging, and production environments, or to isolate different product lines. They also enable multi-tenant SaaS applications where each customer gets their own isolated workspace with complete data separation.
 
-Authentication is issued at the workspace level, and configuration settings can be applied workspace-wide to control behavior across all peers and sessions within that workspace.
+Authentication is scoped to the workspace level, and configuration settings can be applied workspace-wide to control behavior across all peers and sessions within that workspace.
 
 ---
 
@@ -50,14 +50,12 @@ You can use peers for any entity that persists over time--individual users in ch
 
 ### <Icon icon="message" /> Sessions
 
-Sessions represent interaction threads or contexts between peers. A session can involve multiple peers and provides temporal boundaries for when a set of interactions starts and ends. This lets you confine context and memory to specific interactions while still maintaining longer-term peer representations that span sessions.
+Sessions represent interaction threads or contexts between peers. A session can involve multiple peers and provides temporal boundaries for when a set of interactions starts and ends. This lets you scope context and memory to specific interactions while still maintaining longer-term peer representations that span sessions.
 
-Use sessions for things like support tickets, meeting transcripts, learning sessions, or conversations. You can also use single-peer sessions as a way to import external data--create a session with just one peer and structure emails, documents, or files as messages to enrich that peer's representation.
+Use sessions to scope things like support tickets, meeting transcripts, learning sessions, or conversations. You can also use single-peer sessions as a way to import external data--create a session with just one peer and structure emails, documents, or files as messages to enrich that peer's representation.
 
 Session-level configuration gives you fine-grained control over perspective-taking behavior. You can configure whether a peer should form representations of other peers in the session, and whether other peers should form representations of them.
 
-Sessions are also the unit of visibility: when one peer's history spans contexts that shouldn't inform each other, you can group sessions into named [scopes](/v3/documentation/features/advanced/scopes) that bound recall to just those sessions.
-
 ---
 
 ### <Icon icon="envelope" /> Messages
@@ -78,20 +76,6 @@ When you need context from Honcho, you query through the "Chat" endpoint or "Get
 
 The diagram above shows how agents write messages to Honcho, which triggers reasoning that updates peer representations. Agents can then query representations to get additional context for their next response. Black arrows represent read/write of regular data (messages, storage), while red arrows represent read/write of reasoned-over data (logic, peer representations).
 
-### Under the Hood: Write, Reasoning, and Query Paths
-
-Honcho runs as two cooperating processes: an **API server** that handles requests and enqueues background work, and a **worker** that consumes that work off the queue. This split is what keeps the write path fast--your request never waits on an LLM call.
-
-![Honcho Detailed Internals](/images/honcho-system-diagram.png)
-
-**Write path (synchronous).** A message is stored and a reasoning task is enqueued in the same request; the API returns immediately. Nothing about the reasoning that follows blocks the caller.
-
-**Deriver + Summarizer (async, per-message).** The worker picks up queued tasks. The Deriver reads new messages and extracts conclusions about the peer--explicit statements and direct deductions. In parallel, the Summarizer periodically rolls up recent messages into short- and long-form session summaries. Both run per-message rather than on a schedule.
-
-**Dreamer (periodic).** On a schedule (or triggered on demand), the Dreamer revisits existing conclusions to consolidate and deepen them: removing redundant or stale ones, drawing inductive conclusions across patterns that span multiple messages, and updating peer cards--compact biographical summaries of a peer. This is where memory gets richer over time, not just larger.
-
-**Query path (Dialectic).** A `chat()` call spawns a Dialectic agent that answers your question by exploring memory--searching conclusions semantically, pulling supporting messages, and tracing a conclusion back to the premises it was drawn from--before synthesizing a grounded answer. This all happens inline during the request, since answering well is worth the latency that write-path reasoning is designed to avoid.
-
 ## Configuration & Extensibility
 
 Honcho is designed to be flexible. Settings cascade hierarchically from workspace to peer to session, so you can set defaults at the workspace level and override them for specific peers or sessions. Feature flags let you enable or disable reasoning modes, perspective tracking, and other capabilities. You can bring your own LLM provider--OpenAI, Anthropic, or custom endpoints--and metadata fields let you extend any primitive with custom JSON data. Batch operations let you create up to 100 messages in a single API call for efficient bulk ingestion.

docs/v3/documentation/core-concepts/design-patterns.mdx

@@ -1,125 +0,0 @@
----
-title: Design Patterns
-description: "Design your workspace, peers, and sessions for common application patterns"
-icon: "cubes"
----
-
-<Info>
-This page covers **how to structure** workspaces, peers, and sessions for real applications. For the conceptual model behind them, start with [Architecture](/v3/documentation/core-concepts/architecture).
-
-Ready to add Honcho to your codebase? The **`/honcho-integration` skill** applies these patterns for you — it explores your code, asks how your peers and sessions should map to your app, and wires in the Honcho SDK. Run it in any coding agent that supports skills (Claude Code, Cursor, and others).
-</Info>
-
-## Quick Reference
-
-**Workspaces isolate, peers persist, and sessions bound the active context.**
-
-| Decision | Recommendation |
-|----------|---------------|
-| How many workspaces? | One workspace per application, tool, tenant, or collaboration boundary. Split workspaces only when you need hard isolation between products, customers, environments, or agents. |
-| When should agents share a workspace? | When agents collaborate over the same product, project, team, user, customer, or game state. Separate them when they should not see or influence each other's memory. |
-| Who should be a peer? | Any persistent participant whose messages should be attributed or reasoned about: users, agents, assistants, NPCs, students, or customers. Use one peer for the same entity across sessions and platforms. |
-| How should I divide sessions? | Match each session to the active interaction: per-conversation, per-channel, per-task run, per-project, per-import, or other bounded context. Reuse a session when local context should keep accumulating. |
-| How does cross-session reasoning work? | Session memory stays local to one session. Peer representations accumulate across every session where the peer is included, and `session.context()` becomes cross-session when you include a peer target. |
-| Should I set `observe_me: false`? | Yes, for deterministic peers Honcho does not need to model, like bots or tool agents. Still save their messages so other peers have session context. Keep it enabled for users and evolving agents. |
-| Do I need `observe_others`? | Only when a peer needs its own perspective on another participant, such as in games, multi-agent systems, or parent/subagent workflows. |
-| When do I need a scope? | When one peer's history spans contexts that must not leak into each other's recall — but you still want one workspace and one unified peer. Group the confidential sessions into a [scope](/v3/documentation/features/advanced/scopes) and pass it at query time. |
-| Perspectives or scopes? | `observe_others` gives a *participant* its own view of another peer. A scope bounds recall to *where things were said*, for a reader that isn't a participant. If the reader is in the session, use perspectives; if you're fencing off a set of sessions, use a scope. |
-
-## Workspace Design
-
-A workspace is a hard isolation boundary. **Default to one workspace per application,** and split only at a real privacy, compliance, or product boundary (e.g. per-tenant SaaS, or a tool that needs intentionally isolated memory). Agents that collaborate over the same product, user, or game state belong in the *same* workspace so each can retrieve what the others produced.
-
-If what you actually need is "this part of a peer's history shouldn't inform that assistant," don't split the workspace — that severs the peer's identity too. Use a [scope](/v3/documentation/features/advanced/scopes) instead: the peer stays whole, and recall through the scope sees only its member sessions.
-
-Honcho plugins default to one workspace *per host* (`hermes`, `claude_code`, `cursor`, `opencode`). To unify memory across them, point each at the same workspace — see [Unified Memory Setup](/v3/guides/recipes/unified-memory-setup).
-
-<Info>
-The SDK creates a workspace called `default` when no `workspace_id` is specified.
-</Info>
-
----
-
-## Peer Design
-
-Give each real-world entity **one** stable peer ID and reuse it everywhere — splitting one entity across `user-web`, `user-discord`, and `user-slack` builds three separate representations. Prefix IDs by source for multi-channel apps (`discord_491827364`), and if a peer goes by multiple names, store the aliases in its peer card with `set_card()` / `setCard()`.
-
-<Tip>
-For unified context across Honcho plugins, set the same user peer ID (`peerName`) everywhere — that shared ID is what connects memory across Claude Code, Cursor, OpenCode, and your own app. See [Unified Memory Setup](/v3/guides/recipes/unified-memory-setup).
-</Tip>
-
----
-
-## Session Design
-
-Sessions define the temporal boundaries of an interaction. Where you draw those boundaries affects how summaries are generated and how context is retrieved.
-
-**Common session patterns**
-
-| Pattern | Session covers | Example |
-|---------|-------------------|---------|
-| Per-conversation | Each new chat thread | ChatGPT or Claude Code style UI where each thread is a session |
-| Per-channel | A persistent channel or room | Discord channel, Slack thread |
-| Per-interaction | A bounded task or encounter | A support ticket, a game encounter |
-| Per-project | A persistent work area | Coding agent memory for one repository |
-| Per-import | A batch of external data | Importing emails or documents for a single peer |
-
-Create a **new** session when context resets (new conversation, new day, new topic); **reuse** one when context should keep accumulating (ongoing channel, persistent thread).
-
-**How cross-session reasoning works**
-
-- **Session memory** is local to an interaction — summaries and recent-message context describe only what happened there.
-- **Peer memory** (representations) accumulates reasoning across every session the peer is part of.
-
-So you can start a session fresh or pull in a peer's long-term memory. [`session.context()`](/v3/documentation/features/get-context) returns the current session's summary and recent messages; add a [peer target](/v3/documentation/features/get-context#peer-representation-in-context) to fold in that peer's cross-session history.
-
----
-
-## Choosing an Isolation Boundary
-
-Honcho gives you three boundaries at different strengths. Pick the weakest one that solves your problem:
-
-| Boundary | Strength | Use when |
-|----------|----------|----------|
-| **Workspace** | Hard isolation — nothing crosses, including the peer itself | Different products, tenants, or environments |
-| **[Scope](/v3/documentation/features/advanced/scopes)** | Recall boundary — one peer, but queries through the scope see only its sessions | One peer's contexts must not leak into each other (clinical vs. billing, per-reseller support) |
-| **Session allowlist** (`sessions=[...]`) | Ad-hoc recall restriction, decided per request | The session set varies per query, or you need a quick boundary without provisioning anything |
-
-Two things scopes are **not**:
-
-- **Not authorization.** A workspace key reads any session, scoped or not. A scope constrains queries that name it; it doesn't protect data from queries that don't.
-- **Not topic filtering.** Scopes bound recall by *where something was said*, not what it's about. A therapy detail mentioned in a billing session lands in the billing scope. If you might ever need a scope boundary, align your session boundaries with your confidentiality boundaries from the start — the session is the unit scopes can enforce.
-
----
-
-## Common Mistakes
-
-- **Splitting one identity across peer IDs** -- If the same user is `alice`, `alice-discord`, and `alice-cursor`, Honcho builds separate representations. Use one stable peer ID when you want unified memory.
-- **Too many tiny sessions** -- Summaries and recent messages are local to one session. Splitting a continuous conversation across many sessions fragments that local context. Reuse a session when context should flow continuously.
-- **Separating agents that should collaborate** -- If agents need shared product, customer, or team context, put them in the same workspace. Separate workspaces are hard isolation boundaries.
-- **Leaving `observe_me` on for assistants** -- Wastes reasoning compute on a peer you control. Deterministic behavior doesn't need to be modeled.
-- **Turning on `observe_others` everywhere** -- Directional representations are powerful, but they add complexity. Use them when peers need distinct perspectives, not just because a session has multiple peers.
-- **A scope per reader** -- Scopes should map to real confidentiality boundaries, not to consumers. If every assistant gets its own scope, you've rebuilt workspace fragmentation inside one workspace, and each projection reasons over a thin slice. Fewer, boundary-shaped scopes; many readers can share one.
-- **Treating scopes as access control** -- A scope bounds *recall*, not *access*. Enforce who may query what in your application layer; use scopes to keep the answers themselves from drawing on out-of-bounds sessions.
-- **Forgetting `peer_target` on session context** -- `session.context()` defaults to the active session's summary and recent messages, which are local to that session. It becomes cross-session only through adding a peer_target which includes the peer representation.
-- **Blocking on processing** -- Messages are processed asynchronously in the background. Don't poll or wait for reasoning to complete before continuing your application flow.
-
-## Next Steps
-
-<CardGroup cols={2}>
-  <Card title="Unified Memory Setup" icon="diagram-project" href="/v3/guides/recipes/unified-memory-setup">
-    Wire these patterns into one shared workspace across four integrations
-  </Card>
-  <Card title="Get Context" icon="messages" href="/v3/documentation/features/get-context">
-    Retrieve formatted context from sessions for your LLM
-  </Card>
-  <Card title="Scopes" icon="shield-halved" href="/v3/documentation/features/advanced/scopes">
-    Bound recall to named sets of sessions
-  </Card>
-  <Card title="Chat Endpoint" icon="comments" href="/v3/documentation/features/chat">
-    Query Honcho about your peers with natural language
-  </Card>
-  <Card title="Reasoning Configuration" icon="wrench" href="/v3/documentation/features/advanced/reasoning-configuration">
-    Fine-tune what gets reasoned about and how
-  </Card>
-</CardGroup>

docs/v3/documentation/core-concepts/reasoning.mdx

@@ -54,8 +54,6 @@ The explicit reasoning model ([Neuromancer XR](https://blog.plasticlabs.ai/resea
 
 The reasoning that Honcho does is something we're constantly iterating and improving on. Our goal is simple--provide the richest, most relevant context in the fastest, cheapest way possible in order to simulate statefulness in whatever setting you need.
 
-Two components produce this logic: the **Deriver** extracts explicit and deductive conclusions from incoming messages as they arrive, and the **Dreamer** periodically revisits stored conclusions to consolidate them and draw inductive conclusions across patterns spanning multiple messages. See [Architecture](/v3/documentation/core-concepts/architecture) for how these fit into the request/background split.
-
 ## How It Works
 
 When you write messages to Honcho, they're stored immediately and enqueued for background processing. Reasoning asynchronously ensures fast writes while still providing rich reasoning capabilities. Messages are stored immediately without blocking, and session-based queues maintain chronological consistency so reasoning tasks affecting the same peer representation are always processed in order.
@@ -66,16 +64,26 @@ The reasoning outputs--conclusions, summaries, peer cards--are stored as part of
 
 The diagram above shows how agents write messages to Honcho, which triggers reasoning that updates peer representations. Agents can then query representations to get additional context for their next response.
 
+### Token Batching
+
+Rather than running inference on every individual message, Honcho accumulates messages in the queue and processes them as a batch once the total token count of pending messages for a given peer representation crosses a threshold--roughly **1,000 tokens** at the current batch size. This keeps ingestion costs down, since Honcho charges based on reasoning passes, and ensures each pass has a meaningful amount of context to work with. At ~1,000 tokens the batch comfortably fits in the context window of any modern LLM, so no content is lost.
+
+If a user sends several short messages in a row (e.g., "yes", "ok", "sounds good"), those messages sit in the queue until enough content has accumulated. Once the threshold is met, the full batch is processed together in a single reasoning call.
+
+<Note>
+This batching only applies to **representation** tasks (conclusion extraction). Summary and dream tasks have their own scheduling logic and are not subject to the token threshold.
+</Note>
+
 ## Balances & Design Choices
 
 Off-the-shelf LLMs can perform formal logical reasoning, but they aren't optimized for it. Honcho uses custom models trained specifically for logical rigor (following formal reasoning rules rather than plausible-sounding text), structured output (consistent JSON schema with premises and conclusions), and efficiency (smaller, faster models tuned for this specific task). This allows Honcho to reason more reliably and at lower cost than general-purpose frontier LLMs.
 
-The approach balances quality with practical constraints. Custom models are smaller and cheaper to run, and scaffolded conclusions are more token-efficient than raw conversation history.
+The approach balances quality with practical constraints. Custom models are smaller and cheaper to run, scaffolded conclusions are more token-efficient than raw conversation history, and we batch where appropriate to optimize update frequency.
 
 Honcho's reasoning capabilities are actively being improved. Current areas of development include enhanced inductive and abductive reasoning, multi-hop  and temporal reasoning, and expanded file types and modalities. The system is designed to be extensible--new reasoning capabilities can be added without breaking existing functionality.
 
 <Note>
-If you find that the data you're uploading to Honcho isn't being reasoned over to your liking, we'd love to improve it for you and ingest your data for free--reach out via [Discord](https://discord.gg/honcho) or [email](mailto:support@plasticlabs.ai)!
+If you find that the data you're uploading to Honcho isn't being reasoned over to your liking, we'd love to improve it for you and ingest your data for free--reach out via [Discord](https://discord.gg/plasticlabs) or [email](mailto:support@plasticlabs.ai)!
 </Note>
 
 ## Next Steps

docs/v3/documentation/features/advanced/deleting-data.mdx

@@ -1,131 +0,0 @@
----
-title: 'Deleting Data'
-description: 'How to delete sessions, workspaces, and conclusions — and what survives each'
-icon: 'trash'
----
-
-Deletion in Honcho is **permanent and cannot be undone**. There is no soft
-delete, no trash, and no restore.
-
-## What can be deleted
-
-| Resource | Endpoint | Behavior |
-|---|---|---|
-| Session | `DELETE /v3/workspaces/{workspace_id}/sessions/{session_id}` | `202` — cascade runs in the background |
-| Workspace | `DELETE /v3/workspaces/{workspace_id}` | `202` — cascade runs in the background |
-| Conclusion | `DELETE /v3/workspaces/{workspace_id}/conclusions/{conclusion_id}` | `204` — immediate |
-| Webhook endpoint | `DELETE /v3/workspaces/{workspace_id}/webhooks/{endpoint_id}` | Immediate |
-
-**Peers and individual messages cannot be deleted.** To remove a peer's data,
-delete the sessions it participated in, then delete its remaining conclusions
-(see [Conclusions outlive their sessions](#conclusions-outlive-their-sessions)).
-To remove a peer from one conversation without deleting anything, use
-[remove peers from session](/v3/api-reference/endpoint/sessions/remove-peers-from-session)
-instead.
-
-## Deleting a session
-
-```bash
-curl -X DELETE "$HONCHO_URL/v3/workspaces/my-app/sessions/session-1" \
-  -H "Authorization: Bearer $HONCHO_API_KEY"
-```
-
-The session is marked inactive immediately and the endpoint returns `202
-Accepted`. The cascade — messages, message embeddings, queued reasoning work,
-session-scoped conclusions, and peer associations — is processed in the
-background with retries.
-
-Because the work is asynchronous, a `202` means *accepted*, not *finished*. The
-session drops out of session listings right away, but its messages and
-conclusions drain afterwards. Deletion tasks are internal infrastructure work
-and do **not** appear in
-[queue status](/v3/documentation/features/advanced/queue-status) counts, so
-there is no endpoint that reports when the cascade has finished.
-
-<CodeGroup>
-```python Python
-session.delete()
-```
-
-```typescript TypeScript
-await session.delete();
-```
-</CodeGroup>
-
-## Deleting a workspace
-
-A workspace can only be deleted once it has **no active sessions**. Deleting a
-workspace that still has sessions returns `409 Conflict`:
-
-```json
-{"detail": "Cannot delete workspace 'my-app': active session(s) remain. Delete all sessions first."}
-```
-
-The correct order is:
-
-1. List the workspace's sessions — `POST /v3/workspaces/{workspace_id}/sessions/list`
-2. Delete each session — `DELETE /v3/workspaces/{workspace_id}/sessions/{session_id}`
-3. Delete the workspace — `DELETE /v3/workspaces/{workspace_id}`
-
-Step 2 returns `202`, so the session deletions are still draining when step 3
-runs. That is fine: a session is marked inactive synchronously, so the workspace
-delete stops returning `409` as soon as the deletes are accepted. Any session
-created after the workspace deletion is accepted is cascade-deleted too.
-
-<CodeGroup>
-```python Python
-# Materialize the list first — deleting shifts the pagination window
-for session in list(honcho.sessions()):
-    session.delete()
-
-honcho.delete_workspace("my-app")
-```
-
-```typescript TypeScript
-// Materialize the list first — deleting shifts the pagination window
-const sessions = [];
-for await (const session of await honcho.sessions()) sessions.push(session);
-for (const session of sessions) await session.delete();
-
-await honcho.deleteWorkspace("my-app");
-```
-</CodeGroup>
-
-Deleting a workspace removes every peer, session, message, conclusion,
-collection, embedding, webhook endpoint, and queued task belonging to it.
-
-## Conclusions outlive their sessions
-
-This is the most common surprise. Deleting a session does **not** erase
-everything Honcho learned in it.
-
-- **Explicit conclusions** — direct facts drawn from messages — are tied to the
-  session they came from and are deleted with it.
-- **Derived conclusions** (deductive, inductive, contradiction) are consolidations
-  that may draw on several sessions. They are stored at the workspace level with
-  no owning session, so they survive session deletion and stay in the peer's
-  [representation](/v3/documentation/core-concepts/representation).
-
-To remove those, list and delete them directly:
-
-<CodeGroup>
-```python Python
-for conclusion in alice.conclusions.list():
-    alice.conclusions.delete(conclusion.id)
-```
-
-```typescript TypeScript
-for (const conclusion of await alice.conclusions.list()) {
-  await alice.conclusions.delete(conclusion.id);
-}
-```
-</CodeGroup>
-
-Deleting the whole workspace removes conclusions at every level and needs no
-follow-up.
-
-## Permissions
-
-Session and workspace deletion accept any key scoped to that workspace — an
-admin key is not required. Deleting a session additionally accepts a
-session-scoped key.

docs/v3/documentation/features/advanced/overview.mdx

@@ -7,20 +7,15 @@ sidebarTitle: "Overview"
 
 Advanced features give you fine-grained control over Honcho's behavior and implementation.
 
-## Reasoning & Memory
+## Configuration & Monitoring
 
-- [Configuration](/v3/documentation/features/advanced/reasoning-configuration) - Configure reasoning models and behavior
-- [Summarizer](/v3/documentation/features/advanced/summarizer) - Automatic session summarization
-- [Peer Card](/v3/documentation/features/advanced/peer-card) - Quick-reference profile of stable biographical facts about a peer
-- [Directional Representations](/v3/documentation/features/advanced/directional-representations) - How peers build separate representations of each other
-- [Scopes](/v3/documentation/features/advanced/scopes) - Named sets of sessions that act as visibility boundaries for recall
 - [Dreaming](/v3/documentation/features/advanced/dreaming) - Autonomous memory consolidation and self-improvement
 - [Queue Status](/v3/documentation/features/advanced/queue-status) - Monitor background processing and reasoning tasks
+- [Configuration](/v3/documentation/features/advanced/reasoning-configuration) - Configure reasoning models and behavior
+- [Summarizer](/v3/documentation/features/advanced/summarizer) - Automatic session summarization
 
-## Querying & Data
+## Querying & Filtering
 
 - [Search](/v3/documentation/features/advanced/search) - Search across peers, sessions, and messages
 - [Filters](/v3/documentation/features/advanced/using-filters) - Filter queries with advanced parameters
 - [Streaming Responses](/v3/documentation/features/advanced/streaming-response) - Stream dialectic responses in real-time
-- [File Uploads](/v3/documentation/features/advanced/file-uploads) - Ingest files into peer memory
-- [Deleting Data](/v3/documentation/features/advanced/deleting-data) - Delete sessions, workspaces, and conclusions