Cyrene_v2

618 Commits 7 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	b4d55f412e	fix(channel): 连接动作不再乐观 —— 适配器自报连接态三态 + 面板如实呈现 CI / Backend (build / vet / test / cross-compile) (push) Has been cancelled Details CI / Frontend (tsc + vite build) (push) Has been cancelled Details 根因：adminChannelOpen 在 ch.Connect 返回 nil 后硬编码 connected=true。而 Connect 返回 nil 只说明「这次调用没有致命失败」—— ws+client 首连失败刻意非致命（OneBot 实现可能比 Cyrene 后启动），ws+server 则只需监听就绪，两种情况 IsConnected() 都是 false。前端又只按「请求成功」写死「已连接」，于是管理面把「后端受理了」说成「渠道连上了」。改法：三态口径落在适配器自己身上（connected/pending/ready，internal/channel/adapter 的纯函数 ConnectStateOf 判定 + ConnectSignals 结构化入参，避免两个 bool 接反），qq_obv11 实现 ConnectOutcome 并记住脱敏后的失败原因；网关经类型断言探测（与 accountStatusAware/rescanAware 同套路，核心 sdk.Channel 契约刻意不扩展），只做映射不猜 transport/mode。线上投影：open/close 响应与 GET /admin/channels 的平台行/账号行各新增 pending/ready/reason 三个可选键（零值即整键缺席，同 NeedsRescan/LastError 口径）；既有四键逐字不变，未实现该状态面的平台输出逐字节不变。close 报真实 IsConnected()，断开也不乐观。凭据边界：reason 三层脱敏（形状级 → 已知明文替换 → 剥 access_token= 查询参数），日志同样只用脱敏串。验收：主会话亲自复跑 go build/vet 全绿、全树 go test 无 FAIL、目标三包 test 全绿、前端 tsc --noEmit 干净、esbuild 逻辑测试 34+46 checks 全过；主会话亲自变异摘掉第 3 层脱敏实现，发现原两条脱敏用例其实钉不住它（值恰好等于已知明文/被形状级顺带吃掉）⇒ 补一条钉住它独有窗口的用例（短值+紧邻空白），变异下必红、还原后绿。	2026-10-13 19:38:56 +08:00
AskaEth	42279b7124	feat(channels): 按账号连接/断开 + 可删空 id 条目（修主人真机踩的两个缺口）缺口①：「连接」是按平台连、且恒打第一条账号（channelActionRequest 只有 name）⇒ 主人有两条 qq-obv11 时点到的是 mode=server 的历史条目，报 server mode requires listenAddr，而正确的 client 条目轮不到。缺口②：空 id 条目既删不掉（DELETE 要求 id 非空）也改不了（UpsertChannel 空 id = 新建），越改越多。后端： - POST /admin/channels/open\|close 请求体新增可选 accountId（缺省逐字兼容，老客户端零影响）；按该账号驱动；未知 id ⇒ 404 且零连接（不静默回落第一条）；已配置未注册 ⇒ 409 - DELETE /admin/channels/{platform}/config 新增显式 empty=1（id 与 empty=1 互斥 ⇒ 400；无可删 ⇒ 404）；语义严格 —— 只删空 id 条目，绝不把「id 为空」默认解释成删空 id - 响应新增：open/close 的 resolved（实际驱动的适配器名）与 accountId；delete 的 removed/empty； GET /admin/channels 的 accounts[].connected（可选 bool，缺省 = 未知） - 审计动作名不变（channel.open/close/delete），日志行新增 accountId 字段前端：每条账号一行「连接/断开」（带 accountId）；按钮旁明确「会连哪一条」；空 id 行显著标注 + 删除入口；channelActionBody 携带 accountId；新增 action 测试 33 checks + 空 id 行渲染 31 checks。测试：后端 14 个用例（真实 HTTP 路由 + JWT + 真注册表 + spy 适配器，断言「哪一条被驱动、另一条一次都没被碰」）。变异 6 条（accountId 被忽略 / id 为空当删空 id / 找不到静默回落 / 前端丢 accountId / 删空 id 退化成 ?id= / 空 id 行按普通行渲染）。	2026-10-05 10:37:56 +08:00
Aska	5a0c1e2fd1	fix(channelbridge): IM 发送过滤 action/narration + <p>拆多气泡 + 0.5-2s 间隔 CI / Backend (build / vet / test / cross-compile) (push) Has been cancelled Details CI / Frontend (tsc + vite build) (push) Has been cancelled Details 把回复转发给 IM 适配器(sendReply)时剥掉 <action>/<narration> 动作/内心独白(Web 端才渲染灰斜体，IM 只能收纯文本)，并按 <p> 段落拆成多条气泡分别发送；多气泡发送间隔随机 0.5~2s(仅 IM，Web 前端不延迟)。新增 sanitize.go stripNarration/splitBubbles/ bubbleGap + 测试。	2026-09-07 17:50:56 +08:00

Author

SHA1

Message

Date

