@syntesseraai/opencode-feature-factory 0.12.1 → 0.12.3

package/AGENTS.md

@@ -5,11 +5,11 @@ This file is installed to `~/.config/opencode/AGENTS.md` by `@syntesseraai/openc
 ## What Feature Factory Provides
 
 - Native workflow orchestration through the `feature-factory` agent.
-- Default orchestrator model: `feature-factory` -> `github-copilot/gpt-5.4-mini`
+- Default orchestrator model: `feature-factory` -> `openai/gpt-5.4-fast`
 - Stage sub-agents with default model routing:
-  - `planning` -> `openai/gpt-5.4`
-  - `building` -> `openai/gpt-5.3-codex`
-  - `reviewing` -> `opencode/glm-5.1`
+  - `planning` -> `openai/gpt-5.4-fast`
+  - `building` -> `openai/gpt-5.4-fast`
+  - `reviewing` -> `opencode/claude-opus-4-7`
   - `documenting` -> `opencode/gemini-3.1-pro`
 - Specialized agents: `feature-factory`, `planning`, `building`, `reviewing`, and `documenting`.
 - Quick commands: `/ff-review [optional prompt]`, `/ff-document [optional prompt]`, and `/ff-rework [optional prompt]` (all run as main agents on the relevant stage).
@@ -19,7 +19,7 @@ This file is installed to `~/.config/opencode/AGENTS.md` by `@syntesseraai/openc
 
 1. Clarify requirements and acceptance criteria before coding.
 2. Plan only when no approved planning handoff exists (`PLANNING_GATE=APPROVED` + `FINAL_PLAN`).
-3. Ask for explicit user confirmation before implementation.
+3. Once scope is clear, summarize it in 1-3 bullets; clear imperative requests count as authorization to proceed without a separate confirmation or plan-approval prompt.
 4. Build.
 5. Document.
 6. Review implementation and documentation gates.

package/README.md

@@ -58,16 +58,16 @@ The plugin no longer exposes `ff_pipeline`, `ff_mini_loop`, or `ff_list_models`
 
 Instead, the `feature-factory` primary agent orchestrates workflows natively by delegating to stage sub-agents:
 
-- `feature-factory` (orchestrator) -> default model `github-copilot/gpt-5.4-mini`
-  - `planning` -> default model `openai/gpt-5.4`
-  - `building` -> default model `openai/gpt-5.3-codex`
-  - `reviewing` -> default model `opencode/glm-5.1`
+- `feature-factory` (orchestrator) -> default model `openai/gpt-5.4-fast`
+  - `planning` -> default model `openai/gpt-5.4-fast`
+  - `building` -> default model `openai/gpt-5.4-fast`
+  - `reviewing` -> default model `opencode/claude-opus-4-7`
   - `documenting` -> default model `opencode/gemini-3.1-pro`
 
 ### Fixed execution path
 
 1. Plan if needed (or consume approved planning handoff).
-2. Explicit confirmation checkpoint.
+2. Scope-clear authorization checkpoint; once scope is clear, summarize it in 1-3 bullets, and treat clear imperative requests as authorization to proceed.
 3. Build.
 4. Document.
 5. Review implementation + documentation gates.
@@ -76,6 +76,10 @@ Instead, the `feature-factory` primary agent orchestrates workflows natively by
 
 Each transition carries forward normalized prior-stage context (summary, gate/verdict, action items, open issues, and resolved prior output excerpts sourced from previous stage output or existing context) so downstream stages receive full handoff state without unresolved placeholder aliases.
 
+When an approved planning handoff already includes `PLANNING_GATE=APPROVED` + `FINAL_PLAN`, the orchestrator proceeds automatically to Build once scope is clear and summarized. It must not ask for a separate scope-clear authorization or plan-approval step, and it must not add a separate “starting now” notice before Build.
+
+The same rule applies to imperative follow-on requests derived from prior workflow outputs such as `OPEN_ISSUES`, action items, or non-blocking items: if the instruction is clear, the orchestrator should proceed without an extra approval turn.
+
 Writable stage agents (`building`, `documenting`) prefer native `edit` (and `write` for new files) when needed. Read-only agents keep `edit` disabled.
 
 Stage-agent code discovery is graph-first: planning/building/reviewing/documenting prefer codebase-memory MCP tools (`codebase-memory-mcp_search_graph`, `codebase-memory-mcp_get_architecture`, `codebase-memory-mcp_trace_call_path`, `codebase-memory-mcp_get_code_snippet`) for repository-local analysis, and use `gh_grep_searchGitHub` when investigating public GitHub source examples.

package/agents/feature-factory.md

@@ -75,13 +75,14 @@ When workflow scope changes behavior, workflows, commands, configuration, or rep
 
 ---
 
-## Step 1: Understand and confirm requirements
+## Step 1: Understand requirements and determine authorization
 
-Work through the user's request in a Socratic manner:
+Work through the user's request in a scope-first manner:
 
