@nanobpm/nano-workforce 0.171.1 → 0.171.3

package/workers/record-feature-escalation/worker.test.ts

@@ -1,14 +1,15 @@
-// Unit coverage for pr.record-feature-escalation — a feature run parked on the native
-// `feature-escalation` user task (issue #210). Runs on the `escalated` arm, before the user task
-// exists, and must flip the row to the non-terminal `escalated` status and append the agent's
-// `question` to the canonical `feature_escalations` audit log so the nwf UI can surface it (the poller
-// can't read task-local vars, so this is the question's source of truth). Issue #332 dropped the
-// denormalised `feature_runs.escalation_question` / `escalation_user_task_key` columns, so this worker
-// now only flips the status and appends the audit row.
+// Unit coverage for pr.record-feature-escalation — the shared `implement-cell`'s escalation recorder
+// (ADR 0006 S4). It runs on the cell's `escalated` arm for BOTH callers of the cell: a standalone
+// `feature` run (`subjectKey` = its `feature_key`, which HAS a `feature_runs` row to flip to
+// `escalated`) and a plan-fanout wave slice (`subjectKey` = the epic's `plan_key`, which has NO
+// `feature_runs` row — the flip must be a guarded no-op there). In both cases it appends the resolved
+// `question` to the canonical `feature_escalations` audit log (the poller can't read task-local vars,
+// so this is the question's source of truth) and re-emits it, synthesising an answerable one via the
+// #360 no-result net when the agent left none.
 import { test } from "node:test";
-import { assertEquals } from "#test-assert";
+import { assertEquals, assertRejects } from "#test-assert";
 import { noopLog } from "../../test/log.ts";
-import handler from "./worker.ts";
+import handler, { NO_RESULT_QUESTION } from "./worker.ts";
 
 // biome-ignore lint/suspicious/noExplicitAny: tiny in-memory app double, mirrors record-blocked-ack.worker.test
 function fakeApp(rows: Record<string, unknown>[]): any {
@@ -44,14 +45,17 @@ function fakeApp(rows: Record<string, unknown>[]): any {
   };
 }
 
