Add privacy-safe event-contextual Crush discovery and sending

[KalebCole]

User scenario

I am viewing an event and want to find an eligible Mutual, send them a private Crush, and learn only whether it becomes a mutual match. I should not have to expose the event roster or weaken Partiful's anonymity rules to use the CLI.

Problem

Crush is an event-contextual, app-only social feature. The CLI has no candidate discovery, send operation, monthly quota, match state, notification preference, or host setting. contacts list can return Mutuals and shared-event counts, but it is not a verified Crush eligibility source. guests list is host-only and cannot serve as a privacy bypass for attendees.

Verified product behavior

Partiful's current first-party documentation says:

• users may Crush a Mutual, meaning someone with whom they have attended an event;
• the recipient receives an anonymous notification;
• the notification may identify the last shared event;
• Partiful suppresses the shared event when it is small enough to reveal the sender;
• identities are revealed only after the recipient sends a Crush back;
• users can send up to 10 Crushes per month;
• hosts can disable guest Crushes for an event;
• Crush is currently available in the Partiful app.

Current web code exposes Crush notification types and the event field disableCrush. It does not expose a complete candidate or send protocol. Guessed read operations returned 404 and are not a contract. No Crush was sent during investigation.

Sources:

• https://partiful.com/crush
• https://help.partiful.com/hc/en-us/articles/45086026179483-How-does-Crush-work
• https://help.partiful.com/hc/en-us/articles/45361534853019-How-can-I-tell-which-event-my-Crush-attended

Proposed experience

Exact names remain subject to mobile API capture:

partiful crush candidates --event <eventId> --query "name"
partiful crush send --event <eventId> --user-id <id> --dry-run
partiful crush status
partiful events update <eventId> --allow-crushes
partiful events update <eventId> --disable-crushes

crush status should expose only safe account state such as remaining quota and server-confirmed matches whose identities Partiful has already revealed. It must never list incoming anonymous senders.

Scope boundaries

• Preserve server eligibility, block state, event-size privacy, monthly limits, and match transitions.
• Never infer an anonymous sender from event attendance, notification timing, roster size, or local history.
• Never expose a received-Crush list before a server-confirmed mutual match.
• Require exact target resolution, confirmation, and --dry-run for sends.
• Host enable/disable is an event setting and requires host permission plus read-back.
• Turning off Crush notifications must not be described as preventing incoming Crushes unless the product proves that behavior.
• Do not implement guessed endpoint names or payloads.

Discovery needed

Capture the mobile app's canonical event selection, candidate listing/search, send request, response, quota, cancellation if any, pending state, match transition, notification preference, host-setting update, idempotency, and error contracts. Verify whether a Crush can be canceled, repeated, or redirected, and what happens after a block or event setting change.

Acceptance criteria

• Candidate discovery uses only Partiful's canonical eligibility response and respects event and roster privacy.
• Users can search eligible candidates without exposing hidden attendees or internal IDs in normal output.
• crush send requires exact selection, confirmation, and supports a zero-mutation --dry-run.
• Send results reveal no more than Partiful's app reveals at that state.
• Monthly quota and safe pending/match state are machine-readable when the server provides them.
• Anonymous incoming Crushes remain anonymous until a server-confirmed mutual match.
• Hosts can read and change the event's Crush setting with permission checks and read-back.
• Empty candidates, disabled events, ineligible targets, limits, blocks, duplicates, and state conflicts produce structured results or errors.
• CLI help, schemas, privacy-focused unit tests, and a controlled E2E plan with explicit participants ship together.

Related work

#76 owns the general task of intersecting Mutuals with a visible attendee list. Crush may depend on its discovery work, but it must use the stricter server-provided Crush eligibility contract rather than treating every visible Mutual as eligible. The Block List issue owns durable account blocking, which Crush must honor without trying to infer its implementation.