mirror of
https://gitee.com/mateos/mateclaw.git
synced 2026-09-13 03:13:41 +08:00
b478eef78c
Before this, a workflow await_approval step whose approverChannels pointed at feishu/wecom was effectively dead for IM interaction. Even after PR #414 (B1) pushed the notice to the IM group, clicking the card's Approve/Deny buttons did nothing useful: - Identity check (requester==clicker) failed-closed: wf- approvals have userId=null (system-initiated), so every click was rejected. - Even if it passed, the synthetic /approve injection was a dead end: the router routes by conversationId, but wf- ids use a synthetic workflow:run:{runId} key that no IM conversation matches, so findPendingByConversation returned null and the /approve was fed to the LLM as plain text. B3 fix: both ToolGuardCardHandlers now detect the wf- prefix and resolve inline (approvalService.resolve), bypassing the synthetic injection entirely. The WorkflowApprovalResolvedEvent published inside resolve is picked up by ApprovalResumeBridge (activated in PR #414 B2), which resumes the paused run. This mirrors the Web / WebChat resolve path (PR #415). Identity policy: any audience member may resolve a wf- approval. The card only reaches channels declared in await_approval's approverChannels, so whoever sees it is a designated approver. Regular tool approvals keep the strict requester==clicker guard. Tests: - wecom ToolGuardCardHandlerTest: +2 wf- cases (inline resolve, no synthetic injection; already-resolved renders expired). Existing 6 cases updated for the new 3-arg constructor. - feishu FeishuCardDispatcherTest: updated for the new factory constructor signature. Regression: ApprovalWorkflowServiceResolveTest (13), GcTest (7), RecoveryTest (7), feishu dispatcher (4), button value (7), renderer (3+3) — all green. |
||
|---|---|---|
| .. | ||
| src | ||
| Dockerfile | ||
| pom.xml | ||
| settings.xml | ||