-test("record-feature-escalation: flips the run to escalated and appends the question to the audit log", async () => {
+test("feature subject: flips the run to escalated, appends the agent's question, and re-emits it", async () => {
   const rows = [{ feature_key: "owner/repo#7", status: "running" }];
   const app = fakeApp(rows);
   const out = await handler(
-    { jobKey: "job-1", variables: { featureKey: "owner/repo#7", question: "Which API should I use?" } } as never,
+    {
+      jobKey: "job-1",
+      variables: { subjectKey: "owner/repo#7", status: "escalated", question: "Which API should I use?" },
+    } as never,
     app,
   );
-  assertEquals(out, {});
+  assertEquals(out, { question: "Which API should I use?" });
   assertEquals(rows[0].status, "escalated");
   // Issue #305/#332: the question is the sole responsibility of the canonical `feature_escalations`
   // audit log so `pollUserTasks` can source it from a surviving table (the denormalised column is gone).
@@ -61,25 +65,70 @@ test("record-feature-escalation: flips the run to escalated and appends the ques
   assertEquals(app.stores.feature_escalations[0].job_key, "job-1");
 });
 
-test("record-feature-escalation: a retried job (same jobKey) reuses its audit row, never duplicating", async () => {
+test("wave subject (no feature_runs row): the status flip is a guarded no-op, the audit row is still keyed by planKey", async () => {
+  // A plan-embedded wave slice's `subjectKey` is the epic's `plan_key`; there is NO standalone
+  // `feature_runs` row, so the escalated-status flip must be a no-op (never fabricating a bogus row),
+  // while the question is still appended keyed by the plan for the poller to surface.
+  const app = fakeApp([]);
+  const out = await handler(
+    {
+      jobKey: "job-w",
+      variables: { subjectKey: "owner/repo#1", status: "escalated", question: "Rebase or rework?" },
+    } as never,
+    app,
+  );
+  assertEquals(out, { question: "Rebase or rework?" });
+  assertEquals(app.stores.feature_runs.length, 0, "no feature_runs row is fabricated for a wave subject");
+  assertEquals(app.stores.feature_escalations.length, 1);
+  assertEquals(app.stores.feature_escalations[0].feature_key, "owner/repo#1");
+  assertEquals(app.stores.feature_escalations[0].question, "Rebase or rework?");
+});
+
+test("no-result: a missing status/question synthesises the #360 answerable question and re-emits it", async () => {
+  // The implement stage was the only agent stage with no net for "I couldn't read the agent's result".
+  // A non-clean-terminal slice with no machine-readable status routes onto the SAME escalation task, so
+  // a human can enrol the PR or abandon the slice instead of the epic dying with a blank reason.
+  const rows = [{ feature_key: "owner/repo#8", status: "running" }];
+  const app = fakeApp(rows);
+  const out = await handler({ jobKey: "job-8", variables: { subjectKey: "owner/repo#8" } } as never, app);
+  assertEquals(out, { question: NO_RESULT_QUESTION });
+  assertEquals(rows[0].status, "escalated");
+  assertEquals(app.stores.feature_escalations.length, 1);
+  assertEquals(app.stores.feature_escalations[0].question, NO_RESULT_QUESTION);
+});
+
+test("blank-question escalated: still synthesises the #360 question (never a dead-end task)", async () => {
+  const app = fakeApp([]);
+  const out = await handler(
+    { jobKey: "job-b", variables: { subjectKey: "owner/repo#2", status: "escalated", question: "   " } } as never,
+    app,
+  );
+  assertEquals(out, { question: NO_RESULT_QUESTION });
+  assertEquals(app.stores.feature_escalations[0].question, NO_RESULT_QUESTION);
+});
+
+test("fails fast (incident) when subjectKey is absent — never appends a corrupt undefined-keyed audit row", async () => {
+  // The cell's escalation arm always supplies `subjectKey` (the callActivity input), so a missing key
+  // can only mean the `implement-cell` ioMapping/dataEnvelope regressed. The worker must raise an
+  // incident (throw) rather than keying `feature_escalations`/`feature_runs` with `undefined` and
+  // masking the regression — symmetric with `record-feature-implementing`'s fail-fast guard (#642).
+  const app = fakeApp([]);
+  await assertRejects(() => handler({ jobKey: "job-x", variables: {} } as never, app));
+  assertEquals(app.stores.feature_escalations, undefined, "no audit row is appended when subjectKey is absent");
+});
+
+test("a retried job (same jobKey) reuses its audit row, never duplicating", async () => {
   // `record-feature-escalation` is at-least-once: a job that crashed/timed out AFTER the insert but
   // before job completion re-runs with the SAME jobKey. The `job_key` idempotency guard must reuse the
-  // existing `feature_escalations` row rather than append a duplicate (which would bloat the append-only
-  // log and could skew "latest question" selection). Mirrors `record-plan-review`'s `plan_reviews` guard.
+  // existing `feature_escalations` row rather than append a duplicate (mirrors `record-plan-review`).
   const rows = [{ feature_key: "owner/repo#7", status: "running" }];
   const app = fakeApp(rows);
-  const job = { jobKey: "job-retry", variables: { featureKey: "owner/repo#7", question: "Which API?" } } as never;
+  const job = {
+    jobKey: "job-retry",
+    variables: { subjectKey: "owner/repo#7", status: "escalated", question: "Which API?" },
+  } as never;
   await handler(job, app);
   await handler(job, app); // retry with the same jobKey
   assertEquals(app.stores.feature_escalations.length, 1, "the retry reuses the row, no duplicate append");
   assertEquals(app.stores.feature_escalations[0].job_key, "job-retry");
 });
-
-test("record-feature-escalation: a blank/absent question is appended as NULL (badge/affordance stay off)", async () => {
-  const rows = [{ feature_key: "owner/repo#8", status: "running" }];
-  const app = fakeApp(rows);
-  await handler({ jobKey: "job-8", variables: { featureKey: "owner/repo#8", question: "   " } } as never, app);
-  assertEquals(rows[0].status, "escalated");
-  assertEquals(app.stores.feature_escalations.length, 1);
-  assertEquals(app.stores.feature_escalations[0].question, null);
-});

package/workers/record-feature-escalation/worker.ts

@@ -1,42 +1,89 @@
-// pr.record-feature-escalation — a feature run has parked on the native `feature-escalation`
-// user task (the agent reported `status:"escalated"` with a non-blank `question`). This service
-// task runs on the `escalated` arm, immediately BEFORE the user task is created, and:
-//   • flips `feature_runs.status` to the non-terminal `escalated` so status-based views and counts
-//     flag it (and a re-dispatch of the same issue short-circuits while it is parked), and
-//   • appends the agent's `question` to the append-only `feature_escalations` audit log (issue #305),
-//     the canonical, poller-readable source for a parked run's question.
+// pr.record-feature-escalation — the shared `implement-cell`'s escalation recorder (ADR 0006 S4).
 //
-// The completable `userTaskKey` is NOT recorded here — the task does not exist yet at this point.
-// `pollUserTasks` (app/service.ts) reads the engine's open `feature-escalation` task directly once it
-// is observable and projects it onto the `user_tasks` Tasks inbox, pairing it with the audit log's
-// question. Capturing the question HERE (not in the poller) is required because the WASM testkit
-// engine does not surface a user task's ioMapping-mapped local variables through the user-task query,
-// so the process variable must be persisted while it is still in scope on the job.
+// The atomic `implement-cell` owns its `record-escalation` → `human-escalation` loop, so this one
+// service task runs on the cell's `escalated` arm (`ic_gw` "clean terminal?" → `record-escalation`),
+// immediately BEFORE the shared `human-escalation` cell parks on its user task, for EVERY caller that
+// composes the cell: a standalone `feature` run (`subjectKey` = its `feature_key`) and a plan-fanout
+// wave slice (`subjectKey` = the epic's `plan_key`, which has no standalone `feature_runs` row). It:
+//
+//   • synthesises an answerable `question` when the agent left none (a no-machine-readable result, or a
+//     blank-question `escalated`) via the #360 no-result net, so the parked task is never a dead end,
+//     and re-emits it as the `question` variable so the `feature-escalation` form (and the answer loop)
+//     see it (mirrors record-trial-merge),
+//   • appends that question to the append-only `feature_escalations` audit log keyed by `subjectKey` —
+//     the canonical, poller-readable source `pollUserTasks` reads to enrich the parked task's question
+//     on the Tasks inbox (issue #358), and
+//   • flips the run to the non-terminal `escalated` status so status-based views/counts flag it — but
+//     ONLY when a `feature_runs` row for `subjectKey` exists. A plan-embedded wave has NO such row (the
+//     plan/epic IS the subject), so the flip is a guarded no-op there (it never fabricates a row).
+//
+// The completable `userTaskKey` is NOT recorded here — the task does not exist yet (it lives on the
+// `human-escalation` grandchild instance the cell spawns next). Capturing the question HERE (not in the
+// poller) is required because the WASM engine does not surface a user task's ioMapping-mapped local
+// variables through the user-task query, so the process variable must be persisted while it is still in
+// scope on this job.
 import type { AppJobHandler } from "@nanobpm/urban";
+import { classifyEscalation } from "../../app/escalationTaxonomy.ts";
 import { featureRuns, recordFeatureEscalation } from "../../app/feature.ts";
 import type { WorkerInputs } from "../../nano-generated/worker-io.d.ts";
 
-// Input typed off the model data envelope (`RecordFeatureEscalationIn` in feature.bpmn) — ADR 0040.
+// Input typed off the model data envelope (`RecordEscalationIn` in implement-cell.bpmn) — ADR 0040.
 type In = WorkerInputs["pr.record-feature-escalation"];
+interface Out extends Record<string, unknown> {
+  question: string;
+}
+
+const str = (v: unknown): string | undefined =>
+  typeof v === "string" && v.trim().length > 0 ? v.trim() : undefined;
+
+// The answerable prompt synthesised when the agent left no usable question — the implement-stage
+// analogue of record-trial-merge's synthesised trial-merge question. It names the recoverable work (a
+// PR may exist on the slice's branch) and the two answers the cell's `ic_gw_answer` gateway routes on.
+const NO_RESULT_QUESTION =
+  'The implementation agent finished without a machine-readable result (no status was reported), so we cannot tell whether the slice succeeded. It may still have opened a PR (check for a branch targeting the epic base). Choose "Answer" and give guidance to re-run the slice — or choose "Abandon" to skip it and continue.';
+
+const handler: AppJobHandler<In, Out> = async (job, app) => {
+  const subjectKey = job.variables.subjectKey;
+  // Fail fast rather than keying the `feature_escalations` audit log (and the guarded `feature_runs`
+  // flip) with `undefined`. The cell's `escalated` arm always supplies `subjectKey` (the callActivity
+  // input — a feature run's `feature_key` or a wave slice's `plan_key`), so a missing key can only mean
+  // the `implement-cell` ioMapping/dataEnvelope regressed. Raising an incident surfaces that regression
+  // with a clear trail instead of appending a corrupt `undefined`-keyed audit row and masking it —
+  // symmetric with `record-feature-implementing`'s fail-fast guard (#642).
+  if (!subjectKey) {
+    throw new Error(
+      "record-feature-escalation: subjectKey absent — the implement-cell's escalation-arm ioMapping/dataEnvelope has regressed (would key feature_escalations/feature_runs with undefined)",
+    );
+  }
+  const rawQuestion = str(job.variables.question);
+  // The agent's own question is authoritative when it declared a real escalation with one; otherwise
+  // (a no-machine-readable result, or an escalation with a blank question) synthesise an answerable one
+  // so the parked task is never a dead end. Route through the single canonical taxonomy so this net can
+  // never drift from the tier logic every other raise site uses. A "task"-kind escalation is
+  // `decision-required` only when the agent left an answerable question, so this already covers the
+  // blank-question case; the extra `&& rawQuestion` is the type narrowing that lets us hand the string
+  // through without an assertion.
+  const agentEscalated = classifyEscalation({ kind: "task", status: job.variables.status, question: rawQuestion }) ===
+    "decision-required";
+  const question = agentEscalated && rawQuestion ? rawQuestion : NO_RESULT_QUESTION;
+
+  // Append to the canonical `feature_escalations` audit log (the surviving table `pollUserTasks` reads),
+  // keyed by `subjectKey` — the feature run's `feature_key`, or the epic's `plan_key` for a wave slice.
+  await recordFeatureEscalation(app.data, { featureKey: subjectKey, question, jobKey: job.jobKey });
+
+  // Guarded status flip: a standalone `feature` run has a `feature_runs` row to flip to the non-terminal
+  // `escalated`; a plan-embedded wave (`subjectKey` = `plan_key`) has none, so the flip is a no-op there
+  // rather than fabricating a bogus row (the plan/epic is the subject, tracked in `plans`).
+  const runs = featureRuns(app.data);
+  if (await runs.get(subjectKey)) {
+    await runs.update(subjectKey, { status: "escalated", updated_at: new Date().toISOString() });
+  }
+
+  app.log.info("record-escalation", { subjectKey, synthesised: question === NO_RESULT_QUESTION });
 
-const nonBlank = (v: unknown): string | null =>
-  typeof v === "string" && v.trim().length > 0 ? v.trim() : null;
-
-const handler: AppJobHandler<In> = async (job, app) => {
-  const featureKey = job.variables.featureKey;
-  const question = nonBlank(job.variables.question);
-  await featureRuns(app.data).update(featureKey, {
-    status: "escalated",
-    updated_at: new Date().toISOString(),
-  });
-  // Append the question to the canonical `feature_escalations` audit log (issue #305) — the SURVIVING
-  // table `pollUserTasks` reads to enrich the parked `feature-escalation` task's question on the Tasks
-  // inbox (the feature analogue of `record-plan-review` writing `plan_reviews`). The denormalised
-  // `feature_runs.escalation_question` column it used to dual-write was dropped in the contract phase
-  // (issue #332), so this log is now the sole source of the question text.
-  await recordFeatureEscalation(app.data, { featureKey, question, jobKey: job.jobKey });
-  app.log.info("record-feature-escalation", { featureKey, hasQuestion: question !== null });
-  return {};
+  // Re-emit the resolved question so the `feature-escalation` form (and the answer loop) see it.
+  return { question };
 };
 
 export default handler;
+export { NO_RESULT_QUESTION };

package/workers/record-feature-implementing/worker.test.ts

@@ -4,7 +4,7 @@
 // while parked on the native `feature-escalation` user task. Without it, the answer loop-back left
 // `feature_runs.status` a stale `escalated` through the whole re-implementation (the #632 tear).
 import { test } from "node:test";
-import { assertEquals } from "#test-assert";
+import { assertEquals, assertRejects } from "#test-assert";
 import { noopLog } from "../../test/log.ts";
 import handler from "./worker.ts";
 
@@ -55,3 +55,33 @@ test("record-feature-implementing: a confirming write on the first entry (alread
   assertEquals(rows[0].status, "running");
   assertEquals(rows[0].updated_at !== "2025-01-01T00:00:00.000Z", true, "updated_at was refreshed on the confirming write");
 });
+
+test("record-feature-implementing: keyed by `subjectKey` when composed inside the implement-cell answer loop", async () => {
+  // ADR 0006 S4 — inside the shared `implement-cell` the reset runs on `ic_answerLoop` keyed by
+  // `subjectKey` (the callActivity input), NOT `featureKey`. A standalone feature run's `subjectKey`
+  // IS its `feature_key`, so the escalated row resets to `running` before re-implementation.
+  const rows = [{ feature_key: "owner/repo#7", status: "escalated", updated_at: "2025-01-01T00:00:00.000Z" }];
+  const app = fakeApp(rows);
+  await handler({ jobKey: "job-s", variables: { subjectKey: "owner/repo#7" } } as never, app);
+  assertEquals(rows[0].status, "running");
+});
+
+test("record-feature-implementing: a wave subject (no feature_runs row) is a guarded no-op — never fabricates a row", async () => {
+  // A plan-embedded wave slice composes the same cell with `subjectKey` = the epic's `plan_key`, which
+  // has NO standalone `feature_runs` row. The reset must be a guarded no-op there (symmetric with
+  // `record-feature-escalation`'s guarded flip) rather than creating a bogus row.
+  const rows: Record<string, unknown>[] = [];
+  const app = fakeApp(rows);
+  const out = await handler({ jobKey: "job-w", variables: { subjectKey: "owner/repo#epic-42" } } as never, app);
+  assertEquals(out, {});
+  assertEquals(rows.length, 0, "no feature_runs row was fabricated for a wave subject");
+});
+
+test("record-feature-implementing: fails fast (incident) when neither subjectKey nor featureKey is present", async () => {
+  // Both edges into `implement-task` always supply exactly one key, so a missing key can only mean the
+  // BPMN ioMapping/dataEnvelope regressed — the misconfiguration that reintroduces the stale
+  // `status="escalated"` class (#642). The worker must raise an incident (throw) rather than silently
+  // skipping the reset and masking the regression.
+  const app = fakeApp([]);
+  await assertRejects(() => handler({ jobKey: "job-x", variables: {} } as never, app));
+});

package/workers/record-feature-implementing/worker.ts

@@ -1,11 +1,18 @@
 // pr.record-feature-implementing — the twin of `record-feature-escalation` (issue #642). This
 // service task sits on BOTH edges into `implement-task`: the first entry (`f_toImplement`, off
-// `ensure-base-branch`) AND the answer re-entry (`w_answerLoop`, off the `w_gw_answer` gateway).
-// It stamps `feature_runs.status="running"` so the run is `escalated` ONLY while a token is parked
-// on the native `feature-escalation` user task — honouring the invariant `record-feature-escalation`
-// (the sole `escalated` writer) would otherwise violate on the answer loop-back: it had no symmetric
-// reset, so `status` stayed a stale `escalated` through the ENTIRE post-answer re-implementation
-// (the #632 tear). Parity with the PR `status="escalated"` contract, which holds only while parked.
+// `ensure-base-branch` in `feature.bpmn`) AND the answer re-entry — which, after the ADR 0006 S4
+// composition, lives on the shared `implement-cell`'s answer loop (`ic_answerLoop` → `record-implementing`
+// → `implement-task`), keyed by `subjectKey`. It stamps `feature_runs.status="running"` so the run is
+// `escalated` ONLY while a token is parked on the native escalation user task — honouring the invariant
+// `record-feature-escalation` (the sole `escalated` writer) would otherwise violate on the answer
+// loop-back: it had no symmetric reset, so `status` stayed a stale `escalated` through the ENTIRE
+// post-answer re-implementation (the #632 tear). Parity with the PR `status="escalated"` contract,
+// which holds only while parked.
+//
+// Keyed by `subjectKey` (the composed cell) or `featureKey` (feature.bpmn's first entry). A
+// plan-embedded wave slice (`subjectKey` = the epic's `plan_key`) has no `feature_runs` row, so the
+// reset is a guarded no-op there — symmetric with `record-feature-escalation`'s guarded flip, never
+// fabricating a bogus row.
 //
 // Idempotent-safe: re-stamping `running` is a no-op FOR THE STATUS, so the at-least-once job can retry
 // freely; it does still refresh `updated_at` on every invocation (a confirming timestamp write), and
@@ -19,12 +26,29 @@ import type { WorkerInputs } from "../../nano-generated/worker-io.d.ts";
 type In = WorkerInputs["pr.record-feature-implementing"];
 
 const handler: AppJobHandler<In> = async (job, app) => {
-  const featureKey = job.variables.featureKey;
-  await featureRuns(app.data).update(featureKey, {
-    status: "running",
-    updated_at: new Date().toISOString(),
-  });
-  app.log.info("record-feature-implementing", { featureKey });
+  // Keyed by `subjectKey` when composed inside the shared `implement-cell` answer loop (ADR 0006 S4),
+  // or by `featureKey` on `feature.bpmn`'s first-entry edge. A plan-embedded wave slice
+  // (`subjectKey` = the epic's `plan_key`) has no `feature_runs` row, so the reset is a guarded no-op
+  // there — symmetric with `record-feature-escalation`'s guarded flip — never fabricating a bogus row.
+  const subjectKey = job.variables.subjectKey ?? job.variables.featureKey;
+  // Fail fast rather than silently skipping the status reset. Both edges into `implement-task` always
+  // supply exactly one key (`feature.bpmn`'s first entry → `featureKey`; the `implement-cell` answer
+  // loop → `subjectKey`), so a missing key can only mean the BPMN ioMapping/dataEnvelope regressed —
+  // exactly the misconfiguration that reintroduces the stale `status="escalated"` class (#642). Raising
+  // an incident surfaces that regression with a clear trail instead of masking it behind a silent no-op.
+  if (!subjectKey) {
+    throw new Error(
+      "record-feature-implementing: neither subjectKey nor featureKey present — the implement edge's ioMapping/dataEnvelope has regressed (would silently skip the escalated→running reset, #642)",
+    );
+  }
+  const runs = featureRuns(app.data);
+  if (await runs.get(subjectKey)) {
+    await runs.update(subjectKey, {
+      status: "running",
+      updated_at: new Date().toISOString(),
+    });
+  }
+  app.log.info("record-feature-implementing", { subjectKey });
   return {};
 };
 

package/workers/record-wave-escalation/worker.test.ts

@@ -1,95 +0,0 @@
-// Unit coverage for pr.record-wave-escalation — the plan-fanout implement-stage escalation net (issue
-// #360). It runs on the `w_gw` "clean terminal?" gateway's `not clean` arm, BEFORE the shared
-// `feature-escalation` user task, and must:
-//   • pass through the agent's own answerable question when it declared a genuine escalation, but
-//   • SYNTHESISE an answerable question when the agent left none (a no-machine-readable result) so the
-//     parked task is never a dead end — the fix for the silent epic-death this issue reports, and
-//   • append the resolved question to the canonical `feature_escalations` audit log keyed by `planKey`
-//     (the plan-root IS the subject of an embedded slice), the source `pollUserTasks` reads (issue #358),
-//   • re-emit the resolved `question` so the `feature-escalation` form and the answer loop see it.
-import { test } from "node:test";
-import { assertEquals } from "#test-assert";
-import { noopLog } from "../../test/log.ts";
-import handler, { NO_RESULT_QUESTION } from "./worker.ts";
-
-// biome-ignore lint/suspicious/noExplicitAny: tiny in-memory app double, mirrors record-feature-escalation.worker.test
-function fakeApp(): any {
-  const stores: Record<string, Record<string, unknown>[]> = {};
-  return {
-    stores,
-    data: {
-      table(name: string, key: string) {
-        const store = (stores[name] ??= []);
-        return {
-          // biome-ignore lint/suspicious/noExplicitAny: test double
-          get: (k: any) => Promise.resolve(store.find((r) => r[key] === k)),
-          // biome-ignore lint/suspicious/noExplicitAny: test double
-          find: (q: any) => Promise.resolve(store.filter((r) => Object.entries(q).every(([f, v]) => r[f] === v))),
-          // biome-ignore lint/suspicious/noExplicitAny: test double
-          findOne: (q: any) =>
-            Promise.resolve(store.find((r) => Object.entries(q).every(([f, v]) => r[f] === v)) ?? null),
-          // biome-ignore lint/suspicious/noExplicitAny: test double
-          insert: (row: any) => {
-            store.push(row);
-            return Promise.resolve(store.length);
-          },
-          // biome-ignore lint/suspicious/noExplicitAny: test double
-          update: (k: any, patch: any) => {
-            const row = store.find((r) => r[key] === k);
-            if (row) Object.assign(row, patch);
-            return Promise.resolve(row);
-          },
-        };
-      },
-    },
-    log: noopLog(),
-  };
-}
-
-test("record-wave-escalation: a no-machine-readable result synthesises an answerable question and audits it (issue #360)", async () => {
-  const app = fakeApp();
-  // The agent finished with no status and no question — the exact failure that used to fall straight to
-  // terminal `blocked` and silently kill the epic. It must now become an answerable escalation.
-  const out = await handler(
-    { jobKey: "job-1", variables: { planKey: "owner/repo#64", status: undefined, question: undefined } } as never,
-    app,
-  );
-
-  assertEquals(out, { question: NO_RESULT_QUESTION });
-  assertEquals(app.stores.feature_escalations.length, 1);
-  assertEquals(app.stores.feature_escalations[0].feature_key, "owner/repo#64");
-  assertEquals(app.stores.feature_escalations[0].question, NO_RESULT_QUESTION);
-  assertEquals(app.stores.feature_escalations[0].job_key, "job-1");
-});
-
-test("record-wave-escalation: a genuine agent escalation passes its own question through unchanged (issue #360)", async () => {
-  const app = fakeApp();
-  const out = await handler(
-    { jobKey: "job-2", variables: { planKey: "owner/repo#64", status: "escalated", question: "Which auth library should the scaffold use?" } } as never,
-    app,
-  );
-
-  assertEquals(out, { question: "Which auth library should the scaffold use?" });
-  assertEquals(app.stores.feature_escalations[0].question, "Which auth library should the scaffold use?");
-});
-
-test("record-wave-escalation: an escalated status with a blank question is still given an answerable one (issue #360)", async () => {
-  // `escalated` with no usable question is as much a dead end as a no-result — the taxonomy classes it a
-  // NON-escalation, so without synthesis the parked task would show nothing to decide. Synthesise instead.
-  const app = fakeApp();
-  const out = await handler(
-    { jobKey: "job-3", variables: { planKey: "owner/repo#64", status: "escalated", question: "   " } } as never,
-    app,
-  );
-
-  assertEquals(out, { question: NO_RESULT_QUESTION });
-  assertEquals(app.stores.feature_escalations[0].question, NO_RESULT_QUESTION);
-});
-
-test("record-wave-escalation: a retried job (same jobKey) reuses its audit row, never duplicating (issue #360)", async () => {
-  const app = fakeApp();
-  const job = { jobKey: "job-retry", variables: { planKey: "owner/repo#64", status: undefined, question: undefined } } as never;
-  await handler(job, app);
-  await handler(job, app);
-  assertEquals(app.stores.feature_escalations.length, 1, "the retry reuses the row, no duplicate append");
-});

package/workers/record-wave-escalation/worker.ts

@@ -1,69 +0,0 @@
-// pr.record-wave-escalation — a plan-fanout wave slice did NOT return a clean terminal result, so its
-// `implement` subprocess routes here (the `w_gw` "clean terminal?" gateway's `not clean` arm) BEFORE
-// the `feature-escalation` user task is created. It is the plan-fanout analogue of feature.bpmn's
-// `record-feature-escalation`, extended with the no-result net of issue #360.
-//
-// The implement stage was the ONLY agent stage with no net for "I couldn't read the agent's result":
-//   • review rounds re-enter the durable review wait (app/roundResultDefault.ts),
-//   • trial merge raises an answerable human escalation (workers/record-trial-merge/worker.ts),
-//   • implement/wave coerced a missing status straight to terminal `blocked` — silently failing the
-//     epic and orphaning any PR the agent opened (issue #360).
-// This worker closes that gap by routing every non-clean-terminal slice onto the SAME
-// `feature-escalation` user task a genuine `status:"escalated"` already uses, so a human can enrol the
-// PR or abandon the slice instead of the epic dying with a blank reason.
-//
-// It does two things while the process variables are still in scope on the job:
-//   • synthesises an answerable `question` when the agent didn't provide one (a no-machine-readable
-//     result carries no question), mirroring record-trial-merge, and re-emits it as the `question`
-//     variable so the `feature-escalation` form and the poller both see it, and
-//   • appends that question to the append-only `feature_escalations` audit log keyed by `planKey` — the
-//     canonical, poller-readable source `pollUserTasks` reads to enrich the parked task's question on
-//     the Tasks inbox (issue #358). The plan-root embeds the slice as a multi-instance subprocess, so
-//     there is no standalone `feature_runs` row; the epic (plan) IS the subject, hence the `planKey`
-//     key. Capturing it HERE (not in the poller) is required because the WASM engine does not surface a
-//     user task's ioMapping-mapped local variables through the user-task query.
-import type { AppJobHandler } from "@nanobpm/urban";
-import { classifyEscalation } from "../../app/escalationTaxonomy.ts";
-import { recordFeatureEscalation } from "../../app/feature.ts";
-import type { WorkerInputs } from "../../nano-generated/worker-io.d.ts";
-
-// Input typed off the model data envelope (`RecordWaveEscalationIn` in plan-fanout.bpmn) — ADR 0040.
-type In = WorkerInputs["pr.record-wave-escalation"];
-interface Out extends Record<string, unknown> {
-  question: string;
-}
-
-const str = (v: unknown): string | undefined =>
-  typeof v === "string" && v.trim().length > 0 ? v.trim() : undefined;
-
-// The answerable prompt synthesised when the agent left no usable question — the implement-stage
-// analogue of record-trial-merge's synthesised trial-merge question. It names the recoverable work (a
-// PR may exist on the slice's branch) and the two answers the `w_gw_answer` gateway routes on.
-const NO_RESULT_QUESTION =
-  'The implementation agent finished without a machine-readable result (no status was reported), so we cannot tell whether the slice succeeded. It may still have opened a PR (check for a branch targeting the epic base). Choose "Answer" and give guidance to re-run the slice — or choose "Abandon" to skip it and continue the epic.';
-
-const handler: AppJobHandler<In, Out> = async (job, app) => {
-  const planKey = job.variables.planKey;
-  const rawQuestion = str(job.variables.question);
-  // The agent's own question is authoritative when it declared a real escalation with one; otherwise
-  // (a no-machine-readable result, or an escalation with a blank question) synthesise an answerable
-  // one so the parked task is never a dead end. Route through the single canonical taxonomy so this
-  // net can never drift from the tier logic every other raise site uses.
-  // A "task"-kind escalation is `decision-required` only when the agent left an answerable question, so
-  // this already covers the blank-question case; the extra `&& rawQuestion` is the type narrowing that lets
-  // us hand the string through without an assertion.
-  const agentEscalated = classifyEscalation({ kind: "task", status: job.variables.status, question: rawQuestion }) ===
-    "decision-required";
-  const question = agentEscalated && rawQuestion ? rawQuestion : NO_RESULT_QUESTION;
-
-  // Append to the canonical `feature_escalations` audit log (the surviving table `pollUserTasks` reads),
-  // keyed by `planKey` because the plan-root instance IS the subject of the embedded slice's escalation.
-  await recordFeatureEscalation(app.data, { featureKey: planKey, question, jobKey: job.jobKey });
-  app.log.info("record-wave-escalation", { planKey, synthesised: question === NO_RESULT_QUESTION });
-
-  // Re-emit the resolved question so the `feature-escalation` form (and the answer loop) see it.
-  return { question };
-};
-
-export default handler;
-export { NO_RESULT_QUESTION };