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

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

1. 问题定义

• 项目目标：发布管线确定性（构建源=origin/main）；移动端全站溢出修复（用户实测报告）；Lighthouse 真分数与 P0 性能优化落地；en/archives 404 补页
• 目标用户：站长（发布/管理）与移动端读者
• 核心价值：Sveltia 保存即上线的硬前置落地；手机体验从"可晃动破版"到全宽段合身

2. 假设与待确认

2.1 已确认事实

• 移动审计实锤：Header 7 项一行在 390px 溢出 51-88px（B1）；.prose-tech 缺断词（M1）
• Lighthouse 诊断：614 个 @font-face 708KB 渲染阻塞=Perf 62 元凶
• blog 仓公开 → 裸 clone 匿名 fetch 可行

2.2 关键假设

• 320px 超窄 en 残溢记录为已知边界（现实机型 ≥360）
• 正文排版断点为可读性台阶（有意保留）

2.3 待确认问题

• 页面自适应方式 → 结论：布局层流式（clamp/auto-fill）+ Header clamp 连续收缩 + <350px 导航内滚兜底（用户设计诉求"根据设备自适应"驱动）

2.4 可选解释与取舍

• clamp 流式 > 阶梯断点补丁（任意宽度合身，无逐档维护）-> 选流式
• 导航内滚 < hamburger 抽屉（保单行设计语言，改动最小）-> 选内滚

2.5 已证伪路径

• 阶梯断点逐档补丁（430/370 两轮后仍要第三档——治标）

3. 功能范围

3.1 核心功能（MVP）

• T1 裸 clone 构建改造
• T2 移动端布局全页排查与修复
• T3 Lighthouse 真测与 P0/P1 优化落地
• T4 /en/archives/ 补页
• T5 验证收官

3.2 扩展功能

• 无

3.3 不在范围内

• Sveltia 站内入口（下轮）、320px 超窄支持（已记录边界）

4. 最小实现路径

• 最简单可行方案：构建仓 fetch+reset 硬跟 main；Header clamp 替换阶梯；字体 ?url 非阻塞+按轨挂载
• 暂不引入：hamburger 菜单、流体排版（正文有意台阶）
• 不做的抽象/配置化：多构建源

5. 技术决策

• 技术栈：git fetch/reset、CSS clamp、@fontsource ?url、Playwright 密集宽度扫描
• 证据协议：evidence: runs
• 本轮允许改动：infra/deploy/、src/components/Header.astro、src/styles/global.css、src/pages/、scripts/lighthouse/
• 本轮不应触碰：nginx、gitea 运行时、生产内容
• Git integration branch：spec/2026-10-25_add-blog-5c

5.1 验证策略

• 范围级别：package
• 变更对象：构建管线、Header 流式化、移动端缺陷修复面、字体加载策略、en/archives 页
• 快速检查：pnpm astro build
• 集成检查：node tests/e2e.mjs（30 项）+ 移动溢出密集扫描（宽段 320-768 × scrollWidth 断言）
• 全项目检查：Lighthouse 复跑对账（Perf 62→88 基线）+ 生产移动端抽查；仅在构建链或 Header 结构再变更时升级范围
• 升级触发：仅在 nginx 面、构建链、发布载荷变更时升级验证范围并记录理由

6. 成功标准与验证方式

• 移动溢出密集扫描 44 检全过（320-768） -> verify: task_0002
• staging 恒等 origin/main（裸 clone 构建） -> verify: task_0001
• Lighthouse Perf 62→88 实测 -> verify: task_0003
• en/archives 200 -> verify: task_0004

7. 风险与约束

• ESA 边缘缓存旧页会伪装修复失效（刷新后为准）；构建仓 node_modules 留存做增量（loader 逻辑变更须清 .astro 数据仓——前包教训）