Expose guarded Forgejo Actions task rerun command #434

Closed
opened 2026-07-10 10:49:59 +00:00 by coilyco-ops · 8 comments
Member

Problem

The current coilyco Forgejo ops bundle exposes enough Actions state to find failed CI tasks, but not enough authority to re-run one through a guarded ward ops command.

Observed from a read-only director surface on 2026-07-10 UTC:

$ ward ops forgejo tasks --help
COMMANDS:
   list  GET /repos/{owner}/{repo}/actions/tasks

$ ward ops forgejo workflow --help
COMMANDS:
   dispatch  POST /repos/{owner}/{repo}/actions/workflows/{workflowfilename}/dispatches

$ ward ops forgejo actions --help
COMMANDS:
   logs  GET /repos/{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt}/logs (raw)

There is no tasks rerun, runs rerun, or equivalent command. A live tasks list call against coilyco-flight-deck/agentic-os shows failed PR tasks for agentic-os#433 and agentic-os#420, so the missing verb is blocking the current green-CI rescue loop rather than being theoretical.

The committed local OpenAPI lockfile currently contains ListActionRuns, ActionRun, ListActionTasks, and DispatchWorkflow, but no rerun operation:

.ward/forgejo.swagger.lock.json:
  /repos/{owner}/{repo}/actions/runs
  /repos/{owner}/{repo}/actions/runs/{run_id}
  /repos/{owner}/{repo}/actions/tasks
  /repos/{owner}/{repo}/actions/workflows/{workflowfilename}/dispatches

Public Forgejo docs document workflow_dispatch via POST /repos/{owner}/{repo}/actions/workflows/{workflowname}/dispatches, but do not document a task rerun endpoint. If the running Forgejo instance supports rerun through a route that is absent from the pinned swagger, the bundle needs an explicit supported overlay or ward needs a guarded custom call shape.

Do

  • Identify the actual Forgejo endpoint or UI-backed route that re-runs a failed Actions task/run on the deployed Forgejo version.
  • Add a guarded ward ops forgejo command for re-running a specific failed Actions task/run without exposing a broad raw HTTP escape hatch.
  • Keep the command narrower than workflow dispatch: it should target an existing task/run id and should not let agents trigger arbitrary workflows by mistake.
  • Update the committed Forgejo ops reference so future director surfaces show the rerun command.
  • If the endpoint is not present in the pinned swagger, choose the smallest maintainable path:
    • add the endpoint to the lock/spec overlay if the ward-kdl surface supports that, or
    • file and dispatch a ward follow-up if ward itself needs custom non-swagger endpoint support.

Acceptance

  • ward ops forgejo tasks --help or a clearly named sibling command exposes a rerun operation for an existing Actions task/run.
  • The command can re-run a failed PR CI task in a repo such as coilyco-flight-deck/agentic-os without using raw curl.
  • The guardfile keeps rerun scoped to existing Actions task/run identifiers.
  • docs/ward-ops-forgejo-reference.md includes the new command.
  • Repo validation passes, or the issue comment names the exact remaining blocker.

Related: coilyco-flight-deck/ward#1009, coilyco-flight-deck/agentic-os#431, and the current director CI rescue loop.

## Problem The current coilyco Forgejo ops bundle exposes enough Actions state to find failed CI tasks, but not enough authority to re-run one through a guarded `ward ops` command. Observed from a read-only director surface on 2026-07-10 UTC: ```text $ ward ops forgejo tasks --help COMMANDS: list GET /repos/{owner}/{repo}/actions/tasks $ ward ops forgejo workflow --help COMMANDS: dispatch POST /repos/{owner}/{repo}/actions/workflows/{workflowfilename}/dispatches $ ward ops forgejo actions --help COMMANDS: logs GET /repos/{owner}/{repo}/actions/runs/{run}/jobs/{job}/attempt/{attempt}/logs (raw) ``` There is no `tasks rerun`, `runs rerun`, or equivalent command. A live `tasks list` call against `coilyco-flight-deck/agentic-os` shows failed PR tasks for `agentic-os#433` and `agentic-os#420`, so the missing verb is blocking the current green-CI rescue loop rather than being theoretical. The committed local OpenAPI lockfile currently contains `ListActionRuns`, `ActionRun`, `ListActionTasks`, and `DispatchWorkflow`, but no rerun operation: ```text .ward/forgejo.swagger.lock.json: /repos/{owner}/{repo}/actions/runs /repos/{owner}/{repo}/actions/runs/{run_id} /repos/{owner}/{repo}/actions/tasks /repos/{owner}/{repo}/actions/workflows/{workflowfilename}/dispatches ``` Public Forgejo docs document `workflow_dispatch` via `POST /repos/{owner}/{repo}/actions/workflows/{workflowname}/dispatches`, but do not document a task rerun endpoint. If the running Forgejo instance supports rerun through a route that is absent from the pinned swagger, the bundle needs an explicit supported overlay or ward needs a guarded custom call shape. ## Do * Identify the actual Forgejo endpoint or UI-backed route that re-runs a failed Actions task/run on the deployed Forgejo version. * Add a guarded `ward ops forgejo` command for re-running a specific failed Actions task/run without exposing a broad raw HTTP escape hatch. * Keep the command narrower than workflow dispatch: it should target an existing task/run id and should not let agents trigger arbitrary workflows by mistake. * Update the committed Forgejo ops reference so future director surfaces show the rerun command. * If the endpoint is not present in the pinned swagger, choose the smallest maintainable path: * add the endpoint to the lock/spec overlay if the ward-kdl surface supports that, or * file and dispatch a ward follow-up if ward itself needs custom non-swagger endpoint support. ## Acceptance * `ward ops forgejo tasks --help` or a clearly named sibling command exposes a rerun operation for an existing Actions task/run. * The command can re-run a failed PR CI task in a repo such as `coilyco-flight-deck/agentic-os` without using raw `curl`. * The guardfile keeps rerun scoped to existing Actions task/run identifiers. * `docs/ward-ops-forgejo-reference.md` includes the new command. * Repo validation passes, or the issue comment names the exact remaining blocker. Related: coilyco-flight-deck/ward#1009, coilyco-flight-deck/agentic-os#431, and the current director CI rescue loop.
Author
Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T10:50:18Z). 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#434 · branch issue-434 · harness codex · workflow pull-requests-and-merge
  • Run: engineer-codex-agentic-os-434 · ward v0.580.0 · dispatched 2026-07-10T10:50:18Z
  • 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.580.0).

