@letta-ai/letta-code 0.31.5 → 0.31.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@letta-ai/letta-code",
-  "version": "0.31.5",
+  "version": "0.31.6",
   "description": "Letta Code is a CLI tool for interacting with stateful Letta agents from the terminal.",
   "type": "module",
   "packageManager": "bun@1.3.10",
@@ -121,7 +121,7 @@
     "access": "public"
   },
   "dependencies": {
-    "@earendil-works/pi-ai": "0.84.3",
+    "@earendil-works/pi-ai": "^0.84.4",
     "@janhapke/sharp-electron": "0.35.3-electron.1",
     "@letta-ai/letta-client": "^1.10.2",
     "@letta-ai/trajectory": "0.2.0",

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

@@ -1,6 +1,6 @@
 {
   "src/agent/client-skills.test.ts": 1134,
-  "src/agent/memory-git.ts": 2122,
+  "src/agent/memory-git.ts": 2090,
   "src/backend/local-backend.test.ts": 2532,
   "src/backend/local/local-backend.ts": 1014,
   "src/backend/local/local-store.ts": 3459,

package/skills/managing-shared-memory/SKILL.md

@@ -7,7 +7,7 @@ description: Create and manage shared memory — git-tracked repositories hosted
 
 Shared memory is memory created independently of any single agent, designed to be dynamically attached to or detached from multiple agents. Each unit of shared memory is a **shared memory repository**: a git repository hosted on Letta Cloud, owned by your organization rather than by one agent, reachable from any environment (sandboxes, remote machines, sessions).
 
-Shared memory works exactly like your MemFS: attached repositories are real git checkouts on disk, and you read, edit, commit, and push them with ordinary git. The only differences are that each repository has its own projection root (next to your memory directory, not inside it) and its own remote origin, and other agents may be writing to it too.
+Shared memory works like your MemFS: attached repositories are real git checkouts on disk, and you read, edit, and commit with ordinary git. The harness pushes clean committed changes after each turn. Each repository has its own projection root (next to your memory directory, not inside it) and its own remote origin, and other agents may be writing to it too.
 
 Create a shared memory repository when:
 - You have context an agent should be able to access that doesn't belong in its own MemFS (input files, datasets, docs, working artifacts)
@@ -23,16 +23,15 @@ ls "$MEMORY_DIR/../"                      # attached repositories appear here by
 cat "$MEMORY_DIR/../<repo-name>/<path>"   # read like any file
 ```
 
-Edit files with your normal file tools, then commit and push with git — the mount's origin and credentials are already configured:
+Edit files with your normal file tools, then commit with git. The mount's origin and credentials are already configured:
 
 ```bash
 cd "$MEMORY_DIR/../<repo-name>"
 git add <files>
 git commit -m "describe the change"
-git push
 ```
 
-Unlike MemFS, the harness does not auto-push shared memory after turns — a commit you don't push is not visible to other agents or environments. Always push after committing.
+The harness pushes clean commits from read/write attached repositories after the turn. If a push collides with another agent's work, it pulls with rebase and retries once. Dirty files and conflicts are not changed automatically; the harness adds a reminder to the next turn instead.
 
 To pick up other agents' changes:
 
@@ -84,7 +83,7 @@ letta shared-memory history shared-notes --path docs/plan.md
 - **`sync` reports "mount path already exists and is not a git repository"** — a plain directory (usually created by hand before the mount existed) is occupying the mount path. Inspect it, salvage anything worth keeping, move or delete it, then re-run `letta shared-memory sync`.
 - **Never hand-clone the repository to another location (e.g. /tmp) to work around a broken mount** — fix the mount with `letta shared-memory sync` so every session and other agents see the same checkout.
 - **Permission denied under another agent's directory** — shared repositories mount per-agent. Only your own mount (under your agent directory) is accessible; another agent's mount of the same repository is walled off by the cross-agent guard. Run `letta shared-memory sync` to get your own mount.
-- **Push rejected (non-fast-forward)** — another agent pushed first: `git pull --rebase`, resolve any conflicts, push again.
+- **Shared-memory conflict reminder** — resolve the conflict in the named repository, finish the rebase or commit, and leave the repository clean. The harness retries the push after a future turn.
 
 ## Notes and Limits
 

package/skills/submitting-feedback/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: submitting-feedback
+description: Submits user-approved feedback about Letta Code or the current agent to the Letta team. Load when the user is upset, frustrated, dissatisfied, reports poor agent behavior, or asks to send feedback. Works with cloud-hosted and local agents. Ask before submitting unless the user already explicitly requested submission.
+---
+
+# Submitting Feedback
+
+When the user appears upset with the agent, acknowledge the problem and ask whether they want you to submit feedback to the Letta team. Do not submit merely because the user expressed frustration.
+
+If the user says yes, or directly asks you to submit feedback:
+
+1. Write a short factual message in the user's voice. Include what happened, what the user expected, and any useful error or behavior detail already present in the conversation. Do not add claims the user did not make.
+2. Submit it with:
+
+```bash
+letta feedback --message '<feedback>'
+```
+
+3. Tell the user whether submission succeeded. If it failed, report the safe CLI error and do not claim the team received it.
+
+Do not include secrets, credentials, unrelated conversation content, or private file contents. The command adds the current agent and conversation identifiers so the team can find the relevant run.