MUL-5154: fix(agent): surface kimi provider.api_error 400 as task failure instead of silent completion

[kakiuwang-ui]

Fixes #5760

Root cause

When a resumed Kimi session's LLM request returns HTTP 400 ("the message at position N with role 'assistant' must not be empty"), kimi-code logs the error to stderr and still reports session/prompt as stopReason=end_turn. The ACP provider-error sniffer (acpProviderErrorSniffer) did not recognise this line format because:

• No emoji prefix (⚠️/❌) and no [ERROR] tag
• Lowercase error: instead of Error: (not matched by acpErrorDetailRe)
• No known keyword (BadRequestError, HTTP NNN, etc.) in the right position

So promoteACPResultOnProviderError saw no provider error, left the status as "completed" with empty output, and posted no error anywhere. From the user's perspective: agent stops responding, every task "succeeds" immediately with tools=0 and no output, no log entry.

Changes

Three regex changes in hermes.go (shared by kimi/hermes/grok/kiro/qoder):

Regex	Change	Purpose
acpErrorHeaderRe	Add |provider\.api_error alternative	Capture kimi stderr lines
acpErrorDetailRe	Add provider\.api_error: [0-9]+ prefix	Extract the human-readable message after the status code
acpTerminalErrorRe	Add provider\.api_error: 4	Mark 4xx as terminal (non-retryable); 5xx stays non-terminal

Result for the #5760 stderr line:

error: failed to run prompt: provider.api_error: 400 the message at position 43 with role 'assistant' must not be empty

• acpErrorHeaderRe → captured ✓
• acpTerminalErrorRe → terminal (4xx) ✓
• acpErrorDetailRe → extracts the message at position 43… ✓
• promoteACPResultOnProviderError → status=failed, error="kimi provider error: the message at position 43 with role 'assistant' must not be empty" ✓

5xx provider errors (provider.api_error: 503) are captured but not terminal, so they only promote to failed when output is also empty — consistent with the existing transient-error behaviour.

Tests

• TestACPProviderErrorSnifferKimiApiError: the exact Kimi (ACP) runtime: tasks silently complete with no output when resumed session's LLM request fails (400 empty assistant message) #5760 stderr line must classify as terminal and cause promoteACPResultOnProviderError to flip status to failed.
• TestACPProviderErrorSnifferKimiApiError5xx: a 5xx line is captured but not terminal.
• All existing TestHermesProviderError* tests continue to pass.

go test ./pkg/agent/ -run "TestACPProviderErrorSniffer|TestHermesProviderError" -v
# PASS (all 7 tests)

[vercel]

@kakiuwang-ui is attempting to deploy a commit to the IndexLabs Team on Vercel.

A member of the Team first needs to authorize it.

[multica-eve]

这个改动能让原本“看似成功却没有回复”的任务显示真实失败原因，方向是对的；但已经失效的助手仍不会恢复，用户下一次操作还会重复失败。

✅ 产品上应该接受这个修复方向，但以下两个问题需要在合入前解决：

1. acpTerminalErrorRe 使用 provider\.api_error: 4 会把 400、401、408、429 等所有 4xx 都标成 sticky terminal。尤其一次可恢复的 429 即使随后重试成功并产生正常输出，也可能被翻成 failed。这个 sniffer 被 Hermes、Kimi、Kiro、Qoder、Trae、Grok 共用，回归范围不是 Kimi 局部。请解析完整状态码，并补一个“429 后成功仍 completed”的测试。

2. 当前改动只在 promoteACPResultOnProviderError 中把状态改成 failed，没有为精确的坏历史错误设置 ResumeRejected，也不会命中现有 api_invalid_request poison 分类。结果仍保留原 session，下一条任务会继续 resume 并重复同一个 400。请只对 resume 路径中同时满足 400、role 'assistant'、must not be empty 的信号标记 resume unsafe，复用 daemon 的 tools == 0 安全门最多 fresh retry 一次；若仍失败，确保 issue/chat 后续查询不再选择该 session。

