运行检查

检查不是最后补一句“已通过”。在博客搜索案例里，检查要回答三个问题：

• 这次改动有没有格式、路径或边界问题。
• 用户可见行为有没有被验证。
• 哪些检查没有运行，原因是什么。

第一次闭环的最小检查

如果你只做前端本地过滤，先跑：

git diff --check
npm run test:plan

如果项目有前端测试入口，再补真实命令：

npm run test -- --blog

没有 npm 命令面板时，用项目自己的测试入口替换，不要伪造通过结果。

修改项目协议后的检查

博客搜索如果同时更新了 .maw/、模块档案、任务包或 AI 指令，再跑：

bash ops/scripts/check-local-boundary.sh
bash ops/scripts/check-template-module-docs.sh
bash ops/scripts/check-ai-framework-consistency.sh

这些命令用于确认：

• 没有把 .local/、本机路径或真实密钥写入可提交文件。
• 模块档案、任务包和 AI 协作说明没有互相冲突。
• 新手指南、任务包和检查脚本仍符合 Seed 协作规则。

复杂任务的分段检查

Task Pack 不要等最后才检查。可以按阶段记录：

子任务	建议检查
审计当前博客列表	git diff --check，确认只更新状态文件或报告。
实现搜索 UI	前端测试、截图检查或手工验证说明。
增加后端搜索	后端单元测试、API smoke 或接口契约检查。
更新模块文档	模块档案检查和文档链接检查。
最终收口	全部相关检查和发布影响判断。

每一段都更新 SESSION_STATE.md，写清已运行命令、未运行命令和下一步。

公开分享前的检查

如果你要把博客搜索任务包作为公开示例分享，先运行：

bash ops/scripts/check-local-boundary.sh
bash ops/scripts/check-seed-open-source-readiness.sh --strict --format json
bash ops/scripts/check-seed-distribution-readiness.sh

人工复核：

• 示例里没有真实项目名、客户名、截图、日志或账号。
• 仓库地址使用公开地址或占位。
• 验证命令不依赖私有服务。
• README 写清适用范围和不适用场景。

失败怎么处理

失败类型	处理方式
git diff --check 失败	修格式、尾随空格或冲突标记后重跑。
本机路径泄漏	改成仓库相对路径，真实内容放回 .local/。
测试入口缺失	先补测试计划入口，或在收口中说明未配置。
静态检查缺片段	判断是页面确实缺内容，还是检查规则需要同步。
检查不适用	写明不适用原因，不写成已通过。

收口示例

验证：
- git diff --check：通过。
- npm run test:plan：通过，输出博客搜索相关测试计划。
- npm run test -- --blog：未运行，当前项目尚未配置前端测试入口。

风险：
- 目前只验证前端过滤；如果后续接入后端分页，需要补 API 测试。

下一步

阅读 学习模式，把博客搜索过程中确认的术语、边界和踩坑经验沉淀下来。