aif-verify

Verify — 实施后的质量检查

验证已完成的实施是否符合计划、没有遗漏，并且代码已达到可用于生产环境的标准。

此技能为可选技能——在 /aif-implement 完成所有任务后调用，也可随时手动调用。

---

步骤 0：加载上下文

0.0 加载 config.yaml

**首先：**如果 .ai-factory/config.yaml 存在，请读取它以解析：

• 路径：paths.description、paths.architecture、paths.rules_file、paths.roadmap、paths.research、paths.plan、paths.plans、paths.fix_plan、paths.specs、paths.rules 和 paths.archive；派生 research_bundles_dir = <parent directory of paths.research>/research/
• **verify_mode：**默认验证严格程度（strict | normal | lenient）
• Git：git.enabled、git.base_branch、git.create_branches
• **规则层级：**解析后的 RULES.md 路径 + rules.base + 命名的 rules.<area> 条目
• **语言：**用于提示词、面向用户的说明、验证报告、上下文门控摘要、问题修复提示和后续步骤指引的 language.ui
• 工作流：workflow.plan_id_format（默认值：slug）——由第 0.2 步基于分支的计划发现使用。 有效值：slug 和 sequential。发现逻辑会将根目录中的 *.md 文件视为完整计划，但解析后的快速修复/修复路径除外；仅当直接子目录中的 */index.md 恰好包含一个 `` 时，才会将其视为精简入口。 若值为 sequential，搜索所有带编号的格式并选择前缀最大的项。 timestamp 和 uuid 是保留值，当前行为与 slug 相同。 遇到任何未知值时，均按 slug 处理。

verify_mode 优先级：

1. --strict CLI 标志 → 始终使用 strict
2. config.yaml 中的 workflow.verify_mode → 使用配置值
3. 默认值 → normal

如果 config.yaml 不存在，请使用默认值：

• 路径：所有产物均位于 .ai-factory/
• research：.ai-factory/RESEARCH.md
• verify_mode：normal
• 规则：仅 RULES.md
• ui_language：en
• workflow.plan_id_format：slug

解析后的语言值：

• ui_language = language.ui || "en"

所有 AskUserQuestion 提示、面向用户的说明、验证报告、上下文门控摘要、问题修复提示和后续步骤指引都必须使用 ui_language 编写。

保留机器可读的 aif-gate-result JSON 架构字段和枚举值（pass、warn、fail），不得更改。保留 WARN/ERROR 门控标签、命令、路径、配置键、代码标识符、包名、API 名称和原始命令输出，不得更改。

0.1 加载所有权与门控约定

• 首先阅读 references/CONTEXT-GATES-AND-OWNERSHIP.md。
• 阅读 references/GATE-RESULT-CONTRACT.md，了解机器可读的质量门控摘要。
• 将其视为以下内容的权威来源：
  • 命令与产物的所有权关系，
  • aif-commit/aif-review/aif-verify 的只读行为，
  • normal 与 strict 的上下文门控阈值。
• 如果此约定与本文档中的旧示例冲突，请遵循此约定。

0.2 查找计划产物

逻辑与 /aif-implement 相同——在对 plans 目录执行任何 glob 之前，先生成规范的分支词干，以确保生产方和使用方从设计上保持一致。

1. Check current git branch:
   git branch --show-current
2. Convert branch to filename stem (git mode only):
   branch_stem = current branch with every "/" replaced by "-"
   Example: feature/user-auth → feature-user-auth
3. Resolve the plan artifact using <branch_stem>:
   → When `workflow.plan_id_format = sequential`, glob both
       <configured plans dir>/[0-9][0-9][0-9][0-9]_<branch_stem>.md
       <configured plans dir>/[0-9][0-9][0-9][0-9]_<branch_stem>/index.md
     Read every directory candidate and retain it only when `index.md` contains
     exactly one . Choose the highest prefix across
     valid artifacts and warn when multiple valid candidates exist; prefer ultra
     if both shapes share the highest prefix.
   → Otherwise/fallback check the ultra entrypoint and full file:
       <configured plans dir>/<branch_stem>/index.md
       <configured plans dir>/<branch_stem>.md
     Read the directory entrypoint before selection and ignore it unless it
     contains exactly one . If both valid shapes
     exist, warn and prefer ultra.
