修复高影响问题
并写交付说明

先理解今天的原理

问题优先级由影响范围、严重程度和出现概率共同决定。一个只在极端宽度发生的轻微间距偏差，通常低于所有手机都会遇到的链接失效。

交付说明记录别人怎样启动、验证和继续维护项目。它把只存在于当前会话里的信息变成项目资产。

为什么今天要做这件事

1. 按优先级处理可以保护有限时间。
2. 清楚的交付说明能检验项目是否真的离开你的电脑也能运行。
3. 已知限制写明后，下一版不会重新调查相同问题。

开始前检查

这是第 06 天。先完成下面的检查，再开始操作。缺少关键材料时，先补材料，不要让 Agent 猜。

1. 昨天的测试矩阵和问题证据齐全。
2. 当前代码已经保存基线，能够查看修改差异。
3. 确认今天不新增页面范围和新功能。

一步一步完成

第 1 步：把昨天的问题按影响重新排序

优先级看用户能否完成主要任务。页面打不开、内容被遮挡和联系链接失效属于高影响；轻微间距差异可以留到下一版。

1. 打开 evidence/day-5-test.md。
2. 为每个失败项标记阻断、高、中或低影响。
3. 在同一级别里，把出现范围更广的问题排在前面。
4. 删除没有复现步骤和证据的猜测项。
5. 把今天要修的项目控制在阻断和高影响范围。

完成这一步后，你应该看到：你得到一份有明确顺序的问题清单，能解释为什么先修第一项，也知道哪些问题今天不会处理。

第 2 步：保存修复前状态

开始修复前要保留可恢复状态。这样修改引入新问题时，可以查看差异并退回这一项，而不用猜哪段代码造成影响。

1. 确认页面仍能使用昨天记录的命令启动。
2. 如果使用 Git，运行 git status 和 git diff。
3. 保存当前文件清单和测试表。
4. 有未提交改动时先说明来源，不把多天改动混在一次修复里。

完成这一步后，你应该看到：修复前的代码、测试结果和文件差异都有记录；出现问题时可以准确找到本轮改动。

第 3 步：一次只修一个高影响问题

一次同时改多个原因，测试失败时很难知道是哪一项造成。每轮修复都从一个清楚问题开始，改动完成后马上验证。

1. 把问题的条件、复现步骤和预期结果交给 Codex。
2. 要求它先定位原因和计划修改的文件。
3. 确认范围后再允许修改。
4. 查看修改差异，确认没有顺手重构无关内容。
5. 运行这一项对应的测试。

完成这一步后，你应该看到：当前问题消失，修改文件与计划一致，其他页面内容和功能没有被顺手改动。

第 4 步：完成全部回归检查

单项测试通过，只能说明原问题消失。完整回归要重新跑 390px、768px、桌面、键盘、链接和控制台，检查修复有没有带来新问题。

1. 复制昨天的测试矩阵，建立修复后结果列。
2. 按原顺序重跑 T01—T06。
3. 为通过项记录实际结果，不只写“正常”。
4. 发现新问题时加入清单并重新排序。
5. 所有阻断和高影响项通过后，保存最终测试表。

完成这一步后，你应该看到：完整测试矩阵有修复后的实际结果；阻断和高影响项目全部通过，没有未记录的新失败。

第 5 步：写一份别人照着能启动的 README

README 用来帮助下一位维护者在新终端里找到项目、安装依赖、启动页面和检查结果。文档里的命令必须亲自再执行一次。

1. 写清项目用途和最终页面包含什么。
2. 记录环境要求、依赖安装和启动命令。
3. 说明真实内容、图片、程序和证据分别放在哪里。
4. 写下桌面、手机、键盘和链接检查方法。
5. 新开终端逐条执行 README 命令，并修正文档与实际不一致的地方。

完成这一步后，你应该看到：不依赖本次聊天，另一位使用者也能根据 README 找到项目并启动页面。

第 6 步：把已知限制和下一版想法分开

已知限制描述当前版本确实存在的问题；下一版想法记录还没有进入范围的功能。两者分开以后，交付者能判断当前是否可用。

1. 列出尚未解决但不会阻断交付的问题。
2. 为每个限制写明影响条件和临时处理方式。
3. 把博客、后台、多语言等新功能放进下一版候选。
4. 写明哪些原始内容和规则不应直接修改。
5. 保存最终截图和交付说明。

完成这一步后，你应该看到：README 能诚实说明当前能力和限制；下一版候选没有被误写成已经完成。

请处理测试记录中的一个问题：

问题：
出现条件：
复现步骤：
预期结果：
实际结果：
证据：

先说明最可能原因、计划修改的文件和验证方法。等我确认后再修改。
只处理这个问题，不新增功能，不重构无关文件。完成后展示差异并运行对应测试。

# 个人作品主页

## 项目目的与使用者

## 当前版本包含

## 环境要求

## 安装与启动
```bash
cd app
npm install
npm run dev
```

## 内容与图片位置

## 检查方法
- 390px / 768px / 桌面
- 键盘 Tab 与 Enter
- 链接与控制台

## 已知限制

## 下一版候选

## 不应直接修改的原始材料

这次真实操作得到了什么

1. 只修改手机媒体查询中的字号、行高、字距和换行规则；桌面结构与项目交互保持不变。

本次实际结果：390px 文档宽度仍为 390px，构建与自动复测通过。

正确结果长什么样

完成操作后，用结果来判断今天是否学会。页面能打开或命令能运行，只能说明流程启动了；下面这些证据同时出现，今天才算完成。

1. 所有阻断和高影响问题已修复并回归通过。
2. README 中的安装、启动和检查命令可以实际执行。
3. 内容、图片和程序的位置写得清楚。
4. 已知限制与下一版候选项已经分开记录。

常见错误与恢复

留给明天的材料

结束前把今天的关键结果保存到项目目录。下一天会直接使用这些材料，保存清楚可以减少重复说明和错误猜测。

1. 通过回归的项目版本。
2. 可实际执行的 README。
3. 问题优先级、修复证据和已知限制。