From 6c80b76b470c517038b66f01bd6de8e7eb0720b1 Mon Sep 17 00:00:00 2001 From: reachableceo Date: Wed, 2 Sep 2026 23:10:07 -0500 Subject: [PATCH] =?UTF-8?q?docs:=20questions=20v4=20=E2=80=94=20pairing=20?= =?UTF-8?q?mechanism=20fork=20+=20gitea=20allowlist=20ask=20[#626][#734]?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- questions-v3.md | 42 ------------------------------------- questions-v4.md | 55 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+), 42 deletions(-) delete mode 100644 questions-v3.md create mode 100644 questions-v4.md diff --git a/questions-v3.md b/questions-v3.md deleted file mode 100644 index e4b987c..0000000 --- a/questions-v3.md +++ /dev/null @@ -1,42 +0,0 @@ -# Questions — v3 (current round) - -Round v2 was closed out and removed 2026-09-02 by the parallel HA session. -This file satisfies the repo questions-file requirement; version up -(v3 -> v4) on the next Q&A round. - -## Active question channel (founder-directed) - -`~/PTKR.md` — 12 open items: GLPI API key, AI-staff identities, -Vault-vs-Bitwarden for agent secrets, prometheus/grafana envs, VoIP carrier -decision, PMG MX cut-over window, SITES access, October hardware window -dates, Friday 2026-09-04 onsite coordination, #681 Cloudron 500s, nitrokey -purchase, Cloudron packaging session scope. - -## Repo-local questions - -### Q1 — HA remote access: proceed with the Cloudron pairing now? (decision needed before Friday) - -Adopted architecture (your 2026-09-01 ruling on #626): Cloudron HA = family -frontend, pfv-bms = property brain, connected via HA Remote -assistants/entities. Facts verified 2026-09-02 evening: - -- Both instances at 2026.8.3 (above the 2025.7 pairing floor), Cloudron HA - RUNNING, api token in ~/.creds/cloudron-ha.env, Tailscale path Cloudron -> - pfv-bms proven (Kuma already monitors LAN hosts from there). -- Risk on the table: tsys-cloudron Postgres wobbles the same day (#681 500s). - If Cloudron degrades, FAMILY ACCESS degrades — pfv-bms itself is unaffected - either way. - -Options: - -- (A) Proceed with pairing now (recommended) — additive and reversible; pfv-bms - stays unexposed (Tailscale-only admin path); family accounts live on - Cloudron only. Remaining steps: mint pfv-bms long-lived token (yours, or - delegate to agent on approval), wire Cloudron-side integration, pair, - add family accounts. -- (B) Hold until Cloudron stabilizes — nothing lost except timeline; Friday - family-access demo unlikely. -- (C) Nabu Casa interim (~$6.5/mo) — fastest single-instance remote UI, but - does not serve the multi-property global-instance goal you ruled on. - -Answer inline (A/B/C + any conditions): diff --git a/questions-v4.md b/questions-v4.md new file mode 100644 index 0000000..ca95661 --- /dev/null +++ b/questions-v4.md @@ -0,0 +1,55 @@ +# Questions — v4 (current round) + +v3 closed 2026-09-02: Q1 answered in chat ("cloudron postgres solved — +wire up the remote access, hook first"). The deploy hook LANDED (#734, +E2E proven); the pairing hit a wrong premise and needs a fork ruling +below. Version up (v4 -> v5) on the next Q&A round. + +## Active question channel (founder-directed) + +`~/PTKR.md` — 12 open items: GLPI API key, AI-staff identities, +Vault-vs-Bitwarden for agent secrets, prometheus/grafana envs, VoIP carrier +decision, PMG MX cut-over window, SITES access, October hardware window +dates, Friday 2026-09-04 onsite coordination, #681 Cloudron 500s, nitrokey +purchase, Cloudron packaging session scope. + +## Repo-local questions + +### Q1 — HA instance pairing mechanism (blocks #626 family access; would like before Friday) + +The 2025.7+ "built-in pairing" premise was WRONG — no such core +integration exists as of 2026.8.3 (verified on both instances + HA core + +docs; full research in #626 note). Options: + +- **(A)** HACS custom `remote_homeassistant` on the Cloudron HA — full + entity mirroring + control, matches the ruled architecture. Needs a + founder file/HACS install on the Cloudron app (~30 min of your time; + no agent API for Cloudron app files). Caveat: community reports of + recent breakage (remote entities unavailable) — I'd vet the GitHub + issues before committing. +- **(B)** One-way API bridge — pfv-bms pushes ~20 key family states + (temps, UPS, garage/artroom) to the Cloudron HA REST API + I build + family dashboards there via websocket. I can build it entirely + tonight; family gets read-only visibility; no control. +- **(C)** MQTT broker on the VPS, both instances bridge — bidirectional, + but a new always-on service + YAML on both sides. + +Answer (A/B/C) + does family need to TOGGLE things at the property, or +just see status? + +### Q2 — gitea webhook allowlist (1-line + restart; unlocks instant deploys) + +gitea silently drops webhook deliveries to CGNAT-range targets (SSRF +`ALLOWED_HOST_LIST` default — no delivery attempt, no log line; restart +doesn't help; that's why hook #10 never fired). Until it opens, the +5-minute sha-watch net deploys everything reload-only — already live. + +To open the instant path: Cloudron file manager → gitea app.ini → + +```ini +[webhook] +ALLOWED_HOST_LIST = external,private +``` + +then restart gitea. Say the word when done — I'll verify hook #10 fires +end-to-end (it carries the full restart-mapping logic).