docs(testing): distinguish invite policy from implementation

Signed-off-by: Local Builder <1c476cb1127ea270cb900bdc3891060140bdd1173f91498030ee9b4db01c2f20@buzz.block.builderlab.xyz>
This commit is contained in:
Local Builder
2026-10-11 22:59:59 -04:00
parent 94c9ce5f47
commit dda7ef8815

View File

@@ -65,9 +65,10 @@ The inventory keeps membership separate from restriction policy. Public NIP-11,
NIP-05, policy documents, and health probes have no authenticated community
principal. Anonymous policy-receipt acceptance is pre-membership and has no
principal to restrict. Invite claim is also pre-membership, but it carries a
verified NIP-98 principal and remains restriction-enforced: its coverage remains
pending in the inventory until BUZZ-268 lands and qualifies the updated
v1/v2 lifecycle. After BUZZ-268 lands, the intended contract is to retain valid
verified NIP-98 principal and is classified as restriction-enforced in the
inventory. Enforcement will land with BUZZ-268; coverage remains pending until
that sibling lands and qualifies the updated v1/v2 lifecycle. After BUZZ-268
lands, the intended contract is to retain valid
unexpired v1 codes and mint only v2, with a 72-hour default and 30-day maximum
lifetime. Both formats will reject banned claimants and owners transactionally,
and issuer bans will permanently invalidate v2. For v1, an unset operator