From cb852abf68a74f9323db5b0b38b3e5fd5cbfaf4f Mon Sep 17 00:00:00 2001 From: seiler Date: Mon, 5 Oct 2026 21:27:19 +0000 Subject: [PATCH] docs(testing): clarify invite ban regression contract Signed-off-by: seiler Co-authored-by: Codex (cherry picked from commit 5bbf2b64a82115c40fdadeb981dbfdf7122241f2) Signed-off-by: Brad Seiler --- TESTING.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/TESTING.md b/TESTING.md index 3814536771..aec3b98162 100644 --- a/TESTING.md +++ b/TESTING.md @@ -66,9 +66,12 @@ principal to restrict. Invite claim is also pre-membership, but it carries a verified NIP-98 principal and remains restriction-enforced: it is the sole row marked pending in the inventory until BUZZ-268 qualifies the updated v1/v2 lifecycle: -retain valid unexpired v1 codes, mint only v2, reject banned claimants and -owners transactionally, permanently invalidate v2 on issuer ban, and honor the -optional absolute invalid-after boundary for v1. Legacy v1 codes have no issuer +retain valid unexpired v1 codes and mint only v2, with a 72-hour default and +30-day maximum lifetime. Both formats reject banned claimants and owners +transactionally, and issuer bans permanently invalidate v2. For v1, an unset +operator `invalid_after` uses natural expiry; when set, the code rejects at or +after that absolute boundary, while an earlier code expiry still takes effect. +That operator boundary does not affect v2. Legacy v1 codes have no issuer identity, so issuer-specific revocation remains limited until a verified fleet drain or security approval. Relay-operator APIs, deployment-admin APIs, NIP-FI commands, the localhost Git hook, and the gated mesh test endpoint use