fix: removing someone who never redeemed their invitation

A member row appears only when a code is consumed, so revoking someone
invited to the wrong group was refused for having no row — and the node's
refusal aborted the browser's removal before its hub half, leaving them a
member everywhere with a live code. Revoking now cancels unredeemed codes
for that group, and a node refusal no longer cancels the hub removal.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 19 insertions, 0 deletions

diff --git a/CLAUDE.md b/CLAUDE.md
index f0f90d5..928d526 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -438,6 +438,25 @@ do. Read them before writing anything that touches the same mechanism.
   waits for a reply already delivered elsewhere. A reply needs an identifier
   the protocol guarantees, not a field it happens to have
 
+- **One errand, two halves, and the first one's refusal cancelled the second.**
+  Removing a member is the node half (stop wrapping the group key) then the hub
+  half (stop them reaching the node at all), in that order because it fails
+  safe. The node call was not guarded, so anything it refused ended the whole
+  callback — and it refused the commonest case there is: a person invited to
+  the wrong group has no member row on the node, only an unredeemed code, so
+  `set_status` matched nothing and answered "no such member in that group".
+  The removal never reached the hub. They stayed a member in the list (the hub
+  answers it), in the owner's other sessions and in the administrator's view,
+  the code emailed to them stayed live for its seven days, and the interface
+  offered no second way to take back either — the same button, every time,
+  reporting that the person it was listing was not there. Two rules, and the
+  second is the one that generalises: **a half that only ever removes access is
+  not the half to skip when the other is in doubt** — report the refusal after
+  doing what can be done, never instead of it; and **an operation that is
+  refused for the state it was invented to fix is not a refusal, it is a
+  missing case**. `test_member_removal.py` holds the seam, and the node tests
+  hold the case
+
 - **A refusal that never rejects.** Denying Chromium's `fullscreen` permission
   does not make `requestFullscreen()` throw — the promise never settles. The
   deny-everything handler was written from a true sentence ("nothing here needs