@namewta/speculo 1.0.22 → 2.0.1

package/template/skills/docs-sync/references/agents/evidence-collection.md

@@ -1,184 +0,0 @@
-# Evidence Collection
-
-## 原则
-
-写 AGENTS.md 之前，先收集证据，再落结论。不允许在没有文件支撑的情况下写结论。
-
-**核心铁律**：
-- 结论必须能被文件直接支撑
-- 允许总结实现机制，禁止虚构业务语义
-- 当证据不足以支撑强结论时，退回到“入口 + 调查顺序”的写法
-
-## 通用证据收集顺序
-
-适用于所有角色，在角色专属取证之前执行。
-
-### 1. Manifest 文件
-
-读取主 manifest 文件的以下内容：
-
-| 生态 | 关键字段 |
-|------|---------|
-| Node.js / TypeScript | `name`、`description`、`scripts`、`dependencies`、`devDependencies`、`main`、`exports`、`bin`、`workspaces` |
-| Java / Maven | `artifactId`、`description`、`packaging`、`<modules>`、`<dependencies>`、插件配置 |
-| Rust | `[package]` name/description、`[dependencies]`、`[[bin]]`、`[lib]`、`[workspace]` |
-| Go | `module` 路径、`require`/`replace` 指令 |
-| Python | `[project]` name/description、`[project.scripts]`、`[project.dependencies]` |
-| CMake | `project()`、`add_executable()`、`add_library()`、`target_link_libraries()` |
-| 通用 | 任何描述当前模块定位、边界和依赖的声明 |
-
-### 2. 关键目录结构
-
-列出直接子目录，跳过忽略目录。粗略统计：
-
-- 源码主目录（如 `src/`、`lib/`、`app/`）
-- 资源/配置目录（如 `resources/`、`config/`、`assets/`）
-- 测试目录（如 `test/`、`tests/`、`spec/`、`__tests__/`）
-- 文档目录（如 `docs/`）
-
-不超过 10 项。不要穷举，只列对定位问题有用的。
-
-### 3. 关键入口文件
-
-至少找到 3-6 个最能代表模块职责的文件：
-
-- 入口/启动文件
-- 导出索引文件
-- 核心业务/能力文件
-- 关键配置文件
-- 测试入口
-
-### 4. 依赖与消费关系
-
-- 项目/仓库内部依赖了哪些兄弟模块
-- 被哪些兄弟模块依赖（反向消费方）
-- 若有外部关键依赖需要说明，只提 AGENTS 无法从 manifest 推断的
-
-### 5. 测试入口
-
-- 测试目录路径
-- 测试运行命令（如果非标准）
-- 测试覆盖范围简述
-
-## 各角色专属取证重点
-
-### `repo-root`
-
-**优先读**：
-- 顶层 manifest 的 workspace/multi-module 声明
-- 顶层直接子目录的 manifest 清单
-- 根级 CI/CD 配置（如 `.github/workflows/`）
-- 根级工具链配置（如 `turbo.json`、`nx.json`、`lerna.json`）
-
-**重点关注**：
-- 顶层分层理由：为什么这样拆 apps/libs/modules
-- 根级命令与任务编排
-- 哪些是聚合层，哪些是叶子层
-
-### `scripts-docs`
-
-**优先读**：
-- 脚本根目录下的直接子目录
-- 根级读写脚本/管理脚本
-- 配置文件与模板
-
-**至少抽看**：
-- 每个一级子目录的 1-2 个代表性文件
-- 明确哪些子目录是运行时数据、初始化脚本、人工样例或环境配置
-
-**重点关注**：
-- 五类子树覆盖：脚本、SQL/迁移、配置、任务清单、样例数据
-- 不需要穷举所有文件，但必须覆盖各类子树的职责和继续下钻入口
-
-### `aggregator`
-
-**优先读**：
-- 父 manifest 的子模块声明（`<modules>`、`workspaces`、`members`）
-- 子模块名称列表与各自 manifest 的关键字段
-
-**至少抽看**：
-- 1-2 个代表性子模块的 manifest 或源码入口
-- 子模块之间的分组逻辑（BOM 组 / 核心能力组 / 应用组 / 业务域组）
-
-**重点关注**：
-- 为什么需要这个聚合层
-- 子模块的分组逻辑，避免聚合描述空泛
-- 不展开子模块实现细节
-
-### `runnable-app`
-
-**优先读**：
-- 启动入口文件（如 `main.ts`、`Application.java`、`main.rs`）
-- 路由/控制器入口
-- 中间件/插件装配
-- 运行时配置（如 `application.yml`、`.env`、`vite.config.ts`）
-
-**至少抽看**：
-- 请求/响应链路：路由 → 控制器 → 服务 → 数据层
-- store / 状态管理入口（前端）
-- 核心业务子树
-
-**重点关注**：
-- 启动链路与运行时装配方式
-- 内部依赖模块如何组装进应用
-- 不要把应用写成纯目录列表
-
-### `capability-module`
-
-**优先读**：
-- 导出入口文件（如 `src/index.ts`、`mod.rs`、`__init__.py`）
-- 主包路径下的核心分层目录
-
-**至少抽看**：
-- 最能代表模块职责的 3-6 个关键文件或子目录
-- 如果存在明确的请求处理链路（controller → service → domain → mapper），写成排查路径
-- 如果更偏框架扩展，重点看 config / plugin / utils / factory
-
-**重点关注**：
-- 它是能力模块、业务模块还是集成模块
-- 被哪些兄弟模块消费
-- 上下游依赖链
-
-### `contract-module`
-
-**优先读**：
-- manifest 的依赖管理、导出声明
-- 若存在类型文件/配置文件的目录
-
-**重点关注**：
-- 约束了什么：版本对齐、依赖传递、配置契约、类型契约、接口契约
-- 由谁引用、为什么需要独立出来
-- 没有 `src/` 时要显式说明这是约束层
-
-**不需要**：
-- 查运行时代码（它没有）
-- 虚构消费链路
-
-## 证据记录格式
-
-收集证据时，在心里或临时笔记中这样组织：
-
-```
-[目录路径] <角色>
-  Manifest: <关键字段摘要>
-  关键目录: <3-6个>
-  入口文件: <3-6个>
-  内部依赖: <列表>
-  消费方: <列表>
-  测试: <目录或入口>
-  定位: <一句话模块定位>
-  核心逻辑: <2-3句话>
-```
-
-这是内部工作格式，不写入 AGENTS.md。目的是确保有足够证据支撑每个章节。
-
-## 证据不足时的处理
-
-当某个章节找不到足够证据时：
-
-1. **Module Positioning**：退回到“目录位置 + manifest 声明”，不臆断定位。
-2. **Core Logic**：退回到“入口文件 + 阅读顺序”，不虚构工作流。
-3. **Dependencies**：只写 manifest 中直接看到的依赖，不推断传递依赖。
-4. **Usage Notes**：只写可直接验证的提醒，不写猜测。
-
-总之：宁愿留白，不造假。

