docs(workflow): 增加项目初始化到应用拆分流程

PROJECT-INITIALIZATION-AND-APPLICATION-SPLIT.md

@@ -0,0 +1,94 @@
+# 项目初始化到应用拆分工作流
+
+## 1. 文档用途
+
+本工作流用于把项目从“缺少稳定上下文”推进到“形成可执行、可验证的应用拆分基线”。这里的应用是具有明确职责、所有权、接口、数据边界和运行形态的交付单元；应用内部仍可继续划分模块。应用不必等同于微服务，也不要求每个业务能力都独立部署。
+
+本工作流只完成项目资料初始化、需求基线、现状或目标架构分析、应用拆分设计和实施规划。除非用户另行明确授权，不创建业务代码，不迁移数据，不调整部署环境，也不执行 Git 提交或发布。
+
+## 2. 两种执行口径
+
+- 仓库为空、只有少量说明文件，或尚未形成有效源码与构建结构时，使用[新项目初始化与应用拆分工作流](NEW-PROJECT-INITIALIZATION-AND-APPLICATION-SPLIT.md)。
+- 已存在有效源码、构建文件、模块、接口、数据库对象或部署配置时，使用[已有项目初始化与应用拆分工作流](EXISTING-PROJECT-INITIALIZATION-AND-APPLICATION-SPLIT.md)。
+- 情况混合时，以待拆分主体为准：新建独立产品按新项目口径；从现有系统剥离能力按已有项目口径。
+- 执行 `init` 探测后必须展示模式判断及证据，用户可以覆盖建议模式。
+
+## 3. 共同原则
+
+### 3.1 证据分层
+
+所有结论区分为：用户已确认目标、当前项目事实、参考项目做法、项目明确规则、设计建议、待确认项和待验证项。不能把相似系统、单个代码样本或行业惯例直接写成当前项目事实。
+
+### 3.2 拆分判据
+
+候选应用至少从以下方面评估：
+
+- 业务能力与变化节奏；
+- 团队或责任主体；
+- 数据所有权和一致性要求；
+- 对外接口与上下游依赖；
+- 安全、权限、审计和合规边界；
+- 性能、容量、可用性和故障隔离要求；
+- 构建、部署、扩缩容和发布节奏；
+- 迁移、测试、运维和认知成本。
+
+只有拆分收益大于新增的分布式事务、接口治理、数据同步、部署和运维成本时，才建议形成独立应用。证据不足时可以输出模块化单体、逻辑分区或暂不拆分方案。
+
+### 3.3 Skill 使用边界
+
+- `init`：只初始化或合并 `AGENTS.md` 与 `.craftkit/` 项目资料，不生成业务工程。
+- `guidance`：检索项目规则；未安装时按 `AGENTS.md`、`.craftkit/agents/index.md`、`.craftkit/standards/index.md` 和命中正文的顺序手工读取。
+- `requirements`：建立业务需求与验收基线。
+- `design-backend`、`design-frontend`：形成应用内部的后端和前端边界。
+- `design-api`、`prepare-api`：细化跨应用和前后端契约。
+- `design-db`：细化数据所有权、结构、迁移和回滚。
+- `design-workflow`：处理跨状态、跨角色或跨事务的业务流程。
+- `plan-change`：把批准的拆分设计转成按依赖排序的实施计划。
+
+## 4. 共同阶段与审批门
+
+| 阶段 | 目标 | 主要产物 | 完成后动作 |
+| --- | --- | --- | --- |
+| P0 模式判断 | 确认新项目或已有项目口径 | 模式判断、扫描范围、风险 | 进入 G0 |
+| P1 项目初始化 | 建立可持续读取的项目上下文 | `AGENTS.md`、`.craftkit/project.json`、必要索引 | 进入 P2 |
+| P2 需求基线 | 明确目标、范围、角色、流程和验收 | 需求基线、疑问清单 | 进入 G1 |
+| P3 边界分析 | 识别业务能力、数据、接口、团队和运行约束 | 能力地图、依赖图、拆分判据 | 进入 P4 |
+| P4 应用拆分 | 形成候选方案并完成权衡 | 应用清单、职责、契约、数据和部署边界 | 进入 G2 |
+| P5 细化设计 | 细化接口、数据、流程、前后端和非功能要求 | 专项设计与验证矩阵 | 进入 P6 |
+| P6 实施规划 | 确定建设或迁移批次、兼容和回滚 | 分阶段计划、停止条件、回滚方案 | 进入 G3 |
+| P7 交付基线 | 汇总批准结论和后续执行入口 | 架构基线、决策记录、任务清单 | 流程完成 |
+
+审批门：
+
+- G0：确认模式、项目根、参考资料和允许扫描范围。
+- G1：确认需求基线以及仍需保留的业务待决项。
+- G2：确认应用边界、保留的替代方案和不拆分项。
+- G3：确认实施批次、外部依赖、数据迁移、兼容策略和回滚边界。
+
+## 5. 应用拆分基线格式
+
+每个候选应用至少记录：
+
+| 字段 | 内容 |
+| --- | --- |
+| 应用名称 | 中性候选名；未确认时标记为暂定 |
+| 核心职责 | 应用负责的业务能力和业务不变量 |
+| 不负责事项 | 明确排除的能力，防止边界回流 |
+| 使用者 | 用户角色、调用方和运维主体 |
+| 对外契约 | API、事件、文件、任务或人工交互 |
+| 数据所有权 | 主数据、写入责任、读取方式和一致性要求 |
+| 上下游依赖 | 同步、异步、批处理及不可用时的行为 |
+| 运行边界 | 构建、部署、配置、扩缩容和可用性要求 |
+| 安全边界 | 认证、授权、审计、敏感数据和网络限制 |
+| 验证方式 | 契约、集成、迁移、回归和运行验证 |
+| 拆分理由 | 收益、成本、风险及未采用替代方案 |
+
+## 6. 完成标准
+
+- 项目模式和项目根已确认，初始化产物通过 JSON、索引和忽略规则检查。
+- 需求、当前事实、参考做法和设计建议保持可追溯分离。
+- 每个应用都有职责、不负责事项、接口、数据、依赖和运行边界。
+- 跨应用事务、数据同步、失败恢复、兼容和回滚已有明确处理方式或阻塞项。
+- 拆分方案包含至少一个替代方案，并说明为什么不选择过度拆分或维持现状。
+- 实施计划具有依赖顺序、验证方式、停止条件和可恢复路径。
+- 未经授权的编码、数据库、部署、提交和发布操作均未执行。