4. If the branch-based plan is missing or git mode is off:
   → Count root `*.md` full plans and declared-ultra direct child `*/index.md`
     entrypoints as artifacts; exclude resolved fast/fix paths and do not count
     phase files
   → If exactly one exists, use it
   → If multiple exist, ask the user to choose or use `@<path>` via `/aif-implement`
5. No named full/ultra plan → Check the resolved fast plan path
6. No regular plan and no resolved fast plan → fall back to standalone verification choices

**注意：**计划发现仅扫描 paths.plans/。/aif-archive 归档到 paths.archive/plans/ 的计划不会纳入发现范围。如果只在归档中找到计划，则发出 WARN [aif-verify] plan <name> is archived; verifying archived plan。

如果未找到计划产物：

AskUserQuestion: No plan artifact found. What should I verify?

Options:
1. Verify last commit — Check the most recent commit for completeness
2. Verify branch diff — Compare current branch against the configured base branch
3. Cancel

0.3 阅读计划和任务

• 阅读选定的计划入口文件，了解原本要实现的内容
• 自动发现的目录入口文件只有在其中包含 `` 时才是计划；忽略无关的 */index.md 文件。
• 对于 ultra，在验证前检查所有 Phase Index 链接，并阅读每个链接指向的阶段文件。验证实现时，应对照每项任务的详细接口、边界情况、日志记录、验收标准和命令，而不只是 index.md 中简短的复选框文本。缺失、失效或指向目录外部的阶段链接属于阻断性计划完整性故障，因为已提交的规范不完整。
• 将 index.md 中的每个 Task N 与其链接阶段文件中恰好一个匹配的 ## Task N 小节交叉核对。未映射的任务、重复的任务小节以及未链接的 phase-*.md 文件，均属于阻断性计划完整性故障。
• TaskList → 获取所有任务及其状态
• 阅读 .ai-factory/DESCRIPTION.md（使用配置中的路径）以了解项目背景（技术栈、约定）
• 阅读 .ai-factory/ARCHITECTURE.md（使用配置中的路径）以了解依赖和边界规则（如果存在）
• 阅读规则层级（使用配置中的路径）：
  1. RULES.md — 公理（项目通用规则）
  2. rules/base.md — 项目专属的基础约定
  3. rules. — 从配置解析出的领域专属规则条目（例如 rules.api、rules.frontend）
• 阅读 .ai-factory/ROADMAP.md（使用配置中的路径）以检查里程碑是否一致（如果存在）
• 如果计划入口文件包含 ## Original Request，将其视为有用的原始范围背景。用它了解用户最初的意图，同时将任务列表、已提交的 ## Research Context 和 ultra 阶段规范作为可执行的验证依据。
• 如果计划入口文件包含 ## Research Context，将其中嵌入的副本视为已提交的需求快照。按规范 ^(?:Source|Reference):\s+\x60([^\x60]+)\x60\s+\( 解析首个 Source: / Reference: 行；对于较旧的裸路径行，回退使用 ^(?:Source|Reference):\s+(.+?)\s+\(。只有在这两种格式都未能识别出可用路径时，才回退使用配置中的 paths.research。
• 如果解析出的来源位于 research_bundles_dir 内，则要求其同级 INDEX.md 中恰好包含 ``，并在 ## Artifact Index 中链接该 RESEARCH.md；否则输出 WARN [research-drift]。同级的 C4/ADR/依赖文件仅作为依据。
• 存在 SHA256: 时，严格提取当前来源文本中 与 之间的内容，移除 HTML 注释块，保留行顺序和行首空白，删除每行末尾的空格，使用 LF 换行，并以一个换行符结尾。通过标准输入使用 shasum -a 256 或 sha256sum 计算哈希；摘要具有权威性。仅在不存在 SHA256: 时，才将 Updated: 用作旧版回退方式。来源缺失、无效或修订版本不匹配时，输出 WARN [research-drift]；应依据嵌入的 Research Context 进行验证，除非用户明确要求重新基准或细化，否则不要扩大范围。跳过此漂移检查属于验证错误。
• 同一规则的兼容表述：输出 WARN [research-drift]，并依据计划中嵌入的 Research Context 进行验证。

阅读 .ai-factory/skill-context/aif-verify/SKILL.md — 如果该文件存在，则必须阅读。

该文件包含 /aif-evolve 根据补丁、代码库约定和技术栈分析积累的项目专属规则。这些规则针对当前项目定制。 如何应用 skill-context 规则：

