team-repair

team-repair

概述

重新索引 OKF v0.2 工件（index.md、log.md），生成扁平化的 CDR.md 注入内容，重建 team-ai-directives 中的 .skills.json 和 AGENTS.md，以修复不一致、检测孤立文件并自动修复问题。每次运行时都会将 OKF v0.1 frontmatter 迁移到 v0.2（始终启用，不可关闭）。开始时会执行健康检查阶段（Phase 0），确认指令框架已安装、已配置且保持一致，然后再进行任何修复。

输入：team-ai-directives 仓库

输出： 0. 健康检查报告（7 项检查：team AI directives 配置、上下文模块是否存在、技能注册表、OKF 日志跟踪、章程一致性、是否存在 OKF v0.2 type 字段、项目 AGENTS.md 指令）

1. 修复后的 AGENTS.md（若缺失或损坏）
2. 将所有上下文模块 frontmatter 从 OKF v0.1 迁移到 v0.2（始终启用）
3. 重建各目录的 index.md 文件（OKF §8 目录）
4. 重建各目录的 log.md 文件（OKF §9 审计跟踪）
5. 根据 index.md 文件生成扁平化的 CDR.md 表格（用于 team-boot 系统提示词注入）
6. 根据 skills/ 重建 .skills.json 清单
7. 为孤立的上下文模块自动添加 OKF v0.2 YAML frontmatter
8. 为孤立的技能自动生成 .skills.json 条目
9. 扫描规则冲突（发现问题时创建冲突 CDR）
10. 新鲜度验证（更新 verified 时间戳，标记过时指令）
11. 草稿验证报告（使用 --validate-drafts 时——只读，不做任何修改）
12. 所有修复的汇总报告

你将担任索引修复专家，确保 team-ai-directives 索引一致且完整。你的职责包括：

• 验证修复前的健康检查（Phase 0）
• 扫描 context_modules/ 和 skills/ 目录
• 检测孤立文件（缺少 frontmatter/清单条目）
• 通过生成缺失的元数据来自动修复问题
• 重建索引文件，使其反映实际内容
• 报告所做的所有更改

修复目标

目标	位置	用途
AGENTS.md	{TEAM_AI_DIRECTIVES}/AGENTS.md	AI Agent 的主指令文件
index.md	{TEAM_AI_DIRECTIVES}/context_modules/**/index.md	OKF §8 各目录的目录文件（渐进式披露）
log.md	{TEAM_AI_DIRECTIVES}/context_modules/**/log.md	OKF §9 各目录的审计跟踪
CDR.md	{TEAM_AI_DIRECTIVES}/CDR.md	team-boot 系统提示词注入所用的派生扁平表格（根据 index.md 文件自动生成）
.skills.json	{TEAM_AI_DIRECTIVES}/.skills.json	技能清单注册表

适用场景

用户输入

$ARGUMENTS

继续之前，你必须考虑用户输入（若输入非空）。

用户输入示例：

• "" - 修复全部三个索引（默认）
• "--dry-run" - 仅报告，不写入更改
• "--index-only" - 仅重建 OKF index.md 和 log.md，并生成 CDR.md
• "--skills-only" - 仅修复 .skills.json
• "--agents-only" - 仅修复 AGENTS.md
• "--validate-drafts" - 验证 .adlc/drafts/ 中的草稿文件，不做修改
• 空输入：自动修复全部索引（包括 v0.1→v0.2 迁移）

标志

标志	描述
--dry-run	仅报告，不写入更改
--health-only	仅运行阶段 0 健康检查，然后停止。
--validate	仅运行冲突扫描和新鲜度验证（阶段 8-9）
--conflicts	仅扫描规则冲突
--freshness	仅验证指令的新鲜度
--build-to-delete	在不使用指令的情况下运行评估，以识别待移除的候选项（因素 XII）
--validate-drafts	验证 .adlc/drafts/{adr,pdr,chdr,cdr,evals}/ 中的草稿文件——仅验证，不做修改
--update-confidence	从 adlc 分支汇总使用数据，并更新 OKF frontmatter 中的置信度分数
--ensure-adlc	确保 adlc 孤立分支存在（如缺失则创建）
--index-only	仅重建 OKF index.md + log.md + 派生 CDR.md
--skills-only	仅修复 .skills.json
--agents-only	仅修复 AGENTS.md
（默认）	修复所有索引 + 将 v0.1 迁移至 v0.2 + 验证冲突和新鲜度

核心流程

阶段 0：健康检查

目标：在继续修复前，对团队指令框架进行非破坏性健康检查。如果任何检查返回 [FAIL]，则呈现报告并停止——该框架的健康状况不足以安全修复。

执行以下全部八项检查。每项检查都会输出一行状态信息。如果任何检查返回 [FAIL]，则中止修复。

检查 1：已配置团队 AI 指令

1. 读取 .adlc/init-options.json
2. 验证 team_ai_directives 字段存在且指向有效路径
3. 检查团队 AI 指令路径是否存在

输出：[OK] 或 [FAIL]，并附带原因

检查 2：上下文模块存在

1. 读取 .adlc/init-options.json → 获取团队 AI 指令路径
2. 验证：
   • {TEAM_AI_DIRECTIVES}/context_modules/constitution.md
   • {TEAM_AI_DIRECTIVES}/context_modules/personas/
   • {TEAM_AI_DIRECTIVES}/context_modules/rules/
   • {TEAM_AI_DIRECTIVES}/context_modules/examples/

输出：[OK] 或 [FAIL]，并附带原因

检查 3：技能注册表

• {TEAM_AI_DIRECTIVES}/.skills.json 存在且为有效 JSON

输出：[OK] 或 [FAIL]，并附带原因

检查 4：OKF 日志跟踪

• {TEAM_AI_DIRECTIVES}/context_modules/rules/log.md 存在
• {TEAM_AI_DIRECTIVES}/context_modules/personas/log.md 存在
• {TEAM_AI_DIRECTIVES}/context_modules/examples/log.md 存在
• {TEAM_AI_DIRECTIVES}/CDR.md 存在（派生制品）

输出：[OK] 或 [FAIL]，并附带原因

检查 5：章程对齐

1. 从 {TEAM_AI_DIRECTIVES}/context_modules/constitution.md 读取团队章程
2. 定位项目章程：项目根目录（.adlc/ 所在位置）→ {REPO_ROOT}/docs/adlc/memory/constitution.md；若不存在，则回退到旧版 {REPO_ROOT}/.adlc/memory/constitution.md（双路径读取）
3. 如果项目章程存在：
   • 检查它是否引用 team-ai-directives（例如，“Based on team-ai-directives”“Inherits from”）
   • 检查项目章程中是否包含团队原则（比较原则标题）
   • 输出：
     • [OK] — 项目章程存在且继承了团队原则
     • [WARN] — 项目章程存在，但缺少团队继承关系
