feature-factory 0.9.0 → 0.9.1

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/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.

package/package.json

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