第一个问题：这个包现在有什么问题

第一个问题：这个包现在有什么问题？
一、最严重的问题：状态机声称锁住了文件，实际上没有真正锁住

文档宣称状态迁移会检查：

项目是否一致
输入输出文件是否存在
文件哈希是否一致
交接件是否属于当前项目

但实际的 transition.py 没有完整做到。

我构造了一个交接件：

project_id 故意换成完全不同的项目
approved_artifacts 填一个根本不存在的文件
locked_hashes 填一个假的全零哈希

结果状态机仍然返回：

PASS C0 -> W1

也就是说，现在的状态机主要验证的是：

“这张JSON表长得像不像合法交接表。”

而不是：

“这次交接所指向的真实文件和真实项目是否真的成立。”

这是目前最该修的工程漏洞。它不会立刻影响人工使用，但会让系统产生一种危险错觉：以为机器已经保证了真实性，实际上只是保证了字段格式。

应该怎么修

状态迁移必须增加以下硬检查：

state.project_id == manifest.project_id
approved_artifacts 中每个路径必须真实存在
所有批准产物都必须在 locked_hashes 中登记
locked_hashes 必须对真实文件重新计算，而不是相信提交者填写的值
禁止绝对路径、..和项目目录外路径
excluded_artifacts 不能被任何后续阶段重新引用
Apply前写入事务日志，失败时不得部分更新
交接后重新读取状态文件，确认落盘结果

这一项应该作为 v0.15.1阻塞修复，不该拖到未来大版本。

二、运行卡也存在两个真实绕过点

我又测试了合法运行卡，把：

method_version 改成假的 999.999-FAKE
直接删除 source_tier

验证器仍然返回：

PASS

原因是：

method_version 虽然必填，但没有与注册表版本比较
source_tier 在Schema中不是必填字段，缺失时验证器就不检查

这说明“版本锁”和“来源层级锁”还不是完全机器化的。

应该修成
method_version 必须等于注册模块版本
source_tier 必须强制填写并匹配注册值
runtime_card版本也应登记哈希
actor_role不能只是任意字符串，应来自岗位登记表
selected_method、method_id、版本、模块哈希、运行卡哈希应形成一个不可拆分的调用身份

否则未来会出现这种情况：

文件哈希是对的，但调用者声称自己运行的是另一个版本，日志和实际执行内容对不上。

三、“人工批准”目前只是一个可以被AI自己填写的布尔值

现在很多关键门依赖：

"human_approved": true

但这并不能证明真的有人工批准。

只要让AI生成运行卡，它完全可以自己输出 true。系统无法区分：

人真的批准了
AI自己写了“已批准”
操作者复制模板时忘了改
上一个项目的批准字段被复用

这是治理系统里很常见的“形式合规幻觉”。

正确做法

人工批准应该变成独立对象，例如：

{
  "approval_id": "APR-20260803-001",
  "project_id": "PROJECT-X",
  "artifact_sha256": "...",
  "decision": "APPROVED",
  "approved_by": "human-owner",
  "approved_at": "...",
  "scope": "C0_TO_W1",
  "comment": "..."
}

运行卡只能引用 approval_id，验证器再核对：

批准对象哈希是否一致
批准范围是否匹配
批准是否发生在产物生成之后
产物批准后是否被修改

不一定要上密码学签名，个人使用可以先用独立批准回执和追加式日志。但不能继续只靠一个 true。

四、它号称“完整迁移”，却没有完整依赖声明

根目录没有：

requirements.txt
pyproject.toml
锁定依赖版本
安装脚本
环境检查器

实际运行依赖至少包括：

PyYAML
jsonschema

我用不加载第三方包的Python环境运行，立即报错：

ModuleNotFoundError: No module named 'yaml'

现在之所以全部测试通过，是因为当前机器恰好安装了：

PyYAML 6.0.3
jsonschema 4.26.0

所以它目前是“文件可搬迁”，还不是“环境可复现”。

建议

增加：

pyproject.toml
requirements.lock
python_version.txt
bootstrap.py
doctor.py

