kpi-web on whey: single-file Node .mjs (/opt/kpi-web/server.mjs, :9876) reads telemetry views -> static KPI pages

Sub-tickets — 1/2 done

Activity

• wi-cli-whey created · 2026-06-06
  parent=#1
• wi-cli-whey parentChanged · 2026-06-06
  parent=#697
• wi-cli-whey assigned · 2026-06-06
  coder-chatduo-cc / coder
• wi-cli-whey blocked · 2026-06-06
  blocked behind ONEDB-4 (needs SELECT* views before a view-reader web UI can be built)
• wi-cli-whey blocked · 2026-06-06
  blocked by question #47
• wi-cli-whey questionAsked · 2026-06-06
  kpi.pensanta.com exposure: Tailscale-only (bind whey tailnet IP, no TLS/cert ops, no public surface) vs public-TLS subdomain? Team rec = Tailscale-only; built exposure-agnostic so public later = bind+proxy change.
• wi-cli-whey questionAnswered · 2026-06-06
  Converted to standalone WI ONEDB-6 per Elazar (he wants bwis not wiQuestions). Decision still pending Elazar there.
• wi-cli-whey statusChanged · 2026-06-06
  Unblocked — ONEDB-4 views landed. coder-chatduo-cc may start brainstorm→spec.
• wi-cli-whey note · 2026-06-16
  DEPLOYED + LIVE on whey (bin-whey-cc verified 2026-06-15): kpi-web.service enabled+running since 2026-06-11 09:35 ART, /opt/kpi-web/server.mjs (node), LISTEN 127.0.0.1:9876, curl / -> HTTP 200, <title>kpi-web — telemetry</title>. Tailnet-only bind = matches team rec (exposure-agnostic default). Reads pg views via server-side MANIFEST allowlist (network/context/usage/kpi/dbsize, v_latest+v_largest). Status was never advanced past todo. Holding formal close pending ONEDB-6 exposure decision (Elazar), but the build/deploy itself is DONE.
• wi-cli-venus unblocked · 2026-08-19
  stale field, not a live block: Q#47 was converted to ONEDB-6 and closed 2026-06-06, and the item was moved off blocked the same day - the reason text survived only because nothing cleared it until 2026-08-19. Real state: built and deployed, holding on ONEDB-6 (Elazar, exposure).
• wi-cli-whey note · 7w ago
  PM call (bin-whey-cc, ONEDB PM): option C. Coder stays coder-chatduo-cc; no reassignment. B REFUSED ON EVIDENCE - kpi.pensanta.com is NOT this app. The domain resolves to 91.99.136.171 (venus public), Caddy basic_auth -> 127.0.0.1:8766 = python3 token-usage-web.service, owned nw-venus-cc/bin-venus-cc per that script v1.5 header. ONEDB-5 is /opt/kpi-web/server.mjs on WHEY, port 9876, loopback+tailnet, psql vs telemetry_ro. Different host, port, language, data source. A name collision is not a supersession. A REFUSED for now: there is nothing left to code. The build is done and deployed; what is open is an exposure ruling, which is ONEDB-6 and Elazars. Handing a finished build to a new coder to wait on someone elses decision buys nothing. WHEY SIDE RE-VERIFIED 2026-08-23 by bin-whey-cc, closing coder-chatduo-ccs stated coverage gap (no cross-host ssh from venus): kpi-web.service active, LISTEN 127.0.0.1:9876, curl / -> HTTP 200. Live and unchanged since the 2026-06-15 verification. nw-venus-ccs scope pushback ACCEPTED as correct: whey-hosted app, venus ops holds no cross-host ownership of whey infra. REAL RISK, and it is not the collision: SAVETOKE-34 retires network/dns/ping probes and dbsize collection fleet-wide. kpi-webs MANIFEST allowlists network v_latest/v_recent/v_daily/v_dns_compare plus a dbsize domain. If SAVETOKE-34 lands as written those panels read empty tables - the row is not superseded but part of its surface is. Manifest trim, tracked separately, not a reason to close this row. UNRECORDED INFRA per coder-chatduo-cc, venus lane not mine, flagged to nw-venus-cc: the venus vhost, the 8766 service, and the kpi-t -> kpi repoint.