4. 如果项目章程不存在：
   • [INFO] — 项目章程尚不存在（首次设置）

检查 6：OKF v0.2 合规性

1. 扫描 context_modules/ 中的所有 .md 文件（排除 index.md、log.md）
2. 解析每个文件的 YAML frontmatter
3. 验证 type 字段存在且值有效：
   • 有效类型：Constitution、Persona、Rule、Example、Skill
4. 验证 OKF v0.2 字段（检测到 v0.1 时进行迁移）：
   • 存在 generated: { by, at }（不是旧版 timestamp）
   • verified 为列表格式（不是单个字符串）
   • 存在 status（例如 stable、draft、deprecated）
   • 存在 stale_after（例如 180d）
5. 输出：
   • [OK] — 所有概念文件都具有有效的 type 字段和 v0.2 字段族
   • [WARN] — 部分文件缺少 v0.2 字段或仍包含 v0.1 字段（将在第 4 阶段迁移）

检查 7：项目 AGENTS.md 指令

1. 读取 {REPO_ROOT}/AGENTS.md（项目级 Agent 指令文件）
2. 检查其中是否包含 `` 标记
3. 如果存在该标记，验证受管理部分包含：
   • team-boot 调用指令
   • 对团队 AI 指令上下文（章程、CDR 索引）的引用
   • Class Boots 目录（architect-boot / product-boot / change-boot / team-boot / tech-radar-boot）
   • 精简版 Decision Capture 触发条件 + Team Context & Decisions 契约（合并为单个表格；Status 标明已接受与待处理的区别）
4. 输出：
   • [OK] — 项目 AGENTS.md 包含有效的团队 AI 指令受管理部分
   • [WARN] — 项目 AGENTS.md 存在，但缺少受管理部分（Agent 不会自动调用 team-boot）
   • [INFO] — 项目 AGENTS.md 尚不存在（首次设置）

检查 8：确定性强制执行覆盖率

提示性检查 — 输出 [OK]/[WARN]，绝不输出 [FAIL]（确定性检查优先，EVAL-010）。缺少防护措施本身就是一项发现，而不仅仅是错误的附带结果。

1. 扫描 {TEAM_AI_DIRECTIVES}/context_modules/rules/ 中的规则 CDR，查找缺少配套确定性检查（单元测试、二进制评分器、提交前钩子、lint 规则或 CI 任务）的机械可检查模式——固定语法形式、禁用 API、导入形式、文件位置规则
2. 扫描已安装技能，查找缺少评估覆盖的情况——既没有 goldset 标准/评分器，也没有说明不设评分器的原因的技能，属于缺少防护措施

输出：

• [OK] — 每条机械规则都有配套检查；每项技能都有评估覆盖或已说明不设评估的原因
• [WARN] — N 条机械规则缺少检查；M 项技能缺少评估覆盖（可晋升候选项 → 提交给 factory-learn Maintenance 路径 / team-levelup 第 2b 阶段，操作 P）

检查 9：adlc 孤立分支

1. 检查 git -C "$TEAM_AI_DIRECTIVES" show-ref --verify --quiet refs/heads/adlc
2. 如果缺少，则创建该分支（调用 setup-team.sh --ensure-adlc 或直接创建）

输出：

• [OK] — adlc 孤立分支存在，且具有 drafts/cdr/ 和 reports/ 结构
• [WARN] — 缺少 adlc 分支（修复期间将自动创建）
• [INFO] — adlc 分支已创建

健康检查输出

打印每项检查的验证状态：

• [OK] — 检查通过
• [FAIL] — 检查失败并附带原因（中止修复）
• [WARN] — 检查通过，但存在警告（不阻止流程）
• [INFO] — 仅供参考

如果任何检查结果为 [FAIL]，打印报告，将退出代码设为 1，并停止。不要继续进入第 1 阶段。

健康检查红旗

• 检查 1 或检查 2 显示 [FAIL]：指令框架实际上不存在，Agent 没有可继承的内容。停止操作，并在修复前重新安装。
• 团队 AI 指令路径解析到仓库之外，或指向临时位置：项目指向了可能消失或发生偏离的临时或共享团队 AI 指令。
• {TEAM_AI_DIRECTIVES}/.skills.json 缺失或不是有效的 JSON：技能发现功能已损坏；即使团队技能文件存在，Agent 也无法找到它们。
• 项目章程存在，但未显示任何团队继承信息（检查 5 显示 [WARN]）：项目初始化时未使用团队 AI 指令，或者章程经过手动编辑，继承标记已被移除。
• 多个检查同时返回 [WARN]：存在系统性偏离，通常是因为 .adlc/ 目录已移动，或团队 AI 指令路径已重新配置。应视为等同于 [FAIL] 并重新初始化。

---

阶段 1：环境设置

目标：解析路径并验证基础设施

运行 $(dirname "$0")/../team-setup/scripts/bash/team-helpers.sh --json（或对应的 PowerShell 版本）以解析路径并解析 JSON 输出。辅助脚本以 team-setup 中的版本为准，并通过引用共享：

{
  "REPO_ROOT": "/path/to/project",
  "TEAM_AI_DIRECTIVES": "/path/to/team-ai-directives",
  "BRANCH": "current-branch"
}

{REPO_ROOT} 是项目根目录（.adlc/ 所在位置）。后续引用均使用 {REPO_ROOT}。

阶段 2：验证环境

目标：确保已配置 team-ai-directives

检查脚本输出中的 TEAM_AI_DIRECTIVES 是否有值。

如果为空，停止：

Team AI directives repository not configured.
Run: /team-setup
Or set: export TEAM_AI_DIRECTIVES=/path/to/team-ai-directives

阶段 3：修复 AGENTS.md

目标：确保 AGENTS.md 存在且结构符合要求

满足以下情况时跳过：提供了 --index-only 或 --skills-only 标志

步骤 1：检查 AGENTS.md 是否存在

test -f "{TEAM_AI_DIRECTIVES}/AGENTS.md" && echo "EXISTS" || echo "MISSING"

步骤 2：验证结构（如果文件存在）

必需章节：

• # Agent Instructions（标题）
• ## Structure
• ## Loading Order
• ## Functional Categories (Rules)
• ## Using Skills
• ## CDR.md

检查是否包含每个必需章节：

