Files

T

Jesse_ChenandClaude Opus 5 0a1a87b06e 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

2026-09-18 09:40:33 +00:00

5.6 KiB

Raw Blame History

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. 复现方式（已在本机用真实构建复现）

取 staging 真实一轮的回答原文（申报时段 / 「未来半年我事业如何？」）。
用仓库自己的渲染管线跑：renderChatMarkdown(answer)（src/components/chat-markdown-view.tsx）。
用 next build --webpack 产物里的 CSS chunk 套上 .message-markdown 容器，headless Chrome 截图。

产出的 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 正常渲染，不需要改布局方式。

要求：

.message-markdown .markdown-list 恢复项目符号：ul 用 disc、ol 用 decimal；::marker 颜色取次级文字色（不要纯黑）。
顺带核对同一文件里其它被 preflight 清零又没恢复的列表（personal-report-markdown-view 走的是另一套样式，本单不动）。
验收标准：新增一条渲染测试断言 .markdown-list 的计算样式 list-style-type !== "none"（或源码级断言该选择器块内含 list-style）；进度记录附改前改后截图。

2. BUG-963（P1）散文被自动提升成列表

src/lib/chat-definition-lists.ts 的 promoteDefinitionLists：连续 ≥2 个「X：Y」形式的段落会被改写成 - **X**：Y 列表。

它是 BUG-356（2026-08-23）的修复，当时要治的是「行运 / 适合推进这类并列短项被挤成一坨段落」。但 BUG-943（今天）把本命正文改成四标题口语体之后，正文散文本来就长这样——「你这半年的事业是 X：……」「推的是火星：……」——于是整段正文被误判成并列项。

现在的判据太松：

DEFINITION_LINE = /^(.{2,80}?)[：:](.+)$/ 的 term 允许含句号，所以「……也别去应土星弱位的「拖」。去扮演太阳的「署名」」整串都成了 term；
body 只要求 length >= 4，一段一百多字的多句散文照样算「解释」。

要求（收紧，不是删除——BUG-356 的场景要继续工作）：

term 不得含句末标点（。！？；!?;）与换行。
body 必须是单句：不含句末标点，或仅以一个句末标点收尾。
body 长度上限（建议 ≤ 40 个字符，实现方可按 BUG-356 的真实样例校准），超过就是散文，不提升。
三条全部满足才提升，且仍要求连续 ≥2 段。
验收标准：
- 回归 fixture 用两份真实正文：BUG-356 的并列短项（仍然提升）与本轮申报时段回答（不再提升，保持三个 <p>）；
- chat-definition-lists.test.ts 既有断言若需改动，写「原值 / 新值 / 原因」三栏。

3. 硬红线

tsc --noEmit 0 错、npm run lint 0 error、npm test 失败数不超过基线 877128ce 实测的 31 条且清单一致；测试总数不低于 3501。
同一提交更新 frontend/DESIGN.md：写明聊天正文里「列表有符号」「散文不自动变列表」两条口径，以及判据阈值。
不改 next build 后 / 的 ○ Static；首屏 gzip 变化在 ±2% 内（本轮只动 CSS 与一个 lib，预期接近 0）。
不得顺手改个人报告页的 Markdown 样式（那是另一套，未收到反馈）。

4. 开工前置

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。

5.6 KiB Raw Blame History Unescape Escape