unitbob 0.7.7 → 0.7.8

package/dist/runner/bdd.js

@@ -94,6 +94,8 @@ const BDD_STRATEGIES = {
                     'over nothing.',
                 '`conftest.py` is picked up by pytest itself whatever else sits beside it, so shared fixtures ' +
                     'belong there and there is no load-order trap to work around.',
+                'The project root is on `sys.path`, as it is for the structural branch: `from app import …` ' +
+                    'works in `conftest.py` and in step files, with no `sys.path` insert of your own.',
             ],
         },
     },
@@ -175,13 +177,16 @@ async function runPytestBdd(projectRoot, mainPath) {
     writeFileSync(join(projectRoot, PYTEST_BDD_PLUGIN_FILE), PYTEST_BDD_PLUGIN);
     const command = await pickPython(projectRoot);
     const stepsDir = join(BEHAVIORAL_ROOT, STEP_DEFINITIONS);
-    const isVenvPytest = command.endsWith('/pytest');
+    // `python -m pytest`, as the structural branch runs it: `-m` puts the working
+    // directory — the project root — on `sys.path`, so the shared conftest's
+    // `from app import …` resolves. The `pytest` script does not do that, and on
+    // microblog the conftest died on that import before the first Scenario, with
+    // no report to read (spec 51-1).
+    //
     // `--rootdir .`, not the absolute root: the working directory is the project
     // root in every place, and an absolute host path would name a directory that
     // does not exist wherever the run actually happens.
-    const args = isVenvPytest
-        ? ['-c', PYTEST_INI_FILE, '-p', 'no:cacheprovider', '-p', pluginModule(), stepsDir, '--rootdir', '.']
-        : ['-m', 'pytest', '-c', PYTEST_INI_FILE, '-p', 'no:cacheprovider', '-p', pluginModule(), stepsDir, '--rootdir', '.'];
+    const args = ['-m', 'pytest', '-c', PYTEST_INI_FILE, '-p', 'no:cacheprovider', '-p', pluginModule(), stepsDir, '--rootdir', '.'];
     const survivor = clearReport(join(projectRoot, PYTEST_BDD_REPORT));
     const run = await runInProject(projectRoot, command, args, {
         timeoutMs: BDD_TIMEOUT_MS,
@@ -212,10 +217,14 @@ function finalize(run, projectRoot, reportRel, survivor) {
         report: readFreshReport(join(projectRoot, reportRel), survivor),
     };
 }
+// The sidecar's `pytest` is the sign that suite-prepare installed pytest-bdd
+// there; a venv always has a `python` beside it, and that is what runs. Judging
+// by `python` alone would send an unprovisioned venv into "No module named
+// pytest" instead of the message that names the fix.
 async function pickPython(projectRoot) {
-    const sidecarVenvPytest = `${BEHAVIORAL_ROOT}/.venv/bin/pytest`;
-    if (executable(commandFileOnHost(projectRoot, sidecarVenvPytest))) {
-        return sidecarVenvPytest;
+    const sidecarVenvBin = `${BEHAVIORAL_ROOT}/.venv/bin`;
+    if (executable(commandFileOnHost(projectRoot, `${sidecarVenvBin}/pytest`))) {
+        return `${sidecarVenvBin}/python`;
     }
     throw missingRunner('pytest-bdd');
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "unitbob",
-  "version": "0.7.7",
+  "version": "0.7.8",
   "description": "Unitbob connector — thin local hands for the Unitbob Rails brain. Owns no domain logic: it runs tools, relays bytes over the wire, and prints what the server returns.",
   "type": "module",
   "bin": {

package/plugin/codex/agents/suite-repair-worker.toml

@@ -21,7 +21,7 @@ markers, or paths. Do not edit production code, host-owned shared files, the
 connector-owned harness, or another slice.
 
 After every owned edit, run
-`npx -y --loglevel=error unitbob@0.7.7 run-local <branch>` and inspect the machine
+`npx -y --loglevel=error unitbob@0.7.8 run-local <branch>` and inspect the machine
 report. Look only at examples or scenarios matching your owned paths or case
 markers. Do not require a green exit code from the whole branch: foreign failures
 and an already-confirmed product red do not widen your scope. Repeat the bounded

package/plugin/codex/agents/suite-reviewer.toml

@@ -47,7 +47,10 @@ Write strict JSON, and nothing else, to
   "known_defect_probe": { "status": "not_supplied" },
   "selection_review": {
     "plan_digest": "<exact plan_digest from the request>",
-    "capability_reviews": [{ "capability_id": "billing", "verdict": "pass" }]
+    "capability_reviews": [
+      { "capability_id": "billing", "verdict": "pass" },
+      { "capability_id": "reporting", "verdict": "pass" }
+    ]
   }
 }
 ```
@@ -58,11 +61,19 @@ Nesting it one level deeper cost a run its publish; so did inventing values for
 top-level keys", which dropped it entirely. Copy the digest, do not compute it.
 
 Write `selection_review` only when the request carries a `plan_digest`, and give
-it one entry per assigned capability. Its verdicts are `pass` or
-`does_not_pass` — there is no `pass_with_reservation` at capability level — and
-`does_not_pass` owes a non-empty `reviewer_objection_text` naming the lost
-promise, the unjustified merge, or the dishonest deferral. Selection objections
-are recorded; they never block the publish and never downgrade a lamp.
+it one entry for **every capability in the request's `behavioral_assignment`** —
+the map's whole list, not the `worker_plan`'s. The plan takes a few capabilities
+and leaves the rest for a later build; a capability it left out still gets a
+verdict, about the deferral: `pass` when the candidate's `capabilities` mark it
+`unguarded` with an honest reason, `does_not_pass` when a promise was dropped or
+merged away. In the example above, `billing` was planned and `reporting` was
+deferred, and both are there. On soul, 2026-09-11, the reviewer wrote one entry
+per plan item and the publish was refused for every capability it left out.
+Its verdicts are `pass` or `does_not_pass` — there is no `pass_with_reservation`
+at capability level — and `does_not_pass` owes a non-empty
+`reviewer_objection_text` naming the lost promise, the unjustified merge, or the
+dishonest deferral. Selection objections are recorded; they never block the
+publish and never downgrade a lamp.
 
 Omit `candidate_run`, `known_defect_context` and any runner report: the connector
 owns those and adds them itself.
@@ -100,12 +111,21 @@ and no answer that consists of writing nothing.
 it never excuses a "loads successfully" assertion for a promised record, state
 change, message, or side effect.
 
-`public_surfaces` lists the addresses you verified the `When` implementation
-actually drives, and must equal that Scenario's `surface_coverage` in the
-candidate's metadata. If the two disagree, that is a finding — say it in a
-reservation or an objection rather than adjusting your list to match.
+`public_surfaces` is your check of the worker's claim, not a list of your
+own. Read the steps behind the Scenario and confirm every address in its
+`surface_coverage` is really driven by some step; if every one is, copy that
+list into `public_surfaces` verbatim — the two must be equal, and the server
+refuses a Scenario where they are not. If the manifest names an address **no
+step drives at all**, the verdict is `does_not_pass`, naming the address
+(a2time, 2026-08-17: six Scenarios claimed addresses their steps never
+touched). An address a step drives that the manifest does **not** name never
+goes into the field: a `When` reaching another capability's address goes in
+`reservation` (below); a `Then` re-reading state, a `Given` arriving, an `After`
+leaving go nowhere. A claimed address that a `Then` drives rather than the
+`When` is real — it stays in the list; say which step drove it in `reservation`
+if it matters. On microblog, 2026-09-11, that finding was right and the list
+was shortened to show it, and the publish was refused for the shortened list.
 
-The `When`, and only the `When` — the same rule the worker wrote its list by.
 What a `Given` does to arrive (sign in, create the table the Scenario needs) and
 what an `After` does to leave are not the behaviour under test, so an address
 they touch is not missing from `surface_coverage` and not a finding. On soul,
@@ -152,7 +172,10 @@ shared test database and proves nothing about the candidate that was bound.
 
 **Do not rewrite anybody's verdict, including on a second pass.** If you find
 yourself weighing whether an objection is worth the trouble, the answer is that
-it costs this run nothing at all.
+it costs this run nothing at all. A second pass that arrives with a
+`validate-build` refusal corrects the field it names — `public_surfaces` brought
+back to the manifest, a missing `selection_review` entry added — and leaves
+every verdict as it was.
 
 **Do not widen the review.** Whether a capability deserved more Scenarios is the
 `selection_review` question and is answered per capability; everything else about