@lmzhen/dsh-evolution-activity 0.3.18 → 0.3.20
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 +10 -3
- package/package.json +5 -5
package/README.md
CHANGED
|
@@ -1,6 +1,10 @@
|
|
|
1
1
|
# @deepseek-ai/dsh-evolution-activity
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
Durable activity store for self-evolution plan outcomes
|
|
4
|
+
|
|
5
|
+
## What it does
|
|
6
|
+
|
|
7
|
+
Subscribes to the process event `evolution/plan-applied` (payload v2, with sessionId) and persists every plan outcome to `$DSH_HOME/evolution/activity.json` through the evolution IO seam — the same best-effort sidecar posture as `feedback.json` and the curator reports. The sidecar is append-merge (load → fold → save under an in-process queue), so records survive host restarts and are readable without a session. The retired session projection is gone: a session log carrying `evolution/*` types is refused wholesale at resume, so plan-outcome durability lives here instead. A storage-domain table is deferred until a consumer needs domain routing.
|
|
4
8
|
|
|
5
9
|
## Model Experience
|
|
6
10
|
|
|
@@ -18,8 +22,11 @@ Zero direct token effect from this package; consumers add any model-visible toke
|
|
|
18
22
|
|
|
19
23
|
Independent of request-prefix construction. This package does not alter the assembled prompt or tool list.
|
|
20
24
|
|
|
25
|
+
## Configuration
|
|
26
|
+
|
|
27
|
+
- `maxItems`: bound on the retained activity sidecar (default `DEFAULT_MAX_ITEMS = 200`). A non-finite value falls back to the default (0.3.19, S6.4 guard).
|
|
28
|
+
|
|
21
29
|
## Known Limitations and Deferred Work
|
|
22
30
|
|
|
23
31
|
|
|
24
|
-
-
|
|
25
|
-
- On 0.1.1+ hosts the cold-read path (`restore`) calls `stateSchema.parse` on checkpointed rows; a registration missing `stateSchema` would throw on the first cold read, so the new half is load-bearing, not cosmetic.
|
|
32
|
+
- Each event lands through `transactIo` (like `feedback.json`), so append cycles are cross-process atomic at the single-write granularity; the read-modify-write of one event is serialized in-process and atomic on disk. A multi-record batch is still one event at a time — no batch transaction exists.
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@lmzhen/dsh-evolution-activity",
|
|
3
3
|
"description": "Session projection for self-evolution activity (community build)",
|
|
4
|
-
"version": "0.3.
|
|
4
|
+
"version": "0.3.20",
|
|
5
5
|
"publishConfig": {
|
|
6
6
|
"access": "public"
|
|
7
7
|
},
|
|
@@ -33,7 +33,7 @@
|
|
|
33
33
|
"license": "MIT",
|
|
34
34
|
"dependencies": {
|
|
35
35
|
"@deepseek-ai/schemastery": "^3.18.1",
|
|
36
|
-
"@lmzhen/dsh-evolution-core": "^0.3.
|
|
36
|
+
"@lmzhen/dsh-evolution-core": "^0.3.20"
|
|
37
37
|
},
|
|
38
38
|
"peerDependencies": {
|
|
39
39
|
"@deepseek-ai/cordis": "^4.0.1",
|
|
@@ -42,8 +42,8 @@
|
|
|
42
42
|
"devDependencies": {
|
|
43
43
|
"@deepseek-ai/cordis": "^4.0.1",
|
|
44
44
|
"@deepseek-ai/dsh-invariants": "^0.1.1-rc.2",
|
|
45
|
-
"@lmzhen/dsh-evolution-core": "^0.3.
|
|
46
|
-
"@lmzhen/dsh-evolution-io": "^0.3.
|
|
47
|
-
"@lmzhen/dsh-evolution-io-node": "^0.3.
|
|
45
|
+
"@lmzhen/dsh-evolution-core": "^0.3.20",
|
|
46
|
+
"@lmzhen/dsh-evolution-io": "^0.3.20",
|
|
47
|
+
"@lmzhen/dsh-evolution-io-node": "^0.3.20"
|
|
48
48
|
}
|
|
49
49
|
}
|