VibeOps MCP

# Session Memory - 2025-11-04 ## Summary Comprehensive session focused on evolving VibeOps from v2.0.1 to v2.2.0. Published two major releases with AI-driven development enhancements and session memory storage capabilities. Resolved version publishing issues and configured MCP server for Claude Code. ## Key Decisions ### 1. Make DoR Optional, Keep DoD Required **Decision:** Definition of Ready is now optional, Definition of Done remains required **Reasoning:** AI can generate code quickly, so lightweight entry (DoR) is better. But validation (DoD) is MORE important with AI to ensure quality, testing, security, and deployment readiness. ### 2. Feature Dependencies at Feature Level, Not Module Level **Decision:** Added `featureDependencies` to features, not to modules **Reasoning:** Modules are strategic/thematic groupings. Dependencies matter at the implementation level (features), allowing cross-module dependencies and more granular control. ### 3. Enhanced Bug Tracking for AI Debugging **Decision:** Added errorDetails, regression, impact, verification, relatedIssues, fixDetails **Reasoning:** AI can analyze stack traces, correlate regressions to commits, and suggest fixes. Rich metadata enables better AI-assisted debugging. ### 4. Memory Storage Outside Contract System **Decision:** Memory is stored in separate `memories/` directory, not treated as Contract type **Reasoning:** Memory has different lifecycle and structure than contracts. Separating allows flexibility without polluting contract schemas. ## Work Completed ### Version 2.1.0 - AI-Driven Development - ✅ Added `testing` field to user-story schema (unit, integration, e2e, performance) - ✅ Made DoR optional in user-story schema - ✅ Updated DoD template to focus on validation (tests, security, performance, deployment) - ✅ Added `featureDependencies` to feature schema (blocks, requires, related) - ✅ Enhanced bug schema with: - errorDetails (stack traces, logs) - regression (which commit/PR introduced it) - impact (users affected, frequency, workarounds) - verification (test coverage, who verified) - relatedIssues (duplicates, blockers, caused-by) - fixDetails (commit, PR, time to fix, files) - ✅ Updated all templates to match new schemas - ✅ Built and published v2.1.0 ### Version 2.2.0 - Session Memory - ✅ Created memory.schema.json (comprehensive session capture) - ✅ Created memory.template.json - ✅ Implemented memory.ts with 7 tools: - store_memory - get_memory - list_memories - get_recent_memories - search_memories - get_memories_by_contract - get_continuation_context - ✅ Integrated memory tools into MCP server index - ✅ Updated ID generator to support MEM prefix - ✅ Fixed TypeScript errors (Memory not a Contract type) - ✅ Built and published v2.2.0 - ✅ Updated Claude Code config to use latest vibeops ## Pending Tasks ### High Priority - User needs to clear npx cache: `rm -rf ~/.npm/_npx` - User needs to restart Claude Code completely (Cmd+Q) - Verify v2.2.0 loads correctly in Claude Code - Test memory storage tools in actual Claude session ### Medium Priority - Consider adding auto-memory on session end (proactive) - Add memory visualization tool - Create memory export/import for sharing context across team ## Learnings ### 1. AI-Driven Development Shifts Quality Gates **Insight:** With AI code generation, the bottleneck moves from "writing code" to "validating code is production-ready" **Application:** All future schemas should emphasize testing, security, performance validation over creation artifacts ### 2. npx Caching Can Block Updates **Insight:** Even with `@latest`, npx caches packages locally which prevents MCP servers from updating **Prevention:** Document cache clearing in troubleshooting guide. Consider version-pinning in production. ### 3. TypeScript Type System for Non-Contract Data **Insight:** Memory doesn't fit the Contract type hierarchy - needed separate file handling **Application:** Not everything should be a Contract. Some data structures need their own storage patterns. ## Code Patterns ### Pattern: Separate Storage for Different Data Types ```typescript // Memory uses direct file writes, not writeContract() const contractsDir = getContractsDir(); const memoryDir = join(contractsDir, 'memories'); writeFileSync(filePath, JSON.stringify(memory, null, 2), 'utf-8'); ``` **When to use:** Data that doesn't fit existing type hierarchies but needs persistence ### Pattern: Optional Fields for Backward Compatibility ```typescript // New fields are optional - old contracts still validate testing?: { unit?: { required: boolean; coverage: number; status: string }; // ... } ``` **When to use:** Adding features to existing schemas without breaking old data ## Problems & Solutions ### Problem: Version showing 2.0.0 after publishing 2.2.0 **Solution:** 1. Package was correctly published to npm 2. Issue was npx cache in Claude Code 3. Solution: `rm -rf ~/.npm/_npx` + restart Claude Code **Prevention:** Document cache clearing in README/troubleshooting ### Problem: TypeScript errors - Memory not assignable to Contract **Solution:** - Memory doesn't extend Contract types - Implemented separate file handling instead of using writeContract() - Created dedicated `memories/` directory **Prevention:** Document type system boundaries, not everything needs to be a Contract ## Conversation Highlights ### User Intent: "Do modules need dependencies?" **Outcome:** Agreed feature-level dependencies are better - modules are strategic, features are tactical ### User Intent: "What about testing in schemas?" **Outcome:** Added comprehensive testing field to track AI-generated code quality ### User Intent: "What do we need for bugs?" **Outcome:** Enhanced with AI-debugging focused fields (stack traces, regression tracking, impact) ### User Intent: "Will updates force new fields?" **Outcome:** No - updates use shallow merge, preserving existing fields. Optional fields stay optional. ### User Intent: "Store your memory before we exit" **Outcome:** Demonstrated the memory system we just built (meta!) ## Project Context - **Working Directory:** `/Users/ronwilson/Desktop/cursor-projects/3-anckr-internal/vibeops/vibeops-mcp` - **Branch:** main - **Environment:** Development (local npm publishing) - **Related Modules:** N/A (building the system itself) - **Related Features:** N/A ## Continuity Notes ### Next Steps 1. User: Clear npx cache and restart Claude Code 2. Test memory tools in actual Claude session 3. Create a module and feature using new schemas 4. Try storing and retrieving memory in real usage 5. Consider adding auto-memory on significant milestones ### Important Context - Memory storage system is complete but untested in production use - All schemas validated and templates updated - npx cache issue is a known deployment pattern - document it ### Warnings - Don't forget to rebuild (`npm run build`) before publishing - Always update 3 places for version: package.json, server version, console.error message - Test standalone with `npx @anckr/vibeops` before publishing ### Open Questions - Should memory be automatically stored on certain triggers (session timeout, major milestones)? - Would a memory visualization/timeline UI be valuable? - How to handle memory pruning/archiving for long-running projects? ## Metrics - **Duration:** ~2 hours - **Contracts Created:** 2 (memory schema + template) - **Contracts Modified:** 5 (user-story, feature, bug schemas + 3 templates) - **Files Modified:** 8 (schemas, templates, memory.ts, index.ts, id-generator.ts, package.json) - **Versions Published:** 2 (v2.1.0, v2.2.0) - **New MCP Tools:** 7 (all memory-related) ## Session Type Development, Architecture Design, Publishing ## Tags vibeops, mcp-server, ai-driven-development, memory-storage, schema-design, publishing, version-2.1.0, version-2.2.0