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

EXISTING-PROJECT-INITIALIZATION-AND-APPLICATION-SPLIT.md

@@ -0,0 +1,141 @@
+# 已有项目初始化与应用拆分工作流
+
+## 1. 适用范围
+
+适用于已经存在源码、构建文件、模块、接口、数据库对象、任务或部署配置的项目。目标是在保护现有工作区的前提下建立可信项目上下文，识别真实运行与依赖边界，再形成可渐进实施、可回滚的应用拆分方案。
+
+已有目录或模块名称不能直接视为正确应用边界；代码引用也不等于业务所有权。静态源码只能证明当前实现，运行拓扑、流量、数据规模和生产行为仍需配置、日志、部署资料或用户确认支持。
+
+## 2. 输入与保护措施
+
+开始时记录：
+
+- 当前分支、HEAD、staged、unstaged 和 untracked 状态；
+- 适用的 `AGENTS.md`、`.craftkit/`、项目说明和贡献规范；
+- 构建清单、锁文件、源码根、模块、测试和自动化配置；
+- 数据库、消息、缓存、文件、定时任务和外部系统的非秘密元数据；
+- 制品、部署单元、环境配置入口和运行依赖；
+- 已知问题、迁移限制、兼容窗口和不能变更的范围。
+
+不得读取或记录凭据、完整连接串和生产敏感数据。不能为了扫描而构建、启动、迁移或连接外部环境。
+
+## 3. 执行阶段
+
+### E0：确认成熟项目模式
+
+1. 使用 `init` 只读探测有效源码、构建文件、现有项目资料和代表性入口。
+2. 展示“成熟项目”判断、项目根、工作区状态和拟扫描范围。
+3. 多仓或多根目录时，先确认本次拆分主体及关联仓库只读范围。
+4. 到达 G0，等待用户确认模式、范围和可使用的运行资料。
+
+### E1：保守初始化项目资料
+
+1. 完整读取现有 `AGENTS.md` 与 `.craftkit/`，禁止覆盖未知用户章节。
+2. 从构建和锁文件提取语言、框架、精确版本、模块和依赖证据。
+3. 读取少量代表性的入口、接口、服务、数据访问和测试文件；多种风格并存时不按数量自动裁决。
+4. 展示当前项目事实、冲突、疑似历史结构和待确认项。
+5. 用户确认后由 `init` 保守合并项目资料，并验证 JSON、索引和忽略规则。
+6. 使用 `guidance` 或手工入口顺序验证一项真实项目规则。
+
+### E2：建立现状基线
+
+从源码和可用运行资料分别建立视图：
+
+- 构建视图：模块、依赖方向、公共库和循环依赖；
+- 调用视图：入口、同步调用、异步消息、批处理和人工步骤；
+- 数据视图：表、文件、缓存、主数据、写入方和共享访问；
+- 部署视图：制品、进程、配置、扩缩容、故障域和发布方式；
+- 组织视图：维护团队、变更频率、审批和支持责任；
+- 质量视图：测试边界、发布验证、已知风险和观测能力。
+
+每项结论注明证据来源和置信度。无法验证的生产拓扑与流量必须标为待验证。
+
+### E3：建立目标需求基线
+
+1. 使用 `requirements` 区分当前行为、目标行为、必须保持的兼容和范围外事项。
+2. 明确拆分动因，例如独立发布、团队自治、容量、故障隔离、安全边界或技术替换。
+3. 为拆分目标设置可测指标，例如依赖减少、发布独立性、故障影响范围或迁移窗口，而不是只写“解耦”。
+4. 记录必须继续兼容的调用方、数据格式、作业、报表和运维流程。
+5. 到达 G1，由用户确认目标、约束、验收和允许改变的边界。
+
+### E4：识别候选边界与阻塞耦合
+
+1. 从业务能力和数据所有权出发提出候选边界，再映射当前模块，而不是按目录直接切分。
+2. 为每个候选应用列出入口、核心职责、不负责事项、依赖、数据、任务和部署现状。
+3. 识别阻塞拆分的耦合：共享写库、跨模块事务、循环调用、共享会话、共享缓存键、文件约定、定时任务、硬编码配置和公共类中的业务逻辑。
+4. 区分必须拆除的耦合、迁移期允许的兼容桥和可以长期保留的公共基础能力。
+5. 对证据不足的动态调用、反射、配置路由和外部任务安排专项验证。
+
+### E5：设计目标应用和过渡架构
+
+至少比较以下方案：
+
+- 保持现状，仅加强模块边界；
+- 模块化单体并清理依赖；
+- 抽取少量高收益独立应用；
+- 按多个业务能力逐步形成独立应用。
+
+对推荐方案逐项说明业务收益、数据和事务变化、接口成本、部署与观测成本、团队影响、迁移风险和不采用其他方案的理由。应用拆分清单必须包含职责、不负责事项、契约、数据所有权、运行和安全边界。
+
+过渡架构应明确：
+
+- 旧入口与新入口的流量切换方式；
+- 同步接口、事件、批处理或文件交换的适用范围；
+- 数据迁移、复制、校验、回放和最终切换责任；
+- 迁移期读写权威、兼容适配层和弃用条件；
+- 跨边界事务的幂等、补偿、重试和对账方式；
+- 发生失败时回到旧路径的条件和数据处置方法。
+
+到达 G2，由用户确认目标边界、过渡架构和明确不拆分的部分。
+
+### E6：细化专项设计
+
+根据批准方案按需执行：
+
+- `design-backend`：目标应用内部模块、服务、事务、异常和观测边界；
+- `design-frontend`：前端应用、路由、状态、共享组件和渐进切换边界；
+- `design-api`、`prepare-api`：新旧接口、适配层、版本、字段映射和弃用计划；
+- `design-db`：数据所有权、结构、双读双写风险、迁移、校验和回滚；
+- `design-workflow`：跨应用状态、任务、超时、撤回、补偿和审计。
+
+所有专项设计必须映射回现有调用方和测试，不得只描述目标结构。
+
+### E7：制定渐进迁移计划
+
+使用 `plan-change` 将迁移拆为可独立验证的批次。通常按以下顺序评估，但不得机械套用：
+
+1. 增加观测、契约测试和现状回归基线；
+2. 收紧原系统内部模块边界并消除高风险循环依赖；
+3. 建立目标应用骨架和兼容适配层；
+4. 迁移低风险读取或旁路能力；
+5. 迁移写入、任务和数据权威；
+6. 分批切换调用方和流量；
+7. 完成对账、稳定观察、旧路径下线和资料更新。
+
+每个批次必须记录：前置条件、涉及应用、代码与数据范围、兼容方式、验证、观测窗口、停止条件、回滚步骤和不可逆点。未经额外授权，不执行数据库迁移、环境部署或流量切换。
+
+### E8：形成交付基线
+
+汇总并冻结本轮已批准的：现状事实、目标应用边界、决策记录、专项契约、迁移批次、验证矩阵、风险台账和待确认项。需要后续任务接续时使用 `handoff` 生成交接材料，不把未验证运行行为写成已完成结论。
+
+## 4. 已有项目交付物
+
+- 保守合并并验证的 `AGENTS.md` 与 `.craftkit/` 项目资料；
+- 当前模块、调用、数据、部署、组织和质量视图；
+- 拆分目标、兼容范围和可测验收指标；
+- 候选应用、阻塞耦合和目标应用职责矩阵；
+- 目标架构、过渡架构、数据权威和契约清单；
+- 分批迁移、验证、观测、停止和回滚计划；
+- 未验证运行事实、外部协调项和不可逆操作清单。
+
+## 5. 停止条件
+
+遇到以下情况时暂停：无法区分既有改动与本次产物、关键调用或数据写入方未知、生产运行资料与源码冲突、迁移需要未授权的外部系统访问、存在无法回滚的数据变更、关键调用方未纳入范围，或用户尚未批准对应审批门。
+
+## 6. 可直接复制的总控提示词
+
+```text
+请按《已有项目初始化与应用拆分工作流》推进当前项目。先保护现有工作区，使用 init 只读判断成熟项目模式，展示项目根、分支、已有改动、拟扫描范围和运行资料边界，在 G0 等待我确认。确认后保守合并 AGENTS.md 与 .craftkit 项目资料，建立构建、调用、数据、部署、组织和质量现状视图，再使用 requirements 确认拆分动因、兼容范围和可测目标。
+
+基于真实业务能力、调用链、数据写入方和部署单元提出候选应用，识别共享写库、跨模块事务、循环调用、共享会话、缓存、文件和任务耦合。比较保持现状、模块化单体、抽取少量应用和多应用渐进拆分方案，形成目标架构、过渡架构、数据权威、契约、迁移批次、验证、观测、停止和回滚计划。全过程区分源码事实、运行事实、用户确认、项目规则、设计建议和待验证项；不把目录名称直接视为业务边界。只在 G0、G1、G2、G3、业务决策、权限扩大或高风险副作用处暂停。未经我另行授权，不修改业务代码，不连接外部环境，不迁移数据，不部署，不提交，不推送。
+```

