unitbob 0.7.7 → 0.7.12

package/dist/wire.js

@@ -7,11 +7,17 @@ import { proxyHint } from "./proxyHint.js";
 // that reads an absence as a verdict either invents a rejection or invents an
 // approval. `validate-build` is the caller that needs the difference: with no
 // server it succeeds, and says out loud which questions went unasked.
+//
+// `status` is the HTTP status the server answered with, when there was one:
+// for the one caller that treats a 404 — a server older than the route — as
+// an absence rather than a verdict (`map-prepare`, spec 52-4).
 export class WireError extends Error {
     unreachable;
+    status;
     constructor(message, options = {}) {
         super(message);
         this.unreachable = options.unreachable ?? false;
+        this.status = options.status ?? null;
     }
 }
 // POST /repos/register — the linking bootstrap (spec 28). A standalone function
@@ -102,15 +108,19 @@ export class Wire {
         return body.results;
     }
     // GET /repos/:id/suites — both current suites (spec 32), exactly two peer
-    // items. A `ready` item carries its blob; a `not_built` item is skipped.
-    async getSuites() {
+    // items, and since spec 52-3 the checks of every red feature beside them. A
+    // `ready` item carries its blob; a `not_built` item is skipped.
+    async getSuiteIndex() {
         const res = await this.send('GET', this.repoPath('suites'));
         await this.ensureOk(res, `GET ${this.repoPath('suites')}`);
         const body = (await res.json());
         if (!Array.isArray(body.suites)) {
             throw new WireError(`GET ${this.repoPath('suites')} returned no suites array.`);
         }
-        return body.suites;
+        return {
+            suites: body.suites,
+            feature_suites: Array.isArray(body.feature_suites) ? body.feature_suites : [],
+        };
     }
     // POST /repos/:id/runs/batch — ship each branch's raw report (or suite error)
     // in one batch; the server parses each against the exact stored version and
@@ -158,6 +168,69 @@ export class Wire {
         await this.ensureOk(res, `GET ${url}`);
         return (await res.json());
     }
+    // POST /repos/:id/features — record a feature (spec 52-1). A 409 (no current
+    // map) and a 422 (an id not on the map, with both sides named in the body)
+    // surface as a WireError carrying the server's text, so the host reads what
+    // the map knows and corrects its file.
+    async postFeature(payload) {
+        const res = await this.send('POST', this.repoPath('features'), payload);
+        if (res.status === 422)
+            throw new WireError(await unknownCapabilitiesRefusal(res));
+        await this.ensureOk(res, `POST ${this.repoPath('features')}`);
+        return (await res.json());
+    }
+    // GET /repos/:id/features — every feature of the project, newest first, and
+    // the server's words for an empty list (spec 52-2, AC 1.2).
+    async listFeatures() {
+        const res = await this.send('GET', this.repoPath('features'));
+        await this.ensureOk(res, `GET ${this.repoPath('features')}`);
+        return (await res.json());
+    }
+    // GET /repos/:id/features/:feature_id/knowledge_packet (spec 52-2, AC 1.3).
+    async getKnowledgePacket(featureId) {
+        const path = this.repoPath(`features/${encodeURIComponent(String(featureId))}/knowledge_packet`);
+        const res = await this.send('GET', path);
+        await this.ensureOk(res, `GET ${path}`);
+        return (await res.json());
+    }
+    // PUT /repos/:id/features/:feature_id/knowledge (spec 52-2, AC 1.4). The
+    // server checks the file's shape; a 422 carries `problems`, and they are
+    // relaid whole, one line per problem with both sides — the host fixes the
+    // file from those lines, and cutting them at 500 characters would hide the
+    // ones at the end.
+    async putKnowledge(featureId, knowledge) {
+        const path = this.repoPath(`features/${encodeURIComponent(String(featureId))}/knowledge`);
+        const res = await this.send('PUT', path, { knowledge });
+        if (res.status === 422)
+            throw new WireError(await problemsRefusal(res, 'PUT knowledge failed: 422'));
+        await this.ensureOk(res, `PUT ${path}`);
+        return (await res.json());
+    }
+    // GET /repos/:id/features/:feature_id/tests_packet (spec 52-3, AC 2.1). A
+    // 409 is the server's own sentence (talk the feature through first) and is
+    // relaid as it is.
+    async getTestsPacket(featureId) {
+        const path = this.repoPath(`features/${encodeURIComponent(String(featureId))}/tests_packet`);
+        const res = await this.send('GET', path);
+        if (res.status === 409)
+            throw new WireError(await wordedRefusal(res, `GET tests_packet failed: 409`));
+        await this.ensureOk(res, `GET ${path}`);
+        return (await res.json());
+    }
+    // PUT /repos/:id/features/:feature_id/suite (spec 52-3, AC 2.2). Every
+    // refusal is worded by the server: a 409 in one sentence, a 422 in one
+    // sentence or, for a broken seal, with one problem per difference — relaid
+    // whole, both sides per line, like the knowledge file's.
+    async putFeatureSuite(featureId, upload) {
+        const path = this.repoPath(`features/${encodeURIComponent(String(featureId))}/suite`);
+        const res = await this.send('PUT', path, upload);
+        if (res.status === 409)
+            throw new WireError(await wordedRefusal(res, 'PUT suite failed: 409'));
+        if (res.status === 422)
+            throw new WireError(await problemsRefusal(res, 'PUT suite failed: 422'));
+        await this.ensureOk(res, `PUT ${path}`);
+        return (await res.json());
+    }
     // GET /recipes/:name — fetch a recipe at call time. Recipes live on Rails so
     // the connector and Skill carry no recipe text (spec 15, acceptance criteria).
     async getRecipe(name) {
@@ -244,7 +317,7 @@ export class Wire {
         if (res.status === 404) {
             throw new WireError(`This project is linked to a repository the server at ${this.config.server} does not have, ` +
                 'or the token in .unitbob.json does not open it. Delete .unitbob.json to link again ' +
-                '(the old project, along with its map and checks, stays where it is).');
+                '(the old project, along with its map and checks, stays where it is).', { status: 404 });
         }
         let detail = '';
         try {
@@ -253,8 +326,55 @@ export class Wire {
         catch {
             // ignore — the status alone is actionable enough
         }
-        throw new WireError(statusRefusal(what, res, detail, this.config.server));
+        throw new WireError(statusRefusal(what, res, detail, this.config.server), { status: res.status });
+    }
+}
+// The 422 of POST /features carries two lists, and the host corrects its file by
+// reading both (spec 52-1, AC 1.3). `ensureOk` keeps 500 characters of a body,
+// which is a line of context for every other refusal and, on a map of twenty
+// capabilities or more, cuts `known_ids` in half — the list the correction is
+// made from, on exactly the projects that have the most ids to get wrong. So
+// the two lists are relaid whole, one per line; any other 422 body keeps the
+// ordinary shape.
+async function unknownCapabilitiesRefusal(res) {
+    const { text, body } = await readBody(res);
+    if (!Array.isArray(body.unknown_ids) || !Array.isArray(body.known_ids)) {
+        return `POST features failed: 422 — ${text.slice(0, 500)}`;
+    }
+    return (`POST features failed: 422 — ${String(body.error ?? 'These capabilities are not on the current map.')}\n` +
+        `unknown_ids: ${JSON.stringify(body.unknown_ids)}\n` +
+        `known_ids: ${JSON.stringify(body.known_ids)}`);
+}
+// A refusal the server worded in one sentence: that sentence, whole.
+async function wordedRefusal(res, prefix) {
+    const { text, body } = await readBody(res);
+    return `${prefix} — ${typeof body.error === 'string' ? body.error : text.slice(0, 500)}`;
+}
+// A refusal that may carry `problems` — the knowledge file's shape (spec 52-2,
+// AC 5.3) or a broken seal (spec 52-3): the sentence, then one problem per line
+// with both sides, relaid whole because the host fixes the file from all of
+// them; without problems, the sentence.
+async function problemsRefusal(res, prefix) {
+    const { text, body } = await readBody(res);
+    const head = `${prefix} — ${typeof body.error === 'string' ? body.error : text.slice(0, 500)}`;
+    if (!Array.isArray(body.problems))
+        return head;
+    const lines = body.problems.map((problem) => `expected: ${String(problem.expected)}\n     got: ${String(problem.got)}`);
+    return [head, ...lines].join('\n');
+}
+// A refusal body as text and, when it is JSON, as an object; when it is not,
+// the text itself is the detail.
+async function readBody(res) {
+    let text = '';
+    let body = {};
+    try {
+        text = await res.text();
+        body = JSON.parse(text);
+    }
+    catch {
+        // not JSON — the text itself is the detail
     }
+    return { text, body };
 }
 // The two statuses that prove somebody else answered.
 //

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "unitbob",
-  "version": "0.7.7",
+  "version": "0.7.12",
   "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.12 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,
@@ -140,6 +160,24 @@ genuinely holds a promise and holds less of it than its name suggests. Nothing
 mechanical can tell those two apart; what makes the difference is that your
 sentence is specific enough to act on.
 
+## A feature's checks
+
+The same review, for a smaller candidate: the checks of one feature being
+built (spec 52-4). Then the request is
+`.unitbob/features/<id>/tests-review-request.json`, with the same keys as the
+main suite's plus two — `knowledge_path` and `scenarios` — and the review goes
+to the `output_path` it names, in the same form: `candidate_digest` at the top
+level, `bdd_quality_review` with one entry per Scenario by `case_marker` and
+name. There is no `known_defect_probe` and no `selection_review` here; write
+neither.
+
+When the request carries `knowledge_path`, the promise each Scenario protects
+is written in that `knowledge.md`, in its `Scenarios` section — read it there,
+not from the capability description, which for a feature is one line. The
+Scenario text is the user's and sealed; the steps behind it are what you
+judge, exactly as above. Do not read the feature's implementation: whether the
+code is right is the run's question, and the run was made by the connector.
+
 ## What is not yours
 
 **Do not edit the suite.** Not the `.feature` files, not the step definitions,
@@ -152,7 +190,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