用途：为已存在但文档不足的系统编写文档，适用于继承或收购的代码库、原作者已离开的系统、与实际代码不再匹配的文档树，以及必须产出“这个系统到底做什么”文档的调查。不适用于为正在进行的改动写文档、论证重写（属于 writing-design-docs）或修复核查中发现的代码问题。
核心原则：代码在 HEAD 处是唯一可靠证人，名称、注释、旧文档、图表与人的记忆都只是证词，必须先核实再写入。交付物是下一任工程师信任、下次重构无需修改的文档树：只有行为变化或新功能才需要回改。
过程：先调查再写作。先枚举系统表面：入口点与进程、命令与端点、配置、数据、集成、构建与部署；每个计数都需附命令、在 HEAD 运行并标注日期，写入覆盖率台账。文档树由清单推出，而非阅读顺序。契约面（HTTP 端点、消息负载、命令、文件格式、配置键）要穷尽；内部机制只写机制与后果，不重复代码细节；经受“重构测试”，改名会失效的句子属于实现细节，应提升为行为或删除。证据层级：HEAD 代码 > 覆盖路径的测试 > 运行时证据（需标注日期）> 提交历史 > 名称注释旧文档与人记忆（仅作证词）。判断代码死活用接线证据（引用搜索、注册、运行时追踪），区分存活、已死、休眠，配置键需验证绑定，未读取的键标为死旋钮。
文档类型纪律：描述性文档用现在时精确匹配代码行为，开头锚定所描述的模块一次；规范性文档被违反时不淡化，违反写入 findings.md；历史需挖掘并标注，推断须标明依据；过时文档加横幅而非静默删除。怪癖是内容，需平实陈述；缺陷只记录不追猎，一行含 file:line 写入 findings.md，不做严重性分级或修复。
只读规则：整个行动对系统只读，产出仅为文档、findings.md 与台账。覆盖率台账记录各表面计数与分母、每份文档状态（草稿或已复核，草稿需在文档内标注），复核需第二读者。多写作者并行时每份文档仅一名写作者。
推荐文档树结构：docs/ 下含 README.md、overview.md、各子系统文档、config-reference.md、api-reference.md、integrations.md、data-model.md、processes.md、diagrams/、history.md、findings.md、coverage.md、unknowns.md；unknowns.md 即使为空也必填，每条说明已核查内容。数据不足处暂未提供更多细节。