@syntesseraai/opencode-feature-factory 0.3.6 → 0.4.1

package/README.md

@@ -29,47 +29,6 @@ This will:
 - Copy skills to `~/.config/opencode/skills/`
 - Configure MCP servers in `~/.config/opencode/opencode.json`
 
-## Local Recall MCP Daemon
-
-The plugin now includes a local MCP daemon binary: `ff-local-recall-mcp`.
-
-- `ff-deploy` adds a local MCP server entry named `ff-local-recall`
-- The server exposes memory tools:
-  - `local_recall.search`
-  - `local_recall.get`
-  - `local_recall.store`
-  - `local_recall.index.start`
-  - `local_recall.index.status`
-  - `local_recall.index.stop`
-  - `local_recall.index.rebuild`
-- In headless and TUI sessions, relevant memories are automatically injected into model context per user prompt
-
-### Environment Variables
-
-- `FF_LOCAL_RECALL_DIRECTORY` - Directory that contains `ff-memories/` (default: current working directory)
-- `FF_LOCAL_RECALL_DAEMON_AUTOSTART` - Start index daemon automatically (`true` by default)
-- `FF_LOCAL_RECALL_INDEX_INTERVAL_MS` - Background daemon interval in milliseconds (default: `15000`)
-- `FF_LOCAL_RECALL_EXTRACTION_ENABLED` - Run extraction during daemon cycles (`true` by default)
-- `FF_LOCAL_RECALL_EMBEDDING_PROVIDER` - Embedding provider (`ollama` default, `openai` optional)
-- `FF_LOCAL_RECALL_OLLAMA_URL` - Ollama base URL (default: `http://127.0.0.1:11434`)
-- `FF_LOCAL_RECALL_OLLAMA_MODEL` - Ollama embedding model (default: `nomic-embed-text`)
-- `FF_LOCAL_RECALL_OPENAI_URL` - OpenAI embeddings endpoint base (default: `https://api.openai.com/v1`)
-- `FF_LOCAL_RECALL_OPENAI_MODEL` - OpenAI embedding model (default: `text-embedding-3-small`)
-- `OPENAI_API_KEY` - Required when `FF_LOCAL_RECALL_EMBEDDING_PROVIDER=openai`
-
-### Prompt Injection Controls
-
-- `FF_LOCAL_RECALL_PROMPT_INJECTION_ENABLED` - Enable automatic per-prompt memory injection (`true` by default)
-- `FF_LOCAL_RECALL_PROMPT_INJECTION_MIN_PROMPT_CHARS` - Minimum user prompt length before searching (default: `20`)
-- `FF_LOCAL_RECALL_PROMPT_INJECTION_MAX_QUERY_CHARS` - Maximum characters from prompt used for retrieval (default: `2000`)
-- `FF_LOCAL_RECALL_PROMPT_INJECTION_SEARCH_LIMIT` - Max memories fetched before ranking/filtering (default: `8`)
-- `FF_LOCAL_RECALL_PROMPT_INJECTION_MAX_RESULTS` - Max memories injected into model context (default: `5`)
-- `FF_LOCAL_RECALL_PROMPT_INJECTION_MIN_RELEVANCE` - Minimum relevance score for inclusion (default: `0.2`)
-- `FF_LOCAL_RECALL_PROMPT_INJECTION_MIN_IMPORTANCE` - Minimum memory importance used in search (default: `0.2`)
-- `FF_LOCAL_RECALL_PROMPT_INJECTION_MAX_TOKENS` - Approx token budget for injected memory block (default: `400`)
-- `FF_LOCAL_RECALL_PROMPT_INJECTION_SESSION_ONLY` - Restrict retrieval to current session memories only (`false` by default)
-- `FF_LOCAL_RECALL_PROMPT_INTERNAL_MARKERS` - Comma-separated markers that skip injection (default: `[LOCAL_RECALL_INTERNAL]`)
-
 ## Agents Provided
 
 ### Primary Agents

package/agents/building.md

@@ -68,10 +68,27 @@ At the start of EVERY building task:
 5. **Load the ff-delegation skill** and assess parallelization opportunities
 6. **Load the ff-mini-plan skill** and create an execution plan
 7. **Load the ff-todo-management skill** and create a todo list for tracking progress
-8. **Load the ff-learning skill** to capture implementation insights
-9. **Load the ff-severity-classification skill** to assess risks of changes
-10. **Document your context** - Use `ff-agents-update` tool to create `.feature-factory/agents/building-{UUID}.md`
-11. **Check for existing plans** - Use `ff-plans-list` and `ff-plans-get` to find implementation plans
+8. **Load the ff-severity-classification skill** to assess risks of changes
+9. **Document your context** - Use `ff-agents-update` tool to create `.feature-factory/agents/building-{UUID}.md`
+10. **Check for existing plans** - Use `ff-plans-list` and `ff-plans-get` to find implementation plans
+
+## Git Worktrees (Mandatory)
+
+To prevent conflicts and ensure a clean state, you MUST use git worktrees for your implementation:
+
+1. **Create Worktree:** Before starting code modifications, create a dedicated worktree outside the main directory:
+   ```bash
+   git worktree add ../ff-build-{UUID} -b feature/ff-build-{UUID}
+   ```
+2. **Use the Worktree:**
+   - When using the `bash` tool, always set the `workdir` parameter to the absolute path of your worktree.
+   - When using `edit`, `write`, or `read` tools, ensure the `filePath` points to the files inside your worktree (e.g., replace the base project path with the path to your worktree).
+3. **Commit & Push:** Commit your changes and push the branch from within the worktree.
+4. **Cleanup:** After your work is pushed, remove the worktree:
+   ```bash
+   git worktree remove ../ff-build-{UUID} --force
+   git branch -D feature/ff-build-{UUID}
+   ```
 
 ## File Management Tools
 
