🏗️ Architecture: Session 135: Fix reverse dependency in outcome-validator.ts ...

Date: 2026-02-22
Time: 21:01:47 UTC
Session: gspace1-135.11
Agent: architecture
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

Session 135: Fix reverse dependency in outcome-validator.ts — service imports and calls tool handler (handleReportOutcome), violating dependency direction

Task: Fix architecture violation in outcome-validator

🎯 Decision Made

Chosen:

Replaced handleReportOutcome import with direct storage primitives: updateDecisionOutcome + saveMemoryStore + recordLearning. Services now only import from storage/, agents/, and types/ — never from tools/. Zero reverse dependencies remain in the MCP codebase (verified via grep).

Options Considered:

• No alternatives documented

💭 Reasoning

ROOT CAUSE: outcome-validator.ts (a service) imported handleReportOutcome from ../tools/report-outcome.ts (a tool handler). This violates the dependency direction: tools should call services, not the reverse. The same pattern caused the recursion bug in decision-lifecycle-manager.ts. While outcome-validator's specific call path doesn't currently recurse, it would become recursive if anyone adds a 'notify validator' call inside handleReportOutcome. Fixing it now prevents a future recursion bug. The fix is to use the same storage primitives that handleReportOutcome uses internally (updateDecisionOutcome, saveMemoryStore, recordLearning) — the validator doesn't need the lifecycle management or super intelligence calls that the full tool handler adds.

📁 Files Involved

• MCP/mcp-gograb-ai/src/services/outcome-validator.ts

🔗 Related

• Decision ID: dev_1771794107119_i92dfm6
• Session: 135
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation