@syntesseraai/opencode-feature-factory 0.10.1 → 0.10.3

package/README.md

@@ -61,11 +61,11 @@ These colors are intentionally unique to avoid collisions in OpenCode agent UIs
 
 The plugin exposes three MCP tools via the `feature-factory` agent:
 
-| Tool             | Description                                                                                                                                       |
-| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `ff_pipeline`    | Full multi-model pipeline: planning → build → review → documentation. Uses hardcoded per-role model defaults (see Model Routing below).           |
-| `ff_mini_loop`   | Lightweight build → review → documentation loop. **Does not hardcode model defaults** — all roles inherit the current session model when omitted. |
-| `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 pipeline: planning → build → CI → review → documentation. Uses hardcoded per-role model defaults (see Model Routing below). Supports optional `worktree_isolation` / `worktree_parent_dir` for run-level git worktree isolation.                                                 |
+| `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). Supports optional `worktree_isolation` / `worktree_parent_dir`. |
+| `ff_list_models` | Read-only discovery tool. Queries the OpenCode SDK to list all available providers, models, capability badges, connected status, and defaults.                                                                                                                                                    |
 
 ### Mini-Loop Model Inheritance
 
@@ -118,7 +118,7 @@ Both `ff_pipeline` and `ff_mini_loop` tools run asynchronously with real-time pr
 - **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, each review iteration gate decision, each documentation iteration, and the final completion report.
+- **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).
 
@@ -150,6 +150,14 @@ Feedback: Fix type errors in handler.ts
 
 Final reports use `# Pipeline: Complete` or `# Mini-Loop: Complete` headers containing the full markdown report. Errors use `# Pipeline: Error` or `# Mini-Loop: Error`.
 
+## Run Isolation
+
+- Every `ff_pipeline` / `ff_mini_loop` invocation now creates a dedicated run parent session under the caller session.
+- All workflow child prompts and progress notifications are routed through that run parent session to keep caller context slim.
+- When `worktree_isolation: true`, the workflow runs in a dedicated detached git worktree directory.
+- Detached worktrees are cleaned up automatically after the background run finishes, exits early, or fails.
+- CI checks (`ff-ci.sh`) run against the resolved run directory (worktree when enabled, current directory otherwise).
+
 ## Related Docs
 
 - `docs/PIPELINE_ORCHESTRATION.md`

package/agents/feature-factory.md

@@ -32,6 +32,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 +41,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 +55,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 +63,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 +77,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 +87,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 +98,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/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>;
 };