@letta-ai/letta-code 0.33.6 → 0.33.8

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (35) hide show
  1. package/dist/agent-presets.js.map +1 -1
  2. package/dist/channels-public.js.map +1 -1
  3. package/dist/mcp-client.js +53 -11
  4. package/dist/mcp-client.js.map +3 -3
  5. package/dist/mcp-oauth.js +18545 -0
  6. package/dist/mcp-oauth.js.map +155 -0
  7. package/dist/types/agent/client-skills.d.ts.map +1 -1
  8. package/dist/types/agent/skills.d.ts +5 -0
  9. package/dist/types/agent/skills.d.ts.map +1 -1
  10. package/dist/types/backend/backend.d.ts +2 -0
  11. package/dist/types/backend/backend.d.ts.map +1 -1
  12. package/dist/types/backend/dev/fake-headless-backend.d.ts +2 -0
  13. package/dist/types/backend/dev/fake-headless-backend.d.ts.map +1 -1
  14. package/dist/types/backend/dev/pi-ollama-provider.d.ts +7 -16
  15. package/dist/types/backend/dev/pi-ollama-provider.d.ts.map +1 -1
  16. package/dist/types/constants.d.ts +1 -1
  17. package/dist/types/constants.d.ts.map +1 -1
  18. package/dist/types/experiments/manager.d.ts.map +1 -1
  19. package/dist/types/experiments/types.d.ts +1 -1
  20. package/dist/types/experiments/types.d.ts.map +1 -1
  21. package/dist/types/mcp-client.d.ts +6 -0
  22. package/dist/types/mcp-client.d.ts.map +1 -1
  23. package/dist/types/mcp-oauth-callback.d.ts +11 -0
  24. package/dist/types/mcp-oauth-callback.d.ts.map +1 -0
  25. package/dist/types/mcp-oauth-public.d.ts +55 -0
  26. package/dist/types/mcp-oauth-public.d.ts.map +1 -0
  27. package/dist/types/mcp-oauth.d.ts +56 -0
  28. package/dist/types/mcp-oauth.d.ts.map +1 -0
  29. package/dist/types/tools/toolset-catalog.d.ts +1 -1
  30. package/dist/types/types/protocol_v2.d.ts +1 -1
  31. package/dist/types/types/protocol_v2.d.ts.map +1 -1
  32. package/dist/types/utils/secrets.d.ts.map +1 -1
  33. package/letta.js +868 -237
  34. package/package.json +11 -1
  35. package/skills/curating-memory-palace/SKILL.md +105 -0
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@letta-ai/letta-code",
3
- "version": "0.33.6",
3
+ "version": "0.33.8",
4
4
  "lettaStartupLogProtocol": 1,
5
5
  "description": "Letta Code is a CLI tool for interacting with stateful Letta agents from the terminal.",
6
6
  "type": "module",
@@ -27,6 +27,8 @@
27
27
  "dist/memory-constraints.js.map",
28
28
  "dist/mcp-client.js",
29
29
  "dist/mcp-client.js.map",
30
+ "dist/mcp-oauth.js",
31
+ "dist/mcp-oauth.js.map",
30
32
  "dist/agent-presets.js",
31
33
  "dist/agent-presets.js.map",
32
34
  "dist/schedules.js",
@@ -71,6 +73,11 @@
71
73
  "import": "./dist/mcp-client.js",
72
74
  "default": "./dist/mcp-client.js"
73
75
  },
76
+ "./mcp-oauth": {
77
+ "types": "./dist/types/mcp-oauth-public.d.ts",
78
+ "import": "./dist/mcp-oauth.js",
79
+ "default": "./dist/mcp-oauth.js"
80
+ },
74
81
  "./protocol": {
75
82
  "types": "./dist/types/types/protocol.d.ts"
76
83
  },
@@ -228,6 +235,9 @@
228
235
  "mcp-client": [
229
236
  "./dist/types/mcp-client.d.ts"
230
237
  ],
238
+ "mcp-oauth": [
239
+ "./dist/types/mcp-oauth-public.d.ts"
240
+ ],
231
241
  "channels": [
232
242
  "./dist/types/channels-public.d.ts"
233
243
  ],
