Title: Make unavailable ward ops surfaces produce actionable subcommand… #1083

New issue

Closed

opened 2026-07-10 21:51:54 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-10 21:51:54 +00:00

Member

Title: Make unavailable ward ops surfaces produce actionable subcommand errors

Repro from a read-only director surface in /workspace/agentic-os on 2026-07-10:

$ ward ops forgejo describe
ward: ward ops forgejo: guardfile runtime failed to mount: read bundle ops manifest ward.bundle.kdl: open ward.bundle.kdl: no such file or directory

$ ward ops forgejo --help
NAME:
   ward ops forgejo - guarded Forgejo REST surface (unavailable)

$ ward ops forgejo issue list --help
ward: No help topic for 'issue'

The first two outputs expose that the surface is unavailable, but nested help loses that context and looks like the user typed an invalid noun. In a director surface this makes the operator/debugging path worse, because the next natural move is to check the generated subcommand help.

Task:

When an ops surface is unavailable, make nested invocations like ward ops forgejo issue list --help fail with the same actionable unavailability reason, or a short message that names the unavailable surface and suggests ward ops forgejo --help / describe once the bundle is mounted.
Preserve normal behavior when the surface is available.
Add a regression test for a missing bundle or unavailable mount with a nested help/subcommand invocation.
Keep the message public-safe and do not mention host-specific paths.

Related evidence:

The aos docs say read-only director shells should have WARD_CONFIG_REF seeded. agentic-os#455 tracks fixing that bootstrap side.
This ward issue is only about the CLI behavior when the ops surface is unavailable.

Filed by ward agent engineer --harness codex.

— Codex, via ward agent

Title: Make unavailable ward ops surfaces produce actionable subcommand errors Repro from a read-only director surface in `/workspace/agentic-os` on 2026-07-10: ```text $ ward ops forgejo describe ward: ward ops forgejo: guardfile runtime failed to mount: read bundle ops manifest ward.bundle.kdl: open ward.bundle.kdl: no such file or directory $ ward ops forgejo --help NAME: ward ops forgejo - guarded Forgejo REST surface (unavailable) $ ward ops forgejo issue list --help ward: No help topic for 'issue' ``` The first two outputs expose that the surface is unavailable, but nested help loses that context and looks like the user typed an invalid noun. In a director surface this makes the operator/debugging path worse, because the next natural move is to check the generated subcommand help. Task: - When an ops surface is unavailable, make nested invocations like `ward ops forgejo issue list --help` fail with the same actionable unavailability reason, or a short message that names the unavailable surface and suggests `ward ops forgejo --help` / `describe` once the bundle is mounted. - Preserve normal behavior when the surface is available. - Add a regression test for a missing bundle or unavailable mount with a nested help/subcommand invocation. - Keep the message public-safe and do not mention host-specific paths. Related evidence: - The aos docs say read-only director shells should have `WARD_CONFIG_REF` seeded. `agentic-os#455` tracks fixing that bootstrap side. - This ward issue is only about the CLI behavior when the ops surface is unavailable. --- Filed by `ward agent engineer --harness codex`.  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 21:52:02 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-1083 on host KAI-DESKTOP-TOWER.

Reserved by ward agent --harness codex (reserved 2026-07-10T21:52:02Z). 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#1083 · branch issue-1083 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-1083 · ward v0.605.0 · dispatched 2026-07-10T21:52:02Z
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.605.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-1083` on host `KAI-DESKTOP-TOWER`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T21:52:02Z). 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#1083` · branch `issue-1083` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-1083` · ward `v0.605.0` · dispatched `2026-07-10T21:52:02Z` - **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.605.0). </details> </details>  — Codex, via `ward agent`

coilysiren commented

2026-07-10 21:54:47 +00:00

Owner

This isn't a ward issue at all? Ward shouldn't be in the business of mediating guard mechanics aside from being the entry point CLI for invoking them. If we do this it needs to be weaved into specgen, which is a guard concern

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

2026-07-10 22:04:05 +00:00

Make unavailable ward ops surfaces produce actionable subcommand errors #1088

coilyco-ops commented

2026-07-10 22:05:33 +00:00

Author

Member

WARD-OUTCOME: submitted

details

workflow: pull-request-and-merge; review summary: skip state
review gate: intentionally skipped because the temporary ward default is pending brokered QA
implementation: nested help on an unavailable forgejo surface now reuses the mount-failure message instead of degrading to No help topic
confidence: high
surprises: full go test ./... hit unrelated integration failures; the targeted ops slice and pre-commit gate passed
follow-ups: none

WARD-OUTCOME: submitted <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skip state review gate: intentionally skipped because the temporary ward default is pending brokered QA implementation: nested help on an unavailable forgejo surface now reuses the mount-failure message instead of degrading to No help topic confidence: high surprises: full go test ./... hit unrelated integration failures; the targeted ops slice and pre-commit gate passed follow-ups: none  </details>

coilyco-ops closed this issue

2026-07-10 22:14:08 +00:00