engine-cross-validate
将新 pine-foo 引擎接入 fixtures 测试和 cross-validate 脚本,确保与已有实现行为一致。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
将新 pine-foo 引擎接入 fixtures 测试和 cross-validate 脚本,确保与已有实现行为一致。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
构造一个新语言的 pine-foo 引擎实现,遵循「先对齐再重构」策略确保行为一致性。
在下游构造跨引擎一致的算子,确保各语言版本的 Pine 引擎行为一致。
定时自动维护 llmdoc 项目文档的 Skill。支持两种模式:聚合仓库模式(遍历子模块)和 单仓库模式(直接在当前仓库操作)。每天北京时间 5:00(UTC 21:00)由 GitHub Actions schedule 触发,也支持 workflow_dispatch 手动触发。收集指定时间范围内(默认过去 24 小时) 合并到目标分支的提交记录和 PR 内容,分析代码变更是否涉及功能新增、接口变更或架构调整, 如果需要则自动更新 llmdoc/ 下的对应文档并推送到目标分支。不改变外部行为的变更 (bug 修复、重构、依赖升级等)会被跳过。更新完成后输出结构化 JSON 结果并通过飞书通知。
分析 Bug 类型 Issue, 定位根因, 并对简单 Bug 自动创建修复 PR。
根据 Issue 的讨论和方案, 实现功能或修复 Bug, 并创建 PR。
定期巡查仓库,监控 CI 状态、扫描未处理 Issue,自动分发到对应 skill 处理。
| name | engine-cross-validate |
| description | 将新 pine-foo 引擎接入 fixtures 测试和 cross-validate 脚本,确保与已有实现行为一致。 |
指导如何将新构建的引擎接入已有的 fixture 测试框架和 cross-validate 验证系统。
fixtures/operators/*.json)单算子级别的输入/输出对比测试。
格式:
{
"operator": "filter_condition",
"cases": [
{
"name": "remove matching string items",
"params": { "value": "offline" },
"metadata": {
"common_input": [], "item_input": ["status"],
"common_output": [], "item_output": []
},
"input": { "common": {}, "items": [...] },
"expected": { "common": {}, "items": [...] }
}
]
}
接入方式: 在新引擎中编写 fixture test runner:
fixtures/operators/*.json参考实现: pine-java/src/test/java/page/liam/pine/FixtureTest.java
fixtures/pipelines/*.json)多算子 pipeline 级别的端到端测试。
格式:
{
"config": {
"operators": {...},
"pipeline": [...],
...
},
"static_resources": { ... },
"cases": [
{
"name": "case description",
"request": { "common": {...}, "items": [...] },
"expected": { "common": {...}, "items": [...] }
}
]
}
接入方式: 同上,但直接使用 fixture 中的 config 构造 Engine。
fixtures/errors/*.json)验证非法 config 能正确拒绝。
格式:
{
"config": { ... },
"expected_error": "error message substring"
}
接入方式: Engine.create(config) 应抛出包含 expected_error 的异常。
scripts/cross-validate.sh — 7 个验证段落:
| 段 | 验证内容 | CLI 依赖 |
|---|---|---|
| 1 | Codegen schema parity | pineapple-codegen / Codegen class |
| 2 | Render-DAG parity | pineapple-dag / RenderDAGCli |
| 3 | Execution parity | pineapple-run / RunCli |
| 4 | Column-store execution | 同上 (大数据集) |
| 5 | Error parity | 同上 (error fixtures) |
| 6 | Server HTTP parity | PineServer (HTTP) |
| 7 | Cancellation parity | RunCli + timeout |
新引擎需要暴露以下命令行工具:
# 执行 pipeline
pine-foo run -config <path> -request <path> [-static-resources <path>]
# 输出: pretty-print JSON to stdout, errors to stderr + exit(1)
# 渲染 DAG
pine-foo dag -config <path> -format dot|mermaid [-collapse N]
# 输出: dot/mermaid 文本 to stdout
# 导出 schema
pine-foo codegen --export-schema <output-path>
# 或: pine-foo codegen -schema-json <output-path>
在 Pre-build 段添加新引擎的构建:
echo " Building Foo engine..."
cd "$REPO_ROOT/pine-foo"
# 语言相关的构建命令
foo_build_command
# 定义执行函数
foo_run() {
# 执行新引擎 CLI 的命令
pine-foo-binary "$@"
}
在每个验证段中添加新引擎的对比(建议逐段接入):
# 在 section 3 (execution parity) 中追加:
foo_result=$(foo_run run -config "$config_file" -request "$req_file" "${res_args[@]}" 2>/dev/null)
foo_norm=$(echo "$foo_result" | normalize_json)
if [[ "$go_norm" == "$foo_norm" ]]; then
exec_pass=$((exec_pass + 1))
else
fail "execution divergence (Go vs Foo): $fname case $i"
fi
推荐接入顺序(按依赖和调试难度):
cross-validate 中有 normalize_json 函数处理 int/float 差异:
def normalize(obj):
if isinstance(obj, (int, float)):
return float(obj)
return obj
如果新引擎的数值表示和 Go 不同(如 83 vs 83.0),确保 normalize 能覆盖。
diff 直接比较新引擎要通过字节级段落,必须处理 JSON wire format 差异(见 new-engine skill)。
# 手动运行单个 fixture
go_out=$(/path/to/pineapple-run -config config.json -request req.json)
foo_out=$(pine-foo run -config config.json -request req.json)
diff <(echo "$go_out") <(echo "$foo_out")
python3 -c "import json; ..." sort_keys 后对比先跑单段:
# 只跑 execution parity
bash -c 'source scripts/cross-validate.sh' 2>&1 | grep -A5 "Execution parity"
或临时注释掉其他段落,聚焦调试。