Field-level security composes deny-wins across held positions: a platform reviewer who also holds `job_seeker` loses `verification_note` on the employer form

[claude]

Observation from #3 (card 08), sibling of #30 (which records the row-level side of the same composition).

What was measured

On the employer edit form (ats_employer.formViews.default, Verification section = verification_docs, verification_status, verification_note):

• Dev admin holding platform_admin + job_seeker — form labels: Verification*, Verification Documents — no Verification Note.
• Same user after removing the job_seeker position — form labels include Verification Note.

ats_job_seeker declares 'ats_employer.verification_note': { readable: false, editable: false } (as do both employer sets, per DESIGN.md §03 field-level security). The platform's FLS composition takes the most restrictive answer across every set the caller holds, so one seeker grant hides the platform's internal note from a platform reviewer.

Why it is worth a card

DESIGN.md §03 intends the note to be visible to platform roles and hidden from employer-side and seeker roles. That holds only while nobody holds a platform position together with a seeker/employer one. Two shapes to choose from:

• Accept and document: platform staff accounts must not also hold seeker/employer positions (an operational rule; the demo/dev admin then needs separate personas).
• Restate the masks as positive grants on the platform sets if the platform's FLS model supports allow-wins for explicit grants (needs a spec read before assuming).

Evidence: the two label dumps are in the #3 PR body; docs/evidence/issue-3/16-platform-employer-form-verification.png is the platform-only persona.

---

Generated by Claude Code