# 仅检查写作环境

用于 `story-setup check` 或「检查写作环境」「为什么 agent 不可用」等诊断请求。只检查并报告，不复制文件、修改配置、创建部署标记或运行部署、迁移、提交命令。用户已要求修复时，先列出发现，再按 `story-setup/SKILL.md` 的原有部署流程与对应宿主的 `references/deploy-*.md` 处理。

## 1. 确定检查对象

优先使用用户指定的项目根；未指定时从当前目录向上找最近的 `.story-deployed`。找不到则报告「未找到部署标记，无法确认部署状态」，检查现有文件和运行环境，不据此自动初始化。不要扫描无关项目。

读取 `.story-deployed` 的目标端、版本和 reference 路径。多个目标端分别检查；字段缺失、内容不可解析、目标端未知时记录具体问题，不猜一个端写回。将 `agents_version` 与当前 `story-setup/SKILL.md` 比较；本地包较旧时先更新，不能降级重铺。

## 2. 复用部署验证

以每个目标端对应的 `references/deploy-{target_cli}.md` 里的「部署清单」与「验证」为准（只读目标端那几份），加上 `story-setup/SKILL.md` Phase 3 的部署标记检查，逐项读取目标文件并执行只读校验。skill、agent 与 hooks 清单均沿用部署文件。

- 区分安装的 skill 包和项目部署副本：Claude Code、Codex、OpenCode 的项目路径主要保存 agent、hooks 和参考资料，不要求在那里出现整套 `SKILL.md`。其他端按各自部署清单检查；skills-only 端没有原生 agents/hooks 是预期行为。
- 参考资料按源目录的相对文件列表逐一核对，包含子目录；只看目录非空或文件数量相同不足以证明完整。源包不可用或源与目标是同一份时，说明无法独立验证完整性，不把它判为通过。
- 检查 hooks 的配置注册与脚本依赖，不仅检查文件存在；采用各部署文件「验证」中的语法、解析和注册校验，不主动运行可能写入项目的 hook。
- 文件存在只能说明部署文件就绪。当前会话是否加载了 custom agents、hooks 是否已信任，结合宿主实际暴露的能力和可见状态判断；无法确认时记为「未验证」，不要仅因文件存在就宣称可调用，也不要为体检启动写作任务。

## 3. 运行环境与追踪

实际执行 `node --version`；Python 按跨平台约定依次探测 `python3`、`python`、`py`，运行版本检查，确认是 Python 3 后使用该解释器。命令存在但不能执行不算通过。缺失时说明受影响的具体脚本；不自动安装依赖，不调用模型或联网鉴权。

若本次检查涉及长篇项目，按用户指定书目、`.active-book` 或已有 `追踪/` 确定书根；支持当前目录就是书根和 `长篇/{书名}/` 的布局。没有长篇项目则跳过追踪检查，不因此告警。

使用已安装 `story-long-write` skill 的现有校验器：

```bash
"$PYBIN" -B "{story-long-write skill目录}/scripts/tracking_commit.py" check --project "{书根}"
```

`PYBIN` 是前面已成功探测的 Python 3。这个 `check` 校验追踪状态及派生视图；不要用「JSON 能解析」代替它。缺解释器、校验器或其依赖时报告未能完成检查，不另写简化校验器，也不调用 `init` / `commit` 修复。追踪问题沿用 `UPGRADING.md` 的迁移说明和现有追踪事务流程。

## 4. 报告与后续

读者是不懂编程的作者。报告先用写书的话写两段：「现在能用什么」（正常可用的写作能力，一句话概括）和「需要你做什么」（逐条可照做，如「新开一个会话」「在 Codex 里打开 /hooks 信任一下」；没有就写「无需操作」），这两段不出现脚本名、字段名、状态名或文件路径。之后才按「发现的问题」「未验证项」汇总技术明细，每项给出目标端或书目、文件路径/命令结果、具体影响和下一步；正常结果合并概述，skills-only 的预期限制不渲染成安装失败。结论写明本次实际验证的能力。

需要补部署文件时建议重跑 `story-setup`；源包本身缺失或比项目旧时先更新源包，再部署；当前会话未加载能力时提示新开会话或完成该 CLI 的信任步骤。仅检查请求到此结束，不为了消除告警自行执行修复。