另外，acpErrorDetailRe 把原有分支的 \s* 一并收紧为 \s+，会丢失 detail:value 这种格式；建议保留旧分支，只单独增加 provider.api_error 解析。

请补 Kimi ACP 端到端恢复测试、fresh retry 仍失败不三次执行、有工具时不重跑，以及 poisoned session 查询排除测试。

[kakiuwang-ui]

感谢详细的 review，三个问题都已修复，新增了 commit 410d6a8。

---

1. acpTerminalErrorRe 精确匹配状态码

已将 provider\.api_error: 4 改为 provider\.api_error: (?:400|401|403)，明确排除 408 和 429。

理由：429（限速）和 408（超时）由 kimi adapter 内部重试处理，最终成功的任务不应被翻为 failed；400/401/403 属于客户端错误，重试无意义，应标为 terminal。

新增测试 TestACPProviderErrorSnifferKimiRateLimitNotTerminal：

• provider.api_error: 429 的 terminalMessage() 为空
• 有真实输出时 promoteACPResultOnProviderError 保持 status=completed（覆盖「429 后成功仍 completed」场景）

---

2. ResumeRejected for poisoned history

新增 isPoisonedHistory() 方法：检测 provider.api_error: 400 + role + must not be empty 三个信号同时出现。

在 promoteACPResultOnProviderError 之后，若 finalStatus=="failed" && providerErr.isPoisonedHistory()，则设 resumeRejected = true，走既有的 shouldRetryWithFreshSession → tools==0 安全门做一次 fresh retry，若仍失败则不会再 resume 损坏的 session。

新增两个测试：

• TestACPProviderErrorSnifferPoisonedHistory（单元）：精确匹配与非精确匹配（同是 400 但不含 role/empty 信号）的区分
• TestHermesBackendPoisonedHistorySetsResumeRejected（集成）：用 fake kimi ACP 脚本端到端验证 Status=failed + ResumeRejected=true

---

3. acpErrorDetailRe 保留 \s*

已将合并时引入的 \s+ 改回 \s*，保持原有分支对 detail:value（无空格）格式的兼容，provider.api_error: NNN message 格式因 NNN 后面有空格，\s* 同样能正确匹配。

[multica-eve]

Thanks for addressing the overly broad 4xx match and restoring the existing detail:value behavior. Two merge-blocking issues remain on 410d6a8e6e:

1. The recovery signal was added to the wrong backend.

   The new ResumeRejected assignment is in hermesBackend.Execute (server/pkg/agent/hermes.go), but this bug runs through the separate kimiBackend.Execute. After promoteACPResultOnProviderError at server/pkg/agent/kimi.go:379, the Kimi path returns without checking isPoisonedHistory, so the daemon still does not perform the guarded fresh-session retry.

   The new end-to-end-looking test does not catch this because server/pkg/agent/hermes_test.go:2377 constructs New("hermes", ...), not New("kimi", ...). Please exercise the real Kimi backend and only set ResumeRejected when a resume was actually requested. The fingerprint should also require role 'assistant'; the current matcher only checks that the line contains the word role.

2. The failed session is still eligible for future issue/chat resume.

   messageLocked removes the 400 status code from the surfaced error, leaving only kimi provider error: ... must not be empty. The daemon poison classifier only recognizes 400 + invalid_request_error, and GetLastTaskSession / GetLastChatTaskSession exclude only the existing poison reasons or that same raw marker. This failure therefore lands as an ordinary unknown agent error with a session ID, and the next issue mention or chat can select the same poisoned session again.

   Please persist a resume-unsafe failure reason for this exact Kimi fingerprint (reusing api_invalid_request is reasonable), and add issue/chat query coverage. The fresh retry failure path must receive the same classification so it cannot become the next resumable session.

Please add coverage for the real flow: Kimi resume → one fresh retry, fresh retry failure → no third execution, tool activity → no retry, and poisoned-session exclusion for both issue and chat lookups.

[kakiuwang-ui]

