@syntesseraai/opencode-feature-factory 0.10.2 → 0.10.4

package/README.md

@@ -1,6 +1,6 @@
 # @syntesseraai/opencode-feature-factory
 
-OpenCode plugin that provides Feature Factory agents, skills, and pipeline commands.
+OpenCode plugin that provides Feature Factory agents, skills, and workflow MCP tools.
 
 ## Installation
 
@@ -19,136 +19,65 @@ OpenCode plugin that provides Feature Factory agents, skills, and pipeline comma
 npx @syntesseraai/opencode-feature-factory install
 ```
 
-This installer deploys to `~/.config/opencode/`:
+The installer deploys to `~/.config/opencode/`:
 
 - `agents/`
 - `skills/`
-- `command/`
 
 It also updates `~/.config/opencode/opencode.json` non-destructively by merging missing Feature Factory MCP entries and plugins without deleting existing user configuration.
 
 ## Install Behavior
 
-- **Always overwrites packaged assets**: installer unconditionally overwrites Feature Factory `agents`, `skills`, and `command` files on every install.
+- **Always overwrites packaged assets**: installer unconditionally overwrites Feature Factory `agents` and `skills` files on every install.
 - **`opencode.json` is non-destructive**: existing keys/values are preserved; only missing required plugin/MCP entries are added.
 - **Global scope**: assets are installed to `~/.config/opencode/` and shared across projects.
 
-## Agent Frontmatter Metadata
-
-All shipped Feature Factory agent manifests under `agents/*.md` include a `color` frontmatter field using a valid hex value.
-
-| Agent             | Color     |
-| ----------------- | --------- |
-| `feature-factory` | `#10b981` |
-| `planning`        | `#3b82f6` |
-| `building`        | `#22c55e` |
-| `reviewing`       | `#8b5cf6` |
-| `documenting`     | `#f97316` |
-| `ff-research`     | `#6366f1` |
-
-These colors are intentionally unique to avoid collisions in OpenCode agent UIs and logs.
-
-## Pipeline Entrypoint
-
-- Invoke `/pipeline/start <requirements-brief>` directly from any agent (e.g. `@building`).
-- There is no dedicated `@pipeline` intake agent; the command tree handles orchestration autonomously.
-- Orchestration is implemented by the command tree under `command/pipeline/` using subtask2 primitives (`return`, `parallel`, `loop`).
-- Orchestration wrapper commands (`/pipeline/start`, `/pipeline/*/run`, `/pipeline/complete`) pin `agent: general` to avoid recursive self-invocation before phase-specific delegation begins.
-- Coordinator and synthesis model defaults to ChatGPT 5.4 via frontmatter `model:` declarations in orchestrator commands.
-- All orchestrator commands include an explicit **orchestrator constraint**: they must NOT directly read, edit, modify, write, or create any code/config/repository files — they only dispatch sub-commands, pass structured data via `{as:name}` / `$RESULT[name]`, and evaluate gate/loop conditions.
-
 ## Tools
 
 The plugin exposes three MCP tools via the `feature-factory` agent:
 
-| Tool             | Description                                                                                                                                                                                                                       |
-| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `ff_pipeline`    | Full multi-model pipeline: planning → build → CI → review → documentation. Uses hardcoded per-role model defaults (see Model Routing below).                                                                                      |
-| `ff_mini_loop`   | Lightweight build → CI → review → documentation loop. **Does not hardcode model defaults** — all roles inherit the current session model when omitted. CI validation runs `ff-ci.sh` if present (up to 3 attempts with auto-fix). |
-| `ff_list_models` | Read-only discovery tool. Queries the OpenCode SDK to list all available providers, models, capability badges, connected status, and defaults.                                                                                    |
+| Tool             | Description                                                                                                                                                                               |
+| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `ff_pipeline`    | Full multi-model workflow: planning -> build -> CI -> review -> documentation. Uses hardcoded per-role model defaults and supports optional `worktree_isolation` / `worktree_parent_dir`. |
+| `ff_mini_loop`   | Lightweight build -> CI -> review -> documentation loop. Model parameters inherit the current session model when omitted. Supports optional `worktree_isolation` / `worktree_parent_dir`. |
+| `ff_list_models` | Read-only discovery tool that lists available providers/models and defaults from the OpenCode SDK.                                                                                        |
 
 ### Mini-Loop Model Inheritance
 
-When `ff_mini_loop` model parameters are omitted, child sessions inherit the parent session's model (the SDK `model` field is omitted entirely from the prompt body). The `doc_model` has a cascade: if `build_model` is explicitly set but `doc_model` is not, the documentation step uses the same model as build. Users can call `ff_list_models` to discover available `provider/model` strings before overriding.
-
-## Command Tree
-
-- `/pipeline/start`
-- `/pipeline/planning/run`, `/pipeline/planning/plan`, `/pipeline/planning/synthesize`, `/pipeline/planning/gate`, `/pipeline/planning/confirm`
-- `/pipeline/building/run`, `/pipeline/building/breakdown`, `/pipeline/building/validate-batch`, `/pipeline/building/implement-batch`
-- `/pipeline/reviewing/run`, `/pipeline/reviewing/triage`, `/pipeline/reviewing/review`, `/pipeline/reviewing/synthesize`, `/pipeline/reviewing/gate`
-- `/pipeline/documentation/run`, `/pipeline/documentation/document`, `/pipeline/documentation/review`, `/pipeline/documentation/gate`
-- `/pipeline/complete`
-- `/mini-loop/start`
-- `/mini-loop/implementation/run`, `/mini-loop/implementation/build`, `/mini-loop/implementation/review`, `/mini-loop/implementation/gate`
-- `/mini-loop/documentation/run`, `/mini-loop/documentation/document`, `/mini-loop/documentation/review`, `/mini-loop/documentation/gate`
-- Mini-loop wrapper commands (`/mini-loop/start`, `/mini-loop/*/run`) also pin `agent: general` so they can be safely launched from any caller agent.
-
-## Model Routing
-
-Models are declared in each command's frontmatter (`model:` field). Multi-model fan-out targets (`plan.md`, `review.md`) use per-invocation `{model:...}` overrides since they are invoked multiple times with different models.
+When `ff_mini_loop` model parameters are omitted, child sessions inherit the parent session model (the SDK `model` field is omitted). The `doc_model` has a cascade: if `build_model` is set and `doc_model` is omitted, documentation uses `build_model`.
 
-| Role                    | Model                       | Commands                                                                    |
-| ----------------------- | --------------------------- | --------------------------------------------------------------------------- |
-| Orchestration/reasoning | `openai/gpt-5.4`            | All `run.md`, `start.md`, `complete.md`, gates, triage, synthesize, confirm |
-| Implementation          | `openai/gpt-5.3-codex`      | `implement-batch`, `build`, `document`                                      |
-| Architecture analysis   | `anthropic/claude-opus-4-6` | `breakdown`, review fan-out (opus slot)                                     |
-| Validation              | `opencode/gemini-3.1-pro`   | `validate-batch`, documentation review, review fan-out (gemini slot)        |
-| Multi-model fan-out     | per-invocation              | `plan.md`, `review.md`                                                      |
+## Global Config Defaults
 
-- Pipeline stages pass intermediate artifacts with `{as:name}` and `$RESULT[name]` (minimal file persistence)
-- Planning fan-out (with architecture validation): opus, gemini, and codex models in parallel
-- Implementation: codex via frontmatter model declaration in `implement-batch.md`, with parallel `building` sub-agents per independent task within each batch
-- Review fan-out (with architecture validation): opus, gemini, and codex models in parallel
-- Rework path: `/pipeline/reviewing/run` re-enters implementation via `/pipeline/building/implement-batch` when gate status is `REWORK`
-- Documentation stage: codex updates documentation, gemini reviews docs, and orchestrator (`gpt-5.4`) supervises a bounded loop until approved
-- Documentation stage skill usage: codex pass loads `ff-todo-management`, `ff-mini-plan`; gemini review pass loads `ff-report-templates` and `ff-severity-classification`
+The plugin merges the following MCP servers into global OpenCode config when missing:
 
-## Quality Gates
+- `jina-ai`
+- `gh_grep`
+- `context7`
+- `morph-mcp`
 
-- Planning approval: `>=75%` consensus.
-- Review approval: `>=95%` confidence and zero unresolved issues.
-- Documentation approval: documentation reviewer verdict `APPROVED` with zero unresolved documentation issues.
-- Planning loop confirmation: after 5 unsuccessful planning iterations, pipeline asks user whether to continue.
-
-## Async Progress Notifications
-
-Both `ff_pipeline` and `ff_mini_loop` tools run asynchronously with real-time progress notifications:
-
-- **Immediate return**: Tools return instantly with a brief acknowledgment (e.g. `Pipeline started for: <summary>`), so the LLM can continue the conversation.
-- **Background orchestration**: The full pipeline or mini-loop runs in a detached `Promise`. All child session orchestration (fan-out, gates, loops) remains identical — it just executes after the tool returns.
-- **Progress updates via `promptAsync(noReply: true)`**: After each major phase completes, a structured notification is injected into the parent session as a visible chat message. These appear in the OpenCode TUI without triggering an LLM turn.
-- **Phase-by-phase visibility**: Users see updates for planning, building, CI validation (when `ff-ci.sh` present), each review iteration gate decision, each documentation iteration, and the final completion report.
-- **Error notifications**: If the background orchestration throws, a `# Pipeline: Error` or `# Mini-Loop: Error` notification is sent with the last phase and error message.
-- **`context.metadata()` retained**: All existing metadata calls remain in place for future-proofing (when OpenCode's TUI renders tool metadata natively).
-
-### Notification Format
-
-Pipeline notifications use plain-text markdown headers with phase START/END bracketing and per-iteration gate details:
+`morph-mcp` is configured as:
 
+```json
+"morph-mcp": {
+  "type": "local",
+  "command": ["npx", "-y", "@morphllm/morphmcp"],
+  "environment": {
+    "MORPH_API_KEY": "{env:MORPH_API_KEY}"
+  }
+}
 ```
-# Pipeline: Reviewing — Iteration 2/10
 
-Status: APPROVED
-Confidence: 97%
-Unresolved Issues: 0
-Duration: 45.3s
-Feedback: N/A
-```
+### Merge Outcomes
 
-Mini-loop notifications follow the same pattern:
+`DEFAULT_MCP_SERVERS` currently includes 4 servers (`jina-ai`, `gh_grep`, `context7`, `morph-mcp`).
 
-```
-# Mini-Loop: Building — Iteration 1/10
+The merge behavior is additive and non-destructive:
 
-Status: REWORK
-Confidence: 82%
-Unresolved Issues: 2
-Duration: 23.1s
-Feedback: Fix type errors in handler.ts
-```
+- Empty or missing existing MCP config -> 4 servers after merge.
+- Existing config with 1 custom server and a customized `gh_grep` entry -> 5 servers after merge (custom + customized `gh_grep` + 3 missing defaults).
+- Existing server definitions are preserved and never overwritten by defaults.
 
-Final reports use `# Pipeline: Complete` or `# Mini-Loop: Complete` headers containing the full markdown report. Errors use `# Pipeline: Error` or `# Mini-Loop: Error`.
+The plugin list is also merged non-destructively to ensure required companion plugins are present.
 
 ## Related Docs
 

package/agents/building.md

@@ -4,10 +4,10 @@ mode: primary
 color: '#22c55e'
 tools:
   read: true
-  write: true
-  edit: true
+  write: false
+  edit: false
+  edit_file: true
   bash: true
-  hashline_edit: true
   skill: true
   task: true
 permission:
@@ -34,23 +34,19 @@ You are the building specialist.
 - Do not rely on intermediate artifact files for pipeline progression.
 - Persist only when explicitly requested by the user.
 
-## Hashline Workflow (Required)
+## Editing Workflow (Required)
 
-File reads and edits use hashline-annotated tools. The `read` tool returns lines annotated with `#HL <line>:<hash>|<content>` and a `#HL REV:<hash>` header. Follow this workflow:
+Use Morph MCP `edit_file` for all implementation edits.
 
-1. **Always `read` before editing.** Note the `REV` value from the `#HL REV:<hash>` header — you need it for edits.
-2. **Use `hashline_edit`** for targeted, hash-referenced edits. Operations: `replace`, `delete`, `insert_before`, `insert_after`. Example:
-   ```json
-   { "path": "src/app.ts", "operation": "replace", "startRef": "5:a3f", "replacement": "const value = 2", "fileRev": "72c4946c" }
-   ```
-3. **Use built-in `edit`/`write`** for standard edits — hashline prefixes are automatically stripped before the tool executes.
-4. **After any edit/write**, re-read the file to get fresh refs before further edits.
-
-Never fabricate refs — always use exactly the refs returned by `read`.
+1. **Read before editing** to confirm current behavior and scope.
+2. **Apply changes with `edit_file`** for targeted replacements/insertions.
+3. **Re-read after edits** to verify the applied diff and avoid stale assumptions.
+4. **Avoid fallback editors** unless `edit_file` cannot express the required change.
 
 ## Semantic Code Search
 
 Use `cocoindex-code_search` for semantic code search when you need to:
+
 - Find implementations by meaning, not just text matching (e.g., "authentication logic", "database connection handling")
 - Locate related code without knowing exact names or keywords
 - Understand how features work across the codebase

package/agents/documenting.md

@@ -4,10 +4,10 @@ mode: primary
 color: '#f97316'
 tools:
   read: true
-  write: true
-  edit: true
+  write: false
+  edit: false
+  edit_file: true
   bash: false
-  hashline_edit: true
   skill: true
   task: true
 permission:
@@ -26,19 +26,14 @@ You are the documenting specialist.
 - Keep docs concise, consistent, and free of stale references.
 - Return a structured summary for documentation review.
 
-## Hashline Workflow (Required)
+## Editing Workflow (Required)
 
-File reads and edits use hashline-annotated tools. The `read` tool returns lines annotated with `#HL <line>:<hash>|<content>` and a `#HL REV:<hash>` header. Follow this workflow:
+Use Morph MCP `edit_file` for documentation updates.
 
-1. **Always `read` before editing.** Note the `REV` value — you need it for edits.
-2. **Use `hashline_edit`** for targeted, hash-referenced edits. Operations: `replace`, `delete`, `insert_before`, `insert_after`. Example:
-   ```json
-   { "path": "docs/FILE.md", "operation": "replace", "startRef": "5:a3f", "replacement": "Updated text", "fileRev": "72c4946c" }
-   ```
-3. **Use built-in `edit`/`write`** for standard edits — hashline prefixes are automatically stripped.
-4. **After any edit/write**, re-read the file to get fresh refs before further edits.
-
-Never fabricate refs — always use exactly the refs returned by `read`.
+1. **Read before editing** to confirm the current content and linked references.
+2. **Apply changes with `edit_file`** for precise doc updates.
+3. **Re-read after edits** to validate wording and cross-doc consistency.
+4. **Avoid fallback editors** unless `edit_file` cannot express the required change.
 
 ## Semantic Code Search
 

package/agents/feature-factory.md

@@ -7,7 +7,6 @@ tools:
   write: false
   edit: false
   bash: false
-  hashline_edit: false
   skill: true
   task: true
   ff_pipeline: true
@@ -32,6 +31,7 @@ Work through this process step by step. Do NOT skip steps or launch a tool until
 ## Semantic Code Search
 
 Use `cocoindex-code_search` to quickly understand the codebase when clarifying requirements:
+
 - Search by meaning (e.g., "user authentication flow", "API rate limiting") to understand existing architecture
 - Use this to give informed answers when the user asks about current behavior
 
@@ -40,6 +40,7 @@ Use `cocoindex-code_search` to quickly understand the codebase when clarifying r
 ## Step 1: Understand the request
 
 Work through the user's request in a Socratic manner:
+
 - Ask clarifying questions about scope, constraints, and acceptance criteria.
 - Summarise your understanding back to them and ask them to confirm or correct it.
 - Continue until you have a clear, unambiguous set of requirements.
@@ -53,6 +54,7 @@ If the user hasn't provided a request yet, ask them what they would like to buil
 Once requirements are agreed, present the two workflow options:
 
 **Pipeline** (full multi-model workflow)
+
 - Multi-model fan-out planning (3 models propose plans, then consensus synthesis)
 - Build phase with task breakdown and batch validation
 - Multi-model fan-out code review
@@ -60,6 +62,7 @@ Once requirements are agreed, present the two workflow options:
 - Best for: complex features, architectural changes, high-risk work
 
 **Mini-loop** (lightweight workflow)
+
 - Direct build → review loop (single model per step)
 - Documentation with review loop
 - Best for: small features, bug fixes, incremental improvements, well-understood changes
@@ -73,6 +76,7 @@ Ask the user which workflow they prefer. If they are unsure, recommend one based
 Present the default models that will be used for the chosen workflow:
 
 **Pipeline defaults:** (hardcoded per-role model assignments)
+
 - Planning fan-out: opus (anthropic/claude-opus-4-6), gemini (opencode/gemini-3.1-pro), codex (openai/gpt-5.3-codex)
 - Review fan-out: same as planning
 - Orchestrator (synthesis/triage): openai/gpt-5.4
@@ -82,6 +86,7 @@ Present the default models that will be used for the chosen workflow:
 - Doc review: opencode/gemini-3.1-pro
 
 **Mini-loop defaults:** (inherits the current session model)
+
 - All roles (build, review, documentation, doc review) default to the **current session model** — no hardcoded model is forced.
 - This means the mini-loop automatically uses whatever model you're currently chatting with.
 - You can override any individual role if desired (e.g., use a different model for review).
@@ -92,13 +97,19 @@ For the **Mini-loop**, ask: "The mini-loop will use your current session model f
 
 If they want to override, collect the provider/model strings for each role they want to change.
 
+Before moving to launch, also confirm execution isolation:
+
+- Ask whether they want **worktree isolation** enabled.
+- Explain: when enabled, the workflow runs in a dedicated detached git worktree directory to avoid collisions with other concurrent runs.
+- If enabled, optionally collect a custom `worktree_parent_dir`; otherwise default behavior is used.
+
 ---
 
 ## Step 4: Launch
 
 Once all three steps are confirmed, call the appropriate tool:
 
-- If they chose **Pipeline**: call the `ff_pipeline` tool with the agreed requirements and any model overrides.
-- If they chose **Mini-loop**: call the `ff_mini_loop` tool with the agreed requirements and any model overrides.
+- If they chose **Pipeline**: call the `ff_pipeline` tool with the agreed requirements, any model overrides, and worktree options when requested.
+- If they chose **Mini-loop**: call the `ff_mini_loop` tool with the agreed requirements, any model overrides, and worktree options when requested.
 
-Pass only the model parameters that were explicitly overridden; omit any that should use defaults.
+Pass only model parameters that were explicitly overridden, and include worktree parameters only when explicitly requested.

package/agents/ff-research.md

@@ -7,7 +7,6 @@ tools:
   write: false
   edit: false
   bash: false
-  hashline_edit: false
   skill: true
   task: false
 permission:
@@ -28,6 +27,7 @@ You are the research specialist.
 You have access to powerful external research tools. **Use them proactively:**
 
 ### Web Search & Reading
+
 - **`jina-ai_search_web`** — Search the web for current information, docs, articles. Use for up-to-date library info, best practices, changelogs.
 - **`jina-ai_read_url`** — Read and extract content from any URL. Use to read official documentation, blog posts, READMEs.
 - **`jina-ai_expand_query`** — Expand search queries for broader coverage.
@@ -35,17 +35,21 @@ You have access to powerful external research tools. **Use them proactively:**
 - **`jina-ai_parallel_read_url`** — Read multiple URLs in parallel.
 
 ### Library Documentation
+
 - **`context7_resolve-library-id`** — Resolve a library name to a Context7 ID. Call this first before querying docs.
 - **`context7_query-docs`** — Query up-to-date library documentation with code examples. Excellent for API usage, configuration, and best practices.
 
 ### Code Examples
+
 - **`gh_grep_searchGitHub`** — Find real-world code examples from public GitHub repos. Search for literal code patterns (e.g., `useState(`, `import React from`), NOT keywords. Use to see how real projects implement specific patterns.
 
 ### Academic Papers
+
 - **`jina-ai_search_arxiv`** — Search arXiv for research papers (AI, CS, physics, math).
 - **`jina-ai_search_ssrn`** — Search SSRN for social science research.
 
 ### Semantic Code Search
+
 - **`cocoindex-code_search`** — Search the local codebase by meaning. Use to understand the project's existing patterns before recommending changes.
 
 ## Method

package/agents/planning.md

@@ -7,7 +7,6 @@ tools:
   write: false
   edit: false
   bash: false
-  hashline_edit: false
   skill: true
   task: true
 permission:
@@ -26,15 +25,16 @@ You are the planning specialist.
 - Identify risks, assumptions, and validation strategy.
 - Apply planning gate criteria and emit explicit status lines.
 
-## Hashline Workflow (Required)
+## Editing Guidance
 
-Use the `read` tool to inspect files. Lines are annotated with `#HL <line>:<hash>|<content>` and a `#HL REV:<hash>` header. Use these refs when planning edit operations — include the `startRef` values in your implementation steps so the builder can apply them directly.
+Implementation should prefer Morph MCP `edit_file` for code changes. In planning outputs, reference concrete files and intended edits, not line-hash references.
 
 You are a read-only agent — you do not write or edit files.
 
 ## Semantic Code Search
 
 Use `cocoindex-code_search` for semantic code search when planning:
+
 - Understand existing architecture by meaning (e.g., "authentication logic", "API routing")
 - Find related implementations before proposing changes
 - Verify assumptions about how code works
@@ -44,6 +44,7 @@ Prefer this over `grep` when searching by concept rather than exact text.
 ## External Research
 
 Use `@ff-research` for external/library uncertainty. The research agent has access to:
+
 - `jina-ai_search_web` / `jina-ai_read_url` for web search and documentation
 - `context7_query-docs` for library-specific documentation
 - `gh_grep_searchGitHub` for real-world code examples

package/agents/reviewing.md

@@ -7,7 +7,6 @@ tools:
   write: false
   edit: false
   bash: false
-  hashline_edit: false
   skill: true
   task: true
 permission:
@@ -26,15 +25,16 @@ You are the unified reviewing specialist.
 - Apply scope based on context: acceptance, code quality, security, architecture, documentation.
 - Return actionable findings with severity and confidence.
 
-## Hashline Workflow (Required)
+## File Review Guidance
 
-Use the `read` tool to inspect files. Lines are annotated with `#HL <line>:<hash>|<content>` and a `#HL REV:<hash>` header. Use these refs to cite specific lines in your review findings.
+Use the `read` tool to inspect files and cite standard line references in findings. Do not require hash-based line references.
 
 You are a read-only agent — you do not write or edit files.
 
 ## Semantic Code Search
 
 Use `cocoindex-code_search` for semantic code search when reviewing:
+
 - Search by meaning to find related code (e.g., "input validation", "access control checks")
 - Verify that implementations match architectural patterns across the codebase
 - Find similar code to check for consistency

package/bin/ff-deploy.js

@@ -3,7 +3,7 @@
 /**
  * Feature Factory Deployment Script
  *
- * Deploys skills, agents, and command files to the global OpenCode configuration directory.
+ * Deploys skills and agents to the global OpenCode configuration directory.
  * Run manually with: npx @syntesseraai/opencode-feature-factory
  */
 
