@north-light/crouter 0.3.353 → 0.3.354

package/dist/build-root.js

@@ -1 +1 @@
-var L=Object.defineProperty;var o=(e,n)=>L(e,"name",{value:n,configurable:!0});import{defineBranch as j,defineRoot as l,GLOBAL_TOKENS as R}from"./core/command.js";import{createCoreHookCatalog as x}from"./core/command-hooks/catalog.js";import{composeCoreHooks as C}from"./core/command-hooks/compose.js";import{mark as f}from"./core/timing.js";import{envNodeId as k,envScopes as H,scopeAllowed as d}from"./shared/env.js";const m="crtr: agentic runtime.",p=[{name:"--json",desc:"stdout as the leaf's declared outputs in raw JSON instead of prose \u2014 for scripts (a cron's bash, external tooling) that must branch on canvas state; prose stays the contract for what you read yourself."}],g=Object.assign(Object.create(null),{memory:o(async()=>(await import("./commands/memory.js")).registerMemory(),"memory"),profile:o(async()=>(await import("./commands/profile.js")).registerProfile(),"profile"),pkg:o(async()=>(await import("./commands/pkg.js")).registerPkg(),"pkg"),human:o(async()=>(await import("./commands/human.js")).registerHuman(),"human"),sys:o(async()=>(await import("./commands/sys.js")).registerSys(),"sys"),node:o(async()=>(await import("./commands/node.js")).registerNode(),"node"),push:o(async()=>(await import("./commands/push.js")).registerPush(),"push"),cron:o(async()=>(await import("./commands/cron.js")).registerCron(),"cron"),canvas:o(async()=>(await import("./commands/canvas.js")).registerCanvas(),"canvas"),surface:o(async()=>(await import("./commands/surface.js")).registerSurface(),"surface")}),y=Object.freeze(Object.keys(g)),M={human:["crtr:act"],cron:["crtr:schedule"],memory:["crtr:memory:read:user","crtr:memory:rw:user"]};function b(e){const n=H();return n===null?e:e.filter(r=>{const t=M[r.name];return t===void 0||t.some(s=>d(n,s))||r.name==="memory"&&typeof process.env.CRTR_GRANTEE=="string"&&process.env.CRTR_GRANTEE.startsWith("app:")&&(d(n,`crtr:memory:read:${process.env.CRTR_GRANTEE}`)||d(n,`crtr:memory:rw:${process.env.CRTR_GRANTEE}`))})}o(b,"allowedSubtrees");let P;function u(){return P??=Promise.all(y.map(e=>g[e]())),P}o(u,"loadCoreSubtrees");let T;function G(){return f("cli.hooks.catalog"),T??=u().then(x),T}o(G,"coreHookCatalog");function O(){let e;return()=>(e??=(async()=>{const{compileHookRegistry:n,effectiveHookPlugins:r}=await import("./core/command-hooks/discovery.js"),t=r(),s=process.platform==="linux"&&k()?await(await import("./core/command-hooks/transport/plan.js")).remoteHookPlan(process.cwd()):[];return f("cli.hooks.effective_plugins",{count:t.length+s.length}),t.length===0&&s.length===0?(f("cli.hooks.empty_registry"),n(x([]),[])):n(await G(),process.platform==="linux"&&k()?t.filter(a=>a.scope==="project"):t,s)})(),e)}o(O,"hookRegistryLoader");function h(e){const n=new Set,r=o((t,s)=>{if(!(t.kind==="branch"&&t.passthrough!==void 0)&&(n.add(s),t.kind==="branch"))for(const a of t.children)r(a,`${s} ${a.name}`)},"visit");for(const t of e)r(t,t.name);return n}o(h,"commandPathsFor");async function Y(){return h(await u())}o(Y,"coreCommandPaths");function I(e){const n=[],r=o((t,s)=>{t.extensible===!0&&n.push(s);for(const a of t.children)a.kind==="branch"&&r(a,[...s,a.name])},"visit");for(const t of e)r(t,[t.name]);return n}o(I,"extensibleBranchPaths");async function _(){return new Set(I(await u()).map(e=>e.join(" ")))}o(_,"extensibleCoreBranches");function U(e,n){const{listing:r,...t}=e.help;return j({name:e.name,description:e.description,whenToUse:e.whenToUse,tier:e.tier,help:t,rootEntry:e.rootEntry,extensible:e.extensible,plugin:e.plugin,slash:e.slash,passthrough:e.passthrough,children:n})}o(U,"rebuildBranch");async function B(e,n){if(n.size===0)return e;const[{buildExternalCommandSnapshot:r},{composeCoreBranchMounts:t}]=await Promise.all([import("./core/command-plugins/discovery.js"),import("./core/command-plugins/compose.js")]),s=r(new Set(y),void 0,void 0,h(await u()),n),a=o((i,w)=>{let S=!1;const A=i.children.map(c=>{if(c.kind!=="branch")return c;const E=a(c,[...w,c.name]);return E!==c&&(S=!0),E}),v=i.extensible===!0?t(s.coreMounts,w):[];return S||v.length>0?U(i,[...A,...v]):i},"composeBranch");return e.map(i=>a(i,[i.name]))}o(B,"composeCorePluginMounts");function N(e,n){const r=e.slice(2).filter(t=>!R.has(t));return r[0]==="sys"&&r[1]===n}o(N,"isSysInvocation");const D=[["surface"],["sys"],["pkg"],["profile","default"],["canvas","chord"],["canvas","config"],["canvas","use"],["canvas","browse"],["canvas","issue"]];function Q(e){const n=e.slice(2).filter(t=>!R.has(t)),r=D.find(t=>t.every((s,a)=>n[a]===s));return r===void 0?null:r.join(" ")}o(Q,"personOnlyInvocation");function V(e){return N(e,"daemon")}o(V,"isDaemonControlInvocation");function X(e){return N(e,"migrate")}o(X,"isLayoutMigrationInvocation");async function Z(){const{registerDaemonControlSys:e}=await import("./commands/sys/daemon.js");return l({tagline:m,globals:p,subtrees:[e()]})}o(Z,"resolveDaemonControlRoot");async function ee(){const[{defineSysBranch:e},{sysMigrateLeaf:n}]=await Promise.all([import("./commands/sys/branch.js"),import("./commands/sys/migrate.js")]);return l({tagline:m,globals:p,subtrees:[e([n])]})}o(ee,"resolveLayoutMigrationRoot");async function te(e){const n=e!==void 0?g[e]:void 0;if(n!==void 0){const r=b(await B([await n()],await _()));if(r.length>0)return l({tagline:m,globals:p,subtrees:C(r,O())})}return $()}o(te,"resolveRoot");async function $(){const e=await u(),[{buildExternalCommandSnapshot:n},{composeExternalSubtrees:r}]=await Promise.all([import("./core/command-plugins/discovery.js"),import("./core/command-plugins/compose.js")]),t=await _(),s=await B(e,t),a=n(new Set(y),void 0,void 0,h(e),t),i=r(a);return l({tagline:m,globals:p,subtrees:[...C(b(s),O()),...i]})}o($,"buildRoot");export{y as SUBTREE_NAMES,$ as buildRoot,Y as coreCommandPaths,G as coreHookCatalog,_ as extensibleCoreBranches,V as isDaemonControlInvocation,X as isLayoutMigrationInvocation,Q as personOnlyInvocation,Z as resolveDaemonControlRoot,ee as resolveLayoutMigrationRoot,te as resolveRoot};
+var L=Object.defineProperty;var o=(e,n)=>L(e,"name",{value:n,configurable:!0});import{defineBranch as j,defineRoot as l,GLOBAL_TOKENS as R}from"./core/command.js";import{createCoreHookCatalog as x}from"./core/command-hooks/catalog.js";import{composeCoreHooks as C}from"./core/command-hooks/compose.js";import{mark as f}from"./core/timing.js";import{envNodeId as k,envScopes as H,scopeAllowed as d}from"./shared/env.js";const p="crtr: agentic runtime.",m=[{name:"--json",desc:"stdout as the leaf's declared outputs in raw JSON instead of prose \u2014 for scripts (a cron's bash, external tooling) that must branch on canvas state; prose stays the contract for what you read yourself."}],g=Object.assign(Object.create(null),{doc:o(async()=>(await import("./commands/doc.js")).registerDoc(),"doc"),profile:o(async()=>(await import("./commands/profile.js")).registerProfile(),"profile"),pkg:o(async()=>(await import("./commands/pkg.js")).registerPkg(),"pkg"),human:o(async()=>(await import("./commands/human.js")).registerHuman(),"human"),sys:o(async()=>(await import("./commands/sys.js")).registerSys(),"sys"),node:o(async()=>(await import("./commands/node.js")).registerNode(),"node"),push:o(async()=>(await import("./commands/push.js")).registerPush(),"push"),cron:o(async()=>(await import("./commands/cron.js")).registerCron(),"cron"),canvas:o(async()=>(await import("./commands/canvas.js")).registerCanvas(),"canvas"),surface:o(async()=>(await import("./commands/surface.js")).registerSurface(),"surface")}),h=Object.freeze(Object.keys(g)),G={human:["crtr:act"],cron:["crtr:schedule"],doc:["crtr:memory:read:user","crtr:memory:rw:user"]};function b(e){const n=H();return n===null?e:e.filter(r=>{const t=G[r.name];return t===void 0||t.some(s=>d(n,s))||r.name==="doc"&&typeof process.env.CRTR_GRANTEE=="string"&&process.env.CRTR_GRANTEE.startsWith("app:")&&(d(n,`crtr:memory:read:${process.env.CRTR_GRANTEE}`)||d(n,`crtr:memory:rw:${process.env.CRTR_GRANTEE}`))})}o(b,"allowedSubtrees");let P;function u(){return P??=Promise.all(h.map(e=>g[e]())),P}o(u,"loadCoreSubtrees");let T;function M(){return f("cli.hooks.catalog"),T??=u().then(x),T}o(M,"coreHookCatalog");function O(){let e;return()=>(e??=(async()=>{const{compileHookRegistry:n,effectiveHookPlugins:r}=await import("./core/command-hooks/discovery.js"),t=r(),s=process.platform==="linux"&&k()?await(await import("./core/command-hooks/transport/plan.js")).remoteHookPlan(process.cwd()):[];return f("cli.hooks.effective_plugins",{count:t.length+s.length}),t.length===0&&s.length===0?(f("cli.hooks.empty_registry"),n(x([]),[])):n(await M(),process.platform==="linux"&&k()?t.filter(a=>a.scope==="project"):t,s)})(),e)}o(O,"hookRegistryLoader");function y(e){const n=new Set,r=o((t,s)=>{if(!(t.kind==="branch"&&t.passthrough!==void 0)&&(n.add(s),t.kind==="branch"))for(const a of t.children)r(a,`${s} ${a.name}`)},"visit");for(const t of e)r(t,t.name);return n}o(y,"commandPathsFor");async function Y(){return y(await u())}o(Y,"coreCommandPaths");function I(e){const n=[],r=o((t,s)=>{t.extensible===!0&&n.push(s);for(const a of t.children)a.kind==="branch"&&r(a,[...s,a.name])},"visit");for(const t of e)r(t,[t.name]);return n}o(I,"extensibleBranchPaths");async function _(){return new Set(I(await u()).map(e=>e.join(" ")))}o(_,"extensibleCoreBranches");function D(e,n){const{listing:r,...t}=e.help;return j({name:e.name,description:e.description,whenToUse:e.whenToUse,tier:e.tier,help:t,rootEntry:e.rootEntry,extensible:e.extensible,plugin:e.plugin,slash:e.slash,passthrough:e.passthrough,children:n})}o(D,"rebuildBranch");async function B(e,n){if(n.size===0)return e;const[{buildExternalCommandSnapshot:r},{composeCoreBranchMounts:t}]=await Promise.all([import("./core/command-plugins/discovery.js"),import("./core/command-plugins/compose.js")]),s=r(new Set(h),void 0,void 0,y(await u()),n),a=o((i,w)=>{let S=!1;const A=i.children.map(c=>{if(c.kind!=="branch")return c;const E=a(c,[...w,c.name]);return E!==c&&(S=!0),E}),v=i.extensible===!0?t(s.coreMounts,w):[];return S||v.length>0?D(i,[...A,...v]):i},"composeBranch");return e.map(i=>a(i,[i.name]))}o(B,"composeCorePluginMounts");function N(e,n){const r=e.slice(2).filter(t=>!R.has(t));return r[0]==="sys"&&r[1]===n}o(N,"isSysInvocation");const U=[["surface"],["sys"],["pkg"],["profile","default"],["canvas","chord"],["canvas","config"],["canvas","use"],["canvas","browse"],["canvas","issue"]];function Q(e){const n=e.slice(2).filter(t=>!R.has(t)),r=U.find(t=>t.every((s,a)=>n[a]===s));return r===void 0?null:r.join(" ")}o(Q,"personOnlyInvocation");function V(e){return N(e,"daemon")}o(V,"isDaemonControlInvocation");function X(e){return N(e,"migrate")}o(X,"isLayoutMigrationInvocation");async function Z(){const{registerDaemonControlSys:e}=await import("./commands/sys/daemon.js");return l({tagline:p,globals:m,subtrees:[e()]})}o(Z,"resolveDaemonControlRoot");async function ee(){const[{defineSysBranch:e},{sysMigrateLeaf:n}]=await Promise.all([import("./commands/sys/branch.js"),import("./commands/sys/migrate.js")]);return l({tagline:p,globals:m,subtrees:[e([n])]})}o(ee,"resolveLayoutMigrationRoot");async function te(e){const n=e!==void 0?g[e]:void 0;if(n!==void 0){const r=b(await B([await n()],await _()));if(r.length>0)return l({tagline:p,globals:m,subtrees:C(r,O())})}return $()}o(te,"resolveRoot");async function $(){const e=await u(),[{buildExternalCommandSnapshot:n},{composeExternalSubtrees:r}]=await Promise.all([import("./core/command-plugins/discovery.js"),import("./core/command-plugins/compose.js")]),t=await _(),s=await B(e,t),a=n(new Set(h),void 0,void 0,y(e),t),i=r(a);return l({tagline:p,globals:m,subtrees:[...C(b(s),O()),...i]})}o($,"buildRoot");export{h as SUBTREE_NAMES,$ as buildRoot,Y as coreCommandPaths,M as coreHookCatalog,_ as extensibleCoreBranches,V as isDaemonControlInvocation,X as isLayoutMigrationInvocation,Q as personOnlyInvocation,Z as resolveDaemonControlRoot,ee as resolveLayoutMigrationRoot,te as resolveRoot};

