@nanobpm/nano-workforce 0.189.0 → 0.189.1

package/app/service.ts

@@ -9,7 +9,8 @@
 // `Table<T>` surface), not hand-written SQL. Row shapes are declared inline here.
 import type { DataLayer, EngineClient } from "@nanobpm/urban";
 import { ABANDONED_STATUS, abandonUrl, mintAbandonToken, renderAbandonBrief } from "./abandon.ts";
-import { escalationFormId } from "./agentCompletion.ts";
+import { matchAdjudication, prAdjudications, resetAdjudications } from "./adjudications.ts";
+import { completeEscalationAutoApplied, escalationFormId } from "./agentCompletion.ts";
 import { agentSlaTimeout } from "./agentSla.ts";
 import {
   CAPS_RESOLVED_MESSAGE,
@@ -585,6 +586,14 @@ export async function submitPr(
     for (const e of await escs(data).find({ pr_key: parsed.prKey, status: "open" })) {
       await escs(data).update(e.id, { status: "stale" });
     }
+    // A fresh convergence run must ALSO start with a clean durable adjudication memory (issue #806,
+    // Copilot review): the auto-resume replays a prior `(PR, question)` answer forever, so a re-opened
+    // PR whose question recurs would silently auto-apply the stale decision and an operator could never
+    // force a fresh one. This PR's adjudications are invalidated on reopen — but the reset is deferred
+    // to AFTER `process_key` is advanced to the new instance (see below), NOT here: clearing the memory
+    // while `process_key` still names the OLD instance leaves a window where a delayed old-instance
+    // answer job still passes the worker's staleness gate and reinserts its adjudication into the fresh
+    // run (Copilot review of #806). Advancing the run identity FIRST, then clearing, fences that job.
     // Re-open a previously converged/abandoned/merged PR for a fresh convergence run.
     await table.update(parsed.prKey, {
       status: "converging",
@@ -682,8 +691,44 @@ export async function submitPr(
     },
   });
   const processKey = processInstanceKey == null ? null : String(processInstanceKey);
-  if (processKey != null) {
-    await table.update(parsed.prKey, { process_key: processKey });
+  // The `process_key` advance and the adjudication reset below are the two writes that MAKE the new
+  // run authoritative. If EITHER throws, the newly created instance is already live but the reopen is
+  // only half-committed — and a retry would short-circuit at the `alreadyRunning` idempotency gate
+  // (the new instance is ACTIVE, so `derived_status` is non-terminal), never re-running the reset. A
+  // failed reset would then leave the fresh run replaying STALE adjudication memory indefinitely
+  // (Copilot review). So roll the just-created run back on failure: terminate it and rethrow, so the
+  // submission is NOT treated as started. Terminating flips the PR's derived tracking status to a
+  // terminal edge (`abandoned`) via the `instanceTracking` reconciler, making the PR resubmittable so
+  // a retry re-creates a fresh instance and re-runs the reset cleanly — no orphaned run auto-applies
+  // stale decisions in the meantime.
+  try {
+    if (processKey != null) {
+      await table.update(parsed.prKey, { process_key: processKey });
+    }
+    // Invalidate this PR's durable adjudication memory for the fresh run (issue #806, Copilot review) —
+    // deferred to HERE, after `process_key` is advanced to the new instance above, so the reset happens
+    // UNDER the new run identity. On reopen (`existing`), any delayed old-instance answer job is now
+    // rejected by the worker's staleness gate (its `processInstanceKey` no longer matches the advanced
+    // `process_key`), so it cannot reinsert a stale adjudication after the reset; and the worker reads
+    // `process_key` as late as possible so it observes this advance. The insert-if-absent record then
+    // re-learns the operator's new answer for the new run. Runs unconditionally (even if `processKey` is
+    // null: the memory must still be clean for the fresh run). The wipe is a SINGLE atomic `DELETE`
+    // (`resetAdjudications`), never a row-by-row loop, so a crash mid-reset cannot leave a partially
+    // cleared memory (Copilot review of #806).
+    if (existing) {
+      await resetAdjudications(data, parsed.prKey);
+    }
+  } catch (err) {
+    if (processInstanceKey != null) {
+      try {
+        await engine.cancelInstance({ processInstanceKey: String(processInstanceKey) });
+      } catch (cancelErr) {
+        // Best-effort: a failed rollback-cancel leaves the instance for the abandon/reconcile poller
+        // to reap, but must not mask the original error that the caller needs to see and retry on.
+        console.warn(`[submit] ${parsed.prKey} rollback-cancel of ${processInstanceKey} failed: ${cancelErr}`);
+      }
+    }
+    throw err;
   }
   return { prKey: parsed.prKey, processKey };
 }
@@ -2839,12 +2884,67 @@ export async function pollUserTasks(
   // Desired set, deduped by completable key (a task is open at most once; guard a page overlap / a
   // subject seen under two statuses mid-pass).
   const desiredByKey = new Map<string, UserTaskRow>();
+  // Keys auto-resumed from a durable adjudication this pass (issue #806). The reduced-capability scan
+  // visits each instance twice (direct + callActivity hierarchy), and both queries snapshot the task
+  // BEFORE the resume removes it, so the second visit would otherwise re-attempt a now-gone completion
+  // and fall through to projecting the very row we just retired. Recording the key keeps the resume
+  // one-shot and out of the inbox.
+  const resumedByKey = new Set<string>();
   const project = async (elementId: string | undefined, userTaskKey: string, processInstanceKey: string, rootProcessInstanceKey: string, formKey: string) => {
     if (!elementId) return;
     const rowKey = userTaskKey.trim();
-    if (!rowKey || desiredByKey.has(rowKey)) return;
+    if (!rowKey || desiredByKey.has(rowKey) || resumedByKey.has(rowKey)) return;
     const ctx = await contextFor(elementId, userTaskKey, processInstanceKey, rootProcessInstanceKey, formKey);
     if (!ctx) return;
+    // Durable adjudication auto-resume (issue #806): before surfacing a NEW convergence `wait-answer`
+    // to a human, check whether THIS PR already has a settled adjudication for the SAME question
+    // (canonical `questionFingerprint`). If it does, resume the loop with the recorded answer through
+    // the canonical `completeUserTaskAttributed` door — attributed to the prior adjudicator and marked
+    // `auto_applied` (a machine replay, reversible so a human can still override) so it is never
+    // laundered into a first-hand irreversible human authority (Copilot review of #806) — instead of
+    // re-parking a human on an already-answered question (PR #800 / proc 46310: the same design
+    // question escalated at round 2 and again at round 13). Scoped to the review loop's `wait-answer`
+    // on a real PR key; on any resolution failure the task still projects, so an un-resumable question
+    // always reaches a human (fail-open to the human).
+    if (elementId === PR_WAIT_ANSWER_ELEMENT && ctx.subjectType === "pr" && ctx.question && parsePr(ctx.subjectKey)) {
+      try {
+        // The adjudication LOOKUP lives inside this fail-open `try` (not just the resume) so a transient
+        // `pr_adjudications.find` error never rejects `project` and aborts `pollUserTasks` mid-pass — the
+        // task still projects and the question always reaches a human (SPEC: adjudication-resolution
+        // failures fail open to the human).
+        const adjudication = matchAdjudication(await prAdjudications(data).find({ pr_key: ctx.subjectKey }), ctx.question);
+        // Only auto-resume when the prior adjudicator's provenance is KNOWN. A settled row with a blank
+        // `adjudicated_by` (completed out of band, so `latestAdjudicator` returned no actor) must NOT be
+        // manufactured into a synthetic `human` actor — that would audit an unknown-provenance replay as
+        // a first-hand human decision. Fail open to a fresh human task instead (Copilot review of #806).
+        const adjudicatedBy = adjudication?.adjudicated_by?.trim();
+        if (adjudication && adjudicatedBy) {
+          const resumed = await completeEscalationAutoApplied(data, engine, {
+            userTaskKey: rowKey,
+            // The sweep already discovered this task's owning instance — hand it to the resolve so the
+            // auto-apply scans that ONE instance, not every open user task engine-wide (issue #806
+            // Copilot review: an unfiltered per-task scan makes a single poll pass O(N²) across N
+            // already-adjudicated PRs). `contextFor`/the sweep report the task's direct instance, so the
+            // filtered scan finds exactly this task; a miss still fails open to the human.
+            processInstanceKey,
+            variables: { answer: adjudication.answer },
+            actor: {
+              kind: adjudication.adjudicated_kind === "agent" ? "agent" : "human",
+              id: adjudicatedBy,
+            },
+            // Link the auto-apply back to the replayed adjudication (issue #806) so a human revert of the
+            // resulting completion invalidates this exact decision instead of it being silently re-applied.
+            adjudicationId: adjudication.id,
+          });
+          if (resumed.ok) {
+            resumedByKey.add(rowKey);
+            return;
+          }
+        }
+      } catch (err) {
+        console.error(`[poller] adjudication auto-resume (${ctx.subjectKey}): ${err}`);
+      }
+    }
     const row = buildUserTaskRow(ctx, at);
     if (row) desiredByKey.set(rowKey, row);
   };

package/app/terminalReaderBehaviour.test.ts

@@ -51,6 +51,27 @@ function memData(stores: Stores) {
   return {
     table: withTrackingViews((name: string, key: string) =>
       memTable(stores[name]?.rows ?? [], stores[name]?.key ?? key)),
+    // Emulates the atomic bulk `DELETE FROM "pr_adjudications" WHERE "pr_key" = ?` submitPr issues via
+    // `data.open().exec` to reset a reopened PR's adjudication memory (Copilot review of #806). The SQL
+    // is validated against real SQLite in app/adjudications.test.ts; here it need only mutate the store.
+    open: () => ({
+      exec: async (sql: string, params: any[] = []) => {
+        if (/DELETE FROM "pr_adjudications" WHERE "pr_key" = \?/.test(sql)) {
+          const store = stores.pr_adjudications;
+          let changed = 0;
+          if (store) {
+            for (let i = store.rows.length - 1; i >= 0; i--) {
+              if (store.rows[i].pr_key === params[0]) {
+                store.rows.splice(i, 1);
+                changed++;
+              }
+            }
+          }
+          return { changed };
+        }
+        throw new Error(`unexpected exec sql: ${sql}`);
+      },
+    }),
   } as any;
 }
 

package/db/migrations/109_pr_adjudications.sql

@@ -0,0 +1,61 @@
+-- 109_pr_adjudications.sql — issue #806: persist wait-answer human adjudications so an
+-- already-answered convergence question does not re-escalate.
+--
+-- The convergence loop's `wait-answer` escalation (`record-answer` → resume) applies a human's
+-- answer to the CURRENT round but keeps NO durable memory that "(this PR, this question) was already
+-- adjudicated to X". A stateless later round that re-derives the identical escalation condition
+-- re-parks a human from scratch (PR #800 / proc 46310: the same design question escalated at round 2
+-- and again at round 13, both answered identically). A human adjudication is NOT GitHub-derivable —
+-- it is a fact the app itself must remember — so it lives here, durably.
+--
+-- One row per (PR, question) a human has settled: `pr.answer-escalation` (record-answer) writes it on
+-- answering, and the poller (`pollUserTasks`) reads it before surfacing a NEW `wait-answer` — when the
+-- question's fingerprint matches an existing row it auto-resumes with the recorded answer (attributed
+-- to the prior adjudicator) instead of re-escalating a human.
+--
+--   • question_fingerprint — the canonical `normalizeAdvisoryText` + `fingerprint` digest of the
+--     escalation question (app/github.ts `questionFingerprint`), the SAME line-stable normalisation
+--     advisory acks use; so only a byte/semantic-identical, already-answered question is suppressed
+--     while a materially different question still escalates. No second fingerprint implementation.
+--   • answer / adjudicated_by / adjudicated_kind / adjudicated_at — the settled answer, who settled it,
+--     whether they were a `human` or an `agent` (ADR 0046), and when, so the auto-resume replays the
+--     exact decision AND preserves the original attribution kind — a human-settled decision replays as
+--     human, an agent-settled one as agent, so an auto-apply can never launder an agent decision into an
+--     irreversible human authority (Copilot review of #806).
+--   • invalidated_at — a TOMBSTONE set when a human REVERTS the auto-applied completion that replayed
+--     this decision (`revertAgentCompletion` → `invalidateAdjudication`, Copilot review of #806). A plain
+--     DELETE is NOT race-safe: the reverted completion's `record-answer` job can be redelivered
+--     (at-least-once) AFTER the delete and re-insert the SAME `(pr_key, question_fingerprint)`, so the
+--     next poller pass re-auto-applies and silently undoes the revert. Keeping the row as a tombstone lets
+--     the `UNIQUE (pr_key, question_fingerprint)` fence make that redelivered re-insert a no-op, and
+--     `matchAdjudication` skips a tombstoned row so it never auto-applies again. The tombstone is cleared
+--     only by `resetAdjudications` on a fresh-run re-submit. NULL for a live, replayable decision.
+--   • source_completion_id — the `task_completions.id` of the WINNING completion that produced this
+--     decision (issue #806 review). A FIRST-HAND agent answer to a `wait-answer` records its own durable
+--     adjudication (`adjudicated_kind="agent"`) but — unlike a machine auto-apply — its ledger row has
+--     `auto_applied=0` and NO `source_adjudication_id`, so a human revert of that reversible agent
+--     completion could not previously find and tombstone the decision it created, and the poller would
+--     re-auto-apply the reverted answer. Linking every convergence adjudication to its winning completion
+--     lets `revertAgentCompletion` invalidate the decision on ANY reversible agent revert, not only a
+--     machine replay (`invalidateAdjudicationByCompletion`). INSERT-if-absent, so only the ORIGINAL
+--     first-hand completion is recorded; a later auto-apply's re-record is a UNIQUE no-op that leaves the
+--     link pointing at the first-hand winner. NULL for a legacy/uncorrelated answer.
+--
+-- `UNIQUE (pr_key, question_fingerprint)` keeps one settled answer per (PR, question); the surrogate
+-- `id` PK gives the `Table<T>` gateway a single-column key. Forward-only, additive (expand). Numbered
+-- after the current highest committed prefix (104) in the pre-assigned 109–110 block (#806); the
+-- runner wraps each file in its own transaction, so this file must NOT contain BEGIN/COMMIT.
+CREATE TABLE IF NOT EXISTS pr_adjudications (
+  id                   INTEGER PRIMARY KEY AUTOINCREMENT,
+  pr_key               TEXT NOT NULL REFERENCES pull_requests(pr_key),
+  question_fingerprint TEXT NOT NULL,
+  answer               TEXT,
+  adjudicated_by       TEXT,
+  adjudicated_kind     TEXT,
+  adjudicated_at       TEXT NOT NULL,
+  invalidated_at       TEXT,
+  source_completion_id INTEGER,
+  UNIQUE (pr_key, question_fingerprint)
+);
+CREATE INDEX IF NOT EXISTS idx_pradj_pr ON pr_adjudications(pr_key);
+CREATE INDEX IF NOT EXISTS idx_pradj_srccompletion ON pr_adjudications(source_completion_id);

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.1",
   "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;