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

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.