User scenario
I am hosting a small workshop and greeting people at the door. I need a simple, privacy-safe roster that lets me mark arrivals on my own device and later see who has checked in, without turning Partiful RSVPs into a public attendance record.
Problem
guests list shows RSVP status and +watch emits volatile RSVP changes, but neither gives a host an operational arrival view. Paper lists are awkward, and an RSVP is not evidence that someone arrived.
Proposed experience
partiful guests checkin <eventId>
partiful guests checkin <eventId> --mark "Alex Kim"
partiful guests checkin <eventId> --format json
Human output presents a host-only roster with RSVP context and explicit locally recorded check-in state. JSON output includes event metadata, eligible entries, check-in timestamps only when the host has recorded them, and a clear storage/source indicator. Name matches must fail closed with candidates when ambiguous.
Scope boundaries
Check-in is an opt-in host workflow, never a claim that Partiful or a guest consented to attendance tracking. Do not expose the roster to attendees, use biometrics/location, message guests, modify their RSVP, or upload local check-in notes without an explicit separately verified capability.
Discovery needed
Verified repo facts: hosted-event guest reads are permission-gated; guest records include names and RSVP status; +watch is polling and volatile. Unknown: whether Partiful has any canonical attendance/check-in write path. Do not assume one. If none exists, make local-only retention, deletion, encryption, and multi-device behavior an explicit product decision before implementation.
Acceptance criteria
- Only an authorized host can open a roster based on existing guest permissions.
- Marking an arrival is explicit and reversible, with no remote mutation unless a verified canonical capability is chosen later.
- Ambiguous/missing names, permission denial, and write/storage errors are structured and do not mark the wrong person.
- Human output minimizes personal data; JSON states source, retention status, and check-in state deterministically.
- Empty rosters and no check-ins are successful, clear states.
- Tests cover host authorization, name ambiguity, idempotent/reversible marks, deletion/retention behavior, remote-write absence, and JSON output.
Related work
#18 includes high-level attendance analytics but does not provide a live door workflow. +watch observes RSVP changes, which are distinct from arrivals. #77-#81 may inform safe local storage later but do not authorize local attendance tracking by themselves.
User scenario
I am hosting a small workshop and greeting people at the door. I need a simple, privacy-safe roster that lets me mark arrivals on my own device and later see who has checked in, without turning Partiful RSVPs into a public attendance record.
Problem
guests listshows RSVP status and+watchemits volatile RSVP changes, but neither gives a host an operational arrival view. Paper lists are awkward, and an RSVP is not evidence that someone arrived.Proposed experience
Human output presents a host-only roster with RSVP context and explicit locally recorded check-in state. JSON output includes event metadata, eligible entries, check-in timestamps only when the host has recorded them, and a clear storage/source indicator. Name matches must fail closed with candidates when ambiguous.
Scope boundaries
Check-in is an opt-in host workflow, never a claim that Partiful or a guest consented to attendance tracking. Do not expose the roster to attendees, use biometrics/location, message guests, modify their RSVP, or upload local check-in notes without an explicit separately verified capability.
Discovery needed
Verified repo facts: hosted-event guest reads are permission-gated; guest records include names and RSVP status;
+watchis polling and volatile. Unknown: whether Partiful has any canonical attendance/check-in write path. Do not assume one. If none exists, make local-only retention, deletion, encryption, and multi-device behavior an explicit product decision before implementation.Acceptance criteria
Related work
#18 includes high-level attendance analytics but does not provide a live door workflow.
+watchobserves RSVP changes, which are distinct from arrivals. #77-#81 may inform safe local storage later but do not authorize local attendance tracking by themselves.