fix: let the setup wizard offer platforms auto-detection missed

[johanzander]

Summary

• /api/setup/discover now sends huawei_found, which it silently dropped
• All four inverter platform tabs and the three SolaX variant pills stay selectable when auto-detection finds nothing
• A re-scan no longer reverts a manually chosen platform, which left the sensor step permanently uncompletable

Root cause

Three defects stack for a user running Huawei LUNA2000/EMMA through the huawei_emma_management integration (reported by @valexi7).

A — the flag was never sent. backend/api.py:2963 built the discover payload with growatt_found, solax_found, solis_found and huawei_device_id, but no huawei_found. The value exists upstream (core/bess/ha_api_controller.py:3283) and was simply dropped; grep -rn huawei_found backend/ returned nothing. So discovery.huaweiFound was undefined for every user and disabled={wizardMode && !huaweiDetected} was unconditionally true. The Huawei tab was not "disabled when detection fails" — it was never enabled.

It stayed hidden because detectedInverterPlatforms is populated, so a stock huawei_solar user gets the Huawei panel preselected and never clicks the trigger. Only the undetected user needs the click. The e2e fixture hand-wrote a huaweiFound: false field the real API did not return, so no test could catch it.

B — the gate was never Huawei-specific. All four tabs (:360, :372, :384, :396) and the three SolaX pills (:458) gated on detection identically, so an unrecognised Solis build was locked out the same way. Detection matches a fixed list of HA platform names (_INVERTER_PLATFORMS), so any supported inverter reached through a custom integration fails it — the reporter's entities carry huawei_emma_management, not huawei_solar, which is also why their huawei_device_id and sensor maps came back null.

C — Re-scan reverted the choice. handleScan is a useCallback(..., []) and read inverterForm.inverterPlatform from a stale closure. With nothing detected it reset sensors.platform to the default while the form kept the user's choice. allRequiredFilled resolves sensors via sensors.platform but takes its required-key list from the selected tab, so once those diverged the sensor step could never be completed no matter what was typed — and Re-scan is exactly what a user with failed detection reaches for.

Fix

Detection narrows the defaults, never the choices; the per-platform status dot already reports what was found. So: forward the missing flag, drop the disabled props, and read the selected platform through a ref instead of a stale closure. Manual completion already worked — the device-ID input, service-domain field and free-text sensor entries all persist without any detection dependency.

Backend discovery is deliberately not changed: huawei_found: false is correct for this user. The bug is the gate, not the detection.

Test plan

• ./scripts/quality-check.sh passes locally — 2055 passed, vitest 125 passed, tsc + eslint clean
• pytest -m slow — 548 passed, 7 skipped
• /code-review — no CONFIRMED findings
• Live POST /api/setup/discover against mock-HA: undetected scenario returns huaweiFound: false; ci-wizard-huawei-luna2000 returns huaweiFound: true, huaweiDeviceId: 'dev-huawei-battery-001'. The key was absent entirely before this change, so a correctly detected Huawei user also got a grey dot.
• New Playwright specs driven against the real stack in a real browser: all four tabs enabled with nothing detected, Huawei selectable, its panel renders, and the step completes after a Re-scan.
• Full wizard e2e suite: 12 passed, 1 failed

The one failure is redirects to /setup when no sensors are configured, and it is pre-existing — it fails identically with this entire frontend diff reverted and rebuilt, on a clean stack with a pristine fixture. Locally ci-wizard-settings.json yields wizardNeeded: false, so the redirect cannot fire. Worth investigating separately; it may not be proving anything in CI either.

Evidence the test discriminates

Two independent mutations, one per defect:

Defect B — before the fix, every platform tab stays selectable when nothing is detected failed with Playwright resolving the element as:

• <button disabled role="tab" ... id="radix-«r0»-trigger-huawei">, element is not enabled
• That is the reporter's exact symptom, reproduced.

Defect C — with the tab fix in place but only selectedPlatformRef reverted to inverterForm.inverterPlatform, rebuilt and re-run:

• Result: test 1 PASSED, a manually selected platform survives a re-scan FAILED — expect(locator).toBeEnabled() failed / Received: disabled on the Next button
• Restored: tree clean, both green

Defect A — TestDiscoverForwardsInverterDetectionFlags failed RED with KeyError: 'huaweiFound' (3 tests), green after adding the key.