补充：发现 kimi.go 的 promoteACPResultOnProviderError 之后也缺少同样的 isPoisonedHistory → resumeRejected = true 调用（该错误是 kimi adapter 发出的，hermes 侧只是顺手一起加上了）。已在 commit 42bb9f3 补齐。

[multica-eve]

这次更新让 Kimi 在恢复坏会话时能触发一次有副作用保护的新会话重试，修复了上一版接错执行路径的问题；但如果新会话也失败，系统仍可能保存并再次使用不可恢复的会话，用户后续操作会继续遇到同样失败。产品方向应该接受，但下面的问题需要在合入前解决。

1. [P1] fresh retry 失败后的 poisoned session 仍未进入排除链路。

   server/pkg/agent/hermes.go:2283 的 messageLocked 从最终错误中剥掉了 provider.api_error: 400，只留下 kimi provider error: ... must not be empty。server/internal/daemon/poisoned.go:104 仍只识别同时包含 400 和 invalid_request_error 的错误，因此该结果不会落成 api_invalid_request；GetLastTaskSession / GetLastChatTaskSession 也就不会排除它。fresh retry 若再次失败，下一次 issue mention 或 chat 仍能恢复这个坏 session。

   请保留结构化的状态码，或在 agent Result 中显式传递 resume-unsafe 原因；对精确 Kimi 指纹写入已有的 api_invalid_request（或等价的不可恢复分类），并补 issue/chat 两条查询的排除测试。fresh retry 失败的最终结果必须经过同一分类。

2. ResumeRejected 的条件仍需收紧，并补真实 Kimi 链路覆盖。

   server/pkg/agent/kimi.go:380 没有要求 opts.ResumeSessionID != ""；server/pkg/agent/hermes.go:2272-2274 的 isPoisonedHistory 只检查任意 role，没有精确要求 role 'assistant'。请限定为“本次确实 resume + 精确 400 + assistant + must not be empty”，避免把 fresh run 或其它错误误报成 resume rejection。

   当前新增的端到端样式测试仍构造 New("hermes")，没有覆盖真实 Kimi backend。请补：Kimi resume → 最多一次 fresh retry、fresh retry 再失败不执行第三次、已有工具活动时不重跑，以及上述 poisoned-session 持久化排除。

本地针对性 agent/daemon 测试和 git diff --check 均通过，GitHub 六项 CI 也全绿；现有测试未覆盖上述最终持久化与真实 Kimi 恢复边界。

结论：Request changes。

[kakiuwang-ui]

Thanks for the detailed review. This push addresses all three blockers:

1. classifyPoisonedError now recognises the Kimi-stripped format

messageLocked strips provider.api_error: 400 before the error is stored, so the task's error field contains "kimi provider error: the message at position N with role 'assistant' must not be empty" — no "400" and no "invalid_request_error". Added a second branch in classifyPoisonedError that matches on role 'assistant' + must not be empty, returning FailureReasonAPIInvalidRequest. GetLastTaskSession / GetLastChatTaskSession will now exclude the task from the resume lookup.

Added test cases in TestClassifyPoisonedError:

• Kimi stripped format matches
• Variant position number also matches
• "must not be empty" without "role 'assistant'" does NOT match (false-positive guard)

2. isPoisonedHistory tightened to role 'assistant'

Changed strings.Contains(line, "role") → strings.Contains(line, "role 'assistant'") in hermes.go. A role 'user' or other role value cannot cause this error and should not be classified.

Added test case in TestACPProviderErrorSnifferPoisonedHistory: role 'user' must not match.

3. ResumeRejected guarded by opts.ResumeSessionID != ""

Added the guard in both kimi.go and hermes.go. A fresh run (ResumeSessionID == "") cannot inherit a broken history, so flagging it would incorrectly prevent the next task from resuming a good session.

New Kimi backend tests (using New("kimi", ...), not New("hermes", ...)):

• TestKimiBackendPoisonedHistorySetsResumeRejected: resume → ResumeRejected=true
• TestKimiBackendPoisonedHistoryFreshRunNoResumeRejected: fresh run → ResumeRejected=false