[PowerX] add power-basis switching to the main profit chart / 主利润图表支持切换功率依据

[edwingao28]

The per-GW profit chart can now switch between provisioned power and measured-GPU-based modeled system power with 10% headroom. The selector reuses the existing deployment-capacity calculation to update revenue, costs, profit, and GPU-hours. Provisioned power remains the default.

Power inputs, assumptions, source records, and comparison exports move into expandable details. Chart captions, axis labels, CSV, and share links identify the selected basis. The chart still requires an exact measured target: different per-hardware operating points can leave only one supported bar. Unsupported observations have no modeled bar or fallback; AgentX remains unsupported. No backend, producer, model formula, or dependency changes.

Validation: unit suite, typecheck, lint, format, typography, fixture production build, 43 profit-estimator browser tests, and local Cypress smoke suite against the production build. The initial development-server smoke run hit a Next.js performance timestamp error on the Chinese 404 page; the production-build rerun passed. Browser-checked real B200 observation 441192 on desktop and EN/ZH mobile; the modeled chart preserves its negative profit.

中文说明

每 GW 利润主图表现在可在预配功率和“基于 GPU 实测功率的系统估算 + 10% 余量”之间切换。选择器复用已有部署容量计算，更新收入、成本、利润和 GPU 小时数；默认仍为预配功率。

功率输入、假设、来源记录及对比导出收纳为可展开明细。图表说明、坐标轴、CSV 和分享链接标明所选功率依据。图表仍要求精确匹配实际测量的目标运行点：各硬件运行点不同，可能只剩一个可用柱形。不支持的记录不会生成建模柱形或回退到预配值；AgentX 仍不支持系统功耗估算。不改动后端、生产端、模型公式或依赖。

验证：单元测试、类型检查、lint、格式、排版检查、fixture 生产构建、43 项利润估算器浏览器测试及针对生产构建的本地 Cypress 冒烟测试。首次开发服务器冒烟测试在中文 404 页面遇到 Next.js 性能时间戳错误；生产构建重跑通过。使用真实 B200 记录 441192 检查桌面和中英文移动端页面，建模图表保留其负利润结果。

---

Note

Medium Risk
Front-end-only but changes core per-GW revenue/GPU-hour math and URL sharing; wrong modeled gating or capacity wiring would mislead fleet planning views.

Overview
The per-GW profit estimator now exposes a Power basis control that switches the main chart between provisioned power (default) and modeled system power + 10%. In modeled mode, bar data comes from supported exact benchmark comparisons (whole deployments via existing measured-profit capacity math)—revenue, TCO, profit, and GPU-hours update accordingly; there is no provisioned fallback on the chart when a SKU is unsupported.

Power inputs and assumptions wraps the provisioned vs modeled comparison table and JSON/CSV exports in a collapsible section. Modeled planning hides AgentX compare-history; captions, Y-axis wording, chart CSV (new Power basis column), export filenames, and share URLs (c_profit_power=modeled) reflect the active basis. The per chip-hour page stays unchanged (no selector).

Copy in MeasuredProfitComparison clarifies that detail-view provisioned counts use floored deployments while the provisioned chart keeps a continuous GPU denominator. Docs and Cypress cover switching, share links, unavailable targets/AgentX, and EN/ZH.

^{Reviewed by Cursor Bugbot for commit 5e199a2. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
inferencemax-app	Ready	Preview	Sep 11, 2026 2:32am UTC

[github-actions]

Claude finished @edwingao28's task in 6m 59s —— View job

---

Review: PowerX power-basis switching

🟢 LGTM — no blocking issues found.

• Read diff & understand changes
• Static review (logic, bugs, tests, i18n)
• Runtime verification at localhost:3000
• Check CI status
• Post findings

I verified this at runtime against the real read-only DB on /profit-estimator-per-gigawatt, exercising the changed paths:

• Power basis selector renders only on the per-GW (gw-year) basis and defaults to Provisioned. Switching to Modeled system power + 10% updates the chart caption (Power basis: …), the y-axis intent, and the Power inputs and assumptions details block. ✅
• Agentic → modeled correctly shows the "AgentX system estimates are not supported yet" unavailable message with no bar. ✅
• 8k/1k modeled classification works: the comparison table distinguishes supported rows (validated GPU power + complete chassis) from Unavailable / partial-chassis / No validated GPU power rows, and the chart shows the unavailable note when no exact supported point is selected — matching the PR's "exact measured target" contract. ✅
• CSV/JSON exports, share link, and caption all carry the selected basis; the URL round-trip (c_profit_power) is covered by the new url-seed.test.ts and url-state.test.ts cases (including default omission and /zh). ✅
• No console errors across desktop navigation (only unrelated SVG-preload warnings).

Notes I checked and found fine:

• The estimate memo was moved below powerComparisons; no temporal-dead-zone or circular-dependency issue since powerComparisons doesn't read estimate.
• Overlay/visibility: in modeled mode the legend keeps all hw keys (availableHwKeys) so an exact point stays selectable, while estimate.rows is still gated by visibleHwKeys through powerComparisons, and tcoBadges now derives from drawn rows.
• Chinese copy for the new strings (功率依据, 系统建模功率 + 10%, tooltip, formula, unavailable note) reads as natural technical Chinese with no semantic drift — no maintainer escalation needed.

CI: Lint & Format, Tests (Unit), Tests (E2E), and Code Quality all ✅.
· feat/powerx-profit-chart

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 3b3eb0e. Configure here.}

[github-actions]

Claude finished @edwingao28's task in 2m 2s —— View job

---

Re-review: PowerX power-basis switching

Since my previous LGTM (commit 3b3eb0e0), the only new commit is 5e199a2 — a merge of master that resolves conflicts; it doesn't change the PR-owned power-basis code. I focused this pass on the Cursor Bugbot finding and confirmed no regression from the merge.

• Read diff & understand changes
• Static review (logic, bugs, tests, i18n)
• Assess Cursor Bugbot finding (profit sort)
• Runtime verification at localhost:3000
• Check CI status
• Post findings

One non-blocking finding (inline): 🟡 Modeled bars aren't re-sorted by profit — this confirms the Cursor Bugbot report. In modeled mode estimate.rows come from powerComparisons in getResults (throughput-descending) order, while provisioned mode sorts by profit via estimateProfitRows, so the chart's "left-to-right most-profitable" invariant is broken when more than one supported bar is drawn. A one-line .sort((a, b) => b.profit - a.profit || a.resultKey.localeCompare(b.resultKey)) fixes it. Non-blocking because the exact-measured-target contract usually leaves a single supported bar.

Runtime check: loaded /profit-estimator-per-gigawatt?c_profit_power=modeled — page renders, URL seeds modeled mode, 0 console errors (1 unrelated preload warning).

CI: Lint & Format ✅ and the fixtures E2E pre-check ✅; Unit / E2E / Code Quality still in progress at review time — no failures observed.

Everything else from the prior review still stands (selector gating, exports/share round-trip, EN/ZH copy, TDZ-safe memo ordering). LGTM aside from the optional sort tweak.
· feat/powerx-profit-chart

[github-actions]

🟡 WARNING: Modeled bars are not sorted by profit (confirms the Cursor Bugbot finding).

Why it matters: fullEstimate.rows (provisioned mode) come back sorted by profit descending from estimateProfitRows — the chart is documented to "read left to right from the most profitable SKU". The modeled branch takes comparison.measured in powerComparisons order, which is getResults order (throughput descending), so switching the power basis can reorder the same bars even when relative profit is unchanged. With multiple supported bars this breaks the profit-ordering invariant the chart promises.

Fix: sort the modeled rows with the same comparator estimateProfitRows uses:

Suggested change

	rows: modeledPower
	? powerComparisons.flatMap((comparison) =>
	comparison.status === 'supported' ? [comparison.measured] : [],
	)
	: fullEstimate.rows.filter((row) => visibleHwKeys.has(row.hwKey)),
	rows: modeledPower
	? powerComparisons
	.flatMap((comparison) =>
	comparison.status === 'supported' ? [comparison.measured] : [],
	)
	.sort((a, b) => b.profit - a.profit || a.resultKey.localeCompare(b.resultKey))
	: fullEstimate.rows.filter((row) => visibleHwKeys.has(row.hwKey)),
	skipped: modeledPower ? [] : fullEstimate.skipped,

Non-blocking — in practice the "exact measured target" contract often leaves a single supported bar, so this is only observable when more than one SKU shares an exact operating point.