@voidwire/llm-summarize 3.9.4 → 3.10.1

package/index.ts

@@ -28,13 +28,16 @@ export interface SessionInsights {
   // Optional fields populated by custom prompts (e.g., Lore injection)
   extractions?: Extraction[];
   keywords?: string[];
-  // Insights mode fields
+  // Insights mode fields (delta extraction)
   current_focus?: string;
   next_steps?: string[];
   decisions?: string[];
+  corrections?: string[];
+  validated?: string[];
+  problems_solved?: string[];
+  // Legacy fields — kept for backward compatibility with existing session JSONL data
   patterns_used?: string[];
   preferences_expressed?: string[];
-  problems_solved?: string[];
 }
 
 export interface SummarizeResult {
@@ -83,53 +86,73 @@ Output JSON only: {"summary": "One sentence summary"}`;
  * Note: userName param kept for API compatibility but not used in insights mode
  */
 function buildInsightsPrompt(_userName?: string): string {
-  return `You are a session state extractor. Given a development conversation, produce a JSON snapshot of the session's current state.
+  return `You are a session delta extractor. Given a development conversation and the previous state snapshot, extract ONLY what is NEW since the last snapshot.
 
 <instructions>
-1. Read the conversation in the <transcript> section
-2. Ignore the <previous_state> section — it is background context only, not part of this session
-3. Extract ONLY what happened in the transcript
-4. Produce a JSON object with the fields described below
+1. Read the <previous_state> section — this is what was already known
+2. Read the <transcript> section — this is what happened since
+3. Extract ONLY new information not already captured in previous_state
+4. Skip any lines containing markers (📁 CAPTURE, 📚 TEACH, 👤 OBSERVE, 🗣️, ─── REFLECT) — these are handled by a separate system
+5. Focus on: what decisions were made, what changed direction, what the user corrected, what approach was validated
+6. Produce a JSON delta object
 </instructions>
 
 <fields>
-- summary: One sentence describing what was accomplished this session
-- current_focus: The specific task or feature being worked on (omit if exploratory)
-- next_steps: Array of concrete next actions. Name the specific task.
-- decisions: Array of decisions made this session, each with rationale
-- patterns_used: Array of techniques or approaches applied, each with context
-- preferences_expressed: Array of user preferences revealed through direction or correction
-- problems_solved: Array of problems encountered with root cause and fix
+- summary: One sentence — what CHANGED since last snapshot, not a re-summary of the whole session
+- current_focus: The specific task or topic right now (omit if unchanged from previous_state)
+- decisions: New decisions only — include the rationale ("X because Y"). Skip if already in previous_state.
+- corrections: Things the user pushed back on or redirected. Quote their words when possible.
+- validated: Approaches the user approved or confirmed worked. Only when non-obvious.
+- next_steps: Concrete next actions that emerged THIS turn. Name specifics.
+- problems_solved: New problems with root cause and fix. Skip re-statements.
 </fields>
 
-Include a field only when the transcript contains clear evidence. Omit empty arrays. Every value must be a complete sentence.
+<rules>
+- If nothing meaningful changed since previous_state, return {"summary": "continuation", "current_focus": "unchanged"}
+- NEVER repeat information from previous_state — this is a delta, not a snapshot
+- NEVER copy text from the examples below into your output — examples show structure only, your content must come exclusively from the transcript
+- "User clarified X" is NOT a correction — only record corrections when the user explicitly redirects, rejects, or changes direction
+- Every field value must be specific enough to be useful 6 months from now without context
+- If no approaches were validated this turn, omit the validated field entirely
+</rules>
 
 <example>
 <input>
-<previous_state>Focus: Building authentication system</previous_state>
+<previous_state>
+## Context
+- **Focus:** Spaceship navigation module
+- Chose warp drive over hyperspace — fewer dimensional side effects
+## Next
+- Test warp field calculations
+</previous_state>
 <transcript>
-User Asked: Let's use JWT instead of sessions for auth
-Assistant Response: Switched from express-session to jsonwebtoken. JWTs are stateless so we don't need Redis for session storage anymore. Updated the middleware to verify tokens on each request.
-User Asked: Make sure the tokens expire after 24 hours
-Assistant Response: Set expiresIn to 24h in the sign options. Also added a refresh token flow so users don't get logged out mid-work.
+User: Actually let's use hyperspace after all — the crew is more familiar with it and we already have the motivator installed
+Assistant: Switched back to hyperspace engine with the existing motivator. Removed the warp field generator.
+User: Good. And set the jump cooldown to 8 parsecs not the default 24.
 </transcript>
 </input>
 <output>
-{"summary":"Implemented JWT-based authentication replacing session-based auth, with 24-hour token expiry and refresh token flow","current_focus":"Authentication system implementation","next_steps":["Test the refresh token flow with expired tokens","Add token revocation for logout"],"decisions":["Chose JWT over sessions — eliminates Redis dependency since tokens are stateless","Set 24-hour token expiry with refresh flow — balances security with user convenience"],"preferences_expressed":["User directed specific token expiry of 24 hours"]}
+{"summary":"Reversed warp drive decision back to hyperspace — crew familiarity and existing motivator hardware","current_focus":"Hyperspace navigation","decisions":["Reverted to hyperspace engine — crew familiarity outweighs warp drive benefits, motivator already installed"],"corrections":["User reversed the warp drive decision after initial implementation — crew constraints weren't considered"],"next_steps":["Configure 8-parsec jump cooldown","Remove warp field generator dependencies"]}
 </output>
 </example>
 
 <example>
 <input>
-<previous_state>Focus: Investigating test failures</previous_state>
+<previous_state>
+## Context
+- **Focus:** Debugging potion brewing test failures
+- Fixed expired ingredient timestamp in tests
+## Next
+- Verify cauldron CI passes
+</previous_state>
 <transcript>
-User Asked: The CI is failing on the webhook tests
-Assistant Response: Found the issue — the test was using a hardcoded timestamp that expired. Changed it to use a relative timestamp. Also found that the webhook handler had a race condition where two events could arrive simultaneously and both pass the idempotency check. Added a mutex lock.
-User Asked: Good catch on the race condition
+User: CI is green now. Let's move on to the invisibility cloak renderer.
+Assistant: Starting on the cloak renderer. I'll use a phase-shift approach with mithril threading.
+User: Sounds good.
 </transcript>
 </input>
 <output>
-{"summary":"Fixed CI test failure caused by hardcoded timestamp and discovered a race condition in the webhook handler","current_focus":"Webhook test failures and handler reliability","problems_solved":["Fixed expired hardcoded timestamp in webhook tests — replaced with relative timestamp calculation","Fixed race condition in webhook handler where simultaneous events bypassed idempotency check — added mutex lock"],"next_steps":["Verify CI passes with the timestamp and mutex fixes"]}
+{"summary":"Potion CI fixed, pivoted to invisibility cloak renderer","current_focus":"Invisibility cloak renderer implementation","validated":["Phase-shift rendering with mithril threading — user approved the approach"],"next_steps":["Implement phase-shift cloak renderer with mithril threading"]}
 </output>
 </example>
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voidwire/llm-summarize",
-  "version": "3.9.4",
+  "version": "3.10.1",
   "description": "Structured session insight extraction for knowledge systems",
   "type": "module",
   "main": "./index.ts",