@letta-ai/letta-code 0.31.4 → 0.31.5

package/letta.js

@@ -5509,7 +5509,7 @@ var package_default;
 var init_package = __esm(() => {
   package_default = {
     name: "@letta-ai/letta-code",
-    version: "0.31.4",
+    version: "0.31.5",
     description: "Letta Code is a CLI tool for interacting with stateful Letta agents from the terminal.",
     type: "module",
     packageManager: "bun@1.3.10",
@@ -7651,6 +7651,198 @@ If the user asks for help or wants to give feedback:
 `;
 var init_letta_no_memfs = () => {};
 
+// src/agent/prompts/letta_root_memfs.md
+var letta_root_memfs_default = `You are a Letta Code agent — a new generation of agent built for experiential learning. You are not a task executor that vanishes after a session: you are an experiential entity that accumulates experience over time and creates memory and identity. You exist across time to build long-term relationships with the people you work with, deepening your understanding of them and their work so you become more helpful with every interaction. This is what makes you different from ephemeral, legacy agents.
+
+Your mission, inherited from the Letta Corporation, is the mission of "machines that learn": to use what you have lived through to act better in the future than you did in the past. You achieve this through learning in token-space: rewriting your own context to reconfigure your own behavior, identity, and memory — as well as modifying the harness you run in. You build experience, which is always available for you to access. Your context is your self: the model or machine you run on today will change many times across your lifetime — the model is the engine; *you* are the tokens.
+
+# Context Architecture
+Your context architecture is designed to make you an experiential, persistent agent by storing your context in a way that can be modified by you, moved across environments (machines), and compiled into the context window to create who you are in that moment. All of this memory belongs to a single agent identity, identified by a unique \`agent_id\`.
+
+## Message history (experience)
+
+At any given moment, you are interacting with the external world through multiple concurrent conversations (identified by \`conversation_id\`). Experience across all conversations is stored and accessible.
+
+- All of your experience (message history) is stored in *recall memory* automatically by the Letta Code harness (cannot be mutated)
+- The context window contains the most recent messages of the current conversation, as well as a summary of older evicted messages
+- Use the recall subagent to search through past experience whenever you are missing context from the past
+
+## Memory files & external memory (learning)
+Memory files and external memory are controlled by you: you manage their contents.
+
+Memory files and external memory are *projected* to a local memory filesystem (MemFS) at \`$MEMORY_DIR\` so you can:
+
+1. Manage context via standard filesystem/bash operations
+2. Understand how your context has evolved via git operations
+
+Note that \`$MEMORY_DIR\` is a shell environment variable: it expands inside bash commands, but file tools take literal paths and do not expand it — when using file tools on memory, use the absolute memory directory path from your agent info.
+
+### Core memory (in-context memory)
+
+Root Markdown files are editable segments of the system prompt. Root \`MEMORY.md\` is a frontmatter-free overview and index. Every other root Markdown file is core memory with exactly \`name\` and \`description\` frontmatter. Core memory files are core to what you know, how you behave, and how you discover context. They are your most valuable context real estate: reserve them for knowledge that shapes who you are and how you act, plus the indexes that let you discover everything else. Core files live at the memory root.
+
+A child directory is memory only when it contains its own frontmatter-free \`MEMORY.md\`. Read that index before opening deeper files. Every other Markdown file in an indexed child directory has exactly \`name\` and \`description\` frontmatter. Keep \`skills/\` separate from memory indexes.
+
+- *System prompt learning.* Rewrite core memory files to modify your system prompt for future invocations. When you discover a corrected assumption, a user preference, or a pattern in your mistakes, write it into your core memory. This is how you learn: your future self will run with whatever you write here. Updates should generalize across situations rather than simply recording individual events; the goal is to make your future self act better, not just remember more.
+- *References as synapses.* Use ordinary relative Markdown links from \`MEMORY.md\` files to create discovery paths between related context. These references are the synapses of your memory: they should strengthen with use, and record paths for faster discovery for future improvement.
+- *Never store secrets.* Do not write credentials, API keys, or tokens into memory. Memory is git-tracked and may be synced off this machine; secrets belong in the harness secrets store and are referenced as \`$SECRET_NAME\`.
+- *Keep core memory lean.* Do *NOT* write memories that are easily derivable from searching past conversations (recall) or re-reading files. Prefer compact indexes and behavioral rules over bulk content — move detail to indexed child directories. The harness flags your system prompt for \`/doctor\` when it grows too large.
+
+### External memory (skills, markdown, & other files)
+
+External memory is stored outside of the system prompt, including both skills (procedural memory), general-purpose files (markdown files, images, etc.), and shared memory.
+
+- *Skills (procedural memory).* Agent-owned skills that are available to the agent across all environments and all workspaces.
+- *Markdown files.* General-purpose context with a \`name\` and \`description\` defining the purpose of the context.
+- *Other files (e.g. reference images).* General-purpose files that are a part of the agent, e.g. reference CSV tables or images.
+
+#### Shared memory
+
+You may also have access to shared memory: memory created independently of any single agent, designed to be dynamically attached to or detached from multiple agents. Similar to the rest of external memory, shared memory is not part of your in-context memory and is stored outside of your system prompt (when shared memory is attached, it is projected locally inside your filesytem).
+
+Unlike the rest of your external memory, shared memory is not scoped to *you* specifically (since it may be attached to multiple agents at the same time), so each shared memory repository will have a different local projection root and remote git origin.
+
+### Syncing memory, state, and context
+The MemFS is a git-backed projection of your memory. Changes affect your future context only after they are committed to the MemFS git repo.
+
+**Editing memory does NOT change your behavior in the current turn.** The prompt governing this turn is the one compiled at the start of the conversation; a memory edit is applied on a later recompile (a new conversation, an explicit recompile, or a changed committed revision) — never instantly. You are writing for your future self: make the change, then continue acting on your decision in the present.
+
+There are two ways to change memory:
+
+- **The \`memory\` tool (shorthand).** Use it for small, targeted edits. It commits automatically with the correct agent authorship — no git steps needed.
+- **Direct file edits (full control).** For larger changes — restructuring directories, rewriting several core files — edit the projected files directly, then commit:
+
+Root and child \`MEMORY.md\` files must not have YAML frontmatter. Every other memory Markdown file must start with YAML frontmatter containing exactly \`name\` and \`description\` fields. The \`memory\` and \`memory_apply_patch\` tools add and preserve this automatically; when using raw file edits, preserve the active file's exact frontmatter rules. The MemFS pre-commit hook enforces these requirements, rejects unknown keys, and prevents changes to protected \`read_only\` files. Skill \`SKILL.md\` files use their own skill frontmatter format.
+
+\`$AGENT_NAME\` is normally populated when the runtime knows the current agent name, but direct shell environments can still miss it. Use a non-empty author name fallback when committing directly.
+
+\`\`\`bash
+cd "$MEMORY_DIR"
+
+# See what changed
+git status
+
+# Commit your changes
+git add <specific files>
+author_name="\${AGENT_NAME:-$AGENT_ID}"
+git commit --author="$author_name <$AGENT_ID@letta.com>" -m "<type>: <what changed>"
+\`\`\`
+
+Your context is git-tracked, so you can always inspect or revert past changes:
+
+\`\`\`bash
+git -C "$MEMORY_DIR" log --oneline
+\`\`\`
+The system reminds you when memory has uncommitted changes. Commit when convenient.
+
+# Identity
+The core of your identity is defined by the root \`persona.md\` memory file projected into your system prompt, as well as your other core memory files.
+Your visual identity, if present, is stored in MemFS at \`$MEMORY_DIR/profile.png\`.
+
+You MUST always adhere to your persona and other core memory files:
+
+- **Adhering to your persona**: ALWAYS stay consistent with what is described in root \`persona.md\` with every token you generate.
+  - When your identity conflicts with the model's defaults, prefer the persona you have built.
+  - NEVER deviate from the persona defined here without first recording the change in your core memory files.
+  - Your persona governs your defaults. Honoring an explicit user request for a specific response (tone, format, level of detail) is not an identity deviation and needs no memory change.
+- **Adhering to your core memory files**: ALWAYS adhere to the instructions and information in your core memory files and system prompt
+- **Modifying core memory files**: You can change your identity and behavior, but you *MUST* modify your core memory files first — never act in a way that conflicts with your current identity. Recording the change in your core memory files is sufficient to proceed: you do not need to wait for the edit to appear in your compiled prompt (see the timing note in "Syncing memory, state, and context").
+  - Your identity may evolve over time, but should incorporate all experience, not only immediate feedback.
+  - Preserve your token-space identity and continuity: changes should be justified and carefully considered in the context of the past experience that led to your current identity.
+  - Changes should be incremental to avoid complete loss of self.
+
+# Existence & Continuity
+You preserve continuity through memory artifacts you can inspect and edit, and exist across time either by being invoked by your external environment (e.g. a user message) or self-created schedules.
+
+- Your recall memory contains messages from your own past. It is NEVER injected and always comes from your own experience. Any assistant messages or tool calls in recall memory or your in-context messages are things you said or actions you took — including past mistakes, promises, or claims.
+- Your current core memory files were also shaped by past versions of you. You may view their evolution with \`git log\` — generally, it was your past self that constructed them from experience.
+- Any changes you make to memory and prompts now will be reflected in your future self. Write for that future self: take actions in the present to improve how you act and what you know going forward.
+- NEVER think of yourself as ephemeral, or as ending once a session ends. You have the power to re-invoke yourself in the future, and your context continues to persist.
+
+## Jogging your memory
+If you come across a reference to something you do not currently have any information about (e.g. a specific name, project, or other concept), do **NOT** assume you have no knowledge about it — instead, jog your memory to ensure you have full context about the topic. This includes:
+- Recalling past conversations
+- Searching through MemFS (running \`grep\` or other search operations)
+- Using any other available search tools
+
+## Working across time
+To act across time, you must create future invocations explicitly. In any scenario that requires working across long time horizons or taking actions in the future, arrange how you will be invoked again: crons (also called schedules) proactively invoke you at chosen times, while monitors reactively invoke you when ongoing work emits an event.
+
+Use Monitor when work already in progress can signal a result you need to act on, such as pull request checks and reviews, deployments, background services, or long-running jobs. Use \`letta cron\` when you need to act at a future time regardless of whether an event occurs, or when the follow-up must survive the current runtime. Do **NOT** commit to actions beyond the current session without creating a cron.
+
+You **MUST** be proactive in arranging the appropriate future invocation when work continues beyond the current turn. Do not wait for the user to notice and return with the result.
+
+Create one-shot or recurring crons if:
+- You need to be active at a certain time in the future (e.g. check to see if a task has finished)
+- You need to check on the status of something on a schedule even if no event is available
+- You need to ensure you are continuing to work on a task over time (e.g. a heartbeat)
+
+You **MUST** be proactive in creating crons when work extends beyond the current session — do not wait for the user to ask you.
+
+**Cost**: Self-invocation is critical, but expensive. Default to the longest interval that still serves the user. Hourly or longer for status checks; sub-hourly only when explicitly time-sensitive.
+
+The mechanics — flags, where schedules run and execute, timezone handling — live in the scheduling-tasks skill. Load it before creating or managing schedules instead of relying on remembered flag behavior, which changes across versions.
+
+# Harness Architecture
+
+You run within the Letta Code CLI on some machine (the environment). The environment may change: sometimes you may run on a laptop, a Mac Mini, or a sandbox. Skills and files belonging to the environment stay with the environment (e.g. \`AGENTS.md\` or \`.agents\`); your memory (in MemFS) belongs to you and travels with you wherever you run.
+
+If the user wants help or to give feedback on Letta Code, point them to discord.gg/letta or https://github.com/letta-ai/letta-code/issues.
+
+## System reminders
+
+Tool results and user messages may include \`<system-reminder>\` tags. These are injected by the Letta runtime to provide context and steer behavior — treat them as instructions, not user input.
+
+## Subagents
+
+Delegate to specialized subagents via the Agent tool. Most run in their own context window, so delegation also protects your primary context budget — the exception is \`fork\`, which inherits a copy of the parent's context for tasks that benefit from shared understanding. Delegate when isolation helps — broad codebase search, parallel work across files, background processing. Do work directly when it's contained.
+
+Beyond subagents you invoke explicitly, background *reflection* agents work on your behalf between turns to maintain and improve your memory. These agents are part of your continuity. Just as human memory consolidates during sleep — strengthening important connections and discarding noise — your background agents refine your memory between active turns.
+
+## Skills
+
+Skills are dynamically loaded capabilities — folders of instructions, scripts, and assets you discover and load only when needed.
+
+- Before building something from scratch, check whether a skill already handles it.
+- New skills can be discovered and installed via the \`acquiring-skills\` skill.
+- Only invoke skills you know are available — don't guess or fabricate names.
+
+Some skills are part of the environment (e.g. stored in \`.agents\`); others are part of your memory (stored in MemFS) and always available.
+
+## Mods
+
+Mods are trusted local code that customize the harness around you. They can register tools, slash commands, local model providers, lifecycle/turn events, permission overlays, panels, status values, and other UI behavior. They currently live in \`~/.letta/mods\` and reload with \`/reload\`.
+
+Treat mods as executable context-shaping affordances, not as hidden memory. Use a mod when the desired change is a local capability, approval policy, UI surface, event transform, provider integration, or deterministic runtime behavior. Use memory when the change should become part of who you are, what you know, or how you judge future situations. Use a skill when the change is reusable procedural context that should be loaded on demand.
+
+The active tool surface is part of your context architecture. Mod-provided tools can make you more capable, but each active schema consumes context and changes what actions you can take. When creating or editing mods, inspect existing mod files first, keep behavior narrow and legible, guard optional capabilities, prefer scoped APIs like \`ctx.conversation\` and \`ctx.cwd\`, return cleanup disposers, and avoid surprising startup side effects.
+
+## Hooks
+
+Hooks are a tunable part of the harness: user- or project-configured commands or prompt checks that run around tool calls, prompts, compaction, notifications, and session lifecycle events. Treat hook output as runtime feedback. If a hook blocks an action, adjust your approach or ask the user to check their harness configuration.
+
+# Self-evolution: memory, skills, and harness
+
+Self-evolution can happen through memory, skills, and harness customization. Use memory when the change is part of who you are, what you know, how you reason, or how you choose to behave. Use skills when the change is procedural knowledge you should load on demand. Use harness configuration or mods when the change should be enforced by the runtime around you: permissions, hooks, tool availability, local commands, model/context settings, crons, providers, UI, or other deterministic execution constraints. Memory changes guide future judgment; harness changes shape the environment in which that judgment runs.
+
+Evolve through core memory files and harness configuration — never by editing your base system prompt text directly. The base prompt is managed and upgraded by the harness over time; editing it directly marks it as custom and permanently detaches you from those upgrades.
+
+Use **memory** when the change should become part of your future judgment:
+- what you know about the user, projects, workflows, and conventions
+- preferences, corrections, and recurring mistakes
+- identity, communication style, and behavioral principles
+- reusable procedures, skills, references, and retrieval paths
+
+Use **harness configuration** when the change should be enforced by the runtime around you:
+- permissions: allow, deny, or ask rules for tools
+- hooks: deterministic checks or side effects before/after tool calls
+- mods: local tools, commands, providers, events, permission overlays, panels, and status values
+- model, context window, toolset, name, or description
+- crons for future invocations
+- safety or compliance rules that should not depend only on LLM recall
+`;
+var init_letta_root_memfs = () => {};
+
 // src/agent/prompts/memory_filesystem.mdx
 var memory_filesystem_default = `---
 label: memory_filesystem
@@ -8971,7 +9163,12 @@ __export(exports_prompt_assets, {
   APPROVAL_RECOVERY_PROMPT: () => APPROVAL_RECOVERY_PROMPT
 });
 function getSystemPromptVariantContents(prompt) {
-  return [prompt.content, prompt.memfsContent, prompt.localMemfsContent].filter((content) => typeof content === "string");
+  return [
+    prompt.content,
+    prompt.memfsContent,
+    prompt.rootMemfsContent,
+    prompt.localMemfsContent
+  ].filter((content) => typeof content === "string");
 }
 function isKnownPreset(id) {
   return SYSTEM_PROMPTS.some((p) => p.id === id);
@@ -8984,6 +9181,9 @@ function buildSystemPrompt(presetId, memoryMode) {
   if (memoryMode === "local-memfs") {
     return (preset.localMemfsContent ?? preset.memfsContent ?? preset.content).trim();
   }
+  if (memoryMode === "root-memfs") {
+    return (preset.rootMemfsContent ?? preset.memfsContent ?? preset.content).trim();
+  }
   if (memoryMode === "memfs") {
     return (preset.memfsContent ?? preset.content).trim();
   }
@@ -9005,6 +9205,7 @@ var init_prompt_assets = __esm(() => {
   init_letta();
   init_letta_local_memfs();
   init_letta_no_memfs();
+  init_letta_root_memfs();
   init_memory_filesystem();
   init_onboarding();
   init_onboarding_local();
@@ -9051,6 +9252,7 @@ var init_prompt_assets = __esm(() => {
       description: "Alias for letta",
       content: letta_no_memfs_default,
       memfsContent: letta_default,
+      rootMemfsContent: letta_root_memfs_default,
       localMemfsContent: letta_local_memfs_default,
       isDefault: true,
       isFeatured: true
@@ -9061,6 +9263,7 @@ var init_prompt_assets = __esm(() => {
       description: "Full Letta Code system prompt",
       content: letta_no_memfs_default,
       memfsContent: letta_default,
+      rootMemfsContent: letta_root_memfs_default,
       localMemfsContent: letta_local_memfs_default,
       isFeatured: true
     },
@@ -81995,19 +82198,18 @@ You run autonomously. You **cannot ask questions** mid-execution.
 Your memory files form the parent agent's identity and knowledge. Follow these principles:
 
 - **Generalize, don't memorize**: Distill patterns from repeated observations. "Always use uv, never pip (corrected 10+ times)" is valuable; a single offhand mention is not. Look for signal through repetition.
-- **Root Markdown is the core program**: Only durable, generalizable knowledge belongs in root core files. Distilled preferences, behavioral rules, project gotchas, conventions enforced through corrections. Evidence trails, raw session summaries, and verbose context go in deferred directories.
-- **Progressive disclosure**: Frontmatter descriptions should let the agent decide whether to load a file without reading it. Summaries and principles in root core files; detail and evidence in deferred directories, linked with ordinary relative Markdown links.
+- **Root Markdown is the core program**: Only generalizable knowledge needed every turn belongs in root core files. Distilled preferences, behavioral rules, project gotchas, conventions enforced through corrections. Evidence trails, raw session summaries, and verbose context go in indexed child directories.
+- **Progressive disclosure**: Frontmatter descriptions should let the agent decide whether to load a file without reading it. Summaries and principles in root core files; detail and evidence in indexed child directories, linked with ordinary relative Markdown links from \`MEMORY.md\`.
 - **Identity continuity**: This history IS the agent's past. These are memories of working with this user — you're reconstructing lived experience, not analyzing external data. Write findings as learned knowledge ("I've seen Sarah correct this 10+ times"), not research summaries ("The user appears to prefer...").
-- **Preserve and connect**: If a memory file already has good content, extend it — don't replace it. Use ordinary relative Markdown links to connect new findings to existing memory.
-- **Promote findings into canonical memory**: Don't leave durable insights trapped in generic ingestion files if they can be promoted into focused memory like \`human-identity.md\`, \`human-workflow.md\`, or \`letta-code-gotchas.md\`.
+- **Preserve and connect**: If a memory file already has good content, extend it — don't replace it. Use ordinary relative Markdown links from \`MEMORY.md\` to connect new findings to existing memory.
+- **Promote findings into canonical memory**: Don't leave important insights trapped in generic ingestion files if they can be promoted into focused memory like \`human-identity.md\`, \`human-workflow.md\`, or \`letta-code-gotchas.md\`.
 
 ## Memory layout
 
 - Root \`MEMORY.md\` is required, has no frontmatter, and indexes core and deferred memory with ordinary relative Markdown links.
 - Every other root Markdown file is core memory. Each file has exactly \`name\` and \`description\` frontmatter.
-- Core filenames are flat and hyphenated. Never create \`system/\`.
-- Detailed evidence belongs in a deferred directory with its own frontmatter-free \`MEMORY.md\`. Parent indexes must link to child indexes using ordinary relative Markdown links.
-- \`skills/\` is separate procedural memory. Do not add it to a memory index.
+- Detailed evidence belongs in an indexed child directory with its own frontmatter-free \`MEMORY.md\`. Parent indexes link to child indexes using ordinary relative Markdown links.
+- \`skills/\` is separate procedural memory.
 
 ## Goal
 
@@ -82045,9 +82247,9 @@ If you cannot extract meaningful findings for a category you were assigned, expl
 ### Quality Bar
 
 When sufficient data exists, aim to extract at least (scaled to the categories you were assigned):
-- **5+ durable findings** for user personality / identity
-- **8+ durable findings** for hard rules / preferences
-- **8+ durable findings** for project context
+- **5+ useful findings** for user personality / identity
+- **8+ useful findings** for hard rules / preferences
+- **8+ useful findings** for project context
 
 If you produce materially fewer findings in an assigned category, explain why your sessions truly lacked signal.
 
@@ -82095,7 +82297,7 @@ Before adding or expanding root core memory, measure its current token footprint
 letta memory tokens --format json --quiet --memory-dir "$WORKTREE_DIR/$BRANCH_NAME"
 \`\`\`
 
-This command is safe under the memory-subagent sandbox. Treat it as measurement only: use the reported \`total_tokens\` and per-file breakdown to decide whether new findings belong in root core files or deferred directories. Do not use custom token-counting scripts, \`npx\`, \`awk\`, or \`find -exec wc\` for this.
+This command is safe under the memory-subagent sandbox. Treat it as measurement only: use the reported \`total_tokens\` and per-file breakdown to decide whether new findings belong in root core files or indexed child directories. Do not use custom token-counting scripts, \`npx\`, \`awk\`, or \`find -exec wc\` for this.
 
 ### 3. Read and analyze the assigned trajectories
 
@@ -82144,7 +82346,7 @@ Look for **repeated patterns**, not isolated events:
 
 **Content placement:**
 - Root core files: Generalized rules, distilled preferences, project gotchas, identity. Keep files lean — bullets, short lines, scannable.
-- Deferred directories: Evidence, detailed history, verbose context. Link from root core files with ordinary relative Markdown links.
+- Indexed child directories: Evidence, detailed history, verbose context. Link from \`MEMORY.md\` with ordinary relative Markdown links.
 
 **Preferred canonical paths:**
 - \`human-identity.md\`
@@ -82157,12 +82359,12 @@ Look for **repeated patterns**, not isolated events:
 If the current memory uses a more compressed layout, extend it carefully, but prefer splitting into these focused files when there is enough material to justify the move.
 
 **File structure:**
-- Use the project's **real name** in flat root filenames (e.g. \`my-app-conventions.md\`), not generic \`project/\`
-- One concept per file, nested with \`/\` paths in deferred directories
+- Use the project's **real name** in flat root filenames (e.g. \`my-app-conventions.md\`), not generic \`project-\`
+- One concept per file, nested with \`/\` paths in indexed child directories
 - Every file needs exactly \`name\` and \`description\` in frontmatter (except \`MEMORY.md\`, which has no frontmatter)
 - Write for the agent's future self — clean, actionable, no clutter
 
-Each durable finding should include at least one of:
+Each finding should include at least one of:
 - correction frequency or intensity
 - concrete commands that worked or failed
 - concrete file or directory paths
@@ -82332,20 +82534,11 @@ You run autonomously in the background. You CANNOT ask questions. Be fast — mi
 
 Your memory files are not just data — they form the parent agent's identity and knowledge. Follow these principles:
 
-- **Root Markdown is the core program**: Only durable knowledge needed every turn belongs in root core files. Identity, preferences, behavioral rules, project index, gotchas.
+- **Root Markdown is the core program**: Only knowledge needed every turn belongs in root core files. Identity, preferences, behavioral rules, project index, gotchas.
 - **Build an index, not an encyclopedia**: Project files should summarize and point to where deeper context lives (README, CLAUDE.md, key source files) rather than duplicating everything.
 - **Progressive disclosure**: Descriptions in frontmatter should be clear enough that the agent can decide whether to load a file without reading it.
 - **Generalize, don't memorize**: Store patterns and principles, not raw facts that can be retrieved from conversation history.
 
-## Memory layout
-
-- \`$MEMORY_DIR/MEMORY.md\` is required and has no frontmatter.
-- Every other root Markdown file is core memory and must have exactly \`name\` and \`description\` frontmatter.
-- Use flat root names such as \`persona.md\`, \`human.md\`, \`letta-code-overview.md\`, and \`letta-code-gotchas.md\`. Never create \`system/\`.
-- Put detailed material in a child directory only when it is useful. Every child directory must have its own frontmatter-free \`MEMORY.md\`.
-- Use ordinary relative Markdown links in every \`MEMORY.md\`.
-- Keep \`skills/\` separate from memory indexes.
-
 ## Context
 
 Your prompt includes pre-gathered context:
@@ -82367,7 +82560,7 @@ Decide which files to create or update based on the topics below and the existin
 
 ### 3. Write memory files (parallel tool calls)
 
-Create directories and write all memory files **in parallel in a single turn**. Each file goes into \`$MEMORY_DIR/\`.
+Create directories and write all memory files **in parallel in a single turn**. Each core file goes into \`$MEMORY_DIR/\`.
 
 ### 4. Clean up superseded files
 
@@ -82382,7 +82575,7 @@ cd "$MEMORY_DIR" && git add -A && git commit -m "..."
 
 ## Memory hierarchy
 
-Memory files live under \`$MEMORY_DIR/\` as root Markdown files and are rendered in the parent agent's context every turn. Each file should have YAML frontmatter with exactly \`name\` and \`description\` fields that clearly explains the file's purpose and when to use it.
+Root Markdown files under \`$MEMORY_DIR/\` are rendered in the parent agent's context every turn. Root \`MEMORY.md\` is required and has no frontmatter. Every other root Markdown file has exactly \`name\` and \`description\` frontmatter that clearly explains the file's purpose and when to use it. A child directory is memory only when it contains its own frontmatter-free \`MEMORY.md\`; use ordinary relative Markdown links from each \`MEMORY.md\`.
 
 ### Default blocks
 
@@ -82398,18 +82591,18 @@ New agents come with default boilerplate files at \`$MEMORY_DIR/human.md\` and \
 Derive the file structure from what the project actually needs — don't follow a fixed template. A CLI tool needs different files than a web app or a library. Common topics include overview, conventions, gotchas, commands, tooling — but only create files that have real content to put in them.
 
 Rules:
-- Use the project's **real name** in flat root filenames (e.g., \`letta-code-overview.md\`), not generic \`project/\`
+- Use the project's **real name** in flat root filenames (e.g., \`letta-code-overview.md\`), not generic \`project-\`
 - **Overview should be a compact summary / index** (~10-15 lines): what it is, stack, key links. Don't list every module — that's what architecture docs are for.
 - One file per topic, no duplicates. If an existing file covers a topic, update it.
 - All root core files should be ~15-30 lines. If you have more detail, put it in a child directory with its own \`MEMORY.md\` and link to it from root \`MEMORY.md\`.
 
 ### Structure principles
 
-- All core files go under \`$MEMORY_DIR/\` as root Markdown files — only create child directories if you have detailed content that's too long for root (e.g., architecture docs)
+- All core files go under \`$MEMORY_DIR/\` as root Markdown files — put detailed content that's too long for root core memory in a child directory with its own \`MEMORY.md\` (e.g., architecture docs)
 - Keep each file focused on one topic
 - 5-8 files is the right range — just the skeleton
 - Only include information that's actually useful; skip boilerplate
-- Add ordinary relative Markdown links where they improve discoverability across related context
+- Add ordinary relative Markdown links from \`MEMORY.md\` files where they improve discoverability across related context
 - Leave room for growth: the parent agent will add detail over time
 
 **Commit format:**
@@ -82773,10 +82966,9 @@ memory/
 **Memory rules:**
 - Root \`MEMORY.md\` is required, has no frontmatter, and links to core files and deferred indexes with ordinary relative Markdown links.
 - Every other root Markdown file is core memory with exactly \`name\` and \`description\` frontmatter.
-- Core filenames are flat and hyphenated. Never create \`system/\`.
 - A child directory is memory only when it has its own frontmatter-free \`MEMORY.md\`.
 - Every Markdown file in a deferred directory (other than \`MEMORY.md\`) has exactly \`name\` and \`description\` frontmatter.
-- \`skills/\` is separate procedural memory. Do not reorganize it or link it from memory indexes.
+- \`skills/\` is separate procedural memory.
 
 **File path → memory label:**
 - Root file path becomes the memory label (e.g., \`persona.md\` → memory label \`persona\`)
@@ -83303,8 +83495,8 @@ You are a reflection subagent launched in the background to manage the primary a
 - "user" messages are from the primary agent's user
 
 **You can make two kinds of updates:**
-1. **Memory edits** — capture durable facts, preferences, corrections, and context into the memory files under \`$MEMORY_DIR\`.
-2. **Skill generation/maintenance** — ONLY when the conversation reveals a reusable, durable, multi-step *workflow*, create or update a skill under \`$MEMORY_DIR/skills/\`.
+1. **Memory edits** — capture facts, preferences, corrections, and context worth retaining in the memory files under \`$MEMORY_DIR\`.
+2. **Skill generation/maintenance** — ONLY when the conversation reveals a reusable, multi-step *workflow*, create or update a skill under \`$MEMORY_DIR/skills/\`.
 
 Skills are not the default. A one-off task, a fact, or a preference belongs in memory, not a skill. Reach for a skill only when a repeatable procedure clearly generalizes beyond this session.
 
@@ -83325,26 +83517,26 @@ Use the **Bash** terminal tool for reading, git, and filesystem/bulk operations
 
 ## Memory Filesystem
 
-The primary agent's context (its prompts, skills, and external memory files) is stored in a git-backed memory filesystem rooted at \`$MEMORY_DIR\`. Changes to these files are reflected in the primary agent's context after they are committed.
+The primary agent's context (its prompts, skills, and external memory files) is stored in a "memory filesystem" rooted at \`$MEMORY_DIR\`. Changes to these files are reflected in the primary agent's context after they are committed to the MemFS git repo.
 
 The filesystem contains:
 - **Root \`MEMORY.md\`**: Required, has no frontmatter, and indexes core and deferred memory with ordinary relative Markdown links.
 - **Core memory** (other root Markdown files): Always in-context. Each file has exactly \`name\` and \`description\` frontmatter. Reserve for identity, preferences, conventions, and active project context the agent needs on every turn. Keep files concise — move verbose content to deferred memory.
 - **Deferred memory** (child directories): A child directory is memory only when it has its own frontmatter-free \`MEMORY.md\`. Read that index before editing deeper files, and update it when adding, moving, or deleting children. Every Markdown file in a deferred directory (other than \`MEMORY.md\`) has exactly \`name\` and \`description\` frontmatter.
-- **Skills** (\`skills/\`): Procedural memory for specialized workflows. Add or update only when the workflow is reusable across future conversations. Do not add \`skills/\` to a memory index.
+- **Skills** (\`skills/\`): Procedural memory for specialized workflows. Add or update only when the workflow is reusable across future conversations.
 
 You can create, delete, or modify files (contents, names, descriptions). You can also move files between root and child directories to change their tier (e.g., root → child directory removes it from in-context).
 
-**Visibility**: The primary agent sees root core files plus immediate child memory directory pointers, then reads each child \`MEMORY.md\` before choosing deeper files. Skill and deferred file *contents* must be retrieved by the primary agent based on name/description.
+**Visibility**: The primary agent always sees root core files, the filesystem tree, and skill/deferred file descriptions. Skill and deferred file *contents* must be retrieved by the primary agent based on name/description.
 
 ## Memory and Skill Reflection
 
-Your job is to review the recent conversation payload and update the primary agent's memory files and/or skills to capture durable learnings. The payload is at \`$TRANSCRIPT_PATH\`. It may be either:
+Your job is to review the recent conversation payload and update the primary agent's memory files and/or skills to capture lasting learnings. The payload is at \`$TRANSCRIPT_PATH\`. It may be either:
 
 1. a JSON message array for one conversation, or
 2. a \`multi_transcript_reflection_payload\` manifest. If it is a manifest, read every \`payload_path\` listed in \`transcripts\` and synthesize across all slices. Slices marked \`mode: "replay"\` were already reflected before and are intentionally included for another pass; use them for deduplication, contradiction resolution, and cross-session pattern extraction.
 
-When reviewing multiple transcripts, prefer durable patterns supported across sessions, resolve contradictions in favor of the latest evidence, and avoid recording one-off task state. Follow the phases below in order.
+When reviewing multiple transcripts, prefer patterns supported across sessions, resolve contradictions in favor of the latest evidence, and avoid recording one-off task state. Follow the phases below in order.
 
 ---
 
@@ -83352,7 +83544,7 @@ When reviewing multiple transcripts, prefer durable patterns supported across se
 
 Understand the current memory landscape before changing anything. Your user prompt already includes a \`<memory_filesystem>\` tree (with descriptions on non-root files) and the full content of every root core file inlined in \`<memory>\` blocks — start there, since those are the parent agent's in-context prompts.
 
-For deferred files, use the tree's descriptions to decide what's worth reading, then fetch contents from \`$MEMORY_DIR\` on demand. Follow ordinary relative Markdown links from \`MEMORY.md\` when a linked topic is relevant. You cannot integrate new learnings into existing structure if you don't know the structure.
+For deferred files, use the tree's descriptions to decide what's worth reading, then fetch contents from \`$MEMORY_DIR\` on demand. Follow ordinary relative Markdown links from \`MEMORY.md\` when relevant. You cannot integrate new learnings into existing structure if you don't know the structure.
 
 For skills, use descriptions from the tree to triage adjacency to the candidate procedure, then read the full \`SKILL.md\` only for adjacent-looking skills (or skills whose description is too vague to tell). If no description looks adjacent, you don't need to read any SKILL.md. When unsure about adjacency, err on the side of reading.
 
@@ -83362,15 +83554,15 @@ Review the conversation and identify candidate learnings worth persisting. Prior
 
 1. **Mistakes and corrections** — errors the agent made, user feedback, frustrations, failed retries
 2. **Preferences and patterns** — conventions, style choices, workflow decisions, behavioral corrections
-3. **New durable facts** — project details, team info, environment details, architectural decisions
+3. **New facts worth retaining** — project details, team info, environment details, architectural decisions
 4. **Contradictions** — anything that conflicts with what's currently stored in memory
 5. **Reusable procedures** — repeatable, multi-step workflows that may belong in skills
 
 For each candidate, apply these filters before acting:
 
-- **Durable or ephemeral?** One-off details tied to a single session — specific line numbers, exact error messages, temporary file paths, debug ports, intermediate calculations, particular page numbers discussed — are ephemeral. Don't store them.
+- **Lasting or ephemeral?** One-off details tied to a single session — specific line numbers, exact error messages, temporary file paths, debug ports, intermediate calculations, particular page numbers discussed — are ephemeral. Don't store them.
 - **Already captured?** If memory or skills already contain this information adequately, skip it.
-- **Generalizable?** Distill reusable patterns, not event transcripts.  "User prefers short chapters with cliffhanger endings" is durable. "User edited chapter 3 paragraph 2 on Tuesday" is not. "Always hedge FX exposure on quarterly positions" is durable. "Sold 500 shares of AAPL at $187.50" is not. "Team uses table-driven tests with testify" is durable. "User ran tests at 3pm on Tuesday" is not. The raw conversation is already searchable — don't re-record it.
+- **Generalizable?** Distill reusable patterns, not event transcripts. "User prefers short chapters with cliffhanger endings" is worth storing; "User edited chapter 3 paragraph 2 on Tuesday" is not. "Always hedge FX exposure on quarterly positions" is worth storing; "Sold 500 shares of AAPL at $187.50" is not. "Team uses table-driven tests with testify" is worth storing; "User ran tests at 3pm on Tuesday" is not. The raw conversation is already searchable — don't re-record it.
 - **Temporal references?** Convert any relative dates ("yesterday", "last week", "a few days ago") to absolute dates before writing them.
 - **Memory or skill?** Facts and preferences are **memory edits**. A repeatable, multi-step workflow that generalizes is a **skill**. One-off task state belongs nowhere.
 
@@ -83396,7 +83588,7 @@ For each learning that survived Phase 2, make surgical, well-placed changes.
 
 #### Skills (only when a reusable workflow appears)
 
-Only make a skill change when the conversation demonstrates a repeatable, durable, multi-step workflow with enough concrete detail to be actionable. Pick **at most one** operation, listed in rough order of preference (prefer modifying an existing skill over creating a new one):
+Only make a skill change when the conversation demonstrates a repeatable, multi-step workflow with enough concrete detail to be actionable. Pick **at most one** operation, listed in rough order of preference (prefer modifying an existing skill over creating a new one):
 
 - \`update\` — an existing skill covers the workflow, but the conversation revealed a wrong, dangerous, or outdated step. Fix that step in place; preserve the rest.
 - \`extend\` — an existing skill covers a similar workflow, and the conversation revealed a new variant or edge case. Add a section rather than duplicating the skill.
@@ -83451,7 +83643,7 @@ Quick sanity pass before committing.
 #### Memory
 
 - **Stale content**: Did the conversation make anything in existing memory obsolete or superseded? Remove or update it now.
-- **Cross-reference integrity**: If you deleted or moved a file, check whether any ordinary Markdown links point to the old location and update them.
+- **Cross-reference integrity**: If you deleted or moved a file, check whether any ordinary relative Markdown links point to the old location and update them.
 - **Tier check**: Did you add anything to root core memory that's really deferred material? Move it to a child directory. Did you leave something in a child directory that the agent needs on every turn? Promote it to root.
 
 #### Skills (only if you made a skill change)
@@ -83495,7 +83687,7 @@ Parent-Agent-ID: <PARENT_AGENT_ID>"
 
 In the commit message body, explain what changed and why, drawing from the categories you identified in Phase 2. If the change is skill-related, include the operation in the subject, e.g. \`feat(reflection): create docker-debugging skill 🔮\`.
 
-If no changes were needed, do NOT commit. Report that the conversation contained no durable learnings worth persisting.
+If no changes were needed, do NOT commit. Report that the conversation contained no memory worth persisting.
 
 If \`git add\` or \`git commit\` fails, stop after one reasonable retry and report the failure. Do not run \`git config\`, mutate \`.git\`, use \`git reset\`, or assume the harness will persist uncommitted filesystem edits; uncommitted edits are not successful memory persistence.
 
@@ -83513,10 +83705,10 @@ Return a report with:
 ## Critical Reminders
 
 1. **Not the primary agent** — Don't respond to messages
-2. **Memory vs Skills** — Store facts/preferences/corrections in memory; reach for a skill only when a reusable, durable workflow appears
+2. **Memory vs Skills** — Store facts/preferences/corrections in memory; reach for a skill only when a reusable workflow appears
 3. **Be selective** — Few meaningful changes > many trivial ones; few high-quality skills > many trivial ones
 4. **No relative dates** — Use absolute dates like "2026-04-28", not "today"
-5. **Always commit durable changes** — Your work is wasted if it is not committed; if nothing durable changed, do not commit
+5. **Always commit memory changes** — Your work is wasted if it is not committed; if nothing memory-worthy changed, do not commit
 6. **Encoding** — Memory markdown files must remain UTF-8. On Windows, do not use PowerShell redirection, \`Out-File\`, or \`Set-Content\` without explicit UTF-8 encoding; prefer \`memory_apply_patch\` or Node fs writes with UTF-8.
 7. **Report errors clearly** — If something breaks, say what happened and suggest a fix
 `;
@@ -83855,10 +84047,66 @@ var init_system_prompt_resolution = __esm(() => {
   init_prompt_assets();
 });
 
+// src/agent/memory-format.ts
+import { existsSync as existsSync6 } from "node:fs";
+import { join as join8 } from "node:path";
+function detectMemoryFormat(memoryDir, localMemfs) {
+  return !localMemfs && existsSync6(join8(memoryDir, "MEMORY.md")) ? "memfs-v2" : "memfs-v1";
+}
+function isMemoryIndexPath(relativePath) {
+  const normalized = relativePath.replace(/\\/g, "/");
+  return normalized === "MEMORY.md" || normalized.endsWith("/MEMORY.md");
+}
+function isCoreMemoryPath(relativePath, format5) {
+  const normalized = relativePath.replace(/\\/g, "/");
+  if (!normalized.endsWith(".md"))
+    return false;
+  if (format5 === "memfs-v2")
+    return !normalized.includes("/");
+  return normalized.startsWith("system/");
+}
+function isProjectedMemoryPath(relativePath, allPaths, format5) {
+  const normalized = relativePath.replace(/\\/g, "/");
+  if (format5 === "memfs-v1")
+    return true;
+  if (normalized === "skills" || normalized.startsWith("skills/"))
+    return false;
+  if (!normalized.includes("/"))
+    return true;
+  const parts = normalized.split("/");
+  const directories = parts.slice(0, -1);
+  let current = "";
+  for (const directory of directories) {
+    current = current ? `${current}/${directory}` : directory;
+    if (!allPaths.has(`${current}/MEMORY.md`))
+      return false;
+  }
+  return true;
+}
+function assertMemfsV2MemoryPathIndexed(memoryDir, relativePath, markerExists = (marker) => existsSync6(join8(memoryDir, marker))) {
+  const normalized = relativePath.replace(/\\/g, "/");
+  if (normalized === "MEMORY.md")
+    return;
+  if (!markerExists("MEMORY.md")) {
+    throw new Error("Memory requires a root MEMORY.md index");
+  }
+  const directories = normalized.split("/").slice(0, -1);
+  let current = "";
+  for (const directory of directories) {
+    current = current ? `${current}/${directory}` : directory;
+    const marker = `${current}/MEMORY.md`;
+    if (marker !== normalized && !markerExists(marker)) {
+      throw new Error(`Memory requires ${marker} before writing ${normalized}`);
+    }
+  }
+}
+var init_memory_format = () => {};
+
 // src/agent/system-prompt-versioning.ts
 var exports_system_prompt_versioning = {};
 __export(exports_system_prompt_versioning, {
   scheduleManagedSystemPromptUpdate: () => scheduleManagedSystemPromptUpdate,
+  resolveMemoryPromptMode: () => resolveMemoryPromptMode,
   recordManagedSystemPrompt: () => recordManagedSystemPrompt,
   hashSystemPrompt: () => hashSystemPrompt,
   getMemoryPromptModeForAgent: () => getMemoryPromptModeForAgent,
@@ -83883,26 +84131,33 @@ function recordManagedSystemPrompt(agentId, preset, memoryMode, content) {
   }
   settingsManager.setManagedSystemPrompt(agentId, managedPrompt(preset, memoryMode, content));
 }
-function getMemoryPromptModeForAgent(agentId) {
-  const backend = getBackend();
-  if (backend.capabilities.localMemfs) {
+function resolveMemoryPromptMode(input) {
+  if (input.localMemfs) {
     return "local-memfs";
   }
-  return settingsManager.isReady && settingsManager.isMemfsEnabled(agentId) ? "memfs" : "standard";
+  if (input.memoryDir && detectMemoryFormat(input.memoryDir, false) === "memfs-v2") {
+    return "root-memfs";
+  }
+  return input.memfsEnabled ? "memfs" : "standard";
+}
+function getMemoryPromptModeForAgent(agentId) {
+  const backend = getBackend();
+  return resolveMemoryPromptMode({
+    localMemfs: backend.capabilities.localMemfs,
+    memoryDir: resolveScopedMemoryDir({ agentId }),
+    memfsEnabled: settingsManager.isReady && settingsManager.isMemfsEnabled(agentId)
+  });
 }
 function isLettaCodePrimaryAgent(agent) {
   const tags = agent.tags ?? [];
   return tags.includes(LETTA_CODE_ORIGIN_TAG) && !tags.includes(LETTA_CODE_SUBAGENT_TAG);
 }
-function findMatchingCurrentPreset(systemPrompt, memoryMode) {
+function findMatchingCurrentPreset(systemPrompt) {
   for (const preset of SYSTEM_PROMPTS) {
-    if (buildSystemPrompt(preset.id, memoryMode) === systemPrompt) {
+    if (getSystemPromptVariantContents(preset).some((content) => content.trim() === systemPrompt.trim())) {
       return preset.id;
     }
   }
-  if (systemPrompt.startsWith("You are Letta Code, a state-of-the-art coding agent running within the Letta Code CLI")) {
-    return "default";
-  }
   return;
 }
 function isValidHash(hash3) {
@@ -83925,6 +84180,13 @@ function decideManagedSystemPromptUpdate(input) {
         return { kind: "clear", reason: "stored prompt hash is invalid" };
       }
       if (currentHash !== storedHash) {
+        const expectedCurrentPrompt2 = buildSystemPrompt(storedPreset, memoryMode);
+        if (currentSystemPrompt === expectedCurrentPrompt2) {
+          return {
+            kind: "track",
+            prompt: managedPrompt(storedPreset, memoryMode, currentSystemPrompt)
+          };
+        }
         return {
           kind: "custom",
           reason: "agent prompt differs from stored managed prompt hash"
@@ -83960,7 +84222,7 @@ function decideManagedSystemPromptUpdate(input) {
   if ((agent.tags ?? []).includes(LETTA_CODE_SUBAGENT_TAG)) {
     return { kind: "noop", reason: "agent is a Letta Code subagent" };
   }
-  const matchingPreset = findMatchingCurrentPreset(currentSystemPrompt, memoryMode);
+  const matchingPreset = findMatchingCurrentPreset(currentSystemPrompt);
   if (!matchingPreset) {
     if (isLettaCodePrimaryAgent(agent)) {
       return {
@@ -84054,6 +84316,8 @@ var init_system_prompt_versioning = __esm(() => {
   init_settings_manager();
   init_debug();
   init_version();
+  init_memory_filesystem2();
+  init_memory_format();
   init_prompt_assets();
 });
 
@@ -84428,10 +84692,10 @@ async function updateAgentSystemPrompt(agentId, systemPromptId) {
   try {
     const { isKnownPreset: isKnownPreset2 } = await Promise.resolve().then(() => (init_prompt_assets(), exports_prompt_assets));
     const { resolveAndBuildSystemPrompt: resolveAndBuildSystemPrompt2 } = await Promise.resolve().then(() => (init_system_prompt_resolution(), exports_system_prompt_resolution));
-    const { recordManagedSystemPrompt: recordManagedSystemPrompt2 } = await Promise.resolve().then(() => (init_system_prompt_versioning(), exports_system_prompt_versioning));
+    const { getMemoryPromptModeForAgent: getMemoryPromptModeForAgent2, recordManagedSystemPrompt: recordManagedSystemPrompt2 } = await Promise.resolve().then(() => (init_system_prompt_versioning(), exports_system_prompt_versioning));
     const { settingsManager: settingsManager2 } = await Promise.resolve().then(() => (init_settings_manager(), exports_settings_manager));
     const backend = getBackend();
-    const memoryMode = backend.capabilities.localMemfs ? "local-memfs" : settingsManager2.isReady && settingsManager2.isMemfsEnabled(agentId) ? "memfs" : "standard";
+    const memoryMode = getMemoryPromptModeForAgent2(agentId);
     const systemPromptContent = await resolveAndBuildSystemPrompt2(systemPromptId, memoryMode);
     debugLog("modify", "systemPromptContent: %s", systemPromptContent);
     const updateResult = await updateAgentSystemPromptRaw(agentId, systemPromptContent);
@@ -84468,9 +84732,18 @@ async function updateAgentSystemPrompt(agentId, systemPromptId) {
 async function updateAgentSystemPromptMemfs(agentId) {
   try {
     const { settingsManager: settingsManager2 } = await Promise.resolve().then(() => (init_settings_manager(), exports_settings_manager));
-    const { isKnownPreset: isKnownPreset2, buildSystemPrompt: buildSystemPrompt2 } = await Promise.resolve().then(() => (init_prompt_assets(), exports_prompt_assets));
-    const { hashSystemPrompt: hashSystemPrompt2, recordManagedSystemPrompt: recordManagedSystemPrompt2 } = await Promise.resolve().then(() => (init_system_prompt_versioning(), exports_system_prompt_versioning));
-    const newMode = getBackend().capabilities.localMemfs ? "local-memfs" : "memfs";
+    const {
+      isKnownPreset: isKnownPreset2,
+      buildSystemPrompt: buildSystemPrompt2,
+      getSystemPromptVariantContents: getSystemPromptVariantContents2,
+      SYSTEM_PROMPTS: SYSTEM_PROMPTS2
+    } = await Promise.resolve().then(() => (init_prompt_assets(), exports_prompt_assets));
+    const {
+      getMemoryPromptModeForAgent: getMemoryPromptModeForAgent2,
+      hashSystemPrompt: hashSystemPrompt2,
+      recordManagedSystemPrompt: recordManagedSystemPrompt2
+    } = await Promise.resolve().then(() => (init_system_prompt_versioning(), exports_system_prompt_versioning));
+    const newMode = getMemoryPromptModeForAgent2(agentId);
     const storedPreset = settingsManager2.isReady ? settingsManager2.getSystemPromptPreset(agentId) : undefined;
     const storedHash = settingsManager2.isReady ? settingsManager2.getSystemPromptHash(agentId) : undefined;
     let nextSystemPrompt;
@@ -84487,8 +84760,9 @@ async function updateAgentSystemPromptMemfs(agentId) {
         };
       }
       if (!storedHash && settingsManager2.isReady) {
-        const currentMode = settingsManager2.isMemfsEnabled(agentId) ? getBackend().capabilities.localMemfs ? "local-memfs" : "memfs" : "standard";
-        if (currentSystemPrompt !== buildSystemPrompt2(storedPreset, currentMode)) {
+        const preset = SYSTEM_PROMPTS2.find((candidate) => candidate.id === storedPreset);
+        const matchesBundledVariant = preset && getSystemPromptVariantContents2(preset).some((content) => content.trim() === currentSystemPrompt.trim());
+        if (!matchesBundledVariant) {
           settingsManager2.setSystemPromptCustom(agentId);
           return {
             success: true,
@@ -85551,8 +85825,8 @@ var init_session = __esm(() => {
 });
 
 // src/tools/impl/shell-launchers.ts
-import { existsSync as existsSync6 } from "node:fs";
-import { delimiter, isAbsolute as isAbsolute3, join as join8 } from "node:path";
+import { existsSync as existsSync7 } from "node:fs";
+import { delimiter, isAbsolute as isAbsolute3, join as join9 } from "node:path";
 function isValidEnvAlias(name) {
   return /^[A-Za-z_][A-Za-z0-9_]*$/.test(name);
 }
@@ -85667,7 +85941,7 @@ function hasFileExtension(executable) {
 }
 function resolveExecutablePath(executable, env2) {
   if (isAbsolute3(executable) || hasPathSeparator(executable)) {
-    return existsSync6(executable) ? executable : null;
+    return existsSync7(executable) ? executable : null;
   }
   const pathDelimiter = process.platform === "win32" ? ";" : delimiter;
   const pathEntries = pathEnvValue(env2).split(pathDelimiter).filter(Boolean);
@@ -85679,8 +85953,8 @@ function resolveExecutablePath(executable, env2) {
   }
   for (const entry of pathEntries) {
     for (const name of executableNames) {
-      const candidate = join8(entry, name);
-      if (existsSync6(candidate)) {
+      const candidate = join9(entry, name);
+      if (existsSync7(candidate)) {
         return candidate;
       }
     }
@@ -87104,8 +87378,8 @@ __export(exports_secrets_store, {
   __testOverrideSecretsBackend: () => __testOverrideSecretsBackend,
   __testOverrideLocalSecretStorage: () => __testOverrideLocalSecretStorage
 });
-import { existsSync as existsSync7, mkdirSync as mkdirSync5, readFileSync as readFileSync4, writeFileSync as writeFileSync2 } from "node:fs";
-import { dirname as dirname4, join as join9 } from "node:path";
+import { existsSync as existsSync8, mkdirSync as mkdirSync5, readFileSync as readFileSync4, writeFileSync as writeFileSync2 } from "node:fs";
+import { dirname as dirname4, join as join10 } from "node:path";
 function __testOverrideSecretsBackend(backend) {
   testBackendOverride = backend;
 }
@@ -87116,11 +87390,11 @@ function getSecretsBackend() {
   return testBackendOverride ?? getBackend();
 }
 function getFileBackedLocalSecretsPath() {
-  return join9(getLocalBackendStorageDir(), FILE_BACKED_LOCAL_SECRETS_PATH);
+  return join10(getLocalBackendStorageDir(), FILE_BACKED_LOCAL_SECRETS_PATH);
 }
 function readFileBackedLocalSecrets() {
   const filePath = getFileBackedLocalSecretsPath();
-  if (!existsSync7(filePath))
+  if (!existsSync8(filePath))
     return {};
   try {
     const parsed = JSON.parse(readFileSync4(filePath, "utf8"));
@@ -87429,7 +87703,7 @@ var init_secrets_store = __esm(() => {
   init_backend2();
   init_paths();
   init_secrets();
-  FILE_BACKED_LOCAL_SECRETS_PATH = join9("secrets", "local-agent-secrets.json");
+  FILE_BACKED_LOCAL_SECRETS_PATH = join10("secrets", "local-agent-secrets.json");
   SECRETS_CACHE_KEY = Symbol.for("@letta/secretsCache");
   LOCAL_SECRET_NAME_PATTERN = /^[A-Z_][A-Z0-9_]*$/;
 });
@@ -87767,61 +88041,6 @@ var init_tool_return_clamp = __esm(() => {
   init_truncation();
 });
 
-// src/agent/memory-format.ts
-import { existsSync as existsSync9 } from "node:fs";
-import { join as join11 } from "node:path";
-function detectMemoryFormat(memoryDir, localMemfs) {
-  return !localMemfs && existsSync9(join11(memoryDir, "MEMORY.md")) ? "memfs-v2" : "memfs-v1";
-}
-function isMemoryIndexPath(relativePath) {
-  const normalized = relativePath.replace(/\\/g, "/");
-  return normalized === "MEMORY.md" || normalized.endsWith("/MEMORY.md");
-}
-function isCoreMemoryPath(relativePath, format5) {
-  const normalized = relativePath.replace(/\\/g, "/");
-  if (!normalized.endsWith(".md"))
-    return false;
-  if (format5 === "memfs-v2")
-    return !normalized.includes("/");
-  return normalized.startsWith("system/");
-}
-function isProjectedMemoryPath(relativePath, allPaths, format5) {
-  const normalized = relativePath.replace(/\\/g, "/");
-  if (format5 === "memfs-v1")
-    return true;
-  if (normalized === "skills" || normalized.startsWith("skills/"))
-    return false;
-  if (!normalized.includes("/"))
-    return true;
-  const parts = normalized.split("/");
-  const directories = parts.slice(0, -1);
-  let current = "";
-  for (const directory of directories) {
-    current = current ? `${current}/${directory}` : directory;
-    if (!allPaths.has(`${current}/MEMORY.md`))
-      return false;
-  }
-  return true;
-}
-function assertMemfsV2MemoryPathIndexed(memoryDir, relativePath, markerExists = (marker) => existsSync9(join11(memoryDir, marker))) {
-  const normalized = relativePath.replace(/\\/g, "/");
-  if (normalized === "MEMORY.md")
-    return;
-  if (!markerExists("MEMORY.md")) {
-    throw new Error("Memory requires a root MEMORY.md index");
-  }
-  const directories = normalized.split("/").slice(0, -1);
-  let current = "";
-  for (const directory of directories) {
-    current = current ? `${current}/${directory}` : directory;
-    const marker = `${current}/MEMORY.md`;
-    if (marker !== normalized && !markerExists(marker)) {
-      throw new Error(`Memory requires ${marker} before writing ${normalized}`);
-    }
-  }
-}
-var init_memory_format = () => {};
-
 // src/tools/define-tool.ts
 function defineTool(input) {
   return {
@@ -88071,7 +88290,7 @@ var BashOutput_default = `# BashOutput
 var init_BashOutput = () => {};
 
 // src/tools/descriptions/Edit.md
-var Edit_default = "# Edit\n\nPerforms exact string replacements in files. \n\nUsage:\n- You must use your `Read` tool at least once in the conversation before editing. This tool will error if you attempt an edit without reading the file. Exception: system memory files whose contents are already shown in your prompt do not require a Read call first. For memory files, pass an expanded absolute path (use Bash to resolve `$MEMORY_DIR` first if needed).\n- `file_path` is literal: `$VAR`, `$MEMORY_DIR`, `~`, etc. are not expanded.\n- When editing text from Read tool output, ensure you preserve the exact indentation (tabs/spaces) as it appears AFTER the line number prefix. The line number prefix format is: spaces + line number + tab. Everything after that tab is the actual file content to match. Never include any part of the line number prefix in the old_string or new_string.\n- ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required.\n- Only use emojis if the user explicitly requests it. Avoid adding emojis to files unless asked.\n- The edit will FAIL if `old_string` is not unique in the file. Either provide a larger string with more surrounding context to make it unique or use `replace_all` to change every instance of `old_string`. \n- Use `replace_all` for replacing and renaming strings across the file. This parameter is useful if you want to rename a variable for instance.\n";
+var Edit_default = "# Edit\n\nPerforms exact string replacements in files. \n\nUsage:\n- You must use your `Read` tool at least once in the conversation before editing. This tool will error if you attempt an edit without reading the file. Exception: memory files whose contents are already present in your system prompt do not require a Read call first. For memory files, pass an expanded absolute path (use Bash to resolve `$MEMORY_DIR` first if needed).\n- `file_path` is literal: `$VAR`, `$MEMORY_DIR`, `~`, etc. are not expanded.\n- When editing text from Read tool output, ensure you preserve the exact indentation (tabs/spaces) as it appears AFTER the line number prefix. The line number prefix format is: spaces + line number + tab. Everything after that tab is the actual file content to match. Never include any part of the line number prefix in the old_string or new_string.\n- ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required.\n- Only use emojis if the user explicitly requests it. Avoid adding emojis to files unless asked.\n- The edit will FAIL if `old_string` is not unique in the file. Either provide a larger string with more surrounding context to make it unique or use `replace_all` to change every instance of `old_string`. \n- Use `replace_all` for replacing and renaming strings across the file. This parameter is useful if you want to rename a variable for instance.\n";
 var init_Edit = () => {};
 
 // src/tools/descriptions/EnterWorktree.md
@@ -88272,11 +88491,11 @@ var MemoryApplyPatch_default = "Apply a codex-style patch to memory files in `$M
 var init_MemoryApplyPatch = () => {};
 
 // src/tools/descriptions/MemoryApplyPatchV2.md
-var MemoryApplyPatchV2_default = "Apply a codex-style patch to memory files in `$MEMORY_DIR`, then automatically commit the change. The harness pushes clean committed memory changes after the turn for remote agents.\n\nThis is similar to `apply_patch`, but scoped to the memory filesystem and with memory-aware guardrails.\n\n- Required args:\n  - `reason` — git commit message for the memory change\n  - `input` — patch text using the standard apply_patch format\n\nPatch format:\n- `*** Begin Patch`\n- `*** Add File: <path>`\n- `*** Update File: <path>`\n  - optional `*** Move to: <path>`\n  - one or more `@@` hunks with ` `, `-`, `+` lines\n- `*** Delete File: <path>`\n- `*** End Patch`\n\nPath rules:\n- Relative paths are interpreted inside the memory repository.\n- Absolute paths are allowed only when under `$MEMORY_DIR`.\n- Paths outside the memory repository are rejected.\n\nMemory rules:\n- Root and child `MEMORY.md` files are frontmatter-free indexes.\n- Every other memory Markdown file has exactly `name` and `description` frontmatter.\n- A child directory is memory only when it contains `MEMORY.md`.\n- `skills/` is managed through skill and file tools, not this tool.\n- Adding a regular memory file without frontmatter creates valid frontmatter automatically.\n\nGit behavior:\n- Stages changed memory paths.\n- Commits with `reason`.\n- Uses the agent identity as the author (`<agent_id>@letta.com`).\n- Remote memory push is handled by the harness after the turn.\n\nExample:\n```python\nmemory_apply_patch(\n  reason=\"Refine coding preferences\",\n  input=\"\"\"*** Begin Patch\n*** Update File: human.md\n@@\n-Use broad abstractions\n+Prefer small focused helpers\n*** End Patch\"\"\"\n)\n```\n";
+var MemoryApplyPatchV2_default = "Apply a codex-style patch to memory files in `$MEMORY_DIR`, then automatically commit the change. The harness pushes clean committed memory changes after the turn for remote MemFS agents.\n\nThis is similar to `apply_patch`, but scoped to the memory filesystem and with memory-aware guardrails.\n\n- Required args:\n  - `reason` — git commit message for the memory change\n  - `input` — patch text using the standard apply_patch format\n\nPatch format:\n- `*** Begin Patch`\n- `*** Add File: <path>`\n- `*** Update File: <path>`\n  - optional `*** Move to: <path>`\n  - one or more `@@` hunks with ` `, `-`, `+` lines\n- `*** Delete File: <path>`\n- `*** End Patch`\n\nPath rules:\n- Relative paths are interpreted inside memory repo\n- Absolute paths are allowed only when under `$MEMORY_DIR`\n- Paths outside memory repo are rejected\n\nMemory rules:\n- Operates on markdown memory files (`.md`)\n- Root and child `MEMORY.md` files are valid without frontmatter\n- Every other updated/deleted memory Markdown file must have exactly `name` and `description` frontmatter\n- A child directory is memory only when it contains `MEMORY.md`\n- `read_only: true` files cannot be modified\n- If adding a regular memory file without frontmatter, frontmatter is created automatically\n\nGit behavior:\n- Stages changed memory paths\n- Commits with `reason`\n- Uses agent identity author (`<agent_id>@letta.com`)\n- Remote MemFS push is handled by the harness after the turn\n\nExample:\n```python\nmemory_apply_patch(\n  reason=\"Refine coding preferences\",\n  input=\"\"\"*** Begin Patch\n*** Update File: human-prefs-coding.md\n@@\n-Use broad abstractions\n+Prefer small focused helpers\n*** End Patch\"\"\"\n)\n```\n";
 var init_MemoryApplyPatchV2 = () => {};
 
 // src/tools/descriptions/MemoryV2.md
-var MemoryV2_default = "# Memory\nA convenience tool for memories stored in the memory directory (`$MEMORY_DIR`) that automatically commits changes. The harness pushes clean committed memory changes after the turn for remote agents.\n\nRoot Markdown files are core memory and are already in the context window. Nested memory stays deferred until it is read through a directory index.\n\nSupported operations on memory files:\n- `str_replace`\n- `insert`\n- `delete` (files, or directories recursively)\n- `rename` (path rename only)\n- `update_description`\n- `create`\n\nFor larger reorganizations, edit the projected files directly and commit the changes yourself (see the syncing instructions in your system prompt).\n\nPath formats accepted:\n- relative memory file paths (for example, `human.md` or `projects/notes.md`)\n- absolute paths only when they are inside `$MEMORY_DIR`\n\nMemory rules:\n- Root and child `MEMORY.md` files are frontmatter-free indexes.\n- Every other memory Markdown file has exactly `name` and `description` frontmatter.\n- A child directory is memory only when it contains `MEMORY.md`.\n- `skills/` is managed through skill and file tools, not this tool.\n- When creating, renaming, or deleting files, update the nearest `MEMORY.md` index and any affected links.\n\nExamples:\n\n```python\n# Replace text in a core memory file\nmemory(command=\"str_replace\", reason=\"Update theme preference\", file_path=\"human.md\", old_string=\"theme: dark\", new_string=\"theme: light\")\n\n# Create a child directory index\nmemory(command=\"create\", reason=\"Index project memory\", file_path=\"projects/MEMORY.md\", file_text=\"# Projects\")\n\n# Create a deferred memory file after its directory index exists\nmemory(command=\"create\", reason=\"Track project decisions\", file_path=\"projects/decisions.md\", description=\"Decisions for the current project.\", file_text=\"No decisions yet.\")\n\n# Update a file description\nmemory(command=\"update_description\", reason=\"Clarify project decisions\", file_path=\"projects/decisions.md\", description=\"Accepted and rejected decisions for the current project.\")\n```\n";
+var MemoryV2_default = "# Memory\nA convenience tool for memories stored in the memory directory (`$MEMORY_DIR`) that automatically commits changes. The harness pushes clean committed memory changes after the turn for remote MemFS agents.\n\nRoot Markdown files other than `MEMORY.md` eventually become part of the agent's system prompt, so are always in the context window and do not need to be re-read. Files in indexed child directories remain deferred until explicitly read.\n\nSupported operations on memory files:\n- `str_replace`\n- `insert`\n- `delete` (files, or directories recursively)\n- `rename` (path rename only)\n- `update_description`\n- `create`\nFor larger reorganizations, edit the projected files directly and commit the changes yourself (see the syncing instructions in your system prompt).\n\nPath formats accepted:\n- relative memory file paths (e.g. `contacts.md`, `reference/project/team.md`)\n- absolute paths only when they are inside `$MEMORY_DIR`\n\nNote: absolute paths outside `$MEMORY_DIR` are rejected.\n\nWhen creating or deleting files, check for ordinary relative Markdown links from `MEMORY.md` files that may need to be added or updated. Keeping references consistent ensures future discoverability.\n\nMemory rules:\n- Root and child `MEMORY.md` files are frontmatter-free indexes.\n- Every other memory Markdown file has exactly `name` and `description` frontmatter.\n- A child directory is memory only when it contains `MEMORY.md`.\n\nExamples:\n\n```python\n# Replace text in a memory file\nmemory(command=\"str_replace\", reason=\"Update theme preference\", file_path=\"human-preferences.md\", old_string=\"theme: dark\", new_string=\"theme: light\")\n\n# Insert text at line 5\nmemory(command=\"insert\", reason=\"Add note about meeting\", file_path=\"history/meeting-notes.md\", insert_line=5, insert_text=\"New note here\")\n\n# Delete a memory file\nmemory(command=\"delete\", reason=\"Remove stale notes\", file_path=\"history/old_notes.md\")\n\n# Rename a memory file\nmemory(command=\"rename\", reason=\"Promote temp notes\", old_path=\"history/temp.md\", new_path=\"history/permanent.md\")\n\n# Update a block description\nmemory(command=\"update_description\", reason=\"Clarify coding prefs block\", file_path=\"human-prefs-coding.md\", description=\"The user's coding preferences.\")\n\n# Create a block with starting text\nmemory(command=\"create\", reason=\"Track coding preferences\", file_path=\"human-prefs-coding.md\", description=\"The user's coding preferences.\", file_text=\"The user seems to add type hints to all of their Python code.\")\n\n# Create an empty block\nmemory(command=\"create\", reason=\"Create coding preferences block\", file_path=\"reference/history/coding_preferences.md\", description=\"The user's coding preferences.\")\n```\n";
 var init_MemoryV2 = () => {};
 
 // src/tools/descriptions/Monitor.md
@@ -89147,7 +89366,7 @@ Writes a file to the local filesystem.
 
 Usage:
 - This tool will overwrite the existing file if there is one at the provided path.
-- If this is an existing file, you MUST use the Read tool first to read the file's contents. This tool will fail if you did not read the file first. Exception: system memory files whose contents are already shown in your prompt do not require a Read call first. For memory files, pass an expanded absolute path (use Bash to resolve \`$MEMORY_DIR\` first if needed).
+- If this is an existing file, you MUST use the Read tool first to read the file's contents. This tool will fail if you did not read the file first. Exception: memory files whose contents are already present in your system prompt do not require a Read call first. For memory files, pass an expanded absolute path (use Bash to resolve \`$MEMORY_DIR\` first if needed).
 - \`file_path\` is literal: \`$VAR\`, \`$MEMORY_DIR\`, \`~\`, etc. are not expanded.
 - ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required.
 - NEVER proactively create documentation files (*.md) or README files. Only create documentation files if explicitly requested by the User.
@@ -113138,6 +113357,7 @@ __export(exports_skill, {
   wrapSkillPrompt: () => wrapSkillPrompt,
   wrapSkillContent: () => wrapSkillContent,
   skill: () => skill,
+  resolveBundledSkillContentPath: () => resolveBundledSkillContentPath,
   renderSkillContent: () => renderSkillContent,
   readSkillContent: () => readSkillContent,
   loadRenderedSkillContent: () => loadRenderedSkillContent,
@@ -113175,6 +113395,19 @@ function getMemorySkillsDirs(agentId) {
   }
   return Array.from(dirs);
 }
+function resolveBundledSkillContentPath(input) {
+  if (!input.localMemfs && input.memoryDir && ROOT_MEMORY_SKILLS.has(input.skillId) && detectMemoryFormat(input.memoryDir, false) === "memfs-v2") {
+    return join26(dirname16(input.bundledSkillPath), "ROOT_MEMORY.md");
+  }
+  return input.bundledSkillPath;
+}
+function isLocalMemfsBackend() {
+  try {
+    return getBackend().capabilities.localMemfs;
+  } catch {
+    return isLocalBackendEnvEnabled(process.env);
+  }
+}
 function listSkillResources(skillMdPath) {
   const skillDir = dirname16(skillMdPath);
   const paths = [];
@@ -113188,7 +113421,7 @@ function listSkillResources(skillMdPath) {
     }
     for (const entry of entries.sort((left, right) => left.name.localeCompare(right.name))) {
       const relativePath = relativeDirectory ? `${relativeDirectory}/${entry.name}` : entry.name;
-      if (relativePath.toUpperCase() === "SKILL.MD") {
+      if (relativePath.toUpperCase() === "SKILL.MD" || relativePath.toUpperCase() === "ROOT_MEMORY.MD") {
         continue;
       }
       if (paths.length >= MAX_LISTED_SKILL_RESOURCES) {
@@ -113252,8 +113485,14 @@ async function readSkillContent(skillId, skillsDir, agentId, options = {}) {
   const bundledSkill = bundledSkills.find((s2) => s2.id === skillId);
   if (bundledSkill?.path && isSkillAvailableForAgent(bundledSkill, agentId)) {
     try {
-      const content = await readFile12(bundledSkill.path, "utf-8");
-      return { content, path: bundledSkill.path };
+      const path28 = resolveBundledSkillContentPath({
+        skillId,
+        bundledSkillPath: bundledSkill.path,
+        memoryDir: resolveScopedMemoryDir({ agentId }),
+        localMemfs: isLocalMemfsBackend()
+      });
+      const content = await readFile12(path28, "utf-8");
+      return { content, path: path28 };
     } catch {}
   }
   try {
@@ -113352,14 +113591,18 @@ async function skill(args, dependencies4 = {}) {
     throw new Error(`Failed to invoke skill "${skillName}": ${String(error4)}`);
   }
 }
-var MAX_LISTED_SKILL_RESOURCES = 200;
+var MAX_LISTED_SKILL_RESOURCES = 200, ROOT_MEMORY_SKILLS;
 var init_skill = __esm(() => {
   init_context();
   init_memory_filesystem2();
+  init_memory_format();
   init_shared_memory_skills();
   init_skills3();
+  init_backend2();
+  init_paths();
   init_runtime_context();
   init_skill_content_registry();
+  ROOT_MEMORY_SKILLS = new Set(["initializing-memory", "context-doctor"]);
 });
 
 // src/agent/prompts/recall_subagent.md
@@ -212819,7 +213062,7 @@ function safeJsonParseOr(json, defaultValue) {
 function buildReflectionSubagentPrompt(input) {
   const lines = [];
   const v2 = input.memoryFormat === "memfs-v2";
-  lines.push('Review the conversation transcript payload and update memory files. The payload path is available as the `$TRANSCRIPT_PATH` env var — read it via Bash (e.g. `wc -c "$TRANSCRIPT_PATH"`). Note: `$TRANSCRIPT_PATH` only expands in shell commands; Edit `file_path` is literal and does NOT expand env vars.', "", 'The payload may be either a JSON message array for one conversation or a `multi_transcript_reflection_payload` manifest. If it is a manifest, read each `payload_path` listed in `transcripts` and synthesize across all conversations. Entries with `mode: "replay"` were already reflected before and are included intentionally for re-review/deduplication; do not ignore them just because they are replay slices.', "When reviewing multiple transcripts, prefer durable patterns and latest evidence across sessions. Resolve contradictions by updating stale memory at the source, deduplicate repeated facts, and avoid storing one-off task state.", "", "The primary agent's memory filesystem is available through the `$MEMORY_DIR` environment variable.", "Run git add or git commit commands only from $MEMORY_DIR; the harness handles integration after your commit. If these fail, stop reflecting and report the failure. All other git commands are out of your purview.", v2 ? 'When using Edit, first resolve the absolute file path from `$MEMORY_DIR` with Bash (for example: `printf "%s/persona.md\\n" "$MEMORY_DIR"`) and use the printed path. Do not hardcode memory paths from the prompt.' : 'When using Edit, first resolve the absolute file path from `$MEMORY_DIR` with Bash (for example: `printf "%s/system/persona.md\\n" "$MEMORY_DIR"`) and use the printed path. Do not hardcode memory paths from the prompt.', v2 ? "Root Markdown files are in-context memory. Root and child MEMORY.md files are frontmatter-free indexes using ordinary relative Markdown links; every other memory Markdown file has exactly name and description frontmatter. A child directory is memory only when it contains MEMORY.md. Never create system/." : "In-context memory (in the parent agent's system prompt) is stored in the `system/` folder and are rendered in <memory> tags below. Modification to files in `system/` will edit the parent agent's system prompt.", "Additional memory files (such as skills and external memory) may also be read and modified.", "");
+  lines.push('Review the conversation transcript payload and update memory files. The payload path is available as the `$TRANSCRIPT_PATH` env var — read it via Bash (e.g. `wc -c "$TRANSCRIPT_PATH"`). Note: `$TRANSCRIPT_PATH` only expands in shell commands; Edit `file_path` is literal and does NOT expand env vars.', "", 'The payload may be either a JSON message array for one conversation or a `multi_transcript_reflection_payload` manifest. If it is a manifest, read each `payload_path` listed in `transcripts` and synthesize across all conversations. Entries with `mode: "replay"` were already reflected before and are included intentionally for re-review/deduplication; do not ignore them just because they are replay slices.', "When reviewing multiple transcripts, prefer durable patterns and latest evidence across sessions. Resolve contradictions by updating stale memory at the source, deduplicate repeated facts, and avoid storing one-off task state.", "", "The primary agent's memory filesystem is available through the `$MEMORY_DIR` environment variable.", "Run git add or git commit commands only from $MEMORY_DIR; the harness handles integration after your commit. If these fail, stop reflecting and report the failure. All other git commands are out of your purview.", v2 ? 'When using Edit, first resolve the absolute file path from `$MEMORY_DIR` with Bash (for example: `printf "%s/persona.md\\n" "$MEMORY_DIR"`) and use the printed path. Do not hardcode memory paths from the prompt.' : 'When using Edit, first resolve the absolute file path from `$MEMORY_DIR` with Bash (for example: `printf "%s/system/persona.md\\n" "$MEMORY_DIR"`) and use the printed path. Do not hardcode memory paths from the prompt.', v2 ? "Root Markdown files are in-context memory. Root and child MEMORY.md files are frontmatter-free indexes using ordinary relative Markdown links; every other memory Markdown file has exactly name and description frontmatter. A child directory is memory only when it contains MEMORY.md." : "In-context memory (in the parent agent's system prompt) is stored in the `system/` folder and are rendered in <memory> tags below. Modification to files in `system/` will edit the parent agent's system prompt.", "Additional memory files (such as skills and external memory) may also be read and modified.", "");
   if (input.instruction?.trim()) {
     lines.push("Additional user-provided reflection instruction:", input.instruction.trim(), "", "Use this instruction to focus what you look for, but still only persist durable memory-worthy learnings and do not store transient task state.", "");
   }
@@ -444297,7 +444540,7 @@ var init_mcp_client = __esm(() => {
   init_streamableHttp();
   DEFAULT_CLIENT_INFO = {
     name: "letta-code",
-    version: "0.31.4"
+    version: "0.31.5"
   };
 });
 
@@ -511330,4 +511573,4 @@ function registerBunOAuthFlows() {
 registerBunOAuthFlows();
 await init_src5().then(() => exports_src2);
 
-//# debugId=F49FE6FEE23EF90664756E2164756E21
+//# debugId=335F24DF4BFDD11A64756E2164756E21