durable-agent-runtime: add pi-durable deep dive + crash/replay experiments

- new pi-durable.md: architecture (session/entry/document/task/submission),
  effect-sandwich semantics, structured concurrency, storage backends,
  maturity/adoption, taxonomy placement, implications for hermes-vm
- empirical tests on @earendil-works/pi-durable 1.3.0 (Node 22.22.2):
  kill -9 mid-phase (memo vs plain), kill -9 mid-tool (safe vs unsafe),
  SQLite schema; noted cold-open waitForTask race and the main-vs-1.3.0
  version gap (sleepUntil/onWake/restartLimit/sleeping not published)
- taxonomy: durable harness library added as a new primitive family
- sources + next-steps updated

durable-agent-runtime/analysis.md

@@ -3,13 +3,14 @@
 > Part of [[durable-agent-runtime/index|Durable Agent Runtime]]
 > Harness/loop analysis moved to [[harness-engineering/index|Harness Engineering]] (2026-08-11).
 
-## The three primitive families
+## The primitive families
 
 | Family | Example | Compute primitive | Where state lives | Cold start | Hibernation |
 | --- | --- | --- | --- | --- | --- |
 | Durable objects | celld (Deno) | V8 isolate running Worker bundles | Per-object SQLite, replicated to S3 | Fast (isolate) | Idle cells hibernate |
 | Actors | rivet | Lightweight process (Node/Bun/Deno) | In-memory + SQLite/BYO DB | ~20ms | Actors hibernate when idle |
 | VM sandboxes | hypeman, E2B | Firecracker/Cloud Hypervisor/QEMU microVM | VM disk (snapshot for standby) | ~30s VM / sub-30ms from snapshot | standby = snapshot to disk |
+| Durable harness library | pi-durable (2026) | Node process or Cloudflare Durable Object | Immutable transcript + documents + task checkpoints in SQLite/JSONL/DO storage | Reopen + reconcile (ms) | Task sleeps end the invocation; host alarm wakes (onWake on main, not in 1.3.0) |
 | Collaborative substrate | Radicle COBs | Signed, CRDT-like Git commit DAGs | Git objects (replicated, self-certifying) | Instant (local git) | Repos persist; nodes sync on demand |
 
 (Harness libraries — nanocodex, Codex, pi — moved to [[harness-engineering/index|Harness Engineering]].)
@@ -26,6 +27,12 @@ The industry convergence: **compute is disposable, state is durable elsewhere.**
 1. **Cold start latency** — the gap between "VM ~30s" and "actor ~20ms" is closed with snapshots (E2B, hypeman standby, celld/rivet hibernation) or pre-provisioned pools. This is why orbs can feel local despite being remote.
 2. **State checkpointing & recovery** — thread JSONL (Amp), SQLite replication (celld), actor state persistence (rivet), VM disk snapshots (hypeman). Everything is replayable; nothing is lost on compute failure.
 
+## Where pi-durable fits (2026-10-20)
+
+`@earendil-works/pi-durable` is not a new substrate; it is a **durable harness library** that runs on an existing one. It commits the loop's own state — immutable transcript entries, typed documents, per-phase task checkpoints, idempotent submissions — and resumes on reopen. The substrate can be a Node process with SQLite/JSONL or a Cloudflare Durable Object; tools execute through a pluggable `ExecutionEnv`, so a VM sandbox (hypeman/E2B) can sit underneath without the harness knowing.
+
+Its semantics sharpen the "compute disposable, state durable" thesis: the harness process is disposable too, but **phases are at-least-once**, not exactly-once. External effects repeat on rerun unless memoized or idempotent; tools declare `replay: "safe"` to rerun, otherwise the model gets an `interrupted` result. Only submission admission is exactly-once (`requestId`). That is a useful, honest contract to compare against Temporal-style durable execution and against our own kanban/session design. Full write-up: [[durable-agent-runtime/pi-durable|pi-durable]].
+
 ## What this means for hermes-vm (our stack)
 
 Already have (the "durable compute host" layer):
@@ -48,3 +55,5 @@ Interesting but optional:
 ## Verdict
 
 Build the **environment contracts** (setup hooks, AGENTS.md, dev-server skills, event wake) on the existing durable host. Do not build the sandbox platform or a distributed state layer. herdr + systemd + kanban + tailscale already provide the durability; the missing piece is making the environment "assume an agent and tell it where the light switches are."
+
+If we ever build a long-running, multi-client agent *service* (as opposed to cron-driven one-shot tasks), pi-durable is the closest reference implementation: one SQLite-backed Session per service, tools on `NodeExecutionEnv`, views for clients. For the Rust-core direction, treat its spec as the design input and reimplement only the commit/task/ownership semantics we actually need.