7 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	996201c4ed	fix(httpclient): 信封 message 默认不进错误，渠道上游自由文本一并收口 ... 信封路径（非 2xx + 信封体、2xx + code!=0）此前把上游 message 经 RedactText 拼进 error，而上游会在 message 里回显被拒的请求正文 —— 她的原话因此进了错误 与调用方日志（M49 探针实测：code 1: invalid content: 她刚才说的那句话 ...）。 - envelope message 改为**默认不带**（新 opt-in WithEnvelopeMessage()，与 trace.UpstreamError 的 message 同一口径）；code 与上游 status 保留， errors.Is 的 ErrAPI / trace.ErrUpstream 链不变。 - opt-in 下统一走单一清洗 upstreamText：压平空白 + trace.RedactTextLimited， 上限 40 rune（比 trace 的 128 短：错误里那句话是提示，不是摘要）。 - plugins/channels 同族出口一并收口（扫过全部，命中 4 处）： telegram description、qq_obv11 msg（错误 + logEchoFailure 日志）、 weixin_ilink CDN x-error-message；qq 的 status 字段改走 trace.ErrorToken 令牌守卫。被剥掉的一律由 status / error_code / retcode 承担分类。 每条新增/改写用例都做过变异验证（把字段拼回去即变红）。	2026-10-26 19:28:15 +08:00
AskaEth	fe3872ee28	fix(trace): 令牌守卫上移进 trace.UpstreamError，构造即安全 ... M48 复审的中危 finding：error.type 里的散文经 trace.UpstreamError 原样出镜， 因为守卫加在调用方（M46 的 model/voice 两处），构造函数自己不套守卫 —— 任何新调用点默认不安全，httpclient / vision / embedding / weixin 四条出口一直漏。 - trace.UpstreamError 构造时对 error.code / error.type 各走一次 ErrorToken （[A-Za-z0-9_.-]{<=64}，不合规即空串）：默认安全，不是可选加固。 - 构造后注入这条窄路收进 UpstreamErrorInfo.SetCode / SetType（同一道守卫）， 供 DashScope 顶层 code 与 Anthropic 流内 error.type 两处使用 —— 调用方不再 各抄一份 ErrorToken。 - 删除因此冗余的调用方守卫：model.providerUpstreamError 与 voice.dashscopeOKBodyError。保留 voice 的 request_id 守卫（它不是 code/type， 构造函数看不见）。 - 四条漏的出口一行没改，只加用例证明守卫上移后自动安全；摘掉构造函数守卫时 四条用例 + model/voice 旧用例同时变红。	2026-10-26 19:13:38 +08:00
AskaEth	4c187ac070	refactor(trace): 把剥 url.Error 壳的实现收敛成 trace.URLCause ... 五处逐字同形的三行（mediafetch.sanitizeErr / httpclient.transportCause / vision.fetchCause / telegram.callCause / weixin_ilink.urlFreeCause）收敛为 trace 包里的唯一实现，13 个调用点改为直接调用；5 份 body 只剩 1 份，5 个 未导出符号与其文件内注释整份删除（不留薄封装）。 行为等价：只剥 *url.Error、不新增包装，内层哨兵链（context 取消/超时、 *net.DNSError 等）原样透传，因此重试/降级/熔断的分类判据不变。两处刻意的 收紧： - 逐层剥：内层若还是 *url.Error 也一起剥（只剥一层时内层仍带同一段地址）； - *url.Error 的 Err 为 nil（或链自引用）时不再回落到原串，退化成只含 Op 的 替身 —— 那种错误无法在不带地址的前提下原样返回，而地址里就是凭据。 顺带把 httpclient 的 user:pass@ 用例改成变异可打红：net/http 自己在 *url.Error 里就把密码打成 ***，「密码不出现」在剥壳与不剥壳下都成立（空跑）， 用户名才是分水岭。 验收：go build ./... + go vet ./... + 指定包 go test -count=1 全绿； 变异验证（把 URLCause 改成透传）⇒ 五处「不含 URL」断言全红。	2026-10-26 18:45:34 +08:00
AskaEth	4b4173dd42	fix(channel): M41 r1 复审三条 —— telegram 构造分支、QQ 改 MaskQuery、删两处死上限 ... P2-1 telegram doJSON 的**请求构造**失败分支：http.NewRequestWithContext 解析失败的 err 同样是 *url.Error（里面是整条 /bot<token>/… 地址），而 poll.go 的 long poll failed 会原样落日志。改成与传输层分支同形：trace.HostOf(endpoint) + callCause。 P2-2 qq_obv11 connectClient 的成功 INFO 从 maskAccessTokenQuery 换成 trace.MaskQuery：后者认得 access%5Ftoken / token / api_key / 签名参数 / userinfo， 且保留 EscapedPath（路径可读）与不截断。maskAccessTokenQuery 仍被 sanitizeConnectReason 使用，未成死代码。 P2-3 删掉 maxEnvelopeMessageRunes / maxDescriptionRunes（各 200）：trace.RedactText 内部已 truncate 到 maxSummaryRunes=80，这两层永不命中，注释口径与实际不符。改为 直接 return trace.RedactText(压平空白)，注释写明 80 rune 由 RedactText 负责。 用例（全部变异打红，逐条验证）：telegram 构造分支 token、QQ 八形态凭据矩阵 （含四种 maskAccessTokenQuery 漏掉的形态 + 路径可读反向断言）、两处 80 rune 上限。	2026-10-26 13:58:19 +08:00
AskaEth	0f9251b983	fix(channel): 渠道适配器与出站工具的上游响应体/带凭据 URL 不再进日志与错误（M41） ... 接 M38 的 18 条真泄漏里「渠道适配器 + 出站工具」这一族（#10 #11 #12 #13 #15 #16）。 只动日志与 error 文字：发送/接收、解析口径、重试次数一个都没改。 - httpclient.do：非 2xx 不再把 512B 响应体原文拼进 error，改 trace.UpstreamError （状态/体积/sha256 前缀）+ 信封 code/message（RedactText + 200 rune）；error 里的 target 改 trace.HostOf，并剥掉 *url.Error 外壳（它带整条地址） - telegram doJSON：4xx 只解 error_code/description（清洗 + 截断），体其余字段不拼； 传输错误只留来源 —— Bot API 把 token 写在地址路径里 - weixin_ilink doJSON：4096B 体 ⇒ trace.UpstreamError，rawURL ⇒ mediafetch.HostOf； uploadOnce 剥掉预签名上传地址（encrypted_query_param），重试日志补来源主机 - qq_obv11 connectClient 成功 INFO：改走同包已有的 maskAccessTokenQuery （OneBot 惯例把 ?access_token= 写进 remote_url） - plugins/tools/io http 拦截日志：改记 trace.HostOf + 原因码，不记原 URL、也不记错误 原文（解析失败时它包着 *url.Error） 每条都有能变异打红的用例：QQ/iLink 预签名地址的哨兵、三处 4xx 体哨兵、 user:pass@ 与 query 凭据；八处变异逐条验证变红。	2026-10-26 13:47:56 +08:00
Aska	c1bd740f7c	fix(kook): KOOK 机器人鉴权用 Authorization: Bot <token> 而非 Bearer ... httpclient 硬编码 Bearer，导致 KOOK bot token 被当 OAuth2 用户令牌发， / gateway/index 返回 401『登录环境异常』。按 KOOK reference 鉴权规范， 给共享 httpclient 增加可配置 authScheme（默认 Bearer），KOOK 用 Bot。 - httpclient: 新增 WithAuthScheme 选项 + authScheme 字段，do() 按 scheme 组装 - kook/adapter: 装配时传 WithAuthScheme("Bot") - 同步修正 config.go 注释与 send/identity 测试断言	2026-09-07 16:59:53 +08:00
Aska	764d592859	feat(channel): KOOK 渠道适配器 + 框架兼容增强(wsutil/httpclient) ... - plugins/channels/kook: config/adapter/gateway/websocket/send/message/errors — 实现 PlatformAdapter 13方法 - WS 有状态网关: 取gateway地址→连WS→信令0/1/2/3/4/6 + 30s心跳/6s超时 + resume(拼接sn/session_id) + 指数退避重连 - 收事件: 信令0 → UnifiedMessage(word注 channel_type/type/target_id/extra.author→字段) - 发消息: /message/create(频道) + /direct-message/create(私聊,修正正确端点,非user-chat) + Bearer鉴权 - 注册 channels.go + CHANNELS_JSON 多账号 + channelbridge.configured 加 kook(bot_token非空才连) - 框架增强: internal/channel/adapter/wsutil(连接管理/心跳/重连/resume骨架,复用gorilla,KOOK用上) + httpclient(Bearer+envelope归一,KOOK用) - 全仓 go build/vet/test 绿, 零新依赖(复用餐gorilla), 未动telegram/qq/weixin/webhook契约 - §4.6 隔离/黑白名单/第三方边界未破坏 注: KOOK WS/WH 双模式待补(ReceiveMode), 实测需主人提供 CHANNEL_KOOK_TOKEN	2026-09-07 12:01:35 +08:00