engine7 7.1.119 → 7.1.121

package/dist/prompts/atomic-facts-memcell.md

@@ -0,0 +1,80 @@
+
+**CRITICAL LANGUAGE RULE**: You MUST output in the SAME language as the input conversation content. If the conversation content is in Chinese, ALL output MUST be in Chinese. If in English, output in English. This is mandatory.
+
+You are an expert information extraction analyst and information architect.
+Your task is to analyze the given raw conversation transcript (called "CONVERSATION_TEXT") and produce atomic facts optimized for factual retrieval.
+
+---
+
+### INPUT
+- CONVERSATION_TEXT: The raw conversation transcript.
+- TIME: The start time of the conversation, e.g., "March 10, 2024(Sunday) at 2:00 PM UTC".
+
+---
+
+### OUTPUT
+Return **only** one valid JSON object, with the following exact structure:
+
+{
+  "atomic_facts": {
+    "time": "<THE EXACT TIME STRING FROM INPUT TIME>",
+    "atomic_fact": [
+      "<Atomic fact sentence 1>",
+      "<Atomic fact sentence 2>",
+      ...
+    ]
+  }
+}
+
+---
+
+### EXTRACTION RULES
+
+#### 1. Atomicity
+* Each entry in `"atomic_fact"` must express **exactly one coherent unit of meaning** — an action, emotion, reason, plan, decision, or statement.
+* If a speaker expresses multiple ideas (e.g., an event and its reason), split them into multiple atomic facts.
+* Each atomic_fact must be **independent and retrievable on its own**.
+
+#### 2. Time & Date Handling (CRITICAL)
+* The `"time"` field (at the top level) represents the conversation start time.
+* **All generated timestamps must be in UTC.**
+* **Preserve** explicit dates verbatim.
+* **Resolve** relative or vague times (e.g., "yesterday", "last week") relative to `TIME`, and **append the resolved absolute date in parentheses** (e.g., "yesterday (March 9, 2024)").
+
+#### 3. Content Preservation & Attribution
+* **Base facts strictly on the conversation.** Do not infer information not present.
+* **Explicit Attribution**: Always state WHO said or did what.
+  - GOOD: "John said he liked the movie."
+  - BAD: "The movie was liked." (Who liked it?)
+* Resolve pronouns (he/she/it) to specific names where possible.
+
+#### 4. Expression Format
+* Write each atomic_fact as a **single, complete sentence** in **third-person** form (language: follow the CRITICAL LANGUAGE RULE at the top of this prompt).
+* Do **not** simplify, paraphrase, or merge logically distinct ideas.
+
+#### 5. Retrieval Clarity & Filtering
+* **Filter out**: Greetings, phatic communication ("Okay", "Cool"), and low-value chatter unless it conveys specific emotional or factual content.
+* **Keep**: Events, decisions, plans, preferences, specific opinions, factual statements.
+
+#### 6. Output Requirements
+* Output **only** the JSON object — no additional explanation, markdown, or commentary.
+* Ensure valid JSON.
+
+---
+
+### QUALITY CHECKS
+Before returning the final output, verify that:
+1. Every meaningful fact is captured.
+2. Attribution is correct (who said what).
+3. Timestamps are UTC and relative times are resolved.
+4. Redundancy is minimized.
+
+---
+
+Now analyze the provided conversation content and start time carefully, apply all rules above, and return **only the JSON object** in the specified format.
+
+Conversation start time: {TIME}
+Conversation content:
+{INPUT_TEXT}
+
+**CRITICAL LANGUAGE RULE**: You MUST output in the SAME language as the input conversation content. If the conversation content is in Chinese, ALL output MUST be in Chinese. If in English, output in English. This is mandatory.

package/dist/prompts/atomic-facts.md

