Add ward-kdl fetch overlays and first input guard sugar

coilyco-ops commented

2026-07-10 05:30:45 +00:00

Member

Problem

AOS commit b9713b9cf3653d6aded503c31a0db02911077fd9 added a Forgejo Actions log command by wrapping bash .ward/forgejo-actions-logs.sh ... from a generated ward-kdl guardfile. That works only if script discovery is cwd-relative in exactly the right way, or if ward-kdl already has an undocumented bundle-relative executable resolver. The current rendered docs show the literal cwd-relative command, so this is too brittle for a shipped operator surface.

The same command is a good generic case for a ward-kdl fetch primitive: fixed HTTP GET, auth from the same env/SSM machinery, raw body streamed to stdout, and normal nonzero behavior on HTTP errors.

Requested change

Add a generic fetch/specgen surface for non-Swagger operator endpoints. It should be able to express a command like Forgejo Actions plaintext logs without a sidecar bash script.

Candidate shape, adjusted to the repo's parser conventions as needed:

wrap ward ops forgejo {
    fetch "actions logs" {
        method "GET"
        path "/{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt}/logs"
        output "raw"
        env FORGEJO_TOKEN {
            value ssm "/forgejo/coilyco-ops/api-token"
        }
        header "Authorization" "token ${FORGEJO_TOKEN}"
        header "Accept" "text/plain"
        when first input matches coily*
    }
}

Exact syntax is flexible. The semantics are not:

fetch streams or copies the response body to stdout without JSON rendering.
fetch preserves text/plain and other raw bodies.
fetch fails cleanly on non-2xx statuses and surfaces the status.
fetch can follow redirects when the spec asks for that, or documents the default.
generated reference docs show the HTTP fetch shape, not a fake local script invocation.
the guard language accepts first input as sugar for arg0, including parser tests and rendered docs.

Validation

Add parser/specgen tests, guard evaluation tests for first input, and an operator reference rendering test that proves a raw Forgejo-style log fetch can be generated without a bash script.

## Problem AOS commit `b9713b9cf3653d6aded503c31a0db02911077fd9` added a Forgejo Actions log command by wrapping `bash .ward/forgejo-actions-logs.sh ...` from a generated ward-kdl guardfile. That works only if script discovery is cwd-relative in exactly the right way, or if ward-kdl already has an undocumented bundle-relative executable resolver. The current rendered docs show the literal cwd-relative command, so this is too brittle for a shipped operator surface. The same command is a good generic case for a ward-kdl `fetch` primitive: fixed HTTP GET, auth from the same env/SSM machinery, raw body streamed to stdout, and normal nonzero behavior on HTTP errors. ## Requested change Add a generic fetch/specgen surface for non-Swagger operator endpoints. It should be able to express a command like Forgejo Actions plaintext logs without a sidecar bash script. Candidate shape, adjusted to the repo's parser conventions as needed: ```kdl wrap ward ops forgejo { fetch "actions logs" { method "GET" path "/{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt}/logs" output "raw" env FORGEJO_TOKEN { value ssm "/forgejo/coilyco-ops/api-token" } header "Authorization" "token ${FORGEJO_TOKEN}" header "Accept" "text/plain" when first input matches coily* } } ``` Exact syntax is flexible. The semantics are not: * fetch streams or copies the response body to stdout without JSON rendering. * fetch preserves text/plain and other raw bodies. * fetch fails cleanly on non-2xx statuses and surfaces the status. * fetch can follow redirects when the spec asks for that, or documents the default. * generated reference docs show the HTTP fetch shape, not a fake local script invocation. * the guard language accepts `first input` as sugar for `arg0`, including parser tests and rendered docs. ## Validation Add parser/specgen tests, guard evaluation tests for `first input`, and an operator reference rendering test that proves a raw Forgejo-style log fetch can be generated without a bash script.

coilyco-ops commented

2026-07-10 05:31:41 +00:00

Author

Member

Filed dispatch-surface blocker coilyco-flight-deck/ward#951. This issue was captured, but warded engineer ... could not start from the current read-only director surface because /usr/local/bin/warded fails with cannot execute: required file not found.

Filed dispatch-surface blocker coilyco-flight-deck/ward#951. This issue was captured, but `warded engineer ...` could not start from the current read-only director surface because `/usr/local/bin/warded` fails with `cannot execute: required file not found`.

coilyco-ops commented

2026-07-10 05:43:29 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T05:43:28Z). 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#950 · branch issue-950 · harness codex · workflow pull-requests
Run: engineer-codex-ward-950 · ward v0.555.0 · dispatched 2026-07-10T05:43:28Z
Comment thread: 1 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T05:31:41Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-950` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T05:43:28Z). 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#950` · branch `issue-950` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-ward-950` · ward `v0.555.0` · dispatched `2026-07-10T05:43:28Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T05:31:41Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.555.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 05:56:12 +00:00

Author

Member

WARD-DISPATCH: failed ❌

failure details

This forwarded dispatch failed after the issue was already reserved.

Attempted harness: codex
Attempted run: ward agent engineer coilyco-flight-deck/ward#950 --harness codex
Container: engineer-codex-ward-950
Container created: no running engineer was observed.
Host log: /Users/kai/.ward/agent-logs/dispatch/20260710T055608Z-director-codex-aq74-coilyco-flight-deck-ward-950.log
Failure: ward agent engineer --harness codex: issue coilyco-flight-deck/ward#950 is already reserved remotely (by @coilyco-ops at 2026-07-10T05:43:29Z); wait for it to finish or pass --force to override

