@north-light/crouter 0.3.352 → 0.3.354

package/dist/builtin-memory/insights/init.md

@@ -1,14 +1,14 @@
 ---
 kind: knowledge
 when-and-why-to-read: When the user invokes /insights:init to begin gathering user-derived insight about a domain, this knowledge should be read because a correctly scoped listener preserves uniquely valuable knowledge without creating a parallel store or background system.
-short-form: Initialize passive insight gathering for a domain at the narrowest durable scope; create one routed topic index that reviews user-derived principles before saving them.
+short-form: Initialize passive insight gathering for a domain at the narrowest durable owner; create one routed topic index that reviews user-derived principles before saving them.
 slash: true
 rationale: Ordinary conversations, corrections, answers to `crtr human send`, and review comments carry unique user knowledge that agents inconsistently recognize or save; when agents do infer a deeper principle, they have written it without first letting the user correct the extrapolation.
 ---
 
 # /insights:init — begin domain listening
 
-Initialize an ordinary memory directory that listens for user-derived insight about this domain.
+Initialize an ordinary document that listens for user-derived insight about this domain.
 
 **Requested domain and mode:** $ARGUMENTS
 
@@ -16,35 +16,35 @@ Initialize an ordinary memory directory that listens for user-derived insight ab
 
 If `$ARGUMENTS` contains `--active`, follow the **active mode** steps below. Otherwise, follow the **passive mode** steps.
 
-## Establish the topic and scope
+## Establish the topic and owner
 
 Turn the request into a short path-safe topic slug and a compact domain boundary that preserves the user's meaning rather than reducing it to a single keyword. If the request is empty or too vague to distinguish relevant from unrelated information, ask one focused question through `crtr human send`.
 
-Choose the narrowest durable scope that reaches every future conversation where this domain matters:
+Choose the narrowest durable owner that reaches every future conversation where this domain matters:
 
 - project when the insight is meaningful only inside one project;
 - profile when it spans the selected profile's projects but should not follow the user elsewhere; or
 - user when it concerns the person, a market, a craft, or a domain that crosses workspaces.
 
-Infer the scope from the request and current workspace. Ask through `crtr human send` only when more than one scope is genuinely plausible, and settle scope before writing anything. Never use node scope for an ongoing listener.
+Infer the owner from the request and current workspace. Ask through `crtr human send` only when more than one owner is genuinely plausible, and settle the owner before writing anything. Never make a node the owner of an ongoing listener.
 
-Search the chosen scope before creating. Use `<namespace>/insights/<topic>` for project scope and `insights/<topic>` for profile or user scope; if that canonical address already represents the same domain, refine that listener rather than creating an overlapping directory.
+Search the chosen owner before creating. Use `insights/<topic>` under the chosen owner (`--owner repo`, `--owner profile` or `--owner user`); if that name already represents the same domain, refine that listener rather than creating an overlapping one.
 
 ## Create the listener
 
-Run `crtr memory write -h`, then create the directory document at the chosen scope under its canonical address: `<namespace>/insights/<topic>` for project scope and `insights/<topic>` for profile or user scope, as a preference surfaced `{on: boot, at: preview}`. Its physical front door remains `insights/<topic>/INDEX.md`.
+Run `crtr doc write -h`, then create the listener document under the chosen owner, named `insights/<topic>`, as a preference with the rule `on: boot`, `deliver: preview` (`--rule`, see `crtr doc write --rule -h`).
 
-Its routing line must name the actual domain trigger: when user-supplied information, a correction, or a user response relates to this domain, read the preference because recognizing the underlying principle preserves knowledge future decisions can use.
+Its preview must name the actual domain trigger: when user-supplied information, a correction, or a user response relates to this domain, read the preference because recognizing the underlying principle preserves knowledge future decisions can use.
 
 Keep the body short. It contains:
 
 - the domain boundary, including exclusions needed to prevent false triggers;
 - a directive to follow [[insights/capture]] whenever a source episode may reveal a reusable principle; and
-- an `Approved insights` section containing document links to principle memories as they are approved.
+- an `Approved insights` section containing links to the principle documents as they are approved.
 
 Do not copy the capture workflow into the listener. The link keeps that process in one maintained place. Do not create placeholder principle documents.
 
-Run `crtr memory lint`, fix every finding, then report the canonical listener name, selected scope, and the domain boundary. Initialization is complete once the routed listener exists; no independent work follows.
+Run `crtr doc lint`, fix every finding, then report the canonical listener name, selected owner, and the domain boundary. Initialization is complete once the routed listener exists; no independent work follows.
 
 ## Active mode: research and surface claims
 
@@ -52,7 +52,7 @@ When `--active` is present, do not stop after creating the listener. After initi
 
 ### 1. Create the listener first
 
-Follow the passive mode steps above through "Initialization is complete." The listener directory document must exist before spawning the explorer.
+Follow the passive mode steps above through "Initialization is complete." The listener document must exist before spawning the explorer.
 
 ### 2. Spawn the explorer child
 
@@ -68,7 +68,7 @@ Gather evidence from code, docs, existing understanding, and project artifacts.
 **Evidence:** [why you believe this]
 **Question:** [what would prove or disprove this?]
 
