脚本目录里的测试全绿之后，仍有一个问题：换一台只拿到 wheel 的干净解释器，能不能提交、运行、查询、取消，并在失败时说清状态和资源归属？结课不能只靠 PYTHONPATH=src 下的回归。2026-10-12 从当前累计源码重新构建 wheel 和 sdist，用哈希锁安装构建工具；在仓库外创建不含 pip 的目标 venv，用独立 uv 安装 wheel，执行时移除 PYTHONPATH。

新 wheel 的 SHA-256、成员列表及每个 tasklab/*.py 与当前源码相同的核对结果在 examples/python-language/evidence/completion/acceptance/wheel.json。不是仅凭 py3-none-any 标签推断所有运行时都兼容：普通目标是 macOS arm64 CPython 3.12.3，模块路径指向目标 venv 的 site-packages。additional/source-is-not-installation.stderr 则保存故意从源码导入后安装位置断言失败的负例，退出码 1。

每种入口返回同一业务结果

安装环境下实际完成顺序执行、线程与 spawn 进程的词频任务，随后验证 SQLite 重开查询与独占恢复：已完成结果保持 succeeded，被领取却没有提交结果的任务标为 failed、结果未知。run_async、有界队列及回环 JSON 行接口也交回 {"one":2,"two":1}；接口提交确认后的第一次查询仍是 queued，另发 run 后才是 succeeded，取消另一个排队任务得到 cancelled。35 的强制终止已分别证明未提交事务与已提交 running 的恢复结果不同。合起来是对同一任务合同的多入口核对，不是新造五套任务系统。

从目标 venv、源码目录外运行 tools/check_installed.py，逐项检查跨进程 CLI 的提交、执行、查询、取消和错误退出码，并读取 SQLite 的任务 ID、终态、结果及完整性检查。experiments/39_integrated.py 核对安装路径和各策略合同；完整测试入口还覆盖停止接收、迟到 handler、半帧连接与强制终止后的恢复。实际数量和结果以 acceptance/cpython-tests.stderr 为准。个别基准测试自行启动源码路径检查边界，因此完整测试数量不能当作全部只从 wheel 执行的数量；安装 CLI 和集成脚本的导入来源单独记录。

完整累计工程、构建锁、选修依赖哈希锁、00–39 与 E01–E08 的实现、本次原始证据和新 wheel/sdist 放进同名素材归档：下载可复跑的 tasklab 累计工程。归档含逐文件 SHA 清单，排除临时构建目录、.pyc 和机器特定 .so。安全解包、重新核对全部文件、创建第二个干净 venv 安装归档内 wheel，再重放 CLI、集成、完整测试及 E08；结果与归档哈希在 writing-plans/python-language/completion/evidence/delivery/summary.json。页面与归档自己的摘要保存在归档外，避免自引用。

1
2
cd examples/python-language
PYTHONPATH=src "${PYTHON:-python3}" -m unittest discover -s tests -v

当前命令、解释器路径、退出码、原始 stdout/stderr 见 examples/python-language/evidence/completion/acceptance/commands.json；可移植复现入口见 RUN.md。旧 evidence/39/20261008-final/ 是历史记录，不用于替代这次安装。

全部 48 篇正文、导航、图注、代码和链接的独立页面检查另记录在 writing-plans/python-language/completion/evidence/pages/。页面生成不证明业务测试通过，wheel 安装也不证明网页已部署；本地交付没有推送、网站部署或 PyPI 发布。

测试通过不等于保证外部副作用恰好一次。历史 38 的 free-threaded 构建缺 _sqlite3，全套失败仍保留；本次另一个 macOS 3.13.9t 构建含 SQLite，安装同一 wheel 后独立执行完整回归。两者不可互相代验。E04 的 PyPy初轮两项失败已修复，当前完整回归无失败、保留两项实现能力跳过；内存实验使用 PyPy 原生 GC 聚合快照，不冒充 CPython 的逐分配 tracemalloc。选修 C 扩展只声明并验证相应 CPython ABI。

预测题

一个客户端已经收到 submit 的任务 ID，调用方却在下一次查询看到 queued。重启时另一个任务的持久化状态是 running。哪一项可以直接视作词频结果，哪一项需要先确认执行者是否仍存活？

答案：两项都不能直接当作结果。第一项只是已接收的排队任务，须完成 run 并查 succeeded 与结果；第二项可能是在已提交领取后中断，也可能仍由活工作者处理，必须先隔离执行者，才能把遗留 running 标为结果未知的失败。外部副作用是否完成还需自己的确认或幂等机制。

变更题

从 25 的旧 wheel 安装成功，却用 PYTHONPATH=src 跑过第 39 篇集成脚本，能否宣称累计包已安装可用？把普通构建的通过直接搬到另一个缺 SQLite 的 free-threaded 构建，又能否补齐缺扩展？

答案：都不能。第一种导入路径可能来自更新后的源码，须移除 PYTHONPATH 并检查 tasklab.__file__ 指向目标 venv，重建制品并从新 venv 重放；第二种版本、编译模式和扩展集合变了，必须在相应构建单独安装、运行并保留失败。

系列导航列出全部主线和选修；每个环境的实测范围仍由对应证据确定。

参考资料