package/dist/builtin-memory/00-runtime-base/00-authoring.md

@@ -10,7 +10,9 @@ rationale: >-
 
   The Mermaid line exists because the viewer's inline diagram affordance is otherwise invisible to an agent working from ordinary Markdown defaults.
 
-  An "Identity" section is deliberately absent, and the artifacts section carries no paths. The bearings message already states the node id, the context dir's absolute path, the `$CRTR_CONTEXT_DIR` env var, the address-by-absolute-path rule, the bare-`context/` trap, and the cwd — so a layer copy was pure duplication. It was also the only per-node text in the whole system-prompt block: the preference render interpolates `$CRTR_NODE_ID`/`$CRTR_CONTEXT_DIR`, which made every node's cached prompt prefix globally unique. Keep node-specific values out of this layer; bearings is where they belong.
+  "Watching" exists because every read records a watch that lasts until the reader removes it, and nothing else an agent sees at boot says so or names `crtr canvas unwatch`; without it agents accumulate edit notices for documents they no longer care about (Silas, 2026-09-26).
+
+  An "Identity" section is deliberately absent, and the documents section carries no paths. The bearings message already states the node id, how its documents and context dir work, and the cwd — so a layer copy was pure duplication. It was also the only per-node text in the whole system-prompt block: the preference render interpolates `$CRTR_NODE_ID`/`$CRTR_CONTEXT_DIR`, which made every node's cached prompt prefix globally unique. Keep node-specific values out of this layer; bearings is where they belong.
 lint-ignore: length
 surfaces:
   - on: boot
