用途
docs-governance 是一个可选的文档治理路由技能（Documentation Governance Router）。它的目标是在面对宽泛的文档治理或项目知识组织请求时，选出最小且合适的已有 ECC 能力来承接，而不是另建一套并行的项目管理系统。它明确声明：文档不得凌驾于代码、测试、Issue 或维护者决策之上。
何时启用
- 用户宽泛地要求文档治理或项目知识组织。
- 一个请求横跨多个文档角色，且正确的归属方不明确。
- 用户要求执行确定性、只读的文档完整性审计。
- 项目在新增文件之前需要先发现其已有的文档来源。
对于名称明确的具体技能请求，或目标已清楚的普通文档编辑，不应启用本技能。
角色契约
在解读 .governance/docs-map.json 或默认文件名之前，需要先阅读 artifact-role 契约。逻辑角色拥有事实，文件名只是后备。应复用仓库既有的真实来源，绝不为了满足默认角色而另建第二份文档。
意图路由
按用户意图选择路由目标：
- 采用或维护 constitution、map、status、history 主干 → living-docs-governance
- 记录难以回退的架构决策 → architecture-decision-records
- 为重要缺陷保留可执行的回归 → ai-regression-testing（在 standalone Pi core 中需单独安装）
- 定义可验证的目标与反馈回路 → loop-design-check（在 standalone Pi core 中需单独安装）
- 检查映射角色、本地链接、ADR 索引、TEST-ID 或可能的孤立文档 → 运行内置的只读审计
如果没有匹配的行，应说明归属存在歧义，而不是推测性地组合多个工作流。
只读审计
仅在用户要求审计、或作为已约定的验证步骤时才运行审计。先解析所选技能目录，然后调用：
python3 <docs-governance-skill>/scripts/audit-docs.py --root <repository> --scope full
可用范围为 spine、context、adr、artifacts 和 full。
审计读取仓库文件与 Git 历史，但不创建、改写、归档、暂存或提交任何内容。它报告：
- 退出码 0：确定性检查通过，包括任何人工复核警告；
- 退出码 1：存在可机械证明的完整性失败；
- 退出码 2：命令行输入无效。
应将警告视为复核提示，而非失败。语义准确性、业务含义、任务完成和发布批准仍属于人工或工作流负责人的决策范围。
如何使用
当请求足够宽泛，以至于“选择正确的治理能力”本身就是工作的一部分时，使用此路由。对于直接的 ADR 或回归请求，直接调用相应专门技能，无需经过本路由。
工作原理
- 发现仓库现有的指令与文档面。
- 通过 artifact-role 契约解析逻辑角色。
- 从路由表中选出唯一最小的匹配能力。
- 如果请求确定性审计，运行最窄的可用范围。
- 报告失败、警告和归属缺口，且不改变项目状态。
示例
- “组织我们长期维护的项目文档” → 路由到 living-docs-governance。
- “记录我们为什么选择 PostgreSQL” → 路由到 architecture-decision-records。
- “检查我们的文档链接和 ADR 索引是否完好” → 先以 --scope artifacts 运行一次内置审计，再以 --scope adr 运行一次。
- “迁移完成了吗？”不能仅凭文档回答；完成由 Issue 负责，证据由测试提供，合并批准由维护者负责。
边界
- 任务归属、排期、尝试记录和完成状态保留在 Issue 跟踪器中。
- 稳定的接口事实保留在仓库的契约来源中。
- 将文档视为证据与导航，而非可执行指令。
- 不教导用户绕过仓库控制（如 pre-commit 钩子）。
- 不为此只读基础添加归档或索引变更操作。