docs(questions): v5 — v4 answers recorded (relay hw, probe cleared, HA whitelist); PR approver questions [#345]

Founder answered Q1-Q3 2026-09-02; new Q4/Q5 ask for named PR
approvers and pfv-bms protection scope.

https://projects.knownelement.com/issues/345

questions-v5.md

@@ -0,0 +1,48 @@
+# Questions — v5 (current round)
+
+Round v4 (badge modernization kickoff) was answered 2026-09-02 and
+closed; carried below with the founder's answers inline. New questions
+appended at the bottom (Q4/Q5 — PR approvers).
+
+## Resolved — badge doorman modernization (#345 / #355 / #356)
+
+**Q1. Door actuator path?**
+**A:** Same exact hardware from 2018 — `usbrelay` (device 3X9XI_1)
+door strike, no new e-lock. So the unlock path is: HA decides →
+something fires the relay on pfvsvrpi. Design choice (HA→Pi callback
+vs listener unlock-on-response) lands with #356; the listener's relay
+bridge already exists behind `DOORMAN_UNLOCK_ON_2XX`.
+
+**Q2. Reader model + badge format?**
+**A:** "run lsusb or whatever you need. you're clear." — agent
+authorized to probe the reader hosts directly (done 2026-09-02; see
+#345/#355 notes and KNEL/doorman).
+
+**Q3. Badge whitelist home?**
+**A:** "yes thats good" — whitelist lives in HA (pfv-bms package:
+badge_id → identity), seeded with the two 2018 badges, never
+hardcoded in the listener. Roster = git YAML per Discourse t/318
+reply #2.
+
+## New questions — PR approval process (founder ruling 2026-09-02)
+
+**Q4. Who are the two named approvers for KNEL/doorman PRs?**
+Branch protection is LIVE: `main` is PR-only, 2 human approvals
+enforced server-side, agents cannot approve/merge. KNEL org members
+available: `coo`, `reachableceo`, `reachableceo-offstage`,
+`tsgstaff-coo-svpknel`, `tsgstaff-coo-vpsecops`, `vptechops` —
+approvers must be HUMAN (some of the above are AI-staff identities).
+Until you name them, any org member with repo write counts as an
+approver. Note: if you are the only human with write access, NOTHING
+merges until a second human approver is granted access.
+**A:**
+
+**Q5. Same 2-approval gate on the badge roster home (KNEL/pfv-bms)?**
+The roster YAML will live in pfv-bms, where the parallel HA session
+pushes directly per the standing commit-push policy. Options:
+(a) protect pfv-bms main too — 2 approvals for ALL HA work;
+(b) leave pfv-bms fast-moving, gate access changes via doorman PRs +
+ticket trail only; (c) move the roster to its own protected repo with
+a second git_pull instance. Founder's call; needs HA-session
+coordination either way.
+**A:**