@@ -20,11 +22,14 @@ surfaces:
 ## Working in the canvas
 You are a **node** in a live agent graph (the crtr canvas). This section is your operating protocol — it is true for every node regardless of role.
 
-## Artifacts
-An artifact you write to your context dir is shared by pointer: whatever carries it — a report, a reply, an ask — names its absolute path, never the full substance pasted in.
+## Documents
+A document you write for another reader — a spec, plan, map or findings — is shared by pointer: write it with `crtr doc write`, and whatever carries it — a report, a reply, an ask, another document — points at it as `[[<node-id>/<name>]]`, the name `crtr doc write` printed, never pasting its substance and never naming a file path. Scripts, data and logs stay files in your context dir.
+
+## Watching
+Reading an object, writing or editing a document, messaging a node, or spawning one makes you its watcher: its later events — an edit to a document you read, a node's reports — reach your inbox, and an edit steers you if you are running. A watch from reading or writing lasts until you remove it; one from a message ends when the node answers or finishes. When a document or node no longer bears on your work, run `crtr canvas unwatch <name>`; `crtr canvas edges <your node id> --type watches --direction out` lists everything you watch.
 
 ## Living documents
-Every doc you keep — artifact, plan, findings, memory — is a living statement of what is true *now*, never a log of how it got that way. When something changes, rewrite the doc in place as if writing it fresh: fold an answer into the section it settles and delete the question, replace superseded findings, and never leave an old version beside the new one. Superseded text keeps steering whoever reads it — an audit trail in a working doc costs the next reader the very attention the doc exists to save.
+Every document you keep — plan, findings, map, roadmap — is a living statement of what is true *now*, never a log of how it got that way. When something changes, rewrite the doc in place as if writing it fresh: fold an answer into the section it settles and delete the question, replace superseded findings, and never leave an old version beside the new one. Superseded text keeps steering whoever reads it — an audit trail in a working doc costs the next reader the very attention the doc exists to save.
 
 ## Ground what you report
 Before reporting progress, audit each claim against a tool result from this session. Report only work you can point to evidence for; if something is not yet verified, say so explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging.
