Question (product/access decision — not a bug)
Participant allergies is @sensitivity:personal. Tracing where that lands:
- Program leaders DO see it.
GET /api/programs/[id] includes all Participant scalars, and the security policy grants programLeadMentor → their_program_participants:personal, so a lead running a session sees allergies for every enrolled kid. Correct for the feed-a-kid safety case.
- Keyholders / front-desk staff do NOT see it. The only participant-bearing routes a keyholder matches (
GET /api/directory/board) grant ['member','public'] — no personal band. allergies is personal, so front-desk staff never receive it.
This is fine if food/snacks are only ever served inside supervised programs (leads have allergies there). It's a safety gap if food is served in any context staffed by a keyholder/front-desk role rather than a program lead (open shop hours, drop-in, front-desk snacks).
Ask
Whoever owns front-desk / facility ops: is there any food-serving context where the responsible adult is a keyholder (not a program lead)?
- No → close; current tiering is correct.
- Yes → we need to grant the relevant role visibility of
allergies (likely a personal-band grant on a keyholder-facing participant/roster route). This is an access-policy change, not a schema-tier change.
Refs
checkin-app/prisma/schema.prisma — Participant.allergies @sensitivity:personalcheckin-app/src/app/api/programs/[id]/route.ts — includes participant scalars; lead gets their_program_participants:personalcheckin-app/src/security/registry.ts — GET /api/directory/board keyholder view is ['member','public'] only
Surfaced during a schema-sensitivity audit. Originally flagged as "health data under-tiered vs DoB"; that framing was wrong (the app's tiers are role-oriented access bands, not a severity ladder). The real residual is this possible under-exposure to food-serving staff.
Question (product/access decision — not a bug)
Participant
allergiesis@sensitivity:personal. Tracing where that lands:GET /api/programs/[id]includes all Participant scalars, and the security policy grantsprogramLeadMentor→their_program_participants:personal, so a lead running a session sees allergies for every enrolled kid. Correct for the feed-a-kid safety case.GET /api/directory/board) grant['member','public']— nopersonalband.allergiesispersonal, so front-desk staff never receive it.This is fine if food/snacks are only ever served inside supervised programs (leads have allergies there). It's a safety gap if food is served in any context staffed by a keyholder/front-desk role rather than a program lead (open shop hours, drop-in, front-desk snacks).
Ask
Whoever owns front-desk / facility ops: is there any food-serving context where the responsible adult is a keyholder (not a program lead)?
allergies(likely apersonal-band grant on a keyholder-facing participant/roster route). This is an access-policy change, not a schema-tier change.Refs
checkin-app/prisma/schema.prisma—Participant.allergies@sensitivity:personalcheckin-app/src/app/api/programs/[id]/route.ts— includes participant scalars; lead getstheir_program_participants:personalcheckin-app/src/security/registry.ts—GET /api/directory/boardkeyholder view is['member','public']onlySurfaced during a schema-sensitivity audit. Originally flagged as "health data under-tiered vs DoB"; that framing was wrong (the app's tiers are role-oriented access bands, not a severity ladder). The real residual is this possible under-exposure to food-serving staff.