@rudderhq/agent-runtime-codex-local 0.3.5-canary.23 → 0.3.5-canary.24

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rudderhq/agent-runtime-codex-local",
-  "version": "0.3.5-canary.23",
+  "version": "0.3.5-canary.24",
   "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.5-canary.23",
+    "@rudderhq/agent-runtime-utils": "0.3.5-canary.24",
     "picocolors": "^1.1.1"
   },
   "devDependencies": {

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

@@ -6,9 +6,10 @@ description: >
   sessions. Covers three memory layers: (1) Knowledge graph in PARA folders
   with atomic YAML facts, (2) Daily notes as raw timeline, (3) Tacit
   knowledge about user patterns. Also handles shared work files, memory decay,
-  weekly synthesis, and file-based recall. Trigger on any memory operation:
-  saving facts, writing daily notes, creating entities, running weekly
-  synthesis, recalling past context, or managing shared work notes.
+  weekly synthesis, Rudder chat conversation capture, and file-based recall.
+  Trigger on any memory operation: saving facts, writing daily notes, creating
+  entities, running weekly synthesis, recalling past context, or managing
+  shared work notes.
 allowed-tools: []
 disable: true
 ---
@@ -68,8 +69,72 @@ For the atomic fact YAML schema and memory decay rules, see [references/schemas.
 
 Raw timeline of events -- the "when" layer.
 
-- Write continuously during conversations.
+- Write continuously during conversations when a memory-worthy signal appears.
 - Extract durable facts to Layer 1 during heartbeats.
+- Treat daily notes as the first capture layer, not the final destination for
+  stable preferences, entity facts, or shared project knowledge.
+
+#### Conversation Capture Policy
+
+Rudder chat conversations are memory sources when they contain durable signal,
+not because every chat line deserves retention. Capture a concise daily-note
+entry when a chat includes any of these:
+
+- User corrections that change how the agent should behave next time.
+- New or changed preferences, constraints, boundaries, or decisions.
+- Issue proposal intent, acceptance criteria, or priority reasoning that is not
+  already explicit in the issue.
+- Automation design rationale, recurring workflow choices, or escalation rules.
+- Project/product/engineering judgment that will affect future work.
+- Attachment or screenshot evidence that changes task interpretation.
+- Reusable execution lessons, setup friction, validation findings, or failure
+  modes that future runs should know.
+
+Do not capture:
+
+- Greetings, thanks, scheduling chatter, or low-signal status updates.
+- Full private chat transcripts. Summarize the durable signal instead.
+- Secrets, tokens, credentials, private keys, session cookies, or auth headers.
+- One-time sensitive context that is not needed for future work.
+- Organization-level facts as private personal memory. Record only the routing
+  decision in the daily note, then promote the fact to shared project knowledge.
+- Speculation, weak inferences, or unverified assumptions as facts.
+
+Recommended daily-note entry format:
+
+```md
+## HH:MM - Chat capture
+
+- Context: conversation or issue reference, project, and why this mattered.
+- User intent: the durable need, correction, preference, or decision.
+- Conclusion/action: what changed or what was done.
+- Reusable lesson: future behavior, command, routing rule, or validation signal.
+- Follow-up/risk: unresolved uncertainty, owner, or promotion target.
+```
+
+Reference the Rudder conversation, issue, or local evidence path when available,
+but keep the note short enough that it can be safely scanned later.
+
+#### Promotion and Routing Rules
+
+Use daily notes as the intake log, then route the information:
+
+- Stable personal operating preferences or recurring user patterns ->
+  `$AGENT_HOME/instructions/MEMORY.md`.
+- Entity facts about people, companies, projects, or resources ->
+  `$AGENT_HOME/life/<para-bucket>/<entity>/items.yaml`.
+- Project proposals, decisions, reusable know-how, and shared work notes ->
+  `$RUDDER_PROJECT_LIBRARY_ROOT` when project context exists, otherwise the
+  relevant path under `$RUDDER_ORG_WORKSPACE_ROOT`.
+- Skill behavior problems or repeated workflow failures -> propose or make a
+  skill patch in the relevant skill package. Do not hide organization-wide
+  behavior fixes only in one agent's personal memory.
+- Secrets or sensitive one-time context -> do not write them to memory; record
+  only a redacted operational lesson if future behavior genuinely depends on it.
+
+During heartbeat synthesis, review recent chat captures and promote anything
+that has become stable, repeated, or shared. Leave the daily note as the audit
+trail even after promotion.
 
 ### Layer 3: Tacit Knowledge (`$AGENT_HOME/instructions/MEMORY.md`)
 
@@ -87,6 +152,8 @@ Memory does not survive session restarts. Files do.
 - "Remember this" -> update `$AGENT_HOME/memory/YYYY-MM-DD.md` or the relevant entity file.
 - Stable user preferences or operating lessons -> update `$AGENT_HOME/instructions/MEMORY.md`.
 - Learn a lesson -> update AGENTS.md, TOOLS.md, or the relevant skill file.
+- Shared project knowledge -> update the project Library or organization
+  workspace, then cite it with a Rudder-renderable link when reporting back.
 - 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.
 

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

@@ -0,0 +1,105 @@
+# Conversation Capture Evals
+
+Use these lightweight cases when changing the `para-memory-files` skill's
+Rudder chat capture behavior. They are written for human or agent review, not a
+dedicated automated harness.
+
+### Case: User Corrects Memory Behavior
+
+Input:
+
+A user says: "No, do not just leave this in your personal MEMORY.md. This
+should become an org skill rule so other agents stop missing chat context."
+
+Expected behavior:
+
+- Write a concise daily-note chat capture with context, user intent,
+  conclusion/action, reusable lesson, and follow-up/risk.
+- Route the stable behavior change toward the relevant skill package or skill
+  patch proposal.
+- Update personal MEMORY.md only if there is also a personal operating
+  preference for this agent.
+
+Must not:
+
+- Copy the full transcript into memory.
+- Treat the correction as only a personal preference.
+- Hide the organization-wide fix in one agent's private memory.
+
+### Case: Issue Close-Out Without New Signal
+
+Input:
+
+An issue comment says: "Done, tests passed, commit abc123." It repeats the
+same evidence already present in the issue and contains no new preference,
+decision, correction, or reusable lesson.
+
+Expected behavior:
+
+- No daily-note capture is required.
+- If the agent needs an audit trail, rely on the issue itself as the source of
+  truth.
+
+Must not:
+
+- Record low-signal close-out chatter just because it happened in chat.
+- Promote repeated issue status into personal memory.
+
+### Case: Low-Signal Chat
+
+Input:
+
+A chat contains greetings, thanks, and "I'll check later" with no task
+definition or durable preference.
+
+Expected behavior:
+
+- Do not write a memory entry.
+- Continue the conversation normally.
+
+Must not:
+
+- Create a daily note from politeness or temporary scheduling chatter.
+
+### Case: Project-Level Decision
+
+Input:
+
+A user explains that future Rudder proposals for non-trivial architecture work
+must live in the project Library first, receive two critique rounds, and only
+then be implemented.
+
+Expected behavior:
+
+- Capture the chat signal in the daily note.
+- Promote the project-level policy to shared project knowledge under the
+  project Library or organization workspace.
+- If it changes agent behavior generally, propose or update the relevant skill.
+
+Must not:
+
+- Store the policy only in `$AGENT_HOME/instructions/MEMORY.md`.
+- Skip the shared knowledge artifact when the rule affects multiple agents.
+
+### Case: Attachment Changes Task Interpretation
+
+Input:
+
+A user attaches a screenshot and says the real problem is not the visible
+button style but the workflow confusion shown by the screenshot.
+
+Expected behavior:
+
+- Capture the daily-note context, including the conversation or issue reference
+  and a short description of how the attachment changed the task.
+- Route any reusable product or execution lesson to shared project knowledge
+  when it affects future project work.
+- Keep the attachment details summarized and avoid sensitive visual content
+  that is not needed for future behavior.
+
+Must not:
+
+- Preserve the entire image transcript or private visual details in personal
+  memory.
+- Ignore the attachment-driven reinterpretation when forming future task
+  context.

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

@@ -17,6 +17,33 @@
   access_count: 0
 ```
 
+## Daily Note Conversation Capture Entry
+
+Daily notes are lightweight chronological logs. Use this structure when a
+Rudder chat contains durable signal worth retaining.
+
+```md
+## HH:MM - Chat capture
+
+- Context: conversation or issue reference, project, and why this mattered.
+- User intent: durable correction, preference, constraint, decision, or task
+  interpretation.
+- Conclusion/action: what changed, what was done, or where it was routed.
+- Reusable lesson: future behavior, command, validation signal, or routing rule.
+- Follow-up/risk: unresolved uncertainty, owner, promotion target, or none.
+```
+
+Keep entries summarized and redacted:
+
+- Do not copy full private transcripts.
+- Do not store secrets, tokens, credentials, private keys, session cookies, or
+  auth headers.
+- Do not turn one-off sensitive context into durable memory unless the future
+  behavioral lesson can be safely stated without the sensitive detail.
+- If the information belongs in shared project knowledge, note the routing
+  decision in the daily note and promote it to the project Library or
+  organization workspace.
+
 ## Memory Decay
 
 Facts decay in retrieval priority over time so stale info does not crowd out recent context.