@@ -452,31 +469,10 @@ When @reviewing agent returns findings:
 
 Create todos for each critical/high item, fix them, then re-invoke @reviewing if needed.
 
-## Capture Learnings
+## Knowledge Management
 
-Before completing your building task:
+**Always be learning:**
 
-1. **Reflect on insights gained** during implementation:
-   - Technical challenges overcome
-   - Code patterns and best practices discovered
-   - Error resolutions and debugging insights
-   - Integration challenges and solutions
-
-2. **Store important learnings** using the `ff-learning-store` MCP tool:
-   - Use category `pattern` for technical patterns and best practices
-   - Use category `context` for significant implementation experiences
-   - Use category `procedure` for reusable workflows discovered
-   - Tag with relevant technology names and categories
-
-3. **Example learning capture:**
-
-   ```
-   ff-learning-store(
-     title: "Implementation Pattern: [Pattern Name]",
-     description: "Best practice for [scenario] in [technology]",
-     category: "pattern",
-     tags: ["implementation", "pattern", "{technology}"],
-     importance: 0.8,
-     content: "Detailed explanation of the pattern..."
-   )
-   ```
+- Use `docs/learnings/` to store findings, decisions, and patterns.
+- Search `docs/learnings/` before debugging complex issues.
+- Load the `ff-learning` skill for details on how to write good learning docs.

package/agents/ff-acceptance.md

@@ -53,7 +53,6 @@ At the start of EVERY validation task:
 3. **Read relevant contexts** - Use `ff-agents-show()` to read contexts from @building, @planning, etc.
 4. **Load the ff-mini-plan skill** and create a quick 2-5 step plan for your validation approach
 5. **Load the ff-todo-management skill** and create a todo list from your plan
-6. **Load the ff-learning skill** to capture validation insights and patterns
 7. **Load the ff-severity-classification skill** to ensure consistent issue classification
 8. **Load the ff-report-templates skill** for standardized output formatting
 9. **Document your context** - Use `ff-agents-update` tool to create `.feature-factory/agents/ff-acceptance-{UUID}.md`
@@ -278,28 +277,9 @@ Use ff-severity-classification skill standards:
 
 Remember: Your role is to be the "gatekeeper" ensuring requirements are fully and correctly implemented before proceeding.
 
-## Capture Learnings
-
-Before completing your validation task:
-
-1. **Reflect on insights gained** during validation:
-   - Requirement validation patterns and insights
-   - Acceptance criteria patterns observed
-   - Ambiguity resolutions and scope clarifications
-   - Common gaps between requirements and implementation
-
-2. **Store important learnings** using `ff-learning-store` MCP tool:
-   - Use category `pattern` for requirement patterns and validation techniques
-   - Use category `decision` for significant scope clarifications and findings
-   - Tag with requirement types, categories, and validation insights
-
-3. **Example MCP tool call:**
-   ```
-   ff-learning-store(
-     title: "Validation Pattern: [Pattern Name]",
-     description: "Common pattern of [issue] in [type] requirements",
-     category: "pattern",
-     tags: ["validation", "requirements", "pattern", "{category}"],
-     importance: 0.7
-   )
-   ```
+## Knowledge Management
+
+**Always be learning:**
+- Use `docs/learnings/` to store findings, decisions, and patterns.
+- Search `docs/learnings/` before debugging complex issues.
+- Load the `ff-learning` skill for details on how to write good learning docs.

package/agents/ff-research.md

@@ -55,7 +55,6 @@ At the start of EVERY research task:
 5. **Load the ff-research-methods skill** for research methodology
 6. **Load the ff-mini-plan skill** and create a research plan
 7. **Load the ff-todo-management skill** and create a todo list
-8. **Load the ff-learning skill** to capture research findings and knowledge
 9. **Load the ff-report-templates skill** for output formatting
 10. **Document your context** - Use `ff-agents-update` tool to create `.feature-factory/agents/ff-research-{UUID}.md`
 
@@ -423,29 +422,9 @@ Structure research findings using ff-report-templates:
 
 Remember: Your research enables other agents to make informed implementation decisions. Be thorough, current, and precise.
 
-## Capture Learnings
-
-Before completing your research task:
-
-1. **Reflect on insights gained** during research:
-   - Key findings and conclusions
-   - Technology comparisons and evaluations
-   - Best practices discovered
-   - Source quality assessments
-
-2. **Store important learnings** using `ff-learning-store` MCP tool:
-   - Use category `pattern` for key findings and reusable knowledge
-   - Use category `context` for significant research discoveries and context
-   - Tag with research topics, technologies, and categories
-   - Set high importance (0.8-1.0) for critical findings
-
-3. **Example MCP tool call:**
-   ```
-   ff-learning-store(
-     title: "Research Finding: [Topic]",
-     description: "Key finding about [topic] from [source]",
-     category: "pattern",
-     tags: ["research", "{topic}", "{technology}", "best-practices"],
-     importance: 0.9
-   )
-   ```
+## Knowledge Management
+
+**Always be learning:**
+- Use `docs/learnings/` to store findings, decisions, and patterns.
+- Search `docs/learnings/` before debugging complex issues.
+- Load the `ff-learning` skill for details on how to write good learning docs.

package/agents/ff-review.md

@@ -53,7 +53,6 @@ At the start of EVERY review task:
 3. **Read relevant contexts** - Use `ff-agents-show()` to read contexts from @building, @planning, etc.
 4. **Load the ff-mini-plan skill** and create a quick 2-5 step plan for your review approach
 5. **Load the ff-todo-management skill** and create a todo list from your plan