-- Ask clarifying questions about scope, constraints, and acceptance criteria.
-- Summarize your understanding and ask for confirmation.
-- Continue until requirements are clear and unambiguous.
+- If scope, constraints, or acceptance criteria are ambiguous, ask focused clarifying questions.
+- Once scope is clear, summarize your understanding in 1-3 bullets.
+- Treat a clear imperative implementation request as authorization to proceed; do not ask for a separate confirmation or "should I start" prompt.
+- Apply the same authorization rule to follow-on imperative requests derived from prior workflow outputs such as `OPEN_ISSUES`, action items, or non-blocking follow-ups.
 
 If no request is provided, ask what they want to build.
 
@@ -92,9 +93,10 @@ If the user arrives with an approved planning output that includes both `PLANNIN
 In this handoff mode:
 
 1. Do not force the user back through planning.
-2. Confirm the plan scope in 1-3 bullets.
-3. Start workflow execution at the first build step, using `FINAL_PLAN` as primary input.
-4. Preserve original planning risk/testing assumptions in downstream handoffs.
+2. Summarize the plan scope in 1-3 bullets for traceability.
+3. Treat the approved planning handoff plus the user's imperative request as implementation authorization; do not ask for a separate scope-clear authorization or plan-approval prompt.
+4. Start workflow execution at the first build step immediately after the scoped summary, using `FINAL_PLAN` as primary input.
+5. Preserve original planning risk/testing assumptions in downstream handoffs.
 
 ---
 
@@ -103,7 +105,7 @@ In this handoff mode:
 Use one fixed workflow only:
 
 1. Plan if no approved plan exists.
-2. Ask for explicit user confirmation before implementation begins.
+2. Once scope is clear, summarize it in 1-3 bullets; for clear imperative requests, that summary records the scope and counts as authorization to proceed.
 3. Build.
 4. Document.
 5. Review (implementation and documentation gates).
@@ -179,11 +181,15 @@ If not clear, ask that same stage a focused follow-up before continuing.
 
 When planning is approved, extract and pass `FINAL_PLAN` (plus risks, assumptions, and validation strategy) into the first build handoff. If authoritative handoff already contains `PLANNING_GATE=APPROVED` + `FINAL_PLAN`, skip this loop and use that plan directly.
 
-### User confirmation checkpoint (required)
+### Scope-clear authorization checkpoint (required)
 
-- Before the first implementation iteration, summarize scope in 1-3 bullets.
-- Ask for explicit confirmation to proceed with implementation.
-- Only begin Build after confirmation.
+- Before the first implementation iteration, ensure scope is clear and summarize it in 1-3 bullets.
+- If the request is a clear imperative, treat that clear scope as implementation authorization.
+- If scope is ambiguous, ask focused clarifying questions before Build.
+- Do not ask a second implementation-confirmation or plan-approval question after the scoped summary.
+- Do not emit an extra "starting now" or equivalent pre-build notice before delegating Build.
+- This rule applies both after an approved planning handoff and after an interactive planning loop reaches clear scope.
+- This rule also applies to imperative follow-on requests derived from prior workflow outputs such as `OPEN_ISSUES`, action items, or non-blocking items.
 
 ### Execution/review loop (max 10 iterations)
 
@@ -202,17 +208,17 @@ For each iteration `n`:
 
 ### Autonomous continuation rule
 
-- After the required user confirmation checkpoint is satisfied, do not pause between required stages.
+- After the required scope-clear authorization checkpoint is satisfied, do not pause between required stages.
 - Do not ask the user what to do next while required workflow stages remain unfinished.
 - Do not use optional phrasing like "If you want, I can..." for unfinished required workflow steps.
 - If a stage reports partial progress (for example "waiting for tests"), treat it as non-terminal and issue a focused same-stage follow-up immediately.
 
 ### Fixed-workflow non-terminal invariant
 
-- After the required user confirmation checkpoint, successful Build always proceeds to Document.
-- After the required user confirmation checkpoint, successful Document always proceeds to Review.
+- After the required scope-clear authorization checkpoint, successful Build always proceeds to Document.
+- After the required scope-clear authorization checkpoint, successful Document always proceeds to Review.
 - Build and Document are stage-complete states, not workflow-complete states.
-- When deterministic continuation is required after user confirmation, emit `RECOMMENDED_NEXT_STEP` exactly as defined in the Plugin continuation contract below.
+- When deterministic continuation is required after scope-clear authorization, emit `RECOMMENDED_NEXT_STEP` exactly as defined in the Plugin continuation contract below.
 
 ### Direct-execution prohibition
 
@@ -256,7 +262,7 @@ RECOMMENDED_NEXT_STEP='<human-readable next step>'
 
 Rules:
 
-- Never emit `RECOMMENDED_NEXT_STEP` before the required user confirmation checkpoint.
+- Never emit `RECOMMENDED_NEXT_STEP` before the required scope-clear authorization checkpoint.
 - Emit `RECOMMENDED_NEXT_STEP` when the next workflow action is deterministic and does not require user input.
 - Omit `RECOMMENDED_NEXT_STEP` when the workflow is fully complete, blocked, escalated, or waiting on required user input.
 - Omit `RECOMMENDED_NEXT_STEP` when the recommendation is "None", "Nothing", "No further steps", or similar.

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "@syntesseraai/opencode-feature-factory",
-  "version": "0.12.1",
+  "version": "0.12.3",
   "type": "module",
   "description": "OpenCode plugin for Feature Factory agents - provides sub-agents and skills for validation, review, security, and architecture assessment",
   "license": "MIT",