BitFun 自身治理说明

范围：记录 BitFun 仓库自身在验证可配置开发体验、工程治理、安全和质量能力时暴露出的文档、边界、规则和内部验证问题。 边界：本文只用于内部验证和自我改进；目标项目默认流程、技术栈和质量要求以产品需求、设计文档及项目配置为准。

1. 为什么需要独立文档

BitFun 仓库可以作为可配置工程能力的内部验证项目。产品需求和设计文档中的“目标项目”代表任意被用户加载的软件工程；BitFun 仓库的技术栈、模块边界、AGENTS 文档、CI 规则和 fork PR 工作流仅作为高复杂度样本。

因此，BitFun 自身治理问题应单独记录：

1. BitFun 仓库自身为了更好验证这些能力需要补齐的问题。
2. 这些问题如何作为样本输入项目画像、风险分类器、变更就绪度、安全边界和评测。
3. 哪些规则属于 BitFun 仓库特定样本，哪些能力可以抽象为产品默认。

2. 当前内部验证问题

问题	表现	影响	处理边界
产品对象与内部验证对象混用	文档中同时描述 BitFun 自身代码治理和 BitFun 作为产品支持外部项目	读者难以判断设计是在改某个 PR 功能，还是在定义产品级体验架构	产品需求和设计文档聚焦目标项目；本文承载自身治理问题
Harness 术语过重	容易被误解为 BitFun 产品定位或默认用户流程	普通项目会被强治理叙事劝退	Harness 只作为内部支撑能力术语
默认流程偏重	早期文档把 PR 门禁/证据包作为首个闭环	质量保障要求较低的快速试验、演示和个人项目体验过重	P0 改为快速路径 + 安全边界
项目维度过强	容易默认一个项目只有一种质量等级	实际上路径、任务、权限、团队配置都可能改变治理强度	使用配置化策略画像
安全与质量混淆	安全风险、质量建议、PR 策略容易放进同一个门禁	快速任务可能绕过安全，或安全提示被质量流程噪音淹没	安全边界独立常开
BitFun 特定验证路径容易外溢	示例命令、fork PR 流程、模块边界可能被当作通用默认	目标项目适配性降低	作为内部模式样本，不写入产品默认

3. 内部验证项目应如何使用 BitFun 仓库

• 项目画像示例可以读取 BitFun 的 AGENTS.md、CONTRIBUTING、package/cargo scripts、CI 和模块边界。
• 变更就绪度示例可以使用 BitFun 的 fork PR 流程，但必须标注为项目特定。
• 风险分类器示例可以覆盖 Rust 工作区、React frontend、Tauri desktop、remote、AI 适配器、严格审查等高风险区域。
• 安全边界示例应覆盖 shell、网络、凭据、MCP、hook、跨目录写、删除、发布 credential 等安全面。
• 证据包示例应表达为“任务和变更证据”，不默认要求所有项目生成完整证据包。
• 评测示例需要同时覆盖快速路径、误升级、安全提示、PR 就绪度和高风险审查。

4. BitFun 特定规则的适用边界

• pnpm、cargo、Tauri、Rust 工作区和 React 前端只代表 BitFun 技术栈样本。
• fork PR 到 GCWing/BitFun 只代表 BitFun 当前协作模式样本。
• BitFun 的严格审查习惯用于验证 guarded/regulated 场景，不作为所有项目默认质量要求。
• BitFun 的 AGENTS.md 完整度用于验证规则读取能力，不作为目标项目最低要求。
• BitFun 的 CI 行为、耗时和不稳定风险用于验证复杂项目指标，不作为通用阈值。

5. 成功标准

• BitFun 仓库能作为高复杂度、强协作、强安全样本验证设计。
• 普通目标项目仍能保持低摩擦快速路径。
• 文档读者能清楚区分产品默认、团队可选强治理和 BitFun 仓库自身规则。
• 所有从 BitFun 仓库抽象出的能力，都有“哪些场景不适用”的反证说明。