User scenario
After a great dinner party, I want to save a short private recap: what worked, who I meant to follow up with, and one memory tied to the event. Months later, I should be able to revisit that recap before hosting again without treating Partiful attendance data as a social score.
Problem
The CLI can export event and guest data, but it has no intentional, privacy-aware place for the host's own post-event reflection. Notes end up scattered in unrelated tools, and #15 focuses on invite suggestions rather than preserving a user's own recollection.
Proposed experience
partiful events recap <eventId>
partiful events recap <eventId> --add-note "The patio heaters worked well"
partiful events recap <eventId> --format json
Human output combines immutable event context with clearly separate private notes, follow-up reminders phrased by the user, and retention status. JSON output identifies the event, note metadata, local/remote source, and safe empty states. Adding a note must be an explicit local write and never be posted as an event comment or message.
Scope boundaries
Private notes belong to the caller, not guests. Do not automatically infer sentiments, rank people, scrape messages, expose attendee identities in summaries, send reminders, or sync notes off-device without explicit approved configuration. This is not #20 comments/activity, #15 invite intelligence, or a cloud journal.
Discovery needed
Verified repo facts: event details and exports exist; #20 proposes public event comments/activity; #77-#81 are only planning a local mirror and have deferred retention decisions. Unknown: whether the project wants a local notes store, how deletion/export/encryption should work, and whether event deletion should cascade. Do not assume a Partiful notes API or remote storage capability.
Acceptance criteria
- A user can read an empty recap and create/edit/delete their own explicit private notes without remote event mutation.
- Human output clearly separates Partiful event facts from locally authored content.
- JSON includes source, retention/deletion metadata, and deterministic empty states.
- Event access loss does not expose cached attendee data; any retained local recap behavior is disclosed.
- Invalid event IDs, unavailable source event, local-store failures, and ambiguous note selectors return structured errors.
- Tests cover empty/create/edit/delete, redaction, retention/deletion, source separation, access loss, and JSON schema.
Related work
#20 is public interaction on an event, while this is private reflection. #15 uses data to suggest future guests; this preserves user-authored memories without recommendations. #77-#81 may establish a storage foundation later but should not silently decide recap privacy or retention.
User scenario
After a great dinner party, I want to save a short private recap: what worked, who I meant to follow up with, and one memory tied to the event. Months later, I should be able to revisit that recap before hosting again without treating Partiful attendance data as a social score.
Problem
The CLI can export event and guest data, but it has no intentional, privacy-aware place for the host's own post-event reflection. Notes end up scattered in unrelated tools, and #15 focuses on invite suggestions rather than preserving a user's own recollection.
Proposed experience
Human output combines immutable event context with clearly separate private notes, follow-up reminders phrased by the user, and retention status. JSON output identifies the event, note metadata, local/remote source, and safe empty states. Adding a note must be an explicit local write and never be posted as an event comment or message.
Scope boundaries
Private notes belong to the caller, not guests. Do not automatically infer sentiments, rank people, scrape messages, expose attendee identities in summaries, send reminders, or sync notes off-device without explicit approved configuration. This is not #20 comments/activity, #15 invite intelligence, or a cloud journal.
Discovery needed
Verified repo facts: event details and exports exist; #20 proposes public event comments/activity; #77-#81 are only planning a local mirror and have deferred retention decisions. Unknown: whether the project wants a local notes store, how deletion/export/encryption should work, and whether event deletion should cascade. Do not assume a Partiful notes API or remote storage capability.
Acceptance criteria
Related work
#20 is public interaction on an event, while this is private reflection. #15 uses data to suggest future guests; this preserves user-authored memories without recommendations. #77-#81 may establish a storage foundation later but should not silently decide recap privacy or retention.