fix: resolve hwpod by id for caserun agents
This commit is contained in:
Codex Agent
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: hwpod-cli
|
||||
description: Use HWLAB HWPOD from a code agent runner for hardware-development tasks. The hwpod-cli skill reads workspace-local hwpod-spec, calls hwpod-compiler-cli, submits hwpod-node-ops through hwlab-api, and waits for hwpod-node results.
|
||||
description: Use HWLAB HWPOD from a code agent runner for hardware-development tasks. The hwpod-cli skill resolves an HWPOD by hwpod-id through the HWLAB runtime service, submits hwpod-node-ops through hwlab-api, and waits for hwpod-node results.
|
||||
---
|
||||
|
||||
# hwpod-cli
|
||||
@@ -12,27 +12,29 @@ This skill follows Skill(cli-spec). It is the standard task entry for operating
|
||||
```text
|
||||
hwpod from PATH
|
||||
-> tools/hwpod-cli.ts
|
||||
-> tools/hwpod-compiler-cli.ts
|
||||
-> runtime HWPOD registry by hwpod-id
|
||||
-> compiler-backed hwpod-node-ops plan
|
||||
-> /v1/hwpod-node-ops on hwlab-api
|
||||
-> hwpod-node on the host side
|
||||
```
|
||||
|
||||
The HWPOD spec is code-agent-side state. The default path is `.hwlab/hwpod-spec.yaml`; pass `--spec <path>` only when a task explicitly uses another workspace-local spec.
|
||||
The HWPOD definition is runtime service state. The standard runner contract is `--hwpod-id <id>` plus `--workspace-path <run-worktree>` when the task is bound to a run-local workspace. A task may provide the complete `hwpodWorkspaceArgs` string; reuse it exactly. `--spec <path>` is only an explicit debug/import path for a local exported YAML, not the default runner contract.
|
||||
|
||||
## Commands
|
||||
|
||||
- Inspect the HWPOD path: `hwpod inspect --spec .hwlab/hwpod-spec.yaml`.
|
||||
- Workspace search/read/edit: use `hwpod workspace ls|cat|read|rg|grep|search|write|replace|insert-after|apply-patch --spec .hwlab/hwpod-spec.yaml`. `read` is an alias for `cat`; `grep` and `search` are aliases for `rg`; `--file` and `--remote-path` are accepted as path aliases for file-oriented commands.
|
||||
- For symbol lookup or ARM-2D header hunting, prefer `hwpod workspace rg <pattern> [path] --context 3 --spec .hwlab/hwpod-spec.yaml` instead of `cat | grep`.
|
||||
- Inspect the HWPOD path: `hwpod inspect --hwpod-id d601-f103-v2 --workspace-path <run-worktree>`.
|
||||
- Workspace search/read/edit: use `hwpod workspace ls|cat|read|rg|grep|search|apply-patch --hwpod-id d601-f103-v2 --workspace-path <run-worktree>`. `read` is an alias for `cat`; `grep` and `search` are aliases for `rg`; `--file` and `--remote-path` are accepted as path aliases for file-oriented commands.
|
||||
- For symbol lookup or ARM-2D header hunting, prefer `hwpod workspace rg <pattern> [path] --context 3 --hwpod-id d601-f103-v2 --workspace-path <run-worktree>` instead of `cat | grep`.
|
||||
- Build/download/reset: use `hwpod build`, `hwpod download`, and `hwpod reset`; the compiler must translate these through existing file ops and `cmd.run` where possible.
|
||||
- Keil async status: after build/download returns a job id, use separate short `hwpod job status <jobId> --spec .hwlab/hwpod-spec.yaml` calls instead of shell polling wrappers such as `sleep &&`, `timeout`, `watch`, `head`, pipes, or loops.
|
||||
- UART read: use `hwpod uart read --spec .hwlab/hwpod-spec.yaml --port uart1`; the compiler runs the configured serial-monitor CLI through `cmd.run`.
|
||||
- For early debug bindings, put command bindings in `.hwlab/hwpod-spec.yaml` with `spec.workspace.buildCommand`, `spec.debugProbe.downloadCommand`, or `spec.debugProbe.resetCommand`.
|
||||
- Keil async status: after build/download returns a job id, use separate short `hwpod job status <jobId> --hwpod-id d601-f103-v2 --workspace-path <run-worktree>` calls instead of shell polling wrappers such as `sleep &&`, `timeout`, `watch`, `head`, pipes, or loops.
|
||||
- UART read: use `hwpod uart read --hwpod-id d601-f103-v2 --workspace-path <run-worktree> --port uart1`; the compiler runs the configured serial-monitor CLI through `cmd.run`.
|
||||
|
||||
## Boundaries
|
||||
|
||||
- Do not pass manual API URLs in locked AgentRun runtimes. Let `HWLAB_RUNTIME_API_URL` / `HWLAB_RUNTIME_NAMESPACE` select the current lane.
|
||||
- Do not put full `hwpod-spec` on `hwpod-node`. The node only accepts `hwpod-node-ops`.
|
||||
- Do not create, copy, restore, or repair runner-local `.hwlab/hwpod-spec.yaml` as a workaround. Use `hwpod-id` through the runtime service.
|
||||
- Do not use deprecated workspace mutation commands (`workspace write`, `replace`, or `insert-after`) for normal source edits. Use `workspace apply-patch`.
|
||||
- Treat `cmd.run` as the full-capability host execution op. Do not request new hwpod-node ops for build, download, job status, UART, PowerShell/cmd passthrough, or tool maintenance; improve `hwpod-compiler-cli` / `hwpod-cli` combinations first.
|
||||
- Use workspace file operations for subject text edits. Do not use PowerShell/cmd heredocs for normal source edits unless debugging `cmd.run` itself.
|
||||
- For multi-line edits, prefer `hwpod workspace apply-patch` with a Codex/UniDesk apply_patch v2 envelope from stdin or `--patch-content`. Put file paths in `*** Update File:` / `*** Add File:` / `*** Delete File:` headers. Do not pass raw unified diff (`---`, `+++`, `@@ -N`) as the whole patch; HWPOD deliberately rejects that format with a clear hint.
|
||||
|
||||
@@ -1,27 +1,26 @@
|
||||
---
|
||||
name: hwpod-ctl
|
||||
description: Manage the workspace-local HWLAB hwpod-spec and HWPOD node binding from a code agent runner. The hwpod-ctl skill is separate from hwpod-cli and is used for spec editing, validation, smoke checks, and temporary maintenance.
|
||||
description: Manage and validate HWLAB HWPOD runtime bindings from a code agent runner. The hwpod-ctl skill is separate from hwpod-cli and is used for hwpod-id validation, smoke checks, and explicit local spec import/export maintenance.
|
||||
---
|
||||
|
||||
# hwpod-ctl
|
||||
|
||||
This skill follows Skill(cli-spec). It is the standard management entry for the workspace-local HWPOD spec and node binding.
|
||||
This skill follows Skill(cli-spec). It is the standard management entry for runtime-resolved HWPOD identity and node binding checks.
|
||||
|
||||
## Scope
|
||||
|
||||
`hwpod-ctl` is a peer of `hwpod-cli`, not a fallback task path. Use it to maintain `.hwlab/hwpod-spec.yaml`, validate the four HWPOD elements, bind a node, and run smoke or temporary maintenance actions.
|
||||
`hwpod-ctl` is a peer of `hwpod-cli`, not a fallback task path. Use it to validate a service-resolved `hwpod-id`, inspect the four HWPOD elements, check node binding, and run smoke or temporary maintenance actions.
|
||||
|
||||
`hwpod-ctl` does not replace `hwpod-cli` for task execution. When a task needs source lookup, use `hwpod workspace rg/search` for symbol hunting and `hwpod workspace cat` only for full file bodies; when a task needs build/download/UART/job status, hand it back to `hwpod-cli` and its compiler-backed plan path.
|
||||
|
||||
## Commands
|
||||
|
||||
- Initialize or repair local spec: `hwpod-ctl spec init --spec .hwlab/hwpod-spec.yaml --node <nodeId>`.
|
||||
- Validate local spec before hardware work: `hwpod-ctl spec validate --spec .hwlab/hwpod-spec.yaml`.
|
||||
- Edit fields: `hwpod-ctl spec set <dot.path> <value> --spec .hwlab/hwpod-spec.yaml`.
|
||||
- Bind a node: `hwpod-ctl bind --spec .hwlab/hwpod-spec.yaml --node <nodeId>`.
|
||||
- Validate runtime HWPOD before hardware work: `hwpod-ctl spec validate --hwpod-id d601-f103-v2 --workspace-path <run-worktree>`.
|
||||
- Show the resolved HWPOD document: `hwpod-ctl spec show --hwpod-id d601-f103-v2 --workspace-path <run-worktree>`.
|
||||
- For explicit debug/import only, local YAML can still be passed with `--spec <path>`; do not use this as a runner default.
|
||||
|
||||
## Boundaries
|
||||
|
||||
- `hwpod-ctl` owns workspace-local spec management during the fast iteration stage; cloud-side HWPOD spec authority is a later stage.
|
||||
- `hwpod-ctl` must not initialize or restore runner-local `.hwlab/hwpod-spec.yaml` to make a task pass. HWPOD authority is the runtime service and `hwpod-id`.
|
||||
- `hwpod-node` must not receive or store the full `hwpod-spec`.
|
||||
- Temporary maintenance commands belong here, not in normal `hwpod-cli` task flows.
|
||||
|
||||
Reference in New Issue
Block a user