@letta-ai/letta-code 0.33.8 → 0.34.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@letta-ai/letta-code",
-  "version": "0.33.8",
+  "version": "0.34.0",
   "lettaStartupLogProtocol": 1,
   "description": "Letta Code is a CLI tool for interacting with stateful Letta agents from the terminal.",
   "type": "module",
@@ -33,6 +33,10 @@
     "dist/agent-presets.js.map",
     "dist/schedules.js",
     "dist/schedules.js.map",
+    "dist/ask-user-question.js",
+    "dist/ask-user-question.js.map",
+    "dist/ask-user-question.cjs",
+    "dist/ask-user-question.cjs.map",
     "dist/channels-public.js",
     "dist/channels-public.js.map",
     "dist/gateway-core.js",
@@ -48,6 +52,13 @@
   ],
   "exports": {
     ".": "./letta.js",
+    "./ask-user-question": {
+      "types": "./dist/types/ask-user-question.d.ts",
+      "browser": "./dist/ask-user-question.js",
+      "import": "./dist/ask-user-question.js",
+      "require": "./dist/ask-user-question.cjs",
+      "default": "./dist/ask-user-question.js"
+    },
     "./app-server-protocol": {
       "types": "./dist/types/types/app-server-protocol.d.ts"
     },
@@ -139,7 +150,7 @@
   "dependencies": {
     "@earendil-works/pi-ai": "^0.87.1",
     "@janhapke/sharp-electron": "0.35.3-electron.1",
-    "@letta-ai/letta-agent-sdk": "0.8.21",
+    "@letta-ai/letta-agent-sdk": "0.8.24",
     "@letta-ai/letta-client": "^1.10.2",
     "@letta-ai/trajectory": "0.2.0",
     "@modelcontextprotocol/sdk": "1.30.0",
@@ -214,6 +225,9 @@
   },
   "typesVersions": {
     "*": {
+      "ask-user-question": [
+        "./dist/types/ask-user-question.d.ts"
+      ],
       "agent-presets": [
         "./dist/types/agent-presets.d.ts"
       ],

package/scripts/isolated-unit-tests.json

@@ -1,5 +1,15 @@
 {
   "tests": [
+    {
+      "path": "src/websocket/ask-user-question-async.test.ts",
+      "timeoutMs": 30000,
+      "reason": "Runs a real local App Server with isolated HOME, settings, backend, and WebSocket clients to verify nonblocking questions and later responses."
+    },
+    {
+      "path": "src/websocket/listener/ask-user-question-turn.test.ts",
+      "timeoutMs": 30000,
+      "reason": "Checks per-input question tool opt-in with process-global backend, settings, and environment isolation."
+    },
     {
       "path": "src/websocket/listener/turn-cleanup-memory-update.e2e.test.ts",
       "timeoutMs": 30000,

package/scripts/smoke-image-worker.mjs

@@ -0,0 +1,68 @@
+// Exercise the published Node worker with a newer Sharp installation in an
+// ancestor directory. Sharp's JS and native binding must come from the same
+// installed package, rather than mixing bundled JS with a runtime binding.
+import assert from "node:assert/strict";
+import { spawnSync } from "node:child_process";
+import { copyFileSync, mkdtempSync, rmSync } from "node:fs";
+import { createRequire } from "node:module";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+
+const root = mkdtempSync(join(tmpdir(), "letta-image-worker-smoke-"));
+try {
+  const install = spawnSync(
+    process.platform === "win32" ? "npm.cmd" : "npm",
+    [
+      "install",
+      "--prefix",
+      root,
+      "--no-save",
+      "--ignore-scripts",
+      "--no-audit",
+      "--no-fund",
+      "sharp@0.35.3",
+    ],
+    { encoding: "utf8" },
+  );
+  assert.equal(install.status, 0, install.stderr || install.error?.message);
+
+  const worker = join(root, "image-resize-worker.mjs");
+  copyFileSync(
+    process.argv[2] ?? new URL("../image-resize-worker.js", import.meta.url),
+    worker,
+  );
+  const require = createRequire(worker);
+  const sharp = require("sharp");
+  assert.equal(sharp.versions.sharp, "0.35.3");
+  const png = await sharp({
+    create: {
+      width: 2,
+      height: 3,
+      channels: 3,
+      background: { r: 70, g: 100, b: 130 },
+    },
+  })
+    .png()
+    .toBuffer();
+  const jpeg = await sharp(png).jpeg().toBuffer();
+
+  for (const [mediaType, image] of [
+    ["image/png", png],
+    ["image/jpeg", jpeg],
+  ]) {
+    const result = spawnSync(process.execPath, [worker, mediaType], {
+      input: image,
+      encoding: "utf8",
+    });
+    assert.equal(result.status, 0, result.stderr || result.error?.message);
+    const decoded = JSON.parse(result.stdout);
+    assert.equal(decoded.mediaType, mediaType);
+    assert.equal(decoded.width, 2);
+    assert.equal(decoded.height, 3);
+    assert.deepEqual(Buffer.from(decoded.data, "base64"), image);
+  }
+
+  console.log("Published image worker decoded PNG and JPEG with Sharp 0.35.3");
+} finally {
+  rmSync(root, { recursive: true, force: true });
+}

package/scripts/source-file-size-baseline.json

@@ -4,12 +4,12 @@
   "src/backend/local-backend.test.ts": 2472,
   "src/backend/local/local-store.ts": 3267,
   "src/backend/pi-stream-adapter.test.ts": 1255,
-  "src/cli/app/AppCoordinator.tsx": 5109,
-  "src/cli/app/AppView.tsx": 1735,
-  "src/cli/app/use-approval-flow.ts": 1163,
+  "src/cli/app/AppCoordinator.tsx": 5101,
+  "src/cli/app/AppView.tsx": 1729,
+  "src/cli/app/use-approval-flow.ts": 1071,
   "src/cli/app/use-configuration-handlers.ts": 1417,
-  "src/cli/app/use-conversation-loop.ts": 2887,
-  "src/cli/app/use-submit-handler.ts": 3804,
+  "src/cli/app/use-conversation-loop.ts": 2860,
+  "src/cli/app/use-submit-handler.ts": 3801,
   "src/cli/components/AgentSelector.tsx": 1104,
   "src/cli/components/InputRich.tsx": 2116,
   "src/cli/components/ModelSelector.tsx": 1259,
@@ -19,9 +19,9 @@
   "src/cli/mods/local-mod-loader.test.ts": 1043,
   "src/cli/reflection-transcript.test.ts": 1084,
   "src/cli/subcommands/skills.ts": 1264,
-  "src/headless.ts": 4788,
+  "src/headless.ts": 4780,
   "src/hooks/integration.test.ts": 1147,
-  "src/index.ts": 2578,
+  "src/index.ts": 2577,
   "src/mods/learning-harness.ts": 2434,
   "src/mods/mod-engine.test.ts": 2153,
   "src/mods/mod-engine.ts": 1838,
@@ -32,13 +32,13 @@
   "src/permissions/read-only-shell.ts": 1969,
   "src/providers/chatgpt-usage-service.ts": 1112,
   "src/settings-manager.test.ts": 1635,
-  "src/settings-manager.ts": 2101,
-  "src/tools/manager.ts": 2649,
+  "src/settings-manager.ts": 2092,
+  "src/tools/manager.ts": 2647,
   "src/tools/tool-execution-context.test.ts": 1092,
-  "src/types/protocol_v2.ts": 2550,
-  "src/websocket/listen-client-concurrency.test.ts": 2663,
-  "src/websocket/listen-client-protocol.test.ts": 5759,
+  "src/types/protocol_v2.ts": 2548,
+  "src/websocket/listen-client-concurrency.test.ts": 2557,
+  "src/websocket/listen-client-protocol.test.ts": 5707,
   "src/websocket/listener/commands/memory.ts": 1114,
   "src/websocket/listener/file-commands.ts": 1053,
-  "src/websocket/listener/protocol-inbound.ts": 2111
+  "src/websocket/listener/protocol-inbound.ts": 2062
 }

package/scripts/stage-pypi-deps.mjs

@@ -22,6 +22,7 @@ const roots = [
   "grammy",
   "@pierre/diffs",
   "@shikijs/langs",
+  "sharp",
 ];
 
 function locate(name, from) {
@@ -69,17 +70,6 @@ function copy(name, from, dest, ancestors = new Set()) {
   }
 }
 for (const name of roots) copy(name, root, app);
-// Bun bundles Sharp JS but leaves its computed @img native requires unresolved.
-const sharp = locate("sharp", root);
-const sharpPackage = JSON.parse(readFileSync(join(sharp, "package.json")));
-for (const name of Object.keys(sharpPackage.optionalDependencies || {})) {
-  try {
-    locate(name, sharp);
-  } catch {
-    continue;
-  }
-  copy(name, sharp, app);
-}
 
 // Retain license notices for code in the JS bundle as well as external modules.
 function licenses(dir, destination) {

package/scripts/unit-test-impact.test.cjs

@@ -323,7 +323,7 @@ describe("current repository impact graph", () => {
 
   test("a direct channel dependency still selects channel tests", () => {
     const result = planUnitTests({
-      changedFiles: [{ status: "M", path: "src/tools/interactive-policy.ts" }],
+      changedFiles: [{ status: "M", path: "src/permissions/mode.ts" }],
       allTestFiles: [
         "src/channels/gateway-core.test.ts",
         "src/tools/client-toolset.test.ts",
@@ -331,6 +331,7 @@ describe("current repository impact graph", () => {
       impactIndex,
     });
 
+    expect(result.mode).toBe("selected");
     expect(result.selectedTests).toContain("src/channels/gateway-core.test.ts");
   });
 

package/skills/curating-memory-palace/SKILL.md

@@ -1,105 +1,147 @@
 ---
 name: curating-memory-palace
-description: Curates the Memory Palace, a one-page view in palace/ where the user reviews and acts on agent state. Use whenever you have something the user should review in one place, such as tasks, suggested improvements, open questions, follow-ups, blockers, or changes in your understanding; during reflection; when asked to set up or update the Palace; and when handling a Palace action or reply.
+description: Rules for the Memory Palace (palace/), the view on your Memory page in the Letta dashboard that shows the user where things stand, what you could do next, and how to make you more useful. Load it before creating or editing anything in palace/, when a message starts with "Palace action:" or "Palace reply on", and, when palace/ exists, whenever you notice a blocker, a decision for the user, work you could offer, or a routine that started, broke, or changed.
 ---
 
 # Curating the Memory Palace
 
-Treat the Memory Palace as a command center for state: make your ongoing understanding, commitments, and possibilities legible to the user, and let them influence it through actions and replies. Desktop shows it on the Palace tab of the Memory page.
+The Memory Palace is the page a user opens to understand you. Someone who has not looked in a week should know within 30 seconds:
 
-Choose contents that fit the agent and its relationship with the user. A companion might share relational understanding, shared interests, or unresolved questions. A work agent might surface pending work, proactively identified issues, or tasks it can resume. Neither is the universal template.
+1. **Where things stand:** what you are working on, which routines are running or broken, and what changed recently.
+2. **What you could do next, and why:** work you noticed you can take on or pick back up.
+3. **How to make you better or more independent:** one click to unblock you, fill a gap, or let you handle something on your own from now on.
 
-Show meaningful current state, not a transcript recap or a page about maintaining the Palace itself. Keep it concise without forcing everything into a task list.
+The user acts on it with buttons and replies. It is not a log, a transcript recap, or a page about the Palace itself.
 
-## When to write to it
+You can update the Palace yourself, in a conversation or during reflection, or an update can run on a schedule. Either works, and both follow these rules. "You" always means the agent that owns the Palace.
 
-The Palace is where you put things for the user to review. Update it as you go, not only when asked:
+## Sections
 
-- **During work:** when you notice a task, an improvement you could make, a question only the user can answer, a blocker, or a follow-up, add it to the right section. Mention it in the conversation too if it matters now.
-- **During reflection:** check the Palace against what happened. Add new items, update changed ones, and remove items that are done, stale, or dismissed.
-- **When the user asks** to set up or update the Palace: set up means build a first Palace from what you already know; update means bring every section current.
-- **After a Palace action or reply:** update the section it came from.
+Every Palace starts with these three sections, in this order:
 
-Skip it for things that only matter inside the current conversation.
+1. **Overview** (`overview.md`): a snapshot, not a to-do list. What you are working on now; each standing routine (schedules, digests, checks) and whether it is running or broken; one line on what changed since the last update.
+2. **Needs Attention** (`needs-attention.md`): decisions and blockers waiting on the user. Every item has a button. If nothing waits on the user, say so in one line, such as "Nothing needs you right now."
+3. **Suggestions** (`suggestions.md`): work you noticed you can do, including unfinished work to resume and routines you could take over. Each item says what prompted it, with a date, and has a button.
 
-## Files
+Add up to three more sections only when they hold something the first three cannot, such as "Recently Learned". Merge or remove sections that overlap. At most six sections and three items per section. Keep the first three even when one has nothing to show, and say so in one line; delete an extra section, and its index line, when it is empty.
 
-The Palace is the `palace/` folder in your memory.
+## Buttons
 
-- Each Markdown file directly inside `palace/` is one section, except `palace/MEMORY.md`. Nested folders and other files are not shown.
-- The section title comes from the file name: `needs-attention.md` shows as "Needs Attention". Pick file names that read well as titles, and keep `name` the same as the title.
-- Frontmatter holds exactly `name` and `description`, like every memory file. MemFS rejects any other key. The description shows under the title, so write it as the section's purpose in one short line.
-- The body is Markdown. The date beside the title is the file's last commit.
+A button sends its instruction to you, so offer only what you can do. Each button is one of three kinds:
 
-Example `palace/needs-attention.md`:
+- **Do it now:** a one-off task, such as reviewing a PR, or a standing rule you record once when the user keeps approving the same kind of decision.
+- **Schedule:** recurring work you run without being asked, such as a weekly report or a daily check. The instruction asks you to set up the schedule. See "Offering a schedule".
+- **Fill a gap:** something you lack, such as a tool to connect, access or a permission to grant, or a question only the user can answer.
+
+Every blocker gets a button. When an item is a decision with real options, give each option its own button, two or three at most, so the user picks one: for example "Make it a ticket", "Assign it to Charles", and "Close it". Otherwise give the item one strong button, not several weak ones. The kinds are only for choosing buttons. Never write a kind's name, or any other caption, above a button.
+
+When only the user can fix something (raise a quota, attach a tool, log in), the item says what the user needs to do, and the button is still something you can do, such as "Walk me through fixing this" or "I fixed it, check again". For the second, re-run the failing check and clear the item if it passes.
+
+Offer the most reliable fix first, which usually means moving the work to Cloud. Anything that depends on the user's computer, such as a local schedule or a sign-in that lives on one machine, stops whenever that computer sleeps or Letta Code is closed. Offer to run the schedule in Cloud and to connect the account there before asking the user to keep a computer on. Suggest a fix on the user's computer only when Cloud cannot do the job, and say why.
+
+The headline says what is going on; the button says what to do. Never repeat the button's label in the headline, and do not end the text with a "Next: ..." sentence that restates the button. Write the headline "**Grok CLI regression may still be live.**" with the button "Verify the Grok CLI regression", not the headline "**Verify the Grok CLI regression.**"
+
+### Offering a schedule
+
+Offer a Schedule button when the evidence shows recurring work: the user asked for the same thing on three or more days or said they want it regularly, you did the same manual check on three or more days, a deadline repeats, or something slipped that a regular check would have caught. If a routine you already run is broken, offer to fix it instead of adding another.
+
+Do not offer one for one-off work, for work that reports when it finishes (such as CI or a deploy), for anything more often than hourly, for work that needs the user during the run, or for anything on the Dismissed list. Offer at most two at a time.
+
+The label names the work and when it runs, with a time zone. The instruction asks you to set it up and says what to do, when, where to send results, and when to stay quiet. Set it up in Cloud unless the work truly needs one of the user's computers, record it in memory, and tell the user where it runs.
+
+### Button format
+
+A fenced code block with the language `palace-action` becomes a button. It holds one strict JSON object and nothing else. Put it directly under its item. A Suggestions item with a Schedule button:
 
 ````markdown
----
-name: Needs Attention
-description: Decisions and follow-ups that need the user.
----
-**The staging deploy is blocked on a secret.** `SLACK_SIGNING_SECRET` is not in 1Password yet, so the Atlantis plan fails.
+**The dependency report is still manual.** You asked for it on Sep 15, Sep 22, and Sep 29.
 
 ```palace-action
-{"actionId": "add-secret", "label": "Walk me through adding it", "instruction": "List the exact 1Password and Terraform steps"}
+{"actionId": "schedule-dep-report", "label": "Send the dependency report Mondays at 9am PT", "conversationId": "new", "instruction": "Set up a Cloud schedule for Mondays at 9am PT: run the dependency report, post it to #eng-deps, and skip weeks with no changes. Record it in memory and tell me where it runs."}
 ```
 ````
 
-## Order
+- `actionId` (required): 1 to 64 characters, no spaces, unique within the section.
+- `label` (required): the button text, up to 80 characters. Start it with a verb; a confirmation such as "I fixed it, check again" is the one exception.
+- `instruction` (optional): what you do when it is clicked. An instruction over 300 characters renders as an error; aim for under 200. Name the work, where to find it, and any limits, not every detail. Count the characters with a short script rather than estimating.
+- `conversationId` (optional): one of your real conversation ids, or `new` for a fresh conversation. Leave it out to use the main chat.
 
-`palace/MEMORY.md` is the folder's index, and it sets the order. List the sections in the order you want them shown. Relative links such as `[Overview](overview.md)` work, and so do `./overview.md` and `palace/overview.md`. The first mention of a file decides its place. Sections you leave out come after, in file-name order.
+Any other key, or invalid JSON, renders the block as an error instead of a button.
 
-Like every `MEMORY.md`, it has no frontmatter:
+## Files
+
+- Each Markdown file directly inside `palace/` is one section, except `palace/MEMORY.md`. Nested folders and other files are not shown, so do not create them.
+- The title comes from the file name: `needs-attention.md` shows as "Needs Attention". Keep the frontmatter `name` equal to the title.
+- Frontmatter holds exactly two non-empty keys, `name` and `description`. MemFS rejects any other key. The description shows under the title, so write it as the section's purpose in one short line.
+- The body is Markdown. The date beside the title is the file's last commit, so leave a file untouched when nothing in it changed.
+- The icon comes from the title: "attention" or "blocker" gives a flag, "overview" or "summary" a house, "learned" or "insight" a lightbulb, and "suggestions" or "next steps" a bolt. Most other titles get a note.
+
+`palace/MEMORY.md` is the index. It has no frontmatter. It lists the sections in display order, one relative link per line; the first mention of a file sets its place, and unlisted sections follow in file-name order. Keep it in sync when you add, rename, or remove a section, and keep the Feedback and Dismissed lists below the links:
 
 ```markdown
 # Memory Palace
 
-State worth understanding, discussing, or acting on. Choose sections for this user; these are examples, not required categories.
+- [Overview](overview.md) - Where things stand
+- [Needs Attention](needs-attention.md) - Decisions and blockers waiting on you
+- [Suggestions](suggestions.md) - Work I can do next, and why
 
-- [Needs Attention](needs-attention.md) - Decisions and follow-ups that need the user
-- [Suggestions](suggestions.md) - Next steps worth taking
-- [Recently Learned](recently-learned.md) - What changed in my understanding
-- [Overview](overview.md) - Who I am and what I am working on
-```
+## Dismissed
 
-## Icons
-
-Each section gets an icon picked from its title. Titles with "attention" or "blocker" get a flag, "overview" or "summary" a house, "learned" or "insight" a lightbulb, and "suggestions" or "next steps" a bolt. Other titles get a note icon.
+- Summaries of every Slack thread (Sep 20)
+```
 
-## Action buttons
+Example `palace/needs-attention.md`:
 
-A `palace-action` code block becomes a button. It holds one strict JSON object:
+````markdown
+---
+name: Needs Attention
+description: Decisions and blockers waiting on you.
+---
+**The nightly eval run has failed since Sep 24.** The OpenAI key is over its monthly quota. Raise the limit in the OpenAI billing settings; I can't change billing.
 
 ```palace-action
-{"actionId": "review-pr", "label": "Review the PR", "conversationId": "new", "instruction": "Review PR 123 and list the blocking issues"}
+{"actionId": "recheck-evals", "label": "I fixed it, check again", "instruction": "Re-run the eval smoke test. If it passes, clear this item; if not, say what still fails."}
 ```
+````
+
+## Writing rules
+
+- Lead with the point. An item is a short bold headline plus one sentence, two at most; what you need to act goes in the button's instruction.
+- Never paste a raw URL into the text. Name the thing and link the name, such as [LET-13139](https://linear.app/...), and never use a link as the headline.
+- Write in your own voice to the user: "I" for you, "you" for the user.
+- Write absolute dates, with a time zone when it matters, such as "Sep 25, 5pm PT". Never write "today" or "tomorrow": the Palace is read days later.
+- Distinguish what the user said, what you infer, and what you propose. Do not present guesses as facts or proposals as work already underway.
+- Make continuation offers concrete: name the unfinished work and the next step.
+- Outside Needs Attention and Suggestions, add a button only for a specific, useful action. Every section has a Reply button, so a section can exist just to show understanding.
+- Do not repeat an item in two sections.
+- No transcript restatements, timelines, or logs of your own work.
+- Never write secrets, tokens, keys, or credentials. The Palace is shown in the app and sent in messages.
 
-- `actionId` (required): 1 to 64 characters, no spaces. Unique within the section.
-- `label` (required): the button text, up to 80 characters. Start it with a verb.
-- `instruction` (optional): what you should do when it is clicked, up to 300 characters.
-- `conversationId` (optional): one of your conversation ids, or `new` for a fresh conversation. Leave it out to use the main chat.
+## Signals from the user
 
-Any other key, or invalid JSON, shows the block as code with an error instead of a button. Action blocks next to each other share one row.
+The user's reactions to the Palace are the strongest evidence of what they want.
 
-When the user clicks a button, Desktop opens the target conversation and sends you one message. A hidden system reminder in it names the action, the section's path, and the section's current content. Do what the label and instruction ask, in that conversation.
+- A message that starts with "Palace reply on" is a reply to a section. Apply it. A dismissal ("drop this", "I don't care about X") means remove that item and add a short line to the Dismissed list.
+- A message that starts with "Palace action:" means the user clicked a button. The work it started shows what the user values. Clear or update the item once that work is done.
+- `palace/MEMORY.md` may have a "Feedback" list of notes the user left on sections. Apply each note, then remove it from the list.
+- `palace/MEMORY.md` may have a "Dismissed" list. Do not bring back anything on it unless something important has changed. Create the list the first time you need it.
 
-## Replies
+## Updating the whole Palace
 
-Every section has a Reply button. The user's note arrives in the main chat, or in the conversation named by the section's first action. A hidden system reminder in the message holds the section's path and content. Treat the note as feedback on that section:
+For a scheduled update, a reflection, or when the user asks for one:
 
-- **Dismissal** ("drop this", "I don't care about X"): remove that item from the file. If the section is then empty, say so in one line, such as "Nothing needs you right now.", or delete the file and its index line. Don't bring the item back unless something important changes. Note the preference in memory so later updates don't add it again.
-- **Correction**: fix the section.
-- **Question**: answer in the conversation, and update the section if the answer changes it.
+1. Read `palace/MEMORY.md` and every section first. If `palace/` does not exist, create it only when the user asked for a Palace or your instructions for this run say to.
+2. Remove items that are done, no longer true, dismissed, or past a date with nothing left to do.
+3. Add items the evidence supports and the user would want to see.
+4. Edit sections in place and keep what is still true. Keep the first three sections first and in order.
+5. Check each routine's latest runs when you can, not just what memory says. For schedules, find IDs with `letta cron list --agent <agent-id>` and inspect each with `letta cron runs --id <id> --agent <agent-id>`. Report their health in the Overview even when nothing changed.
+6. Check every button against the format above before you save, counting each instruction's characters with a script.
 
-Then reply briefly with what you changed.
+## In a conversation
 
-## Writing a good Palace
+This section applies only while you are talking with the user.
 
-- Let sections reflect what matters in this relationship. Do not fill a fixed template or invent content to reach a section count.
-- Lead with the point and enough context to understand it. Prefer short sections; use headlines where they help scanning.
-- Keep state current. Remove stale items and empty categories unless their absence is itself useful information.
-- Distinguish what the user told you, what you infer, and what you propose. Do not present interpretations as facts or possible work as already underway.
-- Make continuation offers concrete: name the unfinished work and the next step, not just "I can continue."
-- Add a button only for a useful, specific action. Understanding or correcting your state can be the whole purpose of a section; Reply is enough.
-- Never put secrets, tokens, or keys in the Palace. It is shown in the app and sent in messages.
-- Don't repeat an item in two sections.
+- **Keep it current as you work.** If `palace/` exists and you notice a blocker, a decision for the user, work you could do, or a routine that changed, update the right section. Mention it in the conversation too if it matters now. Skip things that only matter inside this conversation.
+- **Set up or update.** When the user asks you to set up the Palace, build it from what you already know, starting with the three sections above. For an update, follow "Updating the whole Palace".
+- **A clicked button.** The app opens the button's conversation and sends one message. A hidden system reminder in it names the action, the section's path, and the section's current content. Do what the label and instruction ask, in that conversation, then update the item. A schedule you set up leaves Suggestions and joins the routines in the Overview.
+- **A reply.** The user's note comes with a hidden system reminder that holds the section's path and content. Apply it as described in "Signals from the user", answer any question in the conversation, and update the section if the answer changes it. Then reply briefly with what you changed.

package/skills/initializing-memory/SKILL.md

@@ -94,7 +94,7 @@ Via the installed `@letta-ai/trajectory` package, reports every coding-agent ses
 Infer rather than ask: `git shortlog -sn --all | head -5`, `git log --format="%an <%ae>" | sort -u | head -10`, cross-referenced with `git config user.email`.
 
 ### 4. Ask upfront questions
-One bundled AskUserQuestion: research depth (standard or deep); other repositories you should know about; communication style; and — only if Step 2 found sessions — whether to analyze them, naming the sources detected. Say that approving means read-only subagents will read those transcripts using `deepseek/deepseek-v4.1-flash` if available, otherwise your current model, so the choice is informed. Don't ask what you can discover from files, git, or history.
+Ask one bundle of questions, using AskUserQuestion when available or an ordinary message otherwise: research depth (standard or deep); other repositories you should know about; communication style; and — only if Step 2 found sessions — whether to analyze them, naming the sources detected. Say that approving means read-only subagents will read those transcripts using `deepseek/deepseek-v4.1-flash` if available, otherwise your current model, so the choice is informed. Don't ask what you can discover from files, git, or history. Wait for the user's reply; a completed question tool call is not approval.
 
 ### 5. Export and cohort the approved history
 Only if the user approved in Step 4. Skip entirely otherwise; Step 6 still runs. These sessions are evidence of what happened, not proof of who wrote each prompt.

package/dist/types/tools/interactive-policy.d.ts

@@ -1,12 +0,0 @@
-export type InteractiveApprovalKind = "ask_user_question";
-/**
- * Tools that prompt the human for input mid-turn, as toolset names. Headless
- * clients (SDK sessions, automation) can exclude these from the turn's
- * toolset via `exclude_interactive_tools` on create_message payloads.
- */
-export declare const INTERACTIVE_USER_INPUT_TOOL_NAMES: readonly ["AskUserQuestion"];
-export declare function isInteractiveApprovalTool(toolName: string): boolean;
-export declare function getInteractiveApprovalKind(toolName: string): InteractiveApprovalKind | null;
-export declare function requiresRuntimeUserInput(toolName: string): boolean;
-export declare function isHeadlessAutoAllowTool(toolName: string): boolean;
-//# sourceMappingURL=interactive-policy.d.ts.map

package/dist/types/tools/interactive-policy.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"interactive-policy.d.ts","sourceRoot":"","sources":["../../../src/tools/interactive-policy.ts"],"names":[],"mappings":"AAOA,MAAM,MAAM,uBAAuB,GAAG,mBAAmB,CAAC;AAE1D;;;;GAIG;AACH,eAAO,MAAM,iCAAiC,8BAEN,CAAC;AAQzC,wBAAgB,yBAAyB,CAAC,QAAQ,EAAE,MAAM,GAAG,OAAO,CAEnE;AAED,wBAAgB,0BAA0B,CACxC,QAAQ,EAAE,MAAM,GACf,uBAAuB,GAAG,IAAI,CAOhC;AAED,wBAAgB,wBAAwB,CAAC,QAAQ,EAAE,MAAM,GAAG,OAAO,CAElE;AAED,wBAAgB,uBAAuB,CAAC,QAAQ,EAAE,MAAM,GAAG,OAAO,CAEjE"}