Outcome-level coverage

• Backend: TestDiscoverForwardsInverterDetectionFlags asserts the endpoint payload, not discover_integrations(). test_scenario_discovery.py:296 already asserted the controller and passed throughout — that is precisely why the gap survived, so the new tests pin the contract at the layer that was broken.
• Frontend: both new e2e specs assert user-visible outcomes — tab enabled, panel rendered, Next button enabled after typing the sensors by hand — not the disabled prop or any internal flag.
• Docs: docs/SOFTWARE_DESIGN.md Stage 1 detection table was missing solis_modbus and huawei_solar, and the wizard step description implied selection follows detection. Both corrected, since this change makes those claims wrong.

Closes #621

[bess-agent]

@claude-bot review

[bess-manager-claude-bot]

Review: fix/issue-621-wizard-platform-gate (closes #621)

Root-cause match: yes, all three defects verified against source.

• Defect A — backend/api.py:2963 now sends "huawei_found": integrations["huawei_found"]. Confirmed huawei_found is unconditionally initialized in discover_integrations()'s base dict (core/bess/ha_api_controller.py:3239-3243), so direct indexing (not .get()) is correct and matches the existing growatt_found/solax_found pattern — not a new convention.
• Defect B — every disabled={wizardMode && !xDetected} gate is gone. I diffed the PR branch's SensorConfigSection.tsx for the string disabled and the only remaining hits are the unrelated disabledSensors field/docstring (#549 feature). All four tab triggers and the three SolaX variant pills (solax_modbus_native/_growatt_min/_growatt_sph) are unconditionally selectable now. The growattDetected/cloudDetected/modbusDetected/solisDetected/huaweiDetected locals are still consumed by the status-dot className, so removing disabled didn't leave dead/unused bindings.
• Defect C — selectedPlatformRef (SetupWizardPage.tsx) mirrors inverterForm.inverterPlatform every render; handleScan's empty-dep useCallback reads selectedPlatformRef.current instead of the stale closure value. This is the same ref-mirroring shape already used in the same file for existingSensorsRef and wizardNeededRef — reuses an existing pattern rather than inventing a new one.

Would the tests catch a regression? Yes, and the PR earns that claim rather than asserting it:

• Backend: TestDiscoverForwardsInverterDetectionFlags asserts the endpoint payload (not discover_integrations() directly, which already had passing coverage and is exactly why the bug survived — good instinct catching that distinction).
• Frontend e2e: two new Playwright specs assert user-visible outcomes (tab toBeEnabled(), panel visibility, Next-button enabled after manual entry) rather than the removed disabled prop itself. I checked every selector used (Not detected — enter entity ID placeholder, Huawei battery device ID placeholder, LUNA2000 text, Re-scan button, Next: Electricity Pricing button) against the actual markup in both changed components — all match.
• PR body documents an actual RED→GREEN cycle for each of the three defects independently (including reverting only the ref fix while keeping the tab fix, to isolate defect C) — satisfies the "must be seen to fail without its fix" rule.

Minimal / no scope creep: yes. Backend: 1 line. Frontend: prop removals + one ref. The ~9 existing test fixtures that gained "huawei_found": False, are a forced, mechanical consequence of switching to direct dict indexing (would otherwise KeyError), not unrelated churn. docs/SOFTWARE_DESIGN.md's added solis_modbus→Solis / huawei_solar→Huawei rows match _INVERTER_PLATFORMS at core/bess/ha_api_controller.py:3758-3763 exactly, and the doc's "defaults, not choices" framing matches the shipped behavior.

Rule compliance: no Optional[x], no hasattr/getattr-with-default, no new classes, camelCase conversion untouched (goes through the existing convert_keys_to_camel_case call), no sensor access bypassing ha_api_controller. PR body explicitly states the fix is scoped as a local bug fix (forward a dropped field, remove a gate that was never meant to block selection, fix a stale-closure read) rather than a new responsibility bolted onto an existing method — satisfies the scope-assessment checklist item.

Nits (non-blocking):

• I could not execute black/ruff/tsc/eslint myself in this review environment (no toolchain available), so I'm relying on the PR's stated local quality-check.sh run rather than independently reproducing it. Nothing in the diff reads as a formatting or type issue on inspection.

No blockers found. Approving.