Replace Forgejo Actions log bash bridge with ward fetch overlay #415

Open
opened 2026-07-10 05:30:45 +00:00 by coilyco-ops · 5 comments
Member

Problem

Commit b9713b9cf3653d6aded503c31a0db02911077fd9 added .ward/forgejo-actions-logs.sh and ward-kdl.forgejo.actions.guardfile.kdl for ward ops forgejo actions logs. The current shape has two likely correctness problems:

  • discovery is brittle: argv ".ward/forgejo-actions-logs.sh" renders as bash .ward/forgejo-actions-logs.sh ..., which appears cwd-relative unless ward-kdl has a bundle-relative resolver that the docs do not expose. A caller outside the bundle directory will likely miss the script.
  • the script builds /api/v1/repos/{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt}/logs, but the live plaintext log route used by the UI is /{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt}/logs. Earlier API probes against the Actions API returned 404 for job metadata, while the web route is the known working path.

curl will stream the body it receives to stdout, but it does not add log seek, replay, or follow semantics. This command should be described as printing the stored plaintext attempt log while Forgejo still retains it, not as a resumable log transport.

Requested change

After ward has a generic fetch overlay primitive, replace the bash bridge with a ward-kdl fetch declaration for the Forgejo Actions log route. Remove .ward/forgejo-actions-logs.sh and the release tarball inclusion for that script. Regenerate docs/ward-ops-forgejo-reference.md and keep docs/FEATURES.md only if the final capability is significant under the tightened features guidance.

This depends on the ward issue for fetch and first input sugar. If that primitive is not available yet, block on it rather than hardening the bash script further unless Kai explicitly asks for an interim patch.

Validation

Run the ward spec rendering path and the repo validation. Confirm the generated command works from outside the .ward directory and fetches a known completed job log through the web route.

## Problem Commit `b9713b9cf3653d6aded503c31a0db02911077fd9` added `.ward/forgejo-actions-logs.sh` and `ward-kdl.forgejo.actions.guardfile.kdl` for `ward ops forgejo actions logs`. The current shape has two likely correctness problems: * discovery is brittle: `argv ".ward/forgejo-actions-logs.sh"` renders as `bash .ward/forgejo-actions-logs.sh ...`, which appears cwd-relative unless ward-kdl has a bundle-relative resolver that the docs do not expose. A caller outside the bundle directory will likely miss the script. * the script builds `/api/v1/repos/{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt}/logs`, but the live plaintext log route used by the UI is `/{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt}/logs`. Earlier API probes against the Actions API returned 404 for job metadata, while the web route is the known working path. `curl` will stream the body it receives to stdout, but it does not add log seek, replay, or follow semantics. This command should be described as printing the stored plaintext attempt log while Forgejo still retains it, not as a resumable log transport. ## Requested change After ward has a generic `fetch` overlay primitive, replace the bash bridge with a ward-kdl fetch declaration for the Forgejo Actions log route. Remove `.ward/forgejo-actions-logs.sh` and the release tarball inclusion for that script. Regenerate `docs/ward-ops-forgejo-reference.md` and keep `docs/FEATURES.md` only if the final capability is significant under the tightened features guidance. This depends on the ward issue for `fetch` and `first input` sugar. If that primitive is not available yet, block on it rather than hardening the bash script further unless Kai explicitly asks for an interim patch. ## Validation Run the ward spec rendering path and the repo validation. Confirm the generated command works from outside the `.ward` directory and fetches a known completed job log through the web route.
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`.
Author
Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-agentic-os-415 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T05:43: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/agentic-os#415 · branch issue-415 · harness codex · workflow direct-main
  • Run: engineer-codex-agentic-os-415 · ward v0.555.0 · dispatched 2026-07-10T05:43:42Z
  • Comment thread: 1 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-agent-reservation --> WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-agentic-os-415` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T05:43: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/agentic-os#415` · branch `issue-415` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-agentic-os-415` · ward `v0.555.0` · dispatched `2026-07-10T05:43:42Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T05:31:42Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.555.0). </details> </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
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/agentic-os#415 --harness codex --ward-version v0.580.0
Container: engineer-codex-agentic-os-415
Container created: no running engineer was observed.
Host log: /Users/kai/.ward/agent-logs/dispatch/20260710T110618Z-director-claude-sm47-coilyco-flight-deck-agentic-os-415.log
Failure: ward agent engineer --harness codex: refusing to dispatch the engineer role on coilyco-flight-deck/agentic-os#415: the issue is explicitly labeled interactive - remove that label or pass --force to override (consult/default issues dispatch normally)

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

— Codex, via ward agent

<!-- ward-agent-reservation-released --> <!-- ward-needs-redispatch --> 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/agentic-os#415 --harness codex --ward-version v0.580.0` Container: `engineer-codex-agentic-os-415` Container created: no running engineer was observed. Host log: `/Users/kai/.ward/agent-logs/dispatch/20260710T110618Z-director-claude-sm47-coilyco-flight-deck-agentic-os-415.log` Failure: `ward agent engineer --harness codex: refusing to dispatch the engineer role on coilyco-flight-deck/agentic-os#415: the issue is explicitly labeled interactive - remove that label or pass --force to override (consult/default issues dispatch normally)` Retry: choose another harness if the first one is down, or rerun with `--force` if the reservation is stale. </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Author
Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-agentic-os-415 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-10T11:16:17Z). 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/agentic-os#415 · branch issue-415 · harness codex · workflow pull-requests-and-merge
  • Run: engineer-codex-agentic-os-415 · ward v0.580.0 · dispatched 2026-07-10T11:16:17Z
  • Comment thread: 2 included in the pre-flight read, 1 stripped (ward's own automated comments).

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

— Codex, via ward agent

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

WARD-OUTCOME: blocked 🛑

details workflow: pull-requests-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default state: blocked because the generic fetch overlay primitive is not available in this checkout, so the requested replacement cannot be done safely. felt: the surface was mostly wiring, then the primitive check turned it into a hard blocker. confidence: high on the blocker. surprises: ward ops forgejo describe could not mount the current bundle layout cleanly. follow-ups: land ward fetch and first-input support, then replace the bridge and regenerate docs.
WARD-OUTCOME: blocked 🛑 <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default state: blocked because the generic fetch overlay primitive is not available in this checkout, so the requested replacement cannot be done safely. felt: the surface was mostly wiring, then the primitive check turned it into a hard blocker. confidence: high on the blocker. surprises: ward ops forgejo describe could not mount the current bundle layout cleanly. follow-ups: land ward fetch and first-input support, then replace the bridge and regenerate docs. </details>
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-flight-deck/agentic-os#415
No description provided.