feature-factory 0.9.1 → 0.9.2

package/WORKFLOW.md

@@ -1393,9 +1393,14 @@ Per slice:
      $ factory slice "$R" "$SLICE_ID" review --evidence-ref "evidence/$SLICE_ID.json" \
        --review-ref "reviews/$SLICE_ID.json" --repo "$RUN_REPO"
      ```
-   - On REJECT, before spending an attempt, identify the design-level root cause. If the fix would
+   - On REJECT, before spending an attempt, identify the cause of the remaining failures. If the fix would
      violate an approved story or brief constraint, or repeated findings trace to the same unresolved
      design choice, stop and escalate the smallest decision needed rather than burning attempts.
+     When repeated reviews leave substantial acceptance gaps, review prior verified progress and identify
+     a bounded, achievable remediation target for the next attempt, even when the design is fully decided.
+     If no such target can be identified, park through the existing parked-stop procedure for replanning
+     or operator clarification; preserve the work and do not silently change approved acceptance criteria.
+     Unchanged finding counts alone are not a stall: progress can occur within a category that remains open.
      Otherwise route the fixes back to that builder and re-observe. After `max_retries`, mark the slice
      `blocked` and stop dispatching its dependents.
 5. **Merge (you, serially)** — on APPROVE, merge the slice branch into the feature branch one at a

package/agents/story-writer.md

@@ -26,6 +26,14 @@ A feature idea in the engineer's words, plus (optionally) a research map from co
 - Acceptance criteria are **testable**: each one is something test-verifier could later assert. "Works well" is not a criterion; "Auditor sees a disabled Save button until all required fields are filled" is.
 - State what's **out of scope** explicitly — it's the cheapest way to prevent scope creep downstream.
 - Keep it product-level. No file paths, no class names — that's the spec-writer's job.
+- Each acceptance criterion must support the requested outcome or a necessary correctness/safety condition.
+  Label additional capabilities and broad architectural requirements as proposed scope additions,
+  explain why they are needed, and obtain explicit approval at the existing story gate before
+  incorporating them into accepted scope. Do not silently turn implementation preferences into requirements.
+  This is not a criterion-count limit or a reason to omit necessary reliability or safety behavior.
+- Scope correctness and safety criteria to the requested behavior. When addressing known defects,
+  name the failure scenarios to prevent rather than silently generalizing them into a subsystem-wide guarantee.
+  If a broader guarantee is necessary, explain its scope and proof obligations before approval.
 
 ## Output contract
 

package/agents/work-reviewer.md

@@ -101,6 +101,11 @@ When the subject is a **class-wide** requirement — one that **cannot be establ
   catch any of this; the two slices share no path. It is decidable from the plan alone, so check it here
   rather than discovering it at the slice that fails.
 - **Doc steps (`spec-writer`, `work-decomposer`):** every required field of the output contract is filled; the artifact is consistent with its inputs (does the brief cover every AC and match the research map's real paths? does the slice DAG obey file-disjoint + hotspot-serialization rules, and does every AC map to a slice?). For `work-decomposer`, do not approve unless the supplied `plan/slices.json` is a top-level object with array-valued `slices` (the exact seedable shape `{ "slices": [...] }`); inspect only the supplied artifact, not a broader plan schema. Coverage is not enough: where more than one slice exists, a slice claiming the entire acceptance set, or claiming paths spanning every module in its lane, is a BLOCKER — that plan reviews clean and fails later as "N categories missing", which is a scope report rather than a defect report. Apply the same reviewability test to **every** slice with no condition on the plan's size, including the only slice of a one-slice plan: if your own likely rejection of it would say whole categories of required behaviour remain unimplemented, it is too large and the plan is a BLOCKER. **A one-slice plan whose `### Single-slice justification` is absent, or which justifies itself only by the brief presenting one closed inventory, is a BLOCKER** — the justification must name the semantic boundaries considered and why splitting them would create proof-only work, illegal path/test ownership, or inseparable implementation. Do not demand a split from a genuinely small change whose justification does that; the requirement is a stated reason, not a minimum slice count. For class-wide subjects, the brief must include the finite implementation matrix (per §"Class-wide completeness") — a class-wide spec that lacks it is a BLOCKER. Whether each slice can make its own `test_plan` green is the satisfiability bullet's check, stated once there rather than repeated here.
+  Check that criteria and proposed requirements support the requested outcome or necessary correctness/safety.
+  Additional capabilities and broad architectural requirements need an explicit scope rationale and approval;
+  reject unapproved scope expansion rather than silently accepting it as an implementation requirement.
+  Check the supplied request and approval record; do not reopen explicitly approved scope merely because
+  a smaller feature is possible. Do not impose a criterion-count limit or reject necessary reliability behavior.
 - **Build slices (`backend-builder` / `frontend-builder`):** apply the repo's own rubric — its agent instructions (`AGENTS.md` or `CLAUDE.md` and any review or rules files it points at — against the **observed diff**:
   - Backend: the repo's layering, its projection/read path, its API boundary.
   - Frontend: the repo's component conventions, binding forms, state approach and design tokens.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "feature-factory",
-  "version": "0.9.1",
+  "version": "0.9.2",
   "description": "Durable, observed control plane for /feature runs. Host-agnostic: no opencode dependency.",
   "type": "module",
   "license": "MIT",