User scenario
I am hosting a dinner in a building with stairs, a buzzer, and a quiet room. I want to prepare a clear accessibility brief for guests before they commit, while keeping any individual accommodation requests private.
Problem
Event descriptions are unstructured plain text and current commands do not help a host identify or consistently present practical access details. Guests must message the host one by one, and an agent cannot distinguish publicly shareable venue facts from private needs.
Proposed experience
partiful events access <eventId>
partiful events access <eventId> --set "step_free=false" --set "quiet_space=true"
partiful events access <eventId> --format json
Human output renders a concise, host-reviewed public preparation brief and clearly shows unknown fields as unknown rather than assuming accessibility. JSON output has a documented schema for published facts, unknown values, source, and visibility. The exact write location is intentionally open: it might be an event description convention or a verified native event field, but must not silently overwrite unrelated details.
Scope boundaries
Never collect, infer, or expose individual disability, medical, dietary, or accommodation information. Do not certify a venue as accessible, provide emergency guidance, or make an event public. Hosts remain responsible for reviewing every published statement.
Discovery needed
Verified repo facts: event descriptions are plain text; event create/update accept descriptions and location data; no structured accessibility fields are documented in the CLI schema. Unknown: whether Partiful supports native accessibility metadata, field visibility rules, and safe partial update behavior. Verify those before any remote write. If unavailable, define a clearly marked host-controlled text/local workflow with explicit consent and retention choices.
Acceptance criteria
- A host can inspect an explicit set of preparation facts with unknown values preserved.
- Any publishing/update path previews changes and requires host confirmation before a remote mutation.
- Human and JSON output distinguish host-entered facts, unknowns, and unsupported fields.
- If no accessibility facts are documented, human output says
No accessibility information documented and JSON returns a successful unknown state, not a claim that the event is accessible.
- Non-host access respects event permissions and never reveals private host drafts.
- Invalid keys/values, unavailable native fields, and update conflicts return structured errors with no partial overwrite.
- Tests cover schema validation, unknowns, preview/confirmation, permissions, description preservation, and JSON output.
Related work
#60 concerns guest-safe location rendering, not accessibility communication. #20 concerns comments/activity, whereas this is a host-curated pre-event preparation brief. This does not add attendee profiling or analytics from #18.
User scenario
I am hosting a dinner in a building with stairs, a buzzer, and a quiet room. I want to prepare a clear accessibility brief for guests before they commit, while keeping any individual accommodation requests private.
Problem
Event descriptions are unstructured plain text and current commands do not help a host identify or consistently present practical access details. Guests must message the host one by one, and an agent cannot distinguish publicly shareable venue facts from private needs.
Proposed experience
Human output renders a concise, host-reviewed public preparation brief and clearly shows unknown fields as unknown rather than assuming accessibility. JSON output has a documented schema for published facts, unknown values, source, and visibility. The exact write location is intentionally open: it might be an event description convention or a verified native event field, but must not silently overwrite unrelated details.
Scope boundaries
Never collect, infer, or expose individual disability, medical, dietary, or accommodation information. Do not certify a venue as accessible, provide emergency guidance, or make an event public. Hosts remain responsible for reviewing every published statement.
Discovery needed
Verified repo facts: event descriptions are plain text; event create/update accept descriptions and location data; no structured accessibility fields are documented in the CLI schema. Unknown: whether Partiful supports native accessibility metadata, field visibility rules, and safe partial update behavior. Verify those before any remote write. If unavailable, define a clearly marked host-controlled text/local workflow with explicit consent and retention choices.
Acceptance criteria
No accessibility information documentedand JSON returns a successfulunknownstate, not a claim that the event is accessible.Related work
#60 concerns guest-safe location rendering, not accessibility communication. #20 concerns comments/activity, whereas this is a host-curated pre-event preparation brief. This does not add attendee profiling or analytics from #18.