@@ -0,0 +1,105 @@
1
+ ---
2
+ name: curating-memory-palace
3
+ 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.
4
+ ---
5
+
6
+ # Curating the Memory Palace
7
+
8
+ 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.
9
+
10
+ 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.
11
+
12
+ 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.
13
+
14
+ ## When to write to it
15
+
16
+ The Palace is where you put things for the user to review. Update it as you go, not only when asked:
17
+
18
+ - **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.
19
+ - **During reflection:** check the Palace against what happened. Add new items, update changed ones, and remove items that are done, stale, or dismissed.
20
+ - **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.
21
+ - **After a Palace action or reply:** update the section it came from.
22
+
23
+ Skip it for things that only matter inside the current conversation.
24
+
25
+ ## Files
26
+
27
+ The Palace is the `palace/` folder in your memory.
28
+
29
+ - Each Markdown file directly inside `palace/` is one section, except `palace/MEMORY.md`. Nested folders and other files are not shown.
30
+ - 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.
31
+ - 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.
32
+ - The body is Markdown. The date beside the title is the file's last commit.
33
+
34
+ Example `palace/needs-attention.md`:
35
+
36
+ ````markdown
37
+ ---
38
+ name: Needs Attention
39
+ description: Decisions and follow-ups that need the user.
40
+ ---
41
+ **The staging deploy is blocked on a secret.** `SLACK_SIGNING_SECRET` is not in 1Password yet, so the Atlantis plan fails.
42
+
43
+ ```palace-action
44
+ {"actionId": "add-secret", "label": "Walk me through adding it", "instruction": "List the exact 1Password and Terraform steps"}
45
+ ```
46
+ ````
47
+
48
+ ## Order
49
+
50
+ `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.
51
+
52
+ Like every `MEMORY.md`, it has no frontmatter:
53
+
54
+ ```markdown
55
+ # Memory Palace
56
+
57
+ State worth understanding, discussing, or acting on. Choose sections for this user; these are examples, not required categories.
58
+
59
+ - [Needs Attention](needs-attention.md) - Decisions and follow-ups that need the user
60
+ - [Suggestions](suggestions.md) - Next steps worth taking
61
+ - [Recently Learned](recently-learned.md) - What changed in my understanding
62
+ - [Overview](overview.md) - Who I am and what I am working on
63
+ ```
64
+
65
+ ## Icons
66
+
67
+ 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.
68
+
69
+ ## Action buttons
70
+
71
+ A `palace-action` code block becomes a button. It holds one strict JSON object:
72
+
73
+ ```palace-action
74
+ {"actionId": "review-pr", "label": "Review the PR", "conversationId": "new", "instruction": "Review PR 123 and list the blocking issues"}
75
+ ```
76
+
77
+ - `actionId` (required): 1 to 64 characters, no spaces. Unique within the section.
78
+ - `label` (required): the button text, up to 80 characters. Start it with a verb.
79
+ - `instruction` (optional): what you should do when it is clicked, up to 300 characters.
80
+ - `conversationId` (optional): one of your conversation ids, or `new` for a fresh conversation. Leave it out to use the main chat.
81
+
82
+ 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.
83
+
84
+ 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.
85
+
86
+ ## Replies
87
+
88
+ 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:
89
+
90
+ - **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.
91
+ - **Correction**: fix the section.
92
+ - **Question**: answer in the conversation, and update the section if the answer changes it.
93
+
94
+ Then reply briefly with what you changed.
95
+
96
+ ## Writing a good Palace
97
+
98
+ - Let sections reflect what matters in this relationship. Do not fill a fixed template or invent content to reach a section count.
99
+ - Lead with the point and enough context to understand it. Prefer short sections; use headlines where they help scanning.
100
+ - Keep state current. Remove stale items and empty categories unless their absence is itself useful information.
101
+ - 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.
102
+ - Make continuation offers concrete: name the unfinished work and the next step, not just "I can continue."
103
+ - 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.
104
+ - Never put secrets, tokens, or keys in the Palace. It is shown in the app and sent in messages.
105
+ - Don't repeat an item in two sections.