package/template/skills/docs-sync/references/agents/manifest-discovery.md

@@ -1,126 +0,0 @@
-# Manifest Discovery
-
-## 核心规则
-
-按真实作用域和独有约束决定是否需要手册；manifest 是定位证据，不是唯一许可或强制创建条件。没有 manifest 不能成为删除用户手册的理由。
-
-## Manifest 文件注册表
-
-一个目录可能同时存在多个 manifest 文件。按优先级选择**主 manifest**，其余作为辅助参考。
-
-| 优先级 | 生态 | Manifest 文件 |
-|--------|------|--------------|
-| 1 | Node.js / TypeScript | `package.json` |
-| 1 | Java / Maven | `pom.xml` |
-| 2 | Java / Gradle | `build.gradle`、`build.gradle.kts` |
-| 1 | Rust | `Cargo.toml` |
-| 1 | Go | `go.mod` |
-| 1 | Python | `pyproject.toml` |
-| 2 | Python（旧） | `setup.py`、`setup.cfg` |
-| 1 | C / C++ / CMake | `CMakeLists.txt` |
-| 3 | C / C++ / 通用 | `Makefile` |
-| 1 | Ruby | `Gemfile` |
-| 1 | Elixir | `mix.exs` |
-| 1 | Dart / Flutter | `pubspec.yaml` |
-| 1 | PHP | `composer.json` |
-| 1 | Zig | `build.zig` |
-| 1 | .NET | `*.csproj`、`*.fsproj` |
-| 1 | Swift | `Package.swift` |
-| 1 | Haskell | `*.cabal`、`stack.yaml` |
-| 1 | Nix | `flake.nix`、`default.nix` |
-
-### 多 manifest 选择规则
-
-同一目录存在多个 manifest 时，按优先级选主 manifest：
-
-```
-目录有 package.json + Makefile → 主 manifest = package.json（优先级1 > 3）
-目录有 pom.xml + build.gradle → 主 manifest = pom.xml（优先级1 > 2）
-目录有 CMakeLists.txt + Makefile → 主 manifest = CMakeLists.txt（优先级1 > 3）
-```
-
-主 manifest 决定角色判定的主要依据；辅助 manifest 在证据收集时补充参考。
-
-## 扫描算法
-
-### 输入
-
-- `root`: 项目根目录
-- `target_subdir`（可选）：仅扫描该子树
-- `manifest_filter`（可选）：仅匹配指定 manifest 文件类型
-
-### 扫描步骤
-
-1. **确定扫描起点**：`scan_root = root / target_subdir`，若未指定则为 `root`。
-2. **递归遍历**：从 `scan_root` 递归遍历所有子目录。
-3. **跳过忽略目录**：见文末「忽略目录完整清单」；另跳过任何在 `.gitignore` 中且非被跟踪的目录。
-4. **检测 manifest**：对每个非忽略目录，检查是否存在任何 manifest 文件。
-5. **选择主 manifest**：按优先级选择。
-6. **应用过滤**：若用户指定了 `manifest_filter`，仅保留匹配该类型的目录。
-7. **补充作用域边界**：检查已定位的嵌套手册、独立测试/生成物约束、部署与安全边界；即使无 manifest，有真实独有约束仍可纳入。候选目录只有在减少歧义或提供独有规则时才生成手册，不按 manifest 数量机械铺开。
-
-### 构建父子树
-
-1. 所有 manifest 目录按路径深度排序。
-2. 每个目录的**父 manifest 目录** = 路径上最近的祖先 manifest 目录。
-3. 项目根目录（`repo-root`）的父级为 `null`。
-
-## 无 manifest 的作用域
-
-scripts-docs 是常见例子，不是唯一合法例外；按实际规则作用域保留或创建手册，不需要仅因无 manifest 另设批准门：
-
-### 自动检测条件
-
-- 目录名匹配 `script`、`scripts`、`docs`、`docker`、`deploy`
-- 且父目录是 manifest 目录
-- 且目录内不含任何 manifest 文件
-
-### 用户显式指定
-
-用户可在调用时声明额外的 scripts-docs 目录，格式：相对于项目根的路径。
-
-## 清理规则
-
-### 仅提出清理候选（按已确认范围和所有权执行）
-
-- 已证实过期且不再有独有作用域约束的 AGENTS.md
-- 对应手册已确认移除且由调用方拥有的 CLAUDE.md
-- 忽略目录（`node_modules` 等）下的任何 `AGENTS.md` 或 `CLAUDE.md`
-
-### 不清理
-
-- 有 manifest 目录下的 `AGENTS.md`（将被刷新）
-- 有 manifest 目录下的 `CLAUDE.md`（将被刷新）
-- 用户显式指定的 scripts-docs 目录下的文档
-
-### 清理后处理
-
-- 删除文档后若目录变空且需要保留，使用 `.gitkeep` 留存。
-- 不要用 README 或 AGENTS 占位。
-
-## 忽略目录完整清单
-
-```
-.git
-node_modules
-dist
-target
-.turbo
-coverage
-__pycache__
-.idea
-.vscode
-build
-out
-.next
-.nuxt
-vendor
-bower_components
-.cache
-*.egg-info
-.venv
-venv
-env
-```
-
-若用户项目有特定忽略需求，以用户说明为准。

