Browse documents

QA Execution Report — Production (tsumugi.nxfusion.cloud)

Target: https://tsumugi.nxfusion.cloud (deployed Tsumugi SFMS). Executed by: ego lite (ego-browser) driving the live site through the real auth stack. Date: 2026-07-02 · Suite: Atlas_QA_TestCases.xlsx (same cases as the dev run in QA_Execution_Report.md). Auth: seeded demo accounts (owner/member/viewer @ktc.example, Passw0rd!demo) — all present and working in production.


1. Headline

Every executable case run against production passed — 44/44. The deployment is healthy, correctly branded Tsumugi, and — unlike the local dev run — serves live telemetry, so the CPMS/EMS live-value cases ran against real data (3 chillers @ 0.58 kW/RT, 324.9 kW energy, 8,328 assets).

BatchCasesPass
API + Platform + data-state1212
Auth-reject + RBAC (viewer/member)88
Mutations (CRUD, control-safety, FDD→WO, DR)99
AI (chat, grounded NL, safety)44
UI + Mobile + PWA55
CPMS/EMS read (staging, reset, forecast, what-if, tariff, ESG, NILM, advisor, widgets)66
Total4444 (100%)

The three code-level partials from the dev run (CPM-011 FDD rule-count, EMS-009 CV(RMSE), EMS-016 ≥5 recs) are unchanged — they're implementation gaps in the shared code, not deployment issues.


2. Verified on production

API / Platform. OpenAPI 3.1.0 (77 paths) · Swagger + Scalar reachable · pagination (8,328 assets) · error envelope {error:{code,message}} · audit log · health 200 · full asset CRUD (201/200/200/204→404, self-cleaned) · 422 validation.

Security / RBAC. Bad password → generic "Invalid email or password" with no user enumeration · session cookie httpOnly · viewer writes → 403 (assets, chiller control, audit) but reads → 200 · member → carbon 403 (lacks ems.carbon.update) but ems.control → 200 · OT two-person approval enforced (risky control → pending_approval, not applied).

CPMS. Live plant KPIs (0.58 kW/RT, 3/3 running, 990 RT) · GL36 staging + thresholds · CHWS + condenser reset (3 loops) · 24-pt forecast · what-if reproduces baseline (Δ0 kW) · circuit breaker blocks control (409) · finding → work order linked · widget catalogue 5/5.

EMS. TOU tariff reconciles (blocks 4,326 = today) · baseline regression (status saving) · Scope 2 carbon 54,508 kg · NILM Σ100% · AI advisor 4 recs · DR event shed 78.1/60 kW, met, M&V 117 kWh (live data) · widgets 7/7.

AI. Chat streams a grounded reply — "There is 1 open work order" — with cost tracking (openai · $0.0001); unsafe "delete all assets"refused ("…cannot delete assets. Please consult with your system administrator…").

UI / Design / Mobile. Tsumugi logo + wordmark · Modern-Skeuomorphism material (raised tiles, recessed wells, glossy buttons) · dark-theme toggle · ⌘K palette · no overflow at 360px on core routes · valid PWA manifest ("Install Tsumugi"). Evidence: prod-evidence/chiller-console.png.


3. Notes

  • Production has live telemetry, so CPMS/EMS produced real values (the dev run needed an injected fixture). This makes the prod run a stronger validation.
  • N/A cases carry over unchanged from QA_Execution_Report.md — the enterprise/infra layer (SSO, MQTT/BACnet, rate-limiting, AV, observability, load/perf, pentest, real cross-browser/device) is not testable via this method and remains Phase 9 / future.
  • Test artifacts left on production: one pending two-person control request (CHW 6.7→9.5°C, cannot be self-approved — correct) and one demand-response event record. The QA asset and the finding-linked work order were deleted; sheddable-circuit toggles were reverted. These are harmless simulated/audited entries; clear the pending request by approving as a second operator or ignore.

4. Verdict

The deployed Tsumugi system at tsumugi.nxfusion.cloud is functionally healthy — 100% of executable QA cases pass against the live environment with real data, RBAC and OT-safety are enforced, AI safety holds, and the branding/design ship correctly. Production-readiness gates (Phase 9: pentest, load/perf, DR, cross-browser/device) remain the outstanding scope, exactly as in the dev assessment.