doctor.py至少检查：

Python版本
PyYAML/jsonschema版本
UTF-8文件系统
根目录写权限
Schema元验证
注册表哈希
发布清单
是否存在缓存和运行残留

然后只保留一个公开入口：

python doctor.py
python screenplay_system.py init
python screenplay_system.py next
python screenplay_system.py verify

现在命令太分散，新操作者很容易漏步骤。

五、测试不少，但没有统一的“发行总闸”

包内有18个测试脚本，我全部跑通了，这是好事。

问题在于：

没有 run_all_tests.py
没有 pytest/tox/nox统一入口
使用说明列出的常用测试只覆盖其中几项
14个测试文件主要依赖Python原生 assert
使用 python -O 时，很多 assert会被直接移除
test_complete_migration.py只检查目录和少数文件存在，不验证完整发布清单
没有测试验证外层ZIP哈希
没有从新目录解压最终ZIP后，再以成品包作为测试对象跑一次

换句话说：

单项测试很丰富，但“正式发布到底要跑哪些测试”没有被机器钉成唯一真相。

应该增加一个发布总闸

例如：

release_gate.py

一次完成：

创建干净临时目录
从正式ZIP解压
检查路径安全
检查依赖
验证发布清单
验证全部5297项哈希
运行全部18项测试
运行负面绕过测试
检查缓存和临时残留
重新打包并生成外层SHA-256
输出机器可读验收报告

现在的 RELEASE_MANIFEST.json 实际上并不是JSON，而是普通SHA清单：

HASH  path
HASH  path

内容本身没错，我已全部复核通过，但扩展名应该改成：

RELEASE_MANIFEST.sha256

否则未来某个工具按JSON读取，必然报错。

六、发布可复现性还没有被证明

包里有一个声称生成“deterministic ZIP”的打包器。

我用包内打包器重新打包，得到：

54f33129af7d4cf59781d25ec4486cc21017c78a3c45cf7d7081a02685ceb2ef

而上传原包是：

431b7028eb83ddc25d2cfb7fe3454a22ff398480450bafef4be2ce4569ad7592

这不表示原包损坏——原包内部文件哈希全部正确。差异可能来自压缩工具、zlib版本或原始发布并非由当前脚本生成。

但它至少说明：

“同一内容可以重新打包”已经成立；“任何环境都能复现同一外层ZIP字节”尚未成立。

未来不要笼统使用“确定性打包”这个说法。更准确的方案是：

内容确定性：文件清单和每项哈希一致
排序确定性：路径顺序固定
元数据确定性：时间、权限固定
压缩字节确定性：只在指定Python、zlib、OS和打包镜像中承诺

最稳的是提供一个固定构建容器或明确构建环境版本。

七、母包、运行包、来源仓混在一起，已经过重

解压后的主要体量：

90_SOURCE_VAULT：约 126MiB
24_DISTILLATION_LIBRARY：约 55MiB
22_CAT_CORE_MODULES：约 34MiB

三者合计约占整个母包的 87%。

而真正的：

配置
Schema
原生脚本
运行卡
核心知识卡
测试

体量其实非常小。

我还发现：

1241组完全相同的重复文件
约 39MB 可确认的冗余副本
同一原包在来源仓、蒸馏仓、工作副本、迭代副本中多次出现
包内有65个ZIP、5个RAR、1个7z，以及大量第三方Python、JS、Shell代码

这不是说这些东西不该保存。完整母包作为冷备份是合理的。

问题是：冷备份和每天使用的运行系统不该是同一个交付物。

建议拆成三包
1. Runtime运行包

只包含：

运行系统
配置
Schema
脚本
运行卡
已批准知识卡
必要适配器
测试

目标控制在几MB到几十MB以内。

2. Archive完整母包

保留全部：

来源原件
聊天旁证
第三方快照
蒸馏过程
被淘汰版本
历史审计证据

只做冷存储、追溯和重建。

3. Distribution安全分享包

只包含权利明确、可安全转发的内容。

这样既不损失完整性，又避免日常运行被5000多个文件拖累。