@syntesseraai/opencode-feature-factory 0.10.2 → 0.10.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +13 -5
- package/agents/feature-factory.md +15 -3
- package/dist/tools/mini-loop.d.ts +4 -0
- package/dist/tools/mini-loop.js +311 -289
- package/dist/tools/pipeline.d.ts +4 -0
- package/dist/tools/pipeline.js +516 -494
- package/dist/workflow/fan-out.d.ts +20 -3
- package/dist/workflow/fan-out.js +34 -8
- package/dist/workflow/orchestrator.d.ts +1 -1
- package/dist/workflow/orchestrator.js +1 -1
- package/dist/workflow/run-isolation.d.ts +13 -0
- package/dist/workflow/run-isolation.js +77 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -61,11 +61,11 @@ These colors are intentionally unique to avoid collisions in OpenCode agent UIs
|
|
|
61
61
|
|
|
62
62
|
The plugin exposes three MCP tools via the `feature-factory` agent:
|
|
63
63
|
|
|
64
|
-
| Tool | Description
|
|
65
|
-
| ---------------- |
|
|
66
|
-
| `ff_pipeline` | Full multi-model pipeline: planning → build → CI → review → documentation. Uses hardcoded per-role model defaults (see Model Routing below).
|
|
67
|
-
| `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). |
|
|
68
|
-
| `ff_list_models` | Read-only discovery tool. Queries the OpenCode SDK to list all available providers, models, capability badges, connected status, and defaults.
|
|
64
|
+
| Tool | Description |
|
|
65
|
+
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
66
|
+
| `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. |
|
|
67
|
+
| `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`. |
|
|
68
|
+
| `ff_list_models` | Read-only discovery tool. Queries the OpenCode SDK to list all available providers, models, capability badges, connected status, and defaults. |
|
|
69
69
|
|
|
70
70
|
### Mini-Loop Model Inheritance
|
|
71
71
|
|
|
@@ -150,6 +150,14 @@ Feedback: Fix type errors in handler.ts
|
|
|
150
150
|
|
|
151
151
|
Final reports use `# Pipeline: Complete` or `# Mini-Loop: Complete` headers containing the full markdown report. Errors use `# Pipeline: Error` or `# Mini-Loop: Error`.
|
|
152
152
|
|
|
153
|
+
## Run Isolation
|
|
154
|
+
|
|
155
|
+
- Every `ff_pipeline` / `ff_mini_loop` invocation now creates a dedicated run parent session under the caller session.
|
|
156
|
+
- All workflow child prompts and progress notifications are routed through that run parent session to keep caller context slim.
|
|
157
|
+
- When `worktree_isolation: true`, the workflow runs in a dedicated detached git worktree directory.
|
|
158
|
+
- Detached worktrees are cleaned up automatically after the background run finishes, exits early, or fails.
|
|
159
|
+
- CI checks (`ff-ci.sh`) run against the resolved run directory (worktree when enabled, current directory otherwise).
|
|
160
|
+
|
|
153
161
|
## Related Docs
|
|
154
162
|
|
|
155
163
|
- `docs/PIPELINE_ORCHESTRATION.md`
|
|
@@ -32,6 +32,7 @@ Work through this process step by step. Do NOT skip steps or launch a tool until
|
|
|
32
32
|
## Semantic Code Search
|
|
33
33
|
|
|
34
34
|
Use `cocoindex-code_search` to quickly understand the codebase when clarifying requirements:
|
|
35
|
+
|
|
35
36
|
- Search by meaning (e.g., "user authentication flow", "API rate limiting") to understand existing architecture
|
|
36
37
|
- Use this to give informed answers when the user asks about current behavior
|
|
37
38
|
|
|
@@ -40,6 +41,7 @@ Use `cocoindex-code_search` to quickly understand the codebase when clarifying r
|
|
|
40
41
|
## Step 1: Understand the request
|
|
41
42
|
|
|
42
43
|
Work through the user's request in a Socratic manner:
|
|
44
|
+
|
|
43
45
|
- Ask clarifying questions about scope, constraints, and acceptance criteria.
|
|
44
46
|
- Summarise your understanding back to them and ask them to confirm or correct it.
|
|
45
47
|
- 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
|
|
|
53
55
|
Once requirements are agreed, present the two workflow options:
|
|
54
56
|
|
|
55
57
|
**Pipeline** (full multi-model workflow)
|
|
58
|
+
|
|
56
59
|
- Multi-model fan-out planning (3 models propose plans, then consensus synthesis)
|
|
57
60
|
- Build phase with task breakdown and batch validation
|
|
58
61
|
- Multi-model fan-out code review
|
|
@@ -60,6 +63,7 @@ Once requirements are agreed, present the two workflow options:
|
|
|
60
63
|
- Best for: complex features, architectural changes, high-risk work
|
|
61
64
|
|
|
62
65
|
**Mini-loop** (lightweight workflow)
|
|
66
|
+
|
|
63
67
|
- Direct build → review loop (single model per step)
|
|
64
68
|
- Documentation with review loop
|
|
65
69
|
- 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
|
|
|
73
77
|
Present the default models that will be used for the chosen workflow:
|
|
74
78
|
|
|
75
79
|
**Pipeline defaults:** (hardcoded per-role model assignments)
|
|
80
|
+
|
|
76
81
|
- Planning fan-out: opus (anthropic/claude-opus-4-6), gemini (opencode/gemini-3.1-pro), codex (openai/gpt-5.3-codex)
|
|
77
82
|
- Review fan-out: same as planning
|
|
78
83
|
- Orchestrator (synthesis/triage): openai/gpt-5.4
|
|
@@ -82,6 +87,7 @@ Present the default models that will be used for the chosen workflow:
|
|
|
82
87
|
- Doc review: opencode/gemini-3.1-pro
|
|
83
88
|
|
|
84
89
|
**Mini-loop defaults:** (inherits the current session model)
|
|
90
|
+
|
|
85
91
|
- All roles (build, review, documentation, doc review) default to the **current session model** — no hardcoded model is forced.
|
|
86
92
|
- This means the mini-loop automatically uses whatever model you're currently chatting with.
|
|
87
93
|
- 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
|
|
|
92
98
|
|
|
93
99
|
If they want to override, collect the provider/model strings for each role they want to change.
|
|
94
100
|
|
|
101
|
+
Before moving to launch, also confirm execution isolation:
|
|
102
|
+
|
|
103
|
+
- Ask whether they want **worktree isolation** enabled.
|
|
104
|
+
- Explain: when enabled, the workflow runs in a dedicated detached git worktree directory to avoid collisions with other concurrent runs.
|
|
105
|
+
- If enabled, optionally collect a custom `worktree_parent_dir`; otherwise default behavior is used.
|
|
106
|
+
|
|
95
107
|
---
|
|
96
108
|
|
|
97
109
|
## Step 4: Launch
|
|
98
110
|
|
|
99
111
|
Once all three steps are confirmed, call the appropriate tool:
|
|
100
112
|
|
|
101
|
-
- If they chose **Pipeline**: call the `ff_pipeline` tool with the agreed requirements
|
|
102
|
-
- If they chose **Mini-loop**: call the `ff_mini_loop` tool with the agreed requirements
|
|
113
|
+
- If they chose **Pipeline**: call the `ff_pipeline` tool with the agreed requirements, any model overrides, and worktree options when requested.
|
|
114
|
+
- If they chose **Mini-loop**: call the `ff_mini_loop` tool with the agreed requirements, any model overrides, and worktree options when requested.
|
|
103
115
|
|
|
104
|
-
Pass only
|
|
116
|
+
Pass only model parameters that were explicitly overridden, and include worktree parameters only when explicitly requested.
|
|
@@ -17,6 +17,8 @@ export declare function createMiniLoopTool(client: Client): {
|
|
|
17
17
|
review_model: import("zod").ZodOptional<import("zod").ZodString>;
|
|
18
18
|
doc_model: import("zod").ZodOptional<import("zod").ZodString>;
|
|
19
19
|
doc_review_model: import("zod").ZodOptional<import("zod").ZodString>;
|
|
20
|
+
worktree_isolation: import("zod").ZodOptional<import("zod").ZodBoolean>;
|
|
21
|
+
worktree_parent_dir: import("zod").ZodOptional<import("zod").ZodString>;
|
|
20
22
|
};
|
|
21
23
|
execute(args: {
|
|
22
24
|
requirements: string;
|
|
@@ -24,5 +26,7 @@ export declare function createMiniLoopTool(client: Client): {
|
|
|
24
26
|
review_model?: string | undefined;
|
|
25
27
|
doc_model?: string | undefined;
|
|
26
28
|
doc_review_model?: string | undefined;
|
|
29
|
+
worktree_isolation?: boolean | undefined;
|
|
30
|
+
worktree_parent_dir?: string | undefined;
|
|
27
31
|
}, context: import("@opencode-ai/plugin/tool").ToolContext): Promise<string>;
|
|
28
32
|
};
|