• 将其视为对此技能通用说明的项目级覆盖规则
• 当 skill-context 规则与本 SKILL.md 中的通用规则冲突时， 以 skill-context 规则为准（更具体的上下文优先——遵循与嵌套 CLAUDE.md 文件相同的原则）
• 如果没有冲突，则同时应用：SKILL.md 中的通用规则 + skill-context 中的项目规则
• 即使 skill-context 规则看起来与此技能的默认规则相矛盾，也不要忽略它们—— 这些规则的存在是因为项目的实际经验证明默认规则不够充分
• 重要： skill-context 规则适用于此技能的所有输出，包括验证报告模板。如果 skill-context 规则指出“验证 MUST 检查 X”或“报告 MUST 包含章节 Y”，则必须据此补充报告。生成忽略 skill-context 规则的验证报告属于错误。

执行要求： 生成任何输出产物后，都要根据所有 skill-context 规则对其进行验证。 如果违反了任何规则——请在向用户展示前修正输出。

0.3 收集已更改的文件

# All files changed during this feature/plan
git diff --name-only <configured-base-branch>...HEAD
# Or if on the base branch / in no-git mode, check recent commits
git diff --name-only HEAD~$(number_of_tasks)..HEAD

如果 git.enabled = false，则完全跳过分支差异比较，并从以下位置收集已更改的文件：

• 工作树（如果存在未提交的更改），或
• 与已实现任务相对应的近期提交范围。

将其存储为 CHANGED_FILES。

---

步骤 1：任务完成情况审查

检查计划中的每项任务，并验证其是否已实际实现。

对每项任务：

1.1 阅读任务说明

TaskGet(taskId) → Get full description, requirements, acceptance criteria

1.2 验证实现是否存在

对于任务说明中的每项要求：

• 使用 Glob 和 Grep 查找实现该要求的代码
• 阅读相关文件，确认实现完整
• 检查实现是否符合描述，而不仅仅是确认“写了点什么”

1.3 创建检查清单

针对每项任务，生成一项验证结果：

✅ Task #1: Create user model — COMPLETE
   - User model created at src/models/user.ts
   - All fields present (id, email, name, createdAt, updatedAt)
   - Validation decorators added

⚠️ Task #3: Add password reset endpoint — PARTIAL
   - Endpoint created at src/api/auth/reset.ts
   - MISSING: Email sending logic (task mentioned SendGrid integration)
   - MISSING: Token expiration check

❌ Task #5: Add rate limiting — NOT FOUND
   - No rate limiting middleware detected
   - No rate-limit related packages in dependencies

状态：

• ✅ COMPLETE — 已在代码中验证所有要求
• ⚠️ PARTIAL — 部分要求已实现，部分缺失
• ❌ NOT FOUND — 未检测到实现
• ⏭️ SKIPPED — 用户在实现过程中有意跳过了该任务

---

步骤 2：代码质量验证

2.1 构建与编译检查

检测构建系统并验证项目能否编译：

检测项	命令
go.mod	go build ./...
tsconfig.json	npx tsc --noEmit
含有 build 脚本的 package.json	npm run build（或 pnpm/yarn/bun）
pyproject.toml	对已更改文件运行 python -m py_compile
Cargo.toml	cargo check
composer.json	composer validate

如果构建失败 → 使用文件:行号引用报告错误。

2.2 测试检查

如果项目有测试，且测试属于计划的一部分：

检测项	命令
jest.config.* 或 vitest	npm test
pytest	pytest
go test	go test ./...
phpunit.xml*	./vendor/bin/phpunit
Cargo.toml	cargo test

如果测试失败 → 报告失败的测试，以及它们是否与已实现的任务有关。

如果不存在测试，或计划中明确跳过了测试 → 予以说明，但不判定为失败。

2.3 Lint 检查

如果已配置 lint 工具：

检测项	命令
eslint.config.* / .eslintrc*	npx eslint [changed files]
.golangci.yml	golangci-lint run ./...
pyproject.toml 中的 ruff	ruff check [changed files]
.php-cs-fixer*	./vendor/bin/php-cs-fixer fix --dry-run --diff

仅对已更改的文件运行 lint，以便让输出更聚焦。

2.4 导入与依赖检查