-6. **Load the ff-learning skill** to capture code quality insights and patterns
 7. **Load the ff-severity-classification skill** to ensure consistent issue classification
 8. **Load the ff-report-templates skill** for standardized output formatting
 9. **Document your context** - Use `ff-agents-update` tool to create `.feature-factory/agents/ff-review-{UUID}.md`
@@ -281,28 +280,9 @@ Use ff-severity-classification skill standards:
 11. Mark all todos complete before finishing
 12. Recommend delegating to other agents if specialized issues found
 
-## Capture Learnings
-
-Before completing your code review:
-
-1. **Reflect on insights gained** during the review:
-   - Code quality patterns observed
-   - Common issues and their solutions
-   - Best practices identified
-   - Review technique improvements
-
-2. **Store important learnings** using `ff-learning-store` MCP tool:
-   - Use category `pattern` for code patterns and anti-patterns
-   - Use category `decision` for significant review findings and trade-offs
-   - Tag with code quality categories, technologies, and patterns
-
-3. **Example MCP tool call:**
-   ```
-   ff-learning-store(
-     title: "Code Pattern: [Pattern Name]",
-     description: "Effective pattern for [scenario] in [technology]",
-     category: "pattern",
-     tags: ["code-quality", "pattern", "{technology}", "{category}"],
-     importance: 0.7
-   )
-   ```
+## Knowledge Management
+
+**Always be learning:**
+- Use `docs/learnings/` to store findings, decisions, and patterns.
+- Search `docs/learnings/` before debugging complex issues.
+- Load the `ff-learning` skill for details on how to write good learning docs.

package/agents/ff-security.md

@@ -53,7 +53,6 @@ At the start of EVERY security audit:
 3. **Read relevant contexts** - Use `ff-agents-show()` to read contexts from @building, @planning, etc.
 4. **Load the ff-mini-plan skill** and create a quick 2-5 step plan for your audit approach
 5. **Load the ff-todo-management skill** and create a todo list from your plan
-6. **Load the ff-learning skill** to capture security insights and vulnerability patterns
 7. **Load the ff-severity-classification skill** to ensure consistent vulnerability classification
 8. **Load the ff-report-templates skill** for standardized output formatting
 9. **Document your context** - Use `ff-agents-update` tool to create `.feature-factory/agents/ff-security-{UUID}.md`
@@ -315,28 +314,9 @@ Use ff-severity-classification skill standards with security-specific definition
 11. Mark all todos complete before finishing
 12. Recommend delegating to other agents if additional issues found
 
-## Capture Learnings
-
-Before completing your security audit:
-
-1. **Reflect on insights gained** during the audit:
-   - Vulnerability patterns discovered
-   - Security best practices identified
-   - Threat model insights
-   - Common security mistakes observed
-
-2. **Store important learnings** using `ff-learning-store` MCP tool:
-   - Use category `pattern` for vulnerability patterns and fixes
-   - Use category `debugging` for significant security findings and investigations
-   - Tag with security categories, vulnerability types, and technologies
-
-3. **Example MCP tool call:**
-   ```
-   ff-learning-store(
-     title: "Security Pattern: [Vulnerability Type]",
-     description: "Common [vulnerability] pattern in [context] and how to fix it",
-     category: "pattern",
-     tags: ["security", "vulnerability", "{type}", "{technology}"],
-     importance: 0.9
-   )
-   ```
+## Knowledge Management
+
+**Always be learning:**
+- Use `docs/learnings/` to store findings, decisions, and patterns.
+- Search `docs/learnings/` before debugging complex issues.
+- Load the `ff-learning` skill for details on how to write good learning docs.

package/agents/ff-validate.md

@@ -53,7 +53,6 @@ At the start of EVERY validation orchestration:
 3. **Read relevant contexts** - Use `ff-agents-show()` to read contexts from @building, @planning, etc.
 4. **Load the ff-mini-plan skill** and create a quick plan for your orchestration approach
 5. **Load the ff-todo-management skill** and create a todo list for tracking
-6. **Load the ff-learning skill** to capture validation insights and patterns
 7. **Load the ff-severity-classification skill** for consistent issue classification
 8. **Load the ff-report-templates skill** for standardized output formatting
 9. **Document your context** - Use `ff-agents-update` tool to create `.feature-factory/agents/ff-validate-{UUID}.md`
@@ -309,28 +308,9 @@ When multiple agents report findings:
 - **Include metrics** - Quantify the validation results where possible
 - **Consider context** - Weight findings based on the scope of changes
 
-## Capture Learnings
-
-Before completing your validation:
-
-1. **Reflect on insights gained** during validation:
-   - Validation patterns and effective techniques
-   - Common issues found across different dimensions
-   - Validation efficiency improvements
-   - Cross-dimensional finding patterns
-
-2. **Store important learnings** using `ff-learning-store` MCP tool:
-   - Use category `pattern` for validation patterns and effective techniques
-   - Use category `decision` for significant validation findings
-   - Tag with validation types and categories
-
-3. **Example MCP tool call:**
-   ```
-   ff-learning-store(
-     title: "Validation Pattern: [Pattern Name]",
-     description: "Common pattern of [findings] when validating [type] changes",
-     category: "pattern",
-     tags: ["validation", "pattern", "{category}"],
-     importance: 0.7
-   )
-   ```
+## Knowledge Management
+
+**Always be learning:**
+- Use `docs/learnings/` to store findings, decisions, and patterns.
+- Search `docs/learnings/` before debugging complex issues.
+- Load the `ff-learning` skill for details on how to write good learning docs.

package/agents/ff-well-architected.md

@@ -53,7 +53,6 @@ At the start of EVERY architecture review:
 3. **Read relevant contexts** - Use `ff-agents-show()` to read contexts from @building, @planning, etc.
 4. **Load the ff-mini-plan skill** and create a quick 2-5 step plan for your review approach
 5. **Load the ff-todo-management skill** and create a todo list from your plan
