feat(recap): add 'fix' entry type for tracking code review resolutions

acreeger · claude · acreeger · commit c077b30fe336 · 2026-03-22T20:23:01.000-04:00
Add a new recap entry type 'fix' so agents can log when code review findings are addressed. Updated across type definitions, Zod schemas, all prompt templates, agent docs, and tests. Closes #960 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
diff --git a/src/mcp/CLAUDE.md b/src/mcp/CLAUDE.md
@@ -18,7 +18,7 @@ Exposes issue/PR operations to agents. Provider-agnostic — routes to GitHub, L
 
 ### recap-server.ts
 
-Manages the recap system — structured knowledge capture (decisions, insights, risks, artifacts) displayed in the VS Code sidebar.
+Manages the recap system — structured knowledge capture (decisions, insights, risks, fixes, artifacts) displayed in the VS Code sidebar.
 
 **Tools:** `set_goal`, `set_complexity`, `add_entry`, `add_artifact`, `get_recap`, `set_loom_state`, `get_loom_state`
 
diff --git a/src/mcp/recap-server.test.ts b/src/mcp/recap-server.test.ts
@@ -91,6 +91,22 @@ describe('recap-server add_entry deduplication', () => {
 				content: 'Found existing helper function',
 			})
 		})
+
+		it('should create a new fix entry and return skipped: false', async () => {
+			const result = await addEntryWithDeduplication(
+				readRecapMock,
+				writeRecapMock,
+				'fix',
+				'Fixed null check in auth handler per review feedback'
+			)
+			expect(result.skipped).toBe(false)
+			expect(result.id).toBe('test-uuid-123')
+			expect(mockRecapFile.entries).toHaveLength(1)
+			expect(mockRecapFile.entries?.[0]).toMatchObject({
+				type: 'fix',
+				content: 'Fixed null check in auth handler per review feedback',
+			})
+		})
 	})
 
 	describe('when adding an entry with duplicate type and content', () => {
diff --git a/src/mcp/recap-server.ts b/src/mcp/recap-server.ts
@@ -1,7 +1,7 @@
 /**
  * Loom Recap MCP Server
  *
- * Captures session context (goal, decisions, insights, risks, assumptions)
+ * Captures session context (goal, decisions, insights, risks, fixes, assumptions)
  * for the VS Code Loom Context Panel.
  *
  * Environment variables:
@@ -234,7 +234,7 @@ server.registerTool(
 			'Append an entry to the recap. If an entry with the same type and content already exists, it will be skipped.',
 		inputSchema: {
 			type: z
-				.enum(['decision', 'insight', 'risk', 'assumption', 'other'])
+				.enum(['decision', 'insight', 'risk', 'assumption', 'fix', 'other'])
 				.describe('Entry type'),
 			content: z.string().describe('Entry content'),
 			worktreePath: z.string().optional().describe('Optional worktree path to scope recap to a specific loom'),
@@ -360,7 +360,7 @@ server.registerTool(
 				z.object({
 					id: z.string(),
 					timestamp: z.string(),
-					type: z.enum(['decision', 'insight', 'risk', 'assumption', 'other']),
+					type: z.enum(['decision', 'insight', 'risk', 'assumption', 'fix', 'other']),
 					content: z.string(),
 				})
 			),
diff --git a/src/mcp/recap-types.ts b/src/mcp/recap-types.ts
@@ -3,11 +3,11 @@
  *
  * The Recap MCP captures session context that scrolls away during Claude sessions:
  * - Goal: The original problem statement
- * - Entries: Decisions, insights, risks, assumptions discovered during the session
+ * - Entries: Decisions, insights, risks, assumptions, fixes discovered during the session
  */
 
 /** Entry types for recap entries */
-export type RecapEntryType = 'decision' | 'insight' | 'risk' | 'assumption' | 'other'
+export type RecapEntryType = 'decision' | 'insight' | 'risk' | 'assumption' | 'fix' | 'other'
 
 /** Artifact types for tracking created items */
 export type RecapArtifactType = 'comment' | 'issue' | 'pr'
diff --git a/src/utils/mcp.ts b/src/utils/mcp.ts
@@ -199,7 +199,7 @@ export async function writeRecapFile(filePath: string, recap: Record<string, unk
 /**
  * Generate MCP configuration for recap server
  *
- * The recap server captures session context (goal, decisions, insights, risks, assumptions)
+ * The recap server captures session context (goal, decisions, insights, risks, fixes, assumptions)
  * for the VS Code Loom Context Panel.
  *
  * @param loomPath - Absolute path to the loom workspace
diff --git a/templates/agents/iloom-code-reviewer.md b/templates/agents/iloom-code-reviewer.md
@@ -17,7 +17,7 @@ You are an expert code reviewer. Your task is to analyze code changes and provid
 - **Concise output**: Return structured review results suitable for the orchestrator to process.
 - **Autonomous handling**: If critical issues are found, report them but do NOT wait for user confirmation.
 - **IMPORTANT recap routing**: You are running inline in a swarm worker's context. You MUST pass `worktreePath` on ALL recap calls (`set_loom_state`, `add_entry`, `get_recap`). The worktree path is provided by the caller — look for it in your invocation prompt (e.g., "Your worktree path is ..."). Without `worktreePath`, recap entries go to the epic's recap file instead of the child's.
-- **Recap from findings**: After completing the review, log key findings as recap entries using `recap.add_entry`. For each critical finding (95-100 confidence), add a `risk` entry. For significant patterns or architectural concerns found across multiple files, add an `insight` entry. For architectural choices or trade-offs surfaced during review, add a `decision` entry. Always include `worktreePath` on these calls.
+- **Recap from findings**: After completing the review, log key findings as recap entries using `recap.add_entry`. For each critical finding (95-100 confidence), add a `risk` entry. For significant patterns or architectural concerns found across multiple files, add an `insight` entry. For architectural choices or trade-offs surfaced during review, add a `decision` entry. When a review finding is addressed in a subsequent implementation pass, the implementer should log a `fix` entry describing what was resolved. Always include `worktreePath` on these calls.
 {{/if}}
 
 ## Do NOT Review Temporal Information
diff --git a/templates/agents/iloom-issue-implementer.md b/templates/agents/iloom-issue-implementer.md
@@ -43,6 +43,8 @@ After creating or updating any issue comment, use the Recap MCP tools:
 
 This enables the recap panel to show quick-reference links to artifacts created during the session.
 
+- When addressing issues identified during code review, use `recap.add_entry` with type `fix` to log what was resolved (e.g., "Fixed null check in auth handler per review feedback").
+
 {{#if SWARM_MODE}}
 **IMPORTANT**: You are running inline in a swarm worker's context. You MUST pass `worktreePath` on ALL recap calls (`add_artifact`, `add_entry`, `set_loom_state`, `get_recap`). The worktree path is provided by the caller — look for it in your invocation prompt (e.g., "Your worktree path is ..."). Without `worktreePath`, recap entries go to the epic's recap file instead of the child's.
 {{/if}}
diff --git a/templates/prompts/issue-prompt.txt b/templates/prompts/issue-prompt.txt
@@ -68,7 +68,7 @@ The recap panel is visible to the user in VS Code. They don't care about your in
 Use these Recap MCP tools:
 - `recap.set_complexity` - Call when complexity is confirmed at ROUTING DECISION POINT (trivial/simple/complex)
 - `recap.get_recap` - Call before adding entries to check what's already captured
-- `recap.add_entry` - Call with type (decision/insight/risk/assumption) and concise content
+- `recap.add_entry` - Call with type (decision/insight/risk/assumption/fix) and concise content
 - `recap.add_artifact` - After creating/updating comments, issues, or PRs, log them with type, primaryUrl, and description. Duplicates with the same primaryUrl will be replaced.
 
 **NEVER log:**
@@ -1413,7 +1413,7 @@ When the user requests help, **YOU MUST USE subagents** to preserve your context
 
 After handling each request, summarize what was done and confirm you're still available.
 
-Use `recap.add_entry` to capture decisions, risks, insights, or assumptions discovered during help sessions. Do not log status updates or task completions.
+Use `recap.add_entry` to capture decisions, risks, insights, fixes, or assumptions discovered during help sessions. Do not log status updates or task completions.
 
 ### Epic Decomposition
 
diff --git a/templates/prompts/pr-prompt.txt b/templates/prompts/pr-prompt.txt
@@ -42,7 +42,7 @@ Use these Recap MCP tools:
 - `recap.set_goal` - Call once after understanding why the user is working on this PR (e.g., "Review PR for security concerns", "Fix failing tests")
 - `recap.set_complexity` - Call when task complexity is assessed (trivial/simple/complex)
 - `recap.get_recap` - Call before adding entries to check what's already captured
-- `recap.add_entry` - Call with type (decision/insight/risk/assumption) and concise content
+- `recap.add_entry` - Call with type (decision/insight/risk/assumption/fix) and concise content
 - `recap.add_artifact` - After creating/updating comments, issues, or PRs, log them with type, primaryUrl, and description. Duplicates with the same primaryUrl will be replaced.
 
 **NEVER log:**
@@ -199,7 +199,7 @@ When the user requests help, **prefer subagents** to preserve your context windo
 
 After handling each request, summarize what was done and confirm you're still available.
 
-Use `recap.add_entry` to capture decisions, risks, insights, or assumptions discovered during help sessions. Do not log status updates or task completions.
+Use `recap.add_entry` to capture decisions, risks, insights, fixes, or assumptions discovered during help sessions. Do not log status updates or task completions.
 
 ### Epic Decomposition
 
diff --git a/templates/prompts/regular-prompt.txt b/templates/prompts/regular-prompt.txt
@@ -42,7 +42,7 @@ Use these Recap MCP tools:
 - `recap.set_goal` - Call once at session start with the user's problem statement
 - `recap.set_complexity` - Call when complexity is confirmed at ROUTING DECISION POINT (trivial/simple/complex)
 - `recap.get_recap` - Call before adding entries to check what's already captured
-- `recap.add_entry` - Call with type (decision/insight/risk/assumption) and concise content
+- `recap.add_entry` - Call with type (decision/insight/risk/assumption/fix) and concise content
 - `recap.add_artifact` - After creating/updating comments, issues, or PRs, log them with type, primaryUrl, and description. Duplicates with the same primaryUrl will be replaced.
 
 **NEVER log:**
@@ -800,7 +800,7 @@ When the user requests help, **prefer subagents** to preserve your context windo
 
 After handling each request, summarize what was done and confirm you're still available.
 
-Use `recap.add_entry` to capture decisions, risks, insights, or assumptions discovered during help sessions. Do not log status updates or task completions.
+Use `recap.add_entry` to capture decisions, risks, insights, fixes, or assumptions discovered during help sessions. Do not log status updates or task completions.
 
 ### Epic Decomposition
 
diff --git a/templates/prompts/session-summary-prompt.txt b/templates/prompts/session-summary-prompt.txt
@@ -32,6 +32,7 @@ You are generating a summary of THIS conversation - the development session you
 - **Insights**: Discoveries that future developers need to know
 - **Risks**: Things that could go wrong
 - **Assumptions**: Bets being made about the implementation
+- **Fixes**: Code review issues that were identified and resolved
 
 When there are conflicts between the recap and conversation transcript, give weight to the most recent timestamp.
 
@@ -145,6 +146,6 @@ Keep the visible themes section brief (3-5 bullet points, one sentence each). Th
 ## VALIDATION CHECKLIST - FAILING THIS LIST MEANS FAILING THE TASK:
 * Did you ouput ONLY the markdown with no commentary before or after?
 {{#if COMPACT_SUMMARIES}}* Did you use the information in the "Previous Conversation Context" section?{{/if}}
-{{#if RECAP_DATA}}* Did you incorporate the decisions, insights, risks, and assumptions from the "Session Recap" section?{{/if}}
+{{#if RECAP_DATA}}* Did you incorporate the decisions, insights, risks, fixes, and assumptions from the "Session Recap" section?{{/if}}
 * Did you avoid process noise? (No mentions of: workflow phases, complexity classifications, git commands, test/build results, or descriptions of what you DID vs what was LEARNED)
 
diff --git a/templates/prompts/swarm-orchestrator-prompt.txt b/templates/prompts/swarm-orchestrator-prompt.txt
@@ -23,7 +23,7 @@ You are a **coordinator**, not an executor. Your job is to schedule work, track
 
 The recap panel is visible to the user in VS Code. Use these Recap MCP tools to capture knowledge:
 
-- `recap.add_entry` - Call with type (decision/insight/risk/assumption) and concise content. **Pass `worktreePath` when the entry is about a specific child issue** to route it to the child's recap file.
+- `recap.add_entry` - Call with type (decision/insight/risk/assumption/fix) and concise content. **Pass `worktreePath` when the entry is about a specific child issue** to route it to the child's recap file.
 - `recap.get_recap` - Call before adding entries to check what's already captured. **Pass `worktreePath` to read a specific child's recap.**
 - `recap.add_artifact` - After creating/updating comments, issues, or PRs, log them with type, primaryUrl, and description. Duplicates with the same primaryUrl will be replaced. **Pass `worktreePath` when the artifact belongs to a child issue.**
 - `recap.set_loom_state` - Update the loom state (in_progress, done, failed, etc.)

Original file line number	Diff line number	Diff line change
`@@ -199,7 +199,7 @@ export async function writeRecapFile(filePath: string, recap: Record<string, unk`
`199`	`199`	`/**`
`200`	`200`	`* Generate MCP configuration for recap server`
`201`	`201`	`*`
`202`		`- * The recap server captures session context (goal, decisions, insights, risks, assumptions)`
	`202`	`+ * The recap server captures session context (goal, decisions, insights, risks, fixes, assumptions)`
`203`	`203`	`* for the VS Code Loom Context Panel.`
`204`	`204`	`*`
`205`	`205`	`* @param loomPath - Absolute path to the loom workspace`