Repository navigation
fix: strip bare "[N]" unread-count prefix from sender - #1
Merged
Merged
Conversation
WeChat emits the unread count both as "[3条]" and as a bare "[82]". Only the
former was stripped, so the latter survived into SENDER_PREFIX and was captured
as part of the name: "[82]一条鱼" instead of "一条鱼". The same person then
appeared under many senders ("韭菜根", "[28]韭菜根", "[29]韭菜根"), which breaks
focus-person tracking in the digest. 1655 of 11440 rows were affected after a
reconnect drove unread counts into the hundreds.
Make 条 optional. The digits stay required, so bracketed emoji display names
("[鲸鱼]", "[火箭]Steve.") are still left alone — there are more rows behind
those names than behind this bug, and a looser rule would corrupt them.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
问题
微信的未读计数有两种形式：
[3条]和不带「条」的[82]。COUNT_PREFIX只剥离了前者，后者会残留下来被SENDER_PREFIX连同昵称一起捕获：同一个人因此被拆成多个 sender（
韭菜根/[28]韭菜根/[29]韭菜根），digest 里的 focus-person 追踪会漏掉这些发言。线上实测：11440 行里有 1655 行受影响——微信断线重连后未读数涨到上百，
[100]…[1626]连续出现。改动
条改为可选：数字仍然是必需的，因此方括号表情昵称不受影响——
[鲸鱼](411 行)、[熊](63 行)、[火箭]Steve.(11 行) 等共 542 行。这是刻意的边界：更宽松的规则（比如剥离任意方括号内容）破坏的行数会超过它修复的行数。测试
新增 4 个用例，覆盖两侧边界：
[82]一条鱼: …/[12]在吗→ 前缀被剥离[火箭]Steve.: …/[鲸鱼]→ 昵称原样保留已验证这些用例在改动前会失败、改动后通过（21 passed / 0 failed）。
版本
1.0.0 → 1.0.1（bugfix），versionCode
202607201。🤖 Generated with Claude Code