Signals over IPC, one-shot timers, and the service harness (M17.4)

Signals are statements delivered as coalescing notifications to the
endpoint a process nominates with signal_bind — never a hijacked stack,
never a question (liveness is the zero-length ping the harness answers).
process_signal is supervisor-or-self gated, like kill; unbound targets
accumulate a pending mask delivered on bind. timer_bind is the missing
timed wait: a one-shot deadline landing in the same replyWait as
everything else — what stop(), hello deadlines, and restart backoff are
built from. runtime.service.run folds requests, signals, and
notifications into callbacks; the VFS conversion deletes its hand-rolled
loop and gains the whole lifecycle contract. The signals scenario drives
ping, reload, terminate->exited, the timer, and the deaf-child
deadline->killed path from ring 3. docs/process-lifecycle.md increments
1-4 are now as-built.

docs/ipc.md

@@ -103,3 +103,22 @@ This is what makes a user-space driver possible at all, and it's the subject of
   the oldest (discrete messages, not a coalescing level like the notification ring).
 - **A bounded reply.** `MSG_MAX` is 256 bytes and the copy runs under the big kernel
   lock; a bulk transfer wants shared pages, not a copy.
+
+## Lifecycle conventions over IPC (M17)
+
+Three conventions from [process-lifecycle.md](process-lifecycle.md) ride the
+notification mechanism:
+
+- **Signals** arrive as notifications on the endpoint a process nominated with
+  `signal_bind` (`runtime.process.bindSignals`): badge = the signal bit plus the
+  coalesced pending mask (`runtime.process.signalsFrom` decodes). Statements,
+  never questions; no payload, no reply.
+- **One-shot timers** (`timer_bind`, `runtime.system.timerOnce`) land as a
+  timer-bit notification — the timed wait: a service arms a deadline and keeps
+  serving, instead of blocking in sleep.
+- **The universal ping**: a **zero-length request is the liveness probe**,
+  answered with a zero-length reply by the service harness itself
+  (`runtime.service.run`). No protocol's requests start at length zero, so the
+  encoding cannot collide, and a wedged service simply fails to answer — which
+  is the diagnosis. Deep health ("can I reach my hardware?") stays a per-service
+  protocol message.

docs/m17-m18-plan.md

@@ -39,7 +39,11 @@ only when its definition of green holds.
       bounded ref-counted table, publish on every death;
       `runtime.process.subscribeExits`; VFS handles carry owners and are swept on
       the owner's death; `vfs-client-death` test; suite 50/50)
-- [ ] **M17.4** — signals, timer notifications, `runtime.process`, the service harness
+- [x] **M17.4** — signals, timer notifications, `runtime.process`, the service
+      harness (signal_bind/process_signal + coalescing pending mask; timer_bind
+      on the tick; bindSignals/signalsFrom/sendSignal/stop + timerOnce;
+      runtime.service.run with the zero-length ping; VFS converted; `signals`
+      scenario; suite 51/51)
 - [ ] **merge** `feat/process-lifecycle` → main, push
 - [ ] **M18.1** — device-manager protocol: hello + restart policy (branch `feat/device-manager`)
 - [ ] **merge** `feat/device-manager` → main, push

docs/process-lifecycle.md

@@ -1,6 +1,9 @@
 # Process lifecycle: signals over IPC
 
-**Status: design.** The primitives underneath are built ([process-management.md](process-management.md):
+**Status: increments 1–4 built** (2026-07-12): claim release on death, exit
+reasons, published exit events, and signals + one-shot timers + the service
+harness are all in — the interface below is as-built. The primitives underneath
+predate this design ([process-management.md](process-management.md):
 spawn, the supervision link, kill, child-exit notifications); this document designs
 the layer above them — the standard vocabulary a danos process speaks about its own
 life, and the stable `runtime.process` interface that carries it. Nothing here is