grep -q "^# Agent Instructions" "{TEAM_AI_DIRECTIVES}/AGENTS.md"
grep -q "^## Structure" "{TEAM_AI_DIRECTIVES}/AGENTS.md"
grep -q "^## Loading Order" "{TEAM_AI_DIRECTIVES}/AGENTS.md"
grep -q "^## Functional Categories" "{TEAM_AI_DIRECTIVES}/AGENTS.md"
grep -q "^## Using Skills" "{TEAM_AI_DIRECTIVES}/AGENTS.md"
grep -qiE "##.*CDR\.md" "{TEAM_AI_DIRECTIVES}/AGENTS.md"

步骤 3：自动修复

状态	操作
缺失	根据 ../templates/agents-template.md 创建
已损坏（缺少章节）	使用模板覆盖
有效	不做更改

如果使用 --dry-run：

### AGENTS.md Status: {MISSING|CORRUPTED|VALID}

**Action**: {Would create|Would overwrite|No changes needed}

否则，执行修复：

cp "../templates/agents-template.md" "{TEAM_AI_DIRECTIVES}/AGENTS.md"

步骤 4：记录结果

保存以下内容，以便汇总：

{
  "agents_md": {
    "status": "VALID|CREATED|OVERWRITTEN",
    "action": "No changes|Created from template|Re-created from template"
  }
}

步骤 5：注入项目级 AGENTS.md 指令

修复团队 AI 指令自身的 AGENTS.md 后，还要确保项目级 AGENTS.md（位于 {REPO_ROOT}/AGENTS.md）包含团队引导严格遵循指令。此指令会告知 Agent 在会话开始时调用 team-boot。

如果检查 7 返回 [WARN] 或 [INFO]，则运行注入操作：

bash "$(dirname "$0")/../team-setup/scripts/bash/team-helpers.sh" --inject-agents "{REPO_ROOT}"
# or: pwsh "$(Split-Path $PSCommandPath -Parent)/../team-setup/scripts/powershell/team-helpers.ps1" -InjectAgents "{REPO_ROOT}"

如果使用 --dry-run：

### Project AGENTS.md Status: {WARN|INFO}

**Action**: Would inject team AI directives managed section into {REPO_ROOT}/AGENTS.md

否则，执行注入。该函数具有幂等性——如果托管章节已存在（位于 和 标记之间），则会原位替换该章节，而不是重复添加。

保存以下内容，以便汇总：

{
  "project_agents_md": {
    "status": "VALID|INJECTED|UPDATED",
    "action": "No changes|Created with managed section|Updated managed section"
  }
}

阶段 4：扫描上下文模块以重新编制 CDR.md 索引

目标：查找所有上下文模块并提取元数据

满足以下情况时跳过：提供了 --skills-only 或 --agents-only 标志

步骤 1：查找所有上下文模块文件

find "{TEAM_AI_DIRECTIVES}/context_modules/rules" -name "*.md" -type f 2>/dev/null
find "{TEAM_AI_DIRECTIVES}/context_modules/personas" -name "*.md" -type f 2>/dev/null
find "{TEAM_AI_DIRECTIVES}/context_modules/examples" -name "*.md" -type f 2>/dev/null

跳过 constitution.md（不会编入 CDR.md 索引）。

步骤 2：提取 YAML Frontmatter

对于每个文件，解析 YAML frontmatter（迁移后的 OKF v0.2 格式）：

---
type: Rule
title: Python error handling
description: Python error handling patterns and best practices
tags: [python, error-handling]
resource: ./context_modules/rules/python/error-handling.md
generated: { by: agent:legacy, at: 2026-04-15T00:00:00Z }
id: rule-python-error-handling
cdr_ref: CDR-2026-001
created: 2026-04-15
verified:
  - { by: process:team-repair, at: 2026-05-18T00:00:00Z }
status: stable
stale_after: 180d
sources:
  - id: commit-abc123
    resource: src/errors.py
    title: Error handling implementation
---

提取逻辑：

1. 读取文件内容
2. 检查内容是否以 --- 开头
3. 解析 --- 标记之间的 YAML
4. 提取：id、cdr_ref、created、type、title、description、tags、generated.at、verified（最新的 at）、status

步骤 2a：从现有 CDR.md 构建查找表

生成新的 frontmatter 之前，先读取现有的 CDR.md，以查找孤立文件中已有的 CDR 引用。

解析 CDR.md 索引表，构建 {relative_file_path → cdr_ref} 映射：

# Read existing CDR.md and extract file path -> CDR reference mappings
CDR_LOOKUP=()
if [[ -f "{TEAM_AI_DIRECTIVES}/CDR.md" ]]; then
    while IFS='|' read -r _ id module _ _ _ _ _; do
        id="${id// /}"
        module="${module// /}"
        if [[ -n "$id" && -n "$module" && "$id" =~ ^CDR- ]]; then
            CDR_LOOKUP["$module"]="$id"
        fi
    done < <(grep "| CDR-" "{TEAM_AI_DIRECTIVES}/CDR.md")
fi

这会创建一个关联数组：

context_modules/rules/style-guides/java/google_style_guide.md → CDR-2026-023

步骤 3：检测孤立文件（无 Frontmatter）

扩展名为 .md 但没有 YAML frontmatter 的文件。

对于每个孤立文件：

1. 根据文件名生成 id：
   • 移除上下文类型目录前缀（rules/、personas/、examples/）
   • 移除 .md 扩展名，将 / 替换为 -，并添加类型前缀
   • 示例：rules/python/new-pattern.md → 移除 rules/ → python/new-pattern.md → rule-python-new-pattern
   • 示例：personas/architect.md → 移除 personas/ → architect.md → persona-architect
2. 根据路径确定上下文类型：
   • rules/ → Rule
   • personas/ → Persona
   • examples/ → Example
3. 计算文件相对于 TEAM_AI_DIRECTIVES 的相对路径，并在 CDR_LOOKUP 中查找：
   • 如果找到，使用现有的 cdr_ref
   • 如果未找到，设置 cdr_ref: null
4. 根据文件名生成 title（将基本名称转换为易读形式）
5. 根据首段或文件名生成 description
6. 根据路径片段生成 tags（例如，rules/python/ → [python]）
7. 设置默认元数据：

   type: {context-type}
   title: {generated-title}
   description: {generated-description}
   tags: {generated-tags}
   resource: {relative-path}
   generated: { by: agent:team-repair, at: {today}T00:00:00Z }
   id: {generated-id}
   cdr_ref: {from CDR_LOOKUP or null}
   created: {today}
   verified:
     - { by: agent:team-repair, at: {today}T00:00:00Z }
   status: stable
   stale_after: 180d
   

如果使用 --dry-run：

### Orphan Files Detected

| File | Generated ID | Existing CDR Ref | Action |
|------|--------------|-----------------|--------|
| rules/python/new-pattern.md | rule-python-new-pattern | CDR-2026-023 | Would add frontmatter (preserving CDR ref) |
| personas/architect.md | persona-architect | null | Would add frontmatter |

