CraftKit/PROJECT-INITIALIZATION-AND-APPLICATION-SPLIT.md

项目初始化到应用拆分工作流

1. 文档用途

本工作流用于把项目从“缺少稳定上下文”推进到“形成可执行、可验证的应用拆分基线”。这里的应用是具有明确职责、所有权、接口、数据边界和运行形态的交付单元；应用内部仍可继续划分模块。应用不必等同于微服务，也不要求每个业务能力都独立部署。

本工作流只完成项目资料初始化、需求基线、现状或目标架构分析、应用拆分设计和实施规划。除非用户另行明确授权，不创建业务代码，不迁移数据，不调整部署环境，也不执行 Git 提交或发布。

2. 两种执行口径

• 仓库为空、只有少量说明文件，或尚未形成有效源码与构建结构时，使用新项目初始化与应用拆分工作流。
• 已存在有效源码、构建文件、模块、接口、数据库对象或部署配置时，使用已有项目初始化与应用拆分工作流。
• 情况混合时，以待拆分主体为准：新建独立产品按新项目口径；从现有系统剥离能力按已有项目口径。
• 执行 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、索引和忽略规则检查。
• 需求、当前事实、参考做法和设计建议保持可追溯分离。
• 每个应用都有职责、不负责事项、接口、数据、依赖和运行边界。
• 跨应用事务、数据同步、失败恢复、兼容和回滚已有明确处理方式或阻塞项。
• 拆分方案包含至少一个替代方案，并说明为什么不选择过度拆分或维持现状。
• 实施计划具有依赖顺序、验证方式、停止条件和可恢复路径。
• 未经授权的编码、数据库、部署、提交和发布操作均未执行。