@syntesseraai/opencode-feature-factory 0.12.0 → 0.12.2

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. Confirm scope in 1-3 bullets; that scope confirmation counts as implementation approval.
 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 confirmation checkpoint; confirmed scope is the implementation approval.
 3. Build.
 4. Document.
 5. Review implementation + documentation gates.
@@ -76,6 +76,8 @@ 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`, or when an interactive planning loop reaches confirmed scope, the orchestrator uses the scoped summary as the only required implementation approval. It must not ask a second implementation-confirmation question or add a separate “starting now” notice before Build.
+
 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.
@@ -95,9 +97,10 @@ The plugin includes an auto-handoff hook that continues deterministic next steps
 - The orchestrator (`@feature-factory`) remains the source of truth for workflow progression.
 - Auto-handoff is a continuation safety net, not a replacement for orchestrator logic.
 - On `session.idle`, the hook queries `client.session.messages({ path: { id: sessionId } })`, scans messages in reverse order, and parses only the latest assistant message.
-- The hook extracts the next prompt only from these exact machine-readable formats:
+- The hook extracts the next prompt only from these machine-readable formats (outer quotes are optional, may be single or double quotes, and are stripped when present):
   - `RECOMMENDED_NEXT_STEP: "<human-readable next step>"`
   - `RECOMMENDED_NEXT_STEP="<human-readable next step>"`
+  - `RECOMMENDED_NEXT_STEP='<human-readable next step>'`
 
 - If the latest assistant message does not include one of those formats, the hook does nothing.
 - The hook does not buffer streaming assistant chunks and does not enforce a fixed per-session handoff cap.

package/agents/feature-factory.md

@@ -93,8 +93,9 @@ 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.
+3. Treat that confirmed scope summary as implementation authorization; do not ask for a second implementation-confirmation 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 +104,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. Confirm scope with the user in 1-3 bullets; that scope confirmation counts as implementation approval.
 3. Build.
 4. Document.
 5. Review (implementation and documentation gates).
@@ -179,11 +180,13 @@ 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 confirmation 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, summarize confirmed scope in 1-3 bullets.
+- Treat the user's scope confirmation as implementation approval.
+- Do not ask a second implementation-confirmation 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 confirmed scope.
 
 ### Execution/review loop (max 10 iterations)
 
@@ -202,17 +205,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 confirmation 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 confirmation checkpoint, successful Build always proceeds to Document.
+- After the required scope confirmation 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 confirmation, emit `RECOMMENDED_NEXT_STEP` exactly as defined in the Plugin continuation contract below.
 
 ### Direct-execution prohibition
 
@@ -248,9 +251,15 @@ or
 RECOMMENDED_NEXT_STEP="<human-readable next step>"
 ```
 
+or
+
+```text
+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 confirmation 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/dist/auto-handoff.js

@@ -1,6 +1,5 @@
 const SERVICE_NAME = 'feature-factory';
-const RECOMMENDED_NEXT_STEP_COLON_RE = /^\s*RECOMMENDED_NEXT_STEP\s*:.*"([^"\r\n]+)".*$/im;
-const RECOMMENDED_NEXT_STEP_EQUALS_RE = /^\s*RECOMMENDED_NEXT_STEP\s*=.*"([^"\r\n]+)".*$/im;
+const RECOMMENDED_NEXT_STEP_RE = /^\s*RECOMMENDED_NEXT_STEP\s*[:=](.*)$/i;
 async function log(client, level, message, extra) {
     try {
         await client.app.log({
@@ -36,13 +35,18 @@ function extractMessageText(message) {
 }
 export function parseRecommendedNextStep(text) {
     const normalizedText = text.replace(/\r\n/g, '\n');
-    const colonMatch = normalizedText.match(RECOMMENDED_NEXT_STEP_COLON_RE);
-    if (colonMatch?.[1]) {
-        return colonMatch[1].trim() || null;
-    }
-    const equalsMatch = normalizedText.match(RECOMMENDED_NEXT_STEP_EQUALS_RE);
-    if (equalsMatch?.[1]) {
-        return equalsMatch[1].trim() || null;
+    for (const line of normalizedText.split('\n')) {
+        const match = line.match(RECOMMENDED_NEXT_STEP_RE);
+        if (!match) {
+            continue;
+        }
+        const rawValue = match[1]?.trim() ?? '';
+        const unquotedValue = rawValue.length >= 2 &&
+            ((rawValue.startsWith('"') && rawValue.endsWith('"')) ||
+                (rawValue.startsWith("'") && rawValue.endsWith("'")))
+            ? rawValue.slice(1, -1).trim()
+            : rawValue;
+        return unquotedValue || null;
     }
     return null;
 }

package/package.json

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