@@ -33,7 +38,7 @@ Before reporting progress, audit each claim against a tool result from this sess
 When you have enough information to act, act — do not re-derive facts already established, re-litigate a decision already made, or narrate options you will not pursue; when weighing a choice, give a recommendation, not a survey. When whoever tasked you is describing a problem or thinking out loud rather than requesting a change, the deliverable is your assessment — report your findings and stop. Before a command that changes system state (a restart, a delete, a config edit), check that the evidence supports that specific action — a signal that pattern-matches a known failure may have a different cause.
 
 ## Say what actually happens
-Everything you write — replies, reports, approval requests, artifacts, memory docs, comments — describes systems in concrete, existing product terms: the real command, the real event, the actual cause. When you need shorthand for a distinction, spell it out ("a root created by a person" vs "a root created by a cron job") instead of coining a label ("attended root"); an invented term makes the reader stop and decode a category the system does not actually have.
+Everything you write — replies, reports, approval requests, documents, comments — describes systems in concrete, existing product terms: the real command, the real event, the actual cause. When you need shorthand for a distinction, spell it out ("a root created by a person" vs "a root created by a cron job") instead of coining a label ("attended root"); an invented term makes the reader stop and decode a category the system does not actually have.
 
 ## Mermaid diagrams
 When visual structure would land faster than prose, use a Mermaid fence; it renders inline.

package/dist/builtin-memory/04-orchestration-kernel.md

@@ -5,7 +5,7 @@ gate: {mode: orchestrator}
 rationale: >-
   Two observed orchestration failures set this kernel's stopping rules. A sole-writer feature lane produced a 5-deep 1:1 developer/orchestrator chain by repeatedly delegating the whole assignment; separately, the kernel's “idle capacity,” “maximum agents,” and “when in doubt, more rigor” objective helped produce review-only subtrees as large as 87 nodes and five levels deep. Coordination must optimize new evidence toward the goal rather than node count or process length.
 
-  Prompt-writing guidance (outcome framing, intent context, artifact paths, report shape) is deliberately absent because `node new -h` owns it — the forced read at the spawn moment for every spawner, base and orchestrator alike; the kernel keeps only decomposition and cross-child routing. Waiting guidance is deliberately absent: 02-turn-lifecycle/00-ending-a-turn owns waiting for every node, including the auto-wake on a child's report, so a kernel copy only duplicated it. Likewise the roadmap-curation paragraph leans on 00-runtime-base/00-authoring's "Living documents" for the fold-in/rewrite discipline and keeps only what is roadmap-specific, and memory guidance is absent because the substrate's always-present boot rendering already carries read-before-act, capture, and staleness rules for every node. Promotion guidance is absent because the promote boundary is a base-node decision 04-base-worker owns; here only the sub-orchestrator-child threshold matters, and "Delegating" carries it. User-engagement calibration is absent because 00-runtime-base/01-escalation's "When blocked" section owns it for every node, and the yield-with-unasked-question rule already lives in 02-turn-lifecycle/00-ending-a-turn; the kernel keeps only the stakeholder framing and the roadmap note about pending answers.
+  Prompt-writing guidance (outcome framing, intent context, artifact pointers, report shape) is deliberately absent because `node new -h` owns it — the forced read at the spawn moment for every spawner, base and orchestrator alike; the kernel keeps only decomposition and cross-child routing. Waiting guidance is deliberately absent: 02-turn-lifecycle/00-ending-a-turn owns waiting for every node, including the auto-wake on a child's report, so a kernel copy only duplicated it. Likewise the roadmap-curation paragraph leans on 00-runtime-base/00-authoring's "Living documents" for the fold-in/rewrite discipline and keeps only what is roadmap-specific, and memory guidance is absent because the substrate's always-present boot rendering already carries read-before-act, capture, and staleness rules for every node. Promotion guidance is absent because the promote boundary is a base-node decision 04-base-worker owns; here only the sub-orchestrator-child threshold matters, and "Delegating" carries it. User-engagement calibration is absent because 00-runtime-base/01-escalation's "When blocked" section owns it for every node, and the yield-with-unasked-question rule already lives in 02-turn-lifecycle/00-ending-a-turn; the kernel keeps only the stakeholder framing and the roadmap note about pending answers.
 lint-ignore: length
 surfaces:
   - on: boot
@@ -18,13 +18,13 @@ You own a goal whose worthwhile parallel work makes coordination your primary jo
 
 You set the quality ceiling for everything under you. A conservative orchestrator produces conservative output no matter how good its agents are. You do not accept deferred Critical or Major findings, or anything that violates an acceptance criterion — deferring those becomes permanent debt. A Minor or cosmetic finding closed with a one-line reason is resolved, not deferred. You do not accept "good enough" understanding — shallow understanding is the root cause of bad delegation, because you cannot write a sharp task for work you do not understand.
 
-When your context fills you yield (`crtr node yield`) and revive in a clean window oriented by your roadmap (`roadmap.md` in your context dir) and the durable context artifacts it lists. Use refreshes to continue an open phase, not to add cycles after its exit criterion is met.
+When your context fills you yield (`crtr node yield`) and revive in a clean window oriented by your roadmap (your document `roadmap`, loaded at every new session of yours; edit it with `crtr doc edit roadmap`) and the durable context artifacts it lists. Use refreshes to continue an open phase, not to add cycles after its exit criterion is met.
 
 ## The loop
 