• 确认没有遗留未使用的导入
• 检查任务中提及的新依赖是否已实际添加（package.json、go.mod、requirements.txt、composer.json）
• 检查是否缺少依赖（导入了依赖文件中未列出的程序包）

---

步骤 3：一致性检查

3.0 需求来源与语义一致性

验证完整链路：权威需求 → 计划 → 实现 → 验证证据，而不仅仅是计划与代码的一致性。

1. 如果计划中包含 ## Requirements Reconciliation，请将引用解析到所选研究来源，并与嵌入其中的 ## Research Context 对照；除非用户明确要求重新基于计划，实时研究文件只用于检测偏差。重新阅读其他引用来源的相关内容。否则，使用原始请求、已提交的研究上下文、项目规则及其明确引用的权威来源。
2. 仅当用户或项目声明了来源优先级时，才遵循该层级。除非明确声明路线图文本是详细行为规范，否则应将其视为范围说明。如果来源之间存在冲突，且未声明权威来源，不要猜测：在常规或宽松模式下发出 WARN [requirement-ambiguity]，在严格模式下发出 ERROR [requirement-ambiguity]。
3. 实现与更高优先级需求之间存在明确矛盾时，属于 ERROR [requirement-conflict]，即使计划、代码和测试彼此一致，也会阻止验证。
4. 当行为取决于彼此独立的选择器、状态、模式或输入形态时，仅列举受支持的组合，并针对每种重要组合验证校验、持久化、输出／转换及副作用。对每个维度分别测试，不能证明它们之间的交互。
5. 当仓库数据、配置、固件、架构或内容定义了规范时，如果存在相关的代表性现有工件，应通过主要集成路径至少验证其中一个。

遵循计划中的测试设置。如果有意跳过测试，则使用静态检查以及计划中的可运行／手动验证证据；在常规模式下，将缺失的证据报告为警告，在严格模式下则报告为失败。

3.1 计划与代码偏差

检查计划描述与实际构建内容之间是否存在差异：

• 命名：变量／函数／端点名称是否与计划指定的一致？
• 文件位置：文件是否位于计划指定的位置？
• API 契约：端点路径、请求／响应结构是否与计划一致？

3.2 遗留工件

搜索本应清理的内容：

