@namewta/speculo 0.3.3 → 0.3.4

package/README.md

@@ -49,7 +49,7 @@ After initialization, the target project gains the following AI agent-callable a
 | `retro` | Retrospective analysis with `gh issue` creation |
 | `status` | Summary of installed workflows, active changes, and anomalies |
 
-### 6 Skills
+### 7 Skills
 
 | Skill | Purpose |
 |---|---|
@@ -58,7 +58,8 @@ After initialization, the target project gains the following AI agent-callable a
 | `docs-sync` | Core documentation audit and synchronization |
 | `github-npm-ops` | GitHub issue/PR triage and npm operations |
 | `speculo-retro` | Retrospective analysis |
-| `dev-worktree` | Git worktree isolation for development |
+| `typescript-engineering-standards` | Progressive TypeScript/JS/React/Node engineering standards with references, templates, and examples |
+| `writing-great-skills` | Authoring guidance for agent skills |
 
 ### 2 Workflow Packages
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@namewta/speculo",
-  "version": "0.3.3",
+  "version": "0.3.4",
   "description": "Workflow-packaged specification-driven development assets with install, update, and migration tooling.",
   "type": "module",
   "bin": {

package/template/skills/typescript-engineering-standards/README.md

@@ -0,0 +1,36 @@
+# TypeScript Engineering Standards Skill
+
+这是一个采用渐进式披露结构的通用 TypeScript 工程规范 Skill。
+
+## 使用方式
+
+将整个 `typescript-engineering-standards/` 目录放入支持 Skill 的目录中，并以 `SKILL.md` 作为入口。不同平台的 Skill 安装位置可能不同；保持目录内部相对路径不变即可。
+
+## 目录说明
+
+```text
+typescript-engineering-standards/
+├── SKILL.md              # 主入口：触发条件、工作流、参考路由
+├── references/           # 详细规范，按任务最小化读取
+├── templates/            # AGENTS、tsconfig、格式化、PR 与评审模板
+├── examples/             # 目录、命名、类型、注释和审查示例
+└── manifest.txt          # 包内文件清单
+```
+
+## 设计原则
+
+- `SKILL.md` 保持相对精简，不承载所有细节。
+- 详细规则按主题拆分到 `references/`。
+- 执行具体任务时只读取必要参考。
+- 模板是起点，不直接覆盖现有仓库配置。
+- 用户要求、平台约束和仓库事实优先于通用默认规则。
+
+## 推荐入口
+
+- 创建或审查项目目录：`references/01-project-architecture-and-directory-layout.md`
+- 文件和标识符命名：`references/02-file-directory-and-symbol-naming.md`
+- TypeScript 类型安全：`references/04-typescript-type-system.md`
+- 注释和 JSDoc：`references/06-comments-jsdoc-and-documentation.md`
+- 测试：`references/07-testing-strategy.md`
+- 格式化、Lint、复杂度：`references/10-formatting-lint-and-complexity.md`
+- CI 和质量门禁：`references/11-configuration-dependencies-and-ci.md`

package/template/skills/typescript-engineering-standards/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: typescript-engineering-standards
+description: 为 TypeScript、JavaScript、React、Node.js、Electron、CLI、npm 库与 Monorepo 项目提供可渐进加载的工程规范。用于新建项目、生成代码、目录设计、命名、类型建模、代码审查、重构、测试、Lint、CI、安全与质量门禁；详细规则按任务从 references/ 中最小化读取。
+---
+
+# TypeScript Engineering Standards Skill
+
+本 Skill 将 TypeScript 工程规范拆成一个轻量主入口和多个主题参考文档。执行任务时采用**渐进式披露**：先判断任务类型，再只读取必要参考，避免把全部规范一次性加入上下文。
+
+## 适用任务
+
+在以下任务中使用本 Skill：
+
+- 设计或调整 TypeScript 项目目录。
+- 创建、重命名、移动 `.ts`、`.tsx`、测试或声明文件。
+- 编写、补全、重构或审查 TypeScript/React/Node.js 代码。
+- 制定团队编码规范、`AGENTS.md`、`CONTRIBUTING.md` 或 PR 检查清单。
+- 配置 TypeScript、格式化、Lint、测试、构建与 CI。
+- 处理类型安全、异步、错误、资源清理、安全、性能或跨平台问题。
+- 对现有仓库做工程质量审计。
+
+不在以下场景机械套用：
+
+- 用户明确指定了不同规范。
+- 框架、生成器或公开 API 有不可违背的约定。
+- 任务仅是解释一段代码且不涉及代码修改或规范判断。
+
+## 规则优先级
+
+发生冲突时依次遵循：
+
+1. 用户的明确要求。
+2. 当前仓库已生效的配置、公共 API 与框架约定。
+3. 当前模块已经形成且一致的局部惯例。
+4. 本 Skill 的通用默认规则。
+
+不要为了符合本 Skill 而进行与任务无关的大规模重命名、格式化或架构迁移。发现历史问题时，区分“本次必须修复”和“建议后续治理”。
+
+## 核心执行流程
+
+### 1. 识别任务和边界
+
+先判断：
+
+- 项目类型：Web、React、Node.js、Electron、CLI、库或 Monorepo。
+- 任务类型：新建、增量开发、重构、审查、修复、规范制定或配置。
+- 运行边界：浏览器、服务端、主进程、预加载、Worker、测试环境。
+- 变更范围：单文件、单领域、跨模块或全仓库。
+
+### 2. 检查仓库事实
+
+修改现有项目时，优先检查：
+
+- `package.json` 与锁文件。
+- `tsconfig*.json`。
+- ESLint、Oxlint、Prettier、Oxfmt、Biome 等配置。
+- 测试配置与现有测试命名。
+- `src/` 目录结构、路径别名和导出方式。
+- `AGENTS.md`、`CONTRIBUTING.md`、README 与 CI 工作流。
+
+不要假设项目使用 React、ESLint、Prettier、Vitest、Zod 或某种模块系统。
+
+### 3. 最小化读取参考文档
+
+仅加载与任务直接相关的参考文档。只有进行全仓库规范设计或综合审计时，才读取多个主题。
+
+| 任务 | 首选参考 |
+|---|---|
+| 判断规则强度、处理冲突 | `references/00-standard-levels-and-precedence.md` |
+| 设计目录、拆模块、平铺策略 | `references/01-project-architecture-and-directory-layout.md` |
+| 文件、目录、变量、类型命名 | `references/02-file-directory-and-symbol-naming.md` |
+| 导入、导出、Barrel、依赖方向 | `references/03-modules-imports-exports-and-dependencies.md` |
+| 类型、`unknown`、联合、声明文件 | `references/04-typescript-type-system.md` |
+| 函数、异步、错误、资源生命周期 | `references/05-functions-async-errors-and-resources.md` |
+| 注释、JSDoc、TODO、文档 | `references/06-comments-jsdoc-and-documentation.md` |
+| 单元、集成、契约、E2E 测试 | `references/07-testing-strategy.md` |
+| React、Hook、状态、可访问性 | `references/08-react-and-frontend.md` |
+| Node.js、CLI、路径、环境变量 | `references/09-node-cli-and-cross-platform.md` |
+| 格式、Lint、文件大小、复杂度 | `references/10-formatting-lint-and-complexity.md` |
+| 配置、依赖、脚本、CI | `references/11-configuration-dependencies-and-ci.md` |
+| 安全、性能、国际化 | `references/12-security-performance-and-i18n.md` |
+| Git、PR、评审和交付 | `references/13-git-review-and-delivery.md` |
+| 老项目迁移、例外和渐进治理 | `references/14-adoption-exceptions-and-migration.md` |
+| 了解 Orca 中提炼出的工程习惯 | `references/15-orca-derived-observations.md` |
+
+完整索引见 `references/README.md`。
+
+### 4. 应用核心默认规则
+
+除非仓库事实或用户要求另有规定，默认遵守：
+
+- 先按运行环境和业务领域划分边界，领域内部局部平铺。
+- 文件名表达“领域 + 职责”，避免 `utils`、`helpers`、`common`、`misc` 等模糊名称。
+- 一个文件只有一个主要职责；不要为单个文件机械创建目录。
+- 默认使用命名导出，控制公共 API，禁止无意义全局 Barrel。
+- TypeScript 开启严格模式；外部输入先作为 `unknown` 并在边界验证。
+- 优先使用可辨识联合表达状态，使无效状态难以构造。
+- 所有 Promise、监听器、Timer、连接和进程都有明确处理与清理路径。
+- 注释解释原因、约束与权衡，不逐行翻译代码。
+- 单元测试靠近源码；跨模块集成与 E2E 测试放在独立测试目录。
+- 通过格式化、Lint、类型检查、测试和构建形成自动化门禁。
+
+### 5. 生成或修改代码
+
+生成代码时：
+
+- 遵循仓库现有模块系统和格式风格。
+- 新公开函数写明确返回类型。
+- 不引入未经请求的新框架或依赖。
+- 不用 `any`、双重断言、规则禁用或删除测试掩盖问题。
+- 需要外部验证时，在边界层完成，不把不可信类型传播到内部。
+- 修复缺陷时优先补回归测试。
+- 只修改任务相关文件，避免格式噪声。
+
+### 6. 审查和输出
+
+代码审查时按以下优先级报告：
+
+1. 正确性、安全和数据损坏风险。
+2. 类型系统未覆盖的运行时风险。
+3. 资源泄漏、竞态、取消与错误处理。
+4. 架构边界、循环依赖和公共 API。
+5. 测试缺口。
+6. 命名、文件大小和可维护性。
+7. 纯风格建议。
+
+每条问题尽量包含：位置、风险、触发条件、修复方向。不要把个人偏好描述成缺陷。
+
+## 常用模板
+
+- 精简团队规则：`templates/AGENTS.typescript.md`
+- 严格 TypeScript 基线：`templates/tsconfig.base.json`
+- 多环境项目引用：`templates/tsconfig.project-references.json`
+- 格式化基线：`templates/prettier.json`
+- 编辑器基线：`templates/.editorconfig`
+- npm 脚本示例：`templates/package-scripts.json`
+- PR 模板：`templates/pull-request-template.md`
+- 代码评审清单：`templates/code-review-checklist.md`
+
+模板是起点，不得在未检查项目工具链时直接覆盖现有配置。
+
+## 示例
+
+- 项目目录示例：`examples/project-layouts.md`
+- 命名模式示例：`examples/naming-patterns.md`
+- 类型建模示例：`examples/type-modeling-patterns.md`
+- 注释示例：`examples/comment-patterns.md`
+- 审查输出示例：`examples/review-output-example.md`
+
+## 交付要求
+
+完成任务前确认：
+
+- 变更符合当前仓库事实，而非仅符合抽象规范。
+- 必要测试和质量检查已执行，或明确说明未能执行的项目。
+- 没有增加无意义目录、模糊文件名或隐藏依赖。
+- 没有通过削弱类型、关闭规则或跳过测试来获得表面通过。
+- 输出聚焦本次任务；更广泛的治理建议单独列出，不混入必要修复。

package/template/skills/typescript-engineering-standards/examples/comment-patterns.md

@@ -0,0 +1,47 @@
+# 注释模式示例
+
+## 兼容性
+
+```ts
+// Why: Windows reports the executable path with inconsistent drive-letter casing.
+const normalizedPath = normalizeWindowsDriveLetter(executablePath)
+```
+
+## 第三方缺陷
+
+```ts
+// Why: SDK 4.2 can invoke this callback twice after cancellation.
+if (requestState.isSettled) {
+  return
+}
+```
+
+## 安全顺序
+
+```ts
+// Validate before resolving the path so traversal segments cannot escape the root.
+const safeRelativePath = parseRelativePath(input)
+```
+
+## 性能
+
+```ts
+// Keep the compiled expression outside the hot loop; this runs for every log line.
+const ansiPattern = createAnsiPattern()
+```
+
+## 不推荐
+
+```ts
+// Loop through items.
+for (const item of items) {
+  // Add the item.
+  results.push(item)
+}
+```
+
+## TODO
+
+```ts
+// TODO(PROJ-1423): Remove the v2 fallback after desktop 3.8 reaches 95% adoption.
+```

package/template/skills/typescript-engineering-standards/examples/naming-patterns.md

@@ -0,0 +1,42 @@
+# 命名示例
+
+## 从模糊名称改为具体名称
+
+| 模糊 | 推荐 |
+|---|---|
+| `utils.ts` | `shell-command-quote.ts` |
+| `helpers.ts` | `workspace-path-normalize.ts` |
+| `manager.ts` | `terminal-process-registry.ts` |
+| `handler.ts` | `payment-webhook-handler.ts` |
+| `service.ts` | `user-session-service.ts` |
+| `data.ts` | `workspace-summary.ts` |
+| `types.ts` | `payment-contract.ts` |
+| `constants.ts` | `terminal-limits.ts` |
+
+## 函数
+
+| 含义弱 | 推荐 |
+|---|---|
+| `handle()` | `handleWorkspaceClosed()` |
+| `process()` | `parseTerminalOutput()` |
+| `check()` | `validateWorkspacePath()` |
+| `getData()` | `loadUserProfile()` |
+| `doRetry()` | `retryPaymentCapture()` |
+
+## 布尔值
+
+| 含义弱 | 推荐 |
+|---|---|
+| `flag` | `shouldPersist` |
+| `enabled` | `isTelemetryEnabled` |
+| `valid` | `isWorkspacePathValid` |
+| `notReady` | `isInitializing` 或 `isReady` |
+
+## 单位
+
+| 含义弱 | 推荐 |
+|---|---|
+| `timeout` | `timeoutMs` |
+| `size` | `payloadSizeBytes` |
+| `delay` | `retryDelayMs` |
+| `limit` | `pageSizeLimit` |

package/template/skills/typescript-engineering-standards/examples/project-layouts.md

@@ -0,0 +1,75 @@
+# 项目目录示例
+
+## 小型 Node 服务
+
+```text
+src/
+├── app/
+│   ├── create-server.ts
+│   └── load-environment.ts
+├── features/
+│   └── user-auth/
+│       ├── authenticate-user.ts
+│       ├── authenticate-user.test.ts
+│       └── user-token.ts
+├── infrastructure/
+│   ├── database/
+│   └── http/
+└── shared/
+    └── result.ts
+```
+
+## React 应用
+
+```text
+src/
+├── app/
+│   ├── App.tsx
+│   └── routes.tsx
+├── features/
+│   ├── workspace-search/
+│   │   ├── WorkspaceSearchPanel.tsx
+│   │   ├── workspace-search-query.ts
+│   │   └── use-workspace-search.ts
+│   └── user-settings/
+├── shared/
+│   ├── components/
+│   └── hooks/
+└── infrastructure/
+    └── api/
+```
+
+`shared/components` 只放真正无业务归属且有多个真实调用方的组件。
+
+## Electron
+
+```text
+src/
+├── main/
+│   ├── app-lifecycle.ts
+│   └── windows/
+├── preload/
+│   └── workspace-api.ts
+├── renderer/
+│   ├── app/
+│   └── features/
+├── shared/
+│   └── workspace-contract.ts
+└── types/
+    └── electron-api.d.ts
+```
+
+## Monorepo
+
+```text
+apps/
+├── web/
+└── api/
+packages/
+├── domain/
+├── contracts/
+├── ui/
+└── test-support/
+```
+
+包边界应与独立发布、运行环境或稳定依赖方向对应，不要仅为缩短相对路径拆包。

package/template/skills/typescript-engineering-standards/examples/review-output-example.md

@@ -0,0 +1,25 @@
+# 代码审查输出示例
+
+## 阻塞问题
+
+### `src/features/workspace/load-workspace.ts:42`
+
+`JSON.parse()` 的结果被直接断言为 `WorkspaceConfig`。当配置缺少 `rootPath` 时，错误会延迟到文件系统调用，并可能访问错误位置。
+
+建议在配置边界使用 Schema 验证，将解析函数返回类型固定为已验证的 `WorkspaceConfig`，并补充缺失字段和路径穿越测试。
+
+## 重要问题
+
+### `src/main/process-registry.ts:88`
+
+关闭窗口时只移除了事件监听器，没有终止仍在运行的子进程。重复打开窗口会留下孤儿进程。
+
+建议让注册函数返回统一 `dispose()`，在窗口关闭和应用退出两个路径都调用，并增加清理回归测试。
+
+## 建议
+
+### `src/features/search/utils.ts`
+
+该文件同时包含查询解析、排序和本地存储。当前功能仍正确，但后续修改会持续扩大职责。
+
+建议在下一次触及该模块时拆为 `search-query-parser.ts`、`search-result-sort.ts` 和 `search-history-storage.ts`。本问题不必阻塞当前仅修复文案的变更。

package/template/skills/typescript-engineering-standards/examples/type-modeling-patterns.md

@@ -0,0 +1,66 @@
+# 类型建模示例
+
+## 状态机
+
+不推荐：
+
+```ts
+type RequestState = {
+  isLoading: boolean
+  hasError: boolean
+  data?: Data
+  error?: Error
+}
+```
+
+推荐：
+
+```ts
+type RequestState =
+  | { kind: 'idle' }
+  | { kind: 'loading' }
+  | { kind: 'success'; data: Data }
+  | { kind: 'failure'; error: Error }
+```
+
+## 外部边界
+
+```ts
+export function parseWorkspaceMessage(input: unknown): WorkspaceMessage {
+  return workspaceMessageSchema.parse(input)
+}
+```
+
+内部代码只接收已经验证的 `WorkspaceMessage`。
+
+## `satisfies`
+
+```ts
+const routes = {
+  home: '/',
+  settings: '/settings'
+} satisfies Record<string, `/${string}`>
+```
+
+保留具体字面量，同时验证整体契约。
+
+## 结果类型
+
+```ts
+type Result<TValue, TError> =
+  | { ok: true; value: TValue }
+  | { ok: false; error: TError }
+```
+
+适合调用方需要显式分支、失败属于正常业务结果的场景。不可恢复的程序错误仍可抛异常。
+
+## 单位类型
+
+高风险领域可使用品牌类型避免单位混用：
+
+```ts
+type Milliseconds = number & { readonly __brand: 'Milliseconds' }
+type Bytes = number & { readonly __brand: 'Bytes' }
+```
+
+仅在实际能降低错误且不会制造大量转换噪声时采用。

package/template/skills/typescript-engineering-standards/manifest.txt

@@ -0,0 +1,33 @@
+README.md
+SKILL.md
+examples/comment-patterns.md
+examples/naming-patterns.md
+examples/project-layouts.md
+examples/review-output-example.md
+examples/type-modeling-patterns.md
+references/00-standard-levels-and-precedence.md
+references/01-project-architecture-and-directory-layout.md
+references/02-file-directory-and-symbol-naming.md
+references/03-modules-imports-exports-and-dependencies.md
+references/04-typescript-type-system.md
+references/05-functions-async-errors-and-resources.md
+references/06-comments-jsdoc-and-documentation.md
+references/07-testing-strategy.md
+references/08-react-and-frontend.md
+references/09-node-cli-and-cross-platform.md
+references/10-formatting-lint-and-complexity.md
+references/11-configuration-dependencies-and-ci.md
+references/12-security-performance-and-i18n.md
+references/13-git-review-and-delivery.md
+references/14-adoption-exceptions-and-migration.md
+references/15-orca-derived-observations.md
+references/README.md
+templates/.editorconfig
+templates/AGENTS.typescript.md
+templates/code-review-checklist.md
+templates/package-scripts.json
+templates/prettier.json
+templates/pull-request-template.md
+templates/tsconfig.base.json
+templates/tsconfig.project-references.json
+manifest.txt

package/template/skills/typescript-engineering-standards/references/00-standard-levels-and-precedence.md

@@ -0,0 +1,51 @@
+# 规则级别与优先顺序
+
+## 规范词义
+
+- **必须**：影响正确性、安全、类型边界、资源生命周期或团队一致性的硬性要求。
+- **应当**：绝大多数情况下适用；偏离时应有可说明的理由。
+- **建议**：默认推荐，但可根据规模、框架和团队经验调整。
+- **禁止**：高概率制造缺陷、隐藏风险或显著降低维护性的做法。
+
+## 冲突优先级
+
+从高到低：
+
+1. 用户明确要求和产品约束。
+2. 运行平台、框架、协议或公开 API 的硬约束。
+3. 已生效的仓库配置与自动化检查。
+4. 当前模块一致、可解释的局部惯例。
+5. 本 Skill 的默认规范。
+
+## 事实优先
+
+审查现有项目时，不要仅凭文件名或技术栈推断规则。应读取配置和相邻实现，确认：
+
+- 模块系统是 ESM、CommonJS 还是打包器模式。
+- 测试框架和测试命名。
+- 格式化与 Lint 工具。
+- 路径别名和包边界。
+- React、Node、Electron 等运行环境。
+- 哪些文件由代码生成器维护。
+
+## 一致性不是绝对理由
+
+“项目一直这么写”不能自动证明做法正确。以下问题即使历史代码广泛存在，也应阻止继续扩散：
+
+- 不可信输入未经验证。
+- 敏感信息泄露。
+- 无法清理的监听器、Timer、连接或进程。
+- `any` 向公共 API 传播。
+- 循环依赖或跨运行环境非法导入。
+- 测试被删除、跳过或规则被关闭以掩盖失败。
+
+处理方式应以增量治理为主：新代码不继续引入，触及旧代码时适度修复，避免无关全仓库改写。
+
+## 建议与缺陷的区分
+
+代码审查中：
+
+- 能导致错误、安全问题或维护阻塞的，标记为缺陷。
+- 存在合理替代方案、但当前实现仍正确的，标记为建议。
+- 纯偏好且仓库已有统一风格的，不应提出。
+- 无法证明风险的猜测，应明确说明不确定性。

package/template/skills/typescript-engineering-standards/references/01-project-architecture-and-directory-layout.md

@@ -0,0 +1,105 @@
+# 项目架构与目录布局
+
+## 先表达边界
+
+目录优先表达以下稳定边界之一：
+
+- 运行环境：`main/`、`renderer/`、`server/`、`worker/`、`cli/`。
+- 产品领域：`user-auth/`、`orders/`、`payments/`。
+- 架构职责：`domain/`、`application/`、`infrastructure/`。
+- 独立发布单元：`apps/`、`packages/`。
+
+不要在同一层混合互不相干的分类逻辑，例如同时出现全局 `components/`、`payments/`、`services/`、`cli/`。
+
+## 领域优先，技术类型局部化
+
+项目很小时可按技术类型组织；业务增长后应将技术目录移动到领域内部。
+
+推荐：
+
+```text
+src/
+├── app/
+├── features/
+│   ├── user-auth/
+│   │   ├── login-service.ts
+│   │   ├── login-service.test.ts
+│   │   └── components/
+│   └── payments/
+├── shared/
+└── infrastructure/
+```
+
+不推荐长期维持：
+
+```text
+src/
+├── components/
+├── hooks/
+├── services/
+├── types/
+└── utils/
+```
+
+## 局部平铺
+
+一个职责明确的领域目录应默认平铺文件，不为每个文件建立同名目录。
+
+建议增加子目录的条件：
+
+- 形成稳定、可命名的子领域。
+- 同级实现文件长期超过约 8～12 个，定位成本明显上升。
+- 文件组拥有独立入口、资源、测试夹具或生命周期。
+- 文件组需要整体移动、替换或发布。
+- 依赖方向或运行环境需要物理隔离。
+
+不要创建仅包含一个普通实现文件的目录，也不要为了对称而制造空层级。
+
+## `shared/` 准入
+
+代码进入共享层前应满足：
+
+1. 至少有两个真实调用方。
+2. 不依赖具体业务领域。
+3. 具有具体、可命名的能力。
+4. API 相对稳定。
+5. 不会造成反向依赖。
+6. 共享确实减少重复，而非提前抽象。
+
+`shared/` 不是“不知道放哪里”的收容区。
+
+## 多运行环境
+
+Electron、全栈、Worker 或混合运行环境项目应物理隔离：
+
+```text
+src/
+├── main/
+├── preload/
+├── renderer/
+├── shared/
+└── types/
+```
+
+要求：
+
+- 各环境使用独立 `tsconfig` 或项目引用。
+- 浏览器代码不导入 Node 专属模块。
+- 服务端代码不无意依赖 DOM。
+- 跨环境数据通过显式、可序列化契约。
+- 桥接层 API 最小化，并验证来自外部边界的数据。
+
+## 推荐深度
+
+目录深度不是硬性指标，但从领域根目录到普通实现文件通常不应超过三层。深层目录往往表示过度分类、缺少领域命名或每文件一目录。
+
+## 拆分信号
+
+出现以下情况时考虑拆模块或拆包：
+
+- 一个目录同时包含多个运行环境代码。
+- 改动一个领域经常触发另一个无关领域。
+- 同一目录的文件命名需要大量前缀才能区分。
+- 公共入口不断扩大。
+- 依赖图出现循环。
+- 不同部分需要不同构建、发布或权限策略。