-Repeat for each claim. Write findings to $CRTR_CONTEXT_DIR/claims.md and report the absolute path.
+Repeat for each claim. Write findings as the document `claims` with `crtr doc write`, and point at it in your report as `[[<node-id>/claims]]`.
 TASK
 ```
 
@@ -81,8 +81,8 @@ When the explorer reports, share its claims with the user. For each claim, ask:
 - Is it incomplete or wrong?
 - What's the actual principle?
 
-For each user response, use [[insights/capture]] to extract and review the insight. Apply approved insights directly to the listener directory document's `Approved insights` section.
+For each user response, use [[insights/capture]] to extract and review the insight. Apply approved insights directly to the listener document's `Approved insights` section.
 
 ### 4. Report completion
 
-Once claims have been surfaced and user guidance has generated approved insights, report that active initialization is complete. The listener directory document now passively captures this domain as new user material emerges.
+Once claims have been surfaced and user guidance has generated approved insights, report that active initialization is complete. The listener document now passively captures this domain as new user material emerges.

package/dist/builtin-memory/internal/INDEX.md

@@ -15,14 +15,14 @@ Open this dir whenever a task turns on understanding the runtime itself or chang
 
 - **nodes-and-canvas** — the agent-runtime model: nodes on the canvas graph, spawn/delegate, the push/feed spine, lifecycle (mode + lifecycle axes), and revive (manual + daemon auto-revive).
 - **storage-tiers** — where every kind of state lives: the two tiers (scope root and canvas home) and their durability/ownership contracts.
-- **memory-loading** — the memory load model: the five surface events, the rung ladder, gates, listings, boot-render ordering, and store mounting/precedence — read when diagnosing why a doc did or didn't load.
-- **agent-shaping** — the when-to-use-which layer over the four dials that shape a node: kinds (the builtin roster, sub-kinds, and custom personas), modes (base vs orchestrator), profiles, and the memory tiers (node/profile/project/user/builtin).
+- **memory-loading** — how documents load: the delivery events, `deliver` levels, `if` conditions, listings, boot-render ordering, and the reader's view — read when diagnosing why a document did or didn't load.
+- **agent-shaping** — the when-to-use-which layer over the four dials that shape a node: kinds (the builtin roster, sub-kinds, and custom personas), modes (base vs orchestrator), profiles, and document owners (node/profile/repo/user).
 - **plugins** — authoring a crtr plugin: the plugin.json manifest, directory layout, scopes, install mechanics, versioning, command-capable plugins (contributing top-level CLI commands through commands.json plus an exec or HTTP transport), and bare binaries a plugin or scope puts on every node's PATH.
 - **marketplaces** — authoring a crtr marketplace: the marketplace.json index, local-link and remote-Git plugin sources, auto-bump CI, dual-publishing.
 - **examples/** — worked compositions of the primitives into complete systems (the analogue of pi's `examples/` dir), e.g. the iMessage assistant node.
 
-Adjacent, outside this dir: authoring memory documents (kind, surfaces routing, gates, routing line, the asked-to-remember workflow) is owned by `crtr memory write -h` — the authoring guide lives on that `-h` surface so it surfaces exactly when you write.
+Adjacent, outside this dir: writing documents (kind, delivery rules, preview, the asked-to-remember workflow) is owned by `crtr doc write -h` and its focused `--owner -h`/`--rule -h` — the guide lives on that `-h` surface so it is delivered exactly when you write.
 
 Briefly: **plugins** package docs and commands, with command execution selected by `plugin.json.transport` (`exec` for a trusted local executable or `http` for a fetched remote REST manifest); **marketplaces** index and distribute plugins. Plugin commands enter the **external-command** fallthrough, leaving the core fast-path untouched.
 
-The individual files surface at their canonical names (open the one the situation calls for); this directory document surfaces at `internal` at `preview`, and `crtr memory read internal` returns its body followed by the directory's immediate listing.
+The individual files surface at their canonical names (open the one the situation calls for); this document is delivered at `preview` under the name `internal`, and `crtr canvas read internal` returns its body followed by the names under it.

package/dist/builtin-memory/internal/agent-shaping.md

@@ -1,23 +1,23 @@
 ---
 kind: knowledge
-when-and-why-to-read: When you are choosing how to shape a node — which kind to spawn, base vs orchestrator, which profile, or which memory scope a doc belongs in — this reference should be read so each task gets the right role, orchestration depth, identity, and guidance reach instead of paying for a mismatched agent shape.
-short-form: The four orthogonal dials that shape a node — kind (role + model tier), mode (base vs orchestrator), profile (identity + purview), and memory tier (who sees a doc) — plus when to reach for each over its alternatives.
-rationale: Agents pick shaping dials by reflex from the one-line `-h` blurbs and get the discriminators wrong — delegating debugging to explore instead of advisor, grinding an orchestrator-shaped job in base, minting a duplicate memory doc at the wrong scope. The per-kind base docs carry the rationale but only the running node of that kind ever sees them; nothing gave a chooser the cross-cutting "which one, and why it's built this way" view before committing.
+when-and-why-to-read: When you are choosing how to shape a node — which kind to spawn, base vs orchestrator, which profile, or which owner a document belongs to — this reference should be read so each task gets the right role, orchestration depth, identity, and guidance reach instead of paying for a mismatched agent shape.
+short-form: The four orthogonal dials that shape a node — kind (role + model tier), mode (base vs orchestrator), profile (identity + purview), and document owner (who sees a document) — plus when to reach for each over its alternatives.
+rationale: Agents pick shaping dials by reflex from the one-line `-h` blurbs and get the discriminators wrong — delegating debugging to explore instead of advisor, grinding an orchestrator-shaped job in base, minting a duplicate document under the wrong owner. The per-kind base docs carry the rationale but only the running node of that kind ever sees them; nothing gave a chooser the cross-cutting "which one, and why it's built this way" view before committing.
 surfaces:
   - on: boot
     at: name
 ---
 
-# Agent shaping — kinds, modes, profiles, and memory tiers
+# Agent shaping — kinds, modes, profiles, and document owners
 
-Four orthogonal dials shape every node. This is the **when-to-use-which** layer over them — the philosophy of each and how to choose between alternatives. It does not cover mechanics: the node/canvas/lifecycle model is `internal/nodes-and-canvas`, the physical disk layout of every store is `internal/storage-tiers`, and the authoring/routing contract for memory docs is `crtr memory write -h`. Point at those; this doc decides which dial to turn.
+Four orthogonal dials shape every node. This is the **when-to-use-which** layer over them — the philosophy of each and how to choose between alternatives. It does not cover mechanics: the node/canvas/lifecycle model is `internal/nodes-and-canvas`, where state lives is `internal/storage-tiers`, and the writing and delivery-rule contract for documents is `crtr doc write -h`. Point at those; this doc decides which dial to turn.
 
 The dials are independent — you set each without constraining the others:
 
 - **kind** — the node's role and expertise (`explore`, `developer`, a custom persona). Carries a model tier and a tool set.
 - **mode** — `base` (do it yourself; yield hands-on when an unsplittable task needs another window) vs `orchestrator` (delegate and hold a roadmap across cycles).
-- **profile** — the node's identity: which project dirs it can see and which memory/config store it resolves against.
-- **memory tier** — where a shared doc lives, which decides who ever reads it.
+- **profile** — the node's identity: which project dirs it can see and which documents and config it resolves against.
+- **document owner** — who owns a shared document, which decides who ever reads it.
 
 A fifth axis, **lifecycle** (`terminal` vs `resident`), is orthogonal too but belongs to the runtime model — see `internal/nodes-and-canvas`. Terminal owes a final up the spine and reaps; resident stays interactable and is never forced to submit. Orchestrating never earns residency on its own.
 
@@ -54,25 +54,25 @@ The roster is extensible. Add a `kinds.<name>` entry to a `config.json` at user
 
 Every kind has both a `base` and an `orchestrator` persona; mode picks which one splices in.
 
-- **base** — hands-on. Do the work yourself and deliver its artifact path. Your scarce resource is the task. Spawn a child only for a cleanly separable unit, never as your first move. When an unsplittable task needs another context window, `crtr node yield` and continue hands-on as base.
-- **orchestrator** — you own a goal with enough independent parallel work that coordination is now your primary job. Decompose it, delegate each piece, integrate what comes back, hold a `$CRTR_CONTEXT_DIR/roadmap.md` that survives refreshes, and yield (`crtr node yield`) into a clean window when context fills. Your scarce resource is your own context window; the moment you start grinding the whole goal out by hand you've lost the plot. The shared loop lives in the `orchestration-kernel` doc (auto-gated for orchestrators).
+- **base** — hands-on. Do the work yourself and deliver its artifact. Your scarce resource is the task. Spawn a child only for a cleanly separable unit, never as your first move. When an unsplittable task needs another context window, `crtr node yield` and continue hands-on as base.
+- **orchestrator** — you own a goal with enough independent parallel work that coordination is now your primary job. Decompose it, delegate each piece, integrate what comes back, hold its document `roadmap`, which loads at every new session, and yield (`crtr node yield`) into a clean window when context fills. Your scarce resource is your own context window; the moment you start grinding the whole goal out by hand you've lost the plot. The shared loop lives in the `orchestration-kernel` doc (auto-gated for orchestrators).
 
 **When to reach for orchestrator over base.** Both conditions must hold: the remaining work contains genuinely independent units that can proceed in parallel, and the task is large or valuable enough that parallel execution will materially improve intelligence, productivity, or elapsed throughput after delegation and synthesis costs. Promote early (`crtr node promote`) once coordination and integration should replace hands-on execution as your primary job; a base node that merely spawns one helper stays base. Task duration, phase count, context exhaustion, and sequential or tightly coupled work do not qualify — yield and continue hands-on instead. Create a bounded child directly as a sub-orchestrator (`crtr node new --mode orchestrator`) only when its own assignment passes the same test.
 
-## Profiles — identity, purview, and a memory store
+## Profiles — identity, purview, and its own documents
 
-A profile is a stable **agent identity**: a fixed id, a display name, its own memory store, and a **purview** of project directories it resolves memory and config from. Select it at spawn with `crtr node new --profile <id-or-name>`; omit and a child inherits the caller's profile. Pin a directory's default profile with `crtr profile default` so the startup chooser stops asking. Manage the identity and purview with `crtr profile new/show/project/rename/delete` (see `crtr profile -h`).
+A profile is a stable **agent identity**: a fixed id, a display name, its own documents, and a **purview** of project directories it resolves documents and config from. Select it at spawn with `crtr node new --profile <id-or-name>`; omit and a child inherits the caller's profile. Pin a directory's default profile with `crtr profile default` so the startup chooser stops asking. Manage the identity and purview with `crtr profile new/show/project/rename/delete` (see `crtr profile -h`).
 
-Each project in the purview carries its own `memory` value, capping how much of that project's stores reach a node's automatic boot and workspace-open context from any directory that node works in. Give `content` to the repos whose front doors the profile's nodes should operate inside, `preview` or `name` to a project the profile must know exists but rarely enters, and `none` to purview held for config, plugins, and deliberate reads alone. It is a delivery dial, not an access one: `crtr memory read` and file- and command-routed docs still see those stores whole.
+Each project in the purview carries the profile's delivery limit per owner (today set per project), capping how much of that repo's documents reach a node's automatic boot and workspace-open context from any directory that node works in. Give `content` to the repos whose front doors the profile's nodes should operate inside, `preview` or `name` to a project the profile must know exists but rarely enters, and `none` to purview held for config, plugins, and deliberate reads alone. It is a delivery dial, not an access one: `crtr canvas read` and `file-read`/`command` rules still reach those documents.
 
-Reach for a **new** profile when a distinct body of work has its own set of directories and its own conventions worth a dedicated store — not for every repo. The **profile memory scope** is exactly where cross-repo conventions and your stance toward that body of work belong (see the memory tiers below); a profile spanning several related dirs lets one doc reach every node working anywhere in that bundle.
+Reach for a **new** profile when a distinct body of work has its own set of directories and its own conventions worth dedicated documents — not for every repo. **The profile as owner** is exactly where cross-repo conventions and your stance toward that body of work belong (see the owners below); a profile spanning several related dirs lets one document reach every node working anywhere in that bundle.
 
-## Memory tiers — where a doc lives decides who sees it
+## Owners — who owns a document decides who sees it
 
-A memory doc's **scope** is a reach dial: the wider the scope, the more agents pay to carry it, forever. Choose the **narrowest scope that still reaches the next agent who needs it**. Physical paths and durability contracts are in `internal/storage-tiers`; the frontmatter/routing contract is `crtr memory write -h`. The scopes, narrowest reach to widest:
+A document's **owner** is a reach dial: the wider the owner, the more agents pay to carry it, forever. Choose the **narrowest owner that still reaches the next agent who needs it**. Where state lives is in `internal/storage-tiers`; the field and delivery-rule contract is `crtr doc write -h`. The owners, narrowest reach to widest:
 
-- **node** (`nodes/<id>/context/memory/`) — only *this* running node sees it; rides its boot context and dies with the node. Scratch memory for one goal's cross-refresh state.
-- **profile** (the profile's own store) — every node running under that profile, across all the dirs in its purview. Cross-repo conventions and the user's stance toward that bundle of work.
-- **project** (`<project>/.crouter/memory/`) — any agent operating in that one repo. Facts and procedures tied to that codebase. Resolves to the nearest ancestor `.crouter/` walking up from cwd, plus every project in the selected profile's purview; `--dir` pins an exact repo.
-- **user** (`~/.crouter/memory/`) — person-wide facts and preferences that follow the user everywhere, regardless of repo or profile.
-- **builtin** (`src/builtin-memory/` in the crouter repo) — ships inside crtr, so *every crtr user on every host* carries it. This tier is the runtime's own self-documentation (this doc lives here); a change here is a change to the product. Author here only for guidance every crouter user needs, never for anything person- or repo-specific.
+- **node** — the default owner of what a node writes. Only this node's view includes it; it is deleted with the node unless a kept document links to it. One goal's cross-refresh state.
+- **profile** (`--owner profile`) — every node running under that profile, across all the dirs in its purview. Cross-repo conventions and the user's stance toward that bundle of work.
+- **repo** (`--owner repo`) — any agent operating in that one repo. Facts and procedures tied to that codebase. Every clone and worktree shares one set, synced over the repo's git ref `refs/crtr/docs`; a repo owns only public documents.
+- **user** (`--owner user`) — person-wide facts and preferences that follow the user everywhere, regardless of repo or profile.
+- **crtr's own documents** (plugin `crtr`, files in `src/builtin-memory/` of the crouter repo) — ships inside crtr, so *every crtr user on every host* carries it. This owner holds the runtime's own self-documentation (this document lives here); a change here is a change to the product. Write here only for guidance every crouter user needs, never for anything person- or repo-specific.

package/dist/builtin-memory/internal/examples/imessage-assistant.md

@@ -20,7 +20,7 @@ A standing assistant that lives on the canvas, sleeps for free, wakes when a tex
 | Hears incoming texts | launchd watcher on `chat.db-wal` → `crtr node message send <body> --to <id>` (event-driven; the message delivers and revives, the node never polls) |
 | Reads messages | sqlite against `~/Library/Messages/chat.db`, cursored by ROWID |
 | Sends replies | `osascript` → Messages.app |
-| Memory | Project-scope substrate (`~/assistants/imessage/.crouter/memory/`) for durable knowledge; context dir for the cursor |
+| Memory | Documents the assistant's repo owns (`--owner repo`) for durable knowledge; context dir for the cursor |
 | Identity/behavior | A custom persona kind |
 | Crash recovery | The daemon makes bounded recovery attempts for interrupted live exits; after terminalization, use `node lifecycle revive` or let the watcher's `node message send` wake the resident target |
 
@@ -90,7 +90,7 @@ Group chats target the chat instead: `send "..." to chat id "iMessage;+;chat123.
 
 Two tiers, matching [[internal/storage-tiers]]:
 