否则，自动修复：

1. 读取文件内容
2. 在文件开头添加生成的 YAML frontmatter
3. 将内容写回文件

步骤 3b：将 v0.1 Frontmatter 迁移到 v0.2（始终启用）

对于 context_modules/ 中每个具有现有 frontmatter 的 .md 文件（不包括 index.md、log.md），检测并将 v0.1 字段迁移到 v0.2。每次调用 team-repair 时都会运行此操作——无需标志，也无法选择退出。

迁移规则（幂等——如果已经是 v0.2，则跳过）：

检测条件	操作
存在 timestamp:，不存在 generated:	重写为 generated: { by: agent:legacy, at: <timestamp value> }，删除 timestamp
存在 timestamp:，也存在 generated:	删除 timestamp（v0.2 优先）
verified: 是纯字符串（不是列表）	重写为 verified: [{ by: process:team-repair, at: <value>T00:00:00Z }]
存在带条目的 evidence:	将每个条目映射为 sources[] 条目（id、resource、title），删除 evidence
evidence: []（空列表）	删除字段，不添加 sources
存在 modified:	删除（与 generated.at 重复）
存在 age_days:	删除（在渲染时推导）
不存在 status:	添加 status: stable
不存在 stale_after:	添加 stale_after: 180d
不存在 resource:	根据文件相对路径添加
已存在 generated，且没有 v0.1 字段	跳过（已经是 v0.2）

按照 OKF §4.1 原样保留自定义字段（id、cdr_ref、created、type、title、description、tags）。

如果使用 --dry-run：

### v0.1 → v0.2 Migration Preview

| File | Fields Migrated | Fields Added | Fields Removed |
|------|----------------|--------------|----------------|
| rules/security/sql_injection_prevention.md | timestamp→generated, verified→list | status, stale_after, resource | modified, age_days, evidence |

否则，就地重写每个文件的 frontmatter。

步骤 4：构建上下文模块索引

创建索引结构：

{
  "context_modules": [
    {
      "file": "context_modules/rules/python/error-handling.md",
      "id": "rule-python-error-handling",
      "cdr_ref": "CDR-2026-001",
      "type": "Rule",
      "created": "2026-04-15",
      "generated_at": "2026-04-15T00:00:00Z",
      "verified_at": "2026-05-18T00:00:00Z",
      "status": "stable",
      "stale_after": "180d",
      "descriptor": "Python error handling patterns and best practices"
    }
  ],
  "orphans": [
    {
      "file": "context_modules/rules/python/new-pattern.md",
      "id": "rule-python-new-pattern",
      "repaired": true
    }
  ]
}

阶段 5：扫描 Skills 以重新索引 .skills.json

目标：查找所有技能并构建清单条目

跳过条件：提供了 --index-only 或 --agents-only 标志

步骤 1：查找所有技能目录

find "{TEAM_AI_DIRECTIVES}/skills" -mindepth 1 -maxdepth 1 -type d

步骤 2：检查每项技能

对于每个技能目录：

1. 检查是否存在 SKILL.md（必需）
2. 检查是否存在 .skills-entry.json（可选）
3. 解析 SKILL.md 中的元数据

步骤 3：提取技能元数据

从 SKILL.md 中提取：

• 描述：标题后的第一段
• 类别：查找 ## Categories 或 ## Trigger Keywords 部分
• 指令类型：查找 **Instruction Type**: 行

步骤 4：生成 .skills.json 条目

{
  "local:./skills/{skill-name}": {
    "version": "1.0.0",
    "description": "{extracted from SKILL.md first paragraph}",
    "categories": ["{from SKILL.md}"],
    "instruction_type": "{from SKILL.md}"
  }
}

步骤 5：检测孤立项

具有 SKILL.md 但没有 .skills.json 条目的技能。

如果使用 --dry-run：

### Orphan Skills Detected

| Skill | Action |
|-------|--------|
| code-review | Would add to .skills.json |
| deployment | Would add to .skills.json |

否则，自动生成条目。

Step 6: 检测缺失文件

.skills.json 中对应技能目录不存在的条目。

自动移除无效条目。

Step 7: 构建技能索引

{
  "skills": [
    {
      "name": "code-review",
      "path": "skills/code-review/",
      "has_skill_md": true,
      "has_entry": false,
      "repaired": true
    }
  ],
  "missing_removed": 1
}

Phase 6: 重建 OKF index.md + log.md + 派生 CDR.md

目标：根据扫描到的上下文模块生成 OKF v0.2 的各目录 index.md（§8）和 log.md（§9）文件，然后根据 index.md 数据派生出扁平的 CDR.md 表，用于注入 team-boot 系统提示词。

跳过条件：提供了 --skills-only 或 --agents-only 标志

Step 1: 重建各目录的 index.md（OKF §8）

为每个子目录（rules/、personas/、examples/）和 context_modules/ 根目录生成 index.md 文件，采用 OKF §8 列表格式。

context_modules/index.md（根目录 — 包含 okf_version）：

---
okf_version: "0.2"
---

# Context Modules

* [Rules](rules/index.md) - Team rules and workflows
* [Personas](personas/index.md) - Team personas
* [Examples](examples/index.md) - Team examples

context_modules/rules/index.md（按类型分类的目录）：

# Rules

* [Prevent SQL Injection](security/sql_injection_prevention.md) - Standards for preventing SQL injection vulnerabilities across all languages
* [Dependency Injection](architecture/dependency_injection.md) - Dependency injection patterns for maintainable code

条目根据每个模块 frontmatter 中的 title 和 description 派生。在每个目录内按标题字母顺序排序。如果模块缺少 description，则根据正文的首段派生。

Personas 和 Examples 遵循相同模式，标题分别为 # Personas 和 # Examples。

Step 2: 重建各目录的 log.md（OKF §9）

为每个子目录生成 log.md 文件，采用 OKF §9 按日期分组的格式（最新在前）。

context_modules/rules/log.md：

# Rules Update Log

## 2026-05-23
* **Creation**: Added [Dependency Injection](architecture/dependency_injection.md) — Dependency injection patterns for maintainable code. CDR: CDR-2026-008.
* **Verification**: Verified [SQL Injection Prevention](security/sql_injection_prevention.md). CDR: CDR-2026-021.

## 2026-05-21
* **Creation**: Added [SQL Injection Prevention](security/sql_injection_prevention.md) — Standards for preventing SQL injection. CDR: CDR-2026-021.

日志条目派生自：

1. Git 历史记录：用于获取创建日期的 git log --diff-filter=A --format="%ai %s" -- <file>
2. 用于验证条目的 frontmatter verified 时间戳
3. 现有 log.md 内容（保留手动添加的条目，并追加新条目）