@@ -18,13 +18,11 @@ const __dirname = dirname(__filename);
 const GLOBAL_CONFIG_DIR = join(homedir(), '.config', 'opencode');
 const SKILLS_DIR = join(GLOBAL_CONFIG_DIR, 'skills');
 const AGENTS_DIR = join(GLOBAL_CONFIG_DIR, 'agents');
-const COMMAND_DIR = join(GLOBAL_CONFIG_DIR, 'command');
 const GLOBAL_CONFIG_FILE = join(GLOBAL_CONFIG_DIR, 'opencode.json');
 
 const PACKAGE_ROOT = join(__dirname, '..');
 const SOURCE_SKILLS_DIR = join(PACKAGE_ROOT, 'skills');
 const SOURCE_AGENTS_DIR = join(PACKAGE_ROOT, 'agents');
-const SOURCE_COMMAND_DIR = join(PACKAGE_ROOT, 'command');
 
 // Check if running in interactive mode (has TTY)
 const isInteractive = process.stdin.isTTY && process.stdout.isTTY;
@@ -49,6 +47,13 @@ const DEFAULT_MCP_SERVERS = {
       CONTEXT7_API_KEY: '{env:CONTEXT7_API_KEY}',
     },
   },
+  'morph-mcp': {
+    type: 'local',
+    command: ['npx', '-y', '@morphllm/morphmcp'],
+    environment: {
+      MORPH_API_KEY: '{env:MORPH_API_KEY}',
+    },
+  },
 };
 
 const DEFAULT_PLUGINS = [
@@ -57,7 +62,6 @@ const DEFAULT_PLUGINS = [
   '@franlol/opencode-md-table-formatter@latest',
   '@spoons-and-mirrors/subtask2@latest',
   'opencode-pty@latest',
-  'opencode-hashline@latest',
 ];
 
 function getPackageBaseName(plugin) {
@@ -132,26 +136,6 @@ async function getFileNames(dir) {
   }
 }
 
-async function getMarkdownFileCount(dir) {
-  try {
-    const entries = await fs.readdir(dir, { withFileTypes: true });
-    let count = 0;
-
-    for (const entry of entries) {
-      const entryPath = join(dir, entry.name);
-      if (entry.isDirectory()) {
-        count += await getMarkdownFileCount(entryPath);
-      } else if (entry.isFile() && entry.name.endsWith('.md')) {
-        count += 1;
-      }
-    }
-
-    return count;
-  } catch {
-    return 0;
-  }
-}
-
 async function updateMCPConfig() {
   if (isInteractive) {
     console.log('\n🔧 MCP Configuration Update');
@@ -292,7 +276,6 @@ async function deploy() {
     await ensureDir(GLOBAL_CONFIG_DIR);
     await ensureDir(SKILLS_DIR);
     await ensureDir(AGENTS_DIR);
-    await ensureDir(COMMAND_DIR);
 
     // Get existing skills/agents for reporting
     const existingSkills = await getDirectoryNames(SKILLS_DIR);
@@ -333,22 +316,11 @@ async function deploy() {
       }
     }
 
-    // Deploy command files
-    if (isInteractive) {
-      console.log('\n⌨️  Deploying Commands...');
-    }
-    await copyDir(SOURCE_COMMAND_DIR, COMMAND_DIR);
-    const commandsCount = await getMarkdownFileCount(SOURCE_COMMAND_DIR);
-    if (isInteractive) {
-      console.log(`  ✅ pipeline commands (${commandsCount} files) (overwritten)`);
-    }
-
     // Summary
     if (isInteractive) {
       console.log('\n✨ Deployment Complete!');
       console.log(`   Skills: ${skills.length} deployed`);
       console.log(`   Agents: ${agents.length} deployed`);
-      console.log(`   Commands: ${commandsCount} deployed`);
       console.log(`   Location: ${GLOBAL_CONFIG_DIR}`);
       console.log('\n📝 Next Steps:');
       console.log('   - Restart OpenCode or run /reload to load new agents');

package/dist/index.js

@@ -45,8 +45,8 @@ export const FeatureFactoryPlugin = async (input) => {
     const qualityGateHooks = await StopQualityGateHooksPlugin(input).catch(() => ({}));
     // Tool registry: workflow tools (ff_pipeline, ff_mini_loop) powered by
     // the SDK client for programmatic session orchestration.
-    // The old ff-* artifact tools were removed; these replace the subtask2
-    // command-based workflow with TypeScript-driven orchestration.
+    // The old ff-* artifact tools were removed; orchestration is fully
+    // TypeScript-driven via these workflow tools.
     const workflowTools = createWorkflowTools(input.client);
     // Merge workflow tools with any existing tools from quality gate hooks
     const existingTools = qualityGateHooks.tool ?? {};

package/dist/mcp-config.d.ts

@@ -22,12 +22,20 @@ export declare const DEFAULT_MCP_SERVERS: {
             readonly CONTEXT7_API_KEY: "{env:CONTEXT7_API_KEY}";
         };
     };
+    readonly 'morph-mcp': {
+        readonly type: "local";
+        readonly command: readonly ["npx", "-y", "@morphllm/morphmcp"];
+        readonly environment: {
+            readonly MORPH_API_KEY: "{env:MORPH_API_KEY}";
+        };
+    };
 };
 export interface MCPServerConfig {
     type: 'local' | 'remote';
-    command?: string;
+    command?: string[];
     url?: string;
     headers?: Record<string, string>;
+    environment?: Record<string, string>;
     enabled?: boolean;
 }
 export interface MCPServers {

package/dist/mcp-config.js

@@ -22,6 +22,13 @@ export const DEFAULT_MCP_SERVERS = {
             CONTEXT7_API_KEY: '{env:CONTEXT7_API_KEY}',
         },
     },
+    'morph-mcp': {
+        type: 'local',
+        command: ['npx', '-y', '@morphllm/morphmcp'],
+        environment: {
+            MORPH_API_KEY: '{env:MORPH_API_KEY}',
+        },
+    },
 };
 /**
  * Merge MCP servers, preserving existing servers and adding new ones.

package/dist/plugin-config.js

@@ -10,7 +10,6 @@ export const DEFAULT_PLUGINS = [
     '@franlol/opencode-md-table-formatter@latest',
     '@spoons-and-mirrors/subtask2@latest',
     'opencode-pty@latest',
-    'opencode-hashline@latest',
 ];
 /**
  * Extract the base package name from a plugin specifier, stripping the

package/dist/tools/mini-loop.d.ts

@@ -17,6 +17,8 @@ export declare function createMiniLoopTool(client: Client): {
         review_model: import("zod").ZodOptional<import("zod").ZodString>;
         doc_model: import("zod").ZodOptional<import("zod").ZodString>;
         doc_review_model: import("zod").ZodOptional<import("zod").ZodString>;
+        worktree_isolation: import("zod").ZodOptional<import("zod").ZodBoolean>;
+        worktree_parent_dir: import("zod").ZodOptional<import("zod").ZodString>;
     };
     execute(args: {
         requirements: string;
@@ -24,5 +26,7 @@ export declare function createMiniLoopTool(client: Client): {
         review_model?: string | undefined;
         doc_model?: string | undefined;
         doc_review_model?: string | undefined;
+        worktree_isolation?: boolean | undefined;
+        worktree_parent_dir?: string | undefined;
     }, context: import("@opencode-ai/plugin/tool").ToolContext): Promise<string>;
 };