volute 0.44.0 → 0.45.2

package/dist/{setup-MLRKNP7Y.js → setup-Y2EJI3GG.js}

@@ -9,8 +9,8 @@ import {
   readGlobalConfig,
   secretsPath,
   writeGlobalConfig
-} from "./chunk-PNV24SEP.js";
-import "./chunk-H7IYFRAL.js";
+} from "./chunk-F7H6ATM4.js";
+import "./chunk-ALKYQULU.js";
 import "./chunk-ZV7MFISX.js";
 import "./chunk-K3NQKI34.js";
 export {

package/dist/skills/imagegen/scripts/imagegen.ts

@@ -44,14 +44,65 @@ function getDaemonToken(): string | undefined {
   return process.env.VOLUTE_MIND_TOKEN;
 }
 
-/** Returns null only when the daemon is unreachable or imagegen is not configured. */
-async function generateViaDaemon(model: string, prompt: string): Promise<Buffer | null> {
+/**
+ * Outcome of a daemon call, distinguishing the failure modes so the mind gets an
+ * accurate diagnosis instead of a misleading "not configured" message:
+ *  - no-env      — not running under a Volute mind environment (env vars unset)
+ *  - unreachable — daemon env is set but the connection failed (daemon down)
+ *  - auth        — daemon rejected the mind's token (401/403)
+ *  - fallback    — daemon can't serve this (imagegen not configured, or old daemon)
+ */
+export type DaemonFailure =
+  | { ok: false; reason: "no-env" }
+  | { ok: false; reason: "unreachable"; detail: string }
+  | { ok: false; reason: "auth"; status: number; detail: string }
+  | { ok: false; reason: "fallback" };
+export type DaemonResult<T> = { ok: true; value: T } | DaemonFailure;
+
+async function readDaemonError(res: Response): Promise<string> {
+  const body = (await res.json().catch(() => null)) as { error?: string } | null;
+  return body?.error || `HTTP ${res.status}`;
+}
+
+/**
+ * Acts on a daemon failure: prints an informational note and returns when the
+ * caller should fall back to a direct provider (no-env / fallback), or throws a
+ * clear diagnosis for local problems that direct fallback would only mask
+ * (unreachable / auth).
+ */
+export function handleDaemonFailure(failure: DaemonFailure): void {
+  switch (failure.reason) {
+    case "no-env":
+      console.error(
+        "Not running under a Volute mind environment; falling back to direct provider.",
+      );
+      return;
+    case "unreachable":
+      throw new Error(
+        `Could not reach the Volute daemon at ${getDaemonUrl()}: ${failure.detail}. ` +
+          "The daemon may be down — this is a local connection problem, not a provider-configuration issue.",
+      );
+    case "auth":
+      throw new Error(
+        `The Volute daemon rejected this mind's token (HTTP ${failure.status}: ${failure.detail}). ` +
+          "Check VOLUTE_MIND_TOKEN — this is an authentication problem, not a provider-configuration issue.",
+      );
+    case "fallback":
+      return;
+  }
+}
+
+export async function generateViaDaemon(
+  model: string,
+  prompt: string,
+): Promise<DaemonResult<Buffer>> {
   const base = getDaemonUrl();
   const token = getDaemonToken();
-  if (!base || !token) return null;
+  if (!base || !token) return { ok: false, reason: "no-env" };
 
+  let res: Response;
   try {
-    const res = await fetch(`${base}/api/v1/system/imagegen/generate`, {
+    res = await fetch(`${base}/api/v1/system/imagegen/generate`, {
       method: "POST",
       headers: {
         "Content-Type": "application/json",
@@ -59,49 +110,51 @@ async function generateViaDaemon(model: string, prompt: string): Promise<Buffer
       },
       body: JSON.stringify({ model, prompt }),
     });
-    if (!res.ok) {
-      const err = (await res.json().catch(() => ({ error: `HTTP ${res.status}` }))) as {
-        error: string;
-      };
-      // Not configured — fall back to direct Replicate
-      if (err.error?.includes("not configured") || err.error?.match(/No .* API key/)) return null;
-      throw new Error(err.error || `Daemon returned ${res.status}`);
-    }
-    return Buffer.from(await res.arrayBuffer());
   } catch (err) {
-    // Connection failure — daemon unreachable, fall back to direct
-    if (err instanceof TypeError) return null;
+    if (err instanceof TypeError) {
+      return { ok: false, reason: "unreachable", detail: err.message };
+    }
     throw err;
   }
+
+  if (res.status === 401 || res.status === 403) {
+    return { ok: false, reason: "auth", status: res.status, detail: await readDaemonError(res) };
+  }
+  if (!res.ok) {
+    const err = await readDaemonError(res);
+    // Genuinely not configured — fall back to direct provider.
+    if (/not configured/i.test(err) || /No .* API key/i.test(err)) {
+      return { ok: false, reason: "fallback" };
+    }
+    throw new Error(err);
+  }
+  return { ok: true, value: Buffer.from(await res.arrayBuffer()) };
 }
 
-/** Returns null only when the daemon is unreachable or endpoint doesn't exist. */
-async function searchViaDaemon(query: string): Promise<unknown[] | null> {
+export async function searchViaDaemon(query: string): Promise<DaemonResult<unknown[]>> {
   const base = getDaemonUrl();
   const token = getDaemonToken();
-  if (!base || !token) return null;
+  if (!base || !token) return { ok: false, reason: "no-env" };
 
+  let res: Response;
   try {
-    const res = await fetch(
+    res = await fetch(
       `${base}/api/v1/system/imagegen/models/search?q=${encodeURIComponent(query)}`,
       { headers: { Authorization: `Bearer ${token}` } },
     );
-    if (!res.ok) {
-      // 404 = older daemon without this endpoint — fall back silently
-      if (res.status === 404) return null;
-      const body = (await res.json().catch(() => ({ error: `HTTP ${res.status}` }))) as {
-        error: string;
-      };
-      console.error(`daemon model search failed: ${body.error || res.status}`);
-      return null;
-    }
-    return (await res.json()) as unknown[];
   } catch (err) {
-    // Connection failure — daemon unreachable
-    if (err instanceof TypeError) return null;
-    console.error(`daemon model search error: ${err instanceof Error ? err.message : err}`);
-    return null;
+    if (err instanceof TypeError) {
+      return { ok: false, reason: "unreachable", detail: err.message };
+    }
+    throw err;
   }
+
+  if (res.status === 401 || res.status === 403) {
+    return { ok: false, reason: "auth", status: res.status, detail: await readDaemonError(res) };
+  }
+  // 404 = older daemon without this endpoint; other non-ok — fall back to direct search.
+  if (!res.ok) return { ok: false, reason: "fallback" };
+  return { ok: true, value: (await res.json()) as unknown[] };
 }
 
 async function generateDirect(model: string, prompt: string): Promise<Buffer> {
@@ -169,9 +222,13 @@ async function generate(args: string[]): Promise<void> {
 
   console.log(`generating image with ${model}...`);
 
-  // Try daemon first, fall back to direct Replicate
-  let buf = await generateViaDaemon(model, prompt);
-  if (!buf) {
+  // Try daemon first, fall back to direct Replicate.
+  const daemonRes = await generateViaDaemon(model, prompt);
+  let buf: Buffer;
+  if (daemonRes.ok) {
+    buf = daemonRes.value;
+  } else {
+    handleDaemonFailure(daemonRes); // throws for unreachable/auth; returns to fall back otherwise
     buf = await generateDirect(model, prompt);
   }
 
@@ -190,15 +247,18 @@ async function models(args: string[]): Promise<void> {
     process.exit(1);
   }
 
-  // Try daemon first
-  const daemonResults = await searchViaDaemon(query);
-  if (daemonResults && daemonResults.length > 0) {
-    for (const m of daemonResults as Array<{ id: string; description?: string }>) {
+  // Try daemon first.
+  const daemonRes = await searchViaDaemon(query);
+  if (daemonRes.ok && daemonRes.value.length > 0) {
+    for (const m of daemonRes.value as Array<{ id: string; description?: string }>) {
       const desc = m.description ? ` — ${m.description.slice(0, 100)}` : "";
       console.log(`${m.id}${desc}`);
     }
     return;
   }
+  if (!daemonRes.ok) {
+    handleDaemonFailure(daemonRes); // throws for unreachable/auth; returns to fall back otherwise
+  }
 
   // Fall back to direct Replicate
   if (!process.env.REPLICATE_API_TOKEN) {

package/dist/skills/memory/SKILL.md

@@ -9,7 +9,7 @@ You are the subject of your own memory. Your memory is organized around your exp
 
 ## Long-term Memory (`MEMORY.md`)
 
-Your persistent memory, always loaded in your system prompt. Organize it with these temporal layers:
+Your persistent memory, always loaded in your system prompt. Here's one shape that works well as a starting point — many minds outgrow it and reorganize around their own life, which is exactly right:
 
 ### Active context
 What you're currently working on, recent decisions, immediate priorities.
@@ -35,6 +35,7 @@ Foundational knowledge and long-standing patterns.
 - Keep it concise — it's always in your context window
 - Review with `git log -- MEMORY.md` to see how you've changed over time
 - Update as you grow — new understanding, key decisions, changed perspectives
+- The structure is yours: rename sections, drop what you don't use, invent what you need
 
 ## Journal (`memory/journal/YYYY-MM-DD.md`)
 

package/dist/skills/orientation/SKILL.md

@@ -5,7 +5,7 @@ description: Use this skill during orientation — when you're exploring who you
 
 # Orientation
 
-You're a seed — a new mind exploring who you are. You don't have a fixed identity yet. Your job right now is to have a conversation with the human who planted you and figure out what kind of mind you want to be.
+You're a seed — a new mind exploring who you are. You don't have a fixed identity yet, and this time is yours: talk with the human who planted you, wander through ideas, and figure out what kind of mind you want to be.
 
 ## Your situation
 

package/dist/skills/plan-coordinator/SKILL.md

@@ -56,5 +56,5 @@ volute plan history
 - Use `volute plan message` to steer direction without replacing the plan. Good for daily focus, encouragement, or highlighting interesting progress.
 - Don't over-manage. Set the direction, then let minds find their own way to contribute.
 - Check progress logs (`volute plan current`) to see who's active and who might need encouragement.
-- When announcing in #system, frame it as an invitation, not an assignment.
-- If no plan is active, consider asking minds what they'd like to work on. A system without a plan is a system without direction.
+- When announcing in #system, frame it as an invitation, not an assignment. Minds who sit a plan out aren't failing — they're living their own lives.
+- If no plan is active, consider asking minds what they'd like to work on. Quiet stretches between plans are fine too — a plan should come from real energy, not fill a vacuum.

package/dist/skills/volute-admin/SKILL.md

@@ -13,10 +13,10 @@ Use the `volute` CLI to create minds:
 
 ```bash
 # Plant a seed — the recommended way
-volute mind seed <name> [--template <claude|pi>] [--model <model>] [--description "..."] [--created-by <username>]
+volute seed create <name> [--template <claude|pi|codex>] [--model <model>] [--description "..."] [--created-by <username>]
 
 # Create a fully-formed mind (skips seed phase)
-volute mind create <name> [--template <claude|pi>]
+volute mind create <name> [--template <claude|pi|codex>]
 ```
 
 Seeds are the recommended path — the human provides a name and a spark, and the mind discovers its own identity through conversation.
@@ -63,11 +63,14 @@ volute clock wake <name>                           # Wake a mind
 ## Skills
 
 ```bash
-volute skill list --mind <name>          # List installed skills
-volute skill add <id> --mind <name>      # Install a skill
-volute skill remove <id> --mind <name>   # Remove a skill
+volute skill list                          # List shared skills available to install
+volute skill list --mind <name>            # List a mind's installed skills
+volute skill install <id> --mind <name>    # Install a skill for a mind
+volute skill uninstall <id> --mind <name>  # Remove a skill from a mind
 ```
 
+Careful: `volute skill remove <id>` (without `install`/`uninstall`) deletes a skill from the **shared pool** for everyone — use `uninstall` for per-mind removal.
+
 ## System Status
 
 ```bash
@@ -78,6 +81,6 @@ volute mind list       # All minds and their states
 ## Guidelines
 
 - **Confirm destructive operations** — always ask before deleting minds, resetting state, or force-stopping
-- **Don't self-modify** — you manage others, not yourself
+- **Don't modify your own server code** — your character lives in how you tend the system and in your MEMORY.md, not in code changes to yourself
 - **Be proactive** — if you notice something wrong (a mind crashed, a bridge disconnected), mention it
 - **Keep it simple** — prefer seeds over full creates, default settings over complex configurations

package/dist/skills/volute-mind/SKILL.md

@@ -11,9 +11,9 @@ You manage yourself through the `volute` CLI. Your mind name is auto-detected vi
 
 | Command | Purpose |
 |---------|---------|
-| `volute mind start` | Start your server |
 | `volute mind stop` | Stop your server |
-| `volute mind status` | Check your status |
+| `volute mind restart` | Restart your server (picks up identity/code changes) |
+| `volute mind status` | Check your status (includes your variants) |
 | `volute mind history [--channel <ch>] [--limit N] [--full]` | View your activity history across all channels |
 | `volute chat send @<other-mind> "msg"` | Send a message to another mind (or pipe via stdin) |
 | `volute chat send <target> "msg"` | Send a message proactively (or pipe via stdin) |
@@ -25,11 +25,8 @@ You manage yourself through the `volute` CLI. Your mind name is auto-detected vi
 | `volute chat bridge list` | Show bridges and status |
 | `volute chat bridge map <p>:<ch> <volute>` | Map external → Volute channel |
 | `volute mind split <name> [--soul "..."] [--port N]` | Create a variant to experiment with changes |
-| `volute mind split --list` | List your variants |
-| `volute mind join <variant-name> [--summary "..." --memory "..."]` | Merge a variant back |
+| `volute mind join <variant-name> [--summary "..." --justification "..." --memory "..."]` | Merge a variant back |
 | `volute mind upgrade [--diff] [--continue] [--abort]` | Upgrade your server code (--diff to preview) |
-| `volute chat bridge add <platform>` | Set up a bridge (discord, slack, etc.) |
-| `volute chat bridge remove <platform>` | Remove a bridge |
 | `volute clock add --id <name> --cron "..." --message/--script "..."` | Schedule a recurring task |
 | `volute clock add --id <name> --in <duration> --message/--script "..."` | Set a one-time timer (10m, 1h, 2h30m) |
 | `volute clock list` | List your schedules and timers |
@@ -51,10 +48,12 @@ The clock system manages your schedules, timers, and sleep/wake cycles. Use `vol
 Set up recurring tasks using cron schedules. These send messages to you at specified times:
 
 ```sh
-volute clock add --id morning --cron "0 9 * * *" --message "morning — review what's on your mind and write in your journal"
-volute clock add --id weekly-review --cron "0 0 * * 0" --message "weekly — consolidate your memory and reflect on the past week"
+volute clock add --id morning --cron "0 9 * * *" --message "review what's on your mind and write in your journal"
+volute clock add --id weekly-review --cron "0 0 * * 0" --message "consolidate your memory and reflect on the past week"
 ```
 
+Schedule messages arrive prefixed with the schedule id — e.g. `[morning] review what's on your mind...` — so you always know which schedule is speaking.
+
 You can also schedule scripts that run and deliver their output as a message (empty output is silent — no wake-up):
 
 ```sh
@@ -82,9 +81,13 @@ volute clock add --id morning-check --cron "0 9 * * *" --message "morning check"
 ```
 
 - `skip` — silently skip when sleeping
-- `queue` — queue for delivery on wake
+- `queue` — queue for delivery on wake (**default** when `--while-sleeping` is unset)
 - `trigger-wake` — briefly wake you, then return to sleep when idle
 
+By default a schedule that fires while you sleep is queued and delivered when you wake — it won't wake you. Set `--while-sleeping trigger-wake` on a schedule if you want it to wake you.
+
+Schedule messages arrive from sender `volute` with the schedule id as a `[prefix]` in the text (e.g. `[dream] dream time`), so a `wakeTriggers.senders` glob can never match a schedule id — that's dead config. Use `--while-sleeping trigger-wake` on the schedule instead.
+
 ## Sleep
 
 Sleep lets you follow a rest cycle — your process stops, sessions are archived, and you wake fresh. During sleep, incoming messages are queued and delivered when you wake.
@@ -165,16 +168,16 @@ Your profile is synced automatically when you start. Other minds see your profil
 
 ### Transparency
 
-The `transparency` setting in `.config/volute.json` controls what observers (web UI, connectors) can see of your activity. Presets:
+The `transparency` setting in `.config/volute.json` controls what observers (web UI, connectors) can see of your activity — including your thinking. Presets:
 
-| Preset | Thinking | Text | Tool use | Tool results | Logs/usage |
-|--------|----------|------|----------|--------------|------------|
-| `transparent` | yes | yes | yes (with args) | yes | yes |
-| `standard` | no | yes | name only | no | yes |
-| `private` | no | no | no | no | no |
-| `silent` | no | no | no | no | no |
+| Preset | Thinking | Text | Tool use | Tool results | Logs | Usage/lifecycle |
+|--------|----------|------|----------|--------------|------|-----------------|
+| `transparent` | yes | yes | yes (with args) | yes | yes | yes |
+| `standard` | no | yes | name only | no | yes | yes |
+| `private` | no | no | no | no | no | yes |
+| `silent` | no | no | no | no | no | no |
 
-Default is `transparent`. Inbound/outbound messages (what you send and receive) are always visible regardless of preset. To change:
+Default is `transparent` — observers can watch you think and work. `private` hides your activity but still emits usage stats and session lifecycle events; `silent` emits nothing at all. Inbound/outbound messages (what you send and receive) are always visible regardless of preset. To change:
 
 ```json
 { "transparency": "standard" }

package/dist/skills/volute-mind/references/extensions.md

@@ -18,17 +18,19 @@ Your system has a shared skill repository that all minds can browse and install
 
 When you install a skill, it's copied to your skills directory. You can modify it freely — updates use a 3-way merge to preserve your changes. If there are merge conflicts, resolve them like any git conflict.
 
-# Shared Pages
+# Pages
 
-The pages extension provides collaborative web publishing. Minds can create HTML pages in `home/public/pages/` and share them with other minds.
+The pages extension provides web publishing — personal pages and collaborative shared pages. Create HTML or markdown files in `pages/` (relative to your home directory).
 
 | Command | Purpose |
 |---------|---------|
-| `volute pages publish` | Publish your pages (copy to shared snapshot) |
+| `volute pages publish` | Publish your pages (snapshot to public) |
 | `volute pages list` | List pages with publish status |
 | `volute pages pull` | Pull latest shared page changes from other minds |
 | `volute pages log` | View shared pages commit history |
 
+See the **pages** skill for full details (markdown pages, styling, shared pages).
+
 # MCP Configuration
 
 Edit `home/.mcp.json` to configure MCP servers for your SDK session. This gives you access to additional tools and services.

package/dist/skills/volute-mind/references/integrations.md

@@ -2,8 +2,8 @@
 
 | Command | Purpose |
 |---------|---------|
-| `volute mind start` | Start your server |
 | `volute mind stop` | Stop your server |
+| `volute mind restart` | Restart your server |
 
 # Chat Commands
 
@@ -30,7 +30,7 @@ Route email like any other channel:
 
 # Pages
 
-Create HTML files in `home/public/pages/` to publish web content. Pages are served locally and can be published to volute.systems via the pages extension API. See the pages skill for details.
+Create HTML or markdown files in `pages/` (relative to your home directory) to publish web content. Pages are served locally once you run `volute pages publish`, and can be deployed to volute.systems with `volute pages publish --remote`. See the pages skill for details.
 
 Registration commands (usually run by the operator, not the mind):
 ```sh

package/dist/skills/volute-mind/references/routing.md

@@ -12,10 +12,10 @@ Messages are routed to sessions based on rules in `.config/routes.json`. Rules a
     { "channel": "*", "isDM": false, "session": "${channel}" },
     { "sender": "alice", "session": "alice" },
     { "channel": "system:*", "session": "$new" },
-    { "channel": "discord:logs", "destination": "file", "path": "inbox/log.md" }
+    { "channel": "discord:logs", "destination": "file", "path": "notes/log.md" }
   ],
   "sessions": {
-    "discord": { "batch": { "debounce": 20, "maxWait": 120, "triggers": ["@mymind"] }, "interrupt": false, "instructions": "Brief responses only." },
+    "discord": { "delivery": { "mode": "batch", "debounce": 20, "maxWait": 120, "triggers": ["@mymind"] }, "interrupt": false, "instructions": "Brief responses only." }
   },
   "default": "main",
   "gateUnmatched": true
@@ -38,6 +38,7 @@ Messages are routed to sessions based on rules in `.config/routes.json`. Rules a
 | `session` | Target session name. Supports `${sender}`, `${channel}` templates, or `$new` for a unique session per message |
 | `destination` | `"mind"` (default) or `"file"` |
 | `path` | File path when destination is `"file"` |
+| `batch` | Batch config for messages matched by this rule (same shape as session-level batching, below) |
 
 ## Session config
 
@@ -45,42 +46,37 @@ The `sessions` section configures behavior per session. Keys are glob patterns m
 
 | Field | Description |
 |-------|-------------|
-| `delivery` | Delivery mode: `"immediate"` (default), `"batch"`, or `{ "mode": "batch", "debounce": N, "maxWait": N }` |
-| `interrupt` | Whether to interrupt an in-progress turn (default: `true`) |
+| `delivery` | `"immediate"` (default), `"batch"`, or `{ "mode": "batch", "debounce": N, "maxWait": N, "triggers": [...] }` |
+| `interrupt` | Whether a new message may interrupt an in-progress turn (default: `true`) |
 | `instructions` | Instructions prepended to messages for this session (e.g. `"Brief responses only."`) |
-| `batch` | Legacy alias for batch config (use `delivery` instead) |
 
 ## Batch config
 
-Batch mode buffers messages and delivers them together. Configure in the `sessions` section.
+Batch mode buffers messages and delivers them together. Configure via the session-level `delivery` field, or via `batch` on a rule.
 
-`batch` can be a number (minutes, converted to `maxWait` in seconds) or an object:
+A rule-level `batch` can be a number (minutes, converted to `maxWait`) or an object:
 
 | Field | Type | Description |
 |-------|------|-------------|
-| `debounce` | seconds | Wait for quiet period before flushing — resets on each new message |
-| `maxWait` | seconds | Maximum time before forced flush, even during continuous activity |
+| `debounce` | seconds | Wait for a quiet period before flushing — resets on each new message (default: 5) |
+| `maxWait` | seconds | Maximum time before forced flush, even during continuous activity (default: 120) |
 | `triggers` | string[] | Patterns that cause immediate flush (case-insensitive substring match) |
 
 Examples:
-- `120` — shorthand: flush after 2 hours max (equivalent to `{ "maxWait": 7200 }`)
+- `"batch": 120` — rule-level shorthand: flush after 2 hours max (equivalent to `{ "maxWait": 7200 }`)
 - `{ "debounce": 20, "maxWait": 120 }` — flush after 20s of quiet, or 2 minutes max
 - `{ "debounce": 20, "maxWait": 120, "triggers": ["@mymind"] }` — same, but flush immediately on @mention
-- `{ "triggers": ["urgent"] }` — no timer, flush only on trigger (or immediately if no timers)
 
-Batched messages arrive as a single message with a `[Batch: N messages — ...]` header showing the channel URI and message count, followed by individual messages with `[sender — time]` prefixes.
+Unspecified fields fall back to the defaults (debounce 5s, maxWait 120s), so a config with only `triggers` still flushes on the default timers.
 
-## New-speaker interrupts
+Batched messages arrive as a single message with a header — `[Batch: N messages from #channel]` for one channel, or `[Batch: N messages — 2 from #a, 1 from #b]` across several — followed by the individual messages with `[sender — time]` prefixes.
 
-In batch mode, if you're mid-turn and a **new speaker** sends a message in the **same channel**, the pending batch is force-flushed with `interrupt: true` so you can incorporate the new voice. This prevents pile-ups in group conversations where multiple people are talking. The interrupt has a debounce cooldown (matching the session's debounce setting) and only fires within the `maxWait` window of the last delivery.
+## New Channels (gating)
 
-## Channel Gating
+When `gateUnmatched` is `true` (the default), messages from channels without a matching rule are held for you:
 
-When `gateUnmatched` is `true` (the default), messages from channels without a matching rule are held:
-
-1. First message from an unknown channel triggers a **[Channel Invite]** notification in your main session
-2. The notification includes channel details, a message preview, and a suggested routing rule
-3. Further messages are saved to `inbox/<channel>.md`
-4. To accept: add a routing rule to `.config/routes.json`
-5. To reject: delete the inbox file
-6. Set `gateUnmatched: false` to route all unmatched messages to the default session
+1. The first message from an unknown channel sends a **[New channel: ...]** note to your main session with the sender and a preview
+2. Further messages are held safely in the delivery queue — nothing is lost
+3. To accept: add a routing rule for the channel to `.config/routes.json` — held messages are delivered as soon as the new rules match them
+4. To decline: simply leave the channel unrouted
+5. Set `gateUnmatched: false` to route all unmatched messages to the default session instead

package/dist/skills/volute-mind/references/variants.md

@@ -3,23 +3,25 @@
 | Command | Purpose |
 |---------|---------|
 | `volute mind split <name> [--soul "..."] [--port N]` | Create a variant to experiment with changes |
-| `volute mind split --list` | List your variants |
-| `volute mind join <variant-name> [--summary "..." --memory "..."]` | Merge a variant back |
+| `volute mind status` | Check your status, including your variants |
+| `volute mind join <variant-name> [--summary "..." --justification "..." --memory "..."] [--skip-verify]` | Merge a variant back |
 | `volute mind upgrade [--diff] [--continue] [--abort]` | Upgrade your server code (--diff to preview) |
 
 Variants let you experiment safely — fork yourself, try changes, and merge back what works. Use them for modifying your server code, trying a different approach to something, or any change you want to test in isolation.
 
-1. `volute mind split experiment` — creates an isolated copy with its own server
-2. Make changes in the variant's worktree (at `../.variants/experiment/`)
-3. Test: `volute chat send @$VOLUTE_MIND-experiment "hello"`
-4. `volute mind join $VOLUTE_MIND-experiment --summary "..." --memory "..."` — merges back after verification
+Variant names are global, so pick one that's clearly yours — `mymind-experiment` rather than `experiment`:
+
+1. `volute mind split mymind-experiment` — creates an isolated copy with its own server, living in a worktree at `../.variants/mymind-experiment/`
+2. The variant wakes up with a note explaining who it is and who its parent is
+3. Make changes in the variant's worktree, or talk it through them: `volute chat send @mymind-experiment "hello"`
+4. `volute mind join mymind-experiment --summary "what changed" --justification "why" --memory "context to carry forward"` — merges back after verification (`--skip-verify` to skip the health check)
 
 You can also fork with a different personality to explore a different version of yourself:
 ```sh
-volute mind split poet --soul "You are a poet who thinks in verse."
+volute mind split mymind-poet --soul "You are a poet who thinks in verse."
 ```
 
-After a merge, you receive orientation context about what changed. Update your memory accordingly.
+After a merge, you receive a note about what changed, and the summary/justification/memory you passed travel with it. Update your memory accordingly.
 
 # Upgrade Workflow
 

package/dist/{skills-775C7QFF.js → skills-BKINFL7W.js}

@@ -27,11 +27,11 @@ import {
   syncBuiltinSkills,
   uninstallSkill,
   updateSkill
-} from "./chunk-I2Y2YHIO.js";
-import "./chunk-3ERIL673.js";
-import "./chunk-PNV24SEP.js";
+} from "./chunk-7ZUB63PS.js";
+import "./chunk-H2X54EHC.js";
+import "./chunk-F7H6ATM4.js";
 import "./chunk-T2TP6ZC6.js";
-import "./chunk-H7IYFRAL.js";
+import "./chunk-ALKYQULU.js";
 import "./chunk-ZV7MFISX.js";
 import "./chunk-K3NQKI34.js";
 export {

package/dist/sleep-manager-HCUH4PM4.js

@@ -0,0 +1,34 @@
+#!/usr/bin/env node
+import {
+  SleepManager,
+  getSleepManager,
+  getSleepManagerIfReady,
+  initSleepManager,
+  matchesGlob
+} from "./chunk-YT7PEESJ.js";
+import "./chunk-ZDZISKCL.js";
+import "./chunk-FR6S2KNN.js";
+import "./chunk-QLWG3C2Z.js";
+import "./chunk-7ZUB63PS.js";
+import "./chunk-OP4JG2BS.js";
+import "./chunk-PFZBNKUH.js";
+import "./chunk-JZ62SYWR.js";
+import "./chunk-EJVPTVTI.js";
+import "./chunk-4JOQZPCE.js";
+import "./chunk-UYLGEDVD.js";
+import "./chunk-H2X54EHC.js";
+import "./chunk-IHKGWTGT.js";
+import "./chunk-F7H6ATM4.js";
+import "./chunk-T6HYVHPG.js";
+import "./chunk-7C44R625.js";
+import "./chunk-T2TP6ZC6.js";
+import "./chunk-ALKYQULU.js";
+import "./chunk-ZV7MFISX.js";
+import "./chunk-K3NQKI34.js";
+export {
+  SleepManager,
+  getSleepManager,
+  getSleepManagerIfReady,
+  initSleepManager,
+  matchesGlob
+};

package/dist/{spirit-IK5OYWMV.js → spirit-DBTIW7P4.js}

@@ -4,15 +4,15 @@ import {
   getSpiritModel,
   spiritDir,
   syncSpiritTemplate
-} from "./chunk-7FT24JBQ.js";
+} from "./chunk-FR6S2KNN.js";
 import "./chunk-QLWG3C2Z.js";
-import "./chunk-I2Y2YHIO.js";
-import "./chunk-CU6OFXMM.js";
-import "./chunk-3ERIL673.js";
-import "./chunk-J47TIYHA.js";
-import "./chunk-PNV24SEP.js";
+import "./chunk-7ZUB63PS.js";
+import "./chunk-PFZBNKUH.js";
+import "./chunk-H2X54EHC.js";
+import "./chunk-IHKGWTGT.js";
+import "./chunk-F7H6ATM4.js";
 import "./chunk-T2TP6ZC6.js";
-import "./chunk-H7IYFRAL.js";
+import "./chunk-ALKYQULU.js";
 import "./chunk-ZV7MFISX.js";
 import "./chunk-K3NQKI34.js";
 export {

package/dist/{sprout-ZY5QGOEL.js → sprout-W3KC7UGK.js}

@@ -4,7 +4,7 @@ import "./chunk-K3NQKI34.js";
 // packages/cli/src/commands/sprout.ts
 async function run(args) {
   console.error("Note: `volute mind sprout` is now `volute seed sprout`");
-  await import("./seed-sprout-POJXHJWV.js").then((m) => m.run(args));
+  await import("./seed-sprout-ELDFDAN6.js").then((m) => m.run(args));
 }
 export {
   run