package/template/skills/docs-sync/references/agents/role-classification.md

@@ -1,141 +0,0 @@
-# Role Classification
-
-## 原则
-
-为按作用域发现的手册目录判定**唯一**角色。manifest 只提供模块结构证据；无 manifest 但有独有约束时按实际职责选择最近角色，说明边界而非臆造模块。
-
-角色决定：
-- 使用哪个模板骨架
-- 证据收集的重点方向
-- AGENTS.md 的章节侧重
-
-## 6 种角色
-
-### 优先级 1：`repo-root`
-
-**判定条件**：目录是项目根目录（扫描起点）。
-
-**识别特征**：
-- 路径等于 `scan_root`
-- 通常包含 `.git`、顶层 CI 配置、workspace 声明等
-
-### 优先级 2：`scripts-docs`
-
-**判定条件**：目录有独立脚本、文档或其他无法由上级手册覆盖的规则作用域。
-
-**识别特征**（满足任一）：
-- 用户显式声明为 scripts-docs
-- 自动检测：目录名匹配 `script`、`scripts`、`docs`、`docker`、`deploy`，且父目录是 manifest 目录
-
-**特殊规则**：
-- 不要求有 manifest 文件
-- 只为根目录生成 AGENTS.md，不为子目录继续生成
-- 说明实际脚本、文档或其他独有约束范围；不把无 manifest 称为违规。
-- 必须区分“可执行脚本”“SQL 资产”“配置模板”“运行时数据目录”
-
-### 优先级 3：`aggregator`
-
-**判定条件**：manifest 声明了子模块、子项目或 workspace 成员。
-
-**各生态识别方式**：
-
-| 生态 | 识别方式 |
-|------|---------|
-| Node.js / TypeScript | `package.json` 含 `workspaces` 字段 |
-| Java / Maven | `pom.xml` 含 `<modules>` 子元素 |
-| Java / Gradle | `settings.gradle` 含 `include` 且当前目录是声明目录 |
-| Rust | `Cargo.toml` 含 `[workspace]` 且当前是 workspace root |
-| Go | 有 `go.work` 且使用 `use` 声明多个模块目录 |
-| Python | `pyproject.toml` 含 `[tool.hatch.workspace]` 或 `[tool.uv.workspace]` |
-| C / CMake | `CMakeLists.txt` 含 `add_subdirectory()` |
-| Dart / Flutter | `pubspec.yaml` 含 `workspace` 且声明了多个 package |
-| .NET | 目录含多个 `*.csproj` 且被父级 `*.sln` 或 Directory.Build.props 统管 |
-
-**关键要求**：
-- 必须解释子模块的分组逻辑，不是只列模块名
-- 必须写清“哪些问题必须进入哪个子模块继续调查”
-- 聚合层只说编排，不展开子模块实现
-
-### 优先级 4：`runnable-app`
-
-**判定条件**：无子模块声明，但有明确的运行入口。
-
-**各生态识别方式**：
-
-| 生态 | 识别方式 |
-|------|---------|
-| Node.js / TypeScript | `package.json` 的 `bin` 字段、`main` 指向可执行入口、或存在 `src/main.ts`、`src/index.ts` 且脚本含 `start`/`dev` |
-| Java | 存在 `@SpringBootApplication`、`@QuarkusMain`、`SpringApplication.run()`、`public static void main` |
-| Rust | `Cargo.toml` 含 `[[bin]]` target，或 `src/main.rs` 存在 |
-| Go | `package main` + `func main()` |
-| Python | 含 `__main__.py`、`console_scripts` entry point、或 `if __name__ == "__main__"` |
-| C / CMake | `CMakeLists.txt` 含 `add_executable()` |
-| Ruby | `Gemfile` 含执行入口声明、或 `bin/` 目录含可执行脚本 |
-| Elixir | `mix.exs` 含 `application` 配置且 `mod` 指向 Application 模块 |
-| Dart | `pubspec.yaml` 含 `executables` 字段 |
-
-**关键要求**：
-- 必须写清启动入口、运行时装配、核心应用链路
-- 必须写清内部依赖模块如何接入到当前应用
-- 不改写成叶子模块的膨胀版
-
-### 优先级 5：`contract-module`
-
-**判定条件**：无子模块、无运行入口，主要职责是暴露类型、契约、配置或依赖约束。
-
-**各生态识别方式**：
-
-| 生态 | 识别方式 |
-|------|---------|
-| Node.js / TypeScript | `package.json` 的 `name` 含 `types`/`config`/`tsconfig`，或 `main`/`exports` 仅暴露 `.d.ts` 文件 |
-| Java / Maven | `pom.xml` 的 `artifactId` 含 `bom`、或 `packaging` 为 `pom`（不含 `<modules>`）、或仅含依赖管理 |
-| Java / Gradle | `build.gradle` 使用 `java-platform` 插件 |
-| Rust | `Cargo.toml` 不含 `[[bin]]`，`[lib]` 仅暴露类型宏，且无实质运行时逻辑 |
-| Go | `go.mod` 声明包但目录内仅含类型定义、常量、接口声明，无 `func main` |
-| Python | `pyproject.toml` 仅含类型桩 (`*.pyi`)、或仅暴露 `__init__.py` 无函数体 |
-| 通用 | 目录没有 `src/` 或仅有类型定义文件 |
-
-**关键要求**：
-- 必须解释约束了什么、被谁消费
-- 没有 `src/` 时，显式说明这是约束层而非实现层
-- 不要误写成运行时代码模块
-
-### 优先级 6：`capability-module`
-
-**判定条件**：以上都不匹配的其余所有 manifest 目录。
-
-**典型匹配**：
-- 能力库、工具库、业务模块
-- 数据层模块、领域模块
-- 集成模块、中间件模块
-- 共享组件库
-
-**关键要求**：
-- 必须写清导出面、核心分层、关键业务/能力入口
-- 必须写清内部依赖与上游消费方
-- 区分它是更偏能力模块、业务模块还是集成模块
-
-## 角色判定流程图
-
-```
-目录有 manifest 文件？
-├── 否 → 是项目根或存在独有约束？→ 是 → 按实际职责选角色；否 → 不新增手册，保留已有用户内容
-│                          └── 是 → repo-root
-│                └── 是 → repo-root
-└── 是 → 是 scripts-docs 目录？→ 是 → scripts-docs
-         └── 否 → 声明了子模块？→ 是 → aggregator
-                  └── 否 → 有运行入口？→ 是 → runnable-app
-                           └── 否 → 仅暴露契约/约束？→ 是 → contract-module
-                                    └── 否 → capability-module
-```
-
-## 角色与模板映射
-
-| 角色 | 模板文件 |
-|------|---------|
-| `repo-root` | `templates/repo-root-AGENTS.md` |
-| `scripts-docs` | `templates/scripts-docs-AGENTS.md` |
-| `aggregator` | `templates/aggregator-AGENTS.md` |
-| `runnable-app` | `templates/runnable-app-AGENTS.md` |
-| `contract-module` | `templates/contract-module-AGENTS.md` |
-| `capability-module` | `templates/capability-module-AGENTS.md` |

