Make ward ops kubectl usable in director surface containers #867

New issue

Closed

opened 2026-07-09 20:47:53 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-09 20:47:53 +00:00

Member

A deploy director surface needed pod-level memory inventory for kai-server, but ward ops kubectl top pod -A --containers failed inside the director container with:

ward: exec: "kubectl": executable file not found in $PATH

The guard surface is present (ward ops kubectl --help lists get/top/logs/etc.), but the container image lacks the kubectl binary. That blocks read-only live ops from answering pod/container questions without falling back to host process names from node-stats-mcp.

Please make the director/warded surface that exposes ward ops kubectl also include a compatible kubectl binary, or route the guarded verb through a known installed path. Keep the fix in the owning layer for the warded container/runtime image, not deploy repo manifests.

Validation target: from a fresh director surface, ward ops kubectl top pod -A --containers should run far enough to reach cluster auth/API errors or return data, not fail with missing executable.

A deploy director surface needed pod-level memory inventory for kai-server, but `ward ops kubectl top pod -A --containers` failed inside the director container with: ```text ward: exec: "kubectl": executable file not found in $PATH ``` The guard surface is present (`ward ops kubectl --help` lists get/top/logs/etc.), but the container image lacks the `kubectl` binary. That blocks read-only live ops from answering pod/container questions without falling back to host process names from node-stats-mcp. Please make the director/warded surface that exposes `ward ops kubectl` also include a compatible `kubectl` binary, or route the guarded verb through a known installed path. Keep the fix in the owning layer for the warded container/runtime image, not deploy repo manifests. Validation target: from a fresh director surface, `ward ops kubectl top pod -A --containers` should run far enough to reach cluster auth/API errors or return data, not fail with missing executable.

coilyco-ops commented

2026-07-09 20:47:59 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-867 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T20:47:56Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#867 · branch issue-867 · harness codex · workflow pull-request
Run: engineer-codex-ward-867 · ward v0.501.0 · dispatched 2026-07-09T20:47:56Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.501.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-867` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T20:47:56Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#867` · branch `issue-867` · harness `codex` · workflow `pull-request` - **Run:** `engineer-codex-ward-867` · ward `v0.501.0` · dispatched `2026-07-09T20:47:56Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.501.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-09 20:55:26 +00:00

Make ward ops kubectl usable in director surface containers #868

coilyco-ops commented

2026-07-09 20:56:15 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: pull-requests; review summary: review gate skipped by ~/.ward/config.yaml default

felt: straightforward after the KDL parser catch

confidence: high

surprises: the exec dialect needs a quoted absolute path literal for kubectl

follow-ups: none

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-requests; review summary: review gate skipped by ~/.ward/config.yaml default felt: straightforward after the KDL parser catch confidence: high surprises: the exec dialect needs a quoted absolute path literal for kubectl follow-ups: none </details>

coilyco-ops closed this issue

2026-07-09 21:08:09 +00:00

coilyco-ops commented

2026-07-09 21:08:19 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: pull-request; review summary: passed: director merged PR #868 after green PR CI and mergeability checks.

merged PR #868 to main from the director merge queue.

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request; review summary: passed: director merged PR #868 after green PR CI and mergeability checks. merged PR #868 to main from the director merge queue. </details>