v0.0.2 — 修复状态文件损坏时门禁放行的安全问题

为什么要发这个版本

v0.0.1 的 tag 指向的是 2026-09-29 当时的提交，比当前 main 落后 9 个提交，因此 v0.0.1 不含下面这些内容（尤其不含安全修复）。v0.0.1 原样保留、未改历史。

下载请用本版本 v0.0.2。

自 v0.0.1 以来的改动

🔴 安全修复：state.yaml 损坏时 phase 守卫会放行（fail-open）

• 原状：只有“文件不存在”（ENOENT）被当作首次运行；其它读取失败/内容坏掉的情况被并进默认状态（current_phase: 0.1），守卫据此照常放行。
• 后果：把状态文件写坏（截断、二进制垃圾、空文件、缺字段、schema 不符）即可绕过阶段门禁与跳跃限制。
• 修复：新增分档读取 readStateGradedSync()，返回 present / reason（present | enoent | empty | bad | schema）。只有 enoent 携带默认状态；其余一律 fail-closed 拒绝，并给出恢复动作。审计监听器在状态不可信时记 (不可知)，不再冒充 0.1。
• 验证强度：离线（损坏五种情况各自断言 deny + 反向对照）与真实 DSH 进程活验都做过——故意写坏状态文件后，模型收到拒绝；坏文件未被改写；审计链留下 decision: deny；恢复后 SHA-256 完全一致；链完整。
• 仍成立的一条限制：不追溯——修复前已放行的历史记录不会被事后改写（那正是审计链的意义）。

详见 SECURITY.md §三与 dsh-fde-phase/README.md §4.7。

其它

• 仓库根目录整理；文档中两处 stale red（记录滞后于实现）已按源码证据订正。
• 四个插件版本号从 0.0.1 升到 0.0.2（此前开发期间从未升过，导致无法从版本号判断现场装的是哪一版）。
• 离线回归 41 个套件全绿；源目录与部署副本 88 个文件逐字节 ALL_MATCH 4。

安装 / 升级

见 README.md 与 docs/03-usage/deployment.md。要点：把 4 个 dsh-fde-* 目录放进 DSH 的 profiles/web/node_modules/，配置 projectRoot / ontologyRoot，改完 lib/*.js 必须重启 DSH。

说明

本项目仍是 PoC 阶段：单机单用户、手工装配，并如实记录若干能力降级（见 docs/01-overview/feature-matrix.md 与各插件 README 的诚实缺口清单）。

v0.0.1 — FDE Copilot PoC（首个可交付版本）

PoC 阶段的第一个可交付版本。 四个 DSH 插件、19 个工具、零运行时依赖。

这是什么

给 AI 助手装上工程护栏：改业务规则、推进项目阶段时，没通过校验就动不了，且所有动作都被记在一本改不掉的账（哈希链审计）上。

插件	管什么
dsh-fde-ontology-gate	谁能在什么条件下改本体（业务规则）
dsh-fde-dsl	改出来的规则能不能信（D3）+ 护栏绑没绑好（D1）
dsh-fde-phase	现在处在哪个业务阶段、能不能推进
dsh-fde-memory	决策、清单、干系人、笔记，以及审计采集

完成度（如实）

• 19 项功能：15 项活验完整、4 项部分完成、0 项未实现 —— 见功能对照表
• 回归：41 套（本机有部署时 41 跑；干净机器上 37 跑 + 4 跳过，跳过是明确标注，不是"已覆盖"）
• CI：windows-latest × Node 22.15.0 / 24，两档全绿

两条必须知道的环境边界

边界	事实
平台	这 41 套回归是 Windows 专用的。ubuntu-latest 上挂 9 套（路径语义 / shell 分词语义差异）。CI 因此固定在 windows-latest —— 没有改成"Linux 失败也算通过"（那是假绿）
Node	≥ 22.15。Node 20 挂 2 套：zlib 没有 zstdDecompressSync 这个导出（实测 20.20.2 无 / 22.15.0 有）。插件 lib/ 本身不用 zstd，所以「跑插件」无此要求
那 4 套	_fde_e1_wiring_test.mjs / _fde_e2_test.mjs / _fde_e5_test.mjs / _fde_phase_wiring_test.mjs 不是离线套件，要读你本机已部署的插件副本。没有那份部署时它们 exit 77 跳过。设 FDE_DSH_HOME=<你的 dsh-home> 即可真跑

已知未修（不是漏了，是修不了）

• 40 个活验脚本仍含作者本机路径。它们的行为必须连着运行中的 DSH 才能验证，而无法验证的改动不允许进主干 ⇒ 保留并写进 README 告知。
• 9 套回归无法在 Linux 上跑。它们是功能测试，不是可移植性测试；改成跨平台属于重写判据。
• D1 的 impl 是 DSL 表达式而非真可执行函数（PoC 降级，见 README 与 docs/05-ai-development/）。

⚠️ 一句必须说的话

本仓库的源码、测试与文档全部由 AI 工具生成。

⇒ 代码质量不能只用「41 套回归全绿」来论证 —— 那 41 套也是 AI 写的。
一个错误理解会被同时写进实现和测试，两边一致 ⇒ 测试全绿 ⇒ 错误被牢牢锁住。

这不是一个已解决问题的项目，而是一个把问题摊开、并给出压制手段的项目。 详见 DISCLOSURE.md 与 docs/05-ai-development/ai-code-risks.md。

快速开始

bash _run_all_tests.sh      # 不需要 DSH；期望末行 ALL-TESTS-GREEN

完整部署步骤见 docs/03-usage/deployment.md。