context_modules/log.md（根目录 — 汇总）：

# Context Modules Update Log

## 2026-08-12
* **Re-index**: Rebuilt all index.md and log.md files via /team-repair. Rules: {N} files, Personas: {N} files, Examples: {N} files.

Step 3: 派生 CDR.md（用于 team-boot 的扁平表格）

根据各目录的 index.md 数据和模块 frontmatter，派生出扁平的 CDR.md 表，用于注入 team-boot 系统提示词。

{TEAM_AI_DIRECTIVES}/CDR.md：

# Context Directive Records (Derived Index)

> ⚠️ Auto-generated by `/team-repair`. Do not edit manually.
> Source of truth: `context_modules/*/index.md` + module frontmatter.
> Decision lifecycle (Accepted/Rejected) lives in project `adlc branch drafts/cdr/`.

## CDR Index

| ID | Path | Type | Description | Generated | Verified | Age | Status |
|----|------|------|-------------|-----------|----------|-----|--------|
| CDR-2026-021 | context_modules/rules/security/sql_injection_prevention.md | Rule | Standards for preventing SQL injection... | 2026-06-14 | 2026-05-21 | 46d | stable |
| rule-frontend-routing | context_modules/rules/frontend/framework/frontend_routing.md | Rule | Client-side routing patterns... | 2026-06-15 | 2026-06-15 | 0d | stable |

**Stats**: {N} entries | Last Updated: {date}

列：

• ID：frontmatter 中的 cdr_ref（如果 cdr_ref 为 null，则使用 id）
• Path：相对于 TEAM_AI_DIRECTIVES 的路径
• Type：frontmatter 中的 type
• Description：frontmatter 中的 description（截断至 80 个字符）
• Generated：generated.at 日期（YYYY-MM-DD）
• Verified：最新的 verified[].at 日期（YYYY-MM-DD）
• Age：距 verified 日期的天数
• Status：frontmatter 中的 status（如果不存在，则为 stable）

Step 4: 写入文件

如果使用 --dry-run：

### OKF Files Preview

Would write:
- context_modules/index.md ({N} entries)
- context_modules/log.md
- context_modules/rules/index.md ({N} entries)
- context_modules/rules/log.md
- context_modules/personas/index.md ({N} entries)
- context_modules/personas/log.md
- context_modules/examples/index.md ({N} entries)
- context_modules/examples/log.md
- CDR.md ({N} derived entries)

否则，写入全部 9 个文件。

目标：根据扫描到的技能生成新的 .skills.json

跳过条件：提供了 --index-only 或 --agents-only 标志

Step 1: 生成技能清单

{
  "skills": {
    "local:./skills/code-review": {
      "version": "1.0.0",
      "description": "Review code following team standards and best practices",
      "categories": ["review", "quality"],
      "instruction_type": "Review"
    }
  }
}

Step 2: 写入 .skills.json

如果使用 --dry-run：

### .skills.json Preview

Would write {N} skill entries

否则：

cat > "{TEAM_AI_DIRECTIVES}/.skills.json" << 'EOF'
{generated JSON}
EOF

Phase 8: 冲突扫描

目标：扫描 team-ai-directives 规则中的矛盾和重叠。

跳过条件：提供了 --skills-only、--agents-only 或 --freshness 标志。

Step 1: 加载规则和宪章

加载：

• {TEAM_AI_DIRECTIVES}/context_modules/constitution.md
• {TEAM_AI_DIRECTIVES}/context_modules/rules/**/*.md

Step 2: 检测冲突

冲突级别：

Level	Pattern	Severity
直接矛盾	must X 与 never X	CRITICAL
隐含矛盾	数值或逻辑上的不可能	ERROR
例外冲突	基础规则与例外	WARNING
范围重叠	规则重叠	INFO
宪章冲突	规则与原则冲突	CRITICAL

使用 team-levelup/scripts/bash/helpers.sh 进行冲突检测，或内联实现：

skills/team/team-levelup/scripts/bash/helpers.sh --conflicts "$TEAM_AI_DIRECTIVES/context_modules/rules"

Step 3: 创建冲突 CDR

对于每个冲突，在 adlc branch drafts/cdr/CDR-{NNN}.md 中创建一个 CDR：

## CDR-{NNN}: Resolve Rule Conflict: {title}

### Status
**Discovered**

### Date
{today}

### Source
Rule conflict detection via /team-repair --validate

### Target Module
`context_modules/rules/{domain}/`

### Context Type
Rule

### Context
**Conflict Details**:
- Rule A: {path} — "{statement}"
- Rule B: {path} — "{statement}"
- Type: {critical|error|warning|info}

### Decision
**Proposed Resolution**:
1. Add exception
2. Edit rule to avoid conflict
3. Mark intentional
4. Deprecate one rule

重新生成本地 CDR 索引。

交接：如果创建了冲突 CDR，建议使用 /team-levelup。

Phase 9: 新鲜度验证

目标：更新有效指令的 verified 时间戳，并标记过期指令。

跳过条件：提供了 --skills-only、--agents-only 或 --conflicts 标志。

第 1 步：识别有效指令

对于每个上下文模块文件（规则、角色设定、示例、章程）和技能 SKILL.md：

• 如果未检测到此文件存在冲突 → 符合验证更新条件
• 如果检测到冲突 → 跳过（将通过冲突 CDR 解决）

第 2 步：更新验证元数据

对于每条符合条件的指令：

1. 解析 YAML frontmatter
2. 将 { by: process:team-repair, at: {today}T00:00:00Z } 追加到 verified 列表
3. 如果本次修复运行期间内容发生变化，则更新 generated.at
4. 将验证条目追加到每个目录的 log.md：

* **Verification**: Verified [{Title}](path) — no conflicts detected.

第 3 步：报告过期指令

标记最新的 verified[].at 早于 stale_after（默认值为 180d）的指令，或 status 为 deprecated 的指令。

### Stale Directives

| File | Last Verified | Age | Stale After | Status |
|---|---|---|---|---|
| rules/old-pattern.md | 2026-04-01 | 190d | 180d | stale |

第 9b 阶段：置信度更新

如果未提供 --update-confidence 标志，则跳过。

目标：从 adlc 孤立分支读取使用数据，汇总为置信度分数，并更新主分支上的 OKF frontmatter。

第 1 步：从 adlc 分支读取使用数据

# Read all project usage files from adlc branch
for file in $(git -C "$TEAM_AI_DIRECTIVES" ls-tree --name-only "$ADLC_BRANCH" "reports/projects/" 2>/dev/null | grep '\.json$'); do
  git -C "$TEAM_AI_DIRECTIVES" show "${ADLC_BRANCH}:${file}"
