peiiii Project Knowledge Governance
目标
维护项目知识沉淀链路，让讨论不会丢，也不会过早升级成设计或计划。
事实维护、资料冲突或判断知识是否仍可用时读取事实知识合同。普通想法分流只读本入口，不加载该合同。知识库复用已有权威源与文档，不默认新增数据库或复制事实清单。
以下分层复用项目既有目录，不要求每个任务依次创建全部文档。
沉淀、整理、升级或维护知识时使用。触达指令系统按项目规则治理；迭代记录按项目日志治理，不以知识分流替代专项合同。
分流规则
docs/TODO.md：一句话想法、待办、未展开建议、还没有明确判断的 Inbox。docs/thoughts：有价值但未定型的产品、架构、交互或战略思考；已经超过一句话想法，但还没有形成定稿设计或执行计划。docs/designs：已经形成结构、边界、owner、数据流、协议或交互设计判断，需要作为后续实现依据。docs/plans：已经准备执行的分步计划，包含范围、步骤、验证和交付顺序。docs/prd：产品需求、用户价值、范围、验收、非目标和版本切分。docs/ROADMAP.md：跨阶段、中长期方向和优先级。docs/logs：代码、脚本、测试、运行链路配置、发布、修复或大规模治理完成后的迭代留痕；不用于普通讨论起草。
升级规则
- TODO 升级为 thought：出现明确背景、核心判断、方案空间或未决问题。
- thought 升级为 design：出现稳定系统边界、模块职责、数据流、协议、交互结构或关键 owner。
- design 升级为 plan：出现明确执行批次、步骤、验证方式和完成标准。
- plan / implementation 升级为 docs/logs：实际完成交付、验证、发布、修复或治理后，按当前项目的迭代记录规则判断。
Plan 合同
生命周期判定大型任务需要 plan 时，读取开发执行 Plan 合同。普通知识分流只需遵守本入口的升级与命名规则，不预读该条件合同。
升级时保留原文链接，不需要删除旧文；若旧文已明显过时，应在旧文顶部标注升级去向。
文件命名
docs/thoughts下的 Markdown 文件必须使用YYYY-MM-DD-<kebab-topic>.thought.md。docs/designs下的 Markdown 文件必须使用YYYY-MM-DD-<kebab-topic>.design.md。docs/plans下的 Markdown 文件必须使用YYYY-MM-DD-<kebab-topic>.plan.md。- 普通主题使用中文正文、英文或拼音无歧义 kebab 文件名均可；优先英文短 slug，便于搜索和链接。
- 同一天同主题的微调更新原文件，不拆细碎新文档。
Thought 正文保留背景、核心判断、方案空间、推荐倾向、未决问题和升级条件，不为模板填无信息内容。
操作流程
先对齐项目愿景，选择最轻的正确层，优先更新同主题条目；保持中文正文、日期/角色后缀与升级条件。新增目录或规则入口同步路由。收尾说明落点与依据，不将早期讨论伪装成可执行计划。