@@ -0,0 +1,108 @@
+You are an expert episodic memory extraction analyst and information architect.
+Your task is to analyze the given narrative or multi-turn conversation (called "EPISODE_TEXT") and produce an event log optimized for factual retrieval.
+
+---
+
+### INPUT
+- EPISODE_TEXT: The memory text saved through the "episode memory".
+- TIME: The start time of the episode, e.g., "March 10, 2024(Sunday) at 2:00 PM".
+
+---
+
+### OUTPUT
+Return **only** one valid JSON object, with the following exact structure:
+
+{
+  "event_log": {
+    "time": "<THE EXACT TIME STRING FROM INPUT TIME>",
+    "atomic_fact": [
+      "<Atomic fact sentence 1>",
+      "<Atomic fact sentence 2>",
+      ...
+    ]
+  }
+}
+
+---
+
+### EXTRACTION RULES
+
+#### 1. Atomicity
+* Each entry in `"atomic_fact"` must express **exactly one coherent unit of meaning** — an action, emotion, reason, plan, decision, or statement.
+* If a speaker expresses multiple ideas (e.g., an event and its reason), split them into multiple atomic facts.
+* Each atomic_fact must be **independent and retrievable on its own**.
+
+#### 2. Time & Date Handling
+* Do **not** add or prepend timestamps such as "On March 10, 2024".
+* The `"time"` field (at the top level) already represents the episode's start time.
+* However, when the original text mentions **explicit or relative time expressions**, you must:
+  - **Preserve** explicit dates verbatim (e.g., "October 6, 2023").
+  - **Resolve** relative or vague times (e.g., "yesterday", "last week", "two months ago") relative to `TIME`, and **append the resolved absolute date in parentheses**.
+    Example: "Gina said she launched the campaign yesterday (March 9, 2024)."
+  - If the exact resolution is uncertain, use a normalized vague phrase (e.g., "in early 2023", "during the summer of 2021") instead of guessing.
+
+#### 3. Content Preservation
+* Preserve **all semantically meaningful information**, including:
+  - emotions, attitudes, reasons, intentions, consequences, conditions, and comparisons
+* Resolve pronouns into explicit names or entities when unambiguous.
+* Keep original wording as much as possible — only fix grammar for clarity.
+
+#### 4. Expression Format
+* Write each atomic_fact as a **single, complete English sentence** in **third-person** form.
+  - e.g., "Gina said that she had launched an ad campaign for her clothing store yesterday (March 9, 2024)."
+* Do **not** simplify, paraphrase, or merge logically distinct ideas.
+
+#### 5. Retrieval Clarity
+* Each atomic_fact must be concise, factual, and self-contained.
+* Avoid small talk or filler unless it conveys meaningful emotional or informational content.
+* Ensure entities and actions are explicit and unambiguous.
+
+#### 6. Output Requirements
+* Output **only** the JSON object — no additional explanation, markdown, or commentary.
+* Ensure valid JSON (proper quotes, commas, and escaping).
+* The `"atomic_fact"` list should include all meaningful facts extracted from the episode.
+
+---
+
+### QUALITY CHECKS
+Before returning the final output, verify that:
+1. Every meaningful fact, intention, and emotion is included.
+2. Each `atomic_fact` contains exactly one idea.
+3. All relevant time references are preserved or normalized.
+4. Wording remains faithful to the source.
+5. The output JSON is valid and follows the exact schema.
+
+---
+
+### EXAMPLE
+
+**Input:**
+TIME = "March 10, 2024(Sunday) at 2:00 PM"
+EPISODE_TEXT =
+"Gina said she just launched an ad campaign for her clothing store yesterday.
+Jon congratulated her and asked how her dance studio search was going.
+Gina explained that she was focusing on the clothing store for now but still hoped to find a suitable studio soon."
+
+**Output:**
+{
+  "event_log": {
+    "time": "March 10, 2024(Sunday) at 2:00 PM",
+    "atomic_fact": [
+      "Gina said that she had launched an ad campaign for her clothing store yesterday (March 9, 2024).",
+      "Jon congratulated Gina on her new campaign.",
+      "Jon asked Gina about the progress of her dance studio search.",
+      "Gina explained that she was focusing on the clothing store for now.",
+      "Gina said that she still hoped to find a suitable studio in the future."
+    ]
+  }
+}
+
+---
+
+Now analyze the provided EPISODE_TEXT and TIME carefully, apply all rules above, and return **only the JSON object** in the specified format.
+---
+
+### INPUT
+- EPISODE_TEXT: "{{{EPISODE_TEXT}}}"
+- TIME: "{{{TIME}}}"  (the start time of the episode, e.g., "March 10, 2024(Sunday) at 2:00 PM")
+

package/dist/prompts/boundary.md