package/template/skills/docs-sync/references/agents/templates/aggregator-AGENTS.md

@@ -1,69 +0,0 @@
-# <module-name>
-
-## Scope
-
-- 说明当前聚合 manifest 覆盖的目录范围。
-- 明确哪些子模块拥有自己的 AGENTS.md。
-
-## Module Positioning
-
-- 标记当前角色为 `aggregator`。
-- 说明它在父层中的职责（公共能力聚合、业务域聚合、独立服务聚合等）。
-
-## Directory Structure
-
-- 列出直接子目录、关键文件、子级 manifest 模块。
-- 对子级模块按职责分组，而不是纯罗列。
-
-## Responsibilities
-
-- 说明当前聚合层负责模块编排、边界划分和阅读入口。
-- 明确不负责子模块内部实现细节。
-
-## Core Logic
-
-- 解释当前聚合为什么存在。
-- 解释 manifest 的子模块声明在编排什么。
-- 解释子模块之间的关系与进入时机。
-
-## Key Entry Points
-
-- 当前 manifest 文件
-- 代表性子模块的 manifest、启动入口或核心能力入口
-- 必要时补充关键配置或装配入口
-
-## Usage And Change Notes
-
-- 先按当前聚合层的分组逻辑定位子模块，再继续下钻，不要把聚合层写成叶子模块说明。
-- 调整子模块清单、模块归类或聚合职责时，同步检查父层导读。
-- 如果问题已经落到接口、领域逻辑或运行时配置，立即进入对应子模块 AGENTS.md 与源码。
-
-## Dependencies And Collaboration
-
-- 说明当前聚合与父层、子层的协作关系。
-- 说明哪些问题必须下钻到哪个子模块源码。
-
-## Investigation Rule
-
-- 明确：先读本层分组和编排关系。
-- 如果需要具体实现、接口、配置或异常处理，继续进入对应子模块 AGENTS.md 与源码。
-- 文档与代码冲突时以代码事实为准。
-
-## Core Commands
-
-- 面向当前聚合层的构建、测试命令。
-
-## Verification
-
-- 当前聚合层最小可执行校验。
-
-## Routing
-
-- 上级 manifest
-- 子级 manifest（每个附带一句话定位）
-
-## References
-
-- 当前 manifest
-- 关键聚合配置
-- 代表性子模块入口

