Say that a retirement decision never asks for a healer

Approving and deleting are a person's act by design (ADR 0230); S15 of to-be
45 now says it leaves them out.

02-DECISIONS/0230-a-consumer-the-mesh-stops-asking-for-is-retired-and-deleted-only-by-a-person.md

@@ -144,7 +144,9 @@ retired or deleted.
   machine through the mesh, as any module's tool is asked, and never touches a backend itself. A provider
   refuses to delete anything active or asked for, and anything not retired.
 - **Every deletion is written to the hand-act log**, as is every approval and rejection — including one
-  made by asking a provider's tool directly rather than through the controller.
+  made by asking a provider's tool directly rather than through the controller. They are a person's decision
+  by design, not a repair, so they never count toward the hand-act log's *healer wanted* (to-be 45 S15):
+  a healer may not withdraw or delete data.
 
 **7. Every provider serves the same four tools**, the protocol between the verbs and the providers:
 `provisioner_retirement` (what is held, waiting, rejected and retired), `provisioner_retire_approve`,

03-DESIGN/01-to-be/45-a-core-that-cannot-fail-silently.md

@@ -347,7 +347,9 @@ A heal is never a hand act. `healers` lists the registry, the acts and the brake
 controller), and `hand-act record` for an act done outside the mesh —
 takes a required `--why` and writes an entry: who, which verb and arguments, why, when, the condition
 key it addresses if any, and a **cause** (the condition kind, or a word the person gives). `status`
-shows the week's count. A cause recorded twice within fourteen days raises `healer-wanted` (S15).
+shows the week's count. A cause recorded twice within fourteen days raises `healer-wanted` (S15) —
+except `retire-waiting` and `cleanup-waiting`: approving a retirement and deleting what was retired are
+a person's decision by design (ADR 0230), and no healer may take them over.
 
 ## 8. Staged core upgrades and rollback (rule 8)