pmx-canvas 0.6.2 → 0.6.4

package/dist/types/client/canvas/FeedbackDialog.d.ts

@@ -0,0 +1,4 @@
+/** Draft only: GitHub owns authentication and the final public submission. */
+export declare function FeedbackDialog({ onClose }: {
+    onClose: () => void;
+}): import("preact/src").JSX.Element;

package/dist/types/client/canvas/auto-fit.d.ts

@@ -17,3 +17,6 @@ export declare function shouldContentFitIframeNode(node: CanvasNodeState): boole
  * capped at the iframe ceiling.
  */
 export declare function computeContentGrowHeight(node: CanvasNodeState, contentHeight: number): number | null;
+/** Keep an automatically growing card clear without moving its neighbors or
+ * changing its column. Groups and screen-pinned cards retain authored placement. */
+export declare function contentFitPosition(node: CanvasNodeState, height: number, allNodes: CanvasNodeState[]): CanvasNodeState['position'];

package/dist/types/client/nodes/use-iframe-content-height.d.ts

@@ -7,9 +7,9 @@ import type { CanvasNodeState } from '../types';
  * because growth is monotonic with a dead-band — cannot oscillate. This is the
  * fix for iframe nodes whose body scrollHeight the parent can't measure.
  *
- * The latest node is read through a ref so the effect stays mounted across the
- * grow (its deps are only id + token). Putting node.size in the deps would re-run
- * the effect on each grow and its cleanup would cancel the pending persist.
+ * Debounce before changing geometry, retaining the latest measurement during a
+ * human grab. Read current geometry at application time; persist only this node.
+ * Relocations are undoable, height-only adjustments do not fill the undo stack.
  */
 export declare function useIframeContentHeight(node: CanvasNodeState, iframeRef: {
     current: HTMLIFrameElement | null;

package/dist/types/client/state/human-store.d.ts

@@ -6,6 +6,7 @@ export declare const otherHumans: import("@preact/signals-core").ReadonlySignal<
 /** Nodes a human took over mid-edit → that human's name, shown as the yield pill for a moment. */
 export declare const yieldedNodes: import("@preact/signals-core").Signal<Map<string, string>>;
 export declare function applyHumanSnapshot(snapshot: Partial<HumanPresenceSnapshot> | null | undefined): void;
+export declare const grabbingNodeId: import("@preact/signals-core").Signal<string | null>;
 /** Report the pointer in world coordinates (throttled); null when it leaves the canvas. */
 export declare function reportHumanCursor(cursor: {
     x: number;

package/dist/types/json-render/catalog.d.ts

@@ -449,6 +449,26 @@ export declare const allComponentDefinitions: {
             readonly showLabels: true;
         };
     };
+    Card: {
+        slots: string[];
+        description: string;
+        props: z.ZodObject<{
+            title: z.ZodNullable<z.ZodString>;
+            description: z.ZodNullable<z.ZodString>;
+            maxWidth: z.ZodNullable<z.ZodEnum<{
+                sm: "sm";
+                md: "md";
+                lg: "lg";
+                full: "full";
+            }>>;
+            centered: z.ZodNullable<z.ZodBoolean>;
+            className: z.ZodNullable<z.ZodString>;
+        }, z.core.$strip>;
+        example: {
+            title: string;
+            description: string;
+        };
+    };
     Badge: {
         props: z.ZodObject<{
             text: z.ZodString;
@@ -491,26 +511,6 @@ export declare const allComponentDefinitions: {
         };
         events: string[];
     };
-    Card: {
-        props: z.ZodObject<{
-            title: z.ZodNullable<z.ZodString>;
-            description: z.ZodNullable<z.ZodString>;
-            maxWidth: z.ZodNullable<z.ZodEnum<{
-                sm: "sm";
-                md: "md";
-                lg: "lg";
-                full: "full";
-            }>>;
-            centered: z.ZodNullable<z.ZodBoolean>;
-            className: z.ZodNullable<z.ZodString>;
-        }, z.core.$strip>;
-        slots: string[];
-        description: string;
-        example: {
-            title: string;
-            description: string;
-        };
-    };
     Stack: {
         props: z.ZodObject<{
             direction: z.ZodNullable<z.ZodEnum<{

package/dist/types/json-render/schema.d.ts

@@ -1,11 +1,31 @@
 export declare const schema: import("@json-render/core").Schema<{
     spec: import("@json-render/core").SchemaType<"object", {
         root: import("@json-render/core").SchemaType<"string", unknown>;
+        state: {
+            optional: true;
+            kind: "record";
+            inner?: import("@json-render/core").SchemaType<"any", unknown> | undefined;
+        };
         elements: import("@json-render/core").SchemaType<"record", import("@json-render/core").SchemaType<"object", {
             type: import("@json-render/core").SchemaType<"ref", string>;
             props: import("@json-render/core").SchemaType<"propsOf", string>;
             children: import("@json-render/core").SchemaType<"array", import("@json-render/core").SchemaType<"string", unknown>>;
             visible: import("@json-render/core").SchemaType<"any", unknown>;
+            repeat: {
+                optional: true;
+                kind: "any";
+                inner?: unknown;
+            };
+            watch: {
+                optional: true;
+                kind: "record";
+                inner?: import("@json-render/core").SchemaType<"any", unknown> | undefined;
+            };
+            slots: {
+                optional: true;
+                kind: "record";
+                inner?: import("@json-render/core").SchemaType<"array", import("@json-render/core").SchemaType<"string", unknown>> | undefined;
+            };
             on: import("@json-render/core").SchemaType<"any", unknown>;
         }>>;
     }>;
@@ -25,11 +45,31 @@ export declare const schema: import("@json-render/core").Schema<{
 export declare const elementTreeSchema: import("@json-render/core").Schema<{
     spec: import("@json-render/core").SchemaType<"object", {
         root: import("@json-render/core").SchemaType<"string", unknown>;
+        state: {
+            optional: true;
+            kind: "record";
+            inner?: import("@json-render/core").SchemaType<"any", unknown> | undefined;
+        };
         elements: import("@json-render/core").SchemaType<"record", import("@json-render/core").SchemaType<"object", {
             type: import("@json-render/core").SchemaType<"ref", string>;
             props: import("@json-render/core").SchemaType<"propsOf", string>;
             children: import("@json-render/core").SchemaType<"array", import("@json-render/core").SchemaType<"string", unknown>>;
             visible: import("@json-render/core").SchemaType<"any", unknown>;
+            repeat: {
+                optional: true;
+                kind: "any";
+                inner?: unknown;
+            };
+            watch: {
+                optional: true;
+                kind: "record";
+                inner?: import("@json-render/core").SchemaType<"any", unknown> | undefined;
+            };
+            slots: {
+                optional: true;
+                kind: "record";
+                inner?: import("@json-render/core").SchemaType<"array", import("@json-render/core").SchemaType<"string", unknown>> | undefined;
+            };
             on: import("@json-render/core").SchemaType<"any", unknown>;
         }>>;
     }>;

package/dist/types/mcp/skills.d.ts

@@ -0,0 +1,13 @@
+import { type McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
+/** SEP-2640 methods are protocol requests, not model-facing canvas tools. */
+export declare function registerSkillExtension(server: McpServer, catalog?: {
+    skills: import("../server/bundled-skills.js").SkillEntry[];
+    files: Map<string, {
+        uri: string;
+        mimeType: string;
+    } & ({
+        text: string;
+    } | {
+        blob: string;
+    })>;
+}): void;

package/dist/types/server/bundled-skills.d.ts

@@ -16,11 +16,17 @@
  *   - `canvas://skills`          → JSON index
  *   - `canvas://skills/<name>`   → full markdown content
  */
+import { z } from 'zod';
+declare const skillFrontmatterSchema: z.ZodObject<{
+    name: z.ZodString;
+    description: z.ZodString;
+}, z.core.$loose>;
 export interface BundledSkill {
     name: string;
     description: string;
     uri: string;
     filePath: string;
+    frontmatter: z.infer<typeof skillFrontmatterSchema>;
 }
 /**
  * Resolve the packaged `skills/` directory. Walks parents from this module
@@ -32,9 +38,31 @@ export interface BundledSkill {
 export declare function findBundledSkillsRoot(): string | null;
 /**
  * Enumerate every `<name>/SKILL.md` under the bundled skills root and return
- * a compact index. Hidden directories (dotfolders) and files that don't parse
- * are skipped silently rather than throwing — missing metadata should never
- * break the MCP server's resource listing.
+ * a compact index. Invalid packaged skills fail explicitly rather than being
+ * silently omitted from the Skills extension's integrity manifest.
  */
-export declare function listBundledSkills(): BundledSkill[];
+export declare function listBundledSkills(root?: string | null): BundledSkill[];
 export declare function readBundledSkill(name: string): string | null;
+export interface SkillEntry {
+    uri: string;
+    frontmatter: BundledSkill['frontmatter'];
+    resources: Array<{
+        uri: string;
+        digest: string;
+        size: number;
+    }>;
+}
+type SkillContent = {
+    uri: string;
+    mimeType: string;
+} & ({
+    text: string;
+} | {
+    blob: string;
+});
+/** Capture immutable package bytes once per MCP process, never read caller-supplied paths. */
+export declare function createBundledSkillCatalog(root?: string | null): {
+    skills: SkillEntry[];
+    files: Map<string, SkillContent>;
+};
+export {};

package/docs/cli.md

@@ -41,11 +41,16 @@ adapter that uses the app's native follow-up channel.
   (who sent it), `$PMX_STEER_TARGET` (your consumer key, or `ALL` for a
   broadcast), and `$PMX_STEER_CREATED_AT` — so the host turn can say who
   steered, whether it was addressed, and how old it is.
-- Startup backlog is marked silently (pass `--backlog deliver` to process it).
+- By default, startup backlog is marked delivered for this consumer without running
+  the command. This acknowledgement is not evidence that work was executed. Start the
+  pump before accepting new tasks, or review queued instructions and explicitly pass
+  `--backlog=deliver` to execute them instead of skipping them.
 - A failing command is retried twice, then the pump exits non-zero and leaves
   the steer pending so a failed host injection cannot look delivered.
 - `--parent <key>` rolls the pumped agent up under an orchestrator's chip;
-  `--once` processes a single steer (useful in scripts and tests).
+  `--once` exits after one successful execution, not after skipping startup history.
+  It may therefore wait for a new steer; use `--backlog=deliver --once` when you
+  intend to execute one reviewed, already-queued instruction.
 - Survives daemon restarts; backs off against pre-0.4.9 servers that ignore
   `waitMs`.
 

package/docs/http-api.md

@@ -88,7 +88,11 @@ curl -X PATCH http://localhost:4313/api/canvas/node/node-abc123 \
 ```
 
 The title follows the new filename unless the node was renamed away from the
-old one (or the patch sets `title` explicitly).
+old one (or the patch sets `title` explicitly). Relative `path` values (including
+`data.path` in batch updates) resolve against the configured canvas workspace,
+not the daemon's working directory; the stored path is absolute. A missing or
+unreadable target fails the update without changing the node or its existing watcher
+(`400` for a direct PATCH; a failed-operation result in a batch).
 
 ```bash
 # Raw bytes for a binary file node (PDF viewer, downloads)

package/docs/mcp.md

@@ -1,7 +1,7 @@
 # MCP reference
 
 PMX Canvas ships an MCP stdio server with **22 tools** + **14 core resources**,
-plus per-skill resources at `canvas://skills/<name>`. The server emits
+plus per-skill resources at `canvas://skills/<name>` and `skill://<name>/SKILL.md`. The server emits
 `notifications/resources/updated` when canvas state changes — humans pin
 nodes in the browser, agents are notified immediately.
 
@@ -202,6 +202,40 @@ Individual bundled skills are also readable at `canvas://skills/<name>`.
 | `canvas://code-graph` | Auto-detected file dependency graph (JS/TS, Python, Go, Rust) |
 | `canvas://skills` | Index of bundled agent skills + per-skill content at `canvas://skills/<name>` |
 
+### Skills extension (SEP-2640)
+
+PMX advertises `capabilities.extensions["io.modelcontextprotocol/skills"] = {}`
+alongside the base `resources` capability. This adds protocol methods, not canvas tools:
+
+| Method | Parameters | Result |
+|--------|------------|--------|
+| `skills/list` | None or `{}` | `{ resultType: "complete", skills: [...] }` |
+| `skills/get` | `{ uri: "skill://pmx-canvas/SKILL.md" }` | `{ resultType: "complete", skill: {...} }` |
+| `resources/read` | `{ uri: "skill://pmx-canvas/references/installing-pmx-canvas.md" }` | Standard resource content |
+
+Each skill entry contains its `SKILL.md` URI, full parsed YAML `frontmatter`, and a complete
+`resources` manifest of `{ uri, digest, size }` for every file. Digests are raw-byte SHA-256
+(`sha256:<hex>`); sizes are bytes. UTF-8 files are returned as text, binary files as base64 blobs.
+Resolve relative references against the skill directory. Files are loaded by the host on demand;
+discovery does not load all instructions into model context or start a canvas daemon.
+
+The packaged catalog fits in one page, so no `nextCursor` is returned and supplied cursors are
+rejected with `-32602`. Unknown skill/file URIs also return `-32602`. Optional
+`resources/directory/read` is not advertised or implemented; manifests already enumerate files.
+PMX currently negotiates the SDK's supported base protocol (up to `2025-11-25`), so the
+`2026-07-28` list-caching fields are not emitted.
+
+The server snapshots packaged files at MCP startup. Restart the MCP process after an upgrade to
+get new instructions and manifests. Invalid frontmatter, symbolic links, non-regular files, and
+skills exceeding 512 files or 16 MiB fail catalog creation. Reads only address captured package
+files, never arbitrary workspace paths. Scripts are served as data and are never executed by these methods.
+
+Hosts must implement the extension's origin tagging, integrity verification, activation, and
+approval rules. Reading a resource does not itself activate a skill or authorize local execution.
+Automatic skill loading depends on host support; ordinary resource reads and filesystem installs
+remain available. Use `pmx-canvas skills sync` for installed local mirrors. See the
+[final specification](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/2640-skills-extension.md).
+
 ## Node interactions (capability-gated)
 
 Eligible nodes emit one normalized, validated interaction envelope

package/docs/node-types.md

@@ -137,7 +137,7 @@ with the server's transport, tool name, and arguments.
 
 `json-render` nodes turn structured JSON specs into rendered UI panels
 (dashboards, tables, forms, cards) without writing HTML. PMX Canvas ships the
-[`@json-render/*`](https://www.npmjs.com/package/@json-render/core) runtime
+[`@json-render/*`](https://www.npmjs.com/package/@json-render/core) 0.21.0 runtime
 and component catalog (core + react + shadcn).
 
 ```ts
@@ -158,6 +158,22 @@ canvas_render({
 `outline`. Older saved specs using `label` or status variants such as
 `success`/`warning` are normalized during validation.
 
+Specs preserve top-level `state` and element-level `repeat`, `watch`, and
+`slots`. Use `$bindState` with JSON Pointer paths for editable form values;
+`$state` only reads a value. Nested repeats can use `statePath: { "$item": "tasks" }`
+to iterate the current item's tasks. Watchers run after changes, not on mount.
+
+Cards keep their body in `children` and accept
+`slots: { header: ['headingId'], footer: ['actionsId'] }`. Slot IDs reference
+entries in `elements`; a custom header replaces the title and description props.
+See the bundled [json-render guide](../skills/json-render-mcp/SKILL.md)
+for a complete state-bound form with watchers and footer actions.
+
+Form edits are viewer-local, not saved into the stored spec. Reloading the iframe
+or updating its spec (including streaming patches) resets that state. Finish
+streaming before collecting input, and persist important changes through an
+explicit server interaction.
+
 Elements may carry an `on` map (`on.press`, `on.change`, …) binding events to
 actions (`{ action, params }`) — built-in actions (`setState`, `pushState`, …) or
 host-provided handlers. PMX wires AX handlers named after interaction types, so a
@@ -185,9 +201,35 @@ source + per-viewer nonce + node id) and submits it server-side; `json-render` /
 `graph` viewers are sandboxed surfaces, so caller-supplied `nodeIds` are clamped
 to the node's own id. See the [MCP reference](mcp.md#node-interactions-capability-gated).
 
+AX handlers are fire-and-forget: `onSuccess` means local dispatch completed,
+not that the server accepted the operation. Confirm acceptance through AX state
+or timeline before showing a saved state or clearing a draft. The built-in
+`validateForm` action returns without calling `onSuccess`; do not chain submission
+through that callback.
+
 Use `canvas_render { action: "describe-schema" }` / `canvas_render { action:
 "validate" }` to introspect the component catalog before building a spec.
 
+### Automatic sizing of authored iframe cards
+
+HTML (except presentation decks), Mermaid, JSON-render, graph, and web-artifact
+cards can grow as their rendered content changes. This changes node geometry;
+**Fit view** only changes the camera. Height measurements include title-bar and
+body padding, grow only up to 1400px, and never change the width. Content beyond
+that limit may still scroll; this is not a general shrink-to-content action.
+
+Fitting waits for local or remote human grabs to end. A growing ungrouped,
+screen-unpinned card moves downward if needed to leave a 24px gap from neighboring
+cards, without moving those neighbors. A relocation records one undo step for
+both size and position; height-only adjustments do not add undo entries.
+Grouped or screen-pinned cards retain their positions. Collapsed cards and cards
+marked `strictSize` or `userResized` are not automatically resized. Hosted MCP
+apps and webpage viewers do not use this authored-content fitting behavior.
+
+Read the settled node geometry after mounting rather than treating requested
+dimensions as final. Prefer targeted node reads or the CLI's projected layout
+fields over fetching full content merely to check spacing.
+
 ## HTML nodes
 
 `html` nodes render a normal self-contained HTML/JS document in a sandboxed iframe.

package/docs/product-context-vision-2026-09.md

@@ -1,6 +1,6 @@
 # Vision extension: boards, personal wiki, and workspace context
 
-**Status:** Proposed for discussion, not an implementation commitment.
+**Status:** Proposed for discussion, not an implementation commitment. **Superseded in part, 2026-09-23:** the maintainer decided that boards are the wiki and that the destination is "share this board" ([vision, move 0 and Part 3](product-vision-2026-09.md); reasoning in the [review](product-vision-review-2026-09.md#design-sketch-boards-are-the-wiki)). The separate entity and revision store, the personal wiki as its own surface, and working-versus-confirmed machinery are not planned; boards, cards and the journal play those roles. Still in force: the publication and audience rules and the threat-model corrections, which apply when sharing reaches a second writer (Part 3), and the validation experiment, run on linked boards instead of a wiki.
 **Date:** 2026-09-06
 **Companions:** [Product review](product-review-2026-09.md), [product vision](product-vision-2026-09.md).
 **Request:** Review the existing vision and explore hosted users building their own wiki by describing their work, with their boards contributing context, and cross-cutting organizational context shared within a workspace. Reuse the logic of the personal/context-frame projects inside pmx-canvas's own store rather than depend on an external wiki.
@@ -10,9 +10,11 @@
 
 **Work visually with your agents, build understanding as you go, and bring the right knowledge into whatever comes next.**
 
-pmx-canvas is for **planning, discovery, analysis, and coordination with agents**. This is its intended purpose, not merely an initial audience experiment. Boards are the working surface; personal knowledge and deliberately shared workspace knowledge provide continuity across them through one underlying knowledge model.
+**The board is the human's extended memory and the agent's working memory.** It is a place for the human to do knowledge work, not just prepare context for an agent: research, analysis, dashboards, discovery, planning, coordination, and starting or orchestrating coding and other work. These are examples of its broad purpose, not a closed list. People can use the board to think and work directly, with agents contributing on the same surface.
 
-- **Shape the work together.** Arrange, connect, pin, and annotate to express relationships and relevance that shape what agents read and help steer what they do next. Agents bring questions, proposals, and results back onto the same surface. Spatial layout provides context; not every move or camera gesture expresses intent.
+As the work develops, sources, notes, questions, charts, plans, decisions, and outputs accumulate and connect on the board. They contribute to a memory graph and maintained wiki that support both human recall and agent context across tasks. Relevant prior knowledge can then return to a board as material for further work. The board, graph, and wiki are connected views and uses of this knowledge—not three competing sources of truth or three separate filing chores.
+
+- **Do and shape the work together.** Read, write, compare evidence, monitor a dashboard, develop a plan, and direct execution on the board. Arrange, connect, pin, and annotate to support human understanding as well as shape agent context. Agents bring questions, proposals, and results back onto the same surface. Spatial layout provides context; not every move or camera gesture expresses intent.
 - **Make memory useful in the next task.** Resume without re-explaining everything. Bring relevant prior learning and authorized cross-team decisions, dependencies, and conflicts into the work—not merely into a growing collection of notes.
 - **Keep context honest as work changes.** Show sources and revisions, surface known changes and conflicts, and make uncertainty and review needs visible. Help people judge what still applies; do not treat a newer timestamp as truth or silently replace confirmed knowledge.
 
@@ -50,12 +52,12 @@ The loop is bidirectional: work produces personal understanding; selected outcom
 8. **Treat hosted as more than a login screen.** Revocation, derived-content permissions, backups/restores, uploads, quotas, sandbox isolation, and operational recovery are new responsibilities. Node-level compare-and-set can be a starting conflict policy, but requires visible conflict/retry behavior; it does not settle collaborative text editing.
 9. **Use measurements as evidence, not promises.** The earlier audit describes a particular tree and machine. Current context construction already has text previews and bounded pending steering. The claimed 10,000-token saving depends on what schemas hosts actually load; on-demand help alone does not remove advertised schemas. Measure current payloads before fixing budgets. Net-negative lines are not a user-value release gate.
 
-The north star is planning, discovery, analysis, and coordination visually with agents, with useful understanding carried into the next task. Validate which spatial signals and memory workflows best serve that purpose—not whether these activities are merely an initial audience experiment. Pins, camera attention, and the time scrubber remain ideas to validate, not proven sources of value.
+The north star is doing knowledge work on a shared visual surface that extends human memory and supplies agent working memory, with understanding carried into the next task. Validate human usefulness as well as agent behavior: can a person inspect evidence, understand relationships, resume research, monitor a dashboard, or develop and direct a plan? Pins, camera attention, and the time scrubber are mechanisms to validate against that purpose, not the purpose itself.
 
 ## The user experience
 
 1. **Describe your work.** “I lead developer experience, work with these teams, and own these outcomes.” The assistant proposes a small personal home: responsibilities, initiatives, goals, people, and open questions. No mandatory taxonomy or blank-wiki setup project.
-2. **Work on named boards.** A discovery board, quarterly plan, and workshop deck remain separate and recoverable. Each board is automatically listed as a source in the owner's context, within its existing permissions.
+2. **Work on named boards.** Research, compare evidence, use dashboards, create outputs, and start, plan, or orchestrate coding and other work. Boards remain separate and recoverable. Each board is automatically listed as a source in the owner's context, within its existing permissions; the human can return to it without needing an agent to reconstruct the work.
 3. **Remember without manual filing.** After the user delegates maintenance of specified private sources, the assistant updates existing personal working pages during the task. Source links, a quiet change history, and undo replace a compulsory wiki-edit review queue. Unknowns stay unknown; generated interpretations stay labeled.
 4. **Confirm what matters.** “Keep this as my decision” confirms an exact revision with its evidence and owner. New agent changes remain working revisions, not silently renewed confirmation. Pinning still means attention, not publication.
 5. **Resume with relevant memory.** A new board retrieves labeled personal working knowledge alongside confirmed personal context and authorized workspace knowledge. For shared organizational facts, shared canon has authority; for personal preferences, the person's context applies. Conflicting or newer evidence is shown rather than overwritten.
@@ -63,11 +65,20 @@ The north star is planning, discovery, analysis, and coordination visually with
 
 Example: a PM explores options on a discovery board, accepts a decision into personal context, then publishes an appropriately sourced workspace decision. A team lead opens a planning board and receives that decision plus related shared dependencies—not the PM's private stakeholder notes or abandoned brainstorming.
 
+### Work becomes memory, and memory supports more work
+
+1. **Work on the board:** humans and agents add and use source material, relationships, live views, plans, and results.
+2. **Connect the memory:** retain source and revision links so a person or agent can follow how an observation relates to evidence, a decision, or an outcome. Not every dashboard refresh or scratch note needs a permanent wiki page.
+3. **Maintain understanding:** under the private-maintenance delegation, synthesize useful learning into existing working wiki pages. Preserve uncertainty and rejected alternatives; confirmation and wider sharing remain separate actions.
+4. **Bring it back into work:** humans browse and revisit the graph, wiki, and boards; agents receive relevant, permission-scoped working context. New work adds evidence and can revise the understanding again.
+
+The graph holds meaningful connections and provenance; the wiki presents maintained understanding; the board keeps active work spatial and usable. A board can contribute immediately as evidence and working memory without declaring all of its contents authoritative. This loop is the proposed direction, not a claim that automatic graph/wiki maintenance already ships.
+
 ## One model, distinct scopes
 
 | Surface | Responsibility | What it must not imply |
 |---|---|---|
-| Board | Spatial working material, artifacts, asks, evidence | Everything visible is accepted knowledge |
+| Board | Human work surface and extended memory; agent working memory through spatial material, artifacts, asks, and evidence | The human only curates for agents, or everything visible is accepted knowledge |
 | Personal wiki | Durable context owned by one person across boards | Workspace membership grants access |
 | Workspace context | Deliberately shared goals, decisions, ownership, dependencies | A union of everyone's private context |
 | Agent brief | Budgeted, task-specific view over authorized material | A new source of truth or permission grant |