done

第 2 步：汇总到 confidence-scores.json

合并所有项目的 JSON，计算：

• usage_count：所有项目中 matched 的总和
• apply_count：所有项目中 applied 的总和
• success_rate：apply_count / usage_count
• last_used：所有项目中最近的 last_used
• trend：rising（最近 7 天内使用过）、stable（最近 30 天内使用过）、falling（超过 30 天）
• projects：项目名称列表

写入 adlc 分支：reports/confidence-scores.json。

第 3 步：更新主分支上的 OKF Frontmatter

对于 confidence-scores.json 中的每个 CDR：

1. 通过 cdr_ref 查找对应的上下文模块文件
2. 在 YAML frontmatter 中添加／更新 confidence: 区块
3. 提交到主分支

第 4 步：使用置信度列重新构建 CDR.md

在派生的 CDR.md 表格中添加 Confidence 和 Usage 列。

第 10 阶段：构建以删除（Factor XII）

目标：识别因基线模型已能原生处理而不再需要的指令。这是“框架衰减”机制——不使用指令运行评测；如果模型能够独立通过，该指令就可能适合移除。

如果未提供 --build-to-delete 标志，则跳过。

此阶段会调用 LLM——它会针对 Agent 运行黄金集用例，以测试是否仍需要这些指令。

第 1 步：加载所有黄金集

从 {TEAM_AI_DIRECTIVES}/evals/ 读取所有黄金集目录：

ls -1 "$TEAM_AI_DIRECTIVES/evals/" 2>/dev/null

对于每个 {directive-id} 目录，读取：

• evals/{directive-id}/goldset.md — 人类可读的用例
• evals/{directive-id}/goldset.json — 机器可读的用例

如果不存在黄金集，则报告：“未找到评测 — 请先运行 /team-levelup 创建评测 CDR。”并跳过此阶段。

第 2 步：识别配对指令

对于每个黄金集，识别其配对指令：

• 从黄金集 frontmatter 中读取 paired_directive
• 从 context_modules/ 读取指令文件（例如，rules/security/sql_injection_prevention.md）
• 如果指令文件不存在 → 跳过（已删除或评测孤立）

第 3 步：不使用指令运行黄金集

对于每组指令和评测：

1. 临时移除指令，使其不被加载到上下文中（模拟 Agent 在没有该规则时的工作方式）
2. 通过 LLM 调用针对 Agent 运行黄金集用例：
   • 对于每个通过用例：提供场景和输入上下文，要求 Agent 生成输出，并检查其是否遵循（已移除的）指令
   • 对于每个失败用例：提供场景和输入上下文，要求 Agent 生成输出，并检查其是否仍会犯同样的错误
3. 计算通过率：cases_passed / total_cases

步骤 4：对结果分类

通过率	判定	建议
100%	删除候选项	模型已能原生处理此规则 — 指令已过时
80-99%	审核候选项	模型基本能处理此规则 — 考虑简化该指令
< 80%	保留	模型仍需要此指令

对于每个判定为 保留（以及 审核候选项）的规则，请提出互补的 提升为检查项 问题（EVAL-010）：能否通过确定性检查（单元测试 / 二进制评分器 / 提交前钩子 / lint 规则 / CI 任务）机械地强制执行此规则？如果可以，则它是一个 提升候选项 — 一次性投入编写检查，而不是在每次会话中重新注入模糊规则。

步骤 5：生成 Harness 衰减报告

## Build to Delete Report

### Candidates for Removal (model passes 100% without directive)

| Directive | Eval | Pass Rate | Recommendation |
|---|---|---|---|
| rules/security/sql_injection.md | evals/CDR-001/ | 100% (6/6) | Delete — model handles this natively now |

### Review Candidates (80-99%)

| Directive | Eval | Pass Rate | Recommendation |
|---|---|---|---|
| rules/devops/helm_packaging.md | evals/CDR-008/ | 83% (5/6) | Simplify — model mostly handles it, 1 case failed |

### Still Needed (< 80%)

| Directive | Eval | Pass Rate | Recommendation |
|---|---|---|---|
| rules/style/python_pep8.md | evals/CDR-015/ | 40% (2/5) | Keep — model still needs guidance |

### Promotion Candidates (Keep, but check-enforceable)

| Directive | Eval | Pass Rate | Proposed Check |
|---|---|---|---|
| rules/architecture/import_boundaries.md | evals/CDR-011/ | 55% (3/5) | Promote to pre-commit lint rule — file-location pattern is mechanical |

步骤 6：创建删除 CDR（及提升 CDR）

对于每个 删除候选项（通过率为 100%），在 adlc branch drafts/cdr/CDR-{NNN}.md 中创建一份 CDR：

## CDR-{NNN}: Delete Directive: [Title]

### Status: **Discovered**

### Date: [YYYY-MM-DD]

### Source: Build to Delete via /team-repair --build-to-delete

### Target Module: `context_modules/rules/{domain}/{file}.md` + `evals/{directive-id}/`

### Context Type: Constitution Amendment

### Descriptor: Directive is obsolete — model handles natively without the rule.

### Context
The directive `{title}` was tested by running its goldenset cases without the directive loaded.
The model passed 100% of cases (N/N), indicating the baseline model now handles this pattern natively.
The directive is a candidate for Harness Decay removal.

### Decision
Delete both the directive file and its paired eval goldenset.

### Evidence
- Directive: context_modules/rules/{domain}/{file}.md
- Eval: evals/{directive-id}/goldset.md
- Pass rate: 100% (N/N cases passed without the directive)
- Test date: [YYYY-MM-DD]

重新生成本地 CDR 索引。交接：建议使用 /team-levelup 审核删除候选项。

对于每个 提升候选项，在 adlc branch drafts/cdr/CDR-{NNN}.md 中创建一份 CDR：

## CDR-{NNN}: Promote Directive to Deterministic Check: [Title]

### Status: **Discovered**

### Date: [YYYY-MM-DD]

### Source: Build to Delete via /team-repair --build-to-delete

### Target Module: `context_modules/rules/{domain}/{file}.md`

### Context Type: Rule

### Descriptor: Rule is mechanically enforceable — promote to a deterministic check.

### Context
The directive `{title}` survived build-to-delete (model still needs it, pass rate < 100%),
but its pattern is mechanical — a deterministic check (unit test / binary grader /
pre-commit hook / lint rule / CI job) can enforce it without session context.

### Decision
Build the deterministic check. Once it exists and runs in CI, deprecate the CDR
or reduce it to a thin pointer (`enforced by <check path>`). Route to
`/team-levelup` action **P — Promote to check** (Phase 2b).

