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
49 lines
2.2 KiB
Markdown
49 lines
2.2 KiB
Markdown
# 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:**
|