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-v4.md

@@ -1,28 +0,0 @@
-# Questions — v4 (current round)
-
-Round v3 closed 2026-09-02 with no open repo-local questions.
-This round opens 2026-09-02 for the badge doorman modernization.
-
-## Badge doorman modernization (#345 / #355 / #356)
-
-**Q1. Door actuator path?** The 2018 `doorman.pl` fired a `usbrelay`
-(device 3X9XI_1) door strike from the reader host. Is that still the
-hardware on the server-room door, or does the new e-lock (Fri 09-04
-onsite batch) take over the strike? If e-lock: make/protocol
-(Zigbee / Z-Wave / HomeKit / wired)? This decides whether HA unlocks
-natively or the pfvsvrpi listener drives the relay on HA's behalf.
-**A:**
-
-**Q2. Reader model + badge format?** Old reader was a keyboard-emulating
-USB RFID reader (usb-13ba "Barcode_Reader"), 10-digit raw-decimal IDs.
-From the box with a reader at fingertips (ultix-field is live in San
-Antonio): paste `lsusb` and `ls -l /dev/input/by-id/` output — and if
-convenient, one badge scan captured with `evtest`.
-**A:**
-
-**Q3. Badge whitelist home?** Proposal: the whitelist lives in HA
-(pfv-bms package: badge_id → identity), replacing the defunct
-doors.pfv.turnsys.net portal and the hardcoded backdoor list. The two
-legacy 2018 badge IDs (Charles NW / Josef C) get re-enrolled through the
-new path, never hardcoded again. Confirm?
-**A:**

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:**