@north-light/crouter 0.3.352 → 0.3.354

package/docs/concepts/lifecycle-and-wakes.md

@@ -23,4 +23,4 @@ A node wakes when work actually arrives: a subscribed child pushes a report, ano
 
 Do not keep a node active to poll a child, a person, or a message. Creation automatically subscribes a parent to its child, and the runtime delivers the child’s outcome. Waiting for something the canvas can push is free: end the turn and let the node become dormant. Schedule a cron only for recurring work or an external condition that nothing can push into the canvas, such as checking a CI run. A timer added “just in case” a child does not report duplicates a runtime guarantee and hides a runtime defect.
 
-A broker crash does not erase the node. The daemon retains the durable node row, conversation, waits, and outstanding inbox entries, then applies its recovery policy. This is what makes a resident event-driven assistant practical: it can wait for a webhook, be dormant for hours, and resume its saved work only when the webhook produces a message. Use [`nodes.message`](../sdk/nodes.md#sending-a-follow-up) to deliver that external event, and run `crtr memory read internal/nodes-and-canvas` for lifecycle operations.
+A broker crash does not erase the node. The daemon retains the durable node row, conversation, waits, and outstanding inbox entries, then applies its recovery policy. This is what makes a resident event-driven assistant practical: it can wait for a webhook, be dormant for hours, and resume its saved work only when the webhook produces a message. Use [`nodes.message`](../sdk/nodes.md#sending-a-follow-up) to deliver that external event, and run `crtr canvas read internal/nodes-and-canvas` for lifecycle operations.

package/docs/concepts/memory.md

@@ -1,34 +1,34 @@
 ---
-title: Memory
-description: When shaping an agent without rewriting its prompt, read this because memory documents separate facts to consult from behavior to embody and let each owner control who receives them.
+title: Documents
+description: When shaping an agent without rewriting its prompt, read this because documents separate facts to consult from behavior to embody and let each owner control who receives them.
 ---
 
-# Memory
+# Documents
 
-Memory shapes a node without adding the same instructions to every prompt. A memory document says what it contains, who owns it, and when it should enter context. The result is durable guidance that can be discovered when relevant instead of a growing startup prompt.
+Documents shape a node without adding the same instructions to every prompt. A document says what it contains, who owns it, and when it should enter context. The result is durable guidance that can be discovered when relevant instead of a growing startup prompt.
 
 There are two kinds. **Knowledge** is something an agent consults: a procedure, fact, or technical reference. A **preference** is behavior the agent should embody: a standing directive or correction. This is a use-based split. A procedure and a fact are both knowledge because the agent reads either one to answer a question; a preference changes how it acts.
 
-| Tier | Owner | Put here |
+| Owner | Who it is | Put here |
 |---|---|---|
 | Node | One running node | A note needed across that node’s fresh contexts |
-| Project | One repository or workspace | Repository facts and procedures |
+| Repo | One repository | Repository facts and procedures |
 | Profile | One application identity and its purview | Application-wide conventions and knowledge |
 | User | One person | Facts and preferences that follow them everywhere |
-| Builtin | crouter | Runtime documentation that ships to every user |
+| Plugin `crtr` | crouter | Runtime documentation that ships to every user |
 
-Choose the narrowest tier that reaches the next agent who needs the document. For an application author, the profile store is the usual home for knowledge shared by that application’s nodes across repositories. [`client.memory`](../sdk/memory.md) names a target for every operation, so the daemon resolves the application’s profile rather than its own current directory. A node’s `memory:read` and `memory:write` scopes can respectively permit reading while denying changes.
+Choose the narrowest owner that reaches the next agent who needs the document. For an application author, the profile is the usual owner for knowledge shared by that application’s nodes across repositories. A node’s `memory:read` and `memory:write` scopes can respectively permit reading while denying changes.
 
 ```mermaid
 flowchart LR
-  Doc[Memory document] --> Surface[Surface entry: event, gate, rung]
-  Surface -->|event matches| Preview[Name, preview, or full body]
-  Preview --> Route[Routing line tells the agent why to read]
-  Route --> Read[Explicit full read when needed]
+  Doc[Document] --> Rule[Delivery rule: on, if, deliver]
+  Rule -->|activity matches| Preview[Name, preview, or full body]
+  Preview --> Line[Preview tells the agent why to read]
+  Line --> Read[Explicit full read when needed]
 ```
 
-A surface entry is the delivery mechanism. A document is not loaded because it sits in a particular folder or because its routing line resembles the task. Its frontmatter names an event such as boot, workspace-open, file read, memory read, command, or pre-command; that entry can also match a path or gate on the node’s shape and selects a rung: its name, a preview, or its full content. A document with no surface entry stays in its directory listing until an agent deliberately finds or reads it.
+A delivery rule is the delivery mechanism. A document is not loaded because of its name or because its preview resembles the task. Each rule names an activity such as boot, workspace-open, file-read, document-read, command, or pre-command; it can also match a path, carry an `if` on the node’s shape, and selects what to deliver: the name, the preview, or the full content. A document with no delivery rule stays in its listing until an agent deliberately finds or reads it.
 
-The routing line is the preview at the middle rung, not a trigger. For example, a profile document can have a file-read surface that delivers a preview when an order record is opened. Its line — “When handling a refund request, read this because the eligibility window is not in the order record” — then tells the agent why an explicit full read is useful. The event delivers the preview; the line helps the agent decide whether to read the body without pretending to replace it.
+The preview is delivered at the middle level, not a trigger. For example, a profile document can have a file-read rule that delivers its preview when an order record is opened. Its line — “When handling a refund request, read this because the eligibility window is not in the order record” — then tells the agent why an explicit full read is useful. The rule delivers the preview; the line helps the agent decide whether to read the body without pretending to replace it.
 
-Memory therefore supports progressive disclosure. You can record knowledge freely, but it costs future contexts only when an explicit surface route delivers it. Read `crtr memory write -h` to author a document and `crtr memory read internal/memory-loading` for the routing mechanics. The SDK [memory page](../sdk/memory.md) shows how an application creates and revises its profile documents.
+Documents therefore support progressive disclosure. You can record knowledge freely, but it costs future contexts only when a delivery rule delivers it. Read `crtr doc write -h` to write a document and `crtr canvas read internal/memory-loading` for the delivery mechanics.

package/docs/concepts/nodes-and-the-canvas.md

@@ -25,4 +25,4 @@ The one way work reports upward is a **push**. A push writes a durable report an
 
 A node owns an outcome, not merely an artifact. It may write files and reports while working, but its terminal result is credible only when it has evidence that the requested goal was met. The canvas supports that responsibility: it preserves the goal, durable artifacts, reports, and relationships across fresh contexts and broker replacement.
 
-Use a one-shot SDK call such as [`nodes.parse`](../sdk/nodes.md#parse-and-structured-output) when work is bounded and its only useful output is a typed result. Use `nodes.create` when the application needs a continuing conversation or must observe work while it runs. For the operational graph and report model, run `crtr memory read internal/nodes-and-canvas`.
+Use a one-shot SDK call such as [`nodes.parse`](../sdk/nodes.md#parse-and-structured-output) when work is bounded and its only useful output is a typed result. Use `nodes.create` when the application needs a continuing conversation or must observe work while it runs. For the operational graph and report model, run `crtr canvas read internal/nodes-and-canvas`.

package/docs/concepts/profiles-kinds-and-modes.md

@@ -1,6 +1,6 @@
 ---
 title: Profiles, kinds, and modes
-description: When designing an agent run, read this because profiles, kinds, modes, and memory tiers solve different problems and prevent a long prompt from becoming an unstable substitute for an application identity.
+description: When designing an agent run, read this because profiles, kinds, modes, and document owners solve different problems and prevent a long prompt from becoming an unstable substitute for an application identity.
 ---
 
 # Profiles, kinds, and modes
@@ -12,20 +12,20 @@ Shape a run by choosing the dial that owns the decision. The four dials are inde
 | Profile | Which application identity, project purview, environment, and profile memory apply? | An application or body of work has stable directories and conventions |
 | Kind | What standing role, model tier, tools, and expertise should the agent have? | The work matches a recurring role such as developer or reviewer |
 | Mode | Does this node work hands-on or coordinate independent children? | Parallel work makes coordination the main job |
-| Memory tier | Who should receive a document? | Guidance must reach one node, project, profile, user, or all crouter users |
+| Document owner | Who should receive a document? | Guidance must reach one node, repo, profile, user, or all crouter users |
 
-A profile is not a label on a run. It is a stable agent identity with its own memory store and a purview of project directories. It lets an application create nodes from the same target context even if the caller runs elsewhere. Create a profile when an app has a durable set of directories, environment values, and conventions worth sharing. Do not make a profile for every repository or individual request. Use [`client.profiles`](../sdk/resources.md) and the SDK’s `profile` create field to select the application’s identity.
+A profile is not a label on a run. It is a stable agent identity with its own documents and a purview of project directories. It lets an application create nodes from the same target context even if the caller runs elsewhere. Create a profile when an app has a durable set of directories, environment values, and conventions worth sharing. Do not make a profile for every repository or individual request. Use [`client.profiles`](../sdk/resources.md) and the SDK’s `profile` create field to select the application’s identity.
 
 ```mermaid
 flowchart LR
   Profile[Profile: purview, environment, memory] --> Node
   Kind[Kind: role and tools] --> Node
   Mode[Mode: base or orchestrator] --> Node
-  Tier[Memory tier: reach] --> Node
+  Tier[Document owner: reach] --> Node
 ```
 
 A kind is a recurring role, not a decorative name. It carries a role-specific posture and may choose a suitable model tier and tools. A custom kind beats a long prompt when the role recurs and needs standing discipline that should survive every run: for example, an application’s compliance reviewer that always needs the same tools, expertise, and model choice. A one-off instruction belongs in the node’s prompt, where it does not create a permanent persona to maintain.
 
 Base mode is the normal choice: the node owns and performs the work, using a child only for a separable part. Promote to orchestrator only when independent parts can proceed in parallel and the benefits outweigh coordination and integration. A terminal orchestrator still finishes normally; residency is separate and belongs to a person-facing ongoing conversation.
 
-These choices keep the application prompt focused. Identity belongs in a profile, standing role in a kind, task-specific intent in the prompt, coordination in mode, and reusable knowledge in the narrowest memory tier. For the full selection rules, run `crtr memory read internal/agent-shaping`; [`nodes.create`](../sdk/nodes.md) documents the profile, kind, and mode fields an application passes.
+These choices keep the application prompt focused. Identity belongs in a profile, standing role in a kind, task-specific intent in the prompt, coordination in mode, and reusable knowledge in the narrowest document owner. For the full selection rules, run `crtr canvas read internal/agent-shaping`; [`nodes.create`](../sdk/nodes.md) documents the profile, kind, and mode fields an application passes.

package/docs/concepts/scopes-and-trust.md

@@ -29,4 +29,4 @@ Scopes rely on a more basic trust boundary: `crtrd` is the sole writer of durabl
 
 For a browser or remote process, run `crtr sys connect`. It enables the daemon’s TCP listener when needed and returns `base_url` plus a bearer `token` to give the application. `crtr sys connect --scopes …` mints a new scoped token instead of returning the owner token. Treat either token as a credential: the remote app sends it as `Authorization: Bearer <token>`, and its scope list is the ceiling for scope-gated calls and newly created nodes.
 
-The remote API is an explicit boundary, not permission to reach around it. Keep application code on the SDK or `/v1` contract, and let the daemon own state transitions. Run `crtr memory read internal/nodes-and-canvas` for the operational ownership model.
+The remote API is an explicit boundary, not permission to reach around it. Keep application code on the SDK or `/v1` contract, and let the daemon own state transitions. Run `crtr canvas read internal/nodes-and-canvas` for the operational ownership model.

package/docs/concepts/why-a-daemon.md

@@ -26,4 +26,4 @@ The costs are real. A daemon must be running, and canvas state has one home inst
 
 Those costs buy a simpler model: one state owner, one broker launcher, and clients that can reconnect. A CLI command, an SDK application, and a terminal viewer all use the same API for canvas state. They can come and go without creating competing writers or losing the graph that explains what each agent is doing.
 
-For the lower-level runtime model, run `crtr memory read internal/nodes-and-canvas`. For a complete remote application setup, start with the SDK [getting started guide](../sdk/getting-started.md).
+For the lower-level runtime model, run `crtr canvas read internal/nodes-and-canvas`. For a complete remote application setup, start with the SDK [getting started guide](../sdk/getting-started.md).

package/docs/sdk/README.md

@@ -5,7 +5,7 @@ description: Drive a crouter daemon from a Node or browser application with the
 
 # `@north-light/crouter-sdk`
 
-The ESM-only client an application installs to drive a crouter daemon: create agent runs, watch streamed events, wait for typed results, read and write memory, and reach the rest of the daemon's `/v1` API.
+The ESM-only client an application installs to drive a crouter daemon: create agent runs, watch streamed events, wait for typed results, and reach the rest of the daemon's `/v1` API.
 
 One package, one class. `new Crouter()` in Node talks to the owner's unix socket. `new Crouter({ baseURL, token })` in a browser or a remote process talks to the daemon's TCP listener with a bearer token. Resource methods issue `/v1` requests; `createAndWait`, `parse`, and `auth.status` compose more than one request. crtrd stays the sole owner of canvas state.
 
@@ -32,7 +32,6 @@ if (run.kind === 'result') console.log(run.output_parsed.root_cause);
 | [Client construction](./client.md) | Every constructor option and its environment-variable fallback; per-request options |
 | [Nodes](./nodes.md) | `create` parameters, the outcome union, `parse()` with a zod schema, `waitForOutcome`, `message`, `cancel`, nested resources |
 | [Streaming](./streaming.md) | The event table, `stream()` / `events()`, the activity helper, resume with `after`, `stream_gap` and `stream_dropped` |
-| [Memory](./memory.md) | The scope object and every `client.memory` method |
 | [Files](./files.md) | Absolute-path reads, writes, and one-level lists |
 | [Bash](./bash.md) | One bounded command and its output result |
 | [Resource map](./resources.md) | Every namespace with its phase, what is deliberately excluded, and the `client.request()` escape hatch |
@@ -42,21 +41,21 @@ if (run.kind === 'result') console.log(run.output_parsed.root_cause);
 
 ## Phases
 
-The surface ships in three cuts. Phase 3 memory methods are shipped.
+The surface ships in three cuts.
 
 | Phase | What lands | State |
 |---|---|---|
 | **Phase 1** | Client construction and transports; `client.auth.status()`; `client.nodes.create`, `retrieve`, `list`, `outcome`, `waitForOutcome`, `createAndWait`, `parse`, `message`, `cancel`, and `interrupt`; `nodes.reports.list`; `profiles.ensure` and `retrieve`; `system.status` and `health`; the error hierarchy; per-request options; `crtr sys connect`; and `env-docker.connection()` | Shipped |
 | **Phase 2 namespaces** | Node lifecycle, job, worktree, and result; canvas and canvas history; crons; human requests and inbox; models; `client.files.read` through `/v1/files/peek`, `write`, and `list`; and `client.bash.run` | Shipped |
 | **Phase 2 streaming** | `GET /v1/nodes/{id}/events`, `nodes.stream(params, options?)`, `nodes.events(id, options?)`, `NodeStream`, and the activity helper | Shipped |
-| **Phase 3** | Memory routes and `client.memory`, plus the review, comment, and chat-inventory namespaces | Memory shipped; remaining namespaces not shipped |
+| **Phase 3** | The review, comment, and chat-inventory namespaces | Not shipped |
 
 The per-run `scopes` create field ships in phase 1. `nodes.update` scope support remains phase 2 and is not in the shipped client or wire declarations.
 
 ## Verification status
 
-The SDK declarations, streaming examples, and memory examples are verified.
+The SDK declarations and streaming examples are verified.
 
 ## Where the agents read this
 
-The same content routed for agents lives in the builtin memory document `crouter-sdk`, which ships with the `crtr` binary. An agent working in an application's repository reaches it with `crtr memory read crouter-sdk` and does not need this repository checked out.
+The same content routed for agents lives in the builtin memory document `crouter-sdk`, which ships with the `crtr` binary. An agent working in an application's repository reaches it with `crtr canvas read crouter-sdk` and does not need this repository checked out.

package/docs/sdk/errors.md

@@ -64,19 +64,6 @@ The SDK validates path-segment identifiers before it makes a request. Invalid no
 | The bearer token's ceiling lacks the scope a route needs, or `nodes.create` asks for `scopes` outside it (`details.scopes` lists them) | `PermissionDeniedError`, 403 `scope_denied` |
 | A scoped token reaches an owner-only route (daemon restart, attach, broker internals, canvas prune, profile pause/resume/delete, model credential install) | `PermissionDeniedError`, 403 `owner_only` |
 
-## Memory requests
-
-| Condition | Class, status, and code |
-|---|---|
-| `retrieve` or `resolve` names a document that does not exist, including a document deleted earlier | `NotFoundError`, 404 `memory_document_not_found` |
-| `history` names a document with no document or revision history | `NotFoundError`, 404 `not_found` |
-| History is requested for a builtin or plugin document | `BadRequestError`, 400 `usage` |
-| A mutation directly sets protected frontmatter (`kind`, `when-and-why-to-read`, `origin`, or `last-updated`) | `BadRequestError`, 400 `invalid_request` |
-| An update would make no change | `BadRequestError`, 400 `usage` |
-| A node-targeted caller lacks `memory:read` or `memory:write` | `PermissionDeniedError`, 403 `scope_denied` |
-
-Invalid names, invalid scope combinations, invalid limits, builtin mutation selections, and invalid search combinations are also `BadRequestError` responses. Builtin and plugin documents cannot be mutated; no code should treat a 400 refusal as a successful write.
-
 ## The wire body
 
 The daemon answers an error with:

package/docs/sdk/guides/README.md

@@ -13,6 +13,5 @@ These recipes turn the SDK namespaces into complete applications: a bounded extr
 | [Event-driven assistant](./event-driven-assistant.md) | Events arrive over time from a webhook, queue, or watcher. | A resident node that wakes for each event. |
 | [Fan-out pipeline](./fan-out-pipeline.md) | One task needs independent research before a synthesis. | An orchestrator's final report. |
 | [Human approval](./human-approval.md) | A person must decide before work continues. | A node resumed by an inbox answer. |
-| [Application memory](./app-memory.md) | Several runs need the same durable application knowledge. | A profile-owned document read by a scoped run. |
 
 Start with typed extraction for a request/response job. Use a resident node when the same assistant should react again later. Use an orchestrator only when child work can proceed independently; otherwise keep the composition in your application.

package/docs/sdk/nodes.md

@@ -189,8 +189,6 @@ for (const report of reports) console.log(report.tier, report.body);
 
 List routes return what the daemon returns. `nodes.list`, `nodes.reports.list`, and `nodes.jobs.list` return plain arrays — there is no page object, no `hasNextPage()`, and no `after` cursor on them, because the daemon has no paging substrate behind those routes and an envelope there would promise a continuation that can never happen.
 
-The one place the page envelope exists is the phase-3 memory routes. See [Memory](./memory.md).
-
 ## Identifier validation
 
 Methods that take a node id validate it before the request: core node methods, lifecycle methods, `nodes.reports`, `nodes.jobs`, `nodes.worktree`, and `nodes.result`. An invalid id throws `TypeError` locally and sends no request. `nodes.outcome(id, { wait })` also throws `RangeError` locally when `wait` is not an integer from 0 through 25.

package/docs/sdk/resources.md

@@ -26,7 +26,6 @@ Every namespace exported by the client. Namespaces are camelCase. Verbs are `cre
 | `human.inbox` | `list`, `retrieve`, `respond`, `progress`, `cancel`, `history`, `response` | `/v1/human/inbox…` |
 | `models.credentials` | `list`, `install`, `remove` | `/v1/model-auth…` |
 | `models.config` | `update` | `PUT /v1/model-config` |
-| `memory` | `list`, `retrieve`, `create`, `update`, `delete`, `move`, `search`, `history`, `resolve` | `/v1/memory…`; see [Memory](./memory.md) |
 
 Action methods keep the product's literal name (`fork`, `revive`, `promote`, `yield`) rather than being renamed into a generic verb. Every request-capable method takes `RequestOptions` as its final argument after its path, body, or query arguments. `RequestOptions` is `{ headers?, signal?, timeout?, maxRetries? }`; stream event options exclude `timeout` and add `after`.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@north-light/crouter",
-  "version": "0.3.352",
+  "version": "0.3.354",
   "description": "crtr — agent runtime with memory, plugins, and marketplaces",
   "type": "module",
   "main": "dist/index.js",
@@ -131,7 +131,7 @@
     "@earendil-works/pi-ai": "0.87.1",
     "@earendil-works/pi-coding-agent": "0.87.1",
     "@earendil-works/pi-tui": "0.87.1",
-    "@north-light/crouter-identity": "^0.3.352",
+    "@north-light/crouter-identity": "^0.3.354",
     "cron-parser": "^5.6.0",
     "esbuild": "^0.27.7",
     "jose": "^6.2.12",

package/packages/crouter-identity/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@north-light/crouter-identity",
-  "version": "0.3.352",
+  "version": "0.3.354",
   "description": "Northlight access-token verification and scope rules",
   "type": "module",
   "main": "./dist/index.js",

package/runtime.lock.json

@@ -1,12 +1,12 @@
 {
   "name": "@north-light/crouter",
-  "version": "0.3.352",
+  "version": "0.3.354",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@north-light/crouter",
-      "version": "0.3.352",
+      "version": "0.3.354",
       "hasInstallScript": true,
       "license": "GPL-3.0-only",
       "workspaces": [
@@ -18,7 +18,7 @@
         "@earendil-works/pi-ai": "0.87.1",
         "@earendil-works/pi-coding-agent": "0.87.1",
         "@earendil-works/pi-tui": "0.87.1",
-        "@north-light/crouter-identity": "^0.3.352",
+        "@north-light/crouter-identity": "^0.3.354",
         "cron-parser": "^5.6.0",
         "esbuild": "^0.27.7",
         "jose": "^6.2.12",
@@ -10885,17 +10885,17 @@
     },
     "packages/crouter-api": {
       "name": "@north-light/crouter-api",
-      "version": "0.3.352",
+      "version": "0.3.354",
       "license": "GPL-3.0-only"
     },
     "packages/crouter-env-docker": {
       "name": "@north-light/crouter-env-docker",
-      "version": "0.3.352",
+      "version": "0.3.354",
       "license": "GPL-3.0-only"
     },
     "packages/crouter-identity": {
       "name": "@north-light/crouter-identity",
-      "version": "0.3.352",
+      "version": "0.3.354",
       "license": "GPL-3.0-only",
       "dependencies": {
         "jose": "^6.2.1"
@@ -10903,19 +10903,19 @@
     },
     "packages/crouter-plugin": {
       "name": "@north-light/crouter-plugin",
-      "version": "0.3.352",
+      "version": "0.3.354",
       "license": "GPL-3.0-only",
       "dependencies": {
-        "@north-light/crouter-api": "^0.3.352"
+        "@north-light/crouter-api": "^0.3.354"
       }
     },
     "packages/crouter-sdk": {
       "name": "@north-light/crouter-sdk",
-      "version": "0.3.352",
+      "version": "0.3.354",
       "license": "GPL-3.0-only",
       "dependencies": {
-        "@north-light/crouter-api": "^0.3.352",
-        "@north-light/crouter-identity": "^0.3.352",
+        "@north-light/crouter-api": "^0.3.354",
+        "@north-light/crouter-identity": "^0.3.354",
         "jose": "^6.2.1"
       }
     }

package/dist/api/dto/memory.d.ts

@@ -1,171 +0,0 @@
-export declare const MEMORY_SCOPES: readonly ["node", "project", "profile", "user", "builtin"];
-export type MemoryScopeName = typeof MEMORY_SCOPES[number];
-/** A canonical document address: slash-joined safe segments, carried as one percent-encoded path segment. */
-export declare function isMemoryDocName(name: string): boolean;
-export interface MemoryOriginConversationDTO {
-    session_file: string;
-}
-export interface MemoryScope {
-    node?: string;
-    cwd?: string;
-    profile?: string;
-    store?: MemoryScopeName;
-}
-export interface MemoryDocSummaryDTO {
-    name: string;
-    short_form: string;
-    kind: string;
-    privacy: 'public' | 'friends' | 'private';
-    scope: MemoryScopeName;
-    extensions: Record<string, Record<string, string | boolean | number>>;
-    path: string;
-    store_root: string;
-    physical_relative_path: string;
-    candidates?: MemoryCandidateDTO[];
-}
-export interface MemoryCandidateDTO {
-    winner: boolean;
-    scope: MemoryScopeName;
-    store_root: string;
-    physical_relative_path: string;
-    path: string;
-}
-export interface MemoryDocDTO extends MemoryDocSummaryDTO {
-    body: string;
-    frontmatter: Record<string, unknown> | null;
-    representation: 'leaf-file' | 'directory-index';
-    links: string[];
-    findings?: MemoryLintFindingDTO[];
-}
-export interface MemoryLintFindingDTO {
-    severity: string;
-    rule: string;
-    message: string;
-}
-export interface MemoryListQuery extends MemoryScope {
-    kind?: string;
-    limit?: number;
-    after?: string;
-}
-export interface MemoryDocCreateRequest extends MemoryScope {
-    name: string;
-    kind: string;
-    when_and_why_to_read: string;
-    body: string;
-    frontmatter?: Record<string, unknown>;
-    extensions?: Record<string, Record<string, string | boolean | number>>;
-}
-export interface MemoryDocUpdateRequest extends MemoryScope {
-    rationale: string;
-    body?: string;
-    frontmatter?: Record<string, unknown>;
-    extensions?: Record<string, Record<string, string | boolean | number>>;
-    unset?: string[];
-}
-export interface MemoryDocDeletedDTO {
-    name: string;
-    scope: MemoryScopeName;
-    path: string;
-    log_path: string;
-    deleted: true;
-}
-export interface MemoryDocMoveRequest extends MemoryScope {
-    to: string;
-}
-export interface MemoryDocMovedDTO {
-    name: string;
-    previous_name: string;
-    scope: MemoryScopeName;
-    path: string;
-    log_path: string;
-    refs_rewritten: Array<{
-        name: string;
-        scope: MemoryScopeName;
-        path: string;
-        refs: number;
-    }>;
-    follow_up: string;
-}
-export interface MemorySearchRequest extends MemoryScope {
-    query: string;
-    kind?: string;
-    grep?: boolean;
-    body?: boolean;
-    limit?: number;
-    after?: string;
-    min_score?: number;
-}
-export type MemorySearchHitDTO = MemoryRankedSearchHitDTO | MemoryGrepSearchHitDTO;
-export interface MemoryRankedSearchHitDTO {
-    name: string;
-    kind: string;
-    privacy: 'public' | 'friends' | 'private';
-    scope: MemoryScopeName;
-    score: number;
-    short_form: string;
-    path: string;
-    store_root: string;
-    physical_relative_path: string;
-    candidates?: MemoryCandidateDTO[];
-}
-export interface MemoryGrepSearchHitDTO {
-    name: string;
-    privacy: 'public' | 'friends' | 'private';
-    scope: MemoryScopeName;
-    line: number;
-    text: string;
-    path: string;
-    store_root: string;
-    physical_relative_path: string;
-    candidates?: MemoryCandidateDTO[];
-}
-export interface MemoryHistoryQuery extends MemoryScope {
-    limit?: number;
-    revision?: number;
-    diff?: boolean;
-}
-export interface MemoryHistoryRevisionDTO {
-    revision: number;
-    op: 'create' | 'edit' | 'delete' | 'move';
-    at: string;
-    node?: string;
-    rationale?: string;
-    verbatim?: true;
-    body_changed: boolean;
-    frontmatter_changed: string[];
-    diff?: string;
-}
-export interface MemoryHistoryRecordDTO {
-    revision: number;
-    op: 'create' | 'edit' | 'delete' | 'move';
-    at: string;
-    node?: string;
-    cwd: string;
-    from?: string;
-    rationale?: string;
-    verbatim?: boolean;
-    before: string;
-    after: string;
-}
-export interface MemoryHistoryDTO {
-    name: string;
-    scope: MemoryScopeName;
-    log_path: string;
-    total: number;
-    deleted?: unknown;
-    revisions?: MemoryHistoryRevisionDTO[];
-    record?: MemoryHistoryRecordDTO;
-}
-export interface MemoryDocRefDTO {
-    name: string;
-    scope: string;
-    path: string;
-    store_root: string;
-    physical_relative_path: string;
-    plugin?: string;
-}
-export interface MemoryListDTO<T> {
-    object: 'list';
-    data: T[];
-    has_more: boolean;
-}

package/dist/api/dto/memory.js

@@ -1 +0,0 @@
-var r=Object.defineProperty;var o=(e,t)=>r(e,"name",{value:t,configurable:!0});const i=["node","project","profile","user","builtin"];function c(e){return/^[A-Za-z0-9._-]+(?:\/[A-Za-z0-9._-]+)*$/.test(e)}o(c,"isMemoryDocName");export{i as MEMORY_SCOPES,c as isMemoryDocName};

package/dist/builtin-memory/crouter-sdk/guides/app-memory.md

@@ -1,73 +0,0 @@
----
-kind: knowledge
-when-and-why-to-read: When an application's agents need shared durable
-  knowledge, read this because a profile store gives runs one owned memory
-  location and scopes can allow reading without writing.
----
-
-# Application memory
-
-Use this recipe when several runs need the same application guidance. Run `npx tsx examples/guides/app-memory.ts /path/to/repo`; it ensures a profile, creates a profile-owned knowledge document if it does not already exist, then starts a run allowed to read but not write memory.
-
-```ts
-import Crouter, { NotFoundError } from '@north-light/crouter-sdk';
-import { resolve } from 'node:path';
-import { z } from 'zod';
-
-const client = new Crouter();
-const cwd = resolve(process.argv[2] ?? process.cwd());
-const profileName = process.env.APP_PROFILE ?? 'release-notes-app';
-
-const profile = await client.profiles.ensure(profileName, {
-  projects: [{ path: cwd, memory: 'content' }],
-});
-
-try {
-  await client.memory.retrieve('release/voice', { profile: profile.id, store: 'profile' });
-} catch (error) {
-  if (!(error instanceof NotFoundError)) throw error;
-  await client.memory.create({
-    name: 'release/voice',
-    kind: 'knowledge',
-    when_and_why_to_read: 'When writing release notes, read this because it defines the product voice and terms customers recognize.',
-    body: 'Use short factual sentences. Name the user-visible result before implementation details.',
-    frontmatter: { surfaces: ['{"on":"boot","at":"preview"}'] },
-    profile: profile.id,
-    store: 'profile',
-  });
-}
-
-const result = await client.nodes.parse({
-  cwd,
-  model: process.env.GUIDE_MODEL,
-  profile: profile.id,
-  root: true,
-  root_lifecycle: 'terminal',
-  deadline: '5m',
-  scopes: ['memory:read'],
-  prompt: 'Write one short release note announcing that customers can download invoices as CSV from account settings. Do not write or update memory.',
-  output_schema: z.object({ release_note: z.string() }),
-});
-
-if (result.kind === 'result') {
-  console.log(result.output_parsed.release_note);
-} else if (result.reason === 'declined') {
-  console.error(`agent declined: ${result.declined?.reason ?? 'no reason supplied'}`);
-  process.exitCode = 2;
-} else {
-  console.error(`agent failed: ${result.reason}`, result.detail);
-  process.exitCode = 1;
-}
-```
-
-A profile is the application's durable identity: it names the memory store and the projects whose context the profile can reach. The routing line is part of the document, not decoration. State both the moment the agent should read it and the reason it matters; a document with a vague routing line will not surface when the agent needs it.
-
-The `boot`/`preview` surface exposes the document's routing line when this profile's agent starts. The task asks for a release note without naming `release/voice`; in the local run the agent read that document before producing the note. Without a surface entry, a memory document appears only in its directory listing and its routing line cannot select it at boot. The run passes `scopes: ['memory:read']`. That is an allow-list: node-targeted memory reads are allowed and writes are refused because `memory:write` is absent. The application itself is not narrowed by those node scopes, so keep application credentials and its memory mutation policy separate from the agent's capabilities.
-
-Observed against the local daemon with `APP_PROFILE=release-notes-app-guide-boot-preview GUIDE_MODEL=openai-codex/gpt-6-sol:high`:
-
-```text
-You can now download your invoices as a CSV from account settings.
-```
-
-Use profile memory for knowledge shared across the application's related projects. Put facts that belong to one repository in project memory instead, and temporary run notes in node memory. See [[crouter-concepts/memory]] for the ownership tiers and [[crouter-concepts/profiles-kinds-and-modes]] for what a profile changes.