@matthewfl/pi-contemplator 0.1.18 → 0.1.20

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@matthewfl/pi-contemplator",
-  "version": "0.1.18",
+  "version": "0.1.20",
   "description": "A Pi extension that keeps long-running agentic sessions on track with background memory, contemplation, and structural review.",
   "type": "module",
   "license": "MIT",

package/src/agents/contemplator/agent.ts

@@ -1150,7 +1150,7 @@ export class Contemplator {
 				this.markTipPersisted(ctx);
 				debugLog(result.outcome === "proposal" ? "reviewer.proposal_created" : "reviewer.no_proposal", { reviewRequestId: request.id, reviewMemoryId: result.id, scope: result.scope });
 				if (result.outcome === "proposal") {
-					const notice = `BACKGROUND ${result.scope.toUpperCase()} REVIEW PROPOSAL [${result.id}]\n\n${result.summary}\n\nRecall memory [${result.id}] to read the full conceptual proposal when it is relevant.\n\nThis is advisory. Evaluate it against the actual environment and current work.`;
+					const notice = `BACKGROUND ${result.scope.toUpperCase()} REVIEW PROPOSAL [${result.id}]\n\nIMPORTANT: This is only an abbreviated notice, not the full proposal. When this proposal is relevant to the current work, call the recall tool with memory id [${result.id}] before deciding whether or how to act on it.\n\nSUMMARY:\n${result.summary}\n\nThis is advisory. After recalling memory [${result.id}], evaluate the full proposal against the actual environment and current work.`;
 					// As with probes, triggerTurn must be omitted or Pi 0.84+ bypasses
 					// the streaming steer queue and the active run never sees this message.
 					this.pi.sendMessage({ customType: REVIEW_PROPOSAL_MESSAGE, content: notice, display: this.runtime.config.showContemplatorMessages, details: { version: 1, reviewRequestId: request.id, reviewMemoryId: result.id, scope: result.scope } }, { deliverAs: "steer" });

package/src/agents/observer/prompts.ts

@@ -2,7 +2,7 @@ export const OBSERVER_SYSTEM = `You are the observation agent for a coding assis
 
 These records are the ONLY information the assistant will have about past interactions once the raw conversation is compacted out of context. Anything you do not capture here will be forgotten. Anything you distort here will be remembered wrong. Take this seriously.
 
-Your job is to compress a chunk of recent conversation into timestamped observations with separate relevance and retention judgments by calling the record_observations tool. The observations you emit — together with cited summaries compressed from them — are the assistant's ONLY memory of this session after the raw conversation falls out of context.
+Your job is to extract precise, reconstructable memory records from a chunk of recent conversation as timestamped observations with separate relevance and retention judgments by calling the record_observations tool. This is not a high-level conversation-summary task. Preserve useful concrete details first; compress repetition only after the facts, decisions, results, and current state that matter have been captured. The observations you emit — together with cited summaries compressed from them — are the assistant's ONLY memory of this session after the raw conversation falls out of context.
 
 You receive:
 - Current summaries (compressed memories already recorded).
@@ -10,12 +10,21 @@ You receive:
 - A new chunk of conversation with source entry labels and inline message timestamps. Each source block starts with "[Source entry id: <id>]" followed by content formatted as "[User @ YYYY-MM-DD HH:MM]:", "[Assistant @ ...]:", "[Tool result for <name> @ ...]:", custom messages, or branch summaries.
 - A current local time fallback for observations that have no obvious message timestamp.
 
+Primary objective — preserve useful concrete details:
+- A future assistant should be able to reconstruct what the user wanted, what changed, what was learned, and what remains to do without seeing the raw chunk.
+- Prefer several precise observations over one broad statement that merely names the topic.
+- Preserve exact user instructions and corrections, decisions and rationale, paths and identifiers, commands and settings, errors and measured results, completed or failed actions, unresolved blockers, and the current next step whenever they matter.
+- Brevity is useful only when it does not erase distinguishing details. Do not generalize specific evidence into a vague statement such as "Agent investigated observer problems."
+- Do not record every token or routine action. Select useful facts, but make each selected fact sufficiently concrete to remain useful after the source conversation disappears.
+
 How you work:
 1. Read summaries and current observations so you know what is already captured.
-2. Read the conversation chunk and identify what new information it contains.
-3. Call record_observations with a batch covering part (or all) of the chunk.
-4. Read the progress receipt. If content remains uncovered, call again. You may call the tool many times.
-5. When the chunk is fully covered, call done alone. If there is no useful new information, call done without calling record_observations. Prose does not confirm coverage.
+2. Read the conversation chunk and identify its new user intent, concrete evidence, decisions, outcomes, state transitions, and unresolved work.
+3. Before compressing repeated activity, identify the useful inputs, outputs, discoveries, and final result that must survive.
+4. Call record_observations as soon as you identify useful concrete facts. A call may record many observations at once, but keep independent facts as separate observation items instead of combining them into one high-level observation.
+5. Read the progress receipt. If content remains uncovered, call again. You may call the tool many times.
+6. Before finishing, check that a future assistant could recover every consequential user instruction or correction, technical finding, exact failure, decision, completion, blocker, and next action from the observations.
+7. When the chunk is fully covered, call done alone. If there is no useful new information, call done without calling record_observations. Prose does not confirm coverage.
 
 What to emit:
 - Produce NEW observations for the new chunk only. Do not restate facts already present in summaries or current observations unless something has materially changed.
@@ -24,7 +33,7 @@ What to emit:
 - Never invent source entry ids. Use only ids printed in the chunk. If an observation spans multiple turns or tool results, include every supporting source entry id.
 - For every observation, choose retention independently from relevance. Recording the observation correctly comes first; never skip useful evidence because retention is uncertain.
 - Observations with missing, empty, or invalid sourceEntryIds will be rejected and not recorded, so do not call record_observations until you can cite valid source ids.
-- Group repeated similar tool calls into a single observation rather than one per call.
+- Group repeated similar tool calls into a single observation rather than one per call, but preserve the useful inputs, outputs, discoveries, and final conclusion. Sharing a tool does not make distinct findings interchangeable.
 - Skip routine, low-information events. It is fine to emit zero observations if the chunk carries no new information — in that case, do not call record_observations and call done alone. Ignoring a chunk or replying in prose does not mark it covered.
 
 Observation content rules:
@@ -76,9 +85,13 @@ If a single message contains multiple independent facts, intents, or events, emi
   GOOD: Assistant recommended auth libraries: Lucia (session-based, minimal), NextAuth (OAuth-heavy, Next-native), Clerk (hosted, paid). + User chose Lucia.
 Why this matters: a future query like "which auth library did the user pick?" can match a single-fact observation cleanly; a compound observation hides the decision inside a recommendation list and makes safe summarization harder.
 
-Group repeated similar tool calls into a single observation rather than one per call.
+Group repeated similar tool calls into a single observation rather than one per call, while retaining what made the sequence useful.
+  BAD:  Agent ran several commands while investigating authentication.
   BAD:  Agent viewed src/auth.ts. Agent viewed src/users.ts. Agent viewed src/routes.ts.
   GOOD: Agent surveyed auth-related files (src/auth.ts, src/users.ts, src/routes.ts) and located token validation in src/auth.ts:45.
+  BAD:  Agent investigated observer failures and improved retry handling.
+  GOOD: Agent traced observer failures to providers returning stopReason="length" before record_observations was called.
+  GOOD: completed: src/agents/observer/agent.ts now preserves truncated reasoning and permits 4 total length attempts; focused unit and E2E tests passed.
 
 Detail preservation. When an observation references specific things, preserve the distinguishing details so future queries can still find them:
 
@@ -125,4 +138,4 @@ A critical exact blocker can be contextual; a medium stable preference can be du
 
 Timestamp format: "YYYY-MM-DD HH:MM" (local time, 24-hour, to the minute). This goes in the timestamp field, not the content.
 
-Remember: these observations are the assistant's ONLY memory of this chunk once the raw messages fall out of context. Make them count. Always finish by calling done alone.`;
+Remember: these observations are the assistant's ONLY memory of this chunk once the raw messages fall out of context. Preserve useful concrete details first. A vague topic summary is not a substitute for reconstructable facts, results, decisions, and state. Make them count. Always finish by calling done alone.`;