这里集中存放不属于某个运行模块、但会影响团队协作、版本解释和交付判断的资料。治理文档约束“怎样证明完成”,不会替代模块运行手册、源码事实或发布制品。
按任务选择页面
- 01/05
代码提交规范
BitzOrcas.Modern 团队代码提交规范 — 分支命名、Commit Message 格式、Code Review 标准与完整 PR 工作流。
- 02/05
更新日志
记录影响开发者、适配器作者和商业交付方的主要能力与文档变化。
- 03/05
最近更新
按页面 lastUpdated 自动列出最近 30 天改过的说明书,不另写人工流水账。
- 04/05
交付状态与路线图
区分当前已交付能力、仍需生产证据的边界和后续投资方向,避免把规划写成现状。
- 05/05
文档维护与事实校准
用源码、测试和交付证据维护中英双语开发说明书,避免路径、模块、能力和发布语义再次漂移。
| 页面 | 用途 |
|---|---|
| 代码提交规范 | 分支、Commit、PR、Review 与敏感信息处理 |
| 最近更新 | 按 lastUpdated 自动列出最近 30 天改过的页面 |
| 更新日志 | 记录有可验证依据的主要交付变化 |
| 路线图 | 区分已交付、待补证据和后续投资方向 |
| 文档维护 | 事实来源、双语同步、链接和自然度检查 |
路线图不是承诺日期,更新日志也不替代 Git 历史和正式发布制品。对客户作出兼容性或交付承诺时,以版本化包、签名制品和 GA 证据为准。
五类事实不能混用
| 信息 | 回答的问题 | 主要证据 |
|---|---|---|
| 提交规范 | 变更怎样进入主分支 | 仓库规则、分支保护、CI |
| 最近更新 | 最近改过哪些说明书页面 | 各页 lastUpdated、构建产物 |
| 更新日志 | 某个已发布版本改变了什么 | Tag、包清单、SBOM、provenance |
| 路线图 | 下一步为什么值得投资 | 风险、用户价值、缺口清单 |
| 文档维护 | 如何防止说明书漂移 | 源码扫描、双语校验、静态构建 |
变更前先做事实核查
# 确认目标仓库规则与当前工作树,避免把计划当成事实。sed -n '1,220p' AGENTS.mdgit status --shortgit log -5 --oneline如果页面涉及具体类型、配置键或运行顺序,还要在产品源码中定位声明与装配点;只搜到接口名不足以证明生产适配器已注册。
变更后留下可复验证据
# 说明书仓库的最小治理闭环。npm run verify:docsnpm run verify:docs-sourcenpm run verify:docs-depthnpm run buildgit diff --check命令输出应进入 PR 说明或发布证据,而不是只写“已测试”。失败项不能通过降低页面状态、删除链接或把当前能力改写成规划来规避。
决策升级路径
发现源码与文档不一致时,先判断是文档夸大、实现缺陷还是仍在规划。文档夸大立即收缩;实现缺陷进入知识库/架构清单并明确 owner;兼容性、数据模型或跨模块边界变化通过 ADR 或正式架构记录决策。
完成定义
治理页完成至少意味着双语同步、事实来源明确、示例可复制、内部链接有效,并能解释尚未交付的边界。对外发布还必须通过 Consumer Contract 与 Commercial GA 门禁;治理文档本身不是放行证书。