Harness Validate Output

harness-validate-output 输出校验技能

核心能力

1. 检查前置条件（harness-enforce-architecture-guardrails）
2. 读取架构护栏规则（ARCHITECTURE_GUARDRAILS.md）
3. 校验输出文件是否符合分层架构
4. 校验命名规范
5. 校验文件结构约定
6. 生成校验报告
7. 记录校验事件
8. 更新全局状态

前置条件

• harness-init 已完成
• harness-enforce-architecture-guardrails 已完成
• ARCHITECTURE_GUARDRAILS.md 文件存在

执行步骤

Step 1: 检查前置条件

使用 Read 工具读取：.EnjoyHarness/SKILL_REGISTRY.md

检查条件：

• harness-enforce-architecture-guardrails 已标记为完成

如果未完成：

❌ 错误: 架构护栏未执行
💡 请先运行: harness-enforce-architecture-guardrails

Step 2: 读取架构护栏规则

使用 Read 工具读取：.EnjoyHarness/ARCHITECTURE_GUARDRAILS.md

提取关键规则：

• 分层架构规则（Types → Config → Repo → Service → Runtime → UI）
• 命名规范（文件、函数、变量）
• 文件结构约定
• 禁止的跨层调用

Step 3: 获取待校验的输出文件

使用 Bash 工具查询：

# 获取最近修改的文件（最近5分钟内）
RECENT_FILES=$(find . -type f \( -name "*.go" -o -name "*.ts" -o -name "*.tsx" -o -name "*.py" \) -mmin -5 | grep -v ".git" | grep -v "node_modules")

echo "待校验文件列表："
echo "$RECENT_FILES"

Step 4: 校验分层架构

对每个待校验文件执行：

# 提取文件路径
FILE_PATH="{文件路径}"

# 判断文件所属层级
LAYER=$(echo "$FILE_PATH" | cut -d'/' -f2)

echo "文件: $FILE_PATH"
echo "层级: $LAYER"

使用 Grep 工具检查导入：

检查是否有违规跨层导入，确保符合架构规则。

Step 5: 校验命名规范

5.1 文件命名规范

FILE_NAME=$(basename "$FILE_PATH")

# Go文件: snake_case
if [[ "$FILE_NAME" =~ \.go$ ]]; then
  if [[ ! "$FILE_NAME" =~ ^[a-z][a-z0-9_]*\.go$ ]]; then
    echo "❌ Go文件命名违规: $FILE_NAME (应为 snake_case)"
  fi
fi

5.2 函数命名规范

使用 Grep 工具提取函数定义并检查命名规范。

Step 6: 校验文件结构约定

使用 Bash 工具检查：

# 检查是否存在禁止的文件结构
FORBIDDEN_PATTERNS=("src/src/" "test/test/" "internal/internal/")

for pattern in "${FORBIDDEN_PATTERNS[@]}"; do
  if find . -type d -path "*$pattern" | grep -q .; then
    echo "❌ 禁止的文件结构: $pattern"
  fi
done

Step 7: 生成校验报告

使用 Write 工具创建文件：.EnjoyHarness/VALIDATION_REPORT.md

内容包括：

• 校验概况（时间、文件数、通过/失败数量）
• 校验规则摘要
• 详细结果（通过/失败的文件列表）
• 问题汇总（架构违规、命名违规、结构违规）
• 建议修复（按优先级分类）

Step 8: 记录校验事件

使用 Edit 工具追加内容到：.EnjoyHarness/EVENT_LOG.md

{当前时间} | OUTPUT_VALIDATION | harness-validate-output | 校验输出文件: {文件数量}个 | {SUCCESS/FAILURE}

Step 9: 更新全局状态

使用 Edit 工具更新：.EnjoyHarness/GLOBAL_STATE.md

last_validation: {当前时间}
validation_status: {PASSED/FAILED}
validation_passed: {通过数量}
validation_failed: {失败数量}

Step 10: 更新事件计数

使用 Edit 工具更新：.EnjoyHarness/EVENT_LOG.md

old_string: total_events: N new_string: total_events: N+1

Step 11: 更新技能注册表

使用 Edit 工具更新：.EnjoyHarness/SKILL_REGISTRY.md

old_string: - [ ] harness-validate-output - 输出校验技能 new_string: - [x] harness-validate-output - 输出校验技能 ✅

