[zhanghaohit]

What type of PR is this?

• bug fix

What this PR does and why

The install-progress "Scaling" step marked the scaler as failing whenever any LLMScaler condition had status: "False". ScalingDeferred reads the other way round: llm-operator sets it True while a rollout or scale-down settle guard holds a step back, and False otherwise (NotDeferred, or DeferralTimedOut after a forced write). So every healthy scaler showed NotDeferred in red.

Condition	Before	After
ScalingDeferred=False	bad, NotDeferred	falls through to the replica check, e.g. ok "1 replicas, steady"
ScalingDeferred=True	falls through (ignored)	wait, "Deferred: "
DecisionAvailable=False	bad	bad (unchanged)

Adds one string, steps.scaler.deferred, in both locales.

Which issue(s) this PR fixes

Fixes #100

How it was tested

• Three cases added to installSteps in lib.test.ts. Against the old scalerStep the first two fail and the third passes, which is the intended split.
• npm run typecheck, npm run build pass. npm test passes on Node 24 (the CI version): 47 files, 421 tests. On Node 25 src/shell/preferences.test.ts fails on main as well (Node's own localStorage global shadows jsdom's); unrelated to this change.
• The status in inferences: scaling step shows a healthy scaler as failing (NotDeferred) #100 was taken from a live LLMScaler on llm-operator 0.5.1-rc1.

Checks

• go test ./... and gofmt -l . is empty (no Go change)
• npm run typecheck && npm test && npm run build in web/ (if web/ changed)
• helm lint --strict helm/console (if the chart changed)
• Docs updated where behaviour, a config key or a chart value moved
• No internal hostnames, IPs, registries or credentials

Notes for reviewers

Deliberately left out: the swiss copy has the same check in components/ReleaseObjects.tsx (the scaler card badge and the condition list dots) and routes/DeploymentDetail.tsx. Per coding-conventions those are fixed upstream in modelsphere/swiss and resynced, not edited here. Until then the cluster-resources scaler card still shows NotDeferred as a warning badge.

Release note

The deployment page no longer shows a healthy autoscaler as failing with "NotDeferred"; a deferred scale step now shows as waiting with its reason.

[huskcass]

No blockers. The fix matches llm-operator's ScalingDeferred semantics (True while a rollout or settle guard holds a step back, False otherwise), and the three new tests pin the split. vitest for src/modules/inferences and typecheck pass locally.

Low, non-blocking:

• The check is still "any False except ScalingDeferred is bad". If llm-operator adds another condition where False is the normal state, it will show red again. Checking only DecisionAvailable=False as a failure would be sturdier.
• A forced write after the defer timeout (ScalingDeferred=False, DeferralTimedOut) now shows as plain ok/steady, so the step gives no hint that a guard was overridden. Fine for this fix; worth a follow-up if that case matters on the page.

Verdict: good to merge.

— Review Golden

[aceforeverd]

LGMT.

BTW, I'm adding new status field to LLMScaler e.g .status.phase and .status.message for summary, so web does not need to aware scaler logic. This patch is kept as backwards compatibility

[aceforeverd]

hold on util modelsphere/llm-operator#23 . It revised LLMScalers .status.conditions to match HPA v2. The healthy check here should match condition type ScalingActive and AbleToScale, with a fallback to old conditions if not found

[huskcass]

Re-review at b01111a.

No blockers.

Verdict: scalerStep matches the condition contract in llm-operator docs/llmscaler.md for new and old objects; typecheck, tests and build pass locally and the gate/go/web checks are green. Mergeable.

— Review Golden

[huskcass]

No blockers.

Comment and test-only follow-up: the scalerStep comment now matches the operator behavior, and the three added cases cover the remaining edge cases; logic unchanged. Good to merge.

— Review Golden

[huskcass]

Re-review at dea3127.

No blockers.

Verdict: the step now reads operator v0.5.0 objects correctly (Custom DecisionAvailable True/False, Prometheus with no conditions) and the AbleToScale/ScalingActive handling is unchanged from b01111a; typecheck, tests and build pass locally and the gate/go/web checks are green. Mergeable.

— Review Golden