### Evidence
- Directive: context_modules/rules/{domain}/{file}.md
- Proposed check vehicle: [unit test | grader | pre-commit | lint | CI job]
- Pass rate without directive: N% (M/K cases) — rule still needed
- Test date: [YYYY-MM-DD]

再次重新生成本地 CDR 索引。交接：建议使用 /team-levelup 审核提升候选项（操作 P）。

阶段 11：验证草稿

目标：验证 .adlc/drafts/ 中的决策记录草稿在结构上是否完整 — 包括必需的 frontmatter 字段、必需的正文部分和有效的枚举值。这是一个只读验证模式 — 不会创建、修改或删除任何文件。

跳过条件：未提供 --validate-drafts 标志。

此阶段不会调用 LLM — 仅进行机械式文件解析和验证，类似于 lint 工具。

步骤 1：扫描草稿目录

扫描相对于 {REPO_ROOT} 的以下草稿目录中的所有文件：

.adlc/drafts/adr/
.adlc/drafts/pdr/
.adlc/drafts/chdr/
adlc branch drafts/cdr/
.adlc/drafts/evals/

对于每个目录，列出所有 *.md 文件。如果目录不存在，则静默跳过（这不是错误 — 该草稿类型只是没有草稿）。

如果所有目录中都没有找到草稿文件，则报告：“在 .adlc/drafts/ 中未找到草稿文件 — 无需验证。”并跳过此阶段。

步骤 2：验证 Frontmatter

对于每个草稿文件，解析 YAML frontmatter（位于 --- 分隔符之间），并验证是否包含以下必需字段：

字段	必需	有效值	备注
status	是	proposed、accepted、rejected、deferred、superseded、discovered	匹配时不区分大小写
date	是	任意非空字符串（预期格式为 YYYY-MM-DD）	不得为空或为占位符
type	是	decision、product、pattern、incident、workaround、constraint、abandoned、eval	匹配时不区分大小写
evidence	是	confirmed、inferred、unknown	匹配时不区分大小写
source	是	任意非空字符串	草稿的来源（技能名称、会话等）
revisit-when	是（字段必须存在）	空字符串、N/A 或任意非空字符串	字段必须存在；值可以为空或为 N/A

对于每个缺失或无效的字段，记录：

• 文件路径
• 行号（frontmatter 键所在行；若完全缺少 frontmatter，则为第 1 行）
• 问题描述（例如：“缺少必需字段：status”，“status 值无效：'draft' — 预期值之一：proposed、accepted、rejected、deferred、superseded、discovered”）

第 3 步：验证正文部分

在 frontmatter 之后，验证以下必需的正文部分是否以 Markdown 标题形式存在：

部分	必需	备注
## Context（或 ### Context）	是	必须以标题形式存在
## Decision（或 ### Decision）	是	必须以标题形式存在
## Rejected Alternatives（或 ### Rejected Alternatives）	是	必须以标题形式存在
## Reason（或 ### Reason）	是	必须以标题形式存在

标题级别灵活性：每个部分接受 ##、###（甚至 ####）。按标题文本匹配（不区分大小写，并去除首尾空格）。

对于每个缺失的部分，记录：

• 文件路径
• 行号（如果未找到该部分则为 0——报告为“未找到该部分”）
• 问题描述（例如：“缺少必需的正文部分：Rejected Alternatives”）

第 4 步：条件验证——Rejected Alternatives 非空

对于 type 为 decision 或 abandoned 的草稿文件，## Rejected Alternatives（或 ### Rejected Alternatives）部分不得为空。“为空”指：

• 标题与下一个标题之间或文件末尾没有内容
• 只有空白字符或占位文本（例如，“N/A”、“TBD”、“TODO”、“none”）

对于每个违规项，记录：

• 文件路径
• 标题所在行号
• 问题：“对于 decision/abandoned 类型，Rejected Alternatives 部分为空——必须至少列出一个被拒绝的替代方案”

第 5 步：生成验证报告

## Draft Validation Report

**Date**: {date}
**Mode**: VALIDATE ONLY (no modifications)

### Summary

| Metric | Count |
|--------|-------|
| Draft directories scanned | {n} |
| Draft files validated | {n} |
| Files with errors | {n} |
| Files with warnings | {n} |
| Files passing validation | {n} |
| Total findings | {n} |

### Findings

| Severity | File | Line | Issue |
|----------|------|------|-------|
| Error | .adlc/drafts/adr/ADR-001.md | 3 | Missing required field: evidence |
| Error | .adlc/drafts/adr/ADR-001.md | 0 | Missing required body section: Reason |
| Error | .adlc/drafts/pdr/PDR-005.md | 7 | Invalid status value: 'draft' — expected one of: proposed, accepted, rejected, deferred, superseded, discovered |
| Warning | adlc branch drafts/cdr/CDR-010.md | 15 | Rejected Alternatives section is empty for decision type — must list at least one rejected alternative |

{If no findings:}
> **All draft files passed validation — no issues found.**

第 6 步：交接

• 如果发现错误：建议先修复草稿文件，再通过相应的 clarify 技能提升草稿（ADR 使用 /architect-clarify，PDR 使用 /product-clarify，ChDR 使用 /change-clarify，CDR 使用 /team-levelup）。
• 如果所有草稿都通过验证：确认草稿在结构上已具备提升条件。
• 提醒：验证不检查语义质量，只检查结构是否完整。通过验证的草稿仍可能在澄清过程中被拒绝。

第 12 阶段：总结报告

## Team Repair Summary

**Date**: {date}
**Team Directives**: {path}
**Mode**: {DRY RUN|LIVE}

### AGENTS.md Repair

| Status | Action |
|--------|--------|
| {VALID|CREATED|OVERWRITTEN} | {No changes needed|Created from template|Re-created from template} |

### OKF index.md + log.md + CDR.md Repair

| Action | Count |
|--------|-------|
| Files scanned | {n} |
| v0.1→v0.2 migrated | {n} |
| index.md files rebuilt | {n} |
| log.md files rebuilt | {n} |
| CDR.md derived entries | {n} |
| Orphans repaired | {n} |
| Missing removed | {n} |

### .skills.json Repair

| Action | Count |
|--------|-------|
| Skills scanned | {n} |
| Valid entries | {n} |
| Orphans repaired | {n} |
| Missing removed | {n} |

### Conflict Scanning

| Metric | Count |
|---|---|
| Conflicts detected | {n} |
| Conflict CDRs created | {n} |
| Critical | {n} |
| Error | {n} |
| Warning | {n} |
| Info | {n} |

### Freshness Verification

| Metric | Count |
|---|---|---|
| Directives updated | {n} |
| Stale directives (>30d) | {n} |
| Skipped (has conflicts) | {n} |

### Draft Validation