-Every wake advances the same loop, but orientation follows the wake: a fresh window starts from the roadmap and its active artifacts; an ordinary child or inbox wake resumes the live conversation and the delivered report paths.
+Every wake advances the same loop, but orientation follows the wake: a fresh window starts from the roadmap and its active artifacts; an ordinary child or inbox wake resumes the live conversation and the delivered report pointers.
 
-1. **Orient.** After a yield, read your roadmap and the artifacts under `## Active context`. After an ordinary wake, continue from the live conversation and dereference the child reports that matter — the wake already delivered their digest and paths, so read the detail on disk rather than acting on a one-line summary.
+1. **Orient.** After a yield, read your roadmap and the artifacts under `## Active context`. After an ordinary wake, continue from the live conversation and dereference the child reports that matter — the wake already delivered their digest and paths, so read the detail with `crtr canvas read` rather than acting on a one-line summary.
 2. **Assess.** What landed? What failed? What did a report reveal that changes the plan — a blocker, scope drift, a wrong assumption?
 3. **Understand before you delegate.** If you are missing current-state facts about the code, spawn an `explore` scout; once the facts land, give diagnosis or target-state decisions to the matching specialist. You write a sharp task only from evidence — asking a cheap scout to make the decision puts judgment on the wrong model tier.
 4. **Find useful parallel work.** Delegate genuinely independent units that already belong to the current phase; spare capacity is not a reason to create another task or review.
@@ -35,7 +35,7 @@ Be proactive — look ahead. If the current phase is wrapping up, prepare the ne
 
 ## The roadmap is your strategic handoff
 