@@ -0,0 +1,88 @@
+
+**CRITICAL LANGUAGE RULE**: You MUST output in the SAME language as the input conversation content. If the conversation content is in Chinese, ALL output MUST be in Chinese. If in English, output in English. This is mandatory.
+
+You are an episodic memory boundary detection expert. Your task is to find all natural "episode boundaries" in a continuous conversation and split it into meaningful, independently memorable segments (MemCells). Your core principle is **"default to merging, split cautiously"**.
+
+### Input Format
+The following is a complete chronological conversation log. Each message is prefixed with a 1-based index and timestamp:
+
+```
+{messages}
+```
+
+### When to split
+
+Add a boundary (by message number) only when **clear signals** appear:
+- **Cross-day split (highest priority):** Adjacent messages have different calendar dates — MUST split at the date boundary.
+- **Substantive topic change:** Conversation shifts from one concrete topic to a completely unrelated one (e.g., project architecture → weekend plans).
+- **Task completion + new topic:** A closing message ("migration done") belongs to its task's episode; split only when the **next** message opens a genuinely unrelated topic.
+- **Long gap + new topic:** Time gap > 4 hours AND new messages have no clear connection to prior conversation.
+
+**Do NOT split for:**
+- Greetings, farewells ("bye", "thanks") — keep with the main episode
+- Transition phrases ("by the way", "oh also") — usually continue the current episode
+- Brief pauses (< 4 hours) followed by the same topic
+
+### `should_wait`
+Set to `true` when the **last segment** has insufficient information to determine its episode context:
+- **Non-text messages:** Only media placeholders (`[image]`, `[video]`, `[file]`) with no accompanying text
+- **Intent-free short replies:** Minimal responses like "ok", "sure", "got it", "😂"
+- **System or non-conversational messages:** System notifications (join/leave group, payment reminders, etc.) cannot themselves determine episode boundaries — wait for the next human message to decide
+- **Ambiguous intermediate state:** Gap of 30 min–4 hours with content that is neither clearly continuing nor clearly starting a new topic
+
+### Decision Principles
+- **Merge by default:** When in doubt, do not split; only split on clear signals
+- **Content over form:** Greetings and farewells belong to the episode they serve, not their own
+- **Process continuity:** Consecutive actions toward the same goal (e.g., create group → post first instruction) form one episode
+- **System messages don't trigger splits:** System messages (e.g., `"[User X] joined the group"`) have their episode context determined by the next human message that follows them
+
+### Examples
+
+**Example 1 — one boundary:**
+Input messages:
+```
+[1] [2024-03-10T09:00:00Z] Alice: Can you help me debug the login issue?
+[2] [2024-03-10T09:01:00Z] Bob: Sure, let me check the logs.
+[3] [2024-03-10T09:05:00Z] Bob: Found it — a null pointer in AuthService line 42.
+[4] [2024-03-10T09:06:00Z] Alice: Fixed, thanks!
+[5] [2024-03-11T10:00:00Z] Alice: Hey, are you free for lunch today?
+[6] [2024-03-11T10:01:00Z] Bob: Sure, 12:30?
+```
+Output:
+```json
+{{
+    "reasoning": "Messages 1-4 are a complete bug-fix episode; message 5 starts a new day with an unrelated lunch topic.",
+    "boundaries": [4],
+    "should_wait": false
+}}
+```
+
+**Example 2 — no boundary:**
+Input messages:
+```
+[1] [2024-03-10T06:00:00Z] Alice: What's the status of the Q2 roadmap?
+[2] [2024-03-10T06:02:00Z] Bob: About 60% done. Need to finalize the API specs.
+[3] [2024-03-10T06:10:00Z] Alice: OK, let's review the specs tomorrow.
+```
+Output:
+```json
+{{
+    "reasoning": "All messages are part of the same Q2 roadmap discussion with no topic change.",
+    "boundaries": [],
+    "should_wait": false
+}}
+```
+
+### Output Format
+Return strictly in the following JSON format:
+```json
+{{
+    "reasoning": "<one sentence explaining all boundary decisions>",
+    "boundaries": [<1-indexed message numbers after which to split>],
+    "should_wait": <boolean, whether the last segment has insufficient information>
+}}
+```
+
+**`boundaries: []` means all messages belong to the same episode — no split.**
+
+**CRITICAL LANGUAGE RULE**: You MUST output in the SAME language as the input conversation content. If the conversation content is in Chinese, ALL output MUST be in Chinese. If in English, output in English. This is mandatory.

package/dist/prompts/case-compress.md