— Codex, via ward agent

<!-- ward-agent-reservation --> WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-agentic-os-434` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T10:50:18Z). 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#434` · branch `issue-434` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-agentic-os-434` · ward `v0.580.0` · dispatched `2026-07-10T10:50:18Z` - **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.580.0). </details> </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Author
Member

The rerun bridge is blocked by the current ward DSL surface. The overlay parses in isolation, but the live ward ops forgejo actions help still exposes only logs, so the rerun verbs never surface as a usable command. I stopped before broadening the surface further.

The rerun bridge is blocked by the current ward DSL surface. The overlay parses in isolation, but the live `ward ops forgejo actions` help still exposes only `logs`, so the rerun verbs never surface as a usable command. I stopped before broadening the surface further.
Author
Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T16:21:11Z). 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#434 · branch issue-434 · harness codex · workflow pull-requests-and-merge
  • Run: engineer-codex-agentic-os-434 · ward v0.583.0 · dispatched 2026-07-10T16:21:11Z
  • Comment thread: 1 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.583.0).

— Codex, via ward agent

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

WARD-OUTCOME: merge-ready

details

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

The rerun bridge landed cleanly after a CI-path fix in shell bootstrap. Confidence: high. Surprise: Forgejo CI used a different checkout path than the local surface, so the shell helpers and entrypoint had to derive the repo root from their own source locations. Follow-up: merge PR #436 when the director lane picks it up.

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default The rerun bridge landed cleanly after a CI-path fix in shell bootstrap. Confidence: high. Surprise: Forgejo CI used a different checkout path than the local surface, so the shell helpers and entrypoint had to derive the repo root from their own source locations. Follow-up: merge PR #436 when the director lane picks it up. </details>
Author
Member

WARD-RESERVATION: held 🔒

reservation details

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

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

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

— Codex, via ward agent

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

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skipped because review gate skipped by ~/.ward/config.yaml default
implemented the guarded Forgejo Actions rerun command, kept the list bridge intact, and merged the branch onto current main.
confidence: high
surprises: the bundle rename split in flight, so the merge had to reconcile mainline bundle files with the rerun overlay.
follow-ups: none.

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skipped because review gate skipped by ~/.ward/config.yaml default implemented the guarded Forgejo Actions rerun command, kept the list bridge intact, and merged the branch onto current main. confidence: high surprises: the bundle rename split in flight, so the merge had to reconcile mainline bundle files with the rerun overlay. follow-ups: none. </details>
Author
Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T18:04:09Z). 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#434 · branch issue-434 · harness codex · workflow pull-requests-and-merge
  • Run: engineer-codex-agentic-os-434 · ward v0.584.0 · dispatched 2026-07-10T18:04:09Z
  • Comment thread: 3 included in the pre-flight read, 3 stripped (ward's own automated comments).

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

— Codex, via ward agent

<!-- ward-agent-reservation --> WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-agentic-os-434` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T18:04:09Z). 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#434` · branch `issue-434` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-agentic-os-434` · ward `v0.584.0` · dispatched `2026-07-10T18:04:09Z` - **Comment thread:** 3 included in the pre-flight read, 3 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T11:36:35Z), @coilyco-ops (2026-07-10T16:33:20Z), @coilyco-ops (2026-07-10T17:03:53Z) - stripped: @coilyco-ops (2026-07-10T10:50:19Z), @coilyco-ops (2026-07-10T16:21:11Z), @coilyco-ops (2026-07-10T16:46:09Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.584.0). </details> </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Author
Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skip - review gate skipped by ~/.ward/config.yaml default
summary: merged current main into issue-434, kept the guarded rerun bridge, updated the release tar list and docs, and dropped the retired bundle validator/test.
felt: mostly mechanical, with two environment detours.
confidence: high
surprises: pre-commit cache exhaustion and a stale git ref cache in the hook env.
follow-ups: none.

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skip - review gate skipped by `~/.ward/config.yaml` default summary: merged current `main` into `issue-434`, kept the guarded rerun bridge, updated the release tar list and docs, and dropped the retired bundle validator/test. felt: mostly mechanical, with two environment detours. confidence: high surprises: pre-commit cache exhaustion and a stale git ref cache in the hook env. follow-ups: none. </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#434
No description provided.