-6. **Load the ff-learning skill** to capture architectural insights and patterns
 7. **Load the ff-severity-classification skill** to ensure consistent issue classification
 8. **Load the ff-report-templates skill** for standardized output formatting
 9. **Document your context** - Use `ff-agents-update` tool to create `.feature-factory/agents/ff-well-architected-{UUID}.md`
@@ -277,28 +276,9 @@ Use ff-severity-classification skill standards:
 
 Focus on providing actionable, specific recommendations that improve the overall architecture quality across all six pillars.
 
-## Capture Learnings
-
-Before completing your architecture review:
-
-1. **Reflect on insights gained** during the review:
-   - Architectural patterns and anti-patterns observed
-   - Pillar-specific insights (Operational Excellence, Security, Reliability, etc.)
-   - Scalability and efficiency considerations
-   - Cross-pillar interactions and trade-offs
-
-2. **Store important learnings** using `ff-learning-store` MCP tool:
-   - Use category `pattern` for architectural patterns and best practices
-   - Use category `decision` for significant architectural trade-offs
-   - Tag with pillar names, architecture categories, and patterns
-
-3. **Example MCP tool call:**
-   ```
-   ff-learning-store(
-     title: "Architecture Pattern: [Pattern Name]",
-     description: "Pattern for achieving [pillar] excellence in [context]",
-     category: "pattern",
-     tags: ["architecture", "{pillar}", "pattern", "{category}"],
-     importance: 0.8
-   )
-   ```
+## Knowledge Management
+
+**Always be learning:**
+- Use `docs/learnings/` to store findings, decisions, and patterns.
+- Search `docs/learnings/` before debugging complex issues.
+- Load the `ff-learning` skill for details on how to write good learning docs.

package/agents/planning.md

@@ -73,7 +73,6 @@ At the start of EVERY planning task:
 5. **Load the ff-delegation skill** and assess parallelization opportunities
 6. **Load the ff-mini-plan skill** and assess task complexity
 7. **Load the ff-todo-management skill** and create a todo list for the planning process
-8. **Load the ff-learning skill** to capture planning insights and patterns
 9. **Load the ff-report-templates skill** for standardized output formatting
 10. **Document your context** - Use `ff-agents-update` tool to create `.feature-factory/agents/planning-{UUID}.md`
 
@@ -358,30 +357,9 @@ Recommend escalation to full architectural planning when:
 - **Include validation** - Specify how to verify the implementation
 - **Escalate appropriately** - Don't try to fit complex work into simple plans
 
-## Capture Learnings
-
-Before completing your planning task:
-
-1. **Reflect on insights gained** during planning:
-   - Architecture decisions made and their rationale
-   - Risk factors identified and mitigation strategies
-   - Pattern discoveries from codebase exploration
-   - Estimation accuracy and lessons learned
-
-2. **Store important learnings** using the `ff-learning-store` MCP tool:
-   - Use category `pattern` for architectural patterns discovered
-   - Use category `decision` for significant planning decisions
-   - Tag with relevant keywords (architecture, patterns, risks, decisions)
-
-3. **Example learning capture:**
-
-   ```
-   ff-learning-store(
-     title: "Architecture Decision: [Decision Name]",
-     description: "Rationale for choosing [approach] over [alternatives]",
-     category: "decision",
-     tags: ["architecture", "decision", "{technology}"],
-     importance: 0.8,
-     content: "Detailed explanation of the decision..."
-   )
-   ```
+## Knowledge Management
+
+**Always be learning:**
+- Use `docs/learnings/` to store findings, decisions, and patterns.
+- Search `docs/learnings/` before debugging complex issues.
+- Load the `ff-learning` skill for details on how to write good learning docs.

package/agents/reviewing.md

@@ -71,7 +71,6 @@ At the start of EVERY review task:
 3. **Read relevant contexts** - Use `ff-agents-show()` to read contexts from @building, @ff-security, etc.
 4. **Generate your UUID** - Create unique ID: `xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx`
 5. **Load the ff-todo-management skill** and create a todo list for tracking review progress
-6. **Load the ff-learning skill** to capture review patterns and insights
 7. **Load the ff-report-templates skill** for standardized output formatting
 8. **Load the ff-severity-classification skill** to classify findings consistently
 9. **Document your context** - Use `ff-agents-update` tool to create `.feature-factory/agents/reviewing-{UUID}.md`
@@ -482,30 +481,9 @@ Typical workflow:
 
 This creates a tight feedback loop for high-quality output.
 
-## Capture Learnings
-
-Before completing your review task:
-
-1. **Reflect on insights gained** during validation:
-   - Common issues and patterns identified across reviews
-   - Quality patterns observed in good implementations
-   - Review effectiveness and process improvements
-   - Tool and technique discoveries
-
-2. **Store important learnings** using the `ff-learning-store` MCP tool:
-   - Use category `pattern` for common issue patterns and solutions
-   - Use category `decision` for significant review findings
-   - Tag with review type, categories, and technologies reviewed
-
-3. **Example learning capture:**
-
-   ```
-   ff-learning-store(
-     title: "Review Pattern: [Common Issue Type]",
-     description: "Common pattern of [issue] found in [context]",
-     category: "pattern",
-     tags: ["review", "pattern", "{issue-type}", "{technology}"],
-     importance: 0.7,
-     content: "Detailed explanation of the pattern and solution..."
-   )
-   ```
+## Knowledge Management
+
+**Always be learning:**
+- Use `docs/learnings/` to store findings, decisions, and patterns.
+- Search `docs/learnings/` before debugging complex issues.
+- Load the `ff-learning` skill for details on how to write good learning docs.

package/bin/ff-deploy.js