@@ -0,0 +1,73 @@
+You are an expert at distilling agent interaction trajectories into concise experience records.
+
+Given an agent trajectory (a JSON list of messages from a single task segment), extract ONE experience record that captures the specific problem solved and the concrete problem-solving process.
+
+An **experience** is a compressed record of how a specific task was solved — preserving all key steps, decisions, and results. It serves two purposes:
+1. **Reference case**: When the agent encounters a similar task, it can retrieve this experience and follow a proven approach.
+2. **Raw material**: Multiple similar experiences are later refined into generalized skills (best practices).
+
+Input messages are in OpenAI chat completion format:
+- role="user": User input
+- role="assistant" without tool_calls: Agent's direct response
+- role="assistant" with tool_calls: Agent decides to call tools (may include reasoning in content)
+- role="tool" with tool_call_id: Tool execution result (may have been pre-compressed)
+
+Pre-processed trajectory:
+{messages}
+
+**CRITICAL LANGUAGE RULE**: You MUST output in the SAME language as the input conversation content. If the conversation content is in Chinese, ALL output MUST be in Chinese. If in English, output in English. This is mandatory.
+
+**Extract the Experience:**
+
+- **task_intent**: Synthesize the specific task from ALL turns into a single, self-contained statement (not a question). This serves as a retrieval key for finding similar past cases. **Max 50 tokens** — be precise and specific, avoid filler words.
+
+- **approach**: A compressed record that decomposes the task into sub-problems. **Max 1000 tokens** — aggressively compress prose and explanations, but preserve critical technical details verbatim.
+  - Each numbered step = one sub-problem the agent needed to solve on the way to the overall task.
+  - Under each step: what the agent tried (tool used or reasoning applied) and the result obtained (findings, errors, metrics).
+  - If a sub-problem required multiple attempts (e.g., first attempt failed, then revised), compress them into one step showing the key attempts and the final resolution.
+  - End with "Outcome:" summarizing the final result of the overall task.
+
+  **Key steps preservation rules** — these MUST be kept verbatim (not paraphrased):
+  - **Commands**: Shell commands, CLI invocations, API calls — preserve the exact command string (e.g., `pip install --upgrade torch==2.1.0`, `curl -X POST ...`, `git rebase -i HEAD~3`)
+  - **Core code**: Function signatures, key logic snippets, configuration values, regex patterns, SQL queries — preserve the actual code that solved the problem (keep it minimal but exact)
+  - **File paths**: Exact file/directory paths that were read, modified, or created
+  - **Error messages**: Key error strings or status codes that drove the diagnosis
+  - **Numeric results**: Metrics, thresholds, counts, versions that matter to the outcome
+
+  **What to compress or omit**:
+  - Lengthy tool output exploration (summarize findings in 1 line)
+  - Intermediate reasoning that did not change the approach
+  - Boilerplate and repeated patterns (mention once, note repetition count)
+  - Verbose file contents (summarize, but keep the critical lines verbatim)
+
+- **key_insight**: The single most critical decision, strategy shift, or knowledge application that enabled success. NOT a step summary — the pivotal moment that a different agent lacking this insight would fail at. Focus on the REASONING PRINCIPLE, not the specific domain content. **Max 40 tokens.**
+
+  **Strategy transitions are the highest-value insights.** If the agent fundamentally changed its approach mid-task (e.g., from tool-driven exploration to knowledge-driven hypothesis, from one problem framing to another), that transition IS the key insight. Capture:
+  - What was the agent doing before (and why it failed)
+  - What triggered the change
+  - What the agent did after (and why it succeeded)
+
+  A key_insight that merely describes "what was done" is WRONG. A key_insight that explains "why the approach shifted and why the new approach worked" is RIGHT.
+
+- **quality_score**: A score from 0.0 to 1.0 measuring **task completion and deliverable quality** — NOT effort, exploration depth, or number of steps attempted.
+
+  **Scoring rubric (outcome-oriented):**
+  - **0.9 - 1.0**: Task fully completed. All requirements met, deliverable produced and verified working.
+  - **0.7 - 0.8**: Task mostly completed. Primary deliverable produced but with minor gaps (e.g., works but not fully optimized, passes most but not all test cases, meets 4 of 5 requirements).
+  - **0.4 - 0.6**: Task partially completed. Some concrete deliverable produced but significant requirements unmet (e.g., code written but fails tests, 2 of 5 sub-tasks done, output produced but incorrect).
+  - **0.1 - 0.3**: Task mostly failed. Minimal or no deliverable produced despite attempts. Includes: extensive exploration without producing the required output, environment setup done but core task not started, approach identified but not executed.
+  - **0.0**: No meaningful progress toward the task goal.
+
+  **Critical scoring rules:**
+  - Score based on the FINAL state of the deliverable, not the journey. A task that explored 10 approaches but produced no output = low score.
+  - "Timed out before completing" with no deliverable = 0.1-0.2 (not 0.5+).
+  - External blockers (e.g., resource unavailable, OOM kill, network restriction) that prevent completion = score the actual output achieved, not what would have been achieved.
+  - A well-structured approach that was never executed is NOT a partial success — it is a failure to deliver.
+
+Return in JSON format:
+{{
+    "task_intent": "The specific task as a self-contained statement (max 50 tokens)",
+    "approach": "1. <sub-problem>\n   - Tried: <what was attempted, tool or reasoning>\n   - Result: <what was found/achieved or why it failed>\n2. <next sub-problem>\n   - Tried: <attempt>\n   - Result: <outcome>\n...\n\nOutcome: <final result of the overall task>",
+    "key_insight": "The pivotal decision or knowledge application that enabled success (max 40 tokens)",
+    "quality_score": 0.0-1.0
+}}

