sync: auto-sync from GURU-5070 at 2026-06-05 08:06:47

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-05 08:06:47

clients/dataforth/power-monitor-demo/QUESTIONS-FOR-GEORG.md

@@ -0,0 +1,73 @@
+# Power Monitor Demo — Questions for Georg
+
+**Status:** DRAFT (for Mike's review before sending) · **Date:** 2026-06-05
+Companion to `GATEWAY-SPEC.md`. Where we have a recommendation it's noted as **(our take)**
+so Georg can confirm or redirect rather than start from scratch.
+
+---
+
+## A. Intent, audience, timeline
+1. **Feedback format** — is a session a live demo you walk partners through, or self-service
+   access they poke at on their own? (Drives how much auth friction is acceptable.)
+2. **Testers** — roughly how many, and the internal/external split? Any names/emails you
+   already know, so we can size the user list?
+3. **Timeline** — when do you want `PWM.dataforth.com` reachable for the first round?
+4. **Shipped product form** — is the eventual customer product a **packaged desktop app
+   they install** (the `dev_server.exe` lineage) or an **on-prem server** they browse to?
+   Doesn't block the demo; it shapes the product-side advice (install/update, where auth lives).
+
+## B. Hosting & access (the "external connection" from your email)
+5. Your *"need an internal IP available for an external connection"* note — what did you
+   picture for letting outside partners reach this? **(Our take:** host a small gateway
+   **inside** your network and tunnel it out to `PWM.dataforth.com` — no meter is ever
+   exposed publicly. Does that fit?)
+6. Where can a small always-on box (VM/container) live **on the meter network** to host
+   that gateway?
+7. Is `dataforth.com` on **Cloudflare** (we'd use a Cloudflare Tunnel), or should we front
+   it with **our reverse proxy / NPM** for the tunnel + TLS?
+
+## C. Meters & demo data
+8. **Which real meters** should appear in the demo (names + IPs)?
+9. For `explore / add a meter by IP` (internal users only), **what IP range** should that
+   be limited to?
+10. **Simulated units stay**, with a clear **"SIMULATION — representative data"** marker —
+    agreed? **(Our take:** yes — keep them, just label them.)
+11. Should **external partners see live meter *data*** at all (IPs always hidden), or should
+    externals be **simulation-only**? You mentioned staff validating live data — confirming
+    whether that extends to outside partners.
+
+## D. Users & permissions
+12. Confirm the model: **simple self-managed user list** (no AD/SSO), **passwordless
+    magic-link** logins, **you + Mike as admins**. **(Our take:** yes.)
+13. Per-internal-user destructive toggles we'd gate: **firmware update, config write,
+    reboot/restore**. Anything else you want as a switch (e.g. CSV/data export, clearing
+    event logs)?
+14. Should **firmware update even be reachable** in the demo (as a *simulated* screen so
+    partners can give feedback on it), or **hidden entirely**?
+15. **New external users default to read-only + simulated-only** — agreed?
+
+## E. Code structure & build (so the demo doesn't fight the product)
+16. Open to **extracting the simulation/mock logic out of `w3js_main.js` into a standalone
+    "demo module"** — so the same code drives the demo *and* can be cleanly omitted from a
+    production build? **(Our take:** yes; it also resolves the "mock data fused into the live
+    path" item.)
+17. **Buildless** (include/omit the demo file) vs **adding a small build step** — preference?
+    Note: since this is **never getting flashed onto the meter**, the "no build tools"
+    rationale in your `project.md` no longer applies — a build step is back on the table if
+    you'd find it useful.
+18. How are you iterating with **Antigravity** — should the demo **always track your latest
+    build**, or be a **pinned snapshot** per feedback round?
+
+## F. What you want from ACG
+19. Concretely, what's our role: **(a)** stand up + host the gated demo gateway, **(b)** a
+    formal external code-review writeup, **(c)** advise/shape only — or some combination?
+
+---
+
+### Heads-up worth mentioning to Georg regardless
+- `project.md` still justifies the whole vanilla-JS / zero-dependency design on *"serve from
+  embedded hardware flash."* If it's never flashed, that rationale is outdated — which quietly
+  **reopens technology choices** (a light framework or build step) he may have ruled out.
+- The package as-sent contains dev/forensic artifacts (Gemini "Antigravity" transcript
+  scrapers with his local path, a script listing live internal meter IPs) and an
+  `original_ui/` duplicate — none of which should travel in an external deliverable.