diff --git a/docs/v3/documentation/features/advanced/queue-status.mdx b/docs/v3/documentation/features/advanced/queue-status.mdx index 44e9a045..9473a91d 100644 --- a/docs/v3/documentation/features/advanced/queue-status.mdx +++ b/docs/v3/documentation/features/advanced/queue-status.mdx @@ -95,7 +95,7 @@ not the total number of items ever processed. The `queue_status` method can take additional -parameters to narrow the status to a specific work unit: +parameters to filter the status by a matching observer, sender, or session: ```python Python diff --git a/docs/v3/documentation/features/advanced/scopes.mdx b/docs/v3/documentation/features/advanced/scopes.mdx index 9ae1b7bc..4fa827fd 100644 --- a/docs/v3/documentation/features/advanced/scopes.mdx +++ b/docs/v3/documentation/features/advanced/scopes.mdx @@ -48,7 +48,8 @@ graph TB that name it; it does not hide the sessions from requests that don't. -Scopes are a recall boundary, not an authorization boundary. Access can be scoped by workspace, session, or peer boundaries. +Scopes are a recall boundary, not an authorization boundary. Who may call the +API is still governed by workspace, session, and peer keys. ## The Two Arms @@ -62,7 +63,7 @@ wrong one is the most common mistake with this feature. | **Conclusions** | All levels — `explicit`, plus `deductive` / `inductive` reasoned **within** the scope | `explicit` only | | **Reasoning chains** | Available | Unavailable | | **Setup required** | Yes — create the scope, add sessions, wait for backfill | None — pass session IDs ad hoc | -| **Accepts** | One scope name, or a list of up to 100 | Up to 1,000 session IDs | +| **Accepts** | One scope name | A list of up to 100 scope names, or up to 1,000 session IDs | ### Named scope: depth @@ -109,7 +110,7 @@ from honcho import Honcho honcho = Honcho(workspace_id="my-app") -# Get or create — idempotent +# Get or create — idempotent; passing metadata updates the existing scope therapy = honcho.scope("therapy") # Add existing sessions (max 100 per call) @@ -133,7 +134,7 @@ import { Honcho } from "@honcho-ai/sdk"; const honcho = new Honcho({ workspaceId: "my-app" }); -// Get or create — idempotent +// Get or create — idempotent; passing metadata updates the existing scope const therapy = await honcho.scope("therapy"); // Add existing sessions (max 100 per call) @@ -180,7 +181,8 @@ curl -X DELETE "$HONCHO_URL/v3/workspaces/my-app/scopes/therapy/sessions/therapy Scope IDs are unprefixed, must match `^[a-zA-Z0-9_-]+$`, and are at most 506 -characters. +characters. Get-or-create is idempotent: if the scope already exists, the same +call returns it, and any `metadata` you pass is written onto it. Every scopes route — and every read that passes `scope` — requires a @@ -234,7 +236,7 @@ empty result means none have — not that the scope is empty. ## Reading Through a Scope -`scope` is accepted on four surfaces: +`scope` is accepted on these surfaces: | Surface | Accepts | Notes | |---------|---------|-------| @@ -242,6 +244,7 @@ empty result means none have — not that the scope is empty. | `peer.representation()` | one scope or a list | Confines conclusion recall | | [`session.context()`](/v3/documentation/features/get-context) | one scope only | Perspective source for `peer_target`'s representation and card. Requires `peer_target`; mutually exclusive with `peer_perspective` | | `honcho.search()` | one scope only | Restricts message search to the scope's member sessions | +| `honcho.chat()` | one scope or a list | Always the allowlist arm — even a single name. There is no observer to swap | ```python Python @@ -321,8 +324,11 @@ A few behaviors follow from how scopes are built: - **The `scope.` prefix is reserved.** Creating a peer, or adding a peer to a session, with a `scope.`-prefixed name is rejected. -- **Scopes are hidden from peer listings by default.** Pass `kind="scope"` to - list only scopes, or `kind="all"` to see both. +- **List scopes through the scopes surface.** `honcho.scopes()` / + `POST /scopes/list` returns unprefixed ids. Peer listings hide scopes by + default; `kind="scope"` on `POST /peers/list` returns the backing peers named + `scope.`, and `kind="all"` includes both regular peers and those backing + peers. - **A scope can't be observed.** No representation is formed *of* a scope, so a scope is rejected in any `target` / observed position, including as a dream target. diff --git a/docs/v3/documentation/features/advanced/search.mdx b/docs/v3/documentation/features/advanced/search.mdx index a95fff15..cf40648c 100644 --- a/docs/v3/documentation/features/advanced/search.mdx +++ b/docs/v3/documentation/features/advanced/search.mdx @@ -49,6 +49,20 @@ import { Honcho } from "@honcho-ai/sdk"; ``` +Pass `scope` on workspace search to restrict matches to that +[scope](/v3/documentation/features/advanced/scopes)'s member sessions. A scope +with no members returns nothing. + + +```python Python +results = honcho.search("budget planning", scope="therapy") +``` + +```typescript TypeScript +const results = await honcho.search("budget planning", { scope: "therapy" }); +``` + + ### Session Search Search within a specific session's conversation history: diff --git a/docs/v3/documentation/features/chat.mdx b/docs/v3/documentation/features/chat.mdx index dc58b144..c83a0ac2 100644 --- a/docs/v3/documentation/features/chat.mdx +++ b/docs/v3/documentation/features/chat.mdx @@ -115,6 +115,12 @@ constrained `filters` body on the endpoint. See [Scoping Recall to Sessions](/v3/documentation/features/advanced/using-filters#scoping-recall-to-sessions) for the accepted shapes and for what an allowlist changes about the answer. +Pass `scope="therapy"` to answer from that [scope](/v3/documentation/features/advanced/scopes)'s +own representation of the peer. A list (`scope=["therapy", "intake"]`) is an +allowlist of those scopes' sessions, not named-scope depth. +`honcho.chat(scope=)` is always the allowlist arm, even with one name. Details +are on the [scopes page](/v3/documentation/features/advanced/scopes#the-two-arms). + ## Structured Outputs When your application needs a machine-readable answer instead of prose, pass a schema as `response_format` and the answer is guaranteed to conform to it: diff --git a/docs/v3/documentation/features/get-context.mdx b/docs/v3/documentation/features/get-context.mdx index 60ff45bc..4707f14c 100644 --- a/docs/v3/documentation/features/get-context.mdx +++ b/docs/v3/documentation/features/get-context.mdx @@ -99,7 +99,7 @@ context = session.context(summary=False, tokens=2000) ### Peer Representation in Context -You can include a peer's [representation](/v3/documentation/core-concepts/representation) and peer card in the context by specifying `peer_target`. This is useful for providing the LLM with knowledge about a specific peer. +You can include a peer's [representation](/v3/documentation/core-concepts/representation) and peer card in the context by specifying `peer_target`. This is useful for providing the LLM with knowledge about a specific peer. Pass `scope` with `peer_target` to use a [named scope](/v3/documentation/features/advanced/scopes) as the perspective source (`scope` is mutually exclusive with `peer_perspective`). ```python Python @@ -119,6 +119,14 @@ context = session.context( peer_target="user-123", peer_perspective="assistant" # From assistant's viewpoint ) + +# Or use a named scope as the perspective source (requires peer_target; +# mutually exclusive with peer_perspective) +context = session.context( + tokens=2000, + peer_target="user-123", + scope="therapy", +) ``` ```typescript TypeScript @@ -139,6 +147,14 @@ context = session.context( peerTarget: "user-123", peerPerspective: "assistant" // From assistant's viewpoint }); + + // Or use a named scope as the perspective source (requires peerTarget; + // mutually exclusive with peerPerspective) + const scopedContext = await session.context({ + tokens: 2000, + peerTarget: "user-123", + scope: "therapy", + }); })(); ``` @@ -211,6 +227,7 @@ context = session.context( | `tokens` | `int` | Maximum tokens to include | | `peer_target` | `str` | Peer ID to include representation for | | `peer_perspective` | `str` | Peer ID for perspective (requires peer_target) | +| `scope` | `str` | Named scope as the perspective source for `peer_target`'s representation and card. Requires `peer_target`; mutually exclusive with `peer_perspective`. See [Scopes](/v3/documentation/features/advanced/scopes) | | `search_query` | `str` | Query for semantic search (requires peer_target) | | `limit_to_session` | `bool` | Limit to session conclusions only | | `search_top_k` | `int` | Semantic search results to include (1-100) |