NEW-PROJECT-INITIALIZATION-AND-APPLICATION-SPLIT.md

@@ -0,0 +1,124 @@
+# 新项目初始化与应用拆分工作流
+
+## 1. 适用范围
+
+适用于空目录、新建仓库，或只有需求、原型和少量说明材料、尚未形成有效源码与构建结构的项目。目标是先建立可信项目上下文，再从已确认需求推导应用边界和实施计划。
+
+本流程不默认选择微服务、前后端框架、数据库、消息系统、云平台或最新版本。`init` 只创建 Agent 与项目知识资料；代码工程初始化属于后续实施任务。
+
+## 2. 输入与前置确认
+
+开始时收集并确认：
+
+- 项目根目录和 Git 状态；
+- 项目用途、目标用户、交付形态和预期运行环境；
+- 需求、原型、会议材料和验收要求；
+- 已确定的语言、框架、数据库、构建工具及精确版本；
+- 组织标识、包名或 npm scope 等必须提前确定的标识；
+- 允许参考的项目，以及只允许借鉴的架构、依赖、命名、测试、规范或工具范围；
+- 安全、合规、容量、可用性、交付期限和团队边界。
+
+未知信息保持为空或标记待确认，不能用流行方案自动补齐。
+
+## 3. 执行阶段
+
+### N0：确认空项目模式
+
+1. 使用 `init` 只读检查源码、构建文件、`AGENTS.md` 和 `.craftkit/`。
+2. 展示“空项目”判断、证据、项目根和允许扫描的参考材料。
+3. 到达 G0，等待用户确认模式和参考范围。
+
+### N1：建立项目上下文
+
+1. 确认项目类型、交付形态、技术选型的已决项和未决项。
+2. 如存在参考项目，分别记录当前项目输入事实、参考项目做法和建议采用项。
+3. 预览拟创建的 `AGENTS.md`、`.craftkit/project.json`、`.craftkit/README.md`、必要索引与 `.craftkit/.gitignore`。
+4. 用户确认后由 `init` 创建最小资料骨架，不提前生成空业务目录。
+5. 校验 JSON、索引链接，以及 `/local/`、`/cache/` 的忽略规则；用 `guidance` 或手工入口顺序验证一次真实规则查询。
+
+### N2：建立需求基线
+
+1. 使用 `requirements` 整理角色、场景、触发条件、主流程、异常流程、数据、权限、兼容和范围外事项。
+2. 为需求分配稳定编号，并为关键场景编写可测试验收标准。
+3. 将技术偏好与业务约束分开；只有影响目标或验收的技术条件才进入需求基线。
+4. 到达 G1，由用户确认需求、范围和暂时保留的业务待决项。
+
+### N3：形成业务能力地图
+
+按业务目标而不是技术分层拆解能力：
+
+1. 识别核心域、支撑能力、通用能力和外部系统责任。
+2. 为每项能力记录使用者、业务不变量、输入输出、关键数据、变化节奏和责任主体。
+3. 标出必须强一致、允许最终一致、可离线处理和必须人工确认的流程。
+4. 识别共享概念中的同名异义与不同上下文，避免直接建立全局统一数据模型。
+
+产物至少包括能力清单、能力关系和待确认边界。
+
+### N4：提出应用拆分候选
+
+1. 先形成最小可行边界：模块化单体、少量独立应用或其他适合交付形态的结构。
+2. 只有在业务所有权、数据、发布节奏、隔离或扩缩容需求明确时才增加独立应用。
+3. 对每个候选应用填写职责、不负责事项、调用方、数据所有权、上下游、运行和安全边界。
+4. 至少比较以下方案：维持单一应用、按主要业务能力拆分、按独立运行要求进一步拆分。
+5. 计算拆分引入的契约治理、分布式一致性、测试、部署、观测和团队协作成本。
+6. 到达 G2，由用户确认目标应用清单、保留模块和不拆分项。
+
+### N5：细化应用契约
+
+根据已批准边界按需执行：
+
+- 使用 `design-backend` 设计应用内部模块、服务、事务和错误边界。
+- 使用 `design-frontend` 设计前端应用、页面、状态和复用边界。
+- 使用 `design-api` 设计跨应用同步接口，使用 `prepare-api` 整理调用方字段映射。
+- 使用 `design-db` 明确数据所有权、表结构、索引和未来迁移边界。
+- 使用 `design-workflow` 设计跨应用状态、任务、补偿、幂等和审计。
+
+跨应用共享代码只保留稳定、无业务所有权争议的基础能力。共享数据库、跨库事务和双向同步必须显式记录风险，不能作为无说明默认方案。
+
+### N6：设计工程和运行结构
+
+在不创建代码的前提下给出建议结构：
+
+- 仓库组织：单仓、多仓或混合方式及选择依据；
+- 每个应用的源码、测试、契约和配置边界；
+- 公共库的准入条件、版本和兼容策略；
+- 本地开发、持续集成、制品、部署和环境配置方式；
+- 日志、指标、追踪、健康检查和故障隔离要求；
+- 认证授权、密钥管理和敏感数据处理边界。
+
+无法从需求确定的平台决策继续作为待确认项，不把目录草案写成已创建结构。
+
+### N7：形成建设计划
+
+使用 `plan-change` 按以下依赖顺序制定计划：
+
+1. 建立项目与契约基线；
+2. 搭建最小工程和验证链路；
+3. 优先实现能纵向验证核心场景的应用切片；
+4. 建设公共能力和外部集成；
+5. 完成跨应用契约、失败恢复和安全验证；
+6. 补齐部署、可观测性、容量和验收验证。
+
+每个批次记录输入、应用范围、产物、依赖、测试、停止条件和回退方式。到达 G3，由用户确认后续是否进入工程创建与代码实现。
+
+## 4. 新项目交付物
+
+- 已验证的 `AGENTS.md` 与 `.craftkit/` 项目资料；
+- 已确认需求基线和待确认清单；
+- 业务能力地图及能力关系；
+- 应用拆分方案、替代方案和决策依据；
+- 应用职责矩阵、契约清单、数据所有权矩阵和依赖关系；
+- 工程与运行结构建议；
+- 分阶段建设计划、验证矩阵和回退边界。
+
+## 5. 停止条件
+
+出现以下情况时暂停，不继续推导：核心业务目标冲突、数据所有权无法确定、关键外部契约未知、技术选型会实质改变交付边界、参考项目授权范围不清，或用户尚未批准对应审批门。
+
+## 6. 可直接复制的总控提示词
+
+```text
+请按《新项目初始化与应用拆分工作流》推进当前项目。先使用 init 只读判断项目模式，展示项目根、Git 状态、输入材料、参考范围和待确认项，在 G0 等待我确认。确认后保守初始化 AGENTS.md 与 .craftkit 项目资料，使用 requirements 建立需求基线，再依次完成业务能力地图、应用拆分候选、方案比较、应用职责与数据所有权矩阵、跨应用契约、工程与运行结构建议以及分阶段建设计划。
+
+全过程区分用户已确认目标、输入事实、参考项目做法、项目规则、设计建议、待确认项和待验证项。不要默认微服务、框架、数据库、云平台或最新版本；允许“不拆分”或“模块化单体”成为最终建议。只在 G0、G1、G2、G3、业务决策、权限扩大或高风险副作用处暂停。未经我另行授权，不创建业务代码，不安装依赖，不执行数据库、部署、提交或发布操作。
+```

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、索引和忽略规则检查。
+- 需求、当前事实、参考做法和设计建议保持可追溯分离。
+- 每个应用都有职责、不负责事项、接口、数据、依赖和运行边界。
+- 跨应用事务、数据同步、失败恢复、兼容和回滚已有明确处理方式或阻塞项。
+- 拆分方案包含至少一个替代方案，并说明为什么不选择过度拆分或维持现状。
+- 实施计划具有依赖顺序、验证方式、停止条件和可恢复路径。
+- 未经授权的编码、数据库、部署、提交和发布操作均未执行。