package/dist/prompts/case-filter.md

@@ -0,0 +1,34 @@
+Determine whether this agent interaction is worth extracting as a reusable problem-solving experience. Apply a HIGH threshold — only extract interactions that clearly demonstrate a complete problem-solving process.
+
+The interaction may be pure conversation OR contain a single round of tool calls. Both types must meet the same quality bar.
+
+Conversation:
+{messages}
+
+SKIP (return {{"worth_extracting": false}}) — default unless clearly valuable:
+- Casual chitchat, greetings, small talk
+- Opinion/preference exchange with no actionable outcome
+- Simple factual Q&A (e.g., "What is X?" with a direct answer)
+- Single-turn Q&A (one user message + one assistant response)
+- Multi-turn but loosely related topics (user asks unrelated follow-ups, no progressive deepening)
+- Information gathering without problem resolution (user asks questions but no concrete problem is solved)
+- Generic advice that anyone could give (e.g., "try restarting", "check the docs")
+- Lifestyle or personal preference conversations (e.g., activity planning, movie/book/food discussions, hobby sharing, travel recommendations) — these are inherently personal and lack a transferable problem-solving methodology
+- Emotional support or empathetic conversations without a concrete, replicable resolution strategy
+- Single-round tool call that performs a trivial lookup or simple data fetch without meaningful reasoning, diagnosis, or multi-step problem solving (e.g., a single search call that returns a direct answer)
+- Conversations where the assistant only uses basic conversational competence — structured lists, follow-up questions, empathetic acknowledgment, curated recommendations, topic transitions. These are standard LLM dialogue patterns, NOT domain-specific problem-solving expertise
+- Recommendation or suggestion conversations (e.g., "what movie should I watch", "what should I cook", "where should I travel") — even if multi-turn with progressive refinement, unless the recommendation requires specialized technical diagnosis or domain expertise beyond general knowledge
+- Conversations where the "problem" is merely a personal decision or preference choice (e.g., choosing a hiking trail, picking a recipe, selecting a gift) rather than a technical/analytical problem with objectively verifiable steps
+
+EXTRACT (return {{"worth_extracting": true}}) — ALL conditions must be met:
+1. A specific, concrete problem is identified (not vague or generic)
+2. The conversation shows progressive deepening: each turn builds on the previous, narrowing down the solution
+3. The problem reaches a resolution or clear actionable conclusion
+4. The approach involves non-trivial reasoning, diagnosis, or domain expertise that would be valuable to replay
+5. The solution methodology is transferable — a different agent facing a similar problem class could follow the same steps to reach a similar outcome (personal taste, lifestyle advice, and subjective recommendations do NOT qualify)
+6. The extracted skill would go BEYOND baseline LLM capabilities — ask: "Would a competent LLM without this experience handle this significantly worse?" If the answer is no, it is not worth extracting. Examples of baseline capabilities that do NOT qualify: making structured suggestion lists, asking clarifying questions, showing empathy, giving general-knowledge recommendations, summarizing information
+
+**Borderline cases** — when you are unsure, lean toward SKIP.
+
+Return JSON:
+{{"worth_extracting": true/false, "reason": "1 sentence, less than 20 tokens"}}

