Your Name and Claude Sonnet 5
7f5756671d
feat(web): real P2P chat-settings detail panel
...
Replaces the detail-column placeholder with the actual "聊天设置" panel
(README §3.4): profile header, quick-action buttons, remark, pin/mute
toggles, blacklist, clear-history, delete-friend -- backed by real REST
endpoints (lib/api/friends.ts, ported from the old app's real
contact-management-view.jsx settings panel, not its unrelated mock
direct-message-view.jsx).
First real use of TanStack Query in this app (useQuery for
friends/conversation-settings/blocks, useMutation for the writes) --
previously only wired up in App.tsx with nothing consuming it yet.
Verified end to end: pin toggle PATCHes /conversations/{topic}/settings
and persists; remark PATCHes /friends/{userId} and reflects immediately
via query invalidation; blacklist PUT/DELETEs /blocks/{userId}.
Known minor gap: the drawer variant (960-1279px tier) stays mounted
(CSS-hidden) alongside the docked panel at >=1280px rather than
unmounting, so both instances' queries run -- harmless since TanStack
Query dedupes/shares the cache by key, but worth a follow-up cleanup.
Also still missing: the <960px "detail settings push as a full page"
variant the mobile spec calls for.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-08 01:54:54 +08:00
Your Name and Claude Sonnet 5
f549248c08
feat(web): real chat list + P2P conversation view against live Tinode data
...
Phase 2 core loop: chat list and single-chat conversation now read/write real
Tinode topic data end to end, replacing the earlier hardcoded placeholders.
- lib/tinode/topics.ts: per-topic pub-sub layered on connection.ts's pattern
(Topic.onData/onInfo/etc are single-slot callbacks, claimed once and fanned
out). Implements the old app's subscribe lifecycle: `me` subscribed once
per session (metadata only), each contact gets a one-shot preview
subscription (withLaterData(1), never left), opening a conversation
leaves-then-resubscribes with a full history page (withData, not
withLaterData -- a preview prefetch already nudging _maxSeq would make
withLaterData return empty).
- lib/tinode/hooks.ts: useChatList()/useTopicMessages() via
useSyncExternalStore, snapshots cached and only invalidated on real
topic-change notifications (not recomputed every render).
- lib/tinode/send.ts: sendText/retryMessage via createMessage+publishDraft
(optimistic local echo), not the simpler publish() -- matches the old
app's approach. retryMessage flushes the failed local entry and rebuilds
before republishing, per the old app's context-menu retry handler.
- lib/messages/{time,avatar,attachments,status,preview,dispatch,drafty}:
formatting utilities. Avatar color hash ports the old app's Java-style
string hash but with modulus 11 (this design's palette) not the old app's
16. @mention renders flat accent blue per the new design, not the old
app's per-user hash color -- a deliberate simplification. File-type icons
(PDF/Word/Excel/PPT) are new-design-only; the old app buckets all
documents identically. Date/time formatting is written fresh against the
design spec (today+time combined, weekday tier) since the old app never
combines a relative-date word with a time in one string.
- ChatListColumn, MessageBubble, ConversationView: real components replacing
the placeholder chat list and "占位" conversation view.
- tinode-sdk.d.ts: expanded with the real Topic/MetaGetBuilder/Drafty
surface needed above, verified against the installed SDK source
(createMessage/publishDraft/messages/msgStatus/noteRead/flushMessage/
Drafty.format's exact treeBottomUp contract, MESSAGE_STATUS_* statics).
Verified end to end against the real backend: used the still-functional old
app (a second account, ixp355087) to create a real friendship and exchange
messages with the new app's test account, confirming the new chat list and
conversation view correctly render pre-existing real data, sending a new
message shows the right optimistic-then-delivered status transition, and
the old app receives it live in return.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-08 01:49:14 +08:00
Your Name and Claude Sonnet 5
aa1c46ff22
feat(web): full auth screens rework to match design + old-app business rules
...
Rebuilt tenant/login/register/reset-password to match the design handoff's
01-account screens precisely (previously only loosely approximated), and
ported the old app's real business rules instead of guessing:
- LoginPage: desktop split branding panel (>=900px), terms-agreement
checkbox gating submit, forgot-password link, password visibility toggle,
full ctrl-error translation table (lib/tinode/errors.ts, ported from the
old app's CTRL_ERROR_TEXT_CN/translateCtrlError -- registration/login go
over native WS, not REST, so client.ts's REASON_MESSAGES never applied).
- RegisterPage: rebuilt as the real unified username-OR-phone form (not
phone-only) -- username optional unless phone is blank, invite code
required+validated only on the username-only path, matching the server's
actual resolveRegistrationAccount rules. connection.ts's
registerAccountByPhone generalized into registerAccount() supporting both
paths, including the Tinode.credential(null) crash the old app had to
work around on the username-only path.
- New ResetPasswordPage wired to /auth/password-reset/* (a different
endpoint family than registration's /auth/verification-codes/*).
- Shared components: PasswordInput, VerificationCodeButton, Agreement,
Toast.
- Fixed tinode-sdk.d.ts: the real method is getCurrentUserID(), not the
invented getAuthenticatedUserID() -- caught live, login crashed past a
successful auth.
- Fixed a responsive bug present on all four auth pages: fixed w-[380px]
forms overflowed past the viewport edge below ~430px wide.
Verified end-to-end against the real backend (api.118im.com, tenant
"default"): fresh phone registration, password reset, re-login with the
new password, and the username-only path's invite-code rejection all
round-tripped correctly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-08 01:11:21 +08:00
Your Name and Claude Sonnet 5
63c1b84b41
feat(web): phone registration + fix login/register response handling
...
- Add RegisterPage (phone + SMS code) and lib/api/auth.ts verification-code
endpoints, wired into App.tsx routing.
- Fix registerAccountByPhone(): the injected acc.phone extra field must be
bare 11-digit, not E.164 -- server checks digit length before normalizing.
- Fix LoginCtrl shape: SDK's login/loginBasic/createAccountBasic promises
resolve with the ctrl fields flat, not wrapped in {ctrl: {...}}.
- Fix tinode-sdk.d.ts: the real method is getCurrentUserID(), there is no
getAuthenticatedUserID().
All three bugs found and fixed via live testing against the real backend
(api.118im.com, tenant "default"), confirming registration and login both
work end-to-end.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-08 00:51:06 +08:00
Your Name and Claude Sonnet 5
8cdd84152d
企业码解析+登录跑通真实后端：Tinode连接适配层、类型化API客户端、会话store
...
lib/tinode/connection.ts：单例Tinode连接+自己的发布订阅层——SDK的onConnect/onDisconnect/onLogin
是单槽位属性（赋值会互相覆盖），不是真正的多监听器事件源，所以这里统一接管这几个槽位，自己
扇出给任意数量的React订阅方（lib/tinode/hooks.ts的useSyncExternalStore）。installTenantHiPatch
照搬旧应用tinode-web.jsx的实现搬过来——服务端{hi}包的tenant字段SDK本身没有API，只能在原始
sendText层面注入，这是后端协议的真实约束，不是旧代码库特有的写法。
lib/api/client.ts：REST客户端按旧应用src/lib/im-api.js的request函数+完整REASON_MESSAGES错误码
翻译表搬过来（含请求头X-MeetingIM-APIKey等几个月联调换来的正确写法），这次是重新用TypeScript
写、不是复制文件，但端点行为对齐。
实机联调过程中发现并修正了一处凭记忆猜错的地方：tenants/resolve真实响应结构是
{endpoints:{api,file,websocket}, tenant:{code,name}}，不是我最初假设的顶层{code,name}——
已用真实请求验证修正。用企业码default解析成功（显示"Default Tenant"）+ 一次真实错误密码
登录尝试（服务端真实401，错误提示正确显示"账号或密码错误"）两步都对着真实后端验证通过，
不是只测了正确路径。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-08 00:38:50 +08:00
Your Name and Claude Sonnet 5
8bcd9f3a5b
新分支：Vite+React19+TS+Tailwind v4 重新搭建，先跑通四级响应式布局壳
...
不再沿用旧 im_webapp 的技术栈（webpack + class组件 + 15000行全局CSS + 手搓History路由），
按业务重新选型：Vite/React Router/Zustand预留/TanStack Query/保留tinode-sdk真实依赖
（协议客户端本身没有重写的业务理由）。新代码放在 web/ 子目录，旧代码原样保留在仓库根目录，
两者共存到重写完成。
这一步先验证布局壳本身：NavRail（消息/通讯录/收藏/文件助手/通话记录/设置）+ 会话列表 +
主区域 + 详情栏，按设计稿的四档断点（<640/640-959/960-1279/≥1280）用真实浏览器宽度逐档验证
过——两列及以下"列表/主区域二选一+返回键"、三列"详情栏抽屉化"、四列"详情栏常驻"均已用
真实点击/返回验证正确，不是只看了截图。会话列表和聊天内容目前是占位数据，业务数据接入和
Tinode连接是下一步。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-08 00:24:11 +08:00
Your Name and Claude Sonnet 5
4e8f45d7d8
路由从 hash 换成 History API（pushState/replaceState/popstate），不再依赖 location.hash
...
HashNavigation 改名 Navigation（src/lib/navigation.js），接口不变，内部改用真实路径：
parseUrlHash/composeUrlHash 改名 parseUrl/composeUrl；navigateTo/navigateReplace 改调
pushState/replaceState 后手动派发 popstate（pushState/replaceState 不会像赋值 location.hash
那样自动触发事件，这里复用 navigateReplace 早就在用的同一个手动 dispatch 手法）；goBack()
不用改，history.back() 本来就是真实浏览器历史机制。新增 Navigation.currentUrl() 替代调用方
原本直接读的 window.location.hash（这个类从来没包装过这个读取）。
一处需要专门处理的边界情况：当 path[0] 是空字符串（"不选中侧栏视图、只开一个会话"这个仓库里
的合法状态）时，拼出的真实路径开头会变成双斜杠，被浏览器当协议相对地址解析、试图跳到一个叫
会话id的host，pushState 直接抛 SecurityError。composeUrl/parseUrl 内部用占位 token "_" 处理
这种情况，对外的调用方（19个文件）完全无感。
tinode-web.jsx 的 handleHashRoute 改名 handleRouteChange，监听从 hashchange 换成 popstate；
service-worker.js 的推送通知点击跳转手动改写成同样的路径格式（这个文件在打包之外单独执行，
没法 import Navigation）。index.html/index-dev.html 加了 <base href="/">——所有静态资源引用
都是相对路径，hash 路由下页面路径永远是 /，换真实路径后深层地址刷新会按当前目录解析出错误
资源地址导致白屏，这一行是标准修法。nginx.conf 的 try_files 兜底规则本来就适用两种路由，只
更新了注释。
实机验证：地址栏不再有 #；点击会话/设置等各类视图正常跳转；浏览器前进后退和应用内"返回"
按钮都正常；收藏页内部的类型 tab 切换（navigateReplace）确认不产生新的历史记录；在会话页/
个人中心页刷新、直接用完整深层路径打开新标签页都能正确恢复到位，资源正常加载不白屏。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-07 21:00:39 +08:00
Your Name and Claude Sonnet 5
97a6b88d59
修复"查找聊天记录"列表条目上下错位、长内容不换行溢出的问题
...
.library-message-results > button 沿用全局 button{height:2.2rem} 的重置，与自己的
min-height:5.5rem 叠加后变成一个"clamp出来的定长"而非auto——内容一旦比这个定长高（比如摘要
换行），这一条本身不会长高，而是让自己末尾的 <small> 时间戳溢出到下一条的发送人名字位置，
视觉上像是变成了下一条的开头，看着上下错位。同一个全局重置还带了 white-space:nowrap，摘要
<p> 继承后完全不换行，比栏宽的内容（尤其是链接）直接顶穿右边界。
改用 height:auto 让每一条按内容真实需要的高度伸展；<p> 补 white-space:normal +
overflow-wrap:anywhere（跟 .bubble div.message-content 处理长链接的方式一致）。移动端窄屏下
实机复现后验证：摘要正确换行、每条自己的时间戳不再越界到下一条。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-07 20:09:06 +08:00
Your Name and Claude Sonnet 5
7981083cad
修复发出消息里的超链接因为和气泡背景同色而完全不可见的问题
...
上一版把发出气泡背景改成蓝色（--clr-primary-accent）时漏了一处：全局 a{color} 用的正是同一个
token，链接文字和气泡背景撞成一模一样的颜色，肉眼完全看不见（但DOM里其实是好的，实测<a href>
标签和完整URL文本都在）。用真实账号发一条带链接的消息复现后确认。改为链接色跟随气泡文字的白色+
下划线，颜色不能再区分链接和普通文字时用下划线区分。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-07 19:58:49 +08:00
Your Name and Claude Sonnet 5
48baeceaa8
修复长按消息气泡弹出自定义菜单时，浏览器/系统原生右键菜单跟着一起弹出的问题
...
chat-message.jsx 新增 suppressNativeContextMenu，在气泡上监听 contextmenu 事件并 preventDefault，
避免长按（或桌面端右键/触屏模拟长按）触发的原生上下文菜单和应用自己的长按菜单重叠显示。
css/base.css 给 .bubble 补了 -webkit-touch-callout:none，同时覆盖 iOS Safari 那条独立于
contextmenu 事件之外的长按呼出菜单（复制/查询/分享...），不影响 user-select，桌面端正常的
点击拖拽选字复制不受影响。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-07 19:50:06 +08:00
Your Name and Claude Sonnet 5
4ce666042e
修复系统消息/我的收藏页"加载更多"按钮文字下沉被裁切的问题
...
.system-notification-load-more/.library-load-more 只覆盖了全局button的字号和内边距，没覆盖
line-height，实测继承的全局button{line-height:2.2rem}比这两个按钮自己的行高需求高出一大截，
把文字挤到框内偏下的位置，底部还被裁切掉约2px（用getBoundingClientRect量出文字整体比按钮
边框低9.9px）。改用flex居中+height:auto，不再依赖固定line-height撑出的位置。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-07 19:41:59 +08:00
Your Name and Claude Sonnet 5
f0091fb146
修复消息气泡配色未跟设计稿核对过的问题：发出气泡改蓝底白字，接收气泡改浅灰，日期分隔去掉气泡背景
...
对照 docs/images/个人对话框（我的状态/对方的状态）.png：发出=蓝色实心+白字，接收=浅灰+深字，
与其余相关截图口径一致；旧配色（接收浅绿#c4e0a3、发出用页面同款off-white）不匹配任何参考图，
是尚未跟设计稿核对过的原始默认值。顺带修了一个自查时发现的新问题：已读回执图标复用的.blue
工具类和新的蓝色发出气泡背景是同一个色值，之前会变成看不见的勾选图标，改为不透明白色。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-07 19:41:18 +08:00
Your Name and Claude Sonnet 5
a8b81a51e3
修复本轮UI走查发现的6处样式/交互问题
...
1. 企业注册-统一社会信用代码：扫码图标误用 icon+onIconClick（渲染在输入框左侧、蓝色），
跟设计稿（图标在右侧、深灰色）不符。原因是 Field 组件里 icon 出现在 <input> 之前；
全仓库唯一一处 onIconClick 用法，改用 PasswordField 同款的 action（渲染在右侧），
复用已有的 .auth-inline-icon 灰色样式，不新增CSS。
2. 意见反馈：图片上传按钮跟设计稿差异较大（当前是通栏虚线框+蓝色图标文字，设计稿是
独立白色方块+灰色图标文字）；字数"0/300"计数器卡在textarea自带边框和外层白卡的接缝
处，看起来像叠在两层盒子中间。改法：拆分原本跟"举报证据上传"共用的CSS规则，给
.feedback-upload>button 单独设置白底/无边框/灰色/7.5rem方块；去掉textarea自身的
border，让计数器所在的外层卡片成为唯一可见的白色容器。"图片"标题跟数量合并回一行
（原来用space-between分居两端），maxFiles真实上限(5，早前已确认是后端真实值)不变。
3. 青少年模式（开启/关闭/验证三个页面互跳）：三处跳转全部误用push（HashNavigation.
navigateTo），导致点返回会先回到流程内已经处理完的页面，跟本工程之前排查过的
同类"tab切换污染历史记录"是同一个模式。新增 navigateReplace()（跟 navigate() 同结构，
内部换成 HashNavigation.navigateReplace，抄的是 message-center-view.jsx/
content-library-view.jsx已验证过的写法），三处调用改用它。
4. 修改密码页面：复用了 profile-editor-page 的通用label/input样式，但没有像
BirthDateEditor那样带上专属wrapper class，导致三个label的<span>不加粗不换行、
紧贴在一起零间距，input还留着给别的编辑器计数器/清空按钮预留的3rem右侧空白。
新增 change-password-fields 样式（参照birth-date-editor的label/span/input规则）。
5. 消息长按弹出菜单：全历史检索确认这个功能从来不是真正的长按手势，唯一实现是点击
气泡右上角一个不透明度只有0.3的小箭头按钮——参考图"消息页面—长按弹出.png"命名的
功能需求和实现从未对齐。给 .bubble 补上真实的touchstart/touchmove/touchend长按
识别（500ms计时器，移动超过10px视为滚动取消），复用同一套菜单构建逻辑（从
handleContextClick里抽出openContextMenu(x,y)公用）。验证时发现并修复了一个重构
引入的真bug：openContextMenu里遗留了两行没改完的e.pageX/e.pageY（应为参数x/y），
会导致点击小按钮和长按两条路径双双抛ReferenceError，已修正并重新验证两条路径都正常。
6. 群公告横幅（群聊导航栏下方常驻提示条）：当前是通栏无圆角、贴边无留白、底部硬分隔线、
文字用的是全局默认灰色(#666 )文本token，设计稿是浮在灰底上的白色圆角卡片、四周留白、
无分隔线、文字接近黑色。改法：加margin+border-radius+box-shadow做出浮起的卡片感，
去掉border-bottom，颜色改用--clr-bubble-text（消息正文同款深色token，而不是改全局
的--clr-text-primary，避免影响其它用到这个默认文本色的地方）。
验证：本地dev-proxy逐项验证——企业注册图标位置颜色（截图核对）、意见反馈布局（截图核对，
0/5计数器无缝落在白卡右下角）、青少年模式三处调用grep确认无遗漏+navigateReplace底层
history.replaceState机制单独验证不增加history.length、修改密码页面（截图核对label加粗
间距生效）、长按弹出（真实dispatch TouchEvent触发菜单成功，且验证点击小按钮路径未被
重构破坏）、群公告横幅（getComputedStyle核对margin/borderRadius/boxShadow/color/
borderBottom五个属性全部生效）。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-07 17:24:24 +08:00
Your Name and Claude Sonnet 5
6ab2867f27
重新构建dev产物，反映本轮死代码清理+收藏批量删除弹层+通讯录CSS修复三处改动
...
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-07 01:59:33 +08:00
Your Name and Claude Sonnet 5
0d32569633
修复通讯录"新朋友"两处视觉问题：未读红点数字被挤出圆圈、拒绝/通过验证按钮在移动端换行
...
现象1：新朋友入口的红色未读数徽标（.people-entry-list em）只显示一个纯红点，数字看不见。
现象2：待处理好友申请行的"拒绝"/"通过验证"两个按钮上下堆叠换行，而不是同一行并排。
根因1：全局 button{line-height:2.2rem} 被 <em> 徽标继承，数字所在的匿名行盒远高于
1.2rem 的圆圈本身，place-items:center 只能让整个超高行盒居中，数字被推出圆心、
甚至溢出到按钮白色背景上（白字白底=看起来像空心圆点）。这跟本工程早前那轮全局
line-height 排查是同一类问题（01325ad0），.messages-conversation-meta b 当时已经
用 line-height:1 修过，.people-entry-list em 这条当时漏改了。
根因2：css/base.css 里 @media(max-width:640px) 断点下有一条
.people-request-list article > span, .group-request-list article > span
{flex-direction:column} 的覆盖规则，把默认的横向flex行强制改成纵向堆叠。核对两处
按钮组的实际内容（拒绝/通过验证、拒绝/确定，均为2个短文本按钮）后确认这条覆盖没有
任何布局必要性，纯属误加；因为 im_webapp 主要是移动端场景，这个断点几乎总命中，
所以两个页面的按钮实际上一直都在换行。
修法：给 .people-entry-list em 补上 line-height:1；删除上述@media块里这条多余的
flex-direction:column（连带align-items:flex-start）覆盖规则，让两个列表都退回默认
的横向排列+垂直居中。
验证：本地起dev-proxy，用真实登录账号在通讯录页面注入与真实DOM结构/class名完全
一致的测试节点核对渲染效果——红点数字正确居中显示，两个按钮同一行并排显示，
与预期一致。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-07 01:30:48 +08:00
Your Name and Claude Sonnet 5
31f2b4afea
修复"我的收藏"批量删除仍用原生 window.confirm()，是本工程已确立模式里同一类问题的第三处
...
现象：跟已经修过的两处同一类问题（46a98782"退出登录"、4773ee5f"解散群组"）一样，
content-library-view.jsx 的收藏批量删除也还在用裸 window.confirm()，4773ee5f 的提交
说明里已经点名记录过这一处、留给第七章处理。
根因：window.confirm() 与本工程其它确认弹层的视觉不一致，且部分内嵌 WebView/kiosk
环境会直接禁用同步对话框（confirm() 恒返回 false，删除被静默拦下、用户毫无感知）。
修法：改成两段式 state（点"删除"先进"确认中"态渲染弹层，弹层里的"确定"才真正调用
batchDeleteFavorites），新增 .library-sheet-backdrop/.library-confirm-sheet 样式，
数值抄自本文件已有的 .personal-*/.group-* 同款弹层（46a98782/4773ee5f），保持视觉
语言一致。
验证：真实浏览器注册全新测试账号，在一个真实群聊里发送并收藏两条消息，进入"我的
收藏"多选模式，选中两项后：先测"点删除→点取消"（弹层消失、两项收藏原样保留、未
发出任何 batch-delete 请求）；再测"点删除→点确定"（真实 POST .../favorites/
batch-delete 200 成功、两项 ok:true、列表正确清空为"暂无此类收藏"、toast 提示
"已删除所选收藏"）。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 17:55:48 +08:00
Your Name
c2e07a89b8
清理死代码：sidepanel-view.jsx里被chapterOneViews短路掉的旧版登录/注册/找回密码分支
...
不是功能修复，纯清理。sidepanel-view.jsx的render()方法开头（chapterOneViews数组
含'login'/'register'/'reset'等）已经对这些view值提前return真实对接后端的
AuthOnboardingView。但同一个render()方法下半部分的三元表达式链里，还留着一份基于
view==='login'/'register'/'reset'的旧分支，分别渲染LoginView/CreateAccountView/
PasswordResetView——由于上面的提前return，这三个view值永远不可能落到这里，是无法
触达的死代码。
确认方式：全仓库搜索确认SidepanelView只有tinode-web.jsx一处渲染入口，其view prop
（state={this.state.sidePanelSelected}）只能来自handleHashRoute对SIDE_PANEL_VIEWS
白名单的校验结果——'login'/'register'/'reset'确实在这个白名单里（否则连
sidePanelSelected都设置不了），但chapterOneViews这个子集在render()内部的检查顺序
必然先于旧分支执行，所以旧分支不可能被触达。
删除范围：三个旧分支的JSX（对应import的LoginView/CreateAccountView懒加载/
PasswordResetView懒加载）+ 三个组件源文件本身（login-view.jsx/create-account-view.jsx/
password-reset-view.jsx，删除引用后确认全仓库不含任何其它referrer）+ 两个文件对应的
已生成umd构建产物（webpack不会自动清理不再产出的旧chunk文件，这两个是被删除源文件
遗留下来的孤儿产物）。'cred'分支（ValidationView，不在chapterOneViews里，仍在真实使用）
未改动。defineMessages里对应的login/register/reset翻译key本次未删——它们现在也
无法被messages[view]这条动态查找命中，但涉及i18n提取产物的联动改动超出这次清理范围，
如实记录，未处理。
验证：npm run build:dev干净通过（三个旧chunk不再产出）；真实浏览器完整走了一遍
登录（已有账号）/注册（全新手机号）/找回密码（重置刚注册账号的密码，重置后用新密码
重新登录成功）三条流程，均无回归。
2026-09-06 17:31:20 +08:00
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
e4b0868036
重新构建dev产物（本轮7个并行agent全部完成后的统一构建）
2026-09-06 16:44:01 +08:00
Your Name
3790472b4c
修复我的收藏/查找聊天记录加载失败时卡死在"加载中…"，没有任何错误提示或重试入口
...
根因：Favorites 和 History（content-library-view.jsx）两个组件的 load() 里，请求失败的
.catch() 只调用 onToast() 弹一条 2 秒自动消失的提示，从未把 items 从初始值 null 变成别的
状态；页面渲染逻辑是"items === null 就显示'加载中…'"，两者叠加导致一次真实失败之后页面永远
停在"加载中…"，等用户反应过来去看的时候提示早就消失了，分不清"还在加载"和"永远不会加载完"。
这个坑本文件自己的 DownloadPage、group-management-view.jsx 的 GroupFiles、
contact-management-view.jsx 的 Profile 三处早就各自修过（都有一个独立的 loadError 状态），
唯独 Favorites/History 这两个用得最多的列表页当时漏掉了。
真实触发场景：用两个全新账号互加好友、发送图片/视频/文件/语音/文本等真实消息并收藏后，
发现收藏一条较大的（out-of-band）文件附件之后，GET /favorites?type=all 从此稳定返回
500 INTERNAL_ERROR（已确认是纯后端问题，不在前端能修的范围内，另行记录）——但这个后端
问题一暴露出来，"我的收藏"默认落地的"全部"tab 就会用真实数据 100% 复现这里描述的前端缺口：
打开就卡在"加载中…"，没有任何办法知道发生了什么、也无法重试。
修复：Favorites/History 都新增 loadError 状态，非 append（首次/切换 tab、类型、搜索词）请求
失败时置为 true、成功时置回 false，切换 type/topic/view/query 时重置；渲染时 items === null
且 loadError 为真则显示"加载失败，请重试"而不是死等的"加载中…"。"加载更多"（append）请求
失败保持原样只弹 toast，不影响已经显示出来的列表。
验证：复现上述 500 场景（GET /favorites?type=all 持续 500），修复前"我的收藏"全部 tab
永久停在"加载中…"；重新构建后同一账号同一坏数据状态下正确显示"加载失败，请重试"。
2026-09-06 16:39:13 +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
4773ee5f64
修复"解散群组"仍用原生 window.confirm()，是本文件唯一未统一的危险操作确认弹层
...
现象：本工程已经在"退出当前登录"那次修复（46a98782）里明确认定原生 window.confirm()
和其余确认弹层不一致、且在部分内嵌 WebView/kiosk 环境下会被直接禁用（同步对话框调用
无提示地恒返回 false，操作被静默拦下且用户毫无感知）。全仓库复查后发现"解散群组"是
group-management-view.jsx 里唯一还在用这个模式的危险操作——同样不可逆、后果同样重大，
却没有跟上那次统一。
修复：改成两段式状态（先点"解散群组"进入确认态，再点确认态里的"确定"才真正调用
delTopic），复用本文件 OwnerSelect 早就在用的同款弹层视觉语言
（.group-sheet-backdrop/.group-confirm-sheet），不再依赖浏览器原生对话框。
验证：真实浏览器操作，用真实账号在真实群里走了"点解散→点取消"（弹层消失、群未受
影响、群列表可正常继续访问）和"点解散→点确定"（原生 WS {del hard:true} 成功执行，
200 ok，正确跳转回群列表且群已从列表消失）两条路径。
顺带记录：content-library-view.jsx 的收藏批量删除也还在用裸 window.confirm()，
是同一类问题，但属于第七章范围，本轮不动，留给对应章节的测试处理。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 16:30:06 +08:00
Your Name and Claude Sonnet 5
30e6d5e300
修复风控弹窗取消后再次发送同一条回复，引用内容与正文被永久追加重复
...
现象：对一条历史消息点"回复"，输入含链接的文本触发风控弹窗后点"取消发送"
（预览条正确保留，这是既有修复的正常行为），不改动文本再次点发送、这次
在弹窗里点"我已知晓，继续发送"——最终发出的消息里，正文被写了两遍（引用
块本身只有一份），例如输入"排查根因4 xxx"，实际发出"[引用] 排查根因4
xxx排查根因4 xxx"。第三次发送同一条文本会变成正文三遍，以此类推。
根因：sendMessage()给回复拼接引用内容时写的是
`Drafty.append(Drafty.sanitizeEntities(this.state.reply.content), msg)`。
Drafty.sanitizeEntities和Drafty.append（umd/tinode.dev.js，第三方SDK，
未改动）都会原地修改第一个参数并把同一个引用返回，从不做深拷贝——
sanitizeEntities内部直接改content.ent[i]再return content，append直接
first.txt+=、first.fmt.push()再return first。这里把this.state.reply.content
（React state里"正在回复"预览条依赖的同一个对象）原样传进去，等于每次
点发送都会把当次输入的正文永久焊死在这条回复引用的原始内容上。
平时这个副作用不可见：一次成功发送后handleCancelReply()马上清掉
state.reply，被污染的对象跟着一起扔掉。但URL风控检查会把真正调用
doSend()（进而调用这行代码）的时机推迟到弹窗resolve之后，"取消发送"
按现有修复（a964d51b）刻意不清空state.reply以保留预览条——这就让
被污染的引用内容留了下来，等下一次点发送时，同一个已经被污染的对象
再被追加一次，正文因此重复。
修复：拼接前对this.state.reply.content做一次深拷贝，让两个SDK方法的
原地修改只作用于用完即扔的副本，不管sendMessage对同一条还没清空的
回复调用多少次都不影响原始状态。
验证：真实浏览器操作，对消息点回复，输入带链接文本发送触发风控弹窗，
点"取消发送"（预览条与文本保留正常），不改文本再次发送并这次确认
"继续发送"——发出的消息引用块和正文都只出现一次，不再重复。
第14+轮最小粒度测试 Ch4 发现（回复+风控弹窗联动场景，紧邻已知修复
a964d51b验证时发现）。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 16:24:30 +08:00
Your Name and Claude Sonnet 5
53e28e3bc6
修复"我在本群的昵称"保存时硬编码 version:0，与本文件其余乐观锁写法不一致
...
现象：GET /groups/{topic}/members/me/profile 实测确认真实带 version 字段（非空），
但 MyNicknameEditor 保存时一直硬编码 updateMyGroupProfile(topic, value, 0)，从不使用
这个已经到手的真实版本号。
根因/影响：跟本文件其余"编辑单个字段+乐观锁"写法（GroupNameEditor/
GroupDescriptionEditor 用 getGroup 拿到的真实 version；Governance/OwnerSelect 的
注释更明确写过"version<=0 时服务端会整个跳过乐观锁 WHERE 子句，两次几乎同时的写入会
静默覆盖，没有冲突信号"）不一致。实测验证这里同样如此：真实 version 是 1，PUT 时传 0
依然 200 成功，服务端自己把 version 推到了 2——多标签页/多端几乎同时修改自己在本群的
昵称时，后写入的会静默覆盖先写入的。
修复：GET 到的 version 存进 state，保存时原样带上，不再硬编码 0。
验证：真实浏览器操作，改群昵称两次，第二次 PUT 请求前 GET 到的 version 正确是上一次
保存后服务端返回的版本号（1→2→3 依次递增），不再是硬编码的 0。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 16:17:03 +08:00
Your Name and Claude Sonnet 5
8cb96e9254
修复撤回消息在对方界面显示"无效内容"而非"消息已删除"
...
现象：真实调用撤回接口成功后（recall_window_seconds=120秒窗口内，长按菜单
"撤回"），撤回发起方自己的消息列表里这条消息直接消失，没有问题；但对方
（消息接收方）的聊天界面上，这条消息位置渲染成一个灰色警告图标+"无效内容"
（invalid content），不是预期的"此消息已被撤回/删除"占位提示。
根因：Tinode原生协议里，一条消息被撤回后，服务端把这条消息的content原地
置为null（seq位置保留，其余内容清空）。chat-message.jsx渲染消息内容时按
Drafty富文本、纯字符串、其余情况三段分支处理，content为null时两段判断
（Drafty.isValid和typeof=='string'）都不成立，直接落到兜底的"invalid
content"分支——这段代码从未加过null-content（撤回）的专门判断。这跟
messages-view.jsx里另一套依赖msg.hi标记位的"删除"消息渲染（走独立的
<MetaMessage deletedText=.../>组件）是两码事：撤回消息还是走的普通
ChatMessage组件，从未接入deletedText这个机制。
修复：chat-message.jsx新增一个content==null的分支，复用
messages-view.jsx里messages.message_deleted已经注册好的同一个i18n
id/文案（"消息已删除"，非新增翻译串），渲染为灰色图标+"消息已删除"，
不再落到"无效内容"兜底分支。
验证：真实浏览器操作，两个全新注册账号互为好友，A发一条文本消息后
立即长按撤回（120秒窗口内），B的聊天界面上这条消息正确显示"消息已删除"
（此前是"无效内容"）。
第14+轮最小粒度测试 Ch4 发现（撤回消息渲染场景）。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 16:12:38 +08:00
Your Name and Claude Sonnet 5
b200dc2525
修复长按消息菜单"撤回"功能完全失效：LOCAL_SEQID 经 webpack externals 解析为 undefined
...
现象：验证第2章长按消息弹出菜单的时间窗口门控时发现，无论消息是不是自己刚发的、群主/普通
成员、发送后多少秒，长按菜单里永远不出现"撤回"这一项——服务端 messagePolicy 明确返回
recall_window_seconds=120，但这个选项在任何情况下都不会出现。
根因：messages-view.jsx 原来 `import { ..., LOCAL_SEQID } from 'tinode-sdk'`，但
webpack.config.js 把 'tinode-sdk' 映射到全局变量 `tinode`（externals: {'tinode-sdk': 'tinode'}），
而这个全局对象（umd/tinode.dev.js 的 UMD 导出）只挂了 {AccessMode, Drafty, TheCard, Tinode}
四个键，从未包含 LOCAL_SEQID——尽管 tinode-sdk 的 ES 模块本身确实导出了这个常量
（umd/tinode.dev.js 内部仍以 `const LOCAL_SEQID = 0xFFFFFFF;` 定义并在多处话题方法里使用，只是
没有挂到对外暴露的全局对象上）。externals 映射对"这个键不在对象上"和"这个导出根本不存在"没有
区分，所以按名字导入被静默解析成 `undefined`，没有任何构建报错。撤回菜单项的门控条件
`params.seq > 0 && params.seq < LOCAL_SEQID` 因此变成 `seq < undefined`，在 JS 里恒为
false——不是时间窗口判断错了，是入口条件本身就从未为真过，撤回功能对所有用户、所有消息实质性
完全失效。
用控制台直接调用 MessagesView 实例的 handleShowMessageContextMenu 并打印各分支布尔值定位到
这一步：seq=2 这样明显合法的正整数，seqOk 却是 false，才追到 LOCAL_SEQID 本身是 undefined。
修复：messages-view.jsx 不再从 'tinode-sdk' 导入 LOCAL_SEQID，改为本文件内本地声明
`const LOCAL_SEQID = 0xFFFFFFF`，与 SDK 内部定义保持一致（未改动 webpack externals 映射本身——
其它页面都依赖它保持现状，改映射风险更大、影响面更广）。
验证：登录测试账号，在群聊里发一条新消息立即长按，确认"撤回"正确出现在菜单中；点击后
`POST /topics/{topic}/messages/{seq}/recall` 返回 200，消息从会话中正确消失；对比一条已经
超过 recall_window_seconds（同时也超过 edit_window_seconds）的旧消息，确认"撤回"和"编辑"
仍正确不显示，时间窗口判断本身未被破坏。
注：umd/index.dev.js 本次未随此提交提交——工作区里并行的其它 agent 仍在改
contact-management-view.jsx / sidepanel-view.jsx 且未提交，重新构建的 index.dev.js 会把它们的
未提交改动一起编译进同一产物文件，为避免混入不相关改动，只提交 messages-view.jsx 按路由懒加载
的独立 chunk（umd/src_views_messages-view_jsx.dev.js 及其 .map），不受这个问题影响。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 16:05:19 +08:00
Your Name and Claude Sonnet 5
5c688007c8
修复会话列表把系统通知/合并转发消息的预览行恒显示成无信息量的"[消息]"
...
现象：好友通过验证、群成员加入、群邀请卡片（"邀请你加入群聊。"）这类系统消息
（x-im-type=system_notice/system_action）和合并转发消息，点开会话看到的是完整的一句
人话，但会话列表的预览行不显示这句话，一律显示占位符"[消息]"。
根因：message-center-view.jsx 的 draftyPreview() 只认三种取值来源——纯字符串、
Drafty 附件实体（content.ent[]，映射成"[图片]"等标签）、以及 content.txt——最后兜底
到"[消息]"。但 system_notice/system_action 的真实文案字段是 content.text（跟
chat-message.jsx 渲染这类消息时读的字段一致），合并转发消息的文案字段是
content.comment/content.title，三者都不是 content.txt，全部落进兜底分支。
修复：draftyPreview() 补上对 content.text（system_*）和 content.comment/
content.title（forward_bundle）的识别，命中就直接用这句真实文案，仍然兜底到
"[消息]"覆盖真正未知的内容形状。
验证：真实浏览器操作，两个全新注册账号之间邀请入群后，会话列表预览行正确显示
"邀请你加入群聊。"，不再是"[消息]"。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 15:58:45 +08:00
Your Name and Claude Sonnet 5
64021fe428
补上"邀请好友入群"功能，POST /groups/{topic}/invitations 真实可用但前端零调用点
...
现象：docs/images/内容沟通对话3-开启进群验证与拉人状态.png 里"你邀请时间旅行者、
李惠惠加入群聊"这条系统事件证明产品设计里确实有"从我的好友里直接选人邀请进群"这条
路径；im-api.js 的 inviteGroupMembers()（POST /groups/{topic}/invitations）也早就
封装好，服务端接口本身可用（实测确认：请求成功返回 pending 状态的邀请记录，对方会在
跟我的会话里收到"邀请你加入群聊。立即加入"卡片）。但全仓库检索这个函数零调用点——
群聊设置页成员格的"添加"格子原来点了只弹一句"请通过转发/分享群二维码邀请成员"，把
这条真实存在的路径堵成了唯一路径（二维码分享走的是另一条"申请入群待审批"的路，跟
"邀请"语义不同，不能互相替代）。
修复：新增 InviteFriends 组件（复用 MemberPicker 同款字母分组多选布局），数据源换成
好友列表并按当前群成员名单过滤掉已在群里的人，选中后调用 inviteGroupMembers；
GroupSettings 成员格的"添加"改为跳转到这个新页面。
顺带修复一处会导致这个新路由完全打不开的既有陷阵：tinode-web.jsx 的 SIDE_PANEL_VIEWS
是一份独立于 group-management-view.jsx 自己 GROUP_MANAGEMENT_VIEWS 的硬编码合法视图
名单（文件里 104-107 行注释解释过这就是历史上"新增路由忘记同步这份名单导致深链被清空"
的同一类坑）——只在后者加了新路由名、没有同步这份名单，会导致 handleHashRoute 判定
"Unknown sidepanel view" 直接不渲染侧栏，新页面点了跟没点一样，一并补上。
验证：真实浏览器操作，两个全新注册账号（好友关系），从群设置页"添加"格子进入，勾选
好友、点完成，对方在跟我的会话里收到真实的"立即加入"邀请卡片，群设置页成员数不变
（邀请只是待确认，尚未入群，符合预期）。邀请确认接受这一步会 500，是已知后端问题
（新增72，AcceptInvitation 里一处表名/字段名写错，见 im_be/server/db/mysql/
tenant_groups.go:448 用了不存在的 subscriptions/Topic/User 而不是 im_subscriptions/
topic/userid），不是本次改动引入。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 15:58:24 +08:00
Your Name and Claude Sonnet 5
b6adc032a2
修复发送含链接消息时切换话题，风控弹窗可能把消息送错会话
...
现象：在会话A输入含链接的消息并点发送，POST /security/urls/check 请求还未返回时切换到
会话B，请求返回后风控弹窗会在会话B里弹出（本该属于会话A），此时点"继续发送"，消息被
真实发进了会话B，而不是最初输入它的会话A——跨会话消息误投递。
复现：会话A（kcg051307）输入"https://example.com/racefix?token=fix002 "点发送，立即
（在checkURL网络请求返回前）切换到会话B（r12c56b2），风控弹窗在会话B视图下弹出；点
"继续发送"后消息被投递进会话B，会话A完全没有收到，会话B收到了本不该发给它的内容
（本次因B恰好还不是好友触发"发送失败"提示，但发送动作本身已经指向了错误的会话，
如果B是好友会真实送达）。
根因：`getDerivedStateFromProps`在话题切换时会把`riskDialog`重置为null，但这只能防住
"弹窗已经弹出、随后切换话题"这一种时序——它防不住"checkURL还在进行中就切换话题，
此时机的.then()回调在切换之后才执行"这种反过来的时序：这次setState({riskDialog:{...}})
是在切换完成之后才发生的，不会被这次重置覆盖，于是在当前（错误的）话题下重新弹出弹窗，
且弹窗里的`doSend`闭包沿用的是`this.props.sendMessage`，按确认时的当前话题发送，
不是消息最初输入时所在的话题。
修法：sendMessage()进入URL风险检测分支时已经缓存了`topicForDraft`（用于清草稿），
在checkURL的.then()回调最开头加一道判断——如果`this.state.topic`已经不等于
`topicForDraft`，说明用户已经离开发起这次检测的会话，直接返回false（视同消息被放弃，
不弹窗、不发送），不再继续读取风控结果或setState。这与本文件已有的"两条风险消息连续
触发、后一个覆盖前一个"场景处理逻辑（resolve(false)后覆盖）是同一种"宁可丢弃، 不可
错误投递"的一贯取舍，只是这次要防的是切换会话而不是重复触发。
验证：npm run build:dev后浏览器实测——(1) 会话A输入风险链接点发送，立即切换到会话B，
2秒后确认会话B里没有弹出风控弹窗（修复前必现）；(2) 切回会话A确认最后一条消息仍是修复
前测试遗留的旧消息，本次新消息没有出现在A也没有出现在B，两个会话都没有收到，符合
"宁可丢弃不可错投"的设计；(3) 对照组（不切换话题、正常触发风控）依旧能看到弹窗并正确
发送/取消，未被这次改动影响。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 15:57:22 +08:00
Your Name
644b663ed1
重新构建本轮2处修复的编译产物（通话小窗预览显隐 + 语音通话菜单翻译）
...
对应前两个commit的源码改动：src/widgets/call-panel.jsx、
src/i18n/zh.json、src/i18n/zh-TW.json。跑 npm run build:i18n 重新生成
src/i18n.min/{zh,zh-TW}.json，再跑 npm run build:dev 让 webpack 重新
编译对应的 umd 产物。
本次只挑了跟这两处修复相关的产物文件加入本commit：call-panel.jsx 自己
的 chunk（含 sourcemap）、zh/zh-TW 两个 i18n chunk。umd/index.dev.js、
umd/index.dev.js.map，以及 umd/src_views_messages-view_jsx.dev.js 等其它
umd 产物这次构建也发生了变化，但那是因为这台机器上同时有其他并行任务在
改 src/views/messages-view.jsx、tinode-web.jsx、contact-management-view.jsx
等跟本轮通话章节测试无关的文件（构建时是从磁盘当前状态整体编译的，会把
它们尚未提交的改动一起编译进去）——这些不是我这轮的改动，没有一并提交，
保留在工作区未纳入版本控制，避免把别的任务未完成的改动夹带进这个commit。
2026-09-06 15:56:44 +08:00
Your Name
56cd91d40e
修复语音通话菜单项中文翻译误译成"称呼"，实际含义是发起语音电话
...
会话更多菜单里发起语音通话的入口（tinode-web.jsx menu_item_audio_call，
唯一消费点，2236 行 formatMessage 渲染其 title）中文翻译一直是"称呼"，
和视频通话入口"视频电话"并列显示时，用户会把它当成设置备注昵称之类的
功能，点开才发现其实是拨打语音电话——源头是英文 defaultMessage 只有一个
词"Call"，同时可以理解成"称呼/命名"或"打电话"，翻译流程选错了词义，
zh.json/zh-TW.json（简繁中文）都错，全仓库搜索确认"称呼"/"稱呼"没有
被其它任何 key 使用，不是复用了别的合法翻译。
改成"语音电话"/"語音電話"，与同一菜单里视频通话入口现有的"视频电话"
措辞保持一致（未改动"电话"这个词本身的选择，只修正词义选错的问题，
避免额外引入新的用词不一致）。
验证：修复前 tw.props.intl.formatMessage({id:'menu_item_audio_call'})
返回"称呼"；重新跑 npm run build:i18n 生成 src/i18n.min 后同一调用
返回"语音电话"。
2026-09-06 15:56:12 +08:00
Your Name
9eb9df649d
修复视频通话振铃阶段本地小窗预览提前可见且可拖动
...
本地小窗预览（.call-party.self）此前只由 audioOnly/minimized 控制显隐，
没有校验连接是否真正建立（this.state.remoteStream），导致视频通话振铃
阶段（对方尚未接听、只有本地摄像头画面）小窗就已经以 display:block 可见，
且 dragStart 里对应的分支同样没有这层校验，振铃阶段就能拖动这个本应还
不存在的预览框。
render() 里 .call-party.self 的 disabled 属性补上 !connected 判断，
dragStart 里进入 'self' 拖动分支的条件补上 this.state.remoteStream 校验，
两处保持一致：只有远端媒体真正到达（连接建立）后小窗才出现并可拖动。
验证：用 canvas.captureStream()/AudioContext 构造的合法 MediaStreamTrack
配合 monkey-patch getUserMedia，绕开已知后端通话邀请 400 缺陷直接驱动
CallPanel 组件状态。振铃阶段（waitingForPeer=true, remoteStream 未设置）
下 .call-party.self 计算样式 display:none、无 [disabled] 属性对应的
cursor:grab；调用 handleTrackEvent 模拟远端媒体到达后，display:block、
cursor:grab，且用真实鼠标拖拽（非合成事件）验证了拖动/边界收紧都正常。
2026-09-06 15:55:48 +08:00
Your Name and Claude Sonnet 5
dbf47847fe
修复系统消息列表漏查表的"group.join_request.accepted/rejected"机器码
...
现象：核对第2章系统消息列表最近修复的"group.announcement.updated"查表遗漏问题时，逐个比对
im_be 的 insertGroupEventTx 调用点，发现入群申请审批这一条并不在当初核对的 9 种静态事件码
之列——群管理员在群管理页批准或拒绝入群申请后，系统消息列表会展示原始机器码，而不是可读文案。
根因：TenantGroupJoinRequestResolve（server/db/mysql/tenant_groups.go:642）拼的事件码是
"group.join_request."+status（status 取 server/store/types/groups.go 的
GroupJoinRequestStatusAccepted/Rejected，即 "accepted"/"rejected"），实际产生的是
"group.join_request.accepted"/"group.join_request.rejected" 两个完整机器码。这两个和已收录的
"group.join_request.created"（提交申请时那条）是三个不同的 key，NOTIFICATION_TEXT 表里只有
后者，前两个查表落空，systemNotificationText() 兜底把原始机器码直接展示给用户。
修复：在 message-center-view.jsx 的 NOTIFICATION_TEXT 表里补上这两个 key。
验证：读 im_be 源码逐个核对 insertGroupEventTx 全部调用点，确认这是唯一还缺失的动态拼接事件码；
重新构建后确认产物里两个 key 及对应文案都已生效。未在真实环境触发一条这样的通知做端到端验证——
需要另一账号先申请加群、本账号再批准/拒绝，属于第6章群管理操作范畴，本轮未展开搭建。
注：umd/index.dev.js 本次同样未随此提交提交——工作区里此刻并行的其它 agent 正在改
i18n/zh(-TW).json、group-management-view.jsx、sidepanel-view.jsx、call-panel.jsx、
contact-management-view.jsx 等多个文件且均未提交，重新构建的 index.dev.js 会把它们的未提交
改动一起编译进同一产物文件，为避免混入不相关改动，本次只提交源码。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 15:51:10 +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
605cd12a6e
修复第1章各认证页之间切换会带出上一个页面的报错文案
...
现象：在注册页填错邀请码提交后（正确显示"邀请码错误，请重新输入"），点击"已有账号？登录"
切到登录页，登录表单顶部会原样带出这条"邀请码错误"提示——用户在登录页什么都还没做，却先看到
一句跟登录毫不相关的报错。反过来，登录密码错误后点"马上注册"也会把"账号或密码错误"带到刚打开
的注册页。
根因：errorText/errorLevel 是 tinode-web.jsx 顶层的一份全局共享状态，不跟当前显示哪个
sidepanel 绑定。Login 组件自己的"切换企业"链接会在跳转前先调用一次 onError() 清空，说明
之前已经意识到这个状态会带着走，但企业码/登录/注册/忘记密码等页面之间的其它跳转都没有做
同样的处理——其中 Register 等好几个视图目前甚至没有拿到 onError 这个 prop，需要在各处
分别补，比较分散。
修复：在 AuthOnboardingView（chapterOneViews 统一走的入口组件）里加一个以 view 为依赖的
useEffect，view 变化时统一调用 onError() 清空全局报错状态，一次性覆盖企业码/登录/注册/
忘记密码等视图之间的所有切换路径（含浏览器前进后退），不用逐个跳转调用点分别处理。
验证：注册页提交错误邀请码复现"邀请码错误，请重新输入"后点击"登录"，确认登录页不再带出
该提示；反向验证登录页密码错误后点击"马上注册"，确认注册页同样不再带出"账号或密码错误"。
注：umd/index.dev.js 本轮未随此提交一起提交——auth-onboarding-view.jsx 不是按路由懒加载的
独立 chunk，此刻工作区里另有并行 agent 正在改 contact-management-view.jsx / call-panel.jsx
且未提交，重新构建的 index.dev.js 会把它们尚未提交的改动一起编译进同一个产物文件，为避免把
不相关改动混进这次提交，本次只提交源码，构建产物留给后续统一重新构建的提交处理。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 15:40:43 +08:00
Your Name and Claude Sonnet 5
a71aee9487
修复"安全"设置页退出登录无二次确认，单击立即登出
...
现象：从 account-settings-view.jsx"账户设置"、info-view.jsx，以及第2章系统消息列表"前往
安全设置"跳转按钮都能到达 acc-security-view.jsx 这个"安全"页（并非废弃页面，是与
personal-settings-view.jsx"设置"页并存的独立入口），点击"登出"没有任何二次确认，单击
图标就会立即退出登录，且没有任何撤销机会。
根因：该文件里"登出"按钮的 onClick 直接调用 this.props.onLogout()，而同文件里紧挨着的
"删除帐户"按钮走的是 onShowAlert 弹确认框（handleDeleteAccount）。此前 46a98782noreply@anthropic.com >
2026-09-06 15:36:55 +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
552c891cc3
修复清除缓存显示"已释放约0.0MB"，与实际清理量不符
...
现象：设置-清除缓存确认后，无论Cache Storage里实际有多少数据，展示的"已释放约
X MB"几乎总是0.0，即使清理动作本身（caches.delete）确实生效（caches.keys()清理后
变为空数组）。
根因：原实现在caches.delete()前后各调用一次navigator.storage.estimate()，用两次
usage之差算释放量。实测确认Chrome的storage.estimate()不会同步反映Cache Storage的
删除——caches.keys()已经确认清空后，estimate()仍继续报告删除前的usageDetails.caches
数值，实测滞后超过500ms未刷新。人为塞入一个2MB的Cache Storage测试项复现：删除成功
但"已释放"显示0.0MB；塞入3MB项验证修复后正确显示3.0MB。
修法：不再依赖storage.estimate()的前后差值，改成删除前逐个遍历所有Cache
Storage条目、读取每个response的真实blob大小并累加，直接得到本次会话即将删除的
真实字节数，不受浏览器存储统计滞后影响。
验证：npm run build:dev后浏览器实测——(1) 无缓存数据时点击"清除缓存"，正确显示
0.0MB且弹层能正常从"清空缓存"态切到"缓存已清理"态、点"完成"可关闭；(2) 用JS人为写入
2MB/3MB测试用Cache Storage条目，分别清理后弹层准确显示2.0MB/3.0MB，且caches.keys()
确认条目已被真实删除。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 15:30:40 +08:00
Your Name
cd092108c2
重新构建dev产物（清理调试残留日志+本轮3处修复的编译产物）
2026-09-06 15:04:00 +08:00
Your Name
4715ea4497
修复未登录状态下深链/跳转到某个话题导致应用整体白屏
...
handleHashRoute 判断 path[1]（话题名）是否合法只检查了 Tinode.topicType(topicName)
这一个语法层面的条件——没登录时把hash设成一个真实群/好友的"#/<topic>"地址（比如
退出登录后浏览器历史回退、或者一个带话题参数的通知/深链在未登录状态下被打开），
话题名本身语法上合法，于是mobilePanel被设成'topic-view'。但render()里
MessagesView真正渲染的前提除了mobilePanel还要求!chapterOneActive（即
this.tinode.isAuthenticated()）——这个前提没登录时是假的。结果移动端下
SidepanelView的显示条件(mobilePanel=='sidepanel')和MessagesView的显示条件同时
为假，两边都不渲染，应用整体白屏（app-container是空的，没有任何报错），
仅靠换hash也无法恢复，只能整页刷新。
修复：判断话题合法性时把"当前是否已认证"也纳入，未登录时统一走已经验证过安全的
"话题名非法"分支（topicName置null，mobilePanel回退到sidepanel）。
已实测复现：退出登录后把location.hash设成一个真实群的话题地址，修复前白屏，
修复后正确回退。
2026-09-06 15:03:48 +08:00
Your Name
ed9a92896c
修复系统消息列表原样显示机器码"group.announcement.updated"
...
NOTIFICATION_TEXT 查表漏收了这一种群事件码。real账号(asn494180)的真实系统消息
列表里实测出现过未翻译的原始事件码——server/db/mysql/tenant_groups.go 的
insertGroupEventTx 一共会写9种 group.* 事件（announcement.updated/created、
join_request.created、member.joined/left/updated、mute.updated、
owner.transferred、role.updated、settings.updated），这张表原来漏了公告更新
这一种，是9种里唯一没查表命中、直接把机器码露给用户看的。
2026-09-06 15:03:34 +08:00
Your Name
a81a7b162d
修复群系统事件消息重新变回普通气泡+"未找到"作者名（并发编辑意外丢失CSS）
...
e6e51f628087fd7e
2026-09-06 15:03:25 +08:00
Your Name
fa2288c497
修复群文件上传不传file_type，图片/视频/语音群文件全部显示成通用文件图标
...
根因：POST /groups/{topic}/files 的 file_type 是客户端登记时自己声明的字段（im-api.js的
addGroupFile早就留了这个参数），不是服务端拿mime_type反推的——实测：上传一张mime_type
正确记成"image/png"的图片，只要请求体不带file_type，服务端就把它落成字面量"file"（不是
留空）。GroupFiles的onFile上传流程一直没传这个字段，导致FILE_TYPE_META准备好的
image/video/audio/document四种彩色图标从未被真正用上，所有群文件不分类型清一色显示灰色
通用文件图标。
修复：新增fileTypeFromMime辅助函数（与content-library-view.jsx的同名函数用同一套mime前缀
优先、扩展名兜底文档类型的判断口径），上传时算出分类一起传给addGroupFile。
验证：真实浏览器上传一张PNG，接口返回file_type从"file"变成"image"，列表图标从灰色通用
文件图标变成绿色图片图标；对照同一会话里upload-fix之前的旧文件，图标仍是灰色（存量数据
不受影响，符合预期，不需要也没有接口能批量回填旧记录）。
2026-09-06 13:47:19 +08:00
Your Name and Claude Sonnet 5
ddf23d40b2
修复新会话首次打开时消息历史被静默截断为1条、对方已读回执永不刷新
...
根因：tinode-web.jsx的prefetchLatestMessagePreviews()（会话列表"最后一条消息"预览）
会在会话列表一渲染就对每个有动态但本地无缓存摘要的话题调用
topic.subscribe(startMetaQuery().withLaterData(1)...)，只为预览目的抓取"最新1条"
消息——这常常发生在用户真正点开这个会话之前。这次订阅会把tinode-sdk的
Topic._attached置为true，且把_maxSeq设成那一条消息的seq。
用户随后点开会话时，messages-view.jsx自己的subscribe()发现topic.isSubscribed()
已经是true就直接return，从未真正发出过完整的{sub}请求。即使去掉这个短路，
SDK的Topic.subscribe()本身在_attached为true时也会无条件短路成
Promise.resolve(this)，完全不看传入的getParams——所以无论如何都不会把
withLaterSub()/withAux()等真正需要的查询发给服务端。
现场复现：全新注册的两个互为好友账号之间发4条真实消息，全新session下第一次点开
该会话，只渲染出最新1条，其余3条静默丢失；对方的已读回执（应变蓝色双勾）永远
不刷新——这两个现象都会在离开会话再重新打开后自愈（因为离开会清掉_attached），
但用户在此之前看到的是一个残缺、状态错误的会话。
修复分两处：
1. subscribe()内，若topic已经isSubscribed()，先topic.leave(false)（只清客户端和
服务端的订阅态，不清本地已缓存消息），再执行真正的subscribe()，确保这次一定
是货真价实的、服务端会认真处理getParams的订阅请求。
2. 把消息分页查询从withLaterData(MESSAGES_PAGE)（"给我比本地_maxSeq更新的消息"）
改成withData(undefined, undefined, MESSAGES_PAGE)（"给我最新的N条消息"，不依赖
本地缓存游标）。前者在_maxSeq被上述预览订阅污染后会查询"since:被污染的seq+1"，
服务端自然返回空；后者是绝对查询，对全新话题（_maxSeq为0，两者退化成同一个
since:undefined查询）行为不变，对被污染的话题能正确要回完整历史。
第14+轮最小粒度测试 Ch3-4 发现（P2P单聊消息状态机场景）。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 13:46:58 +08:00
Your Name
8087fd7e97
补上视频通话小窗拖动功能遗漏的CSS改动（.call-party.self 的 grab 光标提示）
...
上一个 commit（call-panel.jsx 里新增的"全屏连线中拖动本地小窗"功能，对应 8.9 双方
视频通话中.png 的"小窗应支持拖动"需求）只提交了 JSX/JS 那部分，配套的 CSS
（.call-party.self 增加 cursor:grab 提示可拖动，[disabled] 态改回 cursor:unset）
当时被同一文件里其他并发改动的暂存操作顶掉，没有一起进去——这个环境里多个并发
session 同时在改 css/base.css，共享 git index 导致 git add 经常把彼此的暂存内容
一起扫进对方的 commit，这是本轮测试期间反复确认到的现象，不是这次改动本身的问题。
JS 逻辑不受影响（拖动本身早就用真实指针事件验证过可用），这里只是补上缺的光标提示
样式，让用户在尝试拖动前就能看出这个小窗是可拖的。
2026-09-06 13:40:03 +08:00
Your Name and Claude Sonnet 5
e6e51f625e
群系统事件消息改为居中纯文本渲染，不再走普通气泡+作者名的展示逻辑
...
根因：群里的系统事件消息（成员加入、角色变更、公告发布等，x-im-type=system_action/
system_notice）服务端并不带真实的 `from`，但 messages-view.jsx 一直把它们和普通消息
一样交给 ChatMessage 渲染——chat-message.jsx 的 fullDisplay 逻辑会在气泡下方额外画一行
发送者名字，解析不到发送者时回退显示"未找到"。对照参考图 内容沟通对话3-开启进群验证与
拉人状态.png，这类系统事件应该是居中的纯灰字提示，不带头像、不带气泡、不带作者名——现状
既不符合参考图，也让"未找到"这种内部占位文案暴露给了用户。
怎么修：meta-message.jsx 新增 systemText 分支，复用日期分隔条同一套"居中提示"视觉语言
（.meta .bubble.system，无背景、纯居中灰字）；messages-view.jsx 在消息渲染分支里识别
system_action/system_notice 且不带可操作按钮（group_invitation_created 那种带
"立即加入"按钮的除外，仍走完整气泡展示）的消息，改为渲染 MetaMessage 而不是 ChatMessage。
验证：用真实群（3 个真实账号）走了两遍"扫码申请入群→通过审批"，会话里"有成员通过审批
加入了群聊。"正确显示为居中灰字，不再出现气泡、头像和"未找到"作者名；带按钮的
group_invitation_created 消息不受影响，仍是完整气泡+"立即加入"按钮。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 13:39:35 +08:00
Your Name
e53af93409
修复收藏页多选模式下类型状态丢失、跨tab选择静默累加两个问题
...
根因1：'favorites-select' 是全部类型 tab 共用的同一个路由,本身不带类型信息，Favorites
组件原来进入多选模式时把 type 硬编码回退成 'file'，不管进入前实际停在哪个 tab。实测在
"文本"tab 点"多选"，列表和头部计数会静默换成"文件"tab 的数据，用户看不出发生了什么，
勾选/删除会作用在自己根本没看到的文件项上——测试过程中因此真的误删了一条文件收藏。
修复：进入多选前把当前 type 作为 hash 参数带上，多选页/分享页的返回箭头、"取消"、发送后
跳转都改用该参数换算的 tab，不再硬编码 'favorites-files'。
根因2：切换类型 tab 只更新 type，没有清空 selected——在"文件"tab 选中项目后切到"图片"tab，
头部仍显示旧的"已选择 N 项"，实际操作的是已经不在当前列表里的旧类型收藏，删除/转发没有任何
可见提示。修复：切 tab 时一并清空 selected。
验证：真实浏览器逐步复现两个问题后确认修复生效——在"文本"tab进入多选保留文本列表、
切"图片"tab选择清零、"取消"正确回到多选前所在的图片tab；多选删除功能本身回归正常。
2026-09-06 13:38:25 +08:00
Your Name and Claude Sonnet 5
1228d6a534
补上组织架构部门蓝色高亮修复遗漏的CSS改动（.expanded重命名为.me）
...
上一个commit(1d47c586noreply@anthropic.com >
2026-09-06 13:36:27 +08:00
Your Name and Claude Sonnet 5
1d47c586d3
修复组织架构页部门蓝色高亮跟"是否展开"挂钩，根节点被误判成"我的部门"
...
DeptRow原来的蓝色高亮（.organization-department.expanded）直接复用"展开/收起"
这个纯UI交互状态：depth 0的根节点默认就是展开的（DeptNode: useState(depth===0)），
导致根节点从打开页面那一刻起就被误染成"当前用户所在部门"的蓝色，与参考图
（docs/images/部门组织框架.png）不符——图里根节点"总裁办50人（一级）"明明是展开状态，
颜色却是黑色默认色，只有真正包含当前用户的"技术4人（二级）"是蓝色实心菱形。
根因是把"展开状态"和"是否是我的部门"这两个独立概念用同一个CSS类混在了一起。改为
新增containsMe（DeptNode根据自己已加载的members列表里有没有当前用户算出，与expanded
彻底解耦，expanded继续只管chevron方向），CSS类从.expanded改名成.me（与PersonRow已有的
.me保持同一套命名）。顺手把三处重复的"裸id/usr前缀id两种形式对比myUserId"的内联判断
提成共享的isMyUserId函数。
当前测试租户组织架构数据本身为空（GET /organization/departments、/members 都是真实
200+空数组，非账号权限问题——kcg051307交叉验证过同样为空），无法用真实多级树肉眼过一遍，
按测试要求改用桩数据验证：mock了总裁办→财务/销售/技术三个部门+技术下4个成员（含当前
用户）复现参考图的结构，展开技术后确认根节点保持黑色、技术正确变蓝，与参考截图逐像素
对照一致；修复前用同一份桩数据可复现根节点被误染蓝的问题。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 13:35:38 +08:00
Your Name and Claude Sonnet 5
a964d51ba5
修复回复/编辑消息触发风控弹窗时，"正在回复"预览条在弹窗结果出来前就被清空
...
现象：对一条历史消息点"回复"，输入含链接的文本点发送，风控弹窗（安全提醒/警示级）
刚弹出的同时，composer 里"正在回复 XX"的预览条就已经消失了；如果这时候点"取消发送"，
这条回复就被永久放弃——原来引用的消息内容和回复关系不再存在，也没有任何提示，唯一的
恢复办法是回到那条历史消息重新点一次"回复"。编辑消息（修改一条已发消息的内容后再次
包含链接）是同一根因的同款问题，只是编辑可以靠重新点"编辑"找回原文，没有回复那么彻底
不可逆。
根因：sendMessage() 原来在根据 this.state.reply / this.props.forwardMessage 组装好
msg/head 之后，同步、无条件地立刻调用了 this.handleCancelReply()（清空 reply/编辑
状态），这一步发生在下面的 URL 风控检查（POST /security/urls/check）之前——但风控
弹窗要等用户点"继续发送"或"取消发送"才会真正决定要不要走 doSend()，这中间的等待期里
UI 状态已经被提前清空了。
修法：把 handleCancelReply() 从三处提前调用点移到 doSend() 内部、真正调用
this.props.sendMessage(...) 之前。这样它只在真的要发送时才执行——不含链接的普通消息
里 doSend() 本来就是同步立即执行，时机与原来完全一样；命中风控的消息里，"继续发送"
时才会触发（此时清空回复状态是正确的，消息确实发出去了），"取消发送"时 doSend()
根本不会被调用，回复/编辑的预览条和引用内容都会完整保留，可以直接修改文本重试或
自己手动取消。转发场景不受影响：转发消息不会触发这条风控检查（originalText 恒为
null），移动调用时机对它是纯粹的时序等价替换。
验证：真实浏览器操作，对一条消息点"回复"，输入含 https://example.com/a?token=abc123
的文本发送——警示弹窗弹出的同时预览条仍然可见；点"取消发送"后弹窗消失、预览条依旧
完整保留、composer 文本不变；再次点发送、这次点"我已知晓，继续发送"，消息正确以
带引用卡片的回复形式发出，预览条在发送成功后才清空。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com >
2026-09-06 13:32:59 +08:00
