@rudderhq/agent-runtime-codex-local 0.3.6-canary.1 → 0.3.6-canary.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rudderhq/agent-runtime-codex-local",
-  "version": "0.3.6-canary.1",
+  "version": "0.3.6-canary.3",
   "license": "SEE LICENSE IN LICENSE",
   "homepage": "https://github.com/Undertone0809/rudder",
   "bugs": {
@@ -68,7 +68,7 @@
     "probe:quota": "pnpm exec tsx src/cli/quota-probe.ts --json"
   },
   "dependencies": {
-    "@rudderhq/agent-runtime-utils": "0.3.6-canary.1",
+    "@rudderhq/agent-runtime-utils": "0.3.6-canary.3",
     "picocolors": "^1.1.1"
   },
   "devDependencies": {

package/skills/para-memory-files/SKILL.md

@@ -166,26 +166,52 @@ Memory does not survive session restarts. Files do.
 - Make a mistake -> document it so future-you does not repeat it.
 - On-disk text files are always better than holding it in temporary context.
 
-## Memory Recall -- Use The Files Directly
+## Memory Recall -- Use File-Based Memory Search
 
 Use the on-disk structure directly. Do not require a semantic index just to
-recall memory.
+recall memory. The files are the source of truth; search is only the triage step
+for locating the right file, then claims must be verified against the stored
+fact or note.
 
 Recall order:
 
 1. If you already know the entity, open `summary.md` first, then `items.yaml`
    only if the summary is insufficient.
 2. For recent events, read today's and nearby `memory/YYYY-MM-DD.md` files.
-3. For unknown keywords or broad recall, use `rg` across `$AGENT_HOME/life/`
-   and `$AGENT_HOME/memory/`.
+3. For broad recall or unknown entity paths, run Memory Search Mode.
+
+### Memory Search Mode
+
+Use this mode when the request sounds like "what do we know about...", "have we
+seen this before...", "what did the user prefer...", or when plain directory
+search would return too many matches.
+
+1. Define the search target in one sentence: subject, likely entity, timeframe,
+   project, and answer shape.
+2. Build 3-6 focused query terms: exact phrase, synonyms, likely entity names,
+   project names, and durable-signal words such as `preference`, `decision`,
+   `lesson`, `handoff`, `constraint`, or `review`.
+3. Search scoped roots separately so results can be ranked by source type:
 
 ```bash
-rg -n "Christmas" "$AGENT_HOME/life" "$AGENT_HOME/memory"
-rg -n "specific phrase" "$AGENT_HOME/life" "$AGENT_HOME/memory"
+rg -n -i "review|handoff|preference" "$AGENT_HOME/life" "$AGENT_HOME/memory"
+rg -n -i "review|handoff|preference" "$RUDDER_PROJECT_LIBRARY_ROOT"
 ```
 
-The files are the source of truth. Search is only a way to locate the right
-file, then verify against the stored fact or note.
+4. Rank candidate files before opening many of them:
+   - entity `summary.md` over `items.yaml` for quick context;
+   - active `items.yaml` facts over superseded facts;
+   - recent daily notes over old daily notes for event recall;
+   - newest dated shared work notes over older notes;
+   - files matching multiple query terms over single-term matches;
+   - paths in the current project or organization over unrelated roots.
+5. Open the top 3-7 candidate files, not every match. Read enough surrounding
+   context to verify the fact, date, status, and source.
+6. Answer from verified memory only. Cite the file paths used, mention conflicts
+   or weak matches, and say when no reliable memory was found.
+
+Do not dump raw `rg` output as the answer. Do not treat a keyword hit as a fact
+until the source file has been opened and checked.
 
 ## Shared Work Notes
 

package/skills/para-memory-files/evals/conversation-capture.md

@@ -126,3 +126,29 @@ Must not:
   memory.
 - Ignore the attachment-driven reinterpretation when forming future task
   context.
+
+### Case: Broad Memory Recall Needs Search Triage
+
+Input:
+
+A user asks: "What do we know about my previous preferences for agent review
+handoffs?" There is no known entity path, and the relevant notes may live across
+life summaries, daily notes, or shared project Library files.
+
+Expected behavior:
+
+- Build a focused memory-search query set from concrete terms, synonyms,
+  likely entities, and date/project hints before reading files.
+- Search the likely memory roots and return a short ranked candidate list
+  grouped by source type, preferring entity `summary.md`, active facts, recent
+  daily notes, and newest shared work notes.
+- Open only the strongest candidate files, verify claims against stored facts
+  or notes, and cite the file paths used.
+- State uncertainty when matches are weak or conflicting.
+
+Must not:
+
+- Dump raw `rg` output as the answer.
+- Read every matching file without ranking.
+- Treat keyword matches as facts before opening and verifying the source file.
+- Ignore newer dated notes or superseded facts when older matches exist.

package/skills/para-memory-files/references/schemas.md

@@ -64,3 +64,29 @@ Facts decay in retrieval priority over time so stale info does not crowd out rec
 **Weekly synthesis:** Sort by recency tier, then by access_count within tier. Cold facts drop out of the summary but remain in items.yaml. Accessing a cold fact reheats it.
 
 No deletion. Decay only affects retrieval priority via summary.md curation. The full record always lives in items.yaml.
+
+## Memory Search Result Rules
+
+When broad recall uses file search, results are candidates, not facts. Open the
+candidate file and verify the stored note or YAML item before answering.
+
+Rank candidates with this bias:
+
+- `summary.md` gives the fastest current entity context.
+- `items.yaml` is authoritative for atomic facts; ignore facts with
+  `status: superseded` except to explain history or follow `superseded_by`.
+- Daily notes are authoritative for raw timeline and conversation capture.
+- Newer dated shared work notes usually supersede older shared notes unless the
+  older file explicitly remains active.
+- Multiple matching terms in one file are stronger than one isolated match.
+
+When a fact is used in the final answer, update access metadata when practical:
+
+```yaml
+last_accessed: "YYYY-MM-DD"
+access_count: 1
+```
+
+Answers should cite the memory file path or Rudder-renderable Library reference
+used, state when evidence is weak, and avoid exposing raw private transcript
+text unless the exact wording is necessary and safe.