@lmzhen/dsh-evolution-approval 0.3.80 → 0.3.82

package/lib/index.js

@@ -1,5 +1,6 @@
 import { Service } from "@deepseek-ai/cordis";
 import { randomUUID } from "node:crypto";
+import { isProcessAlive, parseLockBody } from "@lmzhen/dsh-evolution-core";
 import z from "@deepseek-ai/schemastery";
 //#region lib/types/index.js
 /**
@@ -135,14 +136,25 @@ var EvolutionApproval = class extends Service {
 		return await this.dedupe(`approve:${id}`, () => this.doApprove(id));
 	}
 	/** S2-P2-22 (0.3.80): return an ORPHANED executing record to the pending
-	* window. "Orphaned" = status `executing` with no approve running in THIS
-	* process (the family single-instance claim rules out any other live
-	* process, so a claim that is not in this service's in-flight dedupe map
-	* belongs to a dead one). The stored `claimedBy` rides along as the seam's
-	* release credential, so no state-seam expansion is needed. The operator is
-	* expected to verify the effect first: re-approving replays the write
-	* deliberately (duplicates possible if the effect already landed);
-	* rejecting closes the record. */
+	* window. "Orphaned" is DECIDED here, never assumed: the older rationale
+	* ("the family single-instance claim rules out any other live process") was
+	* wrong (v43 FLOW2-1) — that claim is a module-scope Map in
+	* core/instance-scope.ts, i.e. PER PROCESS, so a second process over one home
+	* is not excluded at all. Two checks stand in its place:
+	* 1. `inFlight` — an approve/reject running in THIS service instance;
+	* 2. the claim's holder pid. Claim ids are minted as `<pid>:<hex token>`, the
+	*    same body shape the io write lock uses, so `parseLockBody` + the core
+	*    `isProcessAlive` probe answer whether that holder can still be running: a
+	*    LIVE FOREIGN pid REFUSES the release; our own pid is this process's
+	*    leftover (a live in-process approve is what `inFlight` covers); a dead pid
+	*    is a crash. The last two are releasable, which is the S2-P2-22 case.
+	* A claim carrying no pid (the bare-UUID claims minted before this change)
+	* cannot be probed: the release then degrades to an explicitly DESTRUCTIVE
+	* operator action and says so — re-approving replays the write, and that
+	* replay is NOT idempotent if the effect already landed. The operator is
+	* expected to verify the effect first; rejecting closes the record instead
+	* (the stored `claimedBy` rides along as the seam's release credential, so no
+	* state-seam expansion is needed). */
 	async release(id) {
 		const executing = (await this.state().listPending("executing")).find((item) => item.id === id);
 		if (!executing) {
@@ -164,15 +176,32 @@ var EvolutionApproval = class extends Service {
 			ok: false,
 			message: `Pending write "${id}" carries no claim to release (unexpected record shape) — reject it instead.`
 		};
-		await this.state().releasePendingClaim(id, claimId);
+		const holderPid = parseLockBody(claimId);
+		if (holderPid !== null && holderPid !== process.pid && isProcessAlive(holderPid)) return {
+			ok: false,
+			message: `Pending write "${id}" is claimed by pid ${holderPid}, which is ALIVE — another process may be running this approve. Do not release it: verify the write effect instead and let that run finish (a completed approve resolves its own record).`
+		};
+		let released = false;
+		let failure = "";
+		try {
+			await this.state().releasePendingClaim(id, claimId);
+			released = (await this.state().listPending("pending")).some((item) => item.id === id);
+		} catch (error) {
+			failure = error instanceof Error ? error.message : String(error);
+			this.ctx.logger.warn(error);
+		}
+		if (!released) return {
+			ok: false,
+			message: `Release of "${id}" did not take effect (${failure === "" ? "the claim no longer matches the record — a concurrent writer moved it" : failure}) — it stays EXECUTING with its claim unless it resolved, and the write effect is still unverified. Retry, or reject it to close the record without replaying.`
+		};
 		return {
 			ok: true,
-			message: `Released "${id}" back to the pending window. VERIFY the effect first: approve re-runs the write deliberately (duplicates possible if the effect already landed); reject closes the record.`
+			message: `Released "${id}" back to the pending window.${holderPid === null ? " Its claim carries no pid, so liveness could NOT be verified: another process may still be running this approve." : ""} VERIFY the effect before approving: approve re-runs the write, and a non-idempotent replay duplicates an effect that already landed; reject closes the record instead.`
 		};
 	}
 	async reject(id) {
 		return await this.dedupe(`reject:${id}`, async () => {
-			const claimId = randomUUID();
+			const claimId = this.newClaimId();
 			if (!await this.state().claimPending(id, claimId)) {
 				if ((await this.state().listPending("executing")).find((item) => item.id === id)) return (await this.state().tryResolvePending(id, "rejected")).applied ? {
 					ok: true,
@@ -217,6 +246,15 @@ var EvolutionApproval = class extends Service {
 		if (override === "never" || override === "ask") return override;
 		return platformApproval.config?.policy ?? "ask";
 	}
+	/** v43 FLOW2-1: a claim id that CARRIES its holder pid — `parseLockBody`
+	* reads it back and `isProcessAlive` turns it into `release()`'s verifiable
+	* orphan criterion. The `<pid>:<hex token>` body is the io write lock's own
+	* shape, so one set of core helpers reads both; the token stays unique per
+	* call, so two approves of one record can never share a claim (the token is a
+	* dashed UUID stripped to hex because `LOCK_BODY_RE` accepts only hex). */
+	newClaimId() {
+		return `${process.pid}:${randomUUID().split("-").join("")}`;
+	}
 	dedupe(id, task) {
 		const existing = this.inFlight.get(id);
 		if (existing) return existing;
@@ -227,7 +265,7 @@ var EvolutionApproval = class extends Service {
 		return run;
 	}
 	async doApprove(id) {
-		const claimId = randomUUID();
+		const claimId = this.newClaimId();
 		const record = await this.state().claimPending(id, claimId);
 		if (!record) {
 			if ((await this.state().listPending("executing")).find((item) => item.id === id)) return {

package/lib/types/index.d.ts

@@ -97,7 +97,11 @@ export type ApprovalLike = {
     }>;
     /** S2-P2-22 (0.3.80): return an ORPHANED executing record (an approve that
      * crashed mid-run) to the pending window, so it can be deliberately
-     * re-approved or rejected. Optional: only the real service implements it. */
+     * re-approved or rejected. v43 FLOW2-1: "orphaned" is DECIDED — from this
+     * process's in-flight set AND the holder pid the record's claim carries — so a
+     * claim naming a live foreign pid is REFUSED, and a claim without a pid is
+     * released only as an explicitly destructive operator action. Optional: only
+     * the real service implements it. */
     release?(id: string): Promise<{
         ok: boolean;
         message: string;
@@ -164,14 +168,25 @@ export declare class EvolutionApproval extends Service {
         message: string;
     }>;
     /** S2-P2-22 (0.3.80): return an ORPHANED executing record to the pending
-     * window. "Orphaned" = status `executing` with no approve running in THIS
-     * process (the family single-instance claim rules out any other live
-     * process, so a claim that is not in this service's in-flight dedupe map
-     * belongs to a dead one). The stored `claimedBy` rides along as the seam's
-     * release credential, so no state-seam expansion is needed. The operator is
-     * expected to verify the effect first: re-approving replays the write
-     * deliberately (duplicates possible if the effect already landed);
-     * rejecting closes the record. */
+     * window. "Orphaned" is DECIDED here, never assumed: the older rationale
+     * ("the family single-instance claim rules out any other live process") was
+     * wrong (v43 FLOW2-1) — that claim is a module-scope Map in
+     * core/instance-scope.ts, i.e. PER PROCESS, so a second process over one home
+     * is not excluded at all. Two checks stand in its place:
+     * 1. `inFlight` — an approve/reject running in THIS service instance;
+     * 2. the claim's holder pid. Claim ids are minted as `<pid>:<hex token>`, the
+     *    same body shape the io write lock uses, so `parseLockBody` + the core
+     *    `isProcessAlive` probe answer whether that holder can still be running: a
+     *    LIVE FOREIGN pid REFUSES the release; our own pid is this process's
+     *    leftover (a live in-process approve is what `inFlight` covers); a dead pid
+     *    is a crash. The last two are releasable, which is the S2-P2-22 case.
+     * A claim carrying no pid (the bare-UUID claims minted before this change)
+     * cannot be probed: the release then degrades to an explicitly DESTRUCTIVE
+     * operator action and says so — re-approving replays the write, and that
+     * replay is NOT idempotent if the effect already landed. The operator is
+     * expected to verify the effect first; rejecting closes the record instead
+     * (the stored `claimedBy` rides along as the seam's release credential, so no
+     * state-seam expansion is needed). */
     release(id: string): Promise<{
         ok: boolean;
         message: string;
@@ -190,6 +205,13 @@ export declare class EvolutionApproval extends Service {
      * check is lazy: the platform service can start before or after this plugin.
      */
     private deriveSessionPolicy;
+    /** v43 FLOW2-1: a claim id that CARRIES its holder pid — `parseLockBody`
+     * reads it back and `isProcessAlive` turns it into `release()`'s verifiable
+     * orphan criterion. The `<pid>:<hex token>` body is the io write lock's own
+     * shape, so one set of core helpers reads both; the token stays unique per
+     * call, so two approves of one record can never share a claim (the token is a
+     * dashed UUID stripped to hex because `LOCK_BODY_RE` accepts only hex). */
+    private newClaimId;
     private dedupe;
     private doApprove;
 }

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@lmzhen/dsh-evolution-approval",
   "description": "Stage/pending approval service for Hermes-style self-evolution writes (community build)",
-  "version": "0.3.80",
+  "version": "0.3.82",
   "publishConfig": {
     "access": "public"
   },
@@ -26,15 +26,17 @@
   ],
   "license": "MIT",
   "dependencies": {
-    "@deepseek-ai/schemastery": "^3.18.1"
+    "@deepseek-ai/schemastery": "^3.18.1",
+    "@lmzhen/dsh-evolution-core": "^0.3.82"
   },
   "peerDependencies": {
     "@deepseek-ai/cordis": "^4.0.1",
-    "@lmzhen/dsh-evolution-state-storage": "^0.3.80",
-    "@lmzhen/dsh-evolution-state": "^0.3.80"
+    "@lmzhen/dsh-evolution-state-storage": "^0.3.82",
+    "@lmzhen/dsh-evolution-state": "^0.3.82"
   },
   "devDependencies": {
-    "@lmzhen/dsh-evolution-state-storage": "^0.3.80",
-    "@lmzhen/dsh-evolution-state": "^0.3.80"
+    "@lmzhen/dsh-evolution-core": "^0.3.82",
+    "@lmzhen/dsh-evolution-state-storage": "^0.3.82",
+    "@lmzhen/dsh-evolution-state": "^0.3.82"
   }
 }