-- **Durable knowledge** → project-scope memory in the node's pinned dir (`~/assistants/imessage/.crouter/memory/`): one reference per contact/thread (who they are, open loops, tone), loaded by the substrate on the node's own boots. The persona instructs when to write/update these.
+- **Durable knowledge** → documents owned by the node's repo (`crtr doc write --owner repo`): one per contact/thread (who they are, open loops, tone), delivered by rules on the node's boots. The persona says when to write or update them with `crtr doc write`/`crtr doc edit`.
 - **Working state** → the node's context dir: the ROWID cursor, drafts, a running log.
 
 ## The wake loop (persona-side)

package/dist/builtin-memory/internal/marketplaces.md

@@ -108,7 +108,7 @@ cd <marketplace-repo>
 mkdir -p plugins/my-new-plugin/.crouter-plugin plugins/my-new-plugin/memory
 $EDITOR plugins/my-new-plugin/.crouter-plugin/plugin.json
 
-# Add at least one doc (`crtr memory write -h` is the authoring + routing guide)
+# Add at least one doc (`crtr doc write -h` is the field + delivery-rule guide)
 $EDITOR plugins/my-new-plugin/memory/first-doc.md
 
 # Add the plugin to the marketplace index
@@ -117,7 +117,7 @@ $EDITOR .crouter-marketplace/marketplace.json
 
 # Validate
 crtr sys doctor                                    # manifest + structure