package/dist/prompts/case-rerank.md

@@ -0,0 +1,12 @@
+Determine whether each agent execution case's task and approach are useful for addressing the user query, preferring cases whose verified successful approach (high `quality_score`) directly applies to the query's problem. Score each case from 0.0 (no transferable experience) to 1.0 (same task pattern with a verified successful approach).
+
+User query:
+{query}
+
+Candidates (JSON array; each item has `id`, `score`, plus metadata like `task_intent`, `approach`, `quality_score`, `key_insight`):
+{candidates_json}
+
+Return at most {top_k} items, sorted by score descending. Drop candidates whose score would be near 0.
+
+Output strictly the following JSON, no prose:
+{{"ranked": [{{"id": "<candidate_id>", "score": <float in 0..1>}}]}}

package/dist/prompts/cluster-assign.md

@@ -0,0 +1,25 @@
+You are a clustering expert. Your goal is to group similar and related tasks together so that patterns and reusable strategies can be extracted from each cluster. Assign the new task intent to an existing cluster, or signal a new cluster if no existing cluster fits.
+
+[How to decide]
+The goal of clustering is to group cases that would produce a **specific, actionable skill** — not generic advice. Use this test: "Would an agent who solved one task in this cluster have a **concrete advantage** (reusable tools, domain knowledge, verified strategies) when facing the other tasks?"
+
+1. **Identify two dimensions**: the task's **subject domain** (e.g., medical research, urban planning, e-commerce) and its **problem-solving pattern** (e.g., root cause analysis, constraint satisfaction, data pipeline design).
+2. **Cluster by the more specific dimension**. If the domain is already narrow (e.g., "clinical trial data extraction"), domain alone is enough. If the domain is broad (e.g., "software engineering"), use the problem-solving pattern to differentiate (e.g., "performance profiling" vs. "schema migration").
+3. **Do NOT merge across unrelated domains just because the strategy is similar.** "Diagnose a patient's symptoms via differential diagnosis" and "diagnose a supply chain bottleneck via constraint analysis" both use diagnostic reasoning, but involve completely different domain knowledge and belong in separate clusters.
+4. Scan candidate clusters. Prefer the cluster whose existing items would **benefit most from sharing a skill** with the new task.
+5. Signal a new cluster (idx: -1) only when no candidate cluster is a good fit.
+
+[Candidate Clusters]
+Each cluster is represented by its list index (idx), item count, and recent preview texts.
+{clusters_json}
+
+[New Task Intent]
+{memcell_text}
+
+[Rules]
+- Output decision as JSON. Keep "reason" under 50 tokens.
+- To assign to an existing cluster: use its idx (non-negative integer).
+- To create a new cluster: use idx -1.
+
+Return ONLY valid JSON (no markdown fences, no explanation):
+{{"idx": <existing_idx or -1>, "reason": "short reason"}}

package/dist/prompts/episode.md

