User scenario
I hosted a neighborhood mixer with dozens of guests. The next morning I want to remember the people I did not already know, so I can make a deliberate follow-up list without mistaking them for my established Partiful Mutuals.
Problem
guests list <eventId> is a host-only raw roster, while contacts list is account-wide and does not say where a relationship began. guests mutuals in #76 answers the opposite question, who I already know at an event. Neither command identifies the event attendees who are new to me.
Proposed experience
partiful events connections <eventId> --new
partiful events connections <eventId> --new --status GOING MAYBE
partiful events connections <eventId> --new --format json
Human output groups eligible attendees as "new to you" and reports excluded categories such as known Mutuals, unnamed plus-ones, and unavailable identities. JSON output preserves machine-readable counts, event metadata, each eligible display name, RSVP status, and an explicit basis describing the comparison; it must not expose user IDs in human summaries.
Scope boundaries
Read only the caller's permitted attendee and relationship data. Do not bypass event visibility, infer friendships from phone numbers, scrape social profiles, or send follow-ups. This is not invite recommendation or contact tagging.
Discovery needed
Verified repo facts: hosted-event guest reads exist; contacts list returns names, user IDs, and shared-event counts; #76 verified /getMutuals for established Mutuals. Unknown: whether a canonical attendee-visible identity read is available to non-hosts and whether prior shared-event data is sufficiently complete to define "new." Discover those capabilities before choosing the comparison source; fail closed when identities or permissions are unavailable.
Acceptance criteria
events connections <eventId> --new returns only people who can be compared through permitted, exact identities.- Human output explains the comparison basis and omission counts without printing identifiers.
- JSON output has a stable success/error envelope, event ID, counts, entries, and omission reasons.
- An empty result is successful and says no new comparable connections were found.
- Hidden rosters, permission denials, ambiguous identities, and API failures return actionable structured errors without partial private data.
- Tests cover exact joins, known-Mutual exclusion, duplicate guests, plus-ones without identities, empty lists, permission denial, and JSON output.
Related work
#76 finds known people on an attendee list; this intentionally surfaces the complementary new-to-me set after an event. #15 proposes invite suggestions and contact tags, while this is a read-only post-event reconnection outcome rather than a recommendation engine. #77-#81 may later provide local history, but they do not define this user-facing outcome.
User scenario
I hosted a neighborhood mixer with dozens of guests. The next morning I want to remember the people I did not already know, so I can make a deliberate follow-up list without mistaking them for my established Partiful Mutuals.
Problem
guests list <eventId>is a host-only raw roster, whilecontacts listis account-wide and does not say where a relationship began.guests mutualsin #76 answers the opposite question, who I already know at an event. Neither command identifies the event attendees who are new to me.Proposed experience
Human output groups eligible attendees as "new to you" and reports excluded categories such as known Mutuals, unnamed plus-ones, and unavailable identities. JSON output preserves machine-readable counts, event metadata, each eligible display name, RSVP status, and an explicit
basisdescribing the comparison; it must not expose user IDs in human summaries.Scope boundaries
Read only the caller's permitted attendee and relationship data. Do not bypass event visibility, infer friendships from phone numbers, scrape social profiles, or send follow-ups. This is not invite recommendation or contact tagging.
Discovery needed
Verified repo facts: hosted-event guest reads exist;
contacts listreturns names, user IDs, and shared-event counts; #76 verified/getMutualsfor established Mutuals. Unknown: whether a canonical attendee-visible identity read is available to non-hosts and whether prior shared-event data is sufficiently complete to define "new." Discover those capabilities before choosing the comparison source; fail closed when identities or permissions are unavailable.Acceptance criteria
events connections <eventId> --newreturns only people who can be compared through permitted, exact identities.Related work
#76 finds known people on an attendee list; this intentionally surfaces the complementary new-to-me set after an event. #15 proposes invite suggestions and contact tags, while this is a read-only post-event reconnection outcome rather than a recommendation engine. #77-#81 may later provide local history, but they do not define this user-facing outcome.