README.md

@@ -1,11 +1,16 @@
 # CraftKit
 
-CraftKit 是面向 Codex 的通用插件工具集，覆盖软件开发、文档处理、Git 交付、项目知识维护和 Skill 管理。每个插件均可独立安装，能力描述保持简洁、中性，并以当前 Codex 能力和公开标准为基础维护。
+CraftKit 是面向 Codex 的通用插件工具集，覆盖软件开发、文档处理、Git 交付、项目知识维护和 Skill 管理。每个插件的核心能力均可独立安装；同时安装相关插件时可以获得跨 Skill 增强，缺少增强插件时按各 Skill 声明的回退流程执行。能力描述保持简洁、中性，并以当前 Codex 能力和公开标准为基础维护。
 
 ## 全流程自动化
 
 需要根据原始需求和项目代码，串联需求分析、技术设计、开发分支、代码实现、测试审核与本地提交时，请使用 [CraftKit 全流程自动化使用指南](WORKFLOW.md)。该指南提供阶段状态机、人工审批门、自动推进规则和可直接交给 Codex 或其他已安装 CraftKit 工具的总控提示词。
 
+需要从项目上下文初始化推进到应用边界识别、拆分设计和实施规划时，请使用[项目初始化到应用拆分工作流](PROJECT-INITIALIZATION-AND-APPLICATION-SPLIT.md)，并根据项目现状选择：
+
+- [新项目初始化与应用拆分工作流](NEW-PROJECT-INITIALIZATION-AND-APPLICATION-SPLIT.md)：适用于空目录、新仓库或尚未形成有效源码结构的项目。
+- [已有项目初始化与应用拆分工作流](EXISTING-PROJECT-INITIALIZATION-AND-APPLICATION-SPLIT.md)：适用于已有源码、数据、接口和部署形态，需要基于现状渐进拆分的项目。
+
 ## 插件组成
 
 | 插件 | 用途 |
@@ -103,6 +108,13 @@ CraftKit 是面向 Codex 的通用插件工具集，覆盖软件开发、文档
 CraftKit/
 ├─ .agents/plugins/marketplace.json  # 仓库级 Codex 插件市场清单
 ├─ AGENTS.md                         # 项目协作与维护约定
+├─ WORKFLOW.md                       # 需求到本地提交的研发交付工作流
+├─ PROJECT-INITIALIZATION-AND-APPLICATION-SPLIT.md
+│                                   # 项目初始化到应用拆分的共同入口
+├─ NEW-PROJECT-INITIALIZATION-AND-APPLICATION-SPLIT.md
+│                                   # 新项目口径
+├─ EXISTING-PROJECT-INITIALIZATION-AND-APPLICATION-SPLIT.md
+│                                   # 已有项目口径
 ├─ plugins/                          # 可独立安装的插件
 │  ├─ dev/
 │  ├─ doc/