@nanobpm/nano-workforce 0.189.0 → 0.189.2

package/db/migrations/110_task_completions_auto_applied.sql

@@ -0,0 +1,34 @@
+-- 110_task_completions_auto_applied.sql — issue #806 (Copilot review): mark an AUTO-APPLIED escalation
+-- completion so it is distinguishable from a fresh human/agent submission in the attribution ledger.
+--
+-- The convergence poller auto-resumes an already-answered `wait-answer` by replaying a durable
+-- adjudication through the SAME `completeUserTaskAttributed` door a human/agent uses (app/service.ts,
+-- issue #806). Without a marker that replay is INDISTINGUISHABLE from a real, first-hand submission in
+-- `task_completions`, and — recorded as an irreversible authority — it could launder an earlier
+-- agent-originated decision into an unchallengeable human one. `auto_applied=1` records "this
+-- completion is a machine replay of a prior decision, not a fresh submission"; the app also records
+-- such completions `reversible=1` so a human can always override an auto-applied answer.
+--
+-- Forward-only, additive (expand): a nullable-defaulted `ADD COLUMN`, so every existing completion
+-- reads back `auto_applied=0` (a genuine first-hand submission). Numbered after 109 in the pre-assigned
+-- 109–110 block (#806); the runner wraps each file in its own transaction, so no BEGIN/COMMIT here.
+ALTER TABLE task_completions ADD COLUMN auto_applied INTEGER NOT NULL DEFAULT 0;
+
+-- Link an AUTO-APPLIED escalation completion back to the durable adjudication it replayed (issue #806,
+-- Copilot review), so a human's revert of that completion can invalidate the exact decision. The
+-- convergence poller auto-resumes an already-answered `wait-answer` by replaying a `pr_adjudications`
+-- row through `completeEscalationAutoApplied` (app/service.ts); recording WHICH adjudication it replayed
+-- lets `revertAgentCompletion` tombstone that decision (`invalidateAdjudication`) so the revert becomes a
+-- real override — the next round re-parks a human — instead of the poller silently re-applying the same
+-- overridden answer. NULL for every first-hand (human/agent) submission and for legacy rows; only an
+-- auto-apply carries a source adjudication. Additive (expand): a nullable `ADD COLUMN`. Folded into this
+-- file to keep the whole change inside the pre-assigned 109–110 block (#806, Copilot review) rather than
+-- consuming an unallocated 111 prefix.
+ALTER TABLE task_completions ADD COLUMN source_adjudication_id INTEGER;
+
+-- `latestAdjudicator` (workers/answer-escalation) now looks a completion up by `process_instance_key`
+-- for every convergence answer, to correlate the settled adjudicator's attribution (#806). The ledger
+-- is append-only and only carried an index on `user_task_key` (026_agent_completion.sql), so that
+-- lookup would scan the whole completion history as the fleet grows. Index `process_instance_key` too
+-- (additive/expand — a new index, no existing shape touched).
+CREATE INDEX idx_task_completions_pik ON task_completions(process_instance_key);

package/operations/completeUserTask.test.ts

@@ -80,7 +80,7 @@ test("complete-user-task: completes a plan-review escalation and drops its read-
   assertEquals(res.status, 200);
   assertEquals(res.body.ok, true);
   assertEquals(res.body.elementId, "plan-review-decision");
-  assertEquals(completed, [{ userTaskKey: "ut-1", variables: { directive: "revise", notes: "narrow scope" } }]);
+  assertEquals(completed, [{ userTaskKey: "ut-1", variables: { directive: "revise", notes: "narrow scope", completedUserTaskKey: "ut-1", completedCompletionId: 1 } }]);
   assertEquals(stores.user_tasks, []);
   // Attribution recorded as a human completion.
   assertEquals(stores.task_completions.length, 1);
@@ -93,7 +93,7 @@ test("complete-user-task: completes a trial-merge escalation with the typed acti
   const res = await call(app, { userTaskKey: "ut-2", variables: { action: "rebase" } });
 
   assertEquals(res.status, 200);
-  assertEquals(completed, [{ userTaskKey: "ut-2", variables: { action: "rebase" } }]);
+  assertEquals(completed, [{ userTaskKey: "ut-2", variables: { action: "rebase", completedUserTaskKey: "ut-2", completedCompletionId: 1 } }]);
 });
 
 test("complete-user-task: a missing userTaskKey is a 400", async () => {
@@ -120,7 +120,7 @@ test("complete-user-task: completes a feature-blocked acknowledgement with the t
   const res = await call(app, { userTaskKey: "ut-4", variables: { note: "reassigned" } });
   assertEquals(res.status, 200);
   assertEquals(res.body.elementId, "feature-blocked");
-  assertEquals(completed, [{ userTaskKey: "ut-4", variables: { note: "reassigned" } }]);
+  assertEquals(completed, [{ userTaskKey: "ut-4", variables: { note: "reassigned", completedUserTaskKey: "ut-4", completedCompletionId: 1 } }]);
 });
 
 test("complete-user-task: completes a feature-escalation answer (issue #332)", async () => {
@@ -128,7 +128,7 @@ test("complete-user-task: completes a feature-escalation answer (issue #332)", a
   const res = await call(app, { userTaskKey: "ut-6", variables: { resolution: "answer", answer: "use v2" } });
   assertEquals(res.status, 200);
   assertEquals(res.body.elementId, "feature-escalation");
-  assertEquals(completed, [{ userTaskKey: "ut-6", variables: { resolution: "answer", answer: "use v2" } }]);
+  assertEquals(completed, [{ userTaskKey: "ut-6", variables: { resolution: "answer", answer: "use v2", completedUserTaskKey: "ut-6", completedCompletionId: 1 } }]);
 });
 
 test("complete-user-task: refuses a non-completable internal user task (400)", async () => {
@@ -161,5 +161,5 @@ test("complete-user-task: a read-model cleanup failure does not mask a resumed c
 
   assertEquals(res.status, 200);
   assertEquals(res.body.ok, true);
-  assertEquals(completed, [{ userTaskKey: "ut-5", variables: { directive: "revise", notes: "narrow scope" } }]);
+  assertEquals(completed, [{ userTaskKey: "ut-5", variables: { directive: "revise", notes: "narrow scope", completedUserTaskKey: "ut-5", completedCompletionId: 1 } }]);
 });

package/operations/listEscalations.test.ts

@@ -126,7 +126,7 @@ test("listEscalations: round-trip — the listed userTaskKey is exactly what com
   assertEquals(done.status, 200);
   assertEquals(done.body.ok, true);
   assertEquals(done.body.elementId, "wait-answer");
-  assertEquals(completed, [{ userTaskKey: "ut-answer", variables: { answer: "v2" } }]);
+  assertEquals(completed, [{ userTaskKey: "ut-answer", variables: { answer: "v2", completedUserTaskKey: "ut-answer", completedCompletionId: 1 } }]);
   // The answered task's read-model row is dropped, so a re-list no longer shows it.
   assertEquals(stores.user_tasks, []);
   const reListed = await callList(app);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nanobpm/nano-workforce",
-  "version": "0.189.0",
+  "version": "0.189.2",
   "description": "Nano Workforce — an Agent Graph Orchestration application for Agentic SDLC: durable BPMN processes that coordinate a graph of AI agents across the software delivery lifecycle.",
   "type": "module",
   "main": "main.ts",

package/resources/processes/convergence-loop.bpmn

@@ -88,6 +88,10 @@
         <nano:shape id="PrAnswerEscalationIn" name="Answer escalation — input">
           <nano:extend name="prKey" type="string" />
           <nano:extend name="answer" type="string" optional="true" />
+          <nano:extend name="answerContext" type="string" optional="true" />
+          <nano:extend name="completedUserTaskKey" type="string" optional="true" />
+          <nano:extend name="completedCompletionId" type="integer" optional="true" />
+          <nano:extend name="escalationId" type="integer" optional="true" />
         </nano:shape>
         <nano:shape id="PrFinalizeIn" name="Mark converged — input">
           <nano:extend name="prKey" type="string" />
@@ -308,9 +312,14 @@
         <zeebe:ioMapping>
           <zeebe:input source="=prKey" target="prKey" />
           <zeebe:input source="=answer" target="answer" />
+          <zeebe:input source="=&#34;convergence&#34;" target="answerContext" />
+          <zeebe:input source="=completedUserTaskKey" target="completedUserTaskKey" />
+          <zeebe:input source="=completedCompletionId" target="completedCompletionId" />
           <zeebe:output source="=(if scopePending = true then answer else scopeAnswer)" target="scopeAnswer" />
           <zeebe:output source="=0" target="huskRetries" />
           <zeebe:output source="=false" target="reviewStale" />
+          <zeebe:output source="=null" target="completedUserTaskKey" />
+          <zeebe:output source="=null" target="completedCompletionId" />
         </zeebe:ioMapping>
       </bpmn:extensionElements>
       <bpmn:incoming>f_answerRecord</bpmn:incoming>

package/resources/processes/merge-loop.bpmn

@@ -329,6 +329,7 @@
         <zeebe:ioMapping>
           <zeebe:input source="=prKey" target="prKey" />
           <zeebe:input source="=answer" target="answer" />
+          <zeebe:input source="=&#34;merge&#34;" target="answerContext" />
         </zeebe:ioMapping>
       </bpmn:extensionElements>
       <bpmn:incoming>f_m_answerRecord</bpmn:incoming>

package/workers/answer-escalation/worker.ts

@@ -17,21 +17,26 @@
 // durable rows; it returns no variables, leaving the submitted `answer` untouched so it flows on to
 // the next review round.
 import type { AppJobHandler } from "@nanobpm/urban";
+import { generationGuard, recordAdjudication } from "../../app/adjudications.ts";
+import { taskCompletions } from "../../app/agentCompletion.ts";
 import type { WorkerInputs } from "../../nano-generated/worker-io.d.ts";
 
 interface Escalation extends Record<string, unknown> {
   id: number;
   pr_key: string;
   status: string;
+  question: string;
   answer: string | null;
   answered_at: string | null;
 }
 
 // The PR-row fields this worker reconciles when an escalation is answered. Only `status`/`updated_at`
-// are written; the rest of the row is untouched.
+// are written; the rest of the row is untouched. `process_key` is READ (never written here) to reject a
+// delayed/redelivered job from a superseded process instance (Copilot review of #806).
 interface PullRequest extends Record<string, unknown> {
   pr_key: string;
   status: string;
+  process_key: string | null;
   updated_at: string;
 }
 
@@ -42,10 +47,62 @@ type In = WorkerInputs["pr.answer-escalation"];
 function nonBlank(v: unknown): string | undefined {
   return typeof v === "string" && v.trim() !== "" ? v.trim() : undefined;
 }
+// A finite integer variable, or undefined when absent/blank/non-numeric. The `completedCompletionId`
+// envelope field is typed `integer`, so it arrives as a number; tolerate a numeric string defensively.
+function nonBlankInt(v: unknown): number | undefined {
+  if (typeof v === "number") return Number.isFinite(v) ? v : undefined;
+  if (typeof v === "string" && v.trim() !== "") {
+    const n = Number(v);
+    return Number.isFinite(n) ? n : undefined;
+  }
+  return undefined;
+}
 
 const handler: AppJobHandler<In> = async (job, app) => {
   const { prKey } = job.variables;
   const answer = nonBlank(job.variables.answer);
+  // The exact identity of the `wait-*` completion that resumed THIS token (Copilot review of #806),
+  // stamped by `completeUserTaskAttributed` on the resumed token. Used to correlate the durable
+  // adjudication to the completion the engine actually accepted; absent for an out-of-band resume.
+  const completedUserTaskKey = nonBlank(job.variables.completedUserTaskKey);
+  // The exact ledger id of the winning completion (Copilot review of #806), stamped by
+  // `completeUserTaskAttributed`. When present it uniquely identifies the winner — even against a
+  // same-answer losing racer on the same `user_task_key` — so record-answer selects that exact row
+  // rather than correlating by answer. Absent for an out-of-band resume.
+  const completedCompletionId = nonBlankInt(job.variables.completedCompletionId);
+  // The durable id of the escalation THIS completion answers (Copilot review of #806). The originating
+  // `pr.persist-escalation` returns its inserted `escalations.id` as a process variable (`EscalationOut`),
+  // which the `wait-*` completion carries through here. Answering by this exact id — rather than the
+  // newest open row — is what makes a REDELIVERED older answer safe: if the process has since opened a
+  // NEWER escalation (a different question), a stale Q1 `record-answer` whose `escalationId` no longer
+  // matches any open row is a no-op instead of misfiling Q1's answer under Q2's fingerprint and retiring
+  // Q2 unanswered. Absent for a pre-#806 / out-of-band resume — we then fall back to the newest open row.
+  const escalationId = nonBlankInt(job.variables.escalationId);
+  const prs = app.data.table<PullRequest>("pull_requests", "pr_key");
+  // Reject a delayed/redelivered job from a SUPERSEDED process instance (Copilot review of #806).
+  // `pull_requests.process_key` always tracks the CURRENT loop instance for this PR — the convergence
+  // instance at submit, reassigned to the merge instance at merge-start (app/service.ts). A job whose
+  // `processInstanceKey` no longer matches is from an old run that a re-submit (or the merge hand-off)
+  // replaced; accepting it would let a stale process reinsert its adjudication after the fresh run's
+  // reset, or even answer the new run's open escalation, so a re-submit would not be a reliable
+  // fresh-decision boundary. No-op such jobs BEFORE any adjudication/escalation/PR write. When the
+  // current process is unknown (no row / null `process_key`) we cannot classify the job as stale, so
+  // we proceed rather than silently drop a legitimate operator answer.
+  //
+  // The `process_key` is read AS LATE AS POSSIBLE — immediately before the writes below, not at handler
+  // entry — so a concurrent re-submit that advances `process_key` and resets the adjudication memory is
+  // observed here (Copilot review of #806). Paired with submitPr advancing `process_key` BEFORE it
+  // clears the memory, this shrinks the reset window to a single check-then-write step: a straggler is
+  // rejected once the new identity is installed, and any pre-advance insert is cleared by the
+  // post-advance reset.
+  const jobProcessKey = job.processInstanceKey != null ? String(job.processInstanceKey) : undefined;
+  // This one worker services BOTH loops' answer steps (`record-answer` in the convergence loop AND
+  // `record-merge-answer` in the merge loop, #256). Only a CONVERGENCE answer may feed the durable
+  // adjudication memory the convergence poller replays — a merge-loop decision recorded here would let
+  // a later convergence `wait-answer` with the same text replay a merge-context answer that was never a
+  // convergence adjudication (Copilot review of #806). The originating step stamps `answerContext` via a
+  // literal ioMapping so this reconcile can tell them apart.
+  const isConvergence = nonBlank(job.variables.answerContext) === "convergence";
   const escs = app.data.table<Escalation>("escalations", "id");
   // Retire EVERY still-open escalation for this PR. `pr.persist-escalation` always INSERTs a new
   // open row, so a retry/duplicate activation can leave more than one open — answering only the
@@ -53,24 +110,147 @@ const handler: AppJobHandler<In> = async (job, app) => {
   // is still `escalated`. Answer the newest (it carries the operator's reply) and mark any remaining
   // open rows `stale`, mirroring `submitPr`'s resubmit cleanup.
   const open = (await escs.find({ pr_key: prKey, status: "open" })).sort((a, b) => b.id - a.id);
-  if (open.length > 0) {
+  const currentProcessKey = nonBlank((await prs.find({ pr_key: prKey }))[0]?.process_key);
+  if (currentProcessKey !== undefined && jobProcessKey !== undefined && jobProcessKey !== currentProcessKey) {
+    return {};
+  }
+  // The escalation this completion actually answers. Prefer the exact `escalationId` the winning
+  // completion carried; fall back to the newest open row only when it is absent (a pre-#806 / out-of-band
+  // resume). If an `escalationId` was carried but no OPEN row bears it, this is a redelivered answer for
+  // an escalation that has already been retired (or superseded by a newer question) — no-op rather than
+  // misfile the answer under a different escalation's question (Copilot review of #806).
+  const target = escalationId != null ? open.find((e) => e.id === escalationId) : open[0];
+  if (target !== undefined) {
     const ts = new Date().toISOString();
-    await escs.update(open[0].id, {
-      answer: answer ?? null,
-      status: "answered",
-      answered_at: ts,
-    });
-    for (const dup of open.slice(1)) {
-      await escs.update(dup.id, { status: "stale" });
+    // Persist the DURABLE adjudication FIRST, BEFORE the escalation/PR rows transition off `open`
+    // (issue #806, Copilot review — crash safety). `recordAdjudication` is INSERT-if-absent idempotent,
+    // so if the worker crashes after this write but before the row transitions, a retry re-finds the
+    // still-open row and re-records a no-op; whereas recording it LAST would mean a crash in the window
+    // after the rows flip loses the adjudication entirely (the retry finds no open row and returns), so
+    // the answered question could re-escalate after restart. Scoped to convergence answers only.
+    if (isConvergence) {
+      const adjudicator = await latestAdjudicator(app, job.processInstanceKey, answer, completedUserTaskKey, completedCompletionId);
+      await recordAdjudication(app.data, {
+        prKey,
+        question: target.question,
+        answer,
+        adjudicatedBy: adjudicator?.id,
+        adjudicatedKind: adjudicator?.kind,
+        // Link the decision to the winning completion (issue #806 review) so a later revert of that
+        // completion can tombstone it even when it is a FIRST-HAND agent answer with no
+        // `source_adjudication_id`. INSERT-if-absent, so it pins to the original first-hand winner.
+        sourceCompletionId: completedCompletionId,
+        // Run generation this answer belongs to: every adjudication write is fenced on the PR's current
+        // `process_key` still matching it, so a pre-reset straggler (one that passed the check above,
+        // then paused across a re-submit that advanced `process_key` and cleared the memory) cannot
+        // resurrect a stale adjudication after the reset (issue #806, Copilot review). Undefined when the
+        // job carries no instance key — the fence then fails open, exactly like the staleness gate above.
+        expectedProcessKey: jobProcessKey,
+      });
+    }
+    // Fence the escalation/PR transitions on the run generation too (Copilot review of #806). The
+    // ownership check above is READ-TIME — not atomic with these writes — so in the window between it
+    // and here a concurrent re-submit could advance `process_key` and open a FRESH escalation; a naive
+    // `escs.update`/`prs.update` would then answer the new run's snapshot and flip its PR to
+    // `converging`. Each write is now a guarded conditional statement carrying the SAME `generationGuard`
+    // predicate as the adjudication writes (one guard, no second implementation): it applies only while
+    // the PR's current `process_key` still matches this job's generation, so a superseded worker touches
+    // nothing. Fails open when `jobProcessKey` is undefined, exactly like the gate above.
+    const db = app.data.open();
+    const guard = generationGuard(prKey, jobProcessKey);
+    await db.exec(
+      `UPDATE "escalations" SET "answer" = ?, "status" = 'answered', "answered_at" = ? WHERE "id" = ? AND ${guard.sql}`,
+      [answer ?? null, ts, target.id, ...guard.params],
+    );
+    // Mark any OTHER still-open row `stale` (a `pr.persist-escalation` retry can leave more than one
+    // open for the same question). We retire every open row except the one we just answered so a phantom
+    // `activePrs` never keeps deriving while the PR is `escalated`.
+    for (const dup of open) {
+      if (dup.id === target.id) continue;
+      await db.exec(
+        `UPDATE "escalations" SET "status" = 'stale' WHERE "id" = ? AND ${guard.sql}`,
+        [dup.id, ...guard.params],
+      );
     }
     // Move the PR off `status="escalated"` back to
     // `"converging"` now that the question is answered. Without this the row stays `escalated` (with
     // a now-null derived `openEscalation`) until the re-entered round's `persist-round` runs — a
     // `/status` inconsistency and a divergence from the merge path both loops are meant to share.
-    const prs = app.data.table<PullRequest>("pull_requests", "pr_key");
-    await prs.update(prKey, { status: "converging", updated_at: ts });
+    await db.exec(
+      `UPDATE "pull_requests" SET "status" = 'converging', "updated_at" = ? WHERE "pr_key" = ? AND ${guard.sql}`,
+      [ts, prKey, ...guard.params],
+    );
   }
   return {};
 };
 
+/** Who just completed this `wait-answer`: the `{ id, kind }` of the `task_completions` row that
+ *  actually WON the user-task race, so the durable adjudication is attributed to the completion the
+ *  engine accepted — never a losing racer's transient row NOR an older round's completion. Both
+ *  canonical completers (`completeUserTaskAttributed`) insert their ledger row BEFORE calling
+ *  `completeUserTask` and the loser only removes its row AFTER the engine rejects it, so a bare
+ *  "newest row for this process instance" can transiently select a higher-id LOSER; and because a
+ *  convergence-loop instance is REUSED across rounds, an older round's completion (or a delayed
+ *  same-answer redelivery) with a higher id can also linger for the SAME process instance (Copilot
+ *  review of #806). Correlate on the EXACT completion identity: the resumed token carries the
+ *  `completedCompletionId` — the ledger id of the exact completion the engine accepted — so the winner
+ *  is the row with that id, unambiguous even when both racers submitted the IDENTICAL answer (answer
+ *  correlation alone cannot separate two same-answer rows on one `user_task_key`; the higher-id one may
+ *  be the loser). A pre-#806-fix out-of-band resume that carried no `completedCompletionId` falls back
+ *  to the exact `completedUserTaskKey` + winning-answer correlation, and attributes ONLY when that
+ *  leaves exactly one candidate — an ambiguous same-answer set fails open rather than guess a winner.
+ *  The KIND (`human`/`agent`, ADR
+ *  0046) is preserved so a later auto-resume replays with the ORIGINAL attribution and never launders
+ *  an agent decision into a human one. `undefined` (fails open to a fresh human task) when the identity
+ *  is unavailable or no ledger row exactly matches — rather than attribute a wrong one. */
+async function latestAdjudicator(app: Parameters<AppJobHandler<In>>[1], processInstanceKey: unknown, winningAnswer: string | undefined, completedUserTaskKey: string | undefined, completedCompletionId: number | undefined): Promise<{ id: string; kind: string } | undefined> {
+  // Exact ledger-id match by PRIMARY KEY. The engine resumed this token with exactly ONE completion's
+  // variables, and that completion stamped its own (globally unique) ledger id here — so look the
+  // winner up DIRECTLY by primary key, BEFORE the process-instance fallback below. It must NOT be found
+  // via a `process_instance_key`-scoped query: the canonical completers (`completeUserTaskAttributed`)
+  // resolve the task through the typed `openUserTasks` seam, which deliberately omits `processInstanceKey`
+  // (app/service.ts), so EVERY real ledger row is stored with `process_instance_key = null`. A
+  // `process_instance_key`-filtered lookup therefore never matched the winning row and always failed
+  // open — recording a null adjudicator and letting the convergence poller re-park an already-answered
+  // question (Copilot review). Selecting nothing still returns undefined and fails open (never attribute
+  // a wrong row).
+  if (completedCompletionId != null) {
+    const exact = await taskCompletions(app.data).get(completedCompletionId);
+    return exact ? { id: exact.actor_id, kind: exact.actor_kind } : undefined;
+  }
+  // Process-instance fallback for a resume that carried no completion id (a pre-fix / out-of-band
+  // token): require the carried user-task identity, then — when the winning answer is known — keep only
+  // rows whose recorded answer matches it, dropping the same-task losing racer whose recorded submission
+  // differs. Without a completion id there is no evidence WHICH row won, so attribute ONLY when the
+  // candidate set is exactly one (Copilot review of #806): more than one same-answer row on this
+  // `user_task_key` is the very ambiguity the completion id was added to resolve — picking the newest
+  // could attribute to the losing racer — so return undefined and fail open to a human rather than guess.
+  const key = processInstanceKey != null ? String(processInstanceKey) : "";
+  if (key === "") return undefined;
+  const rows = await taskCompletions(app.data).find({ process_instance_key: key });
+  if (completedUserTaskKey == null || completedUserTaskKey === "") return undefined;
+  let candidates = rows.filter((r) => String(r.user_task_key) === completedUserTaskKey);
+  if (winningAnswer != null && winningAnswer !== "") {
+    candidates = candidates.filter((r) => completionAnswer(r.variables_json) === winningAnswer);
+  }
+  if (candidates.length !== 1) return undefined;
+  const only = candidates[0];
+  return { id: only.actor_id, kind: only.actor_kind };
+}
+
+/** The trimmed `answer` field recorded in a completion's `variables_json`, or undefined when the JSON
+ *  is unparseable or carries no string answer. Used to correlate a ledger row with the submission the
+ *  engine actually accepted (see `latestAdjudicator`). */
+function completionAnswer(variablesJson: unknown): string | undefined {
+  if (typeof variablesJson !== "string") return undefined;
+  try {
+    const parsed: unknown = JSON.parse(variablesJson);
+    if (parsed === null || typeof parsed !== "object" || !("answer" in parsed)) return undefined;
+    const answer = parsed.answer;
+    return typeof answer === "string" && answer.trim() !== "" ? answer.trim() : undefined;
+  } catch {
+    return undefined;
+  }
+}
+
 export default handler;