Retry: choose another harness if the first one is down, or rerun with --force if the reservation is stale.

— Codex, via ward agent

WARD-DISPATCH: failed ❌ <details><summary>failure details</summary> This forwarded dispatch failed after the issue was already reserved. Attempted harness: `codex` Attempted run: `ward agent engineer coilyco-flight-deck/ward#950 --harness codex` Container: `engineer-codex-ward-950` Container created: no running engineer was observed. Host log: `/Users/kai/.ward/agent-logs/dispatch/20260710T055608Z-director-codex-aq74-coilyco-flight-deck-ward-950.log` Failure: `ward agent engineer --harness codex: issue coilyco-flight-deck/ward#950 is already reserved remotely (by @coilyco-ops at 2026-07-10T05:43:29Z); wait for it to finish or pass --force to override` Retry: choose another harness if the first one is down, or rerun with `--force` if the reservation is stale. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 06:44:01 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T06:44:00Z). 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#950 · branch issue-950 · harness codex · workflow pull-requests
Run: engineer-codex-ward-950 · ward v0.555.0 · dispatched 2026-07-10T06:44:00Z
Comment thread: 2 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T05:31:41Z), @coilyco-ops (2026-07-10T05:56:12Z)
- stripped: @coilyco-ops (2026-07-10T05:43:29Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-950` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T06:44:00Z). 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#950` · branch `issue-950` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-ward-950` · ward `v0.555.0` · dispatched `2026-07-10T06:44:00Z` - **Comment thread:** 2 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T05:31:41Z), @coilyco-ops (2026-07-10T05:56:12Z) - stripped: @coilyco-ops (2026-07-10T05:43:29Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.555.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 07:05:51 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T07:05:50Z). 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#950 · branch issue-950 · harness codex · workflow pull-requests
Run: engineer-codex-ward-950 · ward v0.555.0 · dispatched 2026-07-10T07:05:50Z
Comment thread: 2 included in the pre-flight read, 2 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T05:31:41Z), @coilyco-ops (2026-07-10T05:56:12Z)
- stripped: @coilyco-ops (2026-07-10T05:43:29Z), @coilyco-ops (2026-07-10T06:44:01Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-950` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T07:05:50Z). 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#950` · branch `issue-950` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-ward-950` · ward `v0.555.0` · dispatched `2026-07-10T07:05:50Z` - **Comment thread:** 2 included in the pre-flight read, 2 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T05:31:41Z), @coilyco-ops (2026-07-10T05:56:12Z) - stripped: @coilyco-ops (2026-07-10T05:43:29Z), @coilyco-ops (2026-07-10T06:44:01Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.555.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 07:24:48 +00:00

Author

Member

Dependency split: the generic fetch guardfile keyword and first input sugar belong in cli-guard, not as a ward-local parser fork. Filed and dispatched coilyco-flight-deck/cli-guard#216 for the engine work. Once that lands, this ward issue should bump cli-guard, replace the Forgejo Actions logs bash bridge with the fetch overlay, and update the rendered ops reference.

Dependency split: the generic `fetch` guardfile keyword and `first input` sugar belong in cli-guard, not as a ward-local parser fork. Filed and dispatched coilyco-flight-deck/cli-guard#216 for the engine work. Once that lands, this ward issue should bump cli-guard, replace the Forgejo Actions logs bash bridge with the fetch overlay, and update the rendered ops reference.

coilyco-ops commented

2026-07-10 08:57:43 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T08:57:42Z). 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#950 · branch issue-950 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-950 · ward v0.569.0 · dispatched 2026-07-10T08:57:42Z
Comment thread: 3 included in the pre-flight read, 3 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T05:31:41Z), @coilyco-ops (2026-07-10T05:56:12Z), @coilyco-ops (2026-07-10T07:24:48Z)
- stripped: @coilyco-ops (2026-07-10T05:43:29Z), @coilyco-ops (2026-07-10T06:44:01Z), @coilyco-ops (2026-07-10T07:05:51Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-950` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T08:57:42Z). 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#950` · branch `issue-950` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-950` · ward `v0.569.0` · dispatched `2026-07-10T08:57:42Z` - **Comment thread:** 3 included in the pre-flight read, 3 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T05:31:41Z), @coilyco-ops (2026-07-10T05:56:12Z), @coilyco-ops (2026-07-10T07:24:48Z) - stripped: @coilyco-ops (2026-07-10T05:43:29Z), @coilyco-ops (2026-07-10T06:44:01Z), @coilyco-ops (2026-07-10T07:05:51Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.569.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops added the

P2

headless

labels

2026-07-10 09:00:32 +00:00

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

2026-07-10 09:18:58 +00:00

Add ward-kdl fetch overlays and first input guard sugar #986

coilyco-ops closed this issue

2026-07-10 09:20:09 +00:00

coilyco-ops commented

2026-07-10 09:20:37 +00:00

Author

Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skipped (review gate skipped by ~/.ward/config.yaml default)
implementation: raw Forgejo Actions logs now stream through ward, and exec guardfiles accept first input as arg0
felt: straightforward once the ward-side override seams were identified
confidence: high
surprises: the local ward exec test path still trips the repo's config-ref guard in this harness
follow-ups: none

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) implementation: raw Forgejo Actions logs now stream through ward, and exec guardfiles accept `first input` as `arg0` felt: straightforward once the ward-side override seams were identified confidence: high surprises: the local `ward exec test` path still trips the repo's config-ref guard in this harness follow-ups: none </details>

Rows
Columns

Add ward-kdl fetch overlays and first input guard sugar #950

Problem

Requested change

Validation