docs(questions): v6 — Q5 resolved (separate roster repo, built); Q4 open (second human) [#345]

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

questions-v6.md

@@ -0,0 +1,35 @@
+# Questions — v6 (current round)
+
+Round v5 resolved 2026-09-02 by founder chat ruling + agent action;
+carried below. One question remains open (Q4).
+
+## Resolved
+
+**Q1. Door actuator path?**
+**A:** Same exact hardware from 2018 — usbrelay strike on pfvsvrpi.
+Relay dongle confirmed present (16c0:05df); usbrelay tool install is a
+ticket-gated #356 item.
+
+**Q2. Reader model + badge format?**
+**A:** Probed 2026-09-02 (founder cleared): both readers = 13ba:0018
+PCPlay Barcode PCP-BCG4209; pfvsvrpi aarch64/event0, ultix-field
+x86_64/event15; 24-byte records; 10-digit decimal + Enter format.
+
+**Q3. Badge whitelist home?**
+**A:** HA-side whitelist, confirmed. Now materialized as a separate
+repo (see Q5).
+
+**Q5. Same 2-approval gate on the badge roster home (pfv-bms)?**
+**A:** RESOLVED 2026-09-02 — founder chat ruling: the human gate is for
+badge IDs only, and the roster should be 100% separate. Built:
+**KNEL/access-roster** (private) — PR-only + two human approvals,
+enforced; holds `roster/badges.yaml` (the HA control file). doorman
+code repo de-gated for fast movement. HA consumption wiring owned by
+the pfv-bms session.
+
+## Open
+
+**Q4. Second human approver in gitea?**
+**A:** Founder: "planned for very near future." Until granted + named,
+KNEL/access-roster merges are IMPOSSIBLE by design (fail-safe). Does
+not block code/deploy work.