MC form: lockable Yes/No toggles for every service section (locked on / locked off)

[rlho]

Desired toggle state per room × service

Room	Furniture	Equipment	Staffing	Catering	Cleaning	Campus Safety
103 Garage	toggle	locked on + details required	locked on + radio required (all options, incl. No technician / Plug & Play, count as a staffing request)	toggle	toggle (dynamic lock while catering = yes)	toggle
202 Lecture Hall	toggle	❓ pending V2	—	none on 202 itself (static "food is not permitted" blurb; catering lives on the 205 Student Lounge annex)	toggle (no lock)	toggle
220 Black Box	locked off (description only: included furniture + link, no fields)	❓ conflict — testing notes say "add equipment toggle", meeting said equipment is not offered here (locked off?)	—	toggle	toggle (dynamic lock)	toggle
221–224 Ballrooms	same as 220	same as 220	—	toggle	toggle (dynamic lock)	toggle
230 Sony Audio Institute Studio	—	locked on + details required	locked on + radio required (2 Audio Tech options starred)	toggle	toggle	toggle
233 Co-Lab	toggle	toggle	— (staffing details at the bottom of the form must not appear for this room)	toggle	toggle	toggle
260 Post Lab	—	toggle (new)	—	—	—	—
1201 Seminar Room	toggle	info only (Campus Media link) → locked off or static	—	toggle	toggle	toggle

Room Setup stays a required radio group with no toggle (not discussed in the meeting — needs confirmation in V2).

Legend: toggle = user-controlled Yes/No; locked on = Yes, cannot be turned off, dependent fields always shown; locked off = No, cannot be turned on, description still shown.

Current behavior

• ResourceFormSectionConfig / ResourceStaffingConfig have no lock flag. mode: "hidden" / showInOrigin only remove the section.
• Cleaning is disabled while catering = yes and forceCleaning is set (BookingFormResourceServices.tsx, FormInput.tsx); security is disabled when attendance ≥ 75. Both are hard-coded.
• Furnishings always renders a switch (no static mode). Leaving the switch on 220–224 with no fields would let users create an empty Setup request (furnishings folds into Setup).
• Staffing toggle on → section defaults are written into staffingServices; off → cleared. Service detection (getMediaCommonsServices) is value-based, so a locked-on staffing toggle already yields a staffing request with no logic change.
• Details fields have no required support (option-level required is parsed but never read).
• The "?" in headers is literal text in schema labels plus a few hard-coded fallbacks ("Catering?", "Cleaning?", "Staffing?").

Proposed change

• Add lock?: "on" | "off" to ResourceFormSectionConfig and ResourceStaffingConfig; add detailsRequired?: boolean alongside showDetailsField.
• Precedence: schema lock > dynamic lock (forceCleaning, large event) > user input.
• lock: "on": switch rendered checked + disabled, value written on mount ("yes", or staffing defaults), dependent fields always shown.
• lock: "off": switch rendered unchecked + disabled, value forced to "no"/empty, dependent fields hidden, description still rendered.
• Touch points: schemaTypes.ts, migrateResourceServices.ts (pass the new keys through), BookingFormResourceServices.tsx (furnishings / equipment / catering / cleaning / security switches + fallback labels), BookingFormStaffingServices.tsx (toggle + seeding + required radio), FormInput.tsx (initial write for shared fields), mcResourceServices.ts code defaults, schemaFieldDocs.ts, unit tests.
• Production config lives in Firestore resources[].services; the code defaults in mcResourceServices.ts only apply to rooms without an object services.

Open questions

1. Shared fields with conflicting locks. Catering, cleaning and security are one booking-level field rendered under every selected room. If rooms disagree (e.g. 202 with no catering + 1201 with a catering toggle), what wins? Proposal: on if any selected room locks on; off only if every selected room locks off; otherwise a normal toggle.
2. Locked off vs. mode: "static". 220–224 furniture and 1201 equipment are description-only. Static already exists for setup/catering/equipment; furnishings would need it. Pick one mechanism — the meeting leaned toward "always show a toggle", i.e. locked off.
3. 220–224 equipment. Testing notes say add an equipment toggle; the meeting said equipment is not offered in those rooms. Needs a decision in V2.
4. Room Setup. Keep as a required radio group with no toggle, or add a toggle for consistency? If no toggle, V2 should state the exception explicitly.
5. VIP / Walk-In origins. Should locks apply when an admin submits on a user's behalf, or should admins be able to override (e.g. skip a locked-on staffing request)? showInOrigin is a separate axis and can coexist either way.

Side effects to keep in mind

• Locked-on staffing means every booking in 103/230 becomes a staffing request and notifies the staffing approvers — intended, but worth flagging to Erik/Ean.
• Locked-off furniture must explicitly write "no", otherwise a stale "yes" produces an empty Setup request.
• useCheckAutoApproval.tsx uses an older client-side service check (staffingServices.length > 0); locked-on rooms will show "not eligible for auto-approval", which matches the server, but verify.