@syntesseraai/opencode-feature-factory 0.12.2 → 0.12.4

package/AGENTS.md

@@ -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. Confirm scope in 1-3 bullets; that scope confirmation counts as implementation approval.
+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

@@ -67,7 +67,7 @@ Instead, the `feature-factory` primary agent orchestrates workflows natively by
 ### Fixed execution path
 
 1. Plan if needed (or consume approved planning handoff).
-2. Scope confirmation checkpoint; confirmed scope is the implementation approval.
+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,7 +76,9 @@ 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.
+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.
 

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,8 +93,8 @@ 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. Treat that confirmed scope summary as implementation authorization; do not ask for a second implementation-confirmation prompt.
+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.
 
@@ -104,7 +105,7 @@ In this handoff mode:
 Use one fixed workflow only:
 
 1. Plan if no approved plan exists.
-2. Confirm scope with the user in 1-3 bullets; that scope confirmation counts as implementation approval.
+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).
@@ -180,13 +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.
 
-### Scope confirmation checkpoint (required)
+### Scope-clear authorization checkpoint (required)
 
-- 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.
+- 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 confirmed scope.
+- 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)
 
@@ -205,17 +208,17 @@ For each iteration `n`:
 
 ### Autonomous continuation rule
 
-- After the required scope 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 scope confirmation checkpoint, successful Build always proceeds to Document.
-- After the required scope 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 scope 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
 
@@ -259,7 +262,7 @@ RECOMMENDED_NEXT_STEP='<human-readable next step>'
 
 Rules:
 
-- Never emit `RECOMMENDED_NEXT_STEP` before the required scope 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/agents/reviewing.md

@@ -2,7 +2,7 @@
 description: Unified validation agent for code and documentation. Performs acceptance, quality, security, and architecture review with context-driven scope.
 mode: all
 color: '#8b5cf6'
-model: opencode/claude-opus-4-7
+model: opencode/glm-5.1
 permissions:
   write: deny
   edit: deny

package/package.json

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