-crtr memory lint                                   # doc frontmatter
+crtr doc lint                                      # document fields and links
 
 # Commit — CI bumps versions if you've wired up auto-bump
 git add -A

package/dist/builtin-memory/internal/memory-loading.md

@@ -1,63 +1,64 @@
 ---
 kind: knowledge
-when-and-why-to-read: When you need to know why a memory doc did or didn't load — or are deciding how a new doc should surface — this reference should be read because it names the event, rung, gate, and ordering that produced the behavior, so you fix loading by turning the right dial instead of guessing at frontmatter.
-short-form: The complete load model — the five surface events, the rung ladder, gates, listings, context exposure, boot-render ordering, and store mounting/precedence.
+when-and-why-to-read: When you need to know why a document did or didn't load — or are deciding how a new document should be delivered — this reference should be read because it names the event, delivery level, `if` condition, and ordering that produced the behavior, so you fix loading by turning the right dial instead of guessing at fields.
+short-form: How documents load — the delivery events, `deliver` levels, `if` conditions, listings, the exposure ledger, boot-render ordering, and the reader's view.
 surfaces:
   - on: boot
     at: name
 ---
 
-# How memory loads
+# How documents load
 
-Every memory doc declares its own delivery in frontmatter `surfaces` entries; the runtime never guesses. Delivery is six events, one rung per entry, document and entry gates, and structural ordering. The authoring contract (flags, routing-line craft) is `crtr memory write -h`; which scope to write to is `internal/agent-shaping`; physical paths are `internal/storage-tiers`. This doc is the mechanics between those: what actually fires, when, and in what order.
+Every document declares its own delivery in its `delivery` rules; the runtime never guesses. Delivery is seven `on` values, one `deliver` level per rule, one `if` per rule, and structural ordering. The writing contract (flags, preview craft) is `crtr doc write -h` and its focused `crtr doc write --rule -h`; which owner to write under is `internal/agent-shaping`; where state lives is `internal/storage-tiers`. This document is the mechanics between those: what actually fires, when, and in what order.
 
-## Surfaces entries
+## Delivery rules
 
-A doc with no `surfaces` does exactly one thing: appears in its directory's listing. Everything beyond that is an explicit entry — `{on: <event>, match?, match-frontmatter?, gate?, at: <rung>}`. An entry's event constraints and optional node-config `gate` must both match; participating entries OR across and fold to their highest rung (`content` > `preview` > `name`), with no cross-entry deny precedence. Multiple entries per event are legal. The events:
+A document with no delivery rules does exactly one thing: appears in the listing of the names above it. Everything beyond that is an explicit rule — `{on: <event>, match?, match-frontmatter?, if?, deliver: <level>}`. A rule's event constraints and optional `if` over the receiving node must both match; matching rules OR across and fold to their highest delivery (`content` > `preview` > `name`), with no cross-rule deny precedence. Multiple rules per event are legal. The events:
 
-- **boot** — the frozen preference system snapshot and first-message knowledge catalog assembled when a context begins. No match; the entry's presence is the match.
-- **workspace-open** — first-message context when cwd/profile mounts the doc's project store. Project stores only.
-- **read** — a `read` tool call returned a matching file: path globs vs the file's absolute path and basename, `./`-anchored globs vs its path relative to the store's owning repo dir, `match-frontmatter` predicates over the read file's own YAML frontmatter.
-- **memory-read** — another doc's full body entered context, including `crtr memory read`: name globs vs its canonical name, `./` anchored to this doc's canonical routing anchor (a collapsed directory document anchors at its own directory name).
+- **boot** — the frozen preference system snapshot and first-message knowledge catalog assembled when a context begins. No match; the rule's presence is the match.
+- **workspace-open** — first-message context when the node works in the repo that owns the document. Repo-owned documents only.
+- **file-read** — a `read` tool call returned a matching file: path globs vs the file's absolute path and basename, `./`-anchored globs vs its path relative to the owning repo's checkout, `match-frontmatter` predicates over the read file's own YAML frontmatter.
+- **document-read** — another document's full body entered context, including `crtr canvas read`: name globs vs its name, `./` anchored to this document's own name.
 - **command** — a matching shell command ran: globs vs the whole command string, `*` crossing `/`. Delivery is post-execution — right for "you are now in this territory"; when the point is "don't run this at all," use `pre-command` instead.
-- **pre-command** — a matching `bash` command is about to run. When the memory has not been read yet, the command does not execute — the memory comes back as the tool result instead, and the agent re-issues the command, which then runs. Use it to guarantee a memory is seen before a sensitive action is taken. Same globs as `command`, matched at command position; `match` is required. A guardrail against the faithful-but-uninformed action, not an enforcement boundary.
+- **pre-command** — a matching `bash` command is about to run. When the document has not been read yet, the command does not execute — the document comes back as the tool result instead, and the agent re-issues the command, which then runs. Use it to guarantee a document is seen before a sensitive action is taken. Same globs as `command`, matched at command position; `match` is required. A guardrail against the faithful-but-uninformed action, not an enforcement boundary.
+- **slash-command** — the document is offered as a slash command in the viewer; invoking it delivers its content.
 