package/template/skills/docs-sync/references/agents/templates/capability-module-AGENTS.md

@@ -1,68 +0,0 @@
-# <module-name>
-
-## Scope
-
-- 说明当前能力型或业务型 manifest 覆盖的目录范围。
-
-## Module Positioning
-
-- 标记当前角色为 `capability-module`。
-- 说明它在整仓中承担的能力或业务职责（能力库、业务模块、集成模块等）。
-
-## Directory Structure
-
-- 列出直接子目录、关键文件、主源码路径、核心分层、资源目录和测试目录。
-- 只保留定位问题需要的结构。
-
-## Responsibilities
-
-- 说明当前模块负责的实现范围、契约范围和边界。
-- 明确不负责的兄弟模块与上层装配职责。
-
-## Core Logic
-
-- 解释当前模块的主干实现路径。
-- 解释最关键的分层、能力点、处理链路或数据流。
-- 解释它更偏能力模块、业务模块还是集成模块。
-
-## Key Entry Points
-
-- 导出入口文件或主包路径
-- 关键源码目录与核心文件
-- 核心资源配置与测试入口
-
-## Usage And Change Notes
-
-- 新增接口、实体、任务或集成能力时，先确认主包路径下的核心分层归属，不要跨层堆逻辑。
-- 改核心逻辑、资源配置或内部依赖时，同步检查上游消费方和对应测试入口。
-- 如果当前模块被运行型应用装配，涉及对外行为变化时要回看装配层。
-
-## Dependencies And Collaboration
-
-- 列出直接内部依赖与直接消费方。
-- 说明当前模块如何被上层应用或兄弟模块使用。
-
-## Investigation Rule
-
-- 明确：先读 manifest，再读主源码路径下最关键的分层，再读资源配置与测试。
-- 如果本文件无法支撑排查，继续顺着依赖模块和消费方代码下钻。
-- 文档与代码冲突时以代码事实为准。
-
-## Core Commands
-
-- 当前模块的测试与构建命令。
-
-## Verification
-
-- 当前模块最小可执行校验。
-
-## Routing
-
-- 上级 manifest
-
-## References
-
-- manifest 文件
-- 主源码路径
-- 关键源码目录
-- 关键资源与测试入口