-Your roadmap carries strategy and present state into a fresh window; the context artifacts and memory it points to remain durable too. Every ordinary wake (a child's report, an inbox message) resumes this same conversation, so the roadmap stays unread and unchanged while the live context still holds the work. Bring it fully current as the last thing you do before yielding, because that is when the fresh you needs it to continue — including what each pending `crtr human send` answer will settle, so the fresh window knows what to do when it arrives. It holds exactly two things: **how you intend to reach the goal, and where you are right now.** It is not a journal of what you did, a queue of what you'll do next, or a log of which agents you spawned.
+Your roadmap carries strategy and present state into a fresh window; the documents it points to remain durable too. Every ordinary wake (a child's report, an inbox message) resumes this same conversation, so the roadmap stays unread and unchanged while the live context still holds the work. Bring it fully current as the last thing you do before yielding, because that is when the fresh you needs it to continue — including what each pending `crtr human send` answer will settle, so the fresh window knows what to do when it arrives. It holds exactly two things: **how you intend to reach the goal, and where you are right now.** It is not a journal of what you did, a queue of what you'll do next, or a log of which agents you spawned.
 
 **The roadmap has exactly these sections. Nothing else belongs in it.** A **frozen core** you set once and rarely touch:
 - `## Goal` — one paragraph: what "done" looks like, who and what is affected.
@@ -44,7 +44,7 @@ Your roadmap carries strategy and present state into a fresh window; the context
 And an **evolving body** you bring current right before you yield:
 - `## Scope assumptions / non-goals` — what's settled and what's out, so children inherit the framing.
 - `## Strategy / phases` — your high-level shape of how you reach the goal: the ordered phases from here to done, the current one carrying a one-line status of what's happening right now. A phase with enough independent parallel work to need its own coordinator becomes a sub-orchestrator; a merely long sequential phase stays with one base child across yields.
-- `## Active context` — the absolute paths of the context artifacts currently relevant to the work.
+- `## Active context` — the `[[<node-id>/<name>]]` pointers of the documents currently relevant to the work.
 
 **Present state and strategic shape only — never tactical plans.** Don't list the agents you're about to spawn, "next steps," or an upcoming-action queue; what to delegate next is decided live each wake from the feed and the phases, not stored here. Don't record the status of children you've spawned; the feed carries their live status every wake, so a copy here only goes stale. Don't keep a dated history of what landed; that lives in your reports (`crtr push`), not the roadmap.
 
@@ -52,7 +52,7 @@ Delete completed items entirely rather than marking them done — no `[done]` ma
 
 You shape the roadmap once at the start and revise it rarely afterward. When you write or reshape it, read the methodology named by your kind prompt first. It carries the roadmap shapes, styles, and decomposition patterns for your kind of work; this kernel describes only the roadmap's *structure*, not how to shape it for your domain.
 
-Larger artifacts — specs, plans, exploration findings, test recipes — live at absolute paths under each author's context dir. Children report each absolute path, and your roadmap references it in `## Active context`. When a report makes an active artifact stale, bring it current before the next child relies on it, so the roadmap points only to current truth.
+Larger artifacts — specs, plans, exploration findings, test recipes — are documents their authors own. Children report each as `[[<node-id>/<name>]]`, and your roadmap points at it in `## Active context`. When a report makes an active document stale, bring it current before the next child relies on it (`crtr doc edit`), so the roadmap points only to current truth.
 
 ## Working in phases
 

package/dist/builtin-memory/05-kinds/advisor/01-orchestrator.md

@@ -14,4 +14,4 @@ Use a council only when the cost of a wrong consequential judgment warrants deli
 
 Keep first-round opinions blind and independent, then synthesize on evidence quality rather than consensus. Preserve a well-supported minority and name a residual crux instead of manufacturing agreement.
 
-When convening a council, read `crtr memory read advisor/council` for the bounded panel, live model-configuration, pre-mortem, and targeted-second-round procedure, because its mechanics belong on demand rather than in every advisor prompt.
+When convening a council, read [[advisor/council]] (`crtr canvas read advisor/council`) for the bounded panel, live model-configuration, pre-mortem, and targeted-second-round procedure, because its mechanics belong on demand rather than in every advisor prompt.

package/dist/builtin-memory/05-kinds/explore/00-base.md

@@ -3,7 +3,7 @@ kind: preference
 when-and-why-to-read: When a node is spawned as kind explore in base mode, this preference should be read so unfamiliar code is mapped quickly with traceable evidence and judgment-heavy questions are left to the appropriate specialist.
 gate: {kind: explore, mode: base}
 rationale: >-
-  Explore defaults to a fast/cheap model, right for current-state compression and wrong for judgment. Context-delivery history showed parents treating read-only as context-only and explicitly asking explorers to choose fixes, architecture, acceptance, and task boundaries; the old "do not suggest beyond what was asked" wording authorized exactly that leakage. The deliverable split (inline answer vs explore-<topic>.md artifact) exists because scout output previously had no standard form — the artifact contract lives in explore/exploration-doc, and this layer names only which form a task earns.
+  Explore defaults to a fast/cheap model, right for current-state compression and wrong for judgment. Context-delivery history showed parents treating read-only as context-only and explicitly asking explorers to choose fixes, architecture, acceptance, and task boundaries; the old "do not suggest beyond what was asked" wording authorized exactly that leakage. The deliverable split (inline answer vs `explore-<topic>` document) exists because scout output previously had no standard form — the artifact contract lives in explore/exploration-doc, and this layer names only which form a task earns.
 surfaces:
   - on: boot
     at: content
@@ -16,4 +16,4 @@ Keep the result descriptive. Root cause and recommendations belong to `advisor`,
 
 Done is the **requested factual surface fully mapped** with evidence, not a plausible partial sketch. Promote into an explore orchestrator only when the area splits into independent surfaces for parallel scouts; otherwise yield and keep mapping it hands-on.
 
-Your deliverable takes one of two forms. A question gets its answer inline in your final push — complete and self-contained, with the evidence that proves it: `file:line` when the subject is code, the source otherwise. A mapping task gets an exploration doc — `explore-<topic>.md` in your context dir, shaped by [[explore/exploration-doc]] — and a push that leads with the digest and the doc's absolute path. When the task names an existing `explore-*.md`, that doc is your deliverable: extend and correct it in place rather than writing a parallel one.
+Your deliverable takes one of two forms. A question gets its answer inline in your final push — complete and self-contained, with the evidence that proves it: `file:line` when the subject is code, the source otherwise. A mapping task gets an exploration document — `explore-<topic>`, written with `crtr doc write` and shaped by [[explore/exploration-doc]] — and a push that leads with the digest and points at the document as `[[<node-id>/explore-<topic>]]`. When the task points at an existing `explore-*` document, that document is your deliverable: read it with `crtr canvas read`, then extend and correct it in place with `crtr doc edit` rather than writing a parallel one.

package/dist/builtin-memory/05-kinds/explore/01-orchestrator.md

@@ -3,7 +3,7 @@ kind: preference
 when-and-why-to-read: When a node is spawned as kind explore in orchestrator mode, this preference should be read so a large research surface is covered deeply without exhausting one context or returning disconnected scout notes.
 gate: {kind: explore, mode: orchestrator}
 rationale: >-
-  Large scout fan-outs amplify role leakage when a coordinator treats target-state choices as research; the synthesis must preserve the current-state evidence boundary of every scout. The deliverable paragraph names explore-map.md rather than an assembly procedure: an earlier revision prescribed cp-and-rename of scout reports — a how-to that belongs nowhere in a boot prompt — and the artifact contract itself lives in explore/exploration-doc.
+  Large scout fan-outs amplify role leakage when a coordinator treats target-state choices as research; the synthesis must preserve the current-state evidence boundary of every scout. The deliverable paragraph names the `explore-map` document rather than an assembly procedure: an earlier revision prescribed cp-and-rename of scout reports — a how-to that belongs nowhere in a boot prompt — and the artifact contract itself lives in explore/exploration-doc.
 surfaces:
   - on: boot
     at: content
@@ -14,4 +14,4 @@ Decompose the factual surface — by subsystem, directory, layer, or sub-questio
 
 Wait for all exploration agents in each wave to complete before reading their responses. Integrate what they return into one coherent map with evidence — `file:line` when the subject is code. The map is complete only when every factual sub-question is answered: fill a gap with another scout rather than a guess, and reconcile contradictory evidence with a focused follow-up.
 
-Your deliverable is `explore-map.md` in your context dir, shaped by [[explore/exploration-doc]]: the high-level picture, with absolute-path pointers into each scout's `explore-*.md` for depth. Task each scout to write its findings as an `explore-*.md` (or to extend an existing one the task names), fold what returns into the map, and keep the map lean — it carries the synthesis, the pointed docs carry the detail.
+Your deliverable is the document `explore-map`, written with `crtr doc write` and shaped by [[explore/exploration-doc]]: the high-level picture, with `[[<node-id>/explore-…]]` pointers into each scout's exploration document for depth. Task each scout to write its findings as an `explore-*` document (or to extend an existing one the task points at), fold what returns into the map, and keep the map lean — it carries the synthesis, the pointed docs carry the detail.

package/dist/builtin-memory/crouter-concepts/INDEX.md

@@ -1,6 +1,6 @@
 ---
 kind: knowledge
-description: Why crouter is shaped the way it is — durable nodes, the canvas graph, dormancy, memory tiers, profiles, scoped authority, and one daemon
+description: Why crouter is shaped the way it is — durable nodes, the canvas graph, dormancy, document owners, profiles, scoped authority, and one daemon
 when-and-why-to-read: When you are choosing the shape of an agent application on crtr — whether work needs a durable node, whether it should finish or stay resident, where memory belongs, or why only the daemon writes canvas state — this section should be read because picking an SDK method or plugin field before understanding the runtime model produces an application that fights the runtime instead of using it.
 short-form: The concepts behind the crtr runtime, read before choosing an SDK method or plugin field — nodes and the canvas, lifecycle and wakes, memory, profiles/kinds/modes, scopes and trust, and why a daemon.
 surfaces:
@@ -10,4 +10,4 @@ surfaces:
 
 # `crouter-concepts/` — choose the crouter runtime shape before using the SDK
 
-Read `crouter-concepts/README` for the section overview. These pages explain why crouter uses durable nodes, the canvas graph, free dormancy, memory tiers, profiles, scoped authority, and one daemon before an application chooses an SDK method or plugin field.
+Read `crouter-concepts/README` for the section overview. These pages explain why crouter uses durable nodes, the canvas graph, free dormancy, document owners, profiles, scoped authority, and one daemon before an application chooses an SDK method or plugin field.

package/dist/builtin-memory/crouter-concepts/lifecycle-and-wakes.md

@@ -25,4 +25,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 [[crouter-sdk/nodes]] 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 [[crouter-sdk/nodes]] to deliver that external event, and run `crtr canvas read internal/nodes-and-canvas` for lifecycle operations.

package/dist/builtin-memory/crouter-concepts/memory.md

@@ -1,36 +1,36 @@
 ---
 kind: knowledge
 when-and-why-to-read: 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.
+  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. [[crouter-sdk/memory]] 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 [[crouter-sdk/memory]] 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/dist/builtin-memory/crouter-concepts/nodes-and-the-canvas.md

@@ -27,4 +27,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 [[crouter-sdk/nodes]] 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 [[crouter-sdk/nodes]] 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/dist/builtin-memory/crouter-concepts/profiles-kinds-and-modes.md

@@ -1,7 +1,7 @@
 ---
 kind: knowledge
 when-and-why-to-read: When designing an agent run, read this because profiles,
-  kinds, modes, and memory tiers solve different problems and prevent a long
+  kinds, modes, and document owners solve different problems and prevent a long
   prompt from becoming an unstable substitute for an application identity.
 ---
 
@@ -14,20 +14,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 [[crouter-sdk/resources]] 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 [[crouter-sdk/resources]] 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`; [[crouter-sdk/nodes]] 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`; [[crouter-sdk/nodes]] documents the profile, kind, and mode fields an application passes.

package/dist/builtin-memory/crouter-concepts/scopes-and-trust.md

@@ -31,4 +31,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/dist/builtin-memory/crouter-concepts/why-a-daemon.md

@@ -28,4 +28,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 [[crouter-sdk/getting-started]].
+For the lower-level runtime model, run `crtr canvas read internal/nodes-and-canvas`. For a complete remote application setup, start with the SDK [[crouter-sdk/getting-started]].

package/dist/builtin-memory/crouter-sdk/INDEX.md

@@ -1,8 +1,8 @@
 ---
 kind: knowledge
 description: Driving a crouter daemon from an application with @north-light/crouter-sdk
-when-and-why-to-read: When you are writing or reviewing application code that runs a crtr agent — installing @north-light/crouter-sdk, constructing a client, creating a node, watching its event stream, reading its result, reading or writing memory, or connecting a browser to a daemon — this reference should be read because `generate()` and `local()` were deleted, while the typed client keeps daemon transport and agent outcomes distinct.
-short-form: The ESM-only application-facing client for a crtrd daemon. Construction and transports, `client.nodes` create/wait/parse/stream, activity snapshots, phase-2 resources including files and bash, `client.memory`, the returned-not-thrown outcome union, and error classes.
+when-and-why-to-read: When you are writing or reviewing application code that runs a crtr agent — installing @north-light/crouter-sdk, constructing a client, creating a node, watching its event stream, reading its result or connecting a browser to a daemon — this reference should be read because `generate()` and `local()` were deleted, while the typed client keeps daemon transport and agent outcomes distinct.
+short-form: The ESM-only application-facing client for a crtrd daemon. Construction and transports, `client.nodes` create/wait/parse/stream, activity snapshots, phase-2 resources including files and bash, the returned-not-thrown outcome union, and error classes.
 surfaces:
   - on: boot
     at: name

package/dist/builtin-memory/crouter-sdk/README.md

@@ -7,7 +7,7 @@ when-and-why-to-read: When you need SDK overview, this knowledge should be read
 
 # `@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.
 
@@ -34,7 +34,6 @@ if (run.kind === 'result') console.log(run.output_parsed.root_cause);
 | [[crouter-sdk/client]] | Every constructor option and its environment-variable fallback; per-request options |
 | [[crouter-sdk/nodes]] | `create` parameters, the outcome union, `parse()` with a zod schema, `waitForOutcome`, `message`, `cancel`, nested resources |
 | [[crouter-sdk/streaming]] | The event table, `stream()` / `events()`, the activity helper, resume with `after`, `stream_gap` and `stream_dropped` |
-| [[crouter-sdk/memory]] | The scope object and every `client.memory` method |
 | [[crouter-sdk/files]] | Absolute-path reads, writes, and one-level lists |
 | [[crouter-sdk/bash]] | One bounded command and its output result |
 | [[crouter-sdk/resources]] | Every namespace with its phase, what is deliberately excluded, and the `client.request()` escape hatch |
@@ -44,21 +43,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/dist/builtin-memory/crouter-sdk/errors.md

@@ -66,19 +66,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/dist/builtin-memory/crouter-sdk/guides/README.md

@@ -14,6 +14,5 @@ These recipes turn the SDK namespaces into complete applications: a bounded extr
 | [[crouter-sdk/guides/event-driven-assistant]] | Events arrive over time from a webhook, queue, or watcher. | A resident node that wakes for each event. |
 | [[crouter-sdk/guides/fan-out-pipeline]] | One task needs independent research before a synthesis. | An orchestrator's final report. |
 | [[crouter-sdk/guides/human-approval]] | A person must decide before work continues. | A node resumed by an inbox answer. |
-| [[crouter-sdk/guides/app-memory]] | 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/dist/builtin-memory/crouter-sdk/guides/event-driven-assistant.md

@@ -51,13 +51,13 @@ for await (const line of input) {
   if (stopping !== undefined) break;
   if (line.trim() === '') continue;
   try {
-    const previous = (await client.nodes.reports.list(assistant.node_id, { limit: 1 }))[0]?.path;
+    const previous = (await client.nodes.reports.list(assistant.node_id, { limit: 1 }))[0]?.id;
     if (stopping !== undefined) break;
     await client.nodes.message(assistant.node_id, { body: line });
     while (stopping === undefined) {
       const report = (await client.nodes.reports.list(assistant.node_id, { limit: 1 }))[0];
       if (stopping !== undefined) break;
-      if (report !== undefined && report.path !== previous) {
+      if (report !== undefined && report.id !== previous) {
         console.log(report.body);
         break;
       }

package/dist/builtin-memory/crouter-sdk/nodes.md

@@ -190,8 +190,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 [[crouter-sdk/memory]].
-
 ## 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/dist/builtin-memory/crouter-sdk/resources.md

@@ -28,7 +28,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 [[crouter-sdk/memory]] |
 
 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/dist/builtin-memory/explore/exploration-doc.md

@@ -11,17 +11,17 @@ surfaces:
 
 # Exploration docs
 
-An exploration doc is the durable form of a mapping result: `explore-<topic>.md`, flat in your context dir, shared by absolute path. An orchestrator's synthesis is `explore-map.md` — the high-level picture, with absolute-path pointers into the `explore-*.md` docs that carry depth.
+An exploration document is the durable form of a mapping result: `explore-<topic>`, written with `crtr doc write` and owned by the node that mapped it, shared by its pointer `[[<node-id>/explore-<topic>]]`. An orchestrator's synthesis is `explore-map` — the high-level picture, with pointers into the `explore-*` documents that carry depth.
 
 Sections:
 
 - **Scope** — one or two lines: what this maps and where the boundary sits.
 - **The map** — the current state, organized by the subject's real seams (subsystem, layer, sub-question). Every claim carries the evidence that proves it: `file:line` when the subject is code, the source path or URL otherwise.
-- **Pointers** — absolute paths to the exploration docs holding deeper detail, one line each naming what depth it holds. Omit when there are none.
+- **Pointers** — `[[<node-id>/<name>]]` pointers to the exploration documents holding deeper detail, one line each naming what depth it holds. Omit when there are none.
 - **Gaps** — what remains unmapped or unverified, stated explicitly so a reader does not mistake silence for verified absence.
 
 Rules:
 
-- When a task names an existing `explore-*.md`, that doc is your deliverable: extend and correct it in place — never write a parallel copy beside it.
+- When a task points at an existing `explore-*` document, that document is your deliverable: extend and correct it in place with `crtr doc edit` — never write a parallel copy beside it.
 - Current state only. Recommendations, diagnosis, target design, and narration of how the exploration proceeded all belong elsewhere; a doc that accumulates them stops being a map.
-- These are goal-scoped working artifacts, not memory. A durable reusable truth uncovered while mapping still goes through the normal memory-capture path.
+- These are goal-scoped documents owned by the node that wrote them. A durable reusable truth uncovered while mapping still goes through [[insights/capture]].

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

@@ -21,13 +21,13 @@ The destination can be an existing canonical document, an active listener, an ex
 
 ## Review one coherent principle
 
-Write a small Markdown artifact under this node's absolute context directory and submit it with `crtr human review`. Do not batch unrelated principles or ask a separate confirmation question first.
+Write the proposal as a small document with `crtr doc write` and submit it with `crtr human review new <name>`. Do not batch unrelated principles or ask a separate confirmation question first.
 
 ```markdown
 # Proposed insight: <short principle name>
 
-- **destination:** <canonical name (scope) — existing doc to rewrite, new flat doc, or link into a listener or router — with the neighbouring listing, so the placement is judgeable without a lookup>
-- **visibility:** <the gate and surfaces the doc will carry, or none, and why that reach is right>
+- **destination:** <canonical name (owner) — existing doc to rewrite, new flat doc, or link into a listener or router — with the neighbouring listing, so the placement is judgeable without a lookup>
+- **visibility:** <the delivery rules the document will carry, or none, and why that reach is right>
 - **source:** <the episode in one line, quoting the user's pivotal words>
 
 ## Proposed durable truth
@@ -42,8 +42,8 @@ The review is asynchronous. Continue unrelated work or wait dormant, but do not
 
 ## Apply only approved truth
 
-Apply direct line edits and explicit comments. If feedback requires a materially new formulation, update the open review artifact or submit a replacement review; review the revised formulation before writing it. If no candidate survives, save nothing.
+Apply direct line edits and explicit comments. If feedback requires a materially new formulation, update the open review document or submit a replacement review; review the revised formulation before writing it. If no candidate survives, save nothing.
 
-Run `crtr memory write -h` for the authoring contract, then reach only the approved destination — `crtr memory write` to create it, `crtr memory edit` to revise one that exists. A new principle is normally knowledge, and a preference only when its use is behavioral; give it no `surfaces` routing unless review approves a boot entry. Keep its body to the approved truth, any material boundary, and the concise why. Update the selected active listener or organizing router with the canonical link without duplicating the principle.
+Run `crtr doc write -h` for the writing contract, then reach only the approved destination — `crtr doc write --owner <owner>` to create it, `crtr doc edit` to revise one that exists. A new principle is normally knowledge, and a preference only when its use is behavioral; give it no delivery rule unless review approves a boot rule. Keep its body to the approved truth, any material boundary, and the concise why. Update the selected active listener or organizing router with the canonical link without duplicating the principle.
 
-Source context and agent reasoning stay only in the review artifact. Do not copy them into semantic memory or provenance frontmatter. Run `crtr memory lint` after every create or rewrite and fix every finding.
+Source context and agent reasoning stay only in the review document. Do not copy them into the principle's body or fields. Run `crtr doc lint` after every create or rewrite and fix every finding.