User scenario
A person named Maya messages me about collaborating. Before I reply, I want to ask Partiful, "How do I know Maya?" and see the events we actually shared, rather than relying on a fuzzy name search or my memory.
Problem
contacts list "Maya" can find contact records and shared-event counts, but it does not reconstruct a relationship timeline. Event lists and exports require manual cross-checking. #15 is about selecting future invitees, not helping a user explain an existing relationship.
Proposed experience
partiful contacts history "Maya"
partiful contacts history --user-id <resolved-id> --format json
Human output resolves exact or safely disambiguated contacts, then presents shared events in date order with the caller's role where available. JSON output includes resolution candidates, the selected contact only after exact selection, shared-event entries, source freshness, and a deterministic empty history state. A name query with several matches must ask for selection through a non-mutating candidate result rather than guessing.
Scope boundaries
Do not reveal emails, phone numbers, hidden events, or another person's private attendance. Do not score closeness, recommend invitations, alter contacts, or search third-party data. Only caller-authorized Partiful data may contribute.
Discovery needed
Verified repo facts: contacts expose names, IDs, and shared-event counts but not emails or phones; event summaries expose IDs and dates; #76 verified Mutual records contain a sharedEvent summary. Unknown: whether the API can enumerate all shared events for a selected contact and what permission rules apply to each historical event. Verify a canonical read path and pagination before promising a complete history; otherwise report the result as partial or unavailable.
Acceptance criteria
- Exact selected contacts yield a chronological, privacy-respecting relationship history when source data permits.
- Ambiguous names return machine-readable candidates and no automatic selection.
- Human output avoids raw Partiful user IDs; JSON retains only identifiers already permitted by the CLI contract.
- No shared history is a successful, explicit empty state.
- Permission, pagination, source-unavailable, and stale/partial-history conditions are distinguishable structured errors or metadata.
- Tests cover exact matching, ambiguity, duplicate names, ordering, zero history, pagination, hidden events, and JSON schema stability.
Related work
#15 uses contact history for future invite suggestions; this is a user-controlled answer to "how do I know this person?" #76 intersects Mutuals with one event, while this spans a chosen contact's shared-event history. #77-#81 may support cached reads later but do not replace live privacy checks.
User scenario
A person named Maya messages me about collaborating. Before I reply, I want to ask Partiful, "How do I know Maya?" and see the events we actually shared, rather than relying on a fuzzy name search or my memory.
Problem
contacts list "Maya"can find contact records and shared-event counts, but it does not reconstruct a relationship timeline. Event lists and exports require manual cross-checking. #15 is about selecting future invitees, not helping a user explain an existing relationship.Proposed experience
Human output resolves exact or safely disambiguated contacts, then presents shared events in date order with the caller's role where available. JSON output includes resolution candidates, the selected contact only after exact selection, shared-event entries, source freshness, and a deterministic empty history state. A name query with several matches must ask for selection through a non-mutating candidate result rather than guessing.
Scope boundaries
Do not reveal emails, phone numbers, hidden events, or another person's private attendance. Do not score closeness, recommend invitations, alter contacts, or search third-party data. Only caller-authorized Partiful data may contribute.
Discovery needed
Verified repo facts: contacts expose names, IDs, and shared-event counts but not emails or phones; event summaries expose IDs and dates; #76 verified Mutual records contain a
sharedEventsummary. Unknown: whether the API can enumerate all shared events for a selected contact and what permission rules apply to each historical event. Verify a canonical read path and pagination before promising a complete history; otherwise report the result as partial or unavailable.Acceptance criteria
Related work
#15 uses contact history for future invite suggestions; this is a user-controlled answer to "how do I know this person?" #76 intersects Mutuals with one event, while this spans a chosen contact's shared-event history. #77-#81 may support cached reads later but do not replace live privacy checks.