Step 12: 输出完成信息

使用 Bash 工具输出：

echo ""
echo "✅ harness-validate-output 完成!"
echo ""
echo "📋 校验结果:"
echo " - 校验文件数: {文件数量}"
echo " - 通过文件数: {通过数量}"
echo " - 失败文件数: {失败数量}"
echo ""
echo "🎯 下一步:"
if [ {失败数量} -gt 0 ]; then
  echo " - 修复失败文件或触发 harness-handle-failure"
else
  echo " - 继续执行后续技能"
fi
echo ""

成功标准

• 读取架构护栏规则
• 校验输出文件架构层级
• 校验命名规范
• 校验文件结构
• 生成校验报告
• 记录校验事件
• 更新全局状态
• 更新事件日志
• 技能注册表已更新

失败兜底

• harness-enforce-architecture-guardrails 未完成 → 终止执行，提示运行前置技能
• ARCHITECTURE_GUARDRAILS.md 不存在 → 终止执行，提示运行前置技能
• 校验失败 → 记录失败详情，触发 harness-handle-failure 或人工修复

联动关系

• 前置: harness-enforce-architecture-guardrails
• 成功后触发: harness-goal（验证目标达成）或继续执行
• 失败后触发: harness-handle-failure

迭代计数

本技能执行预计迭代次数: 约 10 次（Read 2次 + Write 1次 + Edit 3次 + Bash 4次）

测试用例

测试 1: 前置条件检查

输入: 在架构护栏未执行时运行 期望输出: 错误提示"架构护栏未执行" 验证方式: 删除 ARCHITECTURE_GUARDRAILS.md 后运行

测试 2: 分层架构校验

输入: Service层文件导入UI层 期望输出: 违规导入警告 验证方式: 创建测试文件，在service层导入ui层

测试 3: 命名规范校验

输入: Go文件使用kebab-case命名 期望输出: 文件命名违规警告 验证方式: 创建文件 my-test-file.go

测试 4: 文件结构校验

输入: 嵌套的src目录结构 期望输出: 禁止的文件结构警告 验证方式: 创建目录 src/src/

测试 5: 校验报告生成

输入: 执行校验 期望输出: 生成 VALIDATION_REPORT.md 验证方式: ls .EnjoyHarness/VALIDATION_REPORT.md

测试 6: 全局状态更新

输入: 读取 GLOBAL_STATE.md 期望输出: validation_status 为 PASSED 或 FAILED 验证方式: grep "validation_status" .EnjoyHarness/GLOBAL_STATE.md

测试 7: 事件日志记录

输入: 读取 EVENT_LOG.md 期望输出: 包含 OUTPUT_VALIDATION 事件 验证方式: grep "OUTPUT_VALIDATION" .EnjoyHarness/EVENT_LOG.md

测试 8: 所有文件通过

输入: 所有文件符合规范 期望输出: 输出"所有文件校验通过" 验证方式: 确保所有文件符合架构规则

架构违规处理流程

P0 严重违规（必须修复）

• 跨层级调用（如UI直接调用Repo）
• 循环依赖
• 导入私有包
• 违反安全规范

P1 重要违规（应该修复）

• 文件命名不符合规范
• 函数命名不符合规范
• 缺少必要的目录结构

P2 一般违规（建议修复）

• 变量命名不符合规范
• 注释不规范
• 文件结构不够清晰

使用示例

示例 1: 所有文件通过校验

校验文件: 5个
- types/user.go → ✅ 层级: Types, 命名: snake_case
- config/settings.go → ✅ 层级: Config, 命名: snake_case
- repo/user_repo.go → ✅ 层级: Repo, 命名: snake_case
- service/user_service.go → ✅ 层级: Service, 命名: snake_case
- runtime/server.go → ✅ 层级: Runtime, 命名: snake_case

结果: 所有文件校验通过
输出: "✅ 所有文件校验通过"

示例 2: 分层架构违规

校验文件: 2个
- service/auth_service.go → ❌ 导入 UI层 (login_form)
  允许的导入: Types, Config, Repo
  实际导入: UI (违规)
- ui/login_form.go → ✅ 正常

结果: 1个文件校验失败
输出: "❌ 校验失败"
建议: 修复service层导入UI层的问题