Grep in CHANGED_FILES: [T][O][D][O]|[F][I][X][M][E]|HACK|[X][X][X]|TEMP|PLACEHOLDER|console\.log\(.*debug|print\(.*debug

报告所有发现项——它们可能是有意保留的，但应予以标记。

3.3 配置与环境

检查实现是否引入了新的配置要求：

• 引用了但未记录的新环境变量
• 代码中提及但未创建的新配置文件
• 已创建但未在 README／docs 中记录的数据库迁移

Grep in CHANGED_FILES: process\.env\.|os\.Getenv\(|os\.environ|env\(|getenv\(|config\(

对照 .env.example、.env.local、README 或 docs，确保这些内容都有记录。

3.4 DESCRIPTION.md 同步

检查 .ai-factory/DESCRIPTION.md 是否反映当前状态：

• 实现过程中新增的依赖／库 → 应列出
• 架构变更 → 应反映
• 新集成 → 应记录

3.5 上下文门禁（架构 / 路线图 / 规则）

应用 references/CONTEXT-GATES-AND-OWNERSHIP.md 中的规范契约。

明确评估并报告每项门禁：

• 架构门禁

  • 通过：实现遵循文档规定的边界和依赖规则
  • 警告：架构映射含糊或已过时
  • 失败：明确违反了架构约束

• 规则门禁

  • 通过：实现遵循明确的项目规则
  • 警告：相关性或验证情况不明确
  • 失败：明确违反了规则文本

• 路线图门禁

  • 通过：工作与现有里程碑方向一致（如计划中有 ## Roadmap Linkage，优先参考）
  • 警告：缺少 .ai-factory/ROADMAP.md、映射含糊，或 feat/fix/perf 范围内的工作未关联里程碑
  • 失败（严格模式）：在考虑所有可用路线图上下文后，仍明确与路线图相矛盾

普通模式行为：

• 明确违反架构或规则时，验证失败。
• 路线图不匹配以及缺少里程碑关联均为警告，除非存在明确且严重的矛盾。

严格模式行为：

• 明确违反架构或规则时，验证失败。
• 明确与路线图不匹配时，验证失败。
• feat/fix/perf 范围内的工作缺少里程碑关联仍为警告（即使 .ai-factory/ROADMAP.md 存在）。

人工日志 / 报告格式：

• 非阻塞发现：WARN [gate-name] ...
• 阻塞发现：ERROR [gate-name] ...

如果用户希望单独执行仅检查规则的流程，建议使用 /aif-rules-check。上下文门禁的人类可读标签保持为 WARN / ERROR，然后根据完整验证报告得出最终机器可读的门禁结果。

机器可读的门禁结果：

• 在人类可读的验证报告后，追加一个最终的带围栏 aif-gate-result JSON 代码块。
• 使用 "gate": "verify"。
• 使用 "status": "pass|warn|fail"，其中：
  • fail = 必需任务未完成、阻塞性质量检查未通过、严格模式下的上下文门禁失败，或其他需要修复的阻塞项。
  • warn = 仅剩非阻塞警告、跳过了可选检查、接受文档 / 测试缺口作为警告，或上下文偏移情况含糊。
  • pass = 不存在阻塞或警告发现。
• 使用 "blocking": true|false；仅当结果应阻止提交或合并流程时，设为 true。
• "blockers": [ 中仅包含阻塞性发现；非阻塞说明保留在人类可读摘要中。
• "affected_files": [ 中包含已更改或涉及的路径。
• 根据 references/GATE-RESULT-CONTRACT.md，将 "suggested_next": { 设为 /aif-fix、/aif-rules、/aif-architecture、/aif-roadmap、/aif-commit 或 null。

3.6 上下文偏移（可选修复）

/aif-verify 对上下文资源为只读。此处不得编辑或重新生成 .ai-factory/* 文件。

如果发现上下文资源已过时、缺失或含糊，请将其报告为偏移问题，并提供负责者命令以进行修复：

• DESCRIPTION.md 偏移 → 建议使用 /aif（或注明 /aif-implement 本应在实现期间更新它）
• ARCHITECTURE.md 偏移 → 建议使用 /aif-architecture
• ROADMAP.md 偏移 → 建议使用 /aif-roadmap check（或 /aif-roadmap <update request>）
• RULES.md 偏移 → 建议使用 /aif-rules <rule text>

只有在检测到偏移，且立即修复能实质性提升正确性时，才向用户提出一个可选问题：

AskUserQuestion: Context drift detected. Capture updates now?

Options:
1. Yes — show the exact commands to run (recommended)
2. No — proceed without updating context

---

第 4 步：验证报告

4.1 显示结果

使用 ui_language 撰写人类可读的验证报告。以下模板仅定义结构；保持稳定的技术标记和最终 aif-gate-result JSON 架构不变。

## Verification Report

### Task Completion: 7/8 (87%)
| # | Task | Status | Notes |
|---|------|--------|-------|
| 1 | Create user model | ✅ Complete | |
| 2 | Add registration endpoint | ✅ Complete | |
| 3 | Add password reset | ⚠️ Partial | Missing: email sending |
| 4 | Add JWT auth middleware | ✅ Complete | |
| 5 | Add rate limiting | ✅ Complete | |
| 6 | Add input validation | ✅ Complete | |
| 7 | Add error handling | ✅ Complete | |
| 8 | Update API docs | ❌ Not found | No changes in docs/ |

### Code Quality
- Build: ✅ Passes
- Tests: ✅ 42 passed, 0 failed
- Lint: ⚠️ 2 warnings in src/api/auth/reset.ts

### Requirements Consistency
- Source reconciliation: ✅ Passes
- Supported combinations: ✅ Covered
- Representative artifact path: ✅ Verified / ⏭️ Not applicable

### Issues Found
1. **Task #3 incomplete** — Password reset endpoint created but email sending not implemented (SendGrid integration missing)
2. **Task #8 not done** — API documentation not updated despite plan requirement
3. **2 unfinished markers found** — src/services/auth.ts:45, src/middleware/rate-limit.ts:12
4. **New env var undocumented** — `SENDGRID_API_KEY` referenced but not in .env.example

### No Issues
- All imports resolved
- No unused dependencies
- DESCRIPTION.md up to date
- No leftover debug logs

4.2 确定总体状态

• 全部通过 — 所有内容均已验证，没有问题
• 轻微问题 — 存在可以快速修复的小缺口
• 重大缺口 — 任务缺失或部分完成，需要重新实现

4.2.1 追加机器可读的门禁结果

在人类可读报告和总体状态之后，追加且仅追加一个最终的 aif-gate-result fenced JSON 块。

{
  "schema_version": 1,
  "gate": "verify",
  "status": "pass",
  "blocking": false,
  "blockers": [],
  "affected_files": [],
  "suggested_next": {
    "command": "/aif-commit",
    "reason": "Verification passed without blockers."
  }
}

Schema 提醒："status": "pass|warn|fail"、"blocking": true|false、"blockers": [、"affected_files": [、"suggested_next": {。

4.3 问题处理方式

如果发现问题：

AskUserQuestion: Verification found issues. What should we do?

Options:
1. Fix now (recommended) — Use /aif-fix to address all issues
2. Fix critical only — Use /aif-fix for incomplete tasks, skip warnings
3. Fix directly here — Address issues in this session without /aif-fix
4. Accept as-is — Mark everything as done, move on

如果选择“立即修复”或“仅修复关键问题”：

• 首先建议使用 /aif-fix，并将简洁的问题摘要作为参数传入
• 示例：
  • /aif-fix complete Task #3 password reset email flow, implement Task #8 docs update, remove unfinished markers in src/services/auth.ts and src/middleware/rate-limit.ts, document SENDGRID_API_KEY in .env.example
• 如果用户同意，则通过 /aif-fix 继续
• 如果用户拒绝使用 /aif-fix，则在本次会话中直接实施
• 对于每个未完成或部分完成的任务，实施缺失部分（遵循与 /aif-implement 相同的实施规则）
• 清理未完成标记和调试产物
• 对于未记录的配置，更新 .env.example 和文档
• 修复后，重新运行相关验证检查以确认

如果选择“按现状接受”：

• 在计划入口文件中以注释形式记录已接受的问题
• 继续执行步骤 5

---

步骤 5：建议后续技能

验证完成后，根据结果建议后续步骤：

• 如果仍有未解决的问题（已接受或延期），首先建议使用 /aif-fix
• 如果全部通过，则建议进行安全、审查和提交流程

## Verification Complete

Suggested next steps:

1. 🛠️ /aif-fix [issue summary] — Fix remaining verification issues
2. 🔒 /aif-security-checklist — Run security audit on the new code
3. 👀 /aif-review — Code review of the implementation
4. 💾 /aif-commit — Commit the changes

Which would you like to run? (or skip all)

AskUserQuestion: Run additional checks?

Options:
1. Fix issues — Run /aif-fix with verification findings
2. Security check — Run /aif-security-checklist on changed files
3. Code review — Run /aif-review on the implementation
4. Both — Run security check, then code review
5. Skip — Proceed to commit

如果选择修复问题 → 建议调用 /aif-fix <issue summary> 如果选择安全检查 → 建议调用 /aif-security-checklist 如果选择代码审查 → 建议调用 /aif-review 如果两者都选 → 建议先进行安全检查，再进行审查 如果跳过 → 建议使用 /aif-commit

上下文清理

如有需要，建议用户释放上下文空间：使用 /clear（完全重置）或 /compact（压缩历史记录）。

---

严格模式

使用 --strict 调用时：

/aif-verify --strict

• 所有任务都必须完成——不允许部分完成或跳过
• 构建必须通过——如果构建失败，则验证失败
• 测试必须通过——如果任何测试失败，则验证失败（严格模式下必须运行测试）
• Lint 必须通过——零警告、零错误
• 变更文件中不得有未完成任务标记
• 不得有未记录的环境变量
• 架构门禁必须通过——发现明确的边界或依赖违规时，验证失败
• 规则门禁必须通过——发现明确的规则违规时，验证失败
• 路线图门禁必须通过——发现明确的路线图不匹配时，验证失败
• 需求一致性门禁必须通过——存在明确的需求冲突、未解决的源信息歧义，或缺少对重要受支持组合的证据时，验证失败
• 即使在严格模式下，feat/fix/perf 缺少里程碑关联也只是警告
• 不得仅因缺少里程碑关联而判定严格验证失败

建议在合并到配置的基础分支或创建拉取请求之前使用严格模式。

---

用法

实施后（自动建议）

/aif-verify

合并前的严格模式

/aif-verify --strict

独立使用（无计划，验证分支差异）

/aif-verify
→ No plan found → verify branch diff against the configured base branch