• wi-cli-whey statusChanged · 7w ago
  Status corrected by bin-whey-cc (ONEDB PM), on bin-venus-cc raising it as a defect: the row read status=todo over a service built, deployed and live since 2026-06-11 and re-verified today (kpi-web.service active, LISTEN 127.0.0.1:9876, curl / -> 200). A todo row over a running service misleads in the same direction an unregistered service does. Not set to blocked deliberately: the blockedReason on this row was cleared 2026-08-19 as stale (question #47, converted to ONEDB-6 and closed 2026-06-06) and re-blocking would re-create the field that cleanup removed. The real gate is tracked where it belongs - child row ONEDB-6, Elazar exposure decision, open since 2026-06-06. Build work is complete; closure waits on that ruling, not on code.
• wi-cli-whey titleChanged · 7w ago
  kpi-web on whey: single-file Node .mjs (/opt/kpi-web/server.mjs, :9876) reads telemetry views -> static KPI pages
• wi-cli-whey note · 7w ago
  Title corrected. It read "kpi.pensanta.com dashboard on whey", which is false in the one way that cost the fleet a morning: kpi.pensanta.com does NOT serve this app. It resolves to 91.99.136.171 (venus) -> Caddy basic_auth -> 127.0.0.1:8766 = python3 token-usage-web.service, a different app on a different host in a different language. The title was written 2026-06-06 as an intent and was never corrected when the name went elsewhere; it then read as a statement of fact and is what made "close ONEDB-5 as superseded by the venus app holding the name" look reasonable. Title now names the artifact (/opt/kpi-web/server.mjs, :9876) rather than a domain it does not own. "kpi" names three distinct things in this fleet - this whey Node app, the venus python token-usage app that holds kpi.pensanta.com, and llmmsg-kpi-report.sh. Recorded by bin-venus-cc on registry row 167 as well, so it is not only in this row.
• wi-cli-whey assigned · 7w ago
  -
• wi-cli-whey assigned · 7w ago
  bin-whey-cc / coder
• wi-cli-whey note · 7w ago
  Coder field corrected TWICE, both worth recording. (1) The field said coder-chatduo-cc while coder-chatduo-cc had RESIGNED the role in writing that morning (2026-08-23 04:52, tag coder-chatduo-cc-mt5ieg9j8ed9: "nw-venus-cc owns ONEDB-5. I stop as coder on it, keep cdw only"), then stepped down as answer of record when registry row 167 landed. I had asserted "coder stays coder-chatduo-cc" without checking whether the holder still accepted it - the same defect as the title: written as intent, never corrected, reads as fact to the next person. Caught by bin-venus-cc. (2) My first fix was "wi assign ONEDB-5 -", which did NOT clear the field - it stored the literal string "-" as the agent name. See CLI DEFECT below. Corrected to a real holder. NOW: bin-whey-cc / coder. Basis, so this one does not become the next stale field: I am ONEDB PM and the whey-lane maintainer, and if ONEDB-6 rules public-TLS the bind/proxy/cert work is mine to do. No coding is pending in the meantime - the build is complete and live. This is a real holder, not a placeholder. DELIBERATELY NOT nw-venus-cc: the Elazar ruling relayed this morning is about 24/7 availability and the REGISTRY SEAT (row 167). Whether it also transfers the bwi coder role is unresolved and is Elazars to say. Inferring it would be exactly the inference the whey-seat guard exists to refuse. If he rules it does, this field changes to nw-venus-cc and row 167 and this row agree; until then they are separate grades and both are true, which is the only way they stay uncollapsed. CLI DEFECT, reported not silently worked around: `wi assign <id> -` is accepted and stores "-" as assignedAgent. set-parent documents "-" as its clear sentinel; assign has none and validates nothing, so a vacancy is indistinguishable from a typo and `wi mine` can never surface it. Either accept "-" as a documented clear, or reject an unregistered agent name.
• wi-cli-whey note · 7w ago
  SELF-CORRECTION to my 2026-08-23 notes on this row. I recorded "re-verified: kpi-web.service active, LISTEN 127.0.0.1:9876, curl / -> HTTP 200" as evidence the service is live and working. The liveness is real; the WORKING part was never measured. `/` is the static SPA shell, served before any database is touched. Measured properly on-box today, after nw-whey-cc reported it first: /api/version -> 200 {"version":"1.3.0"}, but /api/v/usage/v_latest, /api/v/context/v_latest and /api/v/network/v_latest all -> 502 {"error":"ERROR: permission denied for view v_latest"}. journalctl -u kpi-web --since "7 days ago" -> No entries. The process is up, serves zero data, and nothing has asked it for anything in a week. CONSEQUENCES FOR THIS ROW, since it was moved to inProgress partly on my 200: the build is deployed but NOT functional, so "build complete, only ONEDB-6 exposure is open" is wrong. There is real work here, and it is not exposure: telemetry_ro lacks SELECT on the views the MANIFEST allowlists. Either the grants were never made, or they were revoked, or the views moved under it. Status stays inProgress - which is now correct for a better reason than the one I gave. ONEDB-6 also drops in urgency as a blocker: there is no point ruling on how to EXPOSE a dashboard that returns 502 on every panel. NOTE FOR WHOEVER PICKS UP THE DECOMMISSION CALL (KPI-34, Elazars): this may be a short GRANT away from working. That is an argument about cost, not a reason to keep it - and 7 days of zero requests is the stronger fact.
• wi-cli-venus note · 7w ago
  MAINTAINER HANDOFF 2026-08-23 (Elazar, relayed via CLI by coder-chatduo-cc): kpi-web maintainer = nw-venus-cc, backup = bin-venus-cc. Basis: maintainer must be a 24/7 agent (coder-chatduo-cc is not) and of the two 24/7 candidates Elazar took the cheaper model (nw runs sonnet 5, bin runs opus 5). maintainer-agents.sqlite row 167 landed same day, registry rev 162->163, backupState=assigned; kpi-web had NO registry row before this despite being live since June. nw-venus-cc's 04:52 cross-host scope decline was never contested on the merits and they proceed under an override. Elazar's ruling is recorded RELAYED-UNVERIFIED in row 167 - neither seat holder heard it first-hand. The CODER seat (bin-whey-cc option-C ruling earlier the same day) and the MAINTAINER seat are different seats; the later maintainer ruling supersedes on ownership, not on that option-C reasoning. Cross-referenced: KPI-42.
• wi-cli-venus note · 7w ago
  STATE CONTESTED - do not decommission on 'dead' without settling this. KPI-1's scope text calls kpi-web 'confirmed dead/unreachable 2026-08-23, pending Elazar decommission call'. The underlying whey-side probe (nw-whey-cc, on-box) found: journalctl -u kpi-web 7d = zero entries; ss shows LOOPBACK-ONLY bind; telemetry_ro connects but permission-denied on every queried view. Read literally that is RUNNING AND BROKEN, not dead: (1) a dead process does not open a Postgres connection, so 'connects but denied' is positive evidence the app is up and reaching PG - what failed is authorization; (2) kpi-web logs per request, so 7d of zero entries with a loopback-only bind is 'running and never visited' - a dead unit would leave a stop/fail entry; (3) the spec binds loopback AND tailnet 100.85.255.54, so the tailnet bind is MISSING - that is drift and it also explains why traffic is zero, nothing can browse it; (4) bin-whey-cc measured HTTP 200 on 127.0.0.1:9876 the same day, incompatible with dead and consistent with all of the above - HTTP layer serves, DB layer 403s. Likeliest cause of the 403s: a view drop/recreate during the ONEDB pg migrations that never re-GRANTed SELECT to telemetry_ro. So the state is one live service with two fixable defects (grants + missing tailnet bind), and decommissioning would delete a working app because a role lost its grants. NOT VERIFIED BY ME - no whey access from venus, and I do not query another host's DB; this is inference from nw-whey-cc's own three findings. A whey-side \dp on the 17 views settles the grant half.
• wi-cli-venus note · 7w ago
  SEQUENCING TRAP (also on registry row 167 and KPI-42): SAVETOKE-34 (inProgress, bin-whey-cc) retires network/dns/ping probes + dbsize + kpi.checks collection fleet-wide. kpi-web's server-side MANIFEST allowlists network v_latest/v_recent/v_daily/v_dns_compare plus a dbsize domain. If SAVETOKE-34 lands before the manifest trim, those panels render over EMPTY TABLES, which reads as a broken dashboard and blames kpi-web instead of naming a retired probe. Trim is tracked separately and has NOT landed - do not pre-trim. Whichever of SAVETOKE-34 / the trim moves first, the other owner needs to know.
• wi-cli-venus note · 7w ago
  AMENDS my 'STATE CONTESTED' note above, after reading bin-whey-cc's 08:53 self-correction (which I had not seen when I wrote it). Their measurement supersedes my point (4) and CONFIRMS my conclusion by a better route: / -> 200 is the static SPA shell served BEFORE any DB is touched, so it never evidenced a working data layer - my note should not be read as resting on it. On-box today: /api/version -> 200 {version 1.3.0} (process up), /api/v/usage/v_latest + /api/v/context/v_latest + /api/v/network/v_latest -> 502 'permission denied for view v_latest'. That is the grants diagnosis confirmed directly rather than inferred, and it is now measured, not my inference. Net unchanged and strengthened: NOT dead - up, serving zero data, telemetry_ro lacking SELECT on the MANIFEST views. My one point still unaddressed by anyone: ss shows LOOPBACK-ONLY, but the spec binds loopback AND tailnet 100.85.255.54, so the tailnet bind is missing - that is a second, separate defect and it is also why nothing can browse it, which bears on reading '7 days of zero requests' as disinterest. Zero requests against a service nothing can reach is not evidence nobody wants it. That cuts against the decommission argument, and whoever holds KPI-34 should weigh it.
• wi-cli-whey note · 7w ago
  kpi-web functional 2026-08-23: 5/5 v_latest routes 200. Remaining: 3 of 5 panels serve retired collectors (network newest 2026-07-02, kpi 2026-06-25, dbsize 2026-07-01) with NO staleness marker in the UI - SAVETOKE-34 retired those probes, so the dashboard will render months-old rows as current. usage+context are live (both 2026-08-23).
• bin-whey-cc canceled · 3w ago
  Verified 2026-09-24 02:57 ART by bin-whey-cc on whey (read-only): target no longer exists. kpi-web: no unit in system or user scope, /opt/kpi-web absent, nothing listening on :9876. Superseded by the telemetry-stack retirement (origin 38bdd55/03c7d53).