DanielLavrushin 指出 b4 Discovery 卡片与历史记录的确认状态错配

DanielLavrushin 指出，b4 Discovery 结果卡片和历史记录会把站点最快预设的确认结果用于实际提供的组获胜策略，可能显示未经复核的策略为“Confirmed 3/3”，也可能把已通过确认的策略显示为未确认。他建议优先读取所提供策略自身的结果，仅在该结果不存在时回退到站点级数据，并让实时卡片也将取消的运行视为未确认。

作者原文@DanielLavrushin
Problem
The Discovery result card and History show the confirmation of a site's fastest preset next to the strategy the card offers, the group winner. When the two differ, the label can be wrong both ways:
After Stop now lands between the two confirmations, the card shows a green "Confirmed 3/3" for an offered strategy that was never re-checked.
When the fastest preset failed confirmation and the offered strategy passed 3 of 3, the card says "Not confirmed" while its own caption shows "Confirmed 3/3".
Evidence
recordConfirmation writes the domain-level Confirmed/ConfirmTries only for the domain's best preset (src/discovery/confirm.go:243-246), and Unconfirmed is derived from them.
confirmationOf (src/http/ui/src/utils/discovery.ts) falls back through ?? to the domain-level counts, because the offered strategy's own zero counts are dropped by omitempty.
pushGroup uses dr.unconfirmed only when it is true. In History, historyUnconfirmed and the confirmed chip (HistoryTable.tsx) read the entry's domain-level fields.
The live card ignores a cancelled run, while History treats it as unconfirmed.
The fallback dates from #349. #490 fixed the same mismatch for the MCP tool, where it was new.
Suggested direction
Use the same rule as #490's MCP fix:
Take the confirmation from the offered strategy's own result whenever that result exists, and fall back to the domain-level fields only when it is missing.
Treat a cancelled run as unconfirmed on the live card too.
There is no UI test framework, so the fix can be checked against buildResultEntries and historyUnconfirmed with saved suite JSON, as was done for #490.
Copilot's comment on #490: https://github.com/DanielLavrushin/b4/pull/490#discussion_r4437378624

返回动态列表查看原文