[RFC] 细化知识与公共组件贡献流程

状态：提议中，待讨论。

背景

现有贡献指南侧重写卡、修改 Skill 和运行检查，对贡献动机、效果验证和 committer 检视依据规定不够具体。建议明确知识贡献与公共组件贡献两条流程，并为缺陷修复保留直接提交 PR 的简化路径。

方案

知识贡献

提交知识 Issue → 生产知识并验证效果 → 提交关联 PR → committer 检视后合入。

Issue 说明三件事：

• 缺什么：使用场景、已尝试的检索、现有知识不足及适用范围。
• 怎么产生：来源、生产方法、准备新增或更新的卡片，以及复核方式。
• 有什么效果：能回答什么问题或支持什么操作，至少给出一个包含输入条件和预期结果的验收场景。

PR 关联 Issue，回填实际产物、来源、场景验证结果和未覆盖范围。检查既要确认知识可被找到，也要核对正文能否支撑原问题的答案；技术结论仍需来源或实验支撑。

公共组件贡献

提交 RFC → 实现并完成 A/B test → 提交关联 PR → committer 检视后合入。

组件贡献遵循扩展优先、保持兼容：新增能力优先通过现有扩展点或可选配置接入，保留原有默认流程和对外契约，避免为新能力复制整套流程。

内部重构可以修改原实现；确需主动调整默认流程、接口或既有行为时，RFC 须说明扩展方式为何不足、受影响场景、迁移与回退方案，并由 committer 明确检视。新增能力与原有路径都应有对应验证。纠正错误、恢复既定行为的缺陷修复走下述简化路径。

适用于检索 Skill、索引、摄入、校验、安装等公共能力的新增、优化或主动行为调整，缺陷修复除外。RFC 以标题含 [RFC] 的 Issue 承载，说明：

• 当前问题、修改必要性和影响范围。
• 方案、替代方案、兼容性风险及回退方法。
• A/B 的基线、任务集、控制变量、验收指标和实验计划。

RFC 阶段可先提交实验计划，走此流程的组件 PR 提交前须补齐实际对照结果、退化分析和复现材料。指标按组件职责选择，例如规则变更比较同一组合法、非法输入的处理结果；需走 RFC 流程的检索变更遵循检索 A/B 实验 RFC。

缺陷修复与轻量修订

直接提交修复 PR → committer 检视后合入。

知识错误修正、检索脚本 bug 等缺陷修复，无需先提交 Issue/RFC，也不要求完整 A/B 实验。PR 说明问题、修复内容和影响，提供相应证据与定向验证结果：知识修正附支持结论的来源，脚本修复附复现方式和回归结果。

纯排版、错别字和不改变组件行为的说明文档修订也可直接提交 PR。已有 Issue 可按需关联，不作为前置要求；修复中若包含新增能力或主动流程调整，应拆分后按对应流程贡献。

检视与合入

贡献者负责实现、验证和处理评审意见；committer 核对问题是否解决、证据是否充分、收益与风险是否可接受，并明确记录评审结论。

合入前须满足：对应贡献类型的材料完整、适用验收标准达成、阻断性意见解决、待合入版本的 bash check.sh 通过，并获得 committer 明确认可。由 committer 合入；有关联 Issue/RFC 时回填处理结果，部分完成的需求保留剩余范围。

落地与验收

以 CONTRIBUTING.md 集中维护流程和材料模板，同步 README、贡献 Recipe、Skill 规范和 Agent 约定。首版沿用现有 Issue/PR 表单。