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

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

questions-v5.md

@@ -1,48 +0,0 @@
-# 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:**

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.