Your Name
ac8f0cf315
补上好友申请前后关系状态聊天页的入口，并把验证留言渲染成真实消息气泡
...
第3章要求pending_inbound/pending_outbound/none/blocked几种关系状态都能在真实聊天
窗口里看到（参考图 个人对话框（对方的状态）/（我的状态）.png、开启沟通页面.png）。
messages-view.jsx里对应的横幅逻辑（"以上是打招呼的消息"/"好友申请正在等待处理"等）
本身早就是对的，但排查发现两个问题：
1. 全项目没有任何入口能导航进这个视图——"新朋友"列表(FriendRequests)每一行没有
onClick；好友个人主页(Profile)非好友分支只显示一段cannotAddReason纯文字，没有
任何可点击进聊天的按钮。发起方和接收方在成为好友之前都完全看不到这个视图。
2. 验证留言原文（发好友申请时填的那段话，存在im_friend_requests表的message字段，
不是真实Tinode消息，没有走topic.publish()）没有被当作消息渲染出来，参考图里
明确是作为聊天页第一条消息气泡展示的。
修复：
- contact-management-view.jsx: FriendRequests每一行加onClick，用(onCreateTopic||
onTopicSelected)跳进对应聊天（同一套Profile.openChat已经验证过的冷启动安全写法，
接受/拒绝按钮补stopPropagation不受影响）；Profile非好友分支（blocked_by_peer/
blocked_by_me/pending_inbound/pending_outbound）补一个"查看聊天"按钮，跟
cannotAddReason文字并排展示（不复用people-profile-actions的两列grid，那是给
发消息+音视频通话两个平级按钮设计的）。ContactManagementView/sidepanel-view.jsx
早前就已经把onCreateTopic透传到位，这次只是多接一层。
- messages-view.jsx: loadRelationshipContext新增loadPendingRequestMessage，
relationship是pending_inbound/pending_outbound时，用relationshipContext自带的
request_id去GET /friend-requests换真实留言文本（没有留言用参考图默认文案"请求
添加你为好友"兜底），渲染成一条合成的消息气泡插在消息列表最前面（不进
messageNodes、不调用发消息接口）——pending_inbound左对齐、pending_outbound右
对齐，气泡样式直接复用chat-message.jsx真实消息已经在用的.bubble/.left/.right
这套CSS（app里"发出的"气泡实际是这套已实现的浅色而非参考图的蓝色，保持跟同一
会话里其它真实消息一致，不単独改这一条的颜色去凑旧版参考图）。
验证：真实两个新账号（vcm909641发起→hankqa14b接收）走了一遍完整流程——
从"新朋友"列表点击行正确进入聊天页，留言气泡+"以上是打招呼的消息"横幅正确显示；
从Profile页"查看聊天"进入，留言气泡右对齐+"好友申请正在等待处理"横幅正确显示；
点"通过验证"接受申请后正确留在列表页不误触发导航；接受后重新打开同一会话，
合成气泡正确消失，被真实的"你们已成为好友，现在可以开始聊天了。"系统消息取代，
无残留/无重复。
2026-09-06 17:24:36 +08:00
Your Name
0d2637861d
修复好友个人主页"发消息/音视频通话"对零消息历史的新好友必现"消息已禁用"
...
根因：Profile.openChat() 一直只调用 onTopicSelected（tinode-web.jsx 的 handleTopicSelected），
这个函数只负责"切换到某个已知 topic"，从不发送原生 Tinode {sub} 请求。对一个从未被任何一方
订阅过的全新 P2P 会话（刚通过好友验证、双方都还没发过消息），本地没有缓存的 topic 订阅信息，
messages-view.jsx 的 isWriter 因此永远停在初始值 false，输入框被替换成"消息已禁用"提示且没有
任何入口能发出第一条消息——对每一个"刚加好友、还没聊过天"的真实场景都 100% 必现，不是边缘情况。
tinode-web.jsx 里其实已经有正确处理这个情况的 handleStartTopicRequest（通过 onCreateTopic prop
暴露）：判断 topic 是否已缓存，没有缓存就先设置 sub.mode 为完整权限再切换，已缓存则直接退化成
普通的 handleTopicSelected，两种情况都能正确处理。问题是 sidepanel-view.jsx 渲染
ContactManagementView（好友个人主页/群成员资料页所在文件）时，只透传了 onTopicSelected，
从未把 onCreateTopic 一起传下去，导致 Profile 组件即使想调用正确的入口也拿不到。
修复：sidepanel-view.jsx 补上 onCreateTopic 的透传；contact-management-view.jsx 的
ContactManagementView/Profile 都新增接收这个 prop，openChat 优先调用 onCreateTopic
（不可用时兜底回退到原来的 onTopicSelected，避免类型不匹配报错）。
验证：用两个全新注册、互加好友但零消息历史的真实账号（ch7test1/ch7test2）在浏览器里复现——
修复前点"发消息"进入会话后输入框区域固定显示"消息已禁号"且没有任何输入控件，WS 日志确认
自始至终没有对该 p2p topic 发过 {sub}；修复后点"发消息"能看到真实的 {sub} 请求（带
acs.mode: JRWPA）、输入框正常出现，并成功发送/收到多条真实文本消息。
2026-09-06 16:38:46 +08:00
Your Name and Claude Sonnet 5
5ddace97f4
修复好友资料/验证页对"当前关系"的两处判断遗漏，与已有的好友申请状态机修复形成完整闭环
...
现象一：Profile 组件（好友/陌生人资料页）在 getConversationContext 回来后只合并了
relationship 字段，没有一并合并 capabilities——这个组件判断"能否显示添加好友按钮"
用的是 profile.capabilities.can_add_friend，不是 relationship 本身。已实测复现：
刚发送好友申请、relationship 已经变成 pending_outbound 时，若走的是"直接刷新这个
资料页"而不是 Verification 组件自己的发送成功回调（该回调已由另一处提交单独修复），
canAdd 依然读到发送前搜索结果种子里的 can_add_friend:true，"添加好友"按钮继续可点，
可再次触发一次好友申请（配合后端不去重的缺口——新增44）。
现象二：Verification 组件（好友验证/发送申请页）完全没有用 getConversationContext
校正过 relationship，只依赖 getUserProfile——但该接口对非好友直接 403，403 时的
catch 分支什么都不做。真实复现：本次会话内先成为好友、再解除好友关系后，若该好友的
profile-seed 缓存还留着"好友"时期的旧数据，重新打开验证页会一直显示"你们已经是
好友了"，且不提供发送框，除非整页刷新清掉内存缓存，否则无法向这个人重新发起好友申请。
修复：两处都在 getConversationContext 成功回调里，把它返回的字段当作当前关系的权威
来源合并进本地 profile 状态——Profile 一并合并 capabilities（而不只是 relationship），
Verification 补上原本没有的 getConversationContext 调用去合并 relationship。
验证：真实浏览器操作，两个全新注册账号之间反复走查——(1) 发送好友申请后直接刷新
资料页，"添加好友"按钮正确消失、显示"好友申请正在等待验证"；(2) 成为好友后互相
删除好友关系，立刻重新打开验证页，正确显示可发送的验证留言表单，不再卡在"你们已经
是好友了"。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 15:41:36 +08:00
Your Name and Claude Sonnet 5
51e0fc420f
修复发送好友申请后个人资料页仍显示可点击的"添加好友"按钮
...
现象：搜索陌生人->进入资料页->点"添加好友"->发送验证留言成功后，
无论是验证页800ms后的自动跳转、还是手动点返回，回到这个人的资料页时
仍然显示"添加好友"主按钮（本应显示"好友申请正在等待验证"提示文案），
且这个按钮此时仍可点击，会打开验证页再次发起一次申请（配合后端
好友申请不去重的缺口——新增44——实际造成同一个人收到多条重复申请）。
根因：发送成功后 Verification 组件把 profile-seed 缓存的 relationship
patch 成了 pending_outbound，但没有同步更新 capabilities.can_add_friend
——Profile 组件判断是否展示"添加好友"按钮的 canAdd 变量读的是
profile.capabilities.can_add_friend，不是 relationship 本身，遗留的
can_add_friend:true（原样来自发送前的搜索结果种子缓存）导致按钮继续显示。
修复：发送成功后 patch 缓存时把 capabilities.can_add_friend 一并设为
false，和 relationship 保持同步。
验证：真实浏览器操作，两个全新注册账号之间，搜索->进入资料页->添加好友
->发送验证留言，自动跳转回资料页后正确显示"好友申请正在等待验证"，
"添加好友"按钮消失，无法重复发起申请。
第14+轮最小粒度测试 Ch3-4 发现（好友申请气泡状态机场景）。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 15:35:50 +08:00
Your Name and Claude Sonnet 5
89fdd31cd4
通讯录/新朋友/黑名单列表区分"加载失败"与"真的是空"
...
三处都用 .catch(() => {}) 吞掉网络错误，loading 结束后空数组直接落到
"暂无好友"/"暂无新朋友申请"/"黑名单为空"，加载失败和真的没数据在界面
上无法区分。改成 group-management-view.jsx 里 11 处同类组件已经在用
的 loadError 状态模式。
第十轮最小粒度测试 Ch5-6 发现。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 00:57:17 +08:00
Your Name and Claude Sonnet 5
d759f67b11
第八轮最小粒度测试：修复CSS选择器/JSX结构不匹配的一整类bug，清理Tinode品牌残留
...
第八轮改用"读CSS选择器+核对JSX结构"的方式复测全部11章，命中了7轮纯接口测试从未发现的一类
问题——选择器写对了但目标元素的实际DOM结构/className对不上，样式静默失效：
- 语音通话最小化胶囊按钮尺寸被同特异度规则覆盖；移动端悬浮通话窗口left/right/width三值同时
生效导致过度约束；来电全屏页认证徽章/姓名标题缺少专属样式覆盖
- 我的收藏-语音卡片三列grid对应实际只有1个子元素，播放器被压缩到卡片左侧一角；链接/记录头部
完全没有基础样式，退化成浏览器默认外观
- 多选模式下"收到的"消息气泡被flex auto-margin一起拖到最右侧；.avatar-box/#send-message-panel
两处逗号断句错误导致后半句选择器丢失祖先限定
- 按住说话悬浮反馈渲染成内联胶囊，而参考图要求的居中悬浮卡片样式其实已经存在（挂在了另一个非
生产demo组件上）；批量转发确认框沿用了80%视口高度；audio-player.jsx的playback类点在canvas
上而非包裹层，波形和计时器可能纵向堆叠
- "消息已撤回"占位符误拼了日期分隔条的class而非专属的deleted
品牌清理：浏览器标签页标题、未读数标题更新均硬编码"Tinode"；LINK_CONTACT_US等三个链接常量
指向开源Tinode项目自己的域名（联系我们改为跟用户条款/隐私协议一致的toast，不再发起外部mailto）。
以及：空会话丢失.chat-box样式类、青少年模式PIN定位、若干收藏/文件类型展示细节。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-05 17:09:42 +08:00
Your Name and Claude Sonnet 5
bede45fd7f
第七轮深度测试：修复7个agent发现的12处前端问题，重点是列表分页截断与呼叫/播放状态机
...
- 通话状态机（Ch8）：canStartCall 补齐通话中重复发起的防护，callShouldStart 补齐放弃/失败路径的清理
- 分页截断（Ch5-6）：新增 fetchAllPages 辅助函数，修复通讯录/黑名单/好友申请/群成员/管理员/禁言等
11 处列表只读首页导致真实成员被遗漏的问题；群角色判断改用不受分页影响的 getGroup().my_role
- 消息与媒体（Ch3-4/Ch7/Ch9）：录音超时污染时长、手动重试丢失 head 导致消息被错误分类、批量删除
未取消上传中附件、语音播放器补齐同时只能播一条、workplace-collaboration-view 冗余重试请求
- 独立密码/青少年模式（Ch10-11）：设置密码后按调用来源判断是否应自动开启青少年模式，避免关闭流程
中途"忘记密码"被误当成开启；注销账号确认文案补充群主后果说明
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-05 12:18:25 +08:00
Your Name and Claude Sonnet 5
4a30cfa6b3
第四轮深度测试：修复7个agent发现的问题，重点是编辑态附件覆盖的完整旁路和通话面板崩溃防护
...
再次派7个agent覆盖全部11章，验证第三轮修复+找新问题。本次委托agent专门交叉核对
上一轮每一项修复是否真的生效，多数确认有效，但抓出2处"看似修好、实则有旁路"的情况
和若干新问题。
**编辑消息+拖放文件仍可静默覆盖被编辑消息（上一轮修复的完整旁路，Ch3-4 agent发现）**
上一轮给`onAttachFile`/`onAttachImage`/`onAttachAudio`三个prop加了editingMessage门禁，
但`isDragEnabled()`（messages-view.jsx）没有检查这个状态——拖放文件到聊天窗口走的是
`handleFileDrop`直接调用`handleAttachImageOrVideo`/`handleAttachFile`类方法本身，完全
绕开了被置null的props。编辑态下不点"+"号、直接把文件拖进聊天窗口，依然会静默替换掉
被编辑消息的原文。已给`isDragEnabled()`补上同款判断，这是`handleDrop`和渲染层拖放提示
两处调用的唯一门禁函数，一次性堵住。
同一个agent还发现编辑态下点击"回复"另一条消息会静默放弃当前编辑（`handlePickReply`
覆盖`this.state.reply`但不清`contentToEdit`，发送时值走了`reply`分支而不是`editing`
分支，编辑框里的原文被当成对另一条消息的新回复发出去，原消息未被修改）——已在
`handleShowMessageContextMenu`里比照`menu_item_edit`的年龄过滤模式，编辑态下直接不
提供"回复"这个菜单项。
**实名认证驳回提醒的dismissKey修复上一轮实际没生效（Ch1-2 agent发现，已重新修复）**
上一轮把dismissKey从纯status改成"submission_id或status"，但live验证发现
`bootstrap.security.realname`这个数据源根本不包含submission_id字段（后端serveIMBootstrap
的实现只有status/required/allow_skip/remind_after四个硬编码字段）——所以这个修复在
真实环境下永远退化回status，等于没有变化，两次独立驳回依然会互相误压制提醒。这次改为
额外调用专用的`GET /security/realname`接口（该接口的实现确实会返回submission_id），
用它的数据驱动dismissKey和提醒触发条件，bootstrap的字段只保留用于remind_after/
allow_skip这些它独有的字段。已用真实账号验证dismissKey现在正确从这个新数据源生成。
**呼叫面板未卸载防护补全到call-panel.jsx（Ch8 agent发现，同类问题上一轮只修了
audio-recorder.jsx）**
`start()`/`unmuteVideo()`/`handleSwitchCameraClick()`三处的getUserMedia/
enumerateDevices异步链，结尾都会touch `this.localRef.current`/`this.state.localStream`，
但都没检查组件是否已经卸载——权限弹窗未决出结果时通话结束（呼出超时/收到挂断/对方
主动挂断)，这些promise resolve后会在死实例上抛TypeError，被各自的catch吞掉后又会展示
一句过期的原始英文报错。三处都补了`this._unmounted`检查，拿到的媒体流/轨道直接停止
而不是继续使用。
**其余修复**：`call-message.jsx`补上和`call-status.jsx`一致的"进行中"状态文案（原来
通话进行中且消息还没有最终时长时显示"0:00"而不是"进行中"，已用真实渲染验证过两个
组件行为不一致）；`tinode-web.jsx`的`handleCallClose`补上重置`callSeq`（避免跨通话
残留旧值）+ 更新`armCallRingTimeout`注释准确描述它是后端30秒建立超时的二级兜底而非
主要防线（后端`call_establishment_timeout`默认30秒，已有独立机制处理"直接不接"的
常见场景）；`REASON_MESSAGES`补充`API_KEY_REQUIRED`/`METHOD_NOT_ALLOWED`（此前记录过
一次真实的部署期API Key配置漂移事故，属于这两个reason的真实触发场景）；
`message-center-view.jsx`的`NOTIFICATION_TEXT`补充风险确认"取消"结果的文案（发消息
前风险提示点"取消发送"会产生这个系统通知，此前只收录了"继续"）；会话列表"置顶"从
只变背景色改为真正排到列表最前（原来只有CSS着色，没有任何排序逻辑，已用真实群聊
置顶验证过排序生效且系统消息/文件助手两个固定入口仍保持在最前）；好友聊天设置页
置顶/免打扰开关在初始GET未完成前禁用（避免`version:null`打到后端400）；
`content-library-view.jsx`的`DownloadPage`修复带外附件下载使用未做域名归一化的裸
相对路径（生产环境webapp和文件域名跨域时会必现下载失败，已拆出`resolveFileUrl`
辅助函数只做URL拼装不做预先fetch，跟`getFileUrl`的实际下载区分开）；
`security-support-view.jsx`的意见反馈分类配置改用`useCachedData`获得重试能力（原来
独立实现的边车缓存逻辑没享受到本轮`use-cached-data.js`的重试修复）。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-05 01:03:41 +08:00
Your Name and Claude Sonnet 5
93b856aec8
第三轮深度测试：修复7个并行agent发现的前端问题，含REASON_MESSAGES系统性补全
...
派了Ch1-2/3-4/5-6/7/8/9/10-11共7个agent对全部11章重新深度测试。后端问题已核实追加进
docs/IM-后端问题清单-2026-09-04.md（新增6-9条，发给用户）；本次是前端问题的修复。
**REASON_MESSAGES系统性补全（最高优先级，多个agent独立发现同一个缺口）**
im-api.js的REASON_MESSAGES表新增22个条目，最重要的是PERMISSION_DENIED——后端
server/im_http.go里403响应统一用这个reason（30余处调用），但表里原来只有一个从未
被后端实际发送过的死条目FORBIDDEN，导致全站几乎每一个403从工程一开始就在展示原始
英文"permission denied"。一并补上VERSION_CONFLICT/MALFORMED_REQUEST（Ch9 agent实测
命中）、NOT_FOUND、VERIFICATION_RATE_LIMITED（动态文案，同TOO_MANY_ATTEMPTS模式）等。
新增translateReason()导出函数并用于send-message.jsx的sendFavorite——favorites/forward
等几个批量接口恒定200、真实成败包在items[].reason里，imRequest的自动翻译够不到这种
per-item场景，之前直接显示原始reason字符串。tinode-web.jsx同理补了CTRL_ERROR_TEXT_CN
（原生WS {ctrl}协议错误，同样绕开REASON_MESSAGES）并修了原表从未真正匹配过的bug——
CommError会把状态码拼进message变成"authentication failed (401)"，原表按裸文本精确
匹配，看着正常纯粹是因为401/403兜底文案凑巧一样，一旦命中"unknown authentication
scheme"这类会被兜底文案误导、"policy violation"这类会直接漏出英文。uploadLargeFile/
createChatUploader/createFileDownloader同样绕开REASON_MESSAGES（走原生{ctrl}协议），
补了UPLOAD_CTRL_TEXT_CN小词典。已用真实账号端到端验证：favorites/forward到P2P目标
触发的PERMISSION_DENIED现在正确显示"没有权限执行此操作"；draft接口版本冲突正确显示
"内容已被修改，请刷新后重试"。
**编辑消息时打开附件面板会静默覆盖被编辑消息（Ch3-4 agent发现，数据损坏级别）**
sendMessage对editing状态一律用head.replace，但onAttachFile/onAttachImage/onAttachAudio
原来只在forwardMessage时置空，编辑态没有同款门禁——编辑一条消息不改文字、点"+"选张图片
或名片，会直接把附件内容替换掉被编辑消息的原文，无任何确认。messages-view.jsx新增
editingMessage门禁，和forwardMessage一样把三个attach回调置空（等价于隐藏整个"+"按钮）。
已用真实浏览器验证：编辑态下"+"按钮消失，取消编辑后正常恢复。
**草稿防抖单一共享定时器丢字（Ch1-2、Ch3-4两个agent独立发现）**
handleComposerChange用单个this.draftSaveTimer，话题A打字触发600ms保存后300ms内切到
话题B，会把A的定时器clearTimeout掉，那次输入永久丢失；version也在定时器触发时才重新
读state，此时可能已经在别的话题上，退化成硬编码0——叠加后端draft接口对version=0"无条件
跳过乐观锁"的行为（已记入后端清单新增6），可能静默覆盖别的标签页写入的更新草稿。改为
按话题分开的定时器map，version在调用的当下（保证仍在该话题）同步捕获进闭包。
**呼叫状态机两处真实bug（Ch8 agent此前发现，本次重新核实live代码后确认+修复）**
1. 通话中导航离开messages-view.jsx整个组件树（切到工作台/个人设置，或移动端切回会话
列表）时，没有任何hangup清理——componentSetup已有的"切换话题时正确挂断"逻辑只在
componentDidUpdate里，组件真正卸载时不会触发。CallPanel自己的componentWillUnmount
只做本地清理，不通知对方也不重置tinode-web.jsx顶层callState，导致下次切回通话话题
时remount出一个callState卡在CALL_STATE_IN_PROGRESS的"僵尸"面板——start()走"我们刚
接听"分支直接return，从不调getUserMedia，本地媒体永久拿不到。补了对称的
componentWillUnmount挂断逻辑。
2. this.callTimeoutTimer声明后从未被真正setTimeout赋值——呼出无人接听或accept信令
（fire-and-forget的{note}包）被丢会永久卡在"呼叫中"。补了armCallRingTimeout()，
60秒未接通按跟手动取消完全一样的路径挂断（不发明新的通话结果语义），在收到对方
accept信号的两处分支都正确清timer。
**其余前端修复（按文件）**
- messages-view.jsx: @提醒mentionedUsers只在切话题时清空，同一话题内后续消息里字面
文本"@张三"会被静默解析成真实提醒（发送后清空）；jumpToMessage点开已撤回/删除的
搜索结果原来只console.error静默失败，补了用户可见的错误提示；批量收藏对
favorites/batch共享Idempotency-Key导致的静默丢失（已知后端问题）不再照单全收
"收藏成功"，改为发送后重新拉取真实收藏列表核对每条是否真的落地。
- audio-recorder.jsx: getUserMedia权限弹窗未决出结果时组件被卸载，补_unmounted
标记避免在死实例上继续跑mediaRecorder.start()。
- send-message.jsx: disabled变为true时（对方拉黑/被禁言等实时ACS变化）没有强制结束
正在进行的按住录音，可能remount出无用户手势的"自动录音"；mouseup/touchend覆盖不到
拖出窗口/切换标签页/权限弹窗抢焦点的释放场景，补了blur/visibilitychange兜底。
- tinode-web.jsx: messages-menu视图和messages-home共用MessageCenterView实例无key，
从messages-home以非整体刷新方式切到messages-menu时菜单打不开，补key={view}。
- message-center-view.jsx: 实名认证驳回提醒的dismiss key只按用户+状态区分，同一状态
的两次独立驳回会互相误压制，改按submission_id区分。
- contact-management-view.jsx: Profile/Settings靠getUserProfile刷新拉黑状态，但该
接口对被拉黑对象直接403，导致"之前会话就已拉黑"的场景完全感知不到——叠加
getConversationContext兜底（该接口对拉黑目标正确返回200+relationship）。
- group-management-view.jsx: AdminList显示群主/管理员姓名漏了group_nickname兜底；
JoinRequests从聊天页横幅进入时返回按钮硬编码回group-settings（应回聊天本身），
从Governance进入时返回group-settings而非group-governance（与AdminList/Muted不一致）。
- workplace-collaboration-view.jsx: OrganizationDirectory/DeptNode的部门树加载失败
被无条件当成"暂无数据"渲染，补loadError区分+重试链接。
- personal-settings-view.jsx: CacheClear对navigator.storage/caches整个不存在的情况
只有react出了范围的.catch()覆盖不到的同步抛错，加了特性检测+try/catch；
YouthModeVerify触发TOO_MANY_ATTEMPTS锁定后确定按钮没有禁用/倒计时，会继续发出
注定失败的请求。
- security-support-view.jsx: 意见反馈category字段在config未加载完成前可为空但没有
提交前校验，会打到后端400。
- use-cached-data.js: bootstrap等首次拉取失败且无缓存兜底时永久停在undefined，加了
一次3秒后重试（仅在完全没有缓存值时触发，已有缓存值维持原"显示旧数据"行为不变）。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-04 23:29:52 +08:00
Your Name and Claude Opus 5
d21d046443
修复精准查找对拉黑关系显示"添加"，跟实际能不能添加对不上（第5章复测发现）
...
/users/search 返回结果本身带 relationship 字段，服务端 imRelationshipAction() 对
blocked_by_me/blocked_by_peer 都明确映射成 action:"none"（不允许发起添加）——但
前端 actionLabel 只认 friend/pending_outbound/pending_inbound 三种，其余（含两种
拉黑关系）一律落到兜底的"添加"文案。点进去虽然会跳到资料页、由资料页自己的
cannotAddReason 挡住（不会真的误发出申请），但列表这一行本身的文案是误导的。
补上跟 Profile 组件里已有的 cannotAddReason 一致的两条文案（已拉黑/无法添加），
只是精简成适合一行列表项的长度。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-04 16:25:44 +08:00
Your Name and Claude Sonnet 5
997f8f71d2
修复群成员非好友主页文案错误、添加好友按钮永不出现（第5章复测发现）
...
navigateToProfile 原来只从群成员列表数据（{acs, display_name, group_nickname?, mentionable,
role, user_id}）里摘字段做种子缓存，这份数据里根本没有 capabilities/relationship——Profile
组件正是靠这两个字段判断"要不要显示添加好友按钮"和"该显示哪句失败文案"。缺了它们，非好友的
群成员主页会落到 cannotAddReason 的默认分支：不管真实关系是什么，一律显示"好友申请正在等待
验证"，添加好友按钮永远不出现。
Profile 组件自己的 getUserProfile(uid) 对非好友是 403（服务端隐私默认），403 时会保留种子
不报错——这个保留种子的兜底本身是对的，问题是种子从一开始就没给对数据。
改用 GET /groups/{topic}/members/{user_id}/profile（getGroupMemberProfile，早就封装好但
零调用点）——群上下文里权限判断更宽松，实测对方哪怕不是好友也能拿到
{capabilities, relationship}。navigateToProfile 现在异步补种：跳转后台发起这个请求，回来后
用真实数据覆盖种子并派发一个事件让已经挂载的 Profile 重新读取。
已用真实账号验证：点击群成员头像后，getGroupMemberProfile 真实请求 200，返回
relationship:"friend"、capabilities.can_add_friend:false；Profile 组件的 React state 和
最终渲染的 DOM 都正确更新成"发消息/音视频通话"（通过 React Fiber 直接读取 state 确认，不只是
看界面文字）。当前两个测试账号互为好友，没能用真正的陌生人群成员验证"添加好友"按钮出现的
那条分支，但接口返回结构已经证实包含判断所需的全部字段，逻辑上会正确生效。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-04 13:56:26 +08:00
Your Name and Claude Sonnet 5
0dcef54fed
修复置顶/免打扰开关未接后端、好友二维码死按钮（第5章复测发现）
...
置顶聊天/消息免打扰：原来是纯本地 useState，onChange 只切一下布尔值，从不调用任何接口——
GET/PATCH /conversations/{topic}/settings 早就封装好了，只是零调用点。打开设置页永远显示
"关"，点了也只是那次会话内生效、离开页面就丢，和会话列表真正读取的置顶/免打扰状态是两套
毫不相关的东西。
实测确认真实字段：{pinned, mute_notifications, version}，PATCH 需要带 version 做乐观锁。
接入 getConversationSettings/updateConversationSettings，失败时回滚开关视觉状态。
已用真实账号验证：点击后发出真实 PATCH 请求，带正确的 version。
好友个人主页"二维码"图标：参考图里是独立一行（不是贴在头像卡片里的小图标），点击生成这个
好友的二维码名片，对应接口 createUserQRCode() 早就封装好了，原来这个图标没有任何 onClick，
是个看着能点、点了没反应的死装饰。新增 friend-qr 路由和 FriendQr 组件（复用 QrPage 的结构），
CSS 复用了 .people-settings 那套现成的行样式，不是新造一套。
已用真实账号验证：点击后正确跳转、生成出真实二维码。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-04 13:43:22 +08:00
Your Name and Claude Opus 5
c709abbfa4
修复全页面走查发现的问题（第六批：交互反馈时序）
...
- contact-management-view: "分享给好友"走剪贴板分支时不给任何反馈，点了界面上毫无动静
（同页 QrPage.share 是有 toast 的）；生成二维码失败也被 .catch(()=>{}) 静默吞掉。
三条路径都补上反馈。
- group-management-view: 添加管理员/禁言成功后 900ms 就导航，而 CenterToast 生命周期是
1400ms —— 导航会让整棵子树重挂载把 toast 一起销毁，参考图里那个「设置成功」实际只闪一下
就被截断。改成 1500ms。
回归验证（本轮全部改动）
- 41 个路由逐个访问：零 JS 错误、零 unhandled rejection、零空白页。
- 22 个页面布局扫描：无横向溢出、无文字零高度、无图标未居中。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-03 19:02:15 +08:00
Your Name and Claude Opus 5
35d3e1cf6b
修复全页面走查发现的问题（第四批：精准查找、隐私锁定、搜索防抖）
...
精准查找搜不到手机号（第5章 5.5）
- 一直写死 type=exact_account，而该分支只比对 profile.public_account / u.username / u.id
（tenant_adapter.go:9170-9172），**不匹配 u.phone**。参考图 5.5 里输的恰恰是手机号，
这个场景必然搜不到。改为按输入形态分流：11 位 1 开头走 type=phone。
- phone 分支服务端不做 E.164 归一化（只有模糊的 account 分支才调 normalizeUserPhone），
库里存的是 +86 开头，所以裸号码由前端补区号——注册流程本来也是这么拼的。
- 已用真实后端验证请求正确路由为 q=%2B8613800001188&type=phone。
隐私设置忽略 editable（第10章 10.12/10.13）
- 后端 userPrivacyPayload 返回 editable{add_me_methods, profile_visibility,
last_seen_visibility, read_receipts} 表达"企业强制策略锁死了这一项"，前端完全没读。
被锁的开关照样能点，点了 400 再回滚，用户只看到开关自己弹回去。现在禁用并给出说明文案，
同时补 .personal-switch:disabled 的视觉反馈（否则看不出为什么点不动）。
搜索防抖
- 新增共享的 useDebouncedValue，用在三处真正发服务端请求的搜索：收藏、会话内检索、
群列表、群文件。原来 query 直接进 effect 依赖，每敲一个字符发一次请求；群列表更糟，
reload 对三个分类各发一次，一个字符就是 3 个请求。而且返回顺序没有保证，后发的短前缀
请求可能后到、把正确结果覆盖掉。
- 实测：群列表输入 4 个字，请求数从 12 降到 3。
- FavoriteShare 那处搜索是本地过滤 chatList、不发请求，没有动。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-03 18:56:41 +08:00
Your Name and Claude Opus 5
02b98cceae
修复全页面走查发现的问题（第二批：登录、通讯录、群聊）
...
第1章
- tinode-web: 手输密码登录失败会 navigateTo('') 把用户弹回企业码页，刚输的账号丢了，而
TenantEntry 不渲染 FormAlert，那句错误提示根本看不到。改成只有存储的 token 失效才回登录入口。
- auth-onboarding IdentityCheck: 限流 429 时服务端会连同未过期的 challenge_id 一起返回，
原来只显示错误文案、challengeId 留空，于是 submit 开头的守卫静默吞掉点击——输完验证码点
"确定"毫无反应也无提示。同文件 VerificationButton 早就处理对了，这里是漏抄。
- auth-onboarding Register: 手机号注册路径硬传 invite_code:''，把用户填的邀请码丢了。后端
user.go:175-181 对邀请码的校验和 RecordUse 不区分注册路径，UI 上也摆着这个输入框。
第5章
- 好友列表主副行显示同一串字：后端在有备注时把 display_name 也设成备注（im_http.go:8500-8507），
两个字段同值。加"不同才显示"的守卫。
- 拉黑确认弹窗把设置页当背景渲染并摆出"操作之后"的样子，但背景组件自己的 getUserProfile
回来后又把开关改回未拉黑、"删除好友"红条重新冒出来。加 pinBlocked 挡住这次覆盖。
第6章
- 群列表把群名显示成 topic id、成员数恒为 0。根因在后端：handler 用 store.Users.GetSubs，而
store 自己的注释就写着它 "Does not load Public/Trusted or Private"（store.go:834-835），
groupListItemPayload 却去读 sub.GetPublic()/GetSubCnt()（应该用 GetTopics）。已记为后端问题；
前端先用本地 Tinode 会话缓存兜底（消息首页一直这么取，是准的）。
- 禁言页每行头像画成群组图标（Avatar 兜底图标默认 'group'，没传 icon="person"），
且顺带从成员表带上真实头像。
- 禁言页"以上成员不允许发言"被当成空状态用，语义正好反了——有禁言成员时这句消失、
一个都没有时反而显示。改为列表下方常驻注脚，空态另给文案，并补 .group-inline-note 样式。
- bytesToGB 只输出到 MB，1.4GB 的文件显示成 "1433.6 MB"。
- 群文件"来自"直接显示裸 uploader_id（groupFilePayload 不给昵称），拉成员表交叉引用。
- 群公告从聊天页横幅进入后返回，会把会话一起关掉：navigate 只写 query 参数，path[1] 仍为空，
handleHashRoute 就把 topicSelected 清成 null。Header 支持 onBack，显式把 topic 写回 path[1]。
- 群成员点头像打不开非好友资料页：目标页先读 'profile-seed:' 缓存，因为 getUserProfile 对
非好友直接 403。第5章入口一直有 seed，这里漏了。
- 群简介上限 225 超过后端硬限 200（im_http.go:4667），写满必被打回。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-03 18:40:53 +08:00
Your Name and Claude Opus 5
5a07bb4e3b
修复全页面走查发现的 P0 前端问题（第一批）
...
八个 agent 对 11 章逐页对照设计稿+后端源码后，先修其中"功能不可用/崩溃/谎报成功"级别的：
崩溃与数据错误
- content-library-view: Highlight 按 [start,len] 数组解构后端返回的 {start,end} 对象，
对象不可迭代会直接抛 TypeError，任何文本搜索命中都让整个结果区渲染崩掉。服务端偏移还叠加
两个问题（Go 字节下标 vs JS UTF-16；偏移基准是全文但 snippet 会被开窗截断），改为在展示
文本上本地匹配关键词。
- content-library-view: firstAttachment 用 Drafty.attachments，SDK 里硬过滤 tp=='EX'
只认文件附件，图片(IM)/视频(VD)/语音(AU) 一个都取不到——收藏缩略图、语音播放源、聊天记录
图片视频宫格全部拿不到资源。改用 Drafty.entities 按类型分派（chat-message.jsx 已有先例）。
- message-center-view: 系统通知的机器码兜底会把真实数据吞掉（日报提醒的 summary 就是日期
字符串 "2026-08-20"，会议通知的 summary 是标题），改为查表命中才替换。
- message-center-view: 会话列表漏了 avatar 字段，每行都只能落到兜底图标；同文件
frequentContacts() 本来就是对的，照它补上。
功能不可用
- auth-onboarding-view: 首次开启青少年模式是死路——设完密码丢弃了服务端返回的
enable_action_token，从不调 enableYouthMode，用户走完短信验证+设密码后模式仍是关的。
现在拿着这个 token 把最后一步做完。
- group-management-view: "投诉/举报"是个 onToast('暂未开放') 死桩，而 target_type='group'
这条链路早就通了。接上真实举报页。
- tinode-web: 刷新/深链会被弹回首页。两个原因叠加：初始化白名单还是上游 Tinode 的
['cred','reset','register']；handleLoginSuccessful 无条件把 hash 改写成 workbench，
刷新触发的自动登录也走这条。抽出 SIDE_PANEL_VIEWS 常量复用，并区分登录流程与自动登录。
- widgets/meta-message: deleted 分支从未实现，撤回一条消息后时间线上什么都不剩。
谎报成功 / 判定错误
- tinode-web + personal-settings-view: 改密码不返回 Promise，服务端拒绝时照样弹"密码已更新"。
- group-management-view: 禁言批量读 result.succeeded，但该接口返回的是 {topic, items}，
succeeded 恒为 undefined，不管成没成都弹"设置成功"。两个接口结构不同，分开判定。
- workplace-collaboration-view: 会议取消状态写成 'cancelled'，后端是 'canceled' 单 l，
会议取消后"取消会议"按钮还挂着。
样式与显示
- base.css: 删掉旧版 .organization-department 的 padding-left !important，它压过按层级算出的
内联缩进，导致部门行全平、只有人员行缩进。
- base.css: 补 .youth-password-gate（原来 0 条规则），PIN 框缺 position:relative 和居中。
- security-support-view: shield_lock 不在经典 Material Icons 里（只有 Symbols），会显示成
字面文本；.risk-info-page 也是 0 条规则，整页渲染成裸项目符号列表。改用 verified_user 并
补上 .risk-dialog。
- contact-management-view: 好友资料页性别直接输出后端枚举，显示成 "male"。
- workplace-collaboration-view: 层级标注两条路径两种格式（树形深三层变"3级"、搜索硬传"三"），
统一成一个 helper。
已记录不在前端修的后端缺口：recallMessage 的 version 只能传 1，因为所有消息读取接口
（messagePayload/messageSearchPayload/mediaMessagePayload/favoriteSnapshot）都不下发 version，
冲突错误里也不回传真实值，被编辑过的消息撤回必然失败。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-03 18:31:26 +08:00
Your Name and Claude Sonnet 5
251c9de87c
Convert im_webapp from static mock prototypes to real backend integration
...
Implements all 11 product chapters (auth, messaging, contacts, groups,
files/favorites, calls, workplace/reports, settings, security) against the
real /v1/im REST API and native Tinode WS protocol, replacing the hardcoded
mock data the ba8f48eenoreply@anthropic.com >
2026-09-03 11:40:53 +08:00
richjohnrambo
ba8f48ee83
完成 IM Web Android 端产品页面开发
2026-08-25 18:30:40 +08:00
Your Name