# 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.
