From ee48b114f68581ccff02afd79f0a2ebf29537f4c Mon Sep 17 00:00:00 2001
From: matevip <matevip@mate.vip>
Date: Sun, 10 May 2026 08:28:26 +0800
Subject: [PATCH] chore: scrub external project references from wecom comments

---
 .../vip/mate/channel/wecom/WeComKeepaliveScheduler.java  | 2 +-
 .../wecom/cards/tool_guard/ToolGuardButtonKey.java       | 9 ++++-----
 .../wecom/cards/tool_guard/ToolGuardCardRenderer.java    | 3 +--
 3 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/mateclaw-server/src/main/java/vip/mate/channel/wecom/WeComKeepaliveScheduler.java b/mateclaw-server/src/main/java/vip/mate/channel/wecom/WeComKeepaliveScheduler.java
index 53a0b74e..b53e6db6 100644
--- a/mateclaw-server/src/main/java/vip/mate/channel/wecom/WeComKeepaliveScheduler.java
+++ b/mateclaw-server/src/main/java/vip/mate/channel/wecom/WeComKeepaliveScheduler.java
@@ -20,7 +20,7 @@ import java.util.concurrent.TimeUnit;
  * the eventual {@code finish=true} chunk is silently rejected — the
  * user sees "🤔 思考中..." stuck forever. RFC-32 §2.1.2 (R-7 / B-5).
  *
- * <p><b>Constants</b> (verified against QwenPaw {@code channel.py:66-67,986-1031}):
+ * <p><b>Constants</b> (chosen empirically based on observed slot lifetime):
  * <ul>
  *   <li>20s refresh interval — well under the observed 60s minimum drop</li>
  *   <li>180s force-finish ceiling — bound the worst-case "stuck" UX even
diff --git a/mateclaw-server/src/main/java/vip/mate/channel/wecom/cards/tool_guard/ToolGuardButtonKey.java b/mateclaw-server/src/main/java/vip/mate/channel/wecom/cards/tool_guard/ToolGuardButtonKey.java
index 2e2dcb8f..43687cb8 100644
--- a/mateclaw-server/src/main/java/vip/mate/channel/wecom/cards/tool_guard/ToolGuardButtonKey.java
+++ b/mateclaw-server/src/main/java/vip/mate/channel/wecom/cards/tool_guard/ToolGuardButtonKey.java
@@ -18,11 +18,10 @@ import java.util.Map;
  * minimal context we need to recover the pending approval (the
  * {@code pendingId} alone is enough — mateclaw's
  * {@code ApprovalService.findById} resolves the rest, including the
- * original requester). QwenPaw's approach also stuffs sender/chat
- * context for offline-render reasons; mateclaw doesn't need that
- * because the inbound handler runs in-process and can do a synchronous
- * DB lookup, leaving headroom in the 1024-byte budget for long
- * tool names / Chinese characters.
+ * original requester). Sender/chat context is intentionally not packed
+ * — the inbound handler runs in-process and can do a synchronous DB
+ * lookup, leaving headroom in the 1024-byte budget for long tool names
+ * / Chinese characters.
  *
  * <p>Encoding is stable (LinkedHashMap → consistent key order so byte-
  * length is predictable). Decoding tolerates extra fields — useful if
diff --git a/mateclaw-server/src/main/java/vip/mate/channel/wecom/cards/tool_guard/ToolGuardCardRenderer.java b/mateclaw-server/src/main/java/vip/mate/channel/wecom/cards/tool_guard/ToolGuardCardRenderer.java
index 6d94b52b..0addd2a5 100644
--- a/mateclaw-server/src/main/java/vip/mate/channel/wecom/cards/tool_guard/ToolGuardCardRenderer.java
+++ b/mateclaw-server/src/main/java/vip/mate/channel/wecom/cards/tool_guard/ToolGuardCardRenderer.java
@@ -12,8 +12,7 @@ import java.util.Map;
  * Build the WeCom {@code button_interaction} approval card payload from
  * an {@link ApprovalNotice}.
  *
- * <p>Card structure (verified against QwenPaw {@code tool_guard.py:107-140}
- * + WeCom official protocol):
+ * <p>Card structure (matches the WeCom official protocol):
  * <pre>
  * {
  *   "card_type": "button_interaction",