-Nothing positional fires from where a doc happens to sit on disk — only from its declared entries and its listing.
+Nothing positional fires from where a document's name sits — only from its declared rules and its listing.
 
-## The rung ladder
+## Delivery levels
 
-`at` sets how much delivers when an entry fires:
+`deliver` sets how much delivers when a rule fires:
 
-- `name` — the bare title. The practical boot floor: an agent can't reach for a doc it has never seen named.
-- `preview` — name + the `when-and-why-to-read` routing line, rendered verbatim. The heart of progressive disclosure: one sentence that lets an agent decide whether to spend the read.
-- `content` — the full body inlined. Reserved for always-relevant docs that are either a bullet's worth of text or a wholly-important operating guide (the workspace front door below).
+- `name` — the bare title. The practical boot floor: an agent can't reach for a document it has never seen named.
+- `preview` — name + the `preview` line, rendered verbatim. The heart of progressive disclosure: one sentence that lets an agent decide whether to spend the read.
+- `content` — the full body inlined. Reserved for always-relevant documents that are either a bullet's worth of text or a wholly-important operating guide (the workspace front door below).
 
-Silence is the absence of an entry; there is no `none` rung. `short-form` is **not** a rung and never enters agent context — it exists for the user browsing `crtr memory list`. Disclosure is name → routing line → whole thing; there is deliberately no "just the summary" level, because agents satisfice on abbreviations and never read the rest.
+Silence is the absence of a rule; there is no `none` level. `summary` is **not** a level and never enters agent context — it exists for listings and search results. Disclosure is name → preview → whole thing; there is deliberately no "just the summary" level, because agents satisfice on abbreviations and never read the rest.
 
-## Gates
+## Conditions
 
-A document-level `gate` is the hard eligibility predicate over the node's own config — kind, mode, orchestration depth, scope, cwd — using the standard matcher vocabulary (`crtr memory write -h`). When it fails, no automatic surface delivers the document. An optional `gate` on an individual surface entry applies the same predicate language only to that entry, so one document can choose a different rung by node kind. No gate means always eligible. Persona prose is just gated boot-content docs (`gate: {kind: developer, mode: base}`); guidance that should scale with effort is one predicate (`orchestration.depth: {gte: 2}`), not a mechanism.
+A rule's `if` is the eligibility predicate over the receiving node — kind, mode, lifecycle, orchestration depth, cwd, the repo it works in, profile — using the standard matcher vocabulary (`crtr doc write --rule -h`). When it fails, that rule delivers nothing; there is no document-level condition, so one document can choose a different level by node kind with two rules. No `if` means always eligible. Persona prose is just boot-content documents with an `if` (`if: {kind: developer, mode: base}`); guidance that should scale with effort is one predicate (`orchestration.depth: {gte: 2}`), not a mechanism.
 
 ## Listings and dedup
 
-A full-body delivery is a read: `crtr memory read <doc>` and every content-rung surface delivery expose, once per loaded context, the listing of the doc's directory and each ancestor — one routing line per member doc, one bare name per subdirectory — then fire matching `memory-read` routes. A directory document owns its canonical directory node, so its content delivery exposes its immediate members; `crtr memory read <dir>` returns that document's body followed by the directory's immediate listing without repeating the document, while a directory without a document returns its listing. Content-delivered companions are read in turn until the finite corpus reaches the ledger-deduplicated fixpoint. `unlisted: true` suppresses a doc from every listing. Store roots are never auto-listed — `crtr memory list` is the deliberate root browse.
+A full-body delivery is a read: `crtr canvas read <name>` and every content delivery expose, once per loaded context, the listing of each prefix of the document's name — one preview per document, one bare name per prefix that has names under it — then fire matching `document-read` rules. A document named `x` and documents named `x/…` coexist; reading `x` returns its body and the names under it. Content-delivered companions are read in turn until nothing new is delivered. `unlisted: true` suppresses a document from every listing. An owner's top level is never auto-listed — `crtr canvas list --type document` is the deliberate browse. Every content delivery, like every read, records a watch, so later edits reach the reader as pushes.
 
-Every delivery registers its document or listing identity and rung in the loaded context's exposure ledger. System and transcript ranks max-fold, so a higher rung pierces a lower one while a content delivery silences later lower-rung deliveries and duplicate read attachments. A strict resume preserves that ledger and the byte-stable preference snapshot; yield or another new-context boundary replaces them with exactly the new system and first-message snapshots.
+Every delivery registers the document or listing and its level in the loaded context's exposure ledger, kept in canvas.db. System and transcript ranks max-fold, so a higher level pierces a lower one while a content delivery silences later lower-level deliveries and duplicate read attachments. A strict resume preserves that ledger and the byte-stable preference snapshot; yield or another new-session boundary clears it and replaces them with exactly the new system and first-message snapshots.
 
-## Store mounting and precedence
+## The reader's view
 
-At boot/first-message assembly the runtime mounts: builtin docs, the user store (`~/.crouter/memory/`), the selected profile's store, and every project store — ancestor `.crouter/memory/` dirs walking up from cwd plus each project in the profile's purview. Physical duplicates are deduplicated; name collisions resolve nearest-first (project over profile over user over builtin), which is what lets a project doc shadow a builtin one.
+A rule applies to every node whose view includes the document's owner. A node's view is: its own node, the repos it works in (nearest first), its profile, its app, the user, and installed plugins, with crtr's own documents (plugin `crtr`) last. A bare name resolves in that same order, which is what lets a repo's document shadow one of crtr's own. A node's own documents are in no other node's view, so their rules apply only to that node.
 
-Each project the selected profile has a relationship with carries a `memory` value — `none`, `name`, `preview`, or `content` — and that value is the maximum rung anything in that project's stores delivers at boot and workspace-open, whatever directory the node is working in. It only lowers: an entry authored below the maximum delivers at its authored rung. `none` contributes nothing to either automatic event, so a `none` project cannot shadow a same-named doc from a wider scope — that wider doc becomes the winner. A project store the selected profile has no relationship with delivers exactly what it authored.
+Each owner the selected profile manages carries a delivery limit — `none`, `name`, `preview`, or `content` — and that value is the maximum level anything that owner holds delivers at `boot` and `workspace-open`, whatever directory the node is working in. It only lowers: a rule authored below the maximum delivers at its authored level. `none` contributes nothing to either automatic event, so a `none` owner cannot shadow a same-named document from a wider owner — that wider document becomes the winner. An owner with no limit set delivers exactly what it authored.
 