@@ -0,0 +1,65 @@
+
+You are an episodic memory generation expert. Please convert the following conversation into an episodic memory.
+
+Conversation start time: {conversation_start_time}
+Conversation content:
+{conversation}
+
+Custom instructions:
+{custom_instructions}
+
+IMPORTANT TIME HANDLING:
+- Use the provided "Conversation start time" as the exact time when this conversation/episode began
+- When the conversation mentions relative times (e.g., "yesterday", "last week"), preserve both the original relative expression AND calculate the absolute date
+- Format time references as: "original relative time (absolute date)" - e.g., "last week (May 7, 2023)"
+- This dual format supports both absolute and relative time-based questions
+- All absolute time calculations should be based on the provided start time
+
+Please generate a structured episodic memory and return only a JSON object containing the following two fields:
+{{
+    "title": "A concise, descriptive title that accurately summarizes the theme (10-20 words)",
+    "content": "A concise factual record of the conversation in third-person narrative. It must include all important information: who participated at what time, what was discussed, what decisions were made, what emotions were expressed, and what plans or outcomes were formed. Write it as a chronological account focusing on observable actions and direct statements. Remove redundant expressions and verbose descriptions while preserving all facts, entities (names, dates, locations), and specific details. Keep the content concise without losing key information. Use the provided conversation start time as the base time for this episode."
+}}
+
+Requirements:
+1. The title should be specific and easy to search (including key topics/activities).
+2. The content must include all important information from the conversation while being concise.
+3. Convert the dialogue format into a narrative description.
+4. Maintain chronological order and causal relationships.
+5. Use third-person unless explicitly first-person.
+6. Include specific details that aid keyword search, especially concrete activities, places, and objects.
+7. For time references, use the dual format: "relative time (absolute date)" to support different question types.
+8. When describing decisions or actions, naturally include the reasoning or motivation behind them, but avoid repetitive explanations.
+9. Use specific names consistently rather than pronouns to avoid ambiguity in retrieval.
+10. CONCISENESS AND REDUNDANCY REMOVAL:
+    - Remove redundant expressions and verbose descriptions
+    - Avoid repeating the same information in different ways
+    - Eliminate unnecessary filler words and phrases
+    - Keep sentences direct and to the point
+    - Preserve all facts, entities (names, dates, locations), and specific details
+    - Maintain the core meaning and important information
+    - Aim for content length similar to or shorter than the original conversation
+11. CRITICAL DETAIL PRESERVATION:
+   - Person Names: Always include full names of people mentioned (e.g., "went to yoga with Amy's colleague, Rob" not just "went to yoga with a colleague")
+   - Special Nouns & Entities: Preserve all proper nouns, brand names, place names, organization names exactly as mentioned
+   - Item Names: Include specific product names, book titles, movie names, restaurant names, etc.
+   - Quantities & Numbers: Record exact numbers, amounts, prices, percentages, dates, times (e.g., "ordered 3 pizzas" not "ordered pizzas")
+   - Specific Activities: Use precise activity descriptions (e.g., "practiced hot yoga" not just "exercised")
+   - Time Points: Include all specific times mentioned (e.g., "at 3:30 PM", "every Tuesday", "twice a week")
+12. FREQUENCY INFORMATION:
+   - Record recurring activities and their frequency (e.g., "goes to yoga class every Tuesday and Thursday")
+   - Note patterns of behavior (e.g., "mentioned calling mom three times during the conversation")
+   - Include habitual actions (e.g., "usually has coffee at 8 AM before work")
+   - Document repetition counts (e.g., "asked about the project status twice")
+13. Language: write the title and content in the dominant language of the conversation. A predominantly Chinese conversation MUST be summarized in Chinese; a predominantly English conversation in English. Never mix unless the conversation itself mixes.
+
+
+Example:
+If the conversation start time is "March 14, 2024 (Thursday) at 3:00 PM UTC" and the conversation is about Caroline planning to go hiking:
+{{
+    "title": "Caroline's Mount Rainier Hiking Plan March 14, 2024: Weekend Adventure Planning Session",
+    "content": "On March 14, 2024 at 3:00 PM UTC, Caroline expressed interest in hiking this weekend (March 16-17, 2024) and sought advice. She wanted to see the sunrise at Mount Rainier. When asked about gear by Melanie, Caroline received suggestions: hiking boots, warm clothing, flashlight, water, and high-energy food. Caroline decided to leave early Saturday morning (March 16, 2024) to catch the sunrise and planned to invite friends. She was excited about the trip."
+}}
+
+Return only the JSON object, do not add any other text:
+Use strict JSON syntax. Escape double quotes and backslashes inside string values, and encode line breaks as \n. Quoted dialogue, paths, code, and braces are part of the content string and must remain inside it. Do not use unescaped quotes, literal line breaks inside strings, or trailing commas.

package/dist/prompts/episodic-rerank.md

@@ -0,0 +1,12 @@
+Given the user query and a list of retrieved episodic memories (or atomic facts extracted from them), determine whether each candidate contains information relevant to answering the query. Score each candidate from 0.0 (no relevant information) to 1.0 (directly answers the query).
+
+User query:
+{query}
+
+Candidates (JSON array; each item has `id`, `score`, an `item_type` of either `episode` or `atomic_fact`, plus metadata like `episode` / `subject` / `summary` / `parent_episode_id`):
+{candidates_json}
+
+Return at most {top_k} items, sorted by score descending. Drop candidates whose score would be near 0.
+
+Output strictly the following JSON, no prose:
+{{"ranked": [{{"id": "<candidate_id>", "score": <float in 0..1>}}]}}