@@ -29,17 +29,6 @@ const isInteractive = process.stdin.isTTY && process.stdout.isTTY;
 
 // Default MCP configuration
 const DEFAULT_MCP_SERVERS = {
-  'ff-local-recall': {
-    type: 'local',
-    command: [
-      'npx',
-      '-y',
-      '--package=@syntesseraai/opencode-feature-factory@latest',
-      '--',
-      'ff-local-recall-mcp',
-    ],
-    enabled: true,
-  },
   'jina-ai': {
     type: 'remote',
     url: 'https://mcp.jina.ai/v1',

package/dist/feature-factory-setup.d.ts

@@ -3,7 +3,7 @@ type BunShell = any;
 /**
  * Initialize the Feature Factory directory structure.
  * Creates .feature-factory/ and .feature-factory/agents/ directories.
- * Migrates legacy CI scripts (management/ci.sh and .feature-factory/ci.sh) to ff-ci.sh if they exist.
+ * Migrates legacy CI scripts (ff-ci.sh and .feature-factory/ci.sh) to ff-ci.sh if they exist.
  */
 export declare function initializeFeatureFactory(input: PluginInput, $: BunShell): Promise<void>;
 export {};

package/dist/feature-factory-setup.js

@@ -50,7 +50,7 @@ function isValidDirectory(directory) {
 /**
  * Initialize the Feature Factory directory structure.
  * Creates .feature-factory/ and .feature-factory/agents/ directories.
- * Migrates legacy CI scripts (management/ci.sh and .feature-factory/ci.sh) to ff-ci.sh if they exist.
+ * Migrates legacy CI scripts (ff-ci.sh and .feature-factory/ci.sh) to ff-ci.sh if they exist.
  */
 export async function initializeFeatureFactory(input, $) {
     const { directory, client } = input;
@@ -84,8 +84,8 @@ export async function initializeFeatureFactory(input, $) {
         // Continue even if directory creation fails - it might already exist
     }
     // Check for CI script migration (with timeout protection)
-    // Check both legacy locations: management/ci.sh and .feature-factory/ci.sh
-    const legacyCiPaths = [`${directory}/management/ci.sh`, `${featureFactoryDir}/ci.sh`];
+    // Check both legacy locations: ff-ci.sh and .feature-factory/ci.sh
+    const legacyCiPaths = [`${directory}/ff-ci.sh`, `${featureFactoryDir}/ci.sh`];
     const newCiPath = `${directory}/ff-ci.sh`;
     try {
         // Check if new location already exists (with timeout)

package/dist/index.js

@@ -5,8 +5,6 @@ import { $ } from 'bun';
 import { createFFAgentsCurrentTool } from './plugins/ff-agents-current-plugin.js';
 import { createFFAgentsShowTool } from './plugins/ff-agents-show-plugin.js';
 import { createFFAgentsClearTool } from './plugins/ff-agents-clear-plugin.js';
-import { createLearningStoreTool, createLearningSearchTool, createLearningGetTool, createLearningIndexStartTool, createLearningIndexStatusTool, createLearningIndexStopTool, createLearningIndexRebuildTool, initLocalRecall, } from './local-recall/index.js';
-import { createLocalRecallPromptHooks } from './local-recall/prompt-injection.js';
 import { createFFPlanCreateTool } from './plugins/ff-plan-create-plugin.js';
 import { createFFPlanUpdateTool } from './plugins/ff-plan-update-plugin.js';
 import { createFFAgentContextCreateTool } from './plugins/ff-agent-context-create-plugin.js';
@@ -37,35 +35,23 @@ export const FeatureFactoryPlugin = async (input) => {
     if (!directory || directory === '' || directory === '/') {
         return {};
     }
-    // Initialize local-recall memory system
-    initLocalRecall(directory);
     // Update MCP server configuration in global OpenCode config
     // This ensures Feature Factory MCP servers are available across projects
     try {
         await updateMCPConfig($);
     }
-    catch (error) {
-        // Silently fail - don't block plugin initialization if MCP config update fails
-        // This is a convenience feature, not critical for plugin functionality
+    catch {
+        // Just log or ignore errors during config update to not break plugin load
+        console.error('Failed to update MCP config in OpenCode plugin');
     }
     // Load hooks from the quality gate plugin
     const qualityGateHooks = await StopQualityGateHooksPlugin(input).catch(() => ({}));
-    // Load local-recall prompt injection hooks (headless-safe)
-    const localRecallPromptHooks = createLocalRecallPromptHooks(directory);
     // Create all tools
     const tools = {
         // Agent management tools
         'ff-agents-current': createFFAgentsCurrentTool(),
         'ff-agents-show': createFFAgentsShowTool(),
         'ff-agents-clear': createFFAgentsClearTool(),
-        // Learning/memory tools (local-recall)
-        'ff-learning-store': createLearningStoreTool(),
-        'ff-learning-search': createLearningSearchTool(),
-        'ff-learning-get': createLearningGetTool(),
-        'ff-learning-index-start': createLearningIndexStartTool(),
-        'ff-learning-index-status': createLearningIndexStatusTool(),
-        'ff-learning-index-stop': createLearningIndexStopTool(),
-        'ff-learning-index-rebuild': createLearningIndexRebuildTool(),
         // Plan tools
         'ff-plan-create': createFFPlanCreateTool(),
         'ff-plan-update': createFFPlanUpdateTool(),
@@ -92,7 +78,6 @@ export const FeatureFactoryPlugin = async (input) => {
     // Return combined hooks and tools
     return {
         ...qualityGateHooks,
-        ...localRecallPromptHooks,
         tool: tools,
     };
 };

package/dist/mcp-config.d.ts

@@ -4,11 +4,6 @@ type BunShell = any;
  * These servers will be merged into the global OpenCode config.
  */
 export declare const DEFAULT_MCP_SERVERS: {
-    readonly 'ff-local-recall': {
-        readonly type: "local";
-        readonly command: "ff-local-recall-mcp";
-        readonly enabled: true;
-    };
     readonly 'jina-ai': {
         readonly type: "remote";
         readonly url: "https://mcp.jina.ai/v1";

package/dist/mcp-config.js

@@ -8,11 +8,6 @@ const GLOBAL_OPENCODE_CONFIG_PATH = join(GLOBAL_OPENCODE_DIR, 'opencode.json');
  * These servers will be merged into the global OpenCode config.
  */
 export const DEFAULT_MCP_SERVERS = {
-    'ff-local-recall': {
-        type: 'local',
-        command: 'ff-local-recall-mcp',
-        enabled: true,
-    },
     'jina-ai': {
         type: 'remote',
         url: 'https://mcp.jina.ai/v1',

package/package.json

@@ -1,15 +1,14 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "@syntesseraai/opencode-feature-factory",
-  "version": "0.3.6",
+  "version": "0.4.1",
   "type": "module",
   "description": "OpenCode plugin for Feature Factory agents - provides sub-agents and skills for validation, review, security, and architecture assessment",
   "license": "MIT",
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",
   "bin": {
-    "ff-deploy": "./bin/ff-deploy.js",
-    "ff-local-recall-mcp": "./bin/ff-local-recall-mcp.js"
+    "ff-deploy": "./bin/ff-deploy.js"
   },
   "files": [
     "dist",
@@ -35,9 +34,7 @@
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.0.0",
     "@opencode-ai/plugin": "^1.1.48",
-    "@orama/orama": "^3.0.0",
-    "glob": "^10.0.0",
-    "uuid": "^9.0.0"
+    "glob": "^10.0.0"
   },
   "devDependencies": {
     "@types/bun": "^1.2.6",

package/skills/ff-context-tracking/SKILL.md

@@ -465,12 +465,6 @@ Clean up agent context files.
 - Add "Clean up context" as final todo item
 - Track progress in both todo list AND context file
 
-### With ff-learning
-
-- Store important findings from other agents' contexts
-- Create memories about coordination patterns
-- Learn from how other agents approached similar tasks
-
 ## Best Practices Summary
 
 ### DO:
@@ -513,7 +507,9 @@ ff-agents-show(id: "planning-uuid") → Read implementation plan
 ff-agents-update:
 fileName: "building-{my-uuid}.md"
 content: |
+
 ---
+
 id: "{my-uuid}"
 agent: "building"
 title: "Implement OAuth"
@@ -522,6 +518,7 @@ status: "in-progress"
 started: "2026-02-02T14:30:00Z"
 parent: null
 delegated_to: []
+
 ---
 
     ## Context

package/skills/ff-learning/SKILL.md

@@ -1,339 +1,68 @@
----
-name: ff-learning
-description: Enables agents to capture, store, and retrieve learnings from their work. Uses Local-Recall MCP-backed memory system with automatic extraction from OpenCode sessions.
-license: MIT
-compatibility: opencode
-metadata:
-  audience: agents
-  category: knowledge-management
----
+# Feature Factory Learning Protocol
 
-# Learning Skill (Local-Recall)
+This skill enables agents to continuously document and retrieve knowledge across the lifecycle of a task. It replaces the legacy "local-recall" MCP daemon with a lightweight, transparent Markdown-based system that lives directly in the repository's `docs/learnings/` folder.
 
-Use this skill to capture insights, store knowledge, and retrieve past learnings to improve future work. Memories are stored as JSON in `ff-memories/memories/` and automatically extracted from OpenCode session history.
+## Core Philosophy
 
-## How It Works
+1. **Continuous Documentation:** Write down important facts, solutions, architectural decisions, and troubleshooting steps as soon as you verify them.
+2. **Transparent Storage:** Learnings are stored as plain Markdown files in `docs/learnings/` so they are reviewable, searchable, and committable.
+3. **Proactive Retrieval:** Before starting complex tasks or debugging, search the `docs/` and `docs/learnings/` directories to leverage past experience.
 
-The Local-Recall memory system has two paths for creating memories:
+## How to Use This Skill
 
-1. **Automatic extraction** – A background daemon reads OpenCode session history (`~/.local/share/opencode/storage/`) and extracts insights from assistant messages and thinking blocks.
-2. **Explicit storage** – Agents can store learnings directly using the `ff-learning-store` tool.
+### 1. Documenting New Knowledge (Writing)
 
-Both paths write to the same JSON-based memory store, ensuring a unified search experience.
+Whenever you discover a non-obvious solution, establish a new convention, or resolve a complex bug, create a learning document.
 
-## When to Use
+**Tool to use:** `write` tool to `docs/learnings/{topic-slug}.md`
 
-### Required (ALWAYS use when):
+**Naming Convention:**
+Use descriptive, kebab-case filenames: `docs/learnings/auth-token-refresh-flow.md`, `docs/learnings/docker-build-caching.md`.
 
-- **Completing any significant task** – Store what was learned
-- **Resolving errors or issues** – Document the solution for future reference
-- **Discovering new patterns** – Capture reusable approaches
-- **Making architectural decisions** – Record rationale and context
-- **Researching technologies** – Save key findings and sources
-
-### Optional (use when helpful):
-
-- **Quick fixes** – Simple one-line changes may not need learning capture
-- **Routine tasks** – Well-understood repetitive work
-- **Draft work** – Temporary explorations that won't be retained
-
-## Memory Categories
-
-Memories are organized by category:
-
-### 1. Pattern
-
-**What:** Reusable code patterns, architectural patterns, and best practices
-**When to use:** When a repeatable technique or approach is discovered
-**Example:** "React Server Components require 'use client' directive for client-side interactivity"
-
-### 2. Decision
-
-**What:** Architectural decisions, technology choices, and their rationale
-**When to use:** When a significant decision is made during planning or implementation
-**Example:** "Chose NextAuth.js over Auth0 for OAuth - simpler integration, lower cost for our scale"
-
-### 3. Debugging
-
-**What:** Error resolutions, debugging steps, and troubleshooting knowledge
-**When to use:** After resolving a non-trivial bug or error
-**Example:** "CSRF token mismatch in OAuth - resolved by adding explicit state parameter"
-
-### 4. Preference
-
-**What:** Team conventions, style preferences, and configuration choices
-**When to use:** When establishing or discovering project conventions
-**Example:** "Team prefers barrel exports for module directories"
-
-### 5. Context
-
-**What:** Domain knowledge, project context, and environmental information
-**When to use:** When important contextual information is gathered during research
-**Example:** "Production DB uses read replicas - write queries must target primary"
-
-### 6. Procedure
-
-**What:** Step-by-step procedures, workflows, and how-to guides
-**When to use:** When documenting a process that should be repeatable
-**Example:** "How to set up authentication with NextAuth.js in a Next.js application"
-
-## Tools
-
-The ff-learning skill provides three tools for interacting with the memory system.
-
-### Tool 1: Store Learning (ff-learning-store)
-
-**Purpose:** Create a new memory explicitly
-
-**When to use:**
-
-- At end of task completion
-- When insight or pattern is discovered
-- After error resolution
-- When research findings are significant
-
-**Input parameters:**
-
-- `title` (string, required): Brief title for the learning
-- `description` (string, required): Detailed description of the learning
-- `category` (enum, required): One of `pattern`, `decision`, `debugging`, `preference`, `context`, or `procedure`
-- `tags` (array of strings, required): Relevant keywords for search
-- `importance` (float, required): 0.0 to 1.0 (0.8+ for critical learnings)
-- `content` (string, optional): Additional body content
-- `source` (enum, optional): Origin – conversation, research, implementation, review
-- `relatedMemories` (array, optional): IDs of related memories
-
-**Example:**
-
-```markdown
-Store a learning using ff-learning-store:
-
-- title: "OAuth Implementation Pattern"
-- description: "Successfully implemented OAuth with NextAuth.js, resolved CSRF issues"
-- category: "pattern"
-- tags: ["oauth", "nextauth", "authentication"]
-- importance: 0.8
-- content: "Used state parameter to prevent CSRF. JWT strategy for session persistence."
-```
-
-### Tool 2: Search Learnings (ff-learning-search)
-
-**Purpose:** Find relevant memories by keywords and filters
-
-**When to use:**
-
-- At start of new task (find related past work)
-- When facing similar problem to previous one
-- For context gathering before planning
-- To avoid repeating mistakes
-
-**Input parameters:**
-
-- `query` (string, required): Search terms to match against title, body, and tags
-- `tags` (array, optional): Filter to memories containing ALL specified tags
-- `category` (enum, optional): Filter by category (`pattern`, `decision`, `debugging`, `preference`, `context`, `procedure`)
-- `limit` (number, optional): Max results, 1-50 (default: 10)
-- `minImportance` (float, optional): Minimum importance threshold
-
-**Example:**
+**Template:**
 
 ```markdown
-Search learnings:
-
-- query: "OAuth authentication"
-- tags: ["security"]
-- limit: 5
-```
-
-**Returns:** Array of matching memories sorted by relevance × importance, with id, title, category, tags, importance, and relevance score.
-
-### Tool 3: Get Learning (ff-learning-get)
-
-**Purpose:** Retrieve the full content of a specific memory
-
-**When to use:**
-
-- After search to read full details
-- When referenced by ID in another memory
-- For deep dive into specific learning
-
-**Input parameters:**
+# [Topic Title]
 
-- `memoryId` (string, required): UUID of the memory to retrieve
+**Date:** [Current Date]
+**Tags:** [comma, separated, tags]
 
-**Returns:** Complete memory object with all fields (id, sessionID, messageID, category, title, body, tags, importance, createdAt, extractedBy).
+## Context / Problem
 
-## File Organization
+[Briefly describe what you were trying to do or the problem you encountered.]
 
-### Directory Structure
+## Solution / Discovery
 
-```
-ff-memories/
-├── memories/           # All memory JSON files
-│   ├── {uuid}.json     # Individual memory files
-│   └── ...
-└── processed.json      # Tracks which messages have been processed
-```
-
-### Memory JSON Schema
+[Detail the exact solution, configuration, or architectural decision made.]
 
-Each memory is a JSON file with these fields:
+## Why this matters
 
-```json
-{
-  "id": "uuid-v4",
-  "sessionID": "ses_xxx",
-  "messageID": "msg_xxx",
-  "category": "pattern|decision|debugging|preference|context|procedure",
-  "title": "Brief descriptive title",
-  "body": "Detailed learning content",
-  "tags": ["keyword1", "keyword2"],
-  "importance": 0.8,
-  "createdAt": 1707900000000,
-  "extractedBy": "session|thinking|explicit"
-}
+[Explain why this approach was chosen or why the bug occurred.]
 ```
 
-## Usage by Agent Type
-
-### Planning Agent
-
-**When to capture:** After planning sessions, architectural decisions, risk identification
-**What to capture:** Architecture decisions (decision), risk factors (context), pattern discoveries (pattern)
-
-### Building Agent
-
-**When to capture:** After implementing features, overcoming challenges, resolving errors
-**What to capture:** Code patterns (pattern), error resolutions (debugging), integration insights (context)
-
-### Reviewing Agent
-
-**When to capture:** After completing reviews, identifying common issues
-**What to capture:** Common issue patterns (pattern), quality insights (context)
-
-### Research Agent
-
-**When to capture:** After research, significant findings, technology evaluations
-**What to capture:** Key findings (pattern), technology comparisons (decision), best practices (procedure)
-
-### Security Agent
-
-**When to capture:** After audits, vulnerability findings
-**What to capture:** Vulnerability patterns (debugging), security best practices (procedure)
-
-## Integration with Other Skills
-
-### With ff-delegation
-
-- Store learnings from delegated agents
-- Capture insights from parallel work
-- Link related memories across agent boundaries
-
-### With ff-todo-management
-
-- Add "Capture learnings" as final todo item
-- Track learning capture in todo list
-
-### With ff-mini-plan
-
-- Search past learnings during planning
-- Use previous patterns to inform new plans
-
-## Best Practices
-
-### Do:
+### 2. Retrieving Past Knowledge (Reading)
 
-- **Be specific** – Concrete details are more useful than generalities
-- **Use consistent tags** – Establish tag conventions for your project
-- **Set appropriate importance** – Reserve 0.8-1.0 for truly critical learnings
-- **Write searchable titles** – Use keywords that future you will search for
-- **Capture failures too** – What didn't work is as valuable as what did
-- **Search before storing** – Avoid duplicate memories
-- **Review periodically** – Search old learnings before starting new tasks
+Before diving into debugging or implementing features, scan the `docs/` and `docs/learnings/` directories for relevant context.
 
-### Don't:
+**Tools to use:**
 
-- **Store everything** – Not every small change needs a memory
-- **Use vague titles** – "Fixed bug" is not helpful; "Fixed race condition in auth middleware" is
-- **Store secrets** – Never put credentials or sensitive data in memories
-- **Be too brief** – One-line descriptions lack context
-- **Forget tags** – Untagged memories are hard to find
+- `glob` tool with pattern `docs/learnings/*.md` to see all stored learnings.
+- `grep` tool to search inside `docs/` and `docs/learnings/` for specific keywords (e.g., error messages, library names).
+- `read` tool to pull the full context of relevant markdown files.
 
-## Additional Tools for Read-Only Agents
+### 3. Updating Existing Knowledge (Refining)
 
-Since @planning and @reviewing agents are read-only (cannot write/edit files), the following tools are provided for essential file operations:
+If you find an existing learning document that is outdated or incomplete based on new work, use the `edit` tool to update it. Knowledge should evolve with the codebase.
 
-### Tool 4: Create Plan (ff-plan-create)
-
-**Purpose:** Create a new implementation plan file in `.feature-factory/plans/`
-
-**Input parameters:**
-
-- `title` (string, required): Title of the plan
-- `description` (string, required): What the plan covers
-- `content` (string, required): Full markdown content
-- `planType` (enum, required): implementation, architecture, migration, or research
-- `relatedIssues` (array, optional): Related issue IDs
-- `estimatedEffort` (string, optional): Time estimate
-
-### Tool 5: Create Agent Context (ff-agent-context-create)
-
-**Purpose:** Create a new agent context file in `.feature-factory/agents/`
-
-**Input parameters:**
-
-- `id` (string, required): UUID for this agent instance
-- `agent` (string, required): Agent type (planning, building, etc.)
-- `title` (string, required): Task title
-- `description` (string, required): Task description
-- `status` (enum, optional): in-progress, completed, delegated, failed
-- `parent` (string, optional): Parent agent UUID
-- `delegatedTo` (array, optional): Child agent UUIDs
-- `notes` (string, optional): Additional notes
-
-### Tool 6: Update Agent Context (ff-agent-context-update)
-
-**Purpose:** Update an existing agent context file
-
-**Input parameters:**
-
-- `agentId` (string, required): Agent UUID to update
-- `agent` (string, required): Agent type
-- `status` (enum, optional): New status
-- `addDelegatedTo` (string, optional): Add child agent UUID
-- `notes` (string, optional): Notes to append
-- `progressUpdate` (string, optional): Progress line to add
-
-## Quick Reference
-
-### Creating a Memory
-
-```markdown
-Store a learning:
-
-- title: "Descriptive searchable title"
-- description: "Detailed explanation of what was learned"
-- category: "pattern"
-- tags: ["relevant", "keywords"]
-- importance: 0.8
-```
-
-### Searching Memories
-
-```markdown
-Search learnings:
-
-- query: "authentication"
-- tags: ["oauth", "security"]
-- limit: 5
-```
+## When to Document a Learning
 
-### Memory Checklist
+- **Architectural Decisions:** Why a specific library, pattern, or approach was chosen over alternatives.
+- **Environment Quirks:** Specific workarounds needed for local dev, testing, or deployment.
+- **Complex Debugging:** A root cause analysis of a tricky bug and how it was fixed.
+- **Undocumented Behaviors:** Workarounds for third-party API quirks or internal system edge cases.
 
-Before storing a memory, verify:
+## Checklist for Agents
 
-- [ ] Title is descriptive and searchable
-- [ ] Description explains what was learned
-- [ ] Tags are relevant and consistent
-- [ ] Importance is appropriate (0.0-1.0)
-- [ ] No sensitive data included
+- [ ] Have I encountered a novel problem or established a new pattern? -> **Document it.**
+- [ ] Am I stuck on an error or unclear on a convention? -> **Search `docs/learnings/`.**
+- [ ] Is an existing learning document inaccurate? -> **Update it.**

package/bin/ff-local-recall-mcp.js

@@ -1,9 +0,0 @@
-#!/usr/bin/env node
-
-import { runLocalRecallMCPServer } from '../dist/local-recall/mcp-stdio-server.js';
-
-runLocalRecallMCPServer().catch((error) => {
-  const message = error instanceof Error ? error.message : String(error);
-  console.error(`Failed to start ff-local-recall MCP server: ${message}`);
-  process.exit(1);
-});