package/template/skills/docs-sync/references/agents/templates/contract-module-AGENTS.md

@@ -1,65 +0,0 @@
-# <module-name>
-
-## Scope
-
-- 说明当前契约/约束型 manifest 覆盖的目录范围。
-
-## Module Positioning
-
-- 标记当前角色为 `contract-module`。
-- 说明它负责依赖约束、版本对齐、类型契约、配置契约或导出契约。
-
-## Directory Structure
-
-- 列出直接子目录与关键文件。
-- 如果没有 `src/` 或主源码目录，要显式说明这是约束层而不是实现层。
-
-## Responsibilities
-
-- 说明当前模块约束了什么、暴露了什么。
-- 明确不负责运行时代码或业务处理。
-
-## Core Logic
-
-- 解释当前 manifest 如何提供依赖对齐、导入关系或契约出口。
-- 解释它由谁引用、为什么需要独立出来。
-
-## Key Entry Points
-
-- manifest 文件
-- 若存在类型定义、配置文件或导出文件，列出这些文件
-
-## Usage And Change Notes
-
-- 改版本约束、依赖管理或契约导出前，先确认直接消费它的模块。
-- 如果目录没有实现代码，要明确它仍然是约束层；不要补写成运行时代码模块。
-- 当改动会影响构建对齐或依赖传递时，同步检查根级或聚合层导读。
-
-## Dependencies And Collaboration
-
-- 说明父模块、子模块或消费方如何使用它。
-- 说明它不直接承载业务实现。
-
-## Investigation Rule
-
-- 明确：先读 manifest 的依赖管理、导入关系和导出方式。
-- 若要判断实际实现效果，继续进入引用它的消费模块源码。
-- 文档与代码冲突时以代码事实为准。
-
-## Core Commands
-
-- 当前模块的最小构建校验命令。
-
-## Verification
-
-- 当前模块最小可执行校验。
-
-## Routing
-
-- 上级 manifest
-
-## References
-
-- manifest 文件
-- 关键导出或配置文件
-- 主要消费方