@lmzhen/dsh-evolution-approval 0.3.23 → 0.3.25
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +2 -0
- package/lib/index.js +5 -2
- package/package.json +8 -8
package/README.md
CHANGED
|
@@ -35,3 +35,5 @@ Independent of request-prefix construction. This package does not alter the asse
|
|
|
35
35
|
|
|
36
36
|
|
|
37
37
|
- `approve()` deduplicates concurrent approvals inside one process, and state providers resolve the pending record atomically. However, the replay runner executes **before** that atomic resolution, so two OS processes approving the same id can each perform the write once while only one process wins the audit transition. Run approvals from a single writer process, or make replay runners idempotent when multi-process approval is required.
|
|
38
|
+
- **Concurrent approve + reject on the same id (F-204).** Inside one process the dedupe keys are `approve:<id>` / `reject:<id>`, so the two paths are not serialized against each other. When an approve runner is slow, a reject resolves the still-executing record to `rejected` **without holding a claim**; the runner may then complete and the write can still land while the audit history reads `rejected` — the write effect, not the audit verdict, is what actually persists (`写效果以实际为准`). `reject` on an executing record reports this and asks you to verify the write state manually. Only reject a write after confirming no approve is in flight, or verify the write effect manually afterwards.
|
|
39
|
+
- **No staged-content freshness re-validation (F-328).** The staged record stores the `args` snapshot captured at request time and replays exactly those args, but does not record a content hash, so `approve()` does **not** re-check whether the on-disk skill/memory the write targets changed since staging. The write is applied as staged regardless. The pending surface (`/evolution pending --detail`) exposes the staged `args` so you can review what will actually be replayed before approving; there is no automatic drift warning if the target changed in the meantime.
|
package/lib/index.js
CHANGED
|
@@ -129,7 +129,7 @@ var EvolutionApproval = class extends Service {
|
|
|
129
129
|
if (!await this.state().claimPending(id, claimId)) {
|
|
130
130
|
if ((await this.state().listPending("executing")).find((item) => item.id === id)) return (await this.state().tryResolvePending(id, "rejected")).applied ? {
|
|
131
131
|
ok: true,
|
|
132
|
-
message: `Rejected executing write "${id}" (
|
|
132
|
+
message: `Rejected executing write "${id}" (no claim held — this may race an in-flight approve runner; if the write already landed its effect stands as-is. Verify the write state manually).`
|
|
133
133
|
} : {
|
|
134
134
|
ok: false,
|
|
135
135
|
message: `Pending write "${id}" could not be rejected: it resolved concurrently.`
|
|
@@ -238,7 +238,10 @@ function normalizeSummary(input) {
|
|
|
238
238
|
const trimmed = input.summary.length > 120 ? `${input.summary.slice(0, 117)}...` : input.summary;
|
|
239
239
|
if (input.kind === "memory") {
|
|
240
240
|
const candidate = input.args;
|
|
241
|
-
if (Array.isArray(candidate?.operations) && candidate.operations.length > 1)
|
|
241
|
+
if (Array.isArray(candidate?.operations) && candidate.operations.length > 1) {
|
|
242
|
+
const targetLabel = candidate.target ?? "memory";
|
|
243
|
+
return `memory ${targetLabel === "memory" ? "" : `${targetLabel} `}batch of ${candidate.operations.length} operations`;
|
|
244
|
+
}
|
|
242
245
|
}
|
|
243
246
|
if (input.kind === "skill" && /^skill delete /.test(trimmed)) return `${trimmed} (warning: archive)`;
|
|
244
247
|
return trimmed;
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@lmzhen/dsh-evolution-approval",
|
|
3
3
|
"description": "Stage/pending approval service for Hermes-style self-evolution writes (community build)",
|
|
4
|
-
"version": "0.3.
|
|
4
|
+
"version": "0.3.25",
|
|
5
5
|
"publishConfig": {
|
|
6
6
|
"access": "public"
|
|
7
7
|
},
|
|
@@ -35,15 +35,15 @@
|
|
|
35
35
|
"peerDependencies": {
|
|
36
36
|
"@deepseek-ai/dsh-invariants": "^0.1.1-rc.2",
|
|
37
37
|
"@deepseek-ai/cordis": "^4.0.1",
|
|
38
|
-
"@lmzhen/dsh-evolution-state-storage": "^0.3.
|
|
39
|
-
"@lmzhen/dsh-evolution-state": "^0.3.
|
|
38
|
+
"@lmzhen/dsh-evolution-state-storage": "^0.3.25",
|
|
39
|
+
"@lmzhen/dsh-evolution-state": "^0.3.25"
|
|
40
40
|
},
|
|
41
41
|
"devDependencies": {
|
|
42
42
|
"@deepseek-ai/dsh-invariants": "^0.1.1-rc.2",
|
|
43
|
-
"@lmzhen/dsh-evolution-state-storage": "^0.3.
|
|
44
|
-
"@lmzhen/dsh-evolution-state": "^0.3.
|
|
45
|
-
"@lmzhen/dsh-evolution-io": "^0.3.
|
|
46
|
-
"@lmzhen/dsh-evolution-io-node": "^0.3.
|
|
47
|
-
"@lmzhen/dsh-evolution-state-json": "^0.3.
|
|
43
|
+
"@lmzhen/dsh-evolution-state-storage": "^0.3.25",
|
|
44
|
+
"@lmzhen/dsh-evolution-state": "^0.3.25",
|
|
45
|
+
"@lmzhen/dsh-evolution-io": "^0.3.25",
|
|
46
|
+
"@lmzhen/dsh-evolution-io-node": "^0.3.25",
|
|
47
|
+
"@lmzhen/dsh-evolution-state-json": "^0.3.25"
|
|
48
48
|
}
|
|
49
49
|
}
|