feature-factory 0.9.0 → 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/backend-builder.md

@@ -45,6 +45,16 @@ introducing a shape the repo does not use.
 
 ## Verify before reporting
 
+Before expanding a class-wide behavioral test matrix, run one representative negative control
+within your slice's owned paths. Change production behavior without changing the tests or preventing
+execution. Confirm the mapped test passes before the mutation, fails on the expected behavioral
+assertion with the mutation, and passes after restoration. A syntax, import, discovery, or unrelated
+failure does not count. Restore the mutation before committing or reporting.
+In your narrative report, name the inventory row, production symbol and mutation, exact test command,
+observed assertion failure, and restoration result. Mark an unperformed control as **not run** with
+the reason; never infer a result. This is diagnostic instruction, not a new claim-schema field or a
+replacement for the ratified test run.
+
 From the worktree, compile and run the narrowest relevant tests:
 Use the repo's own build and test commands, scoped as narrowly as they allow — a compile or
 type-check step, then the specific test class or file you touched, not the full suite. If the

package/agents/frontend-builder.md

@@ -48,6 +48,16 @@ and the repo's agent instructions (`AGENTS.md` or `CLAUDE.md`) name the concrete
 
 ## Verify before reporting
 
+Before expanding a class-wide behavioral test matrix, run one representative negative control
+within your slice's owned paths. Change production behavior without changing the tests or preventing
+execution. Confirm the mapped test passes before the mutation, fails on the expected behavioral
+assertion with the mutation, and passes after restoration. A syntax, import, discovery, or unrelated
+failure does not count. Restore the mutation before committing or reporting.
+In your narrative report, name the inventory row, production symbol and mutation, exact test command,
+observed assertion failure, and restoration result. Mark an unperformed control as **not run** with
+the reason; never infer a result. This is diagnostic instruction, not a new claim-schema field or a
+replacement for the ratified test run.
+
 A fresh worktree may share the main repo's installed dependencies via a link the orchestrator created. If they are missing, run the repo's install command via `bash -c "cd $WT && <install"` once before building.
 
 Use the repo's own build or type-check command, run inside `$WT`.

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

@@ -62,6 +62,16 @@ producer for anything it could supply.
 
 When the subject is a **class-wide** requirement — one that **cannot be established by a bounded witness**, so proving it means checking every in-scope member and the set has to be enumerated first. `all`/`every`/`centralize`/`across` and a whole vulnerability or behavior class are the obvious markers, but the words are instances and not the test: an absence ("no module constructs the runtime"), a preserved property ("behaviour remains unchanged") and a global capability ("the installed artifact works") each require checking every member without using any of them, and the rules below are what make such a claim reviewable at all. An existential claim is the opposite and must **not** be treated as class-wide: "a module constructs the runtime" or "the daemon accepts a connection" is settled by one witness, so demanding an exhaustive inventory for it is over-rejection:
 - The spec must carry a finite source→sink inventory with a per-call-site policy, explicit compatibility/exclusion decisions, and mapped tests. A class-wide spec lacking any of these is a **BLOCKER** — reject it as missing targeted research rather than letting an open-ended "apply everywhere" reach builders.
+  For a class-wide behavioral criterion, each inventory row must map to an executable test that
+  invokes the relevant production boundary and asserts its required effect or exclusion. The spec
+  must name that test approach; build review checks its implementation. Shared parameterized tests
+  are valid; separate tests per member are not required.
+  AST references and test names prove enumeration, not behavior.
+- Treat the builder's negative-control report as self-reported diagnostic information,
+  not independent evidence or proof of coverage for every inventory row. Check whether the named
+  mutation tests behavior and the reported failure is the expected behavioral assertion, not a
+  syntax, import, discovery, or unrelated failure. Missing attestation alone is not a blocker;
+  inadequate behavioral coverage is. Do not approve on the attestation alone.
 - On the first review of a class-wide **spec**, enumerate in one pass **every dimension of under-specification** — not just each same-class instance and call site, but every unresolved contract, policy, migration/grant, auth-gating, state, and test seam — and consolidate them all into one `required_fixes` list. A category surfaced in a later round that was discoverable in the first review is a first-pass miss to record once in `required_fixes` and carry forward until observed fixed — it stays blocking (see the precedence rule below), but do not spawn a duplicate finding or a fresh rejection cycle for it.
 - When you reject a class-wide build, make `required_fixes` **exhaustive for the class** as of the current evidence: consolidate every discoverable in-scope same-class instance and affected call site into this review. Do not cite one example while withholding equivalent findings for a later round — drip-feeding one sink per round (each fix triggering the next rejection) is exactly the churn this rule prevents.
 - **Acceptance bar (do not over-reject):** approve a class-wide spec once its inventory is finite, every in-scope sink carries a decided policy, and every row maps to a test — even if some contracts could be specified in more depth. A deferral or exclusion is legitimate **only when the approved story or scope authorizes it**; never waive, defer, or leave undecided an in-scope sink that falls under an `all`/`every`/`across` criterion. A **bounded residual** may be left to build-time remediation only when it is mechanical implementation detail whose behavior, compatibility, security, auth-gating, migration, and state policy are already decided in the brief — an unresolved behavioral or design decision is not a residual and must be decided before approval, never shipped to builders as an open choice. Reject only for a genuinely missing sink, policy, compatibility decision, or test, not for achievable-but-absent depth.
@@ -91,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.0",
+  "version": "0.9.2",
   "description": "Durable, observed control plane for /feature runs. Host-agnostic: no opencode dependency.",
   "type": "module",
   "license": "MIT",