mirrors/pikasTech-HWLAB
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: archive caserun agent trace rows

Browse Source
This commit is contained in:
Codex Agent
2026-06-06 22:49:12 +08:00
parent b73cf2d019
commit 841594437e
3 changed files with 137 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/spec-hwpod-harness.md
+7 -9
View File
@@ -111,7 +111,9 @@ Keil MDK 装配规则：当 `spec.workspace.toolchain` 为 `keil-mdk`、`keil`
## hwpod-node-ops
`hwpod-node-ops` 不表达用户意图，只表达 node 可执行的基础动作。第一版最小集合：
`hwpod-node-ops` 不表达用户意图，只表达 node 可执行的基础动作。当前新增能力边界收敛为文件读写/patch 类 op 加 `cmd.run`：有 `cmd.run` 就能覆盖 host 上成熟 CLI、编译器、下载器、串口工具和维护命令，再加上受控文件读写即可支撑源码修改 case。后续新增 case 不应因为 build、download、job status、UART、reset 或某个调试工具需要而新增专用 node op；这些业务翻译必须优先落在 `hwpod-compiler-cli` / `hwpod-cli` 组合层。
基础 op 集合：
| op | 用途 |
| --- | --- |
@@ -125,15 +127,11 @@ Keil MDK 装配规则：当 `spec.workspace.toolchain` 为 `keil-mdk`、`keil`
| `workspace.write` | 带 `expectedSha`、换行策略和 diff 摘要的整文件写入 |
| `workspace.replace` | 带 `expectedSha`、唯一匹配检查和 diff 摘要的精确文本替换 |
| `workspace.insert-after` | 按精确 anchor 插入文本，避免 PowerShell/cmd quoting |
| `debug.build` | 编译工程 |
| `debug.download` | 下载或烧录目标设备 |
| `debug.reset` | 复位目标设备 |
| `io.uart.read` | 读取 UART |
| `io.uart.write` | 写入 UART |
| `io.uart.jsonrpc` | 通过 UART 做 JSON-RPC |
| `cmd.run` | 临时维护命令透传，仅用于 `hwpod-ctl` 或早期薄 node 调试 |
| `cmd.run` | 通用 host 命令透传，用于组合 Keil、serial-monitor、job status、下载、复位和临时维护动作 |
`hwpod-node` 是 HWPOD 的唯一受控节点执行器。第一阶段的业务扩展优先落在 `hwpod-compiler-cli` / `hwpod-cli`，通过已有文件读写 op 和 `cmd.run` 组合 Keil、serial-monitor 等成熟工具；不要因为某个 case 需要 build、job status、download、UART 或临时维护动作就新增专用 node op。`cmd.run` 的命令解析、PATH 稳定性和跨平台差异必须在 `hwpod-node` 本体内处理；当 Windows service、后台进程或 D601 host 的环境变量与交互 shell 不一致时，不得用 gateway shell、手工 PowerShell、预先手工创建 worktree 或其他旁路代替 `hwpod-node-ops -> hwpod-node`。D601/Windows 实地调试应使用 UniDesk SSH 透传 `D601:win` 观察进程、PATH、工具安装位置和日志，但修复必须回到 `hwpod-node` 源码、配置或启动入口，并用 `/v1/hwpod-node-ops` 原链路复测。
若历史实现中仍存在 `debug.*` 或 `io.*` 这类专用 op，它们只能作为兼容存量观察对象，不再作为新 case 或新 harness 业务的扩展方向。标准路径是：compiler 根据 spec 生成 `cmd.run` 的 `command` + `argv`，node 只负责在目标 host 上忠实执行并返回 stdout/stderr/exit code。
`hwpod-node` 是 HWPOD 的唯一受控节点执行器。第一阶段的业务扩展优先落在 `hwpod-compiler-cli` / `hwpod-cli`，通过已有文件读写 op 和 `cmd.run` 组合 Keil、serial-monitor 等成熟工具；不要因为某个 case 需要 build、job status、download、UART 或临时维护动作就新增专用 node op。`cmd.run` 的命令解析、PATH 稳定性和跨平台差异必须在 `hwpod-node` 本体内处理；当 Windows service、后台进程或 D601 host 的环境变量与交互 shell 不一致时，不得用 gateway shell、手工 PowerShell、预先手工创建 worktree 或其他旁路代替 `hwpod-node-ops -> hwpod-node`。D601/Windows 实地调试应使用 UniDesk SSH 透传 `D601:win` 观察进程、PATH、工具安装位置和日志，但修复必须回到 `hwpod-node` 源码、配置或启动入口，并用 `/v1/hwpod-node-ops` 原链路复测。只有 `cmd.run` 自身的执行语义、环境继承或可见性不满足真实 host 执行时，才修改 `hwpod-node`；否则优先改 compiler/CLI。
Windows subject worktree 文本修改优先使用 `workspace.apply-patch`、`workspace.replace`、`workspace.insert-after` 或 `workspace.write`，不要把 `cmd.run` 的 PowerShell/cmd quoting 当成标准编辑路径。文本编辑结果必须返回编辑前后 SHA、文件字节数、换行类型、diff 摘要和 dry-run 状态；`apply-patch` 匹配失败时必须返回 normalized preview、候选行号、CRLF/LF 统计、文件 SHA/bytes 和 hwpod-node implementation version，便于判断是上下文不匹配、CRLF 问题还是远端实现版本问题。`workspace.apply-patch` 应保留原文件换行风格，尤其不能把 CRLF subject 文件静默改写成 LF。