AskaEth

b4d55f412e

fix(channel): 连接动作不再乐观 —— 适配器自报连接态三态 + 面板如实呈现

CI / Backend (build / vet / test / cross-compile) (push) Has been cancelled

Details

CI / Frontend (tsc + vite build) (push) Has been cancelled

Details

根因：adminChannelOpen 在 ch.Connect 返回 nil 后硬编码 connected=true。而 Connect 返回 nil 只说明「这次调用没有致命失败」—— ws+client 首连失败刻意非致命（OneBot 实现可能比 Cyrene 后启动），ws+server 则只需监听就绪，两种情况 IsConnected() 都是 false。前端又只按「请求成功」写死「已连接」，于是管理面把「后端受理了」说成「渠道连上了」。

改法：三态口径落在适配器自己身上（connected/pending/ready，internal/channel/adapter 的纯函数 ConnectStateOf 判定 + ConnectSignals 结构化入参，避免两个 bool 接反），qq_obv11 实现 ConnectOutcome 并记住脱敏后的失败原因；网关经类型断言探测（与 accountStatusAware/rescanAware 同套路，核心 sdk.Channel 契约刻意不扩展），只做映射不猜 transport/mode。

线上投影：open/close 响应与 GET /admin/channels 的平台行/账号行各新增 pending/ready/reason 三个可选键（零值即整键缺席，同 NeedsRescan/LastError 口径）；既有四键逐字不变，未实现该状态面的平台输出逐字节不变。close 报真实 IsConnected()，断开也不乐观。

凭据边界：reason 三层脱敏（形状级 → 已知明文替换 → 剥 access_token= 查询参数），日志同样只用脱敏串。

验收：主会话亲自复跑 go build/vet 全绿、全树 go test 无 FAIL、目标三包 test 全绿、前端 tsc --noEmit 干净、esbuild 逻辑测试 34+46 checks 全过；主会话亲自变异摘掉第 3 层脱敏实现，发现原两条脱敏用例其实钉不住它（值恰好等于已知明文/被形状级顺带吃掉）⇒ 补一条钉住它独有窗口的用例（短值+紧邻空白），变异下必红、还原后绿。

2026-10-13 19:38:56 +08:00

AskaEth

42279b7124

feat(channels): 按账号连接/断开 + 可删空 id 条目（修主人真机踩的两个缺口）

缺口①：「连接」是按平台连、且恒打第一条账号（channelActionRequest 只有 name）⇒ 主人有两条
qq-obv11 时点到的是 mode=server 的历史条目，报 server mode requires listenAddr，而正确的
client 条目轮不到。缺口②：空 id 条目既删不掉（DELETE 要求 id 非空）也改不了（UpsertChannel
空 id = 新建），越改越多。

后端：
- POST /admin/channels/open|close 请求体新增可选 accountId（缺省逐字兼容，老客户端零影响）；
  按该账号驱动；未知 id ⇒ 404 且零连接（不静默回落第一条）；已配置未注册 ⇒ 409
- DELETE /admin/channels/{platform}/config 新增显式 empty=1（id 与 empty=1 互斥 ⇒ 400；
  无可删 ⇒ 404）；语义严格 —— 只删空 id 条目，绝不把「id 为空」默认解释成删空 id
- 响应新增：open/close 的 resolved（实际驱动的适配器名）与 accountId；delete 的 removed/empty；
  GET /admin/channels 的 accounts[].connected（可选 bool，缺省 = 未知）
- 审计动作名不变（channel.open/close/delete），日志行新增 accountId 字段
前端：每条账号一行「连接/断开」（带 accountId）；按钮旁明确「会连哪一条」；空 id 行显著标注
+ 删除入口；channelActionBody 携带 accountId；新增 action 测试 33 checks + 空 id 行渲染 31 checks。
测试：后端 14 个用例（真实 HTTP 路由 + JWT + 真注册表 + spy 适配器，断言「哪一条被驱动、
另一条一次都没被碰」）。
变异 6 条（accountId 被忽略 / id 为空当删空 id / 找不到静默回落 / 前端丢 accountId /
删空 id 退化成 ?id= / 空 id 行按普通行渲染）。

2026-10-05 10:37:56 +08:00

Aska

5a0c1e2fd1

fix(channelbridge): IM 发送过滤 action/narration + <p>拆多气泡 + 0.5-2s 间隔

CI / Backend (build / vet / test / cross-compile) (push) Has been cancelled

Details

CI / Frontend (tsc + vite build) (push) Has been cancelled

Details

把回复转发给 IM 适配器(sendReply)时剥掉 <action>/<narration> 动作/内心独白(Web 端
才渲染灰斜体，IM 只能收纯文本)，并按 <p> 段落拆成多条气泡分别发送；多气泡发送间隔
随机 0.5~2s(仅 IM，Web 前端不延迟)。新增 sanitize.go stripNarration/splitBubbles/
bubbleGap + 测试。

2026-09-07 17:50:56 +08:00