发布 FLH v1.0：派生的阶段摘要、演练过的回滚与真实浏览器冒烟测试

语言： English | 简体中文

发布日期：2026-11-08

FLH v1.0.0 是第一个我认为可以长期个人使用的版本：一个 Docker 镜像，包含 Go 服务、SQLite 和 React 工作台，只绑定 127.0.0.1。这次发布的主要工作不是新功能，而是让”从问题到 Concept”的日常流程清晰可循，再验证升级可以回退、打包后的应用能在真实浏览器里工作。

我的工程贡献：梳理发布缺口，规定任何发布检查都不能触碰日常实例，并决定哪些证据足以打 v1.0.0 标签。

阶段摘要：派生而不存储

学习记录以前把分析、反馈和提取分成独立面板，看不出哪一步待处理。现在每条记录显示 Where this record stands：分析 → 提取 → Concept 决定，并给出唯一的 Next: 操作。

摘要在渲染时由页面已有的读取推导，外加每个已决定 unit 一次 GET。它不写入数据库，所以不会与记录不一致。记录、unit 所属的 Concept、来源记录和 AI 建议之间都有链接，← Back 返回离开时的视图（视图保持挂载）。

没有改动任何接口、DTO、迁移或 provider prompt。一个一次性 fixture 用真实服务二进制和假的 OpenAI 兼容 provider 驱动整个流程，并对所有权威表做只读 SQLite 快照比对，结果 43 通过、0 失败，其中包括重新提取后过期、被 409 拒绝的建议。

在隔离项目中演练升级

演练一开始就发现了真问题：日常包装脚本写死了 Compose 项目名，compose.yaml 写死了镜像标签。任何设置文件运行 flh-daily.sh up，都会重建日常镜像并重建日常项目。

修复是一个需要显式开启的隔离模式：必须同时提供项目名和 override 文件；拒绝日常项目名和任何 french-learning-hub 镜像；再复查解析后的配置。不设置这两个变量时，命令行与以前逐字节相同。

随后用真实 Docker Compose 演练，43 通过、0 失败：

启动发布前的基线镜像，并用 fixture 写入数据；
备份，并把可用镜像保留为 :before-upgrade；
升级到候选版本，数据与基线快照逐字节一致；
用未知的服务参数制造一次失败升级；
恢复：stop → 重新打 :before-upgrade 标签 → restore。运行的镜像回到基线，数据逐字节一致。

这改变了文档中的回滚步骤。旧指南从上一个 checkout 重新构建；如果先恢复再构建旧镜像，新镜像可能再次迁移已恢复的数据库。现在的指南保留并重新标记已知可用的镜像。

每次运行前后都记录日常容器的 ID、状态、启动时间和镜像，始终没有变化。最早一次无效运行（快照为空）也保留在报告里，连同它促成的修复。

不会碰错服务器的浏览器冒烟测试

NAS 上没有浏览器，所以最初的冒烟脚本只做过语法检查。后续加入了”失败即拒绝”的归属检查：写入数据前，从实时 Docker 状态证明 127.0.0.1:PORT 属于它自己创建的演练项目，compose 文件、数据挂载、假 provider 都符合预期，数据库为空。指向 :8080 或 localhost 会在发出任何请求前退出。

Chromium 运行在一次性容器中。前五次运行都因测试脚本缺陷失败：选择器、/api 前缀，以及返回建议页时重新读取与过期阶段之间的竞争。没有发现产品缺陷。 最终两次运行均 36 项通过、0 失败。受控失败探针证明：冒烟失败时以非零退出，保留证据，只删除自己的资源。同一 workflow 之后也在 GitHub 托管 runner 上通过。

v1.0 没有证明的事

升级演练没有迁移数据库：两个镜像都是迁移 001–013。
假 provider 只证明机制，不证明模型判断；真实模型的建议质量未测量。
冒烟测试只在 Chromium、单一屏幕尺寸下运行。
没有身份认证；服务只监听回环地址，通过 SSH 隧道访问。

实现由 Claude Code 和 Codex 在我的指导、任务定义和审查下完成。

发布说明 · 日常流程 RC · 升级演练 · 浏览器冒烟 · 关于我

发布提交。