blog/.spec/specs/2026-10-25_add-blog-5c/spec.md

Phase 5c：裸 clone 构建 + 移动端布局排查 + Lighthouse 真测 + en/archives 补页 - 项目范围

1. 问题定义

• 项目目标：一句话描述项目要解决什么问题
• 目标用户：谁会使用这个产品或系统
• 核心价值：完成后能持续提供什么价值

2. 假设与待确认

2.1 已确认事实

• 事实 A

2.2 关键假设

• 假设 A

2.3 待确认问题

• 问题 A

2.4 可选解释与取舍

• 当前选择：xxx -> 理由

2.5 已证伪路径

• 无（暂无证伪记录；条目写：方案概述 + 证伪依据出处 + 日期）

3. 功能范围

3.1 核心功能（MVP）

• 功能 A：描述

3.2 扩展功能

• 无

3.3 不在范围内

• 明确列出本轮不做的内容

4. 最小实现路径

• 最简单可行方案：xxx
• 暂不引入：xxx
• 不做的抽象/配置化：xxx

5. 技术决策

• 技术栈：xxx 或适用外
• 证据协议：evidence: runs（机器任务 verify 命令由 scripts/spec_verify.py run 真实执行并记录 runs.jsonl；无命令任务写 verify: manual: <理由>；verify 命令不得自引用本包 check 门禁）
• 本轮允许改动：xxx
• 本轮不应触碰：xxx
• Git integration branch：spec/2026-10-25_add-blog-5c

5.1 验证策略

• 范围级别：package
• 变更对象：本任务包 boundary 涉及的模块、入口和数据契约
• 快速检查：<变更对象对应的局部测试/静态检查命令>
• 集成检查：适用外：本轮没有直接受影响的跨模块用户路径
• 全项目检查：适用外：本轮不涉及共享基础设施、跨模块契约或发布载荷；由发布门禁统一执行
• 升级触发：只有改动共享基础设施、跨模块契约、构建/依赖、发布载荷，或 package/integration 检查暴露跨边界回归时，才把范围升级并记录理由

6. 成功标准与验证方式

• 标准 A 达成 -> verify: task_0001
• 标准 B 达成 -> verify: task_0002

7. 风险与约束

• 风险点：xxx -> 缓解措施