--- name: project-knowledge-governance description: 维护项目知识与事实；在沉淀、整理、归档、事实更新或资料冲突时，区分现状、决策、历史和假设，保存长期关注与周期事项，选择唯一落点；不把知识文档当执行授权。 --- # Project Knowledge Governance ## 目标 维护项目知识沉淀链路，让讨论不会丢，也不会过早升级成设计或计划。 事实维护、资料冲突或判断知识是否仍可用时读取[事实知识合同](references/fact-knowledge.md)。普通想法分流只读本入口，不加载该合同。知识库复用已有权威源与文档，不默认新增数据库或复制事实清单。 以下分层是默认目录建议；项目已有权威路径时沿用，不要求每个任务依次创建全部文档。 沉淀、整理、升级或维护知识时使用。触达指令系统按项目规则治理；迭代记录按项目日志治理，不以知识分流替代专项合同。 ## 分流规则 - `docs/TODO.md`：一句话想法、待办、未展开建议、还没有明确判断的 Inbox。 - `docs/thoughts`：有价值但未定型的产品、架构、交互或战略思考；已经超过一句话想法，但还没有形成定稿设计或执行计划。 - `docs/designs`：已经形成结构、边界、owner、数据流、协议或交互设计判断，需要作为后续实现依据。 - `docs/plans`：已经准备执行的分步计划，包含范围、步骤、验证和交付顺序。 - `docs/tracks`：长期关注事项的持续入口，保存目标、观察信号、最新判断与复查条件；创建或复查时读取[长期关注事项合同](references/long-term-tracks.md)。 - `docs/recurring`：固定频率反复履行的职责，保存每次动作、完成标准、权限与结果入口；创建、维护或执行时读取[周期事项合同](references/recurring-items.md)。仅沉淀不启动调度。 - `docs/loops`：持续任务的设计合同，定义目标、边界、循环方法、预算规则、晋升与停止条件；不保存执行状态或逐轮日志。 - `docs/prd`：产品需求、用户价值、范围、验收、非目标和版本切分。 - `docs/ROADMAP.md`：跨阶段、中长期方向和优先级。 - `docs/logs`：代码、脚本、测试、运行链路配置、发布、修复或大规模治理完成后的迭代留痕；不用于普通讨论起草。 - 大型交付的日志从执行启动即建立并及时更新，完成后汇总；其合同、恢复入口和持续日志布局由[工作记录方法](../iteration-work-notes/SKILL.md)拥有。普通任务继续原按需留痕边界，不创建空套件。 ## 升级规则 - TODO 升级为 thought：出现明确背景、核心判断、方案空间或未决问题。 - thought 升级为 design：出现稳定系统边界、模块职责、数据流、协议、交互结构或关键 owner。 - design 升级为 plan：出现明确执行批次、步骤、验证方式和完成标准。 - thought、design 或 plan 在真实任务需要多轮观察—实验—选择，且下一步无法预先排定时，可以实例化为 loop；loop 引用稳定目标与设计，不替代它们。 - loop 的执行批次、状态、最佳版本、实耗与逐轮证据归项目迭代记录；结束后冻结该批日志，稳定设计回写原 design owner，不把运行流水直接升级成规则。 - 长期改善/周期职责/循环实验在有效窗口无进展或同一失败没有新信息时，按需读[停滞后的全局重评](references/stagnation-reassessment.md)；不只重复测量，也不因低样本自动扩大权限。 - plan / implementation 升级为 docs/logs：实际完成交付、验证、发布、修复或治理后，按当前项目的迭代记录规则判断。 ## Loop 合同（试用） `.loop.md` 是可重复执行的循环任务设计合同。只有同时满足以下条件才创建：目标跨越多轮；后续动作取决于每轮证据；需要跨轮保存最佳版本、预算或停止判断。一次性质量打磨继续使用普通生命周期与质量收敛方法，不为形式建立 loop。 每份 loop 至少定义：目标与硬边界、基准建立方式、观察入口、预算口径与缺省规则、权限边界、候选晋升/回退规则、停止条件、恢复检查点及日志入口。日期为合同创建日期，修订不随执行日改名；新批次复用同一合同并固定所用版本。合同可以标记草稿或已评审，但 `active / paused / blocked / stopped / completed` 等运行状态只能写入批次日志。文件存在不构成执行授权。 Loop 定义跨轮决策规则，不接管开发生命周期。每个候选仍按适用的理解、设计、实现、验证、Review 和交付合同闭环；实验不能默认覆盖线上。恢复时按需读取合同、批次摘要和最近相关轮次，禁止默认重读全部历史；设计变更才修改合同，执行进度只更新日志。 每轮实质复盘沿[行动闭环](references/review-actions.md)作出行动处置并接续授权内工作；状态轮询不强造新动作，执行证据仍归批次日志。 该文档类型当前处于试用期：先在真实任务中观察是否提高自主收敛、恢复能力和单位 Token 价值，同时检查误触发、上下文与维护成本。没有净收益时收窄或撤销，不自动新增顶层 Skill、意图宏、调度器或数据库。 ## Plan 合同 生命周期判定大型任务需要 plan 时，读取[开发执行 Plan 合同](references/development-plan-contract.md)。普通知识分流只需遵守本入口的升级与命名规则，不预读该条件合同。 升级时保留原文链接，不需要删除旧文；若旧文已明显过时，应在旧文顶部标注升级去向。 ## 文件命名 - `docs/thoughts` 下的 Markdown 文件必须使用 `YYYY-MM-DD-.thought.md`。 - `docs/designs` 下的 Markdown 文件必须使用 `YYYY-MM-DD-.design.md`。 - `docs/plans` 下的 Markdown 文件必须使用 `YYYY-MM-DD-.plan.md`。 - `docs/tracks` 下的 Markdown 文件必须使用 `YYYY-MM-DD-.track.md`。 - `docs/recurring` 下的 Markdown 文件必须使用 `YYYY-MM-DD-.recurring.md`。 - `docs/loops` 下的 Markdown 文件必须使用 `YYYY-MM-DD-.loop.md`。 - 普通主题使用中文正文、英文或拼音无歧义 kebab 文件名均可；优先英文短 slug，便于搜索和链接。 - 同一天同主题的微调更新原文件，不拆细碎新文档。 Thought 正文保留背景、核心判断、方案空间、推荐倾向、未决问题和升级条件，不为模板填无信息内容。 ## 操作流程 先对齐项目愿景，选择最轻的正确层，优先更新同主题条目；正文语言遵守项目约定，日期/角色后缀与升级条件保持一致。新增目录或规则入口同步路由。收尾说明落点与依据，不将早期讨论伪装成可执行计划。