Your Name and Claude Opus 5
7728afe79f
群主转让加一步密码二次确认，跟账号注销/改密码等其它高风险操作保持一致（第6章复测发现）
...
serveIMGroupOwnerTransfer 核实过：只认 {target_user_id, version}，没有任何
action_token/二次验证机制——不是文档滞后，是这个操作本身就没有服务端强制的二次
确认。但转让群主同样不可逆、后果同样重大（"确定后你将立即失去群主身份"），本项目
对同一类场景已有明确先例：personal-settings-view.jsx 的 DeleteAccountConfirm 就是
纯前端加的密码输入门槛，不指望服务端校验它，只是让"手滑点确定"变成需要多打一遍
密码才会发生的事。
OwnerSelect 原来点目标人选后只有一层"确定/取消"的确认表，点确定直接调用真实转让
接口。现在拆成两步：第一步维持原有确认文案不变，第二步新增密码输入，留空点确定
会被拦下（不发请求），填了任意内容才真正调用 transferGroupOwner。
真实验证（真实群+真实候选人）：空密码点确定确认没有发出请求；填入密码后
transferGroupOwner 真实调用成功，正确跳转回群组管理页。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-04 17:04:26 +08:00
Your Name and Claude Opus 5
3a78c40389
修复创建群聊名称长度上限与编辑页不一致的问题（第6章复测发现）
...
创建群聊弹窗的名称输入框 maxLength 是30，但群资料页的编辑器（GroupNameEditor）
是11——两者编辑的是同一个 group.name 字段，建群时能起最多30字的名字，进编辑页
却连原样保存都做不到（打不满30个字符，且无法回退到超过11字的原值）。
核对参考图 设置昵称(1).png：这个字段的编辑器明确画的是"0/11"上限，没有任何一张
图支持30。后端本身不做长度限制（实测 PATCH 17 字符的名称成功),11 纯粹是前端自
己的约束，应该是创建页和编辑页保持一致，而不是让创建页放宽成一个没有依据的数字。
改为创建弹窗也用 maxLength="11"，跟编辑页对齐。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-04 14:46:25 +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 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 Opus 5
f7bc98811e
群聊设置：重做成员预览区，修掉错位间距、多余横线和被压扁的名字
...
用户实机截图反馈这块"图标和间距有问题"。对照 docs/images/群聊设置.png 逐项查证，实际有四个独立
缺陷叠在一起：
1. 多余横线：成员容器 div 和邀请按钮都是 section 的直接子元素，命中了通用列表项样式
（.group-settings section > button/div 带 border-bottom + min-height + padding），
于是这一块被当成两个普通设置行渲染，凭空多出两截下划线。
2. 间距错位：原来是 flex 布局，成员列表 flex:1 占满剩余宽度，把邀请按钮一路挤到最右，两者之间
出现一大片空白；参考图是等宽网格。
3. 名字看不见：全局 button 规则（base.css:1999）写死 height/line-height 2.2rem，成员格子没有
覆盖它，整个格子被压到 29px 高——48px 的头像直接溢出，名字被压成 0 高度，实测
getBoundingClientRect().height 为 0。
4. 图标撞车：成员头像的兜底图标沿用了 Avatar 的默认值 group（双人图标），跟上方群头像长得一模
一样，分不清哪个是群哪个是人；改传 icon="person"。
改成参考图的结构：一行"群成员"标题（右侧显示人数）+ 5 列等宽网格，最后一格是与头像同尺寸、
同圆角的浅色"添加"块。新样式用 .group-settings section > .group-member-* 提高特异性，明确压过
那套列表项规则，并显式写 height:auto 覆盖全局 button 高度。
刻意没做的两点，都是因为本分支没有对应页面，不想做点了没反应或跳错地方的入口：参考图里"查看
15465群成员"那个可点链接（没有通用群成员列表页，这里只展示人数文字），以及"删除"格（没有移除
成员的页面）。这两个缺口需要单独补页面，不在这次范围内。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-03 17:43:22 +08:00
Your Name and Claude Opus 5
3bdb0bf40f
群昵称改用专门的接口读取，修好读不回已保存值的问题
...
上一个commit修好了"群资料"页把群名称当成个人群昵称显示的问题，但实机验证发现改完仍然显示"未设置"。
抓包确认根因：GET /groups/{topic}/members 列表接口的每一项里压根没有 group_nickname 字段（只有
acs/display_name/mentionable/role/user_id），所以任何从成员列表里读昵称的写法，不管代码逻辑对不对，
都永远拿不到值——这个文件里原有的 MyNicknameEditor 也是同样的写法，同样存在这个问题（打开编辑器时
不会回填已保存的昵称）。
真正能读到昵称的是保存用的那个路径上对应的 GET：GET /groups/{topic}/members/me/profile，返回
{nickname, version, updated_at}（server/im_http.go:4776-4782）。im-api.js 里之前只封装了 PUT，
补上了对应的 getMyGroupProfile，两处读取（群资料页预览行、昵称编辑器回填）都改成用它。
实机验证：保存"测试昵称A"后重新打开群资料页，"群昵称"正确显示"测试昵称A"，"群名称"独立显示
"扫码测试群"。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-03 17:20:36 +08:00
Your Name and Claude Sonnet 5
e4c6e1b246
Fix group-profile nickname preview showing group name instead of my own nickname
...
GroupProfile's "群昵称" preview row showed group.name -- the group's own display name -- instead
of the current user's personal nickname within that group (a real, distinct concept, correctly
handled by the existing MyNicknameEditor/group-my-nickname page, just not wired into this preview
row). Ported the substance of a bug dev independently found and fixed in their own reimplementation
of this same page ("show saved group nickname", found while evaluating what from dev's post-fork
commits was worth bringing over). Reuses the same getGroupMembers+filter-by-myUserId approach
MyNicknameEditor already uses in this file (there's no working "me" shortcut on the
member-profile-by-id endpoint that would let this be fetched more directly -- confirmed by reading
server/im_http.go's routing, which never special-cases that literal string).
Also renamed the adjacent "群昵称"->"群名称" label for the group's own display name field, since
having two rows both labeled "群昵称" (one for my personal nickname, one for the group's name) is
exactly the confusion that caused this bug in the first place.
Evaluated the rest of dev's post-fork commits (9 commits fixing this same page's nickname-save
reliability, plus the wholesale chapter-view reimplementation) for anything else worth porting:
the version-conflict retry logic they built doesn't apply here since this branch already sends
version:0 (confirmed server/im_http.go:4793 treats <=0 as "skip the check" -- the exact mechanism
their fix was working around a different way), and their nickname maxLength bump (11->20) is
already exceeded by this branch's existing 32, which matches the real backend limit
(server/im_http.go:4789). Nothing else from dev's branch was found applicable.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-03 17:08:38 +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