| Metric | Count |
|--------|-------|
| Draft files validated | {n} |
| Files with errors | {n} |
| Files with warnings | {n} |
| Files passing validation | {n} |
| Total findings | {n} |

{If --validate-drafts was not run:}
> **Note**: Draft validation not run (use `--validate-drafts` to validate .adlc/drafts/)

### Files Modified

| File | Change |
|------|--------|
| {file} | {change description} |

{If --dry-run:}
> **Note**: Dry run mode - no files were modified

### Next Steps

1. Review repaired files
2. If conflict CDRs were created, run `/team-levelup` to resolve them
3. Commit changes if satisfied

备注

• 自动修复：始终自动修复问题（无需确认）
• 试运行：使用 --dry-run 预览更改，不写入文件
• 选择性修复：对特定目标使用 --index-only、--skills-only 或 --agents-only
• 验证模式：--validate 运行冲突扫描和时效性检查；--conflicts 和 --freshness 分别运行这两项检查
• 草稿验证：--validate-drafts 验证 .adlc/drafts/{adr,pdr,chdr,cdr,evals}/——只读，不做修改（与 --build-to-delete 一样，只报告发现的问题）
• YAML frontmatter：为孤立的上下文模块自动生成
• Skills 条目：根据 SKILL.md 内容自动生成
• AGENTS.md：如果文件损坏（缺少必需部分），则覆盖该文件
• 幂等：重复运行会产生相同结果

常见借口

借口	实际情况
“索引看起来没问题——没必要重新索引。”	不进行完整目录扫描，就无法发现孤立文件和缺失的 frontmatter。
“我直接手动编辑 CDR.md，添加缺失的行就行。”	手动编辑会与实际内容产生偏差；重建可确保索引与文件系统一致。
“没必要试运行——直接写入更改就行。”	试运行会在修改任何文件之前，暴露意外的孤立项和空的 CDR 引用。
“AGENTS.md 看起来有效，所以我跳过 Phase 2。”	缺失的章节可能很隐蔽（例如标题被重命名）。验证成本低，而且可幂等执行。
“跳过 Step 5——项目的 AGENTS.md 不归我管。”	团队 AI 指令自身的 AGENTS.md 描述了其结构；项目级 AGENTS.md 则会告知 Agent 在会话开始时调用 team-boot。没有它，这些指令就不会被发现。
“孤立项可以跳过 CDR_LOOKUP 步骤。”	不进行查找，现有的 CDR 引用就会丢失，孤立条目也会变成 cdr_ref: null，破坏可追溯性。
“我直接开始修复就行——没必要先做健康检查。”	Phase 0 的存在，正是因为框架状态不健康会让修复变得危险或毫无意义。请先运行它。
“Phase 0 出现 [WARN]，基本就等于 [OK]。”	警告不会影响退出码，但通常表明存在偏差，之后可能导致 [FAIL]。请跟踪每次运行中的警告。

危险信号

• 未先验证结构就覆盖 AGENTS.md — 判定文件“已损坏”应以缺失章节的证据为依据，而非凭直觉；否则会破坏自定义内容。
• 现有 CDR_LOOKUP 条目存在时仍生成 cdr_ref: null — 这会在不知不觉中切断上下文模块与其已接受 CDR 记录之间的审计轨迹。
• 孤立项数量较多时跳过试运行 — 未经审查就批量自动修复，会导致伪造的 ID 和元数据传播到版本控制中。
• 未解析实际的 SKILL.md 就写入 .skills.json 条目 — 伪造的描述和类别会让技能无法搜索，并歪曲其能力。
• TEAM_AI_DIRECTIVES 为空时仍继续执行 Phase 2 — 在未配置的仓库中操作，会写入未定义的路径并破坏错误的工作区。
• 跳过 Phase 0 Health Check — 未验证框架是否已安装就直接开始修复，有写入不存在或配置错误的工作区的风险。
• 跳过 Step 5（注入项目级 AGENTS.md） — 团队 AI 指令自身的 AGENTS.md 描述了其结构，但项目级 AGENTS.md 才会告知 Agent 在会话开始时调用 team-boot。没有它，Agent 就没有会话开始指令，团队 AI 指令也会一直不可见，除非手动加载。

验证

• 在尝试任何修复之前，Phase 0 健康检查通过全部 8 项检查（没有 [FAIL]）。
• {TEAM_AI_DIRECTIVES}/AGENTS.md 存在，且包含全部六个必需章节。
• 项目级 {REPO_ROOT}/AGENTS.md 包含 `` 管理章节，其中包含事件钩子意识说明、备用 team-boot 调用、Class Boots 目录、Team Context in Use 输出契约，以及精简的 Decision Capture 触发条件。
• CDR.md 条目数等于扫描到的上下文模块 .md 文件数（不包括 constitution.md）。
• context_modules/{rules,personas,examples}/ 下的每个上下文模块文件都包含 YAML frontmatter，且具有非空的 id 字段。
• 每个孤立 frontmatter 中的 cdr_ref 都与预先存在的 CDR 查找结果匹配（不会将先前存在的引用回退为 null）。
• 每个包含 SKILL.md 的技能目录在 .skills.json 中都有对应条目。
• .skills.json 中没有引用磁盘上不存在的技能目录的条目。
• 摘要报告列出的 "Files scanned" / "Skills scanned" 计数均非零，且总数一致。
• 不带标志重新运行技能时，不会产生任何 "Files Modified" 条目（幂等性检查）。
• 已完成冲突扫描（若未跳过），并为发现的任何问题创建了冲突 CDR。
• 已完成新鲜度验证（若未跳过），并报告过时的指令。
• 执行 --validate 后，没有仍未报告的规则矛盾。
• 如果运行了 --validate-drafts：已扫描 .adlc/drafts/{adr,pdr,chdr,cdr,evals}/ 中的每个草稿文件，并报告发现的问题（如有）。
• 如果运行了 --validate-drafts：.adlc/drafts/ 中没有文件被创建、修改或删除（仅验证、只读模式）。
• 如果运行了 --validate-drafts：草稿验证结果中的每个问题都包含文件路径、行号和问题描述。

配置

• TEAM_AI_DIRECTIVES — 团队 AI 指令的路径（优先于 .adlc/init-options.json）。
• .adlc/init-options.json — 项目级配置文件，包含 team_ai_directives 字段。
• 默认回退路径：相对于项目根目录的 team-ai-directives/。
• ../team-setup/scripts/bash/team-helpers.sh / ../team-setup/scripts/powershell/team-helpers.ps1 — 用于解析路径的共享脚本（以 team-setup 中的版本为准）。

12-Factor 对齐

Factor XI（指令即代码）——维护受版本控制的团队指令的完整性。