覆盖矩阵与渐进采用
综合标准表示每个相关领域都有具体决策和验证方式，不表示每个项目都要有 Docker、数据库、微服务或独立文档。
生命周期覆盖
| 领域 | 最低要解决的问题 | 适用条件 |
|---|---|---|
| AI 参与开发 | AI 的任务上下文、范围、权限、验证证据和人类责任人是什么？ | 使用 AI 编码代理或自动化开发工具时；本标准以此工作流为设计中心 |
| 范围与所有权 | 谁拥有项目、维护和支持？ | 所有项目 |
| 产品与需求 | 解决谁的问题，怎样验收？ | 所有非琐碎工作 |
| 仓库与看板 | 项目、仓库、组件、Project 如何关联？ | 多仓库/多人规划 |
| 命名与布局 | 标识、目录、公开名称怎样保持稳定？ | 所有项目 |
| 文档与决策 | 哪份文档对谁权威，何时更新？ | 所有项目，详略随风险变化 |
| 本地开发/Docker | 开发路径、命令、隔离、数据生命周期是什么？ | Docker 有益时才用 Docker |
| 配置与依赖 | 配置优先级、秘密、锁文件和运行时由谁负责？ | 所有项目 |
| 架构和代码 | 模块、边界、失败行为和依赖方向是什么？ | 需要维护的代码 |
| API/事件/SDK | 谁发布契约，如何授权、兼容、重试和去重？ | 存在外部或异步消费者时 |
| 持久数据和迁移 | 数据由谁拥有，如何迁移、留存和恢复？ | 有持久数据时 |
| 测试与验证 | 哪种证据能证明本次结果？ | 所有行为变更 |
| 安全与隐私 | 真实信任边界、权限、秘密和数据分类是什么？ | 用户输入、敏感数据或权限时 |
| UI 与可访问性 | 复用什么组件/Token，怎样验证主要交互？ | 有用户界面时 |
| 可靠性与性能 | 哪些可观测目标与产品需要相关？ | 持续运行或有已知负载要求时 |
| Git/协作 | Issue、PR、分支、跨仓库状态由谁负责？ | 使用协作平台时 |
| 构建与发布 | 源码如何变成可追溯工件并被验收？ | 有构建或分发时 |
| 运维与支持 | 负责人如何发现、响应和恢复故障？ | 实际运行服务时 |
| 研究、数据和 AI | 来源、许可、配置、隔离和指标是什么？ | 研究或模型产物时 |
| 维护与退役 | 支持多久，如何弃用、迁移和处置数据？ | 持续维护或停用项目时 |
新项目采用步骤
- 定义稳定 project_id、负责人、用户成果和当前生命周期。
- 建立 AI 工作约定：权威上下文、可执行任务契约、允许操作、验证命令和人类评审/发布责任。
- 决定协调仓库、实现仓库、文档权威位置和交付 Project 的目的。
- 按项目职责和复杂度选择 small、service、platform、SDK 或 research 布局；这些是工程形态，不代表团队规模。
- 写明人类和代理都能复现的开发命令、工具链、配置、秘密与依赖；选择原生、部分 Docker 或完整容器模式。
- 为适用风险选取测试、安全、权限、数据和 UI 检查，记录运行命令与真实证据。
- 发布物关联源码和版本；有线上责任的项目补齐运维、恢复和退役安排。
现有项目采用
先登记当前事实、已有约定、兼容风险和采用差距。挑选一小批不同类型的项目，优先补足文档入口、运行验证和项目/仓库关系。之后逐仓库推进，保护未提交变更、未发布分支、本地数据、worktree 与子模块。
每个采用差距记录：规则、风险、最小下一步、负责人或待定、权威文件、验证方法和复核触发条件。只有确实不适用时才标“不适用”，不能用它掩盖未完成的工作。
偏差和例外
例外写出适用的仓库/功能、原因、兼容影响、负责人或决定来源及复核条件。合理的既有约定不需要额外审批官僚流程。批量搬移、改名、建看板、换框架、修改保护策略和上线动作都要与当前工作授权对应；标准文档不会自行授权这些更改。