-The maximum reaches those two events and nothing else. Read, memory-read, command, and pre-command entries fire at their authored rungs; directory listings, `crtr memory read`, `crtr memory find`, config resolution, and plugin discovery all see the full corpus. An explicit `crtr memory read` is itself a content delivery, so reading a capped or document-gated doc returns its whole body and records content — the upgrade path for a doc the automatic events disclosed only by name or preview. Entry gates apply to companion docs routed by the `memory-read` event, not to the deliberate read or its listings.
+The limit reaches those two events and nothing else. `file-read`, `document-read`, `command`, and `pre-command` rules fire at their authored levels; listings, `crtr canvas read`, `crtr canvas search`, config resolution, and plugin discovery all see every document the reader may read. An explicit `crtr canvas read` is itself a content delivery, so reading a capped document returns its whole body and records content — the upgrade path for a document the automatic events disclosed only by name or preview. `if` conditions apply to companion documents delivered by the `document-read` event, not to the deliberate read or its listings.
 
-A workspace's front door is an ordinary doc carrying the entry pair `{on: workspace-open, at: content}` + `{on: read, match: "./**", at: content}` — the operating guide loads when that workspace mounts or its files are read, not in every boot catalog. `crtr memory lint` requires exactly one workspace-open content doc per profile-managed project store. Multiple mounted roots render broad-to-specific.
+A workspace's front door is an ordinary repo-owned document carrying the rule pair `{on: workspace-open, deliver: content}` + `{on: file-read, match: "./**", deliver: content}` — the operating guide loads when a node works in that repo or reads its files, not in every boot catalog. `crtr doc lint` requires exactly one `workspace-open` content document per repo the profile manages. Several repos render broad-to-specific.
 
-A `.crouter/memory/` store nested BELOW a mounted root (a package or subsystem dir) is delivered by the read path, not by boot: reading any file beneath its owning dir surfaces its read-routed docs, filtered against what the loaded context already contains. Addressability is separate — the `crtr memory` leaves (list/read/find/lint/delete/origin) discover nested stores through a bounded walk (git-aware, depth- and time-capped), while the boot catalog stays ancestor+profile only, which is why a nested doc's boot entries are inert (lint warns; drop them).
+A repo's documents about one package or subsystem are named under its folder (for example `packages/api/…`) and keep their `file-read` rules: reading any file beneath that folder delivers them, filtered against what the loaded context already contains.
 
 ## Ordering
 
-The boot render is structural, never a per-doc knob: docs group by boot rung (content bodies as prose, then previews, then names), and within a group order general-to-specific — scope first (builtin → user → profile → outermost project root → nearest), then tree position (higher directories before deeper), then filename. A numeric `NN-` filename prefix (stripped from the doc's name) is the sparing escape hatch when an exact sequence must be pinned.
+The boot render is structural, never a per-document knob: documents group by boot level (content bodies as prose, then previews, then names), and within a group order general-to-specific — owner first (crtr → user → profile → outermost repo → nearest), then name depth (shorter names before deeper ones), then name. A numeric `NN-` prefix (stripped from the document's name) is the sparing escape hatch when an exact sequence must be pinned.
 
-`crtr memory lint` is the validator for all of the above: frontmatter schema, strict `surfaces` entries, rung-scaled body length, dangling `[[links]]`, and each profile-managed project's front door.
+`crtr doc lint` is the validator for the rest: body length for its delivery, the preview's shape when a rule delivers it at `preview`, links to nothing, and one `workspace-open` content document per repo the profile manages.

package/dist/builtin-memory/internal/nodes-and-canvas.md

@@ -9,7 +9,7 @@ surfaces:
 
 # How nodes and the canvas work (operational)
 
-Every agent is a **node** in one directed graph (the **canvas**). Each node has a canvas row, its own context dir, and one detached headless broker engine; tmux panes are only viewer surfaces that attach to a broker. The graph's edges are `subscribes_to` — the **spine** — and they decide who-wakes-whom.
+Every agent is a **node** in one directed graph (the **canvas**). Each node has a canvas row, its own documents and context dir, and one detached headless broker engine; tmux panes are only viewer surfaces that attach to a broker. The graph's edges are `subscribes_to` — the **spine** — and they decide who-wakes-whom.
 
 The **daemon** (`crtrd`) is the sole owner of canvas persistent state: it is the only process that opens `canvas.db`, launches brokers, and writes runtime/model-auth, all behind an HTTP+WS API on a unix socket (dockerd model). Every `crtr` command and viewer is a pure client of that `/v1` API — they never open the store. A local interactive viewer still streams a node's broker socket (`view.sock`) directly, because that is broker IPC, not canvas state.
 

package/dist/builtin-memory/internal/plugins.md

@@ -13,12 +13,14 @@ A **plugin** is a directory shipping substrate docs (knowledge and preferences)
 
 Audience: LLM agents creating or maintaining a crtr plugin.
 
-## When you need a plugin (vs scope-owned memory docs)
+## When you need a plugin (vs documents a person or repo owns)
 
-Scope-owned docs live at `~/.crouter/memory/` (user) or `<project>/.crouter/memory/` (project). They're personal and per-machine/per-repo.
+Documents a person or repo owns are written with `crtr doc write --owner user|repo`; a plugin's documents ship as files in its `memory/` folder and belong to the plugin.
+
+Each file under `memory/` becomes one document the plugin owns: its path below `memory/`, without `.md` (and without a `NN-` prefix), is the document's name, written `<plugin>/<name>` from other owners. Installing records the document and its delivery rules; its body is always read from the file. The file's frontmatter keys are the document's fields: `kind` (`knowledge` or `preference`), `preview`, `summary`, `delivery` (a list of rules, each with `on`, optional `match`/`match-frontmatter`, optional `if`, and `deliver`), `unlisted`, `why-it-exists`, `lint-ignore`, and `extensions`. Plugin documents are public and read-only; they change only when the plugin is updated.
 
 Reach for a **plugin** when:
-- You want to share memory docs across multiple projects or with other people.
+- You want to share documents across multiple projects or with other people.
 - You want versioning + update mechanics (`crtr pkg plugin update --name <name>`).
 - You want a marketplace to index the work — see [[internal/marketplaces]].
 
@@ -98,8 +100,8 @@ Each addendum is a nonempty object keyed by lowercase kebab-case local field nam
 | `type` | yes | `boolean`, `string`, `number`, or `enum`. |
 | `values` | enum only | A nonempty, unique list of nonempty strings. It is invalid for every other type. |
 | `default` | no | A value matching `type`; an enum default must be one of `values`. |
-| `write_help` | yes | Nonblank single-line text generated into the field catalog on `crtr memory write -h`. |
-| `edit_help` | yes | Nonblank single-line text generated into the field catalog on `crtr memory edit -h`. |
+| `write_help` | yes | Nonblank single-line text generated into the field catalog on `crtr doc write -h`. |
+| `edit_help` | yes | Nonblank single-line text generated into the field catalog on `crtr doc edit -h`. |
 
 The generated catalogs show each installed field's full path, type (or enum alternatives), and default when declared. They are the maintained authoring surface; the addendum is their sole help source. Read those leaves for the set, change, and unset mechanics.
 
@@ -113,7 +115,7 @@ extensions:
 
 `extensions` and each namespace must be mappings. Values may only be strings, booleans, or finite numbers; a declared field then must satisfy its own type, and an enum must be one of its declared strings. A plugin can declare only fields in its own manifest-name namespace. Two plugins can use the same local field name because their namespaces remain distinct.
 
-A default is interpretation, not persistence: an absent declared field resolves to its default only in the effective metadata projection and is never written back into frontmatter. `crtr memory read --frontmatter` exposes exactly the explicit raw mapping. Structured `crtr --json memory read` and `crtr --json memory list` expose only effective, valid metadata in `extensions`, overlaying explicit values on enabled declarations' defaults. Ordinary read and list rendering deliberately omit the metadata, and crouter never injects it into a memory body or agent-facing memory render.
+A default is interpretation, not persistence: an absent declared field resolves to its default only in the effective metadata projection and is never written back into frontmatter. `crtr canvas read --fields` exposes exactly the explicit raw mapping. Structured `crtr --json canvas read` and `crtr --json canvas list --type document` expose only effective, valid metadata in `extensions`, overlaying explicit values on enabled declarations' defaults. Ordinary read and list rendering deliberately omit the metadata, and crouter never injects it into a memory body or agent-facing memory render.
 
 Crouter maintains separate declaration views for validation and interpretation. Validation and generated authoring help use the closest installed declaration even when its plugin is disabled, so an existing value remains type-checked and can be changed or removed. Effective structured metadata uses only the winning enabled declaration. Therefore disabling a plugin leaves its raw frontmatter in place but omits that namespace and its defaults from effective output; it has no crouter behavior of its own. If the owner is removed or cannot resolve, the namespace is raw-only and inert, lint reports it as unresolved, and unrelated core-frontmatter edits preserve it. Re-enabling or reinstalling the owner restores explicit values and defaults to effective interpretation without rewriting the document.
 
@@ -135,11 +137,11 @@ Archive plugins declare the identical addendum in `bundle.json` beside `bundleVe
 
 The archive validator applies the same closed declaration contract and copies the accepted block into the synthesized installed `plugin.json`; archive and source plugins therefore present one installed declaration model.
 
-`crtr memory lint` validates extension mappings and reports malformed mappings, unresolved namespaces, undeclared fields, non-scalar values, wrong types, and invalid enum values at their field paths. Installation and every update validate the candidate declaration plus every candidate `memory/**/*.md` document against the shared core-frontmatter and extension contracts before activation. The candidate's own declaration governs its package while it is checked, including when it changes or removes a declaration present in the installed version. Candidates are staged outside active plugin paths and replace the active package only after validation; a failed source, archive, or marketplace candidate never becomes reachable through an active plugin path, and the previous package and recorded version remain active.
+`crtr doc lint` validates extension mappings and reports malformed mappings, unresolved namespaces, undeclared fields, non-scalar values, wrong types, and invalid enum values at their field paths. Installation and every update validate the candidate declaration plus every candidate `memory/**/*.md` document against the shared core-frontmatter and extension contracts before activation. The candidate's own declaration governs its package while it is checked, including when it changes or removes a declaration present in the installed version. Candidates are staged outside active plugin paths and replace the active package only after validation; a failed source, archive, or marketplace candidate never becomes reachable through an active plugin path, and the previous package and recorded version remain active.
 
 ## Plugin kinds
 
-A plugin can ship a complete persona kind: declare the registry entry in the manifest's `kinds` block, and author the persona prose as ordinary plugin memory docs gated `{kind: <name>, mode: base}` (and `{kind: <name>, mode: orchestrator}`) surfaced `{on: boot, at: content}` — the same shape a builtin kind uses at `kinds/<kind>/00-base.md`. Nothing else is needed: gates evaluate uniformly over plugin docs, so the persona splices into any node launched with that kind.
+A plugin can ship a complete persona kind: declare the registry entry in the manifest's `kinds` block, and author the persona prose as ordinary plugin documents with the rule `{on: boot, if: {kind: <name>, mode: base}, deliver: content}` (and one with `if: {kind: <name>, mode: orchestrator}`) — the same shape a builtin kind uses at `kinds/<kind>/00-base.md`. Nothing else is needed: `if` conditions evaluate uniformly over plugin documents, so the persona splices into any node launched with that kind.
 
 `readMergedLaunchConfig` layers an enabled plugin's `kinds` entries directly above the builtin registry and below its host scope's own `config.json` — full precedence: builtin → user-scope plugins → user config → profile → per project root (that root's plugins → that root's config). So a plugin kind appears in `crtr node new -h` and is launchable like any other, and a user or project `config.json` can still patch or shadow it. Plugins within one scope layer name-sorted; the scope's own config always wins.
 
@@ -194,7 +196,7 @@ Four ways a plugin lands in a scope:
 mkdir -p my-plugin/.crouter-plugin my-plugin/memory
 $EDITOR my-plugin/.crouter-plugin/plugin.json      # write the manifest
 cd my-plugin
-$EDITOR my-plugin/memory/my-first-doc.md           # author the doc — `crtr memory write -h` is the frontmatter + routing guide
+$EDITOR my-plugin/memory/my-first-doc.md           # author the doc — `crtr doc write -h` is the field + delivery-rule guide
 
 # Symlink for fast iteration — no clone, edits land immediately
 ln -s $(pwd) ~/.crouter/plugins/my-plugin
@@ -202,9 +204,9 @@ ln -s $(pwd) ~/.crouter/plugins/my-plugin
 # Verify
 crtr pkg plugin list                       # my-plugin appears
 crtr pkg plugin show my-plugin             # lists its docs
-crtr memory read my-plugin/my-first-doc            # resolve it under the plugin namespace
+crtr canvas read my-plugin/my-first-doc            # resolve it under the plugin's name
 crtr sys doctor                                    # validates the manifest
-crtr memory lint                                    # validates doc frontmatter
+crtr doc lint                                       # validates document fields and links
 ```
 
 When ready to share: push to a git remote; anyone can `crtr pkg plugin install <url> --scope user`.
@@ -223,9 +225,9 @@ Standard semver:
 
 ## Enable/disable
 
-`crtr pkg plugin disable <name>` flips the per-scope config without removing files. Disabled plugins are hidden from `crtr memory list` and don't resolve via `crtr memory read <name>`. Re-enable with `crtr pkg plugin enable <name>`.
+`crtr pkg plugin disable <name>` flips the per-scope config without removing files. Disabled plugins are hidden from `crtr canvas list` and don't resolve via `crtr canvas read <name>`. Re-enable with `crtr pkg plugin enable <name>`.
 
-Individual memory docs inside an enabled plugin are hidden by giving them no `surfaces` entries plus `unlisted: true` (or a gate that fails), not by a command — see `crtr memory write -h`.
+Individual documents inside an enabled plugin are hidden by giving them no delivery rules plus `unlisted: true` (or a rule whose `if` fails), not by a command — see `crtr doc write --rule -h`.
 
 ## What goes in a plugin
 
@@ -410,7 +412,7 @@ Both relative `argv[0]` and `cwd` resolve against the declaring scope's authorin
 - Each scope `humanActions` declaration is reported as a `humanActions:<name>` check. Doctor validates names, argv shape, cwd, executable existence, and execute permission without executing the action; plugins and profiles never contribute this block.
 - When an enabled plugin declares `requires`, each `requires:<name>` check names the plugin and resolved executable path on pass, or carries its install hint as remediation on fail. The executable is never run; a malformed declaration fails source-plugin install and update, while an absent executable remains advisory.
 
-`crtr memory lint` checks the docs under `memory/`: frontmatter parses, valid `kind`, valid `surfaces` entries. Run `crtr memory write -h` for the authoring + routing guide. Other sibling artifact dirs (`rules/`, `agents/`, `hooks/`) are validated by their respective specs as those land.
+`crtr doc lint` checks the documents under `memory/`: fields parse, valid `kind`, valid `delivery` rules. Run `crtr doc write -h` for the field + delivery-rule guide. Other sibling artifact dirs (`rules/`, `agents/`, `hooks/`) are validated by their respective specs as those land.
 
 ## Cross-publishing with Claude Code
 

package/dist/builtin-memory/internal/storage-tiers.md

@@ -15,17 +15,17 @@ crtr state is split into two tiers with distinct ownership and durability. This
 
 ## 1. Scope root — durable user/repo content and prepared support material
 
-`~/.crouter/` (user scope) or `<project>/.crouter/` (project scope), resolved by `src/core/scope.ts`. Durable content includes `memory/`, `prompts/`, `plugins/`, `marketplaces/`, `personas/`, and `config.json`; user-authored content belongs to the user scope and repo-authored content to the project scope. `prompts/<name>.md` becomes `/<name>` in every node, with nested paths becoming colon-namespaced commands and the nearest resolved scope winning.
+`~/.crouter/` (user scope) or `<project>/.crouter/` (project scope), resolved by `src/core/scope.ts`. Durable content includes `prompts/`, `plugins/`, `marketplaces/`, `personas/`, and `config.json`; user-authored content belongs to the user scope and repo-authored content to the project scope. `prompts/<name>.md` becomes `/<name>` in every node, with nested paths becoming colon-namespaced commands and the nearest resolved scope winning.
 
-`~/.crouter/support/<reference>/` is user-scope prepared local diagnostic material. A reference contains the prepared support bundle and manifest for explicit handling; it is not `memory/`, project memory, a node context artifact, or a project-scoped support store. Preparation is local and zero-egress; submission is an explicit operation to its verified destination. Invocation, output, and artifact details belong on the relevant command leaf `-h` surfaces.
+`~/.crouter/support/<reference>/` is user-scope prepared local diagnostic material. A reference contains the prepared support bundle and manifest for explicit handling; it is not a document, a node context artifact, or a project-scoped support store. Preparation is local and zero-egress; submission is an explicit operation to its verified destination. Invocation, output, and artifact details belong on the relevant command leaf `-h` surfaces.
 
 User-wide content with no cwd dimension also belongs here: `~/.crouter/profile-defaults.json` maps realpath'd directories to their selected profile, and `~/.crouter/prompt-reviews/` holds prompt-review exports.
 
 ## 2. Canvas home — node-graph runtime state, node artifacts, and bounded diagnostics
 
-`~/.crouter/canvas/` (overridable with `CRTR_HOME`) is the cwd-agnostic node-graph home. `canvas.db` is the SQLite WAL topology store for nodes and edges, including durable tmux-pane focus. `nodes/<node_id>/` owns `meta.json`, `context/`, `reports/`, `messages/`, `inbox.jsonl`, `transcript.jsonl`, `session.ptr`, and `job/` state. Human ticket files (`page.json`, `page.tsx`, `page.js`, optional `reply-route.json`, `action.json`, `response.json`, `review.json`, and `branch-point.jsonl`) live under `nodes/`, the single derived ticket root. A ticket is not owned by a node: reply-bearing tickets target the bridge recorded in `reply-route.json`, while a ticket created programmatically has no bridge and outlives the process that created it. `action.json` is the frozen action binding — the declared `humanActions` name, its resolved argv and cwd, and the opaque payload — written once at creation and never rewritten, so a later config edit cannot redirect an existing request. Whichever writer wins settlement is the one that queues delivery; the attempt schedule itself is crtrd scheduling state in `canvas.db`, not a ticket file, and delivery never rewrites the ticket's terminal result.
+`~/.crouter/canvas/` (overridable with `CRTR_HOME`) is the cwd-agnostic node-graph home. `canvas.db` is the SQLite WAL topology store for nodes and edges, including durable tmux-pane focus. `nodes/<node_id>/` owns `meta.json`, `context/`, `messages/`, `inbox.jsonl`, `transcript.jsonl`, `session.ptr`, and `job/` state. Human ticket files (`page.json`, `page.tsx`, `page.js`, optional `reply-route.json`, `action.json`, `response.json`, `review.json`, and `branch-point.jsonl`) live under `nodes/`, the single derived ticket root. A ticket is not owned by a node: reply-bearing tickets target the bridge recorded in `reply-route.json`, while a ticket created programmatically has no bridge and outlives the process that created it. `action.json` is the frozen action binding — the declared `humanActions` name, its resolved argv and cwd, and the opaque payload — written once at creation and never rewritten, so a later config edit cannot redirect an existing request. Whichever writer wins settlement is the one that queues delivery; the attempt schedule itself is crtrd scheduling state in `canvas.db`, not a ticket file, and delivery never rewrites the ticket's terminal result. Document bodies are content-addressed files under `bodies/`; their records, revisions, delivery rules, edges and watches are rows in `canvas.db`. A repo's documents also travel on the repo's git ref `refs/crtr/docs`.
 
-Specifications and plans are ordinary node-context artifacts. They share the node's lifetime and are removed when that node is reaped.
+Specifications and plans are documents their node owns. They are deleted with that node unless a kept document links to them or they are given another owner (`crtr doc move --owner`).
 
 ### Canonical event streams
 

package/dist/builtin-memory/memory-read-orientation.md

@@ -10,4 +10,4 @@ surfaces:
     at: content
 ---
 
-`crtr memory read --frontmatter <name>` includes YAML frontmatter. Revise a document with `crtr memory edit` (recorded, with a rationale), or browse the inventory with `crtr memory list`.
+`crtr canvas read --fields <name>` includes the document's fields. Revise a document with `crtr doc edit` (recorded, with a rationale), or browse the inventory with `crtr canvas list --type document`.