docs(tasks): 聊天正文排版两条根因,出 BUG-962/963 任务书

用仓库自己的渲染管线 + next build 的 CSS chunk + headless Chrome 复现:
列表无项目符号(preflight 清 list-style,.markdown-list 没恢复);
promoteDefinitionLists 把四标题口语体散文误判成并列项,三段正文被
改写成列表项。收紧判据而非删除,BUG-356 的并列短项场景要继续工作。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0193vBv6w5MV2cifdTUu9H5P
This commit is contained in:
Jesse_Chen
2026-09-18 09:40:33 +00:00
co-authored by Claude Opus 5
parent ea0280c121
commit 0a1a87b06e
2 changed files with 83 additions and 0 deletions
+1
View File
@@ -140,6 +140,7 @@
| `TASK-consult-pass4-streaming-20260918.md` | `PROGRESS-consult-pass4-streaming-20260918.md` | 验收 review 三轮:Pass 4 一 hold 正文就整段蹦出、逐字流式消失(BUG-950 产品拍板按句放行);无出生分钟模式整段被一句拒绝顶掉、一般知识句一起丢(951 改按句丢弃);该模式下日期不留痕(952);校正流 token 级 thinking 是死链,按 P2 删除并把测试翻转成否定合同(953)。基线 `1e553976` | 待验收 | `cd4775ae` |
| `TASK-window-consult-contract-20260918.md` | `PROGRESS-window-consult-contract-20260918.md` | **P0 线上**:申报时段模式**自 2026-08-21 起每轮秒败**69ms、0 token、模型从未被调用)。服务端日志实证根因:窗口 Agent attach 了 `jyotishSkillBinding()`,但 `windowJyotishInstructions` 从来不含方法块 marker,输入处理器直接 abortBUG-954)。abort 与「模型没调工具」同码,是它藏四周的原因(955);另含合同未绿不得丢正文(956)、计算不该由模型触发(957,须等 954 上线后另轮)、窗口指令应期冲突(958)。基线 `9cdcf96b` | 已验收通过(Claudetsc 0 / lint 0 error / npm test 3501 条 31 红同基线 / `/` Static / gzip 无变化;实跑确认窗口 Agent 指令已含 marker);review 另出 BUG-959~961 见下一行 | `5b6abc23` |
| `TASK-contract-degraded-pass4-20260918.md` | — | 验收 review:BUG-956 新增的降级交付路径绕过 Pass 4,保证句原样送达(BUG-959);`uncontractedText` 跨 attempt 不清零,同一轮正文说两遍(960);降级后还空跑一轮 compose(961)。基线 `877128ce` | 待领取 | — |
| `TASK-chat-markdown-list-20260918.md` | — | 真机排版反馈:聊天正文列表**没有项目符号**Tailwind v4 preflight 清了 `list-style``.markdown-list` 没恢复,BUG-962);`promoteDefinitionLists` 把四标题口语体的散文误判成并列项,三段正文被改写成列表(BUG-963,判据太松,收紧而非删除——BUG-356 的场景要留)。基线 `ea0280c1` | 待领取 | — |
| `TASK-first-paint-dead-screen-fallback-20260917.md` | — | 真机:首页永远停在「正在载入账户」,兜底全在没跑起来的 bundle 里(BUG-936 investigating)。根 layout 加与 bundle 无关的内联兜底 + 去掉本仓正则后行断言 | 待领取 | — |
| `TASK-consultation-answer-start-anchor-20260917.md` | `PROGRESS-consultation-answer-start-anchor-20260917.md` | 主会话回答落在结尾:`useConversationScrollAnchor` 是贴底跟随,流式期间视口钉在最后一个字,回答开头滚出视口;改为发送后问题钉顶、回答向下长、长出视口显示「跳到最新」、末尾动态留白;产品追加拍板:校正面同一语义(推翻 BUG-041/048 贴底),本轮开头 = 用户行或新助手行。BUG 段 930 起 | 已验收(经修复单) | `worktree/green-harbor-5be3` |
| `TASK-consultation-answer-start-anchor-fix-20260917.md` | `PROGRESS-consultation-answer-start-anchor-fix-20260917.md` | 验收修复单:F1 头就是留白行时留白按整视口算(BUG-931);F2 留白只在钉住期间存在(BUG-932);前置:先修 e4e73f56 的两处 TS 错否则门禁不过 | 已验收 | `cc1a8980`Claude 验收:tsc 0 / lint 0 error / npm test 3457 条 39 红与 11c0028d 逐条一致、新增 2 条绿 / `next build --webpack` 通过、`/` Static、首屏 gzip 591,242(较 09-16 基线 582,800 +1.45%,含会话列表单)/ Chrome 真实布局 S1–S6 全部通过,S6 新助手行距顶 16px 且增高不动,S5 不再写留白);真机六条欠 |
@@ -0,0 +1,82 @@
# TASK · 回答正文的列表渲染(2026-09-18 第六轮)
> 基线:`origin/staging` @ `ea0280c1`(代码部分 = 已部署的 `877128ce`)。
> 触发:产品在 staging 真机看申报时段回答,反馈「排版没对齐、看起来很难受」。
> BUG 编号起点:`docs/BUG_HISTORY.md` 当前最大号 **BUG-958**`TASK-contract-degraded-pass4-20260918.md` 已占 959~961,本单占 **BUG-962 ~ BUG-963**。
## 0. 复现方式(已在本机用真实构建复现)
1. 取 staging 真实一轮的回答原文(申报时段 / 「未来半年我事业如何?」)。
2. 用仓库自己的渲染管线跑:`renderChatMarkdown(answer)``src/components/chat-markdown-view.tsx`)。
3.`next build --webpack` 产物里的 CSS chunk 套上 `.message-markdown` 容器,headless Chrome 截图。
产出的 HTML(节选,**这是渲染器真实输出**):
```html
<h2>先回答你的问题</h2>
<p>这是你出生窗口内的稳定结构,不是某一分钟的盘。……</p>
<ul class="markdown-list">
<li><p><strong>你这半年的事业是「外刚内不承」</strong>:表面硬气是真的硬——……</p></li>
<li><p><strong>推的是火星</strong>:事情由你自己起动、自己顶上去。……</p></li>
<li><p><strong>所以别去应火星的「硬顶」,也别去应土星弱位的「拖」。去扮演太阳的「署名」</strong>:……</p></li>
</ul>
<ul class="markdown-list"><li>口头承诺一律补一条确认消息</li>……</ul>
```
模型写的是**三段散文**,渲染出来变成了**三条列表项**,而且和结尾真正的行动清单用同一种样式。
## 1. BUG-962(P1)聊天正文的列表没有项目符号
`src/app/globals.css:1336-1349``.markdown-list` 设了 `display: grid``gap``padding-inline-start: 1.35em`**但没有恢复 `list-style`**。项目是 Tailwind v4`@import "tailwindcss"` 的 preflight 把 `ul, ol``list-style` 清成 `none`
结果:所有列表项只是「往右缩进一段的孤行」,看不出是清单;正文段落靠左、列表块缩进,页面出现两级左边界——这就是产品说的「没对齐」。
已验证:在同一份编译 CSS 上加一行 `list-style: disc` 后,`display: grid``::marker` 正常渲染,**不需要改布局方式**。
**要求**
1. `.message-markdown .markdown-list` 恢复项目符号:`ul``disc``ol``decimal``::marker` 颜色取次级文字色(不要纯黑)。
2. 顺带核对同一文件里其它被 preflight 清零又没恢复的列表(`personal-report-markdown-view` 走的是另一套样式,本单不动)。
3. 验收标准:新增一条渲染测试断言 `.markdown-list` 的计算样式 `list-style-type !== "none"`(或源码级断言该选择器块内含 `list-style`);进度记录附改前改后截图。
## 2. BUG-963P1)散文被自动提升成列表
`src/lib/chat-definition-lists.ts``promoteDefinitionLists`:连续 ≥2 个「X:Y」形式的段落会被改写成 `- **X**Y` 列表。
它是 BUG-3562026-08-23)的修复,当时要治的是「行运 / 适合推进这类**并列短项**被挤成一坨段落」。但 BUG-943(今天)把本命正文改成四标题口语体之后,正文散文**本来就长这样**——「你这半年的事业是 X:……」「推的是火星:……」——于是整段正文被误判成并列项。
现在的判据太松:
- `DEFINITION_LINE = /^(.{2,80}?)[:](.+)$/` 的 term 允许含句号,所以「……也别去应土星弱位的「拖」。去扮演太阳的「署名」」整串都成了 term;
- body 只要求 `length >= 4`,一段一百多字的多句散文照样算「解释」。
**要求**(收紧,不是删除——BUG-356 的场景要继续工作):
1. term 不得含句末标点(`。!?;!?;`)与换行。
2. body 必须是**单句**:不含句末标点,或仅以一个句末标点收尾。
3. body 长度上限(建议 ≤ 40 个字符,实现方可按 BUG-356 的真实样例校准),超过就是散文,不提升。
4. 三条**全部**满足才提升,且仍要求连续 ≥2 段。
5. 验收标准:
- 回归 fixture 用**两份真实正文**:BUG-356 的并列短项(仍然提升)与本轮申报时段回答(**不再提升**,保持三个 `<p>`);
- `chat-definition-lists.test.ts` 既有断言若需改动,写「原值 / 新值 / 原因」三栏。
## 3. 硬红线
1. `tsc --noEmit` 0 错、`npm run lint` 0 error、`npm test` 失败数不超过基线 `877128ce` 实测的 31 条且清单一致;测试总数不低于 3501。
2. 同一提交更新 `frontend/DESIGN.md`:写明聊天正文里「列表有符号」「散文不自动变列表」两条口径,以及判据阈值。
3. 不改 `next build``/``○ Static`;首屏 gzip 变化在 ±2% 内(本轮只动 CSS 与一个 lib,预期接近 0)。
4. 不得顺手改个人报告页的 Markdown 样式(那是另一套,未收到反馈)。
## 4. 开工前置
```bash
git fetch origin --prune
git worktree add -b codex/chat-markdown-list-20260918 \
.worktrees/chat-markdown-list-20260918 origin/staging
cd .worktrees/chat-markdown-list-20260918/frontend
npm test 2>&1 | grep -E "^# (tests|pass|fail)" # 开工基线:tests 3501 / pass 3455 / fail 31
```
截图复现法(本单验收要用同一套):把真实回答喂给 `renderChatMarkdown`,套 `next build` 产物里的 CSS chunk,用 headless Chrome 截 `.message-markdown`
收工:`docs/tasks/PROGRESS-chat-markdown-list-20260918.md`(附改前改后截图)+ `docs/BUG_HISTORY.md`BUG-962/963+ `frontend/DESIGN.md`,与代码同一批推 `staging`