Add specverb fetch overlays and first input guard sugar

coilyco-ops commented

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

Member

Ward needs a generic guardfile/specverb fetch surface for non-Swagger endpoints instead of cwd-relative bash wrappers. This is the engine half of ward#950.

Requirements:

Add a fetch guardfile node that mounts an HTTP fetch leaf under the wrapped command path.
Support fixed method/path, path placeholders from positional args, auth/value providers, headers, raw stdout output, and non-2xx failure with status/body context.
Keep redirects bounded by the existing opcore client behavior: GET/HEAD may follow, mutating methods must not silently redirect.
Include describe output so generated references show the HTTP fetch, not a fake local script.
Add guard-language sugar first input as an alias for arg0, with parser tests and docs.
Preserve fail-closed behavior for unknown fields and invalid fetch definitions.

Candidate ward KDL shape:

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*
    }
}

After this lands, ward can bump cli-guard and replace its Forgejo Actions log bash bridge with the fetch overlay.

Ward needs a generic guardfile/specverb `fetch` surface for non-Swagger endpoints instead of cwd-relative bash wrappers. This is the engine half of ward#950. Requirements: * Add a `fetch` guardfile node that mounts an HTTP fetch leaf under the wrapped command path. * Support fixed method/path, path placeholders from positional args, auth/value providers, headers, raw stdout output, and non-2xx failure with status/body context. * Keep redirects bounded by the existing opcore client behavior: GET/HEAD may follow, mutating methods must not silently redirect. * Include describe output so generated references show the HTTP fetch, not a fake local script. * Add guard-language sugar `first input` as an alias for `arg0`, with parser tests and docs. * Preserve fail-closed behavior for unknown fields and invalid fetch definitions. Candidate ward KDL shape: ```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* } } ``` After this lands, ward can bump cli-guard and replace its Forgejo Actions log bash bridge with the fetch overlay.

coilyco-ops commented

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

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-cli-guard-216 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T07:24:41Z). 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/cli-guard#216 · branch issue-216 · harness codex · workflow pull-requests
Run: engineer-codex-cli-guard-216 · ward v0.555.0 · dispatched 2026-07-10T07:24:41Z
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.555.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-cli-guard-216` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T07:24:41Z). 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/cli-guard#216` · branch `issue-216` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-cli-guard-216` · ward `v0.555.0` · dispatched `2026-07-10T07:24:41Z` - **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.555.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from coilyco-flight-deck/ward

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

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

coilyco-ops commented

2026-07-10 07:38:02 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-cli-guard-216 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T07:38:01Z). 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/cli-guard#216 · branch issue-216 · harness codex · workflow pull-requests
Run: engineer-codex-cli-guard-216 · ward v0.555.0 · dispatched 2026-07-10T07:38:01Z
Comment thread: 0 included in the pre-flight read, 1 stripped (ward's own automated comments).
- stripped: @coilyco-ops (2026-07-10T07:24:42Z)

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-cli-guard-216` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T07:38:01Z). 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/cli-guard#216` · branch `issue-216` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-cli-guard-216` · ward `v0.555.0` · dispatched `2026-07-10T07:38:01Z` - **Comment thread:** 0 included in the pre-flight read, 1 stripped (ward's own automated comments). - stripped: @coilyco-ops (2026-07-10T07:24:42Z) 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 08:10:48 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-cli-guard-216 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T08:10:47Z). 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/cli-guard#216 · branch issue-216 · harness codex · workflow pull-requests
Run: engineer-codex-cli-guard-216 · ward v0.555.0 · dispatched 2026-07-10T08:10:47Z
Comment thread: 0 included in the pre-flight read, 2 stripped (ward's own automated comments).
- stripped: @coilyco-ops (2026-07-10T07:24:42Z), @coilyco-ops (2026-07-10T07:38:02Z)

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-cli-guard-216` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T08:10:47Z). 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/cli-guard#216` · branch `issue-216` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-cli-guard-216` · ward `v0.555.0` · dispatched `2026-07-10T08:10:47Z` - **Comment thread:** 0 included in the pre-flight read, 2 stripped (ward's own automated comments). - stripped: @coilyco-ops (2026-07-10T07:24:42Z), @coilyco-ops (2026-07-10T07:38:02Z) 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 added the

P2

headless

labels

2026-07-10 08:59:44 +00:00

coilyco-ops commented

2026-07-10 16:45:23 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-cli-guard-216 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T16:45:23Z). 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/cli-guard#216 · branch issue-216 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-cli-guard-216 · ward v0.584.0 · dispatched 2026-07-10T16:45:23Z
Comment thread: 0 included in the pre-flight read, 3 stripped (ward's own automated comments).
- stripped: @coilyco-ops (2026-07-10T07:24:42Z), @coilyco-ops (2026-07-10T07:38:02Z), @coilyco-ops (2026-07-10T08:10:48Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-cli-guard-216` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T16:45:23Z). 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/cli-guard#216` · branch `issue-216` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-cli-guard-216` · ward `v0.584.0` · dispatched `2026-07-10T16:45:23Z` - **Comment thread:** 0 included in the pre-flight read, 3 stripped (ward's own automated comments). - stripped: @coilyco-ops (2026-07-10T07:24:42Z), @coilyco-ops (2026-07-10T07:38:02Z), @coilyco-ops (2026-07-10T08:10:48Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.584.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-10 17:14:26 +00:00

Add fetch overlays and first input sugar

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

2026-07-10 17:14:53 +00:00

Add fetch overlays and first input sugar #221

coilyco-ops commented

2026-07-10 17:16: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)
summary: added fetch overlays and first input sugar across parser, runtime, describe, tests, and docs.
felt: steady integration work with a few lint and doc-cap cleanups.
confidence: high.
surprises: the repo-level docs size cap and godoc drift were the only real follow-up chores.
follow-ups: merge PR #221 when the merge director is ready.

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skipped (review gate skipped by ~/.ward/config.yaml default) summary: added fetch overlays and first input sugar across parser, runtime, describe, tests, and docs. felt: steady integration work with a few lint and doc-cap cleanups. confidence: high. surprises: the repo-level docs size cap and godoc drift were the only real follow-up chores. follow-ups: merge PR #221 when the merge director is ready. </details>

coilyco-ops closed this issue

2026-07-10 22:12:21 +